F-mode — 過濾優先模式

原則：原始資料絕不進入上下文；只有結果才進入。 將邏輯移至資料端（shell 管線、簡短腳本、子代理），並帶回精簡摘要。你閱讀日誌轉儲的每個 Token，都是你無法用於推理的 Token——而冗長嘈雜的上下文不僅讓推理更昂貴，還會讓推理品質變差。

1. 先過濾和聚合，再讀取

不要這樣做	改這樣做
`cat app.log`	`grep -c ERROR app.log; grep -E 'ERROR
讀取 5 MB 的 JSON	`jq '.items \| length'`、`jq -r '.items[] \| [.id,.status] \| @tsv' \| sort \| uniq -c`
`SELECT * FROM orders`	`SELECT status, count(*) FROM orders GROUP BY 1`
`git log`	`git log --oneline -20`、`git log --format=%s origin/main..HEAD`
滾動瀏覽檔案	`grep -n 'def handle' file.py`，然後使用偏移/限制讀取

一個看起來一切正常的截斷檢視，比沒有檢視更糟糕。

保留退出碼：set -o pipefail，或 cmd > out.txt 2>&1; echo "exit=$?"; tail -20 out.txt。直接 pipe 進 tail 會遺失指令的退出碼。
除了 tail 之外，還要 grep 失敗標記：grep -cE 'FAIL|ERROR|Traceback|panic' out.txt。
印出帶分母的計數：passed 41/42，絕不只是「OK」。

pytest -q --tb=short > /tmp/t.out 2>&1; echo "exit=$?"
grep -cE 'FAILED|ERROR' /tmp/t.out; tail -15 /tmp/t.out

十個端點、二十個檔案、三十個要驗證的資料列：撰寫一個腳本進行迴圈，並印出一個精簡表格 (name | status | detail) 以及總計。而不是進行十次工具呼叫，每次回傳十個完整輸出。

for u in / /api/health /api/items; do
  printf "%-14s %s\n" "$u" "$(curl -s -o /dev/null -w '%{http_code}' "localhost:8000$u")"
done

看起來有效的輸出仍然可能是錯的。請與預期值或完整性總數進行比對：計數加起來是否等於輸入大小、已知的資料列是否存在、檔案數量是否與 ls | wc -l 相符。如果無法交叉檢查摘要，請明確說明。

靜默模式、簡短回溯、失敗區段的尾端：

執行一個回傳精簡 JSON ({title, errors: n, buttons: n, overflowX: bool}) 的腳本，而不是完整的 DOM 快照。只有在 DOM 結構本身就是問題時才拍攝快照。螢幕截圖用於視覺檢查，而非讀取文字。

大型搜尋、日誌取證、資料庫傾印：委派給一個子代理，由其回傳帶有 file:line 參考的結論。其結果仍然是一個主張——在據以行動之前，請驗證關鍵要點。

切勿在摘要或診斷中印出機密或真實的個人識別資訊。請遮罩（postgres://***）或計數（emails found: 12）。同時也要遮罩捕獲的例外訊息中的連線字串和金鑰。

同一個修復失敗兩次 → 停止。從確切的錯誤行找出根本原因，或提出詢問。不得進行第三次盲目重試。