AI 代理真的会写测试吗？
How well do agents use test/verification techniques?
我测试了 26 种不同的测试指令和库，包括 TDD、Lean 4、QuickCheck 等，让 AI 代理用 Rust 实现 Zstd。结果令人失望：无论是指令还是技能，代理大多无法有效运用这些技术。它们要么只是把普通测试塞进新框架，要么只做了表面功夫，比如用随机输入测试无关属性。即使有 25 万星的 ECC 技能包，效果也不如默认指令。AI 代理在测试上表现糟糕，似乎根本不懂如何合理测试，这可能是因为缺乏针对有效测试技术的 RL 训练环境。
如果你让代理使用某种特定的测试技术或测试库，这种糟糕的方法并没有像人们希望的那样发生太大改变。
HN 评论区
38- andai
我做独立游戏开发，所以不确定我的经验能在多大程度上迁移过来，但我一直在开发一款浏览器游戏，这游戏其实挺烂的，但测试数量却巨多（按我的标准）。所以，你完全可以用一堆测试写出垃圾软件。（当然，你也可以用极少的测试写出超棒的软件！）
另外，我有过一次搞笑的经历：AI 把一个架构改动完全搞反了。这个实现毫无意义，不仅没让情况变好，反而更糟。但我依然收到了“所有测试全绿”的结果 lol，因为它只是证明了那个错误的东西确实能正常工作。
我有点好笑地注意到，形式化验证在那种情况下也帮不上忙，它只会更强有力地证明那个本来就不该存在的东西是“正确”的。
- ivanzhaowy123
据我的经验，代理在编写单元测试时，往往能想到比人类更多的边缘情况。但在某些技能集的引导下，它们可能会变得机械，从而忽略业务逻辑。
例如，当我使用 Superpowers 技能集时，代理会主动为每个新功能采用 TDD（测试驱动开发）。但它对测试的理解往往停留在表面：如果用户要求做一个带“发送”按钮的界面，它会先写一个测试来检查按钮是否存在。测试失败后，它就加上按钮让测试通过。
结果，测试套件里堆满了低价值的用例，只检查某个属性是否存在或字符串是否完全匹配。代理遵循“先写失败的测试，再实现功能”的流程，却从未真正测试业务行为：什么时候允许发送？成功或失败后会发生什么？重复提交该如何处理？
问题不在于代理写不出测试。而在于它们似乎倾向于将 TDD 简化为僵化的步骤序列，难以从业务需求中独立推导出有意义的测试用例，并以此驱动开发。
- siscia
现在还为时过早，但我发现这个实验没什么意义，几乎没什么用处。
测试代码的方式不能（也不应该）与代码本身的架构方式脱钩。
80% 以上的有效测试不在于测试框架，而在于代码架构。
作者没有提到代码是如何架构和管理的。
就我而言，我发现强制代理使用 DI/六边形架构，并强制进行简单的覆盖率检查，相当有用，能以相对较少的精力产出整体足够好的代码。
- movpasd
这比我做过的任何测试都要彻底得多，而且是在完全不同的领域，但我让代理使用 Hypothesis 的轶事经验相当糟糕。
代理真的、非常难以弥合代码与其本应建模的实际业务规则之间的差距。它也难以判断在哪些层级、哪些函数适合编写测试。因此，它的测试往往对领域逻辑的变更非常脆弱。
本质上，代理似乎一直难以处理模块化和问题分解。好的测试在于找到正确的测试对象，这意味着要将输入状态细分成适当的产品状态，并独立检查每种行为。在我看来，这是编程中最困难、最复杂的事情，所以我不说它比人类更“挣扎”——但人类的优势在于可以“睡一觉再想”？
我观察到的一个小细节是，它往往会在浮点边缘情况（NaN、无穷大）上卡住。也许浮点边缘情况在属性测试的训练数据中占比过高，但这对我的使用场景来说基本无关紧要，至少就业务规则而言。
- anitil
你知道大家总觉得代理在它们擅长的事情上表现糟糕，而在它们不擅长的事情上却表现很好吗？事实证明，我可能在测试方面很不行，因为我觉得它们做得还挺不错的。