让 Agent 多写测试为什么仍会漏错，问题出在谁定义正确

作者：林岚｜OC 开发者生态编辑

据 Dan Luu 最新公开实验，给编程 Agent 补一句“使用 TDD”“使用属性测试”或指定形式化工具，并没有稳定带来更好的实现正确性。他以 Rust 实现 Zstd 为主要任务，比较多组提示条件，并用隐藏测试验收；结论针对这套模型、任务与运行设置，不是给所有测试方法排终身座次。

一句话结论：让 Agent 做更多测试，不等于让它检验更多真实风险；最容易遗漏的仍是测试本身是否知道什么叫正确。

代码和测试可以一起犯同一个错

我们很容易被一份“测试全部通过”的报告安慰。可如果实现和测试都由同一个过程生成，测试可能只是忠实地复述了实现。代码把字段顺序写反，测试却也按照反过来的顺序准备预期结果，两边自然相安无事。

Dan Luu 的观察中，有 Agent 用形式化工具证明无关紧要的性质，也有测试因为输入过于相似，根本没触及容易出错的区别。一个典型例子是四条数据流：如果它们长得完全一样，交换次序也看不出差异。更多同类样本只能强化“没看见问题”，不能证明问题不存在。来源：实验原文

这不是说 AI 测试一无是处。恰恰相反，容易生成大量样本，本来应该是自动化的优势。问题在于样本分布有没有穿过危险区域。对一个严格格式的解析器乱塞字节，可能大部分时间都在检验“如何拒绝垃圾”，却很少进入真正复杂的解码路径。

工具名不能替代测试目标

“用属性测试”只说明采用某种方法，还没有说明属性是什么。假设我们检查一个排序函数，“输出长度没变”是一条属性，但一个原样返回输入的错误实现也能满足它。加入“输出有序”仍不够：永远返回等长零数组也可能蒙混过关，还需要验证元素集合得到保留。

同样，往返测试并非天然独立。编码器与解码器如果共享同一种错误，它们仍可能完成漂亮的自我往返。要知道输出能否被其他实现理解，就需要有独立来源的样本、参考实现或外部规范，而不是只让自己给自己发合格证。

这些例子是 OC 对测试设计的解释，不是此次实验报告的额外结果。它们指向同一件事：质量来自能区分正确与错误的判据，而非文件数量、断言数量或者测试工具的声望。

更有用的指令，应该描述失败会长什么样

给 Agent 的要求可以具体一些。例如，处理金额时，明确小数边界、舍入规则、负数与撤销流程；处理权限时，要求同一资源在不同角色下有不同结果；处理导入时，把空文件、重复行、截断输入和部分成功分别列成业务情境。

这并不是让人先把所有测试写完，才能让 Agent 工作。人的作用可以是给出独立约束和几类高风险反例，让 Agent 扩展样本、运行检查、归纳失败。随后再审查它的“预期结果”来自哪里：规范、人工算例、参考程序，还是刚刚跑出来的实现输出。

还可以有意识地试验测试会不会失败。在隔离的试验副本中，故意反转一个比较条件、跳过一项权限检查或交换两个字段，如果现有测试依然全绿，就说明验收网没有罩住那一类错误。这种验证针对的是测试的辨别力，而不是生产代码是否暂时运行顺畅。

不过，不能把这又缩成一句万能口令。任何方法都可能被执行成仪式。测试失败后，应先问是实现错误、测试错误还是需求不清楚，而不是默认让 Agent 改到绿为止。否则，它可能只是把验收标准往当前代码身上挪。

别从一次实验推导出“停止使用 TDD”

原文比较的是 Agent 在得到方法名等指引后的行为，不能直接等同于熟练工程师严格执行这些方法的效果。隐藏测试本身也只覆盖选定任务，模型版本、推理预算、参考材料和时间限制都会影响结果。

因此，最值得带走的不是某个排名，而是评估习惯：检查实际轨迹，看看工具究竟被怎么用了。一个团队若要决定保留哪种提示模板，应把它放进自己的任务集比较正确率、总耗时和人工修复量，而不是根据一篇博客把整个工程流程推倒重来。

关键事实

• 来源：Dan Luu 的公开实验与行为分析。
• 主要任务：Rust 实现 Zstd，并有其他协议任务的补充尝试。
• 验收重点：隐藏测试中的实现正确性，而非 Agent 自建测试的通过率。
• 适用边界：方法名称的提示效果，不等于该方法由专家实施时的能力上限。

OC 判断

AI 编程正在把“谁来写代码”的问题，推向“谁来定义验收”的问题。测试可以大量自动生成，但至少一部分正确性依据必须独立于实现。否则，自动化只会更高效地完成自我确认。

为什么重要

• 对开发者：审查预期值和样本分布，常比继续增加相似测试更有价值。
• 对企业：把隐藏验收和失败案例沉淀为资产，别只统计代码与测试产量。
• 对用户：软件可靠性取决于错误能否被发现，不取决于发布说明里写了多少条测试。

参考来源

• Dan Luu：How well do agents use test/verification techniques?