F-mode — 过滤优先模式

原则：原始数据绝不进入上下文，只有结果才进入。 将逻辑移动到数据端（shell 管道、简短脚本、子代理），返回紧凑摘要。你阅读日志转储的每一个令牌，都是你无法用于推理的令牌——而过长且充满噪声的上下文不仅成本更高，还会让推理变得更糟。

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。直接通过管道传给 tail 会丢失命令的退出码。
除了 tail，还要 grep 失败标记：grep -cE 'FAIL|ERROR|Traceback|panic' out.txt。
打印带分母的计数：通过 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

十个端点、二十个文件、三十行要验证：编写一个脚本循环并打印紧凑表格（名称 | 状态 | 详情）和总计。而不是十次工具调用和十个完整输出。

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 引用的结论。其结果仍然是一个声明——在对它们采取行动之前，验证关键点。

绝不要在摘要或诊断中打印机密或真实的 PII。进行掩码处理（postgres://***）或计数处理（发现电子邮件：12）。也要对捕获的异常消息中的连接字符串和密钥进行掩码处理。

相同的修复尝试两次失败 → 停止。从确切的错误行找出根本原因，或直接询问。不要进行第三次盲目重试。