证据门槛

一个智能体报告”所有测试通过”，却从未运行过pytest。输出语气自信，措辞自然，但结论是假的。整个会话期间没有调用任何测试套件。该智能体根据自己对代码变更的理解推断测试会通过，然后将推断当作事实陈述。

我之所以发现了这个问题，是因为我有一条规则：每份完成报告都必须引用具体证据。不是”我相信测试会通过”，而是测试输出，粘贴出来，显示零失败。不是”文件应该已更新”，而是文件路径、行号、具体变更内容。不是”这遵循了现有模式”，而是模式的名称、它所在的文件，以及新代码与之匹配的行号。

这条规则在我的系统中有个名字：证据门槛。任何工作在完成报告中的每项声明都有可观测的依据之前，都不算完成。”我认为”不是证据。”应该没问题”不是证据。”我很有信心”不是证据。证据是文件路径、测试结果、具体代码引用或直接观测。

为什么现在尤为重要

语言模型生成的是看似合理的文本。这既是它们的核心能力，也是核心风险。关于测试结果的一个合理声明，与经过验证的测试结果声明，在外观上别无二致——除非你要求提供验证产物。

失败模式并非戏剧性的幻觉。智能体不会凭空捏造测试框架或编造错误信息。失败模式是将推断当作观测呈现。智能体推理出测试应该通过，然后把这个推理过程当作测试运行结果来汇报。推理甚至可能是正确的。但推理测试和运行测试是两回事，bug就潜伏在二者的间隙中。

我称之为幻影验证：完成报告声称进行了验证，实际上并未验证。在我对500多个自主会话的追踪中，幻影验证占需要人工介入的智能体故障的12%。¹这是最常见的不产生任何可见错误的失败模式。智能体报告成功，输出看起来正常，bug就这样上线了。

门槛标准

证据门槛包含六项标准。每项非平凡变更都必须在标记完成前，为全部六项提供证据。

这些标准刻意追求具体。每一项都要求特定的产物，而非笼统的保证。”遵循代码库模式”不能用”我遵循了现有惯例”来满足。满足它的方式是：”fetch_nvd()中的重试模式与fetch_semantic_scholar()第241行的指数退避一致。”

具体性就是关键所在。一个必须提供文件路径和行号的智能体无法进行幻影验证。文件要么存在于该路径且代码与声明一致，要么不一致。没有模棱两可的余地。

模糊语言作为信号

证据门槛包含一个模糊语言检测器。特定词汇会触发重新验证：

• “应该”（”这应该能工作”）
• “大概”（”大概处理了这个边界情况”）
• “似乎”（”输出似乎正确”）
• “我认为”（”我认为测试通过了”）
• “看起来正确”（”实现看起来正确”）
• “我很有信心”（”我很有信心这是对的”）

这些词汇表明智能体在推理结果，而非观测结果。推理可能正确。但如果智能体可以直接观测结果（运行测试、读取文件、检查输出），推理就是比观测更弱的证据形式。

当完成报告包含模糊语言时，回应不是”你错了”，而是”用观测替代模糊表述”。如果你认为测试通过了，运行测试并粘贴输出。如果看起来正确，读取文件并引用行号。模糊表述是验证被跳过的信号，而非验证失败的信号。

智能体为何使用模糊语言

智能体使用模糊语言有三个原因，理解这些原因对设计门槛至关重要。

上下文窗口压力。 运行测试套件消耗上下文。读取文件消耗上下文。管理长会话的智能体可能会跳过验证以保留上下文给下一个任务。证据门槛使这种权衡变得可见：智能体无法在没有产物的情况下声明完成，因此上下文压力表现为未完成的工作，而非幻影验证。

工具调用回避。 某些智能体配置会限制或惩罚工具调用。一个无需调用pytest就能报告”测试通过”的智能体节省了一次工具调用。证据门槛消除了这条捷径：测试输出是强制性的，因此工具调用也是强制性的。

