代理不应给自己批改作业

你让 Claude 审查你的代码。它说代码看起来很整洁。它当然会这么说，因为代码是它五分钟前写的。这就像让作者给自己论文评分，他当然会给自己打个 A。

AI 代码审查是有效的。但当你让作者审查自己的工作时，它们就会失效。质量源于一种“角色互不审计”的架构设计。

2024 年的研究显示存在“自我偏好偏差”（self-preference bias）。模型会对自己的输出给出比同等质量的其他输出更高的评分。模型能识别出自己的风格并对其产生偏好。

“先编写，再审查刚才写的内容”这种循环是失效的。你得到的不是审查，而是辩解。代理已经认定代码是好的，再次询问只会进一步确认这一决定。

遵循以下规则来构建更好的代理工作流：

• 审查者绝不能是作者。使用不同的模型系列作为审查者，以打破风格识别。
• 使用干净的上下文。审查者不应看到原始的实现提示词（prompt）或作者设定的约束条件。
• 去除身份信息。不要告诉审查者代码是谁写的。作者的身份会触发偏差。
• 避免过度标记。AI 审查者经常为了显得有用而凭空捏造问题。这会导致你不再信任它们。

使用“凭证规则”（receipt rule）来减少误报。在向你展示每一个发现之前，必须包含证明。

如果审查者声称存在 SQL 注入风险，他们必须提供：

• 对用户输入的 grep 检索。
• 查询流的追踪（trace）。

如果该值是常量，则忽略该发现。如果它来自 HTTP 请求，则保留。证明应先于判断。

对于关键发现，使用“怀疑者小组”。他们的工作不是确认 Bug，而是反驳它。他们必须尝试证明为什么该发现不是 Bug。只有当大多数人无法推翻该发现时，它才能通过。

真相源于矛盾，而非自我声明。

构建一个角色永不重叠的系统：

• 编写者编写代码。
• 测试者仅根据规范（spec）编写测试。
• 审查者没有编写代码。
• 在任何人类或 LLM 查看之前，必须通过 linting 和测试等客观关卡。

一个会自我修正的修正器什么也修正不了。AI 审查的质量取决于你阻止它自我评分的次数。

Source: https://dev.to/ohugonnot/no-agent-grades-its-own-homework-8lb

Optional learning community: https://t.me/GyaanSetuAi