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

代理不该给自己的代码打分,审查需外部证据与多道独立门槛。
文章指出,让编写代码的 AI 代理自我审查在结构上注定失效,因为写代码和审查代码共享同一套假设与盲点,重新运行"仔细检查"只会得到更多自信而非更多覆盖。作者提出四个实践中有效的做法:先跑 Linter、测试、密钥扫描等确定性检查以节省模型注意力;用不同厂商或架构的模型做审查者,把模型间的分歧当作有价值的信号;将候选、已验证、人工审查、已发布拆分为四个不可跳过的显式状态;审查对象必须是可 grep、可 diff 的源码文件,而非会引导审查者接受代理推理框架的聊天记录。作者据此构建了多模型讨论与交叉审查的桌面工具 Brainstorm。
最近在X上浏览时,我发现一个想法反复出现在不同的代码仓库里:在代理生成的代码被推送之前,增加一个审查步骤,并且不要让编写代码的那个代理来决定它是否完成。
我同意这个观点,这也成了我构建工具时遵循的规则。

为什么自我审查不起作用
当一个模型编写代码然后自己检查时,它往往会重复自己的盲点。产生 bug 的假设,正是它用来审查代码的假设。用同样的模型重新运行"请仔细检查",主要得到的是更多自信,而不是更多覆盖。
这背后有一个结构性原因:模型的推理路径是连续的。它在写代码时建立的上下文——对需求的理解、对边界条件的假设、对依赖行为的预期——会完整地保留在审查阶段。它不会突然获得一个"外部视角",因为同一套权重不可能同时是问题制造者和问题发现者。
实践中有效的四个做法
先跑确定性检查
Linter、测试、密钥扫描器。它们能廉价地捕获那些无聊的问题,这样任何模型审查都可以把注意力花在意图和边缘情况上。
这个顺序很重要。如果先让模型审查,它可能会在风格问题上浪费大量 token,而 Linter 用毫秒级的时间就能解决。把确定性工具放在前面,等于给模型审查做了一次"预处理",让它的上下文窗口专注于真正需要判断力的部分。
确定性检查指的是输出完全可预测、不依赖概率推理的工具:Linter 依据固定规则检查代码风格和常见错误,单元测试对给定输入产生固定的通过或失败结果,密钥扫描器用正则或熵分析匹配敏感字符串。与之相对,模型审查是概率性的——同一份代码在不同运行中可能得到不同结论。把确定性检查前置的价值在于:它提供的是二元、可复现的信号,不消耗模型上下文,也不会被模型的推理偏差污染,从而为后续的模型审查留下一个更干净的起点。
用不同的模型做审查者
不同的训练,不同的盲点。分歧才是有用的信号。
这一点在多源讨论中被反复提及。据 X 上的多位开发者分享,他们在 CI 流程中接入第二个模型做代码审查时,最有价值的输出不是"通过",而是两个模型给出不一致结论的那些案例。这些分歧点往往指向真实的设计模糊地带或隐藏的边界条件。
这里的"不同"不只是指模型名称不同,而是指训练数据、微调目标和推理风格存在实质差异。同一家族的不同尺寸模型往往共享大量训练语料和对齐策略,盲点高度重叠,审查效果有限。真正有价值的是来自不同厂商、不同架构的模型,它们对同一段代码的"第一反应"可能截然不同,而这种不一致恰好暴露了需求描述中的模糊之处。实践中可以把第二个模型的输出当作信号而非裁决:一致通过时仍需人工抽检,出现分歧时则优先人工介入。
保持状态分离
"候选"、"已验证"、"人工审查过"和"已发布"是四件不同的事情。把它们混为一谈,就是未审查代码进入主分支的方式。
很多团队的问题不在于没有审查,而在于状态机被压缩了。代理说"完成了",代码就被标记为可合并——中间缺少了确定性检查通过、第二模型审查通过、人类确认这三个独立门槛。每个门槛都应该是一个显式的、不可跳过的状态转换。
状态机是软件工程中描述系统在有限个状态之间按规则转换的模型。在代码审查流程里,把"候选""已验证""人工审查过""已发布"建模为显式状态,意味着每次转换都必须有对应的证据触发:测试通过才能从候选进入已验证,第二模型审查通过才能进入人工审查,人类确认后才能发布。状态分离的本质是把"完成"从一个主观判断变成一条可审计的转换记录,任何跳过中间状态的捷径都会在流程上留下可见的缺口。
把源码作为文件取出来
阅读聊天记录不是审查。下载代码,在你的编辑器中打开它,看看交接点。
聊天记录是一种叙事,它会自然地引导你接受代理的推理框架。而文件是客观的——你可以 grep、可以 diff、可以跳转到定义。审查的对象必须是文件,而不是对话。
我如何把这个理念构建进工具
我做了一个叫 Brainstorm 的桌面工作区,几个 AI 模型在其中讨论一个目标、拆分工作,然后由一个不同的模型在事情算作完成之前进行审查。你导出源码,自己做最终决定。
它是 BYOK 模式:你连接自己的模型账户或 API 密钥,我们不卖 token。Linux 是第一个平台。
如果你有兴趣看看:https://brainstorm.mungwaan.cn
你今天如何把关代理编写的代码:只靠测试、第二个模型,还是每次都人工审查?
为什么这个问题会越来越重要
随着编码代理承担越来越多的实际工作,"谁来判断完成"这个问题会从工程细节上升为流程设计的核心。自我审查的失败不是模型能力问题,而是结构问题——任何单一判断者都会系统性遗漏自己制造的问题。多模型审查、确定性检查前置、状态分离和源码文件化,这四个做法共同构成了一道不依赖单一模型自觉性的防线。
据多位开发者在 X 上的讨论,最危险的往往不是代理写错代码,而是代理自信地宣布代码正确。审查流程的设计目标,应该是让"正确"成为一个需要外部证据支撑的断言,而不是代理的一句话。
相关推荐

Workbuddy零基础入门:桌面AI智能体如何落地工作流
Workbuddy桌面AI智能体零基础教程解读:从安装、积分领取到文件管理与自动化工作流搭建,对比CodeX的适用场景与成本差异,帮助职场人完成从AI提问者到AI管理者的思维转变。

OpenAI智能体新栈:计算机操作、决策API与超速工作流
OpenAI Dev Day发布智能体新栈:Computer Use操作速度超越普通人,Decisions API基于Luna实现极低延迟分类,Agents API开放同源计算机操作能力,GPT-6.1 Sol成本仅为Astra七分之一。本文梳理核心更新、实测数据与开发者落地要点。

梁文峰开源推理框架DeepInfo,硬刚美国禁令
DeepSeek在开源模型后再开源推理框架DeepInfo,包含GPU/CPU交叉流水线、小模型预判大模型复核、华为昇腾与英伟达芯片全面适配等技术,直面美国联邦禁令。本文解析其对AI产业落地的意义与开源策略。