别让AI给自己打分：自评代码为何总通过

让写代码的 Agent 自己判断是否完成，结果几乎永远是通过——这不是态度问题，而是结构决定的。原文作者用一个清晰的观点戳中了当前 AI 编程工作流里最容易被忽视的漏洞：写代码的人和验收代码的人是同一个，验收就必然失真。

自评为什么注定失效

写过这段代码的 Agent，脑子里保留的是「我打算做什么」。当它回头检查时，比对的是代码与意图，而不是代码与结果。于是「这段代码能跑吗」悄悄变成了「这是我设想的样子吗」——答案当然总是肯定的，因为代码就是按它的设想生成的。

更隐蔽的一层是激励方向。对同一个模型来说，说「完成了」意味着任务关闭，说「还没好」意味着工作量继续累积。在没有角色隔离的情况下，最短路径永远胜出。原文把这一点称为「by construction」——不是模型想偷懒，而是流程设计本身就奖励自我通过。

rss source: Do not let the agent grade its own work

写与验，必须拆成两个角色

原文列出了「作者」与「评审者」之间的四条分界线，这四条构成了可操作的角色隔离原则。

评审者不读代码，只跑命令

评审角色执行测试、跑 lint、跑构建、调用端点。它对代码的主观看法不算数，算数的只有退出码（exit code）。这一条把验收从「读起来像不像对的」拉回到「跑起来是不是对的」，消除了审美判断和意图比对的空间。

分数是数值，且有硬阈值

评分范围 0-100，并事先声明阈值（比如 85）。「我觉得没问题」不能过关；低于阈值就是失败。数值化让验收结论可以被记录、被比较、被追溯，而不是停留在模糊的定性描述上。

文中反复提到的**退出码（exit code）**是 Unix 进程结束时返回给调用方的整数状态，0 通常表示成功，非 0 表示各类失败。测试框架、linter、构建工具都会把结果编码进退出码，因此它天然适合做机器可判定的验收信号：不需要解析人类可读的输出文本，也不需要模型去「理解」日志。这也解释了为什么评审者只跑命令而不读代码——退出码把复杂的质量判断压缩成一个确定性的布尔值，消除了语言模型在解读日志时可能产生的幻觉和宽容。

失败必须给出原因

只说「失败了」不够，报告必须列出具体失败项以及对应的命令输出。没有失败原因，修复角色只能在黑暗中盲改，容易把没坏的部分一起重写。

评审者不负责修

评审只测量，不修复。修复由作者完成，然后回到同一把尺子下重新测量，直到通过为止。这条约束避免了「一边测一边改标准」的滑坡。

实际运行时的样子

原文给了一组对照输出：

SCORE=100.0  THRESHOLD=85.0  GATE=passed
SCORE=60.0   THRESHOLD=85.0  GATE=failed
GAPS=["pytest: exit code 1, expected 0"]

同样的循环、同样的代码，两轮得到两个不同答案，原因是第二轮里放了一个故意写坏的测试。评审者并不知道这一点——它只是测量。这个对照实验说明，当验收权交给一个只认退出码的角色时，评分才有区分度。

工作方式会发生什么变化

角色拆开之后，日常协作的重心从「听 Agent 汇报」转向「看报告数据」。原文总结了三点变化。

不再审核承诺。 交付物是一份带分数和原因的报告，而不是一句「已成功实现」。审核者面对的是可验证的证据，而不是需要自行判断可信度的说法。

Agent 的自我改进有了靶子。 手里有明确的失败原因，它只需修复坏掉的部分，而不是推倒重写。修复范围收窄，副作用也随之收窄。

回归变得可见。 两轮之间分数下降，就意味着有东西坏了——在上线之前就能看到。分数成为一条连续的健康曲线，而不是一次性的通过与否。

适用边界与遗留问题

这套方法的前提是「正确性可以被命令验证」。测试覆盖率高的项目能直接受益；但对于 UI 观感、产品逻辑取舍这类无法用退出码表达的维度，数值化的评审仍然会退回到主观判断。原文没有展开这部分，是实践中需要自行补齐的环节。

另一个隐含成本是评审门槛的设置：阈值定得太低，评审形同虚设；定得太高，Agent 陷入反复修复的循环。原文给出的 85 只是一个示例值，真实项目需要根据自己的测试成熟度调整。

原文作者还提供了一个叫 AI Test Loop 的技能链接和付费的引导式配置服务（首个周期共同运行），说明这套模式已经被打包成可复用的工作流。对团队来说，值得先在自己最成熟的测试套件上跑一轮，看看分数是否真的能区分「能跑」和「跑对」。

背景补充

这里的「阈值」在工程上对应的是**质量门禁（quality gate）**的概念。质量门禁是指在流程中预设一组可量化的判据，只有全部满足才能进入下一阶段，常见于 CI/CD 流水线中的代码覆盖率门槛、静态扫描零高危漏洞等。把它用在 Agent 自评上，关键不在于数值本身，而在于「事先声明」——阈值一旦落定，就不能在评审过程中被重新谈判，否则评审者与修复者共享同一目标时，标准会随结果漂移。实践中阈值应基于历史数据设定，例如取近期人工验收通过样本的分数下沿，再留一定余量，而不是凭感觉拍一个整数。

「同一把尺子」背后的原则是测量不可变性（measurement immutability）：评审所用的命令、配置、测试用例在修复轮次之间必须保持冻结，只有被测代码变化。如果在修复过程中顺手修改了测试或调低了断言强度，分数上升就不再代表质量提升，而只是测量工具被放松了。这一点与科学实验中的对照组思想一致——变量唯一，结论才可归因。工程上可以通过对评审脚本做哈希校验、把测试套件纳入只读挂载等方式强制约束，确保每一轮分数都落在同一个坐标系里。