[控场AI]
· 4 分钟阅读· 2,188 字

别让AI给自己批作业:编码代理审查的四个关键原则

别让AI给自己批作业:编码代理审查的四个关键原则

代理不该给自己的代码打分,审查需外部证据与多道独立门槛。

文章指出,让编写代码的 AI 代理自我审查在结构上注定失效,因为写代码和审查代码共享同一套假设与盲点,重新运行"仔细检查"只会得到更多自信而非更多覆盖。作者提出四个实践中有效的做法:先跑 Linter、测试、密钥扫描等确定性检查以节省模型注意力;用不同厂商或架构的模型做审查者,把模型间的分歧当作有价值的信号;将候选、已验证、人工审查、已发布拆分为四个不可跳过的显式状态;审查对象必须是可 grep、可 diff 的源码文件,而非会引导审查者接受代理推理框架的聊天记录。作者据此构建了多模型讨论与交叉审查的桌面工具 Brainstorm。

最近在X上浏览时,我发现一个想法反复出现在不同的代码仓库里:在代理生成的代码被推送之前,增加一个审查步骤,并且不要让编写代码的那个代理来决定它是否完成。

我同意这个观点,这也成了我构建工具时遵循的规则。

rss source: Your coding agent shouldn't grade its own homework

为什么自我审查不起作用

当一个模型编写代码然后自己检查时,它往往会重复自己的盲点。产生 bug 的假设,正是它用来审查代码的假设。用同样的模型重新运行"请仔细检查",主要得到的是更多自信,而不是更多覆盖。

这背后有一个结构性原因:模型的推理路径是连续的。它在写代码时建立的上下文——对需求的理解、对边界条件的假设、对依赖行为的预期——会完整地保留在审查阶段。它不会突然获得一个"外部视角",因为同一套权重不可能同时是问题制造者和问题发现者。

实践中有效的四个做法

先跑确定性检查

Linter、测试、密钥扫描器。它们能廉价地捕获那些无聊的问题,这样任何模型审查都可以把注意力花在意图和边缘情况上。

这个顺序很重要。如果先让模型审查,它可能会在风格问题上浪费大量 token,而 Linter 用毫秒级的时间就能解决。把确定性工具放在前面,等于给模型审查做了一次"预处理",让它的上下文窗口专注于真正需要判断力的部分。

确定性检查指的是输出完全可预测、不依赖概率推理的工具:Linter 依据固定规则检查代码风格和常见错误,单元测试对给定输入产生固定的通过或失败结果,密钥扫描器用正则或熵分析匹配敏感字符串。与之相对,模型审查是概率性的——同一份代码在不同运行中可能得到不同结论。把确定性检查前置的价值在于:它提供的是二元、可复现的信号,不消耗模型上下文,也不会被模型的推理偏差污染,从而为后续的模型审查留下一个更干净的起点。

用不同的模型做审查者

不同的训练,不同的盲点。分歧才是有用的信号。

这一点在多源讨论中被反复提及。据 X 上的多位开发者分享,他们在 CI 流程中接入第二个模型做代码审查时,最有价值的输出不是"通过",而是两个模型给出不一致结论的那些案例。这些分歧点往往指向真实的设计模糊地带或隐藏的边界条件。

这里的"不同"不只是指模型名称不同,而是指训练数据、微调目标和推理风格存在实质差异。同一家族的不同尺寸模型往往共享大量训练语料和对齐策略,盲点高度重叠,审查效果有限。真正有价值的是来自不同厂商、不同架构的模型,它们对同一段代码的"第一反应"可能截然不同,而这种不一致恰好暴露了需求描述中的模糊之处。实践中可以把第二个模型的输出当作信号而非裁决:一致通过时仍需人工抽检,出现分歧时则优先人工介入。

保持状态分离

"候选"、"已验证"、"人工审查过"和"已发布"是四件不同的事情。把它们混为一谈,就是未审查代码进入主分支的方式。

很多团队的问题不在于没有审查,而在于状态机被压缩了。代理说"完成了",代码就被标记为可合并——中间缺少了确定性检查通过、第二模型审查通过、人类确认这三个独立门槛。每个门槛都应该是一个显式的、不可跳过的状态转换。

状态机是软件工程中描述系统在有限个状态之间按规则转换的模型。在代码审查流程里,把"候选""已验证""人工审查过""已发布"建模为显式状态,意味着每次转换都必须有对应的证据触发:测试通过才能从候选进入已验证,第二模型审查通过才能进入人工审查,人类确认后才能发布。状态分离的本质是把"完成"从一个主观判断变成一条可审计的转换记录,任何跳过中间状态的捷径都会在流程上留下可见的缺口。

把源码作为文件取出来

阅读聊天记录不是审查。下载代码,在你的编辑器中打开它,看看交接点。

聊天记录是一种叙事,它会自然地引导你接受代理的推理框架。而文件是客观的——你可以 grep、可以 diff、可以跳转到定义。审查的对象必须是文件,而不是对话。

我如何把这个理念构建进工具

我做了一个叫 Brainstorm 的桌面工作区,几个 AI 模型在其中讨论一个目标、拆分工作,然后由一个不同的模型在事情算作完成之前进行审查。你导出源码,自己做最终决定。

它是 BYOK 模式:你连接自己的模型账户或 API 密钥,我们不卖 token。Linux 是第一个平台。

如果你有兴趣看看:https://brainstorm.mungwaan.cn

你今天如何把关代理编写的代码:只靠测试、第二个模型,还是每次都人工审查?

为什么这个问题会越来越重要

随着编码代理承担越来越多的实际工作,"谁来判断完成"这个问题会从工程细节上升为流程设计的核心。自我审查的失败不是模型能力问题,而是结构问题——任何单一判断者都会系统性遗漏自己制造的问题。多模型审查、确定性检查前置、状态分离和源码文件化,这四个做法共同构成了一道不依赖单一模型自觉性的防线。

据多位开发者在 X 上的讨论,最危险的往往不是代理写错代码,而是代理自信地宣布代码正确。审查流程的设计目标,应该是让"正确"成为一个需要外部证据支撑的断言,而不是代理的一句话。

#编码代理#AI代码审查#代理自我审查#多模型审查#代码质量门禁#AI编程工作流#Brainstorm
分享:

相关推荐