复盘 AI 审查日志，找出漏网缺陷

AI 写代码，再让另一个 AI 审查，真正值得留下的可能是那些「没通过」的对话。作者保存了一个 sprint 内的完整审查记录，发现拒绝理由、作者的回应和修改过程，比合并后的 PR 更能说明审查有没有用。

他们还把审查结论整理成后续任务可复用的规则。不过，这只是一个团队、一个 sprint 的观察，没有对照实验。值得借鉴的是反馈如何留存和复用，不能据此认定双 Agent 审查一定更可靠。

被拒绝时，问题才开始显形

作者的流程是一个 Agent 写改动，另一个 Agent 审查，反复进行，直到通过或由人接手。

通过的记录通常很短：执行检查、没发现问题、放行。拒绝的记录则暴露了更多信息。作者 Agent 必须重新解释改动到底做了什么，有时解释到一半，就发现了另一个问题。日志里有几处 bug，是在回复拒绝意见时修好的，审查 Agent 当时还没进行下一轮检查。

审查的价值，不只在于指出问题，也在于迫使实现者重新检查自己的解释。

最具体的例子是一个下载函数：服务器返回错误页面，代码却无条件把响应正文写进文件，最后用户下载到的是 HTML。

审查 Agent 在第一轮就拦住了它，而且指出了无条件写入响应正文的具体位置。这类意见比「请完善异常处理」有用，因为它把触发条件、错误行为和代码位置连在了一起。

但原文没有给出代码、检查项或漏报记录。这个案例能证明它抓到过一个实际问题，不能证明它覆盖了所有下载失败场景。

留下聊天记录之后，还要让教训进入下次任务

这套流程运行在开源协作工作区 Octo 上，使用的是 Critic mode。作者将其描述为作者 Agent 与审查 Agent 彼此隔离，工作通过 do、review、reject 或 pass 流转，除此之外不交换其他信息。具体隔离机制，原文没有展开。

审查对话附着在名为 loops 的工作单元上。一个 loop 承载任务从启动到验收的全过程，每轮意见都留在其中。即使改动三周后才落地，作者仍能回看早期决策为什么这样做。

这解决的是追溯问题。更进一步，他们把拒绝意见和最终验收结果转成 preference cards，也就是供后续任务参考的规则卡。

每张卡只承载一条可验证规则，同时记录证据、适用范围和置信度。下载 bug 就变成了一条关于文件写入路径处理 non-200 响应的规则。下次遇到同类任务，这张卡会提前进入上下文。

这里有个实用区别：日志记录「当时发生了什么」，规则卡负责「下次提前检查什么」。只有归档，没有后续使用入口，教训仍然容易被遗忘。

两三轮通过，可以拿来当团队指标吗

作者观察到，大多数 PR 在两到三轮内结束。只走一轮的改动通常比较简单；超过四轮时，问题往往已经出在任务本身，例如需求模糊，或者起点就带着错误假设。这时他们会转交给人。

轮数因此不只反映代码质量，也可能暴露需求质量。

不过，作者明确说了：这些数字来自一个 sprint 的团队经验，不是基准。原文没有交代 PR 总数、改动规模、模型配置，也没有比较人工审查或单 Agent 流程。

所以，两到三轮适合当观察线索，不能直接变成所有团队的验收目标。原文也没有说明恰好四轮时如何处理，不必替作者补出一条硬规则。

我的判断

我认同它把注意力放在拒绝记录上。只看最终 PR，容易忽略哪些问题被拦过、哪些判断曾经反复摇摆。完整过程更适合用来检查审查机制是否有效。

但「抓到过 bug」和「整体更可靠」之间，还缺少漏报率、误报率、时间成本等证据。作者的结论应当按经验之谈来读。

与把所有经验塞进一份越来越长的规则文档相比，带证据和适用范围的规则卡更方便逐条核查。不过，卡片如何筛选、何时更新、错误规则如何撤销，原文都没说清。

下载案例也提醒我们：从个案提炼规则时要保留适用条件。原文用 non-200 描述这张卡，但团队实际采用时，仍要结合接口约定判断成功响应，避免把一次修复机械推广到所有文件写入逻辑。

能拿来做什么

• 在现有 AI 编程流程里，先保存一个 sprint 的完整审查记录，并关联到任务或 PR，优先回看拒绝轮次，检查意见是否指出了具体行为和位置。
• 审查前端或 Node 下载逻辑时，沿着「收到响应到写入文件」的路径检查失败处理，确认错误页面不会被当作正常文件保存。
• 从确认有效的修复中提炼少量规则，每条写清证据、适用范围和置信度，在相似任务开始时提供给 Agent。
• 当审查反复超过四轮时，安排人检查需求和初始假设；把这个数字当排查信号，再根据自己团队的记录调整。