用跨模型审查补上AI编码盲点

Claude Code 写完代码、跑通测试，再让它检查一遍，仍然可能漏掉重要问题。作者给出的办法是：让另一个工具里的不同模型独立审查，再让双方拿证据讨论，无法解决的分歧交给人。

这套方法在作者开发 agy-bridge 时，抓出了重复启动审查进程、未备份未提交代码等真实缺陷。文章值得看的，是怎样组织审查、质疑错误建议，以及让能运行测试的审查 Agent 接触项目时，如何保护现场。

为什么换一个窗口还不够

作者坚持两个条件：不同工具、不同模型。

模型负责推理，工具负责系统提示、文件读取、命令执行和上下文组织。同一个模型装进不同工具，表现可能不同；两个窗口如果用的是同一个模型，也可能共享相似盲点。

按作者标注的 2026 年 11 月配置，Claude Code 担任主 Agent：Fable 负责设计，Opus 写代码，Sonnet 测试；Antigravity 中的 Gemini 4 Argon 审查各阶段，并参与设计讨论。多数审查使用 medium effort，架构或安全敏感改动再提高投入。这是作者当时的搭配，不是通用排名。

他选择完整的 Agent 工具，是因为审查者需要自己读上下游文件、运行测试，并在临时目录验证替代方案。只看提交过去的 diff，容易遗漏调用约束。

不过，作者把模型的默认输出概括为「平均水平」，又把自查的局限归因于训练分布和服从倾向，这部分属于他的解释。原文没有实验支撑这些普遍判断，也没有证明跨模型组合一定优于同模型的独立审查。

这篇文章最有价值的，是让审查者拿出可验证的证据。

四阶段审查，重点是允许反驳并强制复查

第一阶段是交接。审查者不继承作者全部对话，避免一起接受前面未经验证的假设，但必须知道需求、修改范围、测试与构建方式、重点风险，以及已经确认的问题。

作者会把审查者设定成团队外部的资深专家。这种角色提示究竟贡献多大，原文没有对照数据；交接信息是否完整，则直接决定审查是否有用。

第二阶段要求结构化结论：批准、要求修改或需要讨论，每个问题附上严重程度、位置、原因和建议，再列出需要作者回答的问题。

同时，关键主张必须标为 user、evidence、inferred 或 unknown，并注明具体来源。标签不够，文件、测试、日志或用户原话才是依据。作者最初只要求标签，审查者两次把猜测当事实；补上来源要求后，他报告这个问题得到修正。

一次演讲规划中，Claude 默认听众是 Python 开发者。审查者追问出处，才发现这是猜测，相关方向随即暂停，等待知情人确认。对 AI 编程而言，「这个接口保证不会返回空值」也应该接受同样的追问。

第三阶段把审查交回作者，但不能直接命令它全部照做。

作者记录了一个具体反例：Antigravity 找到了恢复代码中的真实问题，却建议用 git apply --relative 修复。Claude 在临时仓库验证后发现，从子目录运行会静默跳过补丁，于是反驳，审查者接受了证据。发现缺陷和给对修复方案，是两件事。

设计争议则允许讨论一次后结束。作者用一个定价案例测试这条规则：原本 4 行的函数加入 5 美元优惠券，又被拆成六个类。审查者发现，3 美元订单会算成负 2 美元，将其标为 medium；过度设计被标为 low。作者修复计算错误，并解释下个迭代会增加折扣类型，审查者接受理由，没有继续纠缠类的数量。

第四阶段是修改后复查。作者曾观察到 Claude 为了「快一点」跳过这一步，因此把禁止跳过复查写进 skill。

修复也是新代码，测试通过不能替代对修复的审查。

作者的经验是，第二轮通常已经足够；争论一轮后仍不能一致，或者出现只有用户能回答的问题，就带着双方理由交给人。这是停止规则，不是无限互审。

agy-bridge 自动化了什么，又留下哪些边界

