让编程Agent交付可核验的完成证据

dev.to · AI#AI编程#Agent#测试验证

Editor brief · 编辑速览

文章建议先把任务写成可观察的验收条件，再要求Agent报告改动、实际执行的命令、检查结果及未验证范围。通过折扣计算回归测试示例，说明如何判断测试是否覆盖原始问题。

文章思维导图

Knowledge map

拖拽缩放

AI deep read

AI 深度解读

AI Agent 说「修好了，测试全过」，离可以合并还有多远？这篇文章给出的答案是：先把完成声明拆成可检查的证据，再判断这些证据是否覆盖了需求。测试变绿、构建成功、页面截图，各自能证明的事情不同。

作者提出了一套轻量验收流程：提前约定行为，检查回归测试，审阅测试自身的改动，并明确记录没验证的部分。它没有提供效率对照数据，但适合解决日常 AI 编程中的一个问题：代码看起来交付了，验证却没有交代清楚。

「修复结算 bug」留给 Agent 的解释空间太大。作者建议把任务写成可观察的结果：折扣超过订单小计时，总价应为零；补上回归测试；正常折扣行为保持不变。

这段要求同时限定了修复目标和不能破坏的行为。Agent 即使让某个测试通过，也还需要回答：是不是满足了这个结果，有没有影响原本正确的情况？

UI 任务同样需要描述交互，API 任务则要说明响应和副作用。副作用就是请求之外真正发生的变化，例如数据是否写入。仅仅返回成功，并不能证明保存已经完成。

完成报告也要围绕这些要求写。作者给出的有效示例包含三层信息：已添加超额折扣的回归测试，结算测试套件通过，但由于缺少支付凭据，没有验证浏览器结算流程。读者由此能区分哪些结果有依据，哪些仍需补查。

完成报告应该交代证据及其边界。

如果工具能展示执行日志，还应核对日志。报告里提到一条命令，只能证明 Agent 声称运行过它；实际执行和通过结果，需要进一步确认。

作者最有价值的提醒是：通过的测试，也可能没有验证需求。

例如，expect(result).toBeDefined(); 只检查结果是否存在。即使总价依然是负数，它也可能通过。

下面这段断言才直接检查超额折扣的处理：

expect(calculateTotal(50, 80)).toBe(0);

要看的是 toBe(0)：订单小计为 50、折扣为 80 时，要求明确落在了总价归零上。可行时，还应确认这个回归测试在原实现上失败、在修复后通过，否则它是否捕获了原始缺陷仍存疑。

只检查异常分支还不够，正常折扣也需要保留：

expect(calculateTotal(50, 20)).toBe(30);

这里要注意预期值 30。它约束的是正常计算，避免修复超额折扣时顺手破坏有效折扣。

接下来要读测试文件的 diff。Agent 是否跳过失败用例、删除重要断言、用过于方便的 mock 替换真实行为，或者直接改了预期值，让测试迎合实现？检查配置是否被关闭，也属于这一轮审阅。

这些修改可能有合理原因，例如旧测试确实过时了。但理由必须能和需求对上。相关检查被削弱后，「全部通过」的证明力也会下降。

构建成功，只能证明构建完成；截图可以展示外观，却不能证明按钮真的保存了内容。作者强调，验证方式应由改动承诺的行为决定。

对前端开发，这个区分很实用：如果任务涉及一次交互，证据就应该覆盖那次交互产生的结果。对 API 改动，响应是否正确，以及预期副作用有没有发生，也需要分别检查。

同时，还要防止修复把问题挪到别处。作者建议先看 diff 摘要，再沿受影响路径检查：

改动大并不自动代表有问题，但解释应该与范围相称。

验证受阻也要单独记录。数据库不可用、依赖安装失败、缺少浏览器访问能力，都只能说明检查没完成。报告应明确写出阻塞原因，并在合适的环境补做，不能把「无法测试」写成「应该没问题」。

我赞同作者把验收重点放在「需求和证据能否对应」上。相比只要求 Agent 在最后列出测试结果，这套做法更进一步：既检查有没有运行，也检查测试是否有用，以及验证条件有没有被改松。

它的局限也很明确。原文是一套工作建议，没有展示团队实测、误报率或时间成本对照，不能据此断言它能减少多少缺陷。结算代码也是说明性示例，不是完整项目中的修复记录。

在旧实现上运行新增回归测试尤其有帮助，但存在前提：旧实现和测试环境仍能复现，新增测试也能在旧代码上运行。作者用了「可行时」这个限定。条件不满足，就应把缺口写清楚。

这套流程也依赖需求本身足够明确。如果团队对正确行为没有共识，再完整的执行日志也解决不了验收争议。先确认预期，再评估证据，顺序不能倒过来。