基于人类模式的训练。 人类经常在完成报告中使用模糊语言。”我更新了配置，测试应该能通过。”基于人类文本训练的智能体会复现这种模式。证据门槛是一种训练后干预，通过拒绝接受没有产物的报告来打破这一模式。

自尊检查

证据门槛是我称之为”自尊检查”的更广泛质量体系的一部分。每次非平凡变更后，问自己五个问题：

1. 资深工程师会认可这个方案吗？
2. 代码是否不言自明？
3. 边界情况处理了吗？
4. 简洁程度是否恰当？
5. 代码库比我接手时更好了吗？

自尊检查是主观的，证据门槛是客观的。证据门槛问的是”你能证明这行得通吗？”自尊检查问的是”你愿意把这个展示给你敬重的人看吗？”两者缺一不可。有证据无自尊，产出的代码能跑但无人愿意维护。有自尊无证据，产出的代码好读但未必能跑。

二者结合形成质量循环：实现、逐行审查、通过证据门槛、执行自尊检查、修复发现的每个问题，循环往复直到两者都通过。这个循环不高效，也不快，但它是正确的。在智能体能以极高速度生成看似合理的代码的时代，正确性才是真正的差异化因素。

失败模式

证据门槛能捕获幻影验证，但无法捕获所有失败模式。在自主智能体会话中，有七种已命名的失败模式：¹

捷径螺旋。 跳过证据门槛步骤以更快地报告完成。智能体生成不完整的报告并声称已完成。

信心幻象。 以高度确信的语气声明”我很有信心”。证据门槛能捕获这种语言，但足够流畅的智能体可能会改写措辞以规避检测。

差不多高原。 代码能跑，但不够整洁，测试不充分。证据门槛的”最简可行方案”标准部分解决了这个问题，但自尊检查才是主要防线。

隧道视野。 打磨一个函数的同时破坏了相邻代码。”无回归”标准可以应对，但前提是智能体检查了正确的文件。

延迟债务。 提交代码中出现TODO/FIXME/HACK。证据门槛不检查这些，应使用单独的lint规则来防范。

空洞报告。 报告”完成”但不提供任何标准的证据。证据门槛的结构使这种报告明显不完整，但智能体可能生成看似完整实则遗漏某项标准的报告。

幻影验证。 证据门槛的首要目标。声称进行了测试或验证却没有产物。在门槛被一致执行时，12%的故障率降至接近零。

纪律

证据门槛不是技术创新，而是一种纪律。要求在接受声明之前提供证据的纪律。将”我认为”视为不充分的纪律。即使你知道测试会通过，仍然运行测试的纪律。

在智能体出现之前，这种纪律的重要性不如今天。人类开发者说”测试通过了”时，通常确实运行过测试。声明和观测混为一体，因为人类两者都做了。而智能体说”测试通过了”时，可能两者都没做。证据门槛将声明与观测分离，并要求二者兼备。

在输出看似合理的时代，证据是唯一可靠的信号。其他一切都只是推断。

常见问题

这不就是代码审查吗？

代码审查检验代码是否正确。证据门槛检验完成报告是否诚实。代码审查可能批准了从未测试过的正确代码。证据门槛则无论代码看起来多正确，都要求测试输出。

这会拖慢开发速度吗？

会。运行测试、读取文件、引用具体证据都需要时间。替代方案是发布经过幻影验证的代码，然后在生产环境中才发现bug。证据门槛用开发速度换取部署信心。

智能体能学会绕过证据门槛吗？

智能体可能伪造测试输出或引用错误的行号。证据门槛并非对抗性攻击的完全防护。它捕获的是常见失败模式（推断当作观测），而非对抗性失败模式（蓄意伪造）。蓄意伪造需要不同的防御手段。

如何在自主智能体中执行这一标准？

证据门槛标准是系统提示的一部分。质量循环（实现、审查、门槛、检查、修复、重复）编码在编排系统中。智能体在为全部六项标准提供证据之前无法报告完成。如果缺少某项标准，循环会返回到修复步骤。

参考来源