agy-bridge 是一个开源 MCP server，通过 Antigravity 的无界面命令行工具 agy 收发 JSON，复用已有登录，无需额外管理 API key。每次审查维持一个进程，保存会话 ID，支持跨 Claude Code 会话恢复；桥接层不硬编码模型。

下面的返回格式，让 Claude 可以逐项处理审查意见，而不是面对一篇泛泛的评论：

{
  "verdict": "changes_requested",
  "summary": "Retries work, but the backoff ignores Retry-After and one path never gives up.",
  "findings": [
    {"severity": "high", "category": "correctness", "location": "client.py:88",
     "issue": "...", "recommendation": "..."}
  ],
  "questions_for_claude": ["Should a 429 count towards max_attempts?"]
}

要看最后一行：HTTP 429 是否计入 max_attempts，属于需要澄清的策略。结构化输出把它和已经发现的缺陷分开，避免模型自行补成需求。

桥接层提供八个工具：agy_start、agy_say 启动和继续对话；agy_wait、agy_status 处理长任务；agy_sessions、agy_resume 查找和恢复审查；agy_end 关闭会话；agy_list_agents 查看已安装的 Agent 和模型。超出调用等待时间时返回 RUNNING，后台继续执行。

项目附带 code-reviewer、design-reviewer、thinking-partner，分别处理代码、设计和开放讨论。Agent 使用带 YAML front matter 的 Markdown；全局目录是 ~/.gemini/config/agents/，项目 .agents/agents/ 优先。技能沿用 SKILL.md 格式。

工程上更关键的是每轮的前后保护：先记录文件大小、时间戳，以及 Git 的 HEAD、stashes、worktrees，并备份未提交工作；结束后再次快照并比较，单独列出测试缓存和构建产物。

审查者可以读项目、跑测试、linter 和构建，文件写入工具只允许操作临时目录。但 shell 无法受同样的目录限制，因此备份和比较是补救机制，不能当作完整隔离。桥接层也不会使用 --dangerously-skip-permissions。

作者还明确承认：AGY 会读取项目 .agents/ 中的技能，不可信仓库可能通过植入指令影响审查。

运行条件是已安装并登录 AGY CLI、Claude Code、Python 3.11 或以上，以及 uv，支持 macOS 和 Linux。安装命令如下：

git clone https://github.com/kulaone/agy-bridge.git
cd agy-bridge
uv sync
uv run agy-bridge install

最后一行会安装 Agent、技能并注册 MCP server；作者称它不会覆盖用户修改过的文件。重启 Claude Code 后，用 uv run agy-bridge doctor 检查连接。

我的判断

我赞同把「发现问题」「评估建议」「验证修改」分开。编写者容易维护自己的方案，审查者也可能提出错误修法，双方都需要举证。相比让模型反复自查，这套流程至少明确增加了独立上下文和实验步骤。

但原文提供的是作者的案例和经验，没有缺陷检出率、误报率、耗时或费用对照。它说明这套流程曾经有效，不能证明 Gemini 4 Argon 是最佳审查模型，也不能证明每次都值得跨工具运行。

「第二轮通常足够」同样是经验之谈。真正的退出条件应该看问题是否解决、关键假设是否确认，以及剩余风险是否需要人判断。

此外，备份能降低工作丢失的风险，快照能帮助发现变化，两者都不能撤销审查期间已经发生的全部外部影响。团队采用时，应把运行环境和权限边界算进成本。原文也提醒，每轮要花几分钟，一晚就丢的餐厅选择页面没有必要照搬全套流程。

能拿来做什么

• 给前端或 Node 项目准备固定的审查交接模板，写清需求来源、修改范围、测试命令和已知问题，并要求关键假设附具体出处。
• 处理重试、状态恢复、并发执行等改动时，让独立审查 Agent 自己运行测试；收到修改建议后，先复现问题，再验证修法。
• 把「修复后必须复查、设计争议讨论一次、真实缺陷持续跟踪」写进团队 skill，并将无法确认的业务规则交给人。
• 接入能执行 shell 的审查者前，先确认未提交代码的备份、改动检测和项目技能来源；按改动风险决定是否启用完整流程。