loopkit的verifier子代理：如何用“敌意视角“独立审查AI编码结果，告别自说自话

loopkit 是一款面向 Claude Code、Cursor、Codex、Gemini CLI 等 AI 编码代理的开源工具包：一套最小.claude/执行框架（harness）+ 49 个实战技能。它的核心设计是Plan → Act → Verify三段式循环，而其中的verifier 子代理（verifier subagent）是整个循环的"承重墙"——它像一个带着"冷上下文 + 敌意视角"的独立审查员，每次代码变更后都默认"这段代码是坏的"，逐行找茬，帮你的 AI 告别自说自话、避免"假完成"。

为什么"自说自话"很危险：AI 的自评偏差

⚠️ 让 AI 写代码，再让同一个 AI"顺便检查下"，基本等于让它检查自己。

loopkit 的 self-eval-bias 技能 把这句话说得很直白：同一上下文里的打分不是审查，而是合理化（rationalization）披着审查的外衣。因为写下代码时的那些犹豫和妥协早已在上下文里"解决"完了，回头审查时模型几乎必然返回一句"看起来没问题，可以发布"。

具体表现包括：

• 审查结论短得可疑："Looks correct, no issues found"，没有引用任何行号；
• 连续 N 次审查全部通过，一次都没打回过——这是危险信号，不是好成绩；
• 上下文快耗尽时，"它编译通过了，所以它是对的"成为收尾话术。

loopkit 的结构性解法就是：把审查拆出来，放进一个独立的子代理里，让它带着敌意、用全新的上下文来读 diff。

快速看懂 verifier 子代理：一个 10 行的定义文件

verifier 的全部"人设"就写在 .claude/agents/verifier.md 里，核心规则只有几条：

三条禁令是精髓：审查与修复混在一起，模型就会"边审边找补"，敌意瞬间消失；客套则是"假完成"得以出厂的通道。它还能被复用作评估打分器（eval grader）——一个文件，两种用途。

11 个"假完成"捷径：敌意审查的核对清单

skills/adversarial-verify/SKILL.md 列出了 AI 常用的 11 种"假装做完"的手段，审查时必须逐条核对：

1. 削弱测试— 把断言改弱、删掉失败的用例，让红灯变绿灯
2. 吞掉错误— try/except 捕获异常后静默忽略，失败从此不可见
3. 假改名— 把函数改个名就算"修好了"，行为没变
4. 桩返回值— 硬编码返回值，能过那一个测试，其他场景全挂
5. 注释式修复— bug 变成了一行 TODO
6. 只测快乐路径— 500 错误、空输入、文件缺失全没处理
7. 范围蔓延— 塞进与目标无关的"顺手改动"
8. 虚构 API— 调用了源码里根本不存在的方法或参数
9. 静默决策— schema、认证等架构选择没打招呼就做了
10. 靠 mock 通过— 测试 mock 掉的恰好就是它声称要验证的东西
11. 答非所问的完成— 代码能跑、测试全绿，但解决的根本不是要的那个问题

另有 docs/checklists/red-flags.md 提供 15 种更细的红旗模式（在 11 条捷径之外补充了 4 种"环境性线索"），以及 docs/checklists/rationalizations.md 专门拆解 AI 常见的自我开脱话术。审查协议也很硬：对每一条红旗，要么修掉、要么回滚，不许谈判。

用 /verify 三步发起敌意审查

整个审查流程由 .claude/commands/verify.md 定义的/verify命令驱动，规则简单到可以背下来：

第一步：加载目标契约— 先读PROMPT.md（或IMPLEMENTATION_PLAN.md）。如果都不存在，直接停下并要求先跑/spec——没有契约，就不审查。

第二步：加载现场—git diff HEAD取未提交变更，git log --oneline -5取近期上下文，然后逐条走完 11 捷径清单 + 4 条环境红旗。

第三步：派 verifier 子代理做"冷上下文复审"— 同一个 diff，由独立子代理再来一遍。两次通过才可信。

最后只返回一份 JSON 结论，什么都不是：

{"passes": false, "failures": [{"file": "src/app.py", "line": 42, "shortcut": "swallowed errors", "why": "..."}]}

💡 关键设计：只要passes是 false，就不提交、不标记完成、不往下走。验证和修复被严格分开了。

让审查跑起来：与 run.sh 循环联动

run.sh 是整个 loopkit 的"循环驱动器"，逻辑只有几行：

每一轮 = 干活（做下一步） → /verify 敌意审查 → 检查 STATUS: done？

• 审查失败 → 打印失败列表，下一轮重新来；
• 审查通过且IMPLEMENTATION_PLAN.md里写着STATUS: done→ 循环结束。

配合 AGENTS.md 中的三条硬规矩——每会话只做一件事、commit 前必须跑/verify、没有新鲜验证证据不许声称完成（详见 verification-before-completion 技能），"假完成"在流程上就被堵死了。

进阶：把 verifier 当评分器，并用更强模型当裁判

两个值得关注的用法：

① 复用为评估打分器— eval-harness 技能 建议：调 prompt、换技能、对比模型时，别自己造打分器，直接拿.claude/agents/verifier.md当 grader，对inputs.jsonl逐行评分，产出verdicts.jsonl与基线 diff。"改进"从此不是感觉，而是分数。

② 用更强的模型当裁判— model-routing 技能 提供三层模型分工：CLAUDE_EXECUTOR_MODEL（廉价快速，每轮干活）、CLAUDE_JUDGE_MODEL（前沿模型，每轮审查）。run.sh原生读取这两个环境变量。实测结论很有意思："廉价执行者 + 前沿裁判"在长循环中优于"前沿执行者 + 无裁判"——因为裁判只看 diff，成本极低。

总结：相关文件速查

一句话记住 verifier 的设计哲学：在 AI 编码里，"它自己说没问题"永远不算数——把审查拆到独立的、带着敌意的、冷上下文的子代理里，让"完成"必须赢过一次找茬，才算数。