Agent 声称需求已完成且可以发布时，如何确认它做对了？

核心回答

确认 Agent 做对了，要把需求变成可以核验的验收条件，再检查实际改动、真实运行结果和最终产物。Agent 的完成说明是交付摘要，不能单独证明功能已实现；测试通过也要确认测试覆盖了这次需求。

例如要求“导出本月有权限查看的订单”，应核对导出入口、月份筛选、权限过滤和文件内容，而不只是确认下载按钮能点、生成了一个文件。自动化适合执行可重复检查，业务判断和开放性的体验问题再由相应负责人重点查看，检查力度随改动范围和影响调整。

测试、发布和验收的分工可以这样落地：AI 编写并运行针对性测试、整理变更和发布检查结果，人核对业务预期、测试断言与高影响改动；已有自动化流程负责执行发布步骤，发布权限与是否放行仍按团队流程处理。验收时，明确且可重复的条件交给自动检查，体验、业务取舍及未被覆盖的风险由相应负责人判断。

从需求到证据怎样对应

先列清楚用户可以观察到的结果：什么输入得到什么输出，哪些条件下应报错，已有行为需要保持什么。把关键条件对应到可执行检查、页面操作或产物检查；存在歧义时先补齐影响实现的条件，避免做完才发现双方理解不同。

随后审阅 diff，确认改动确实落在相应模块，是否遗漏调用方、状态更新或异常分支。对新增测试尤其要看断言：断言“函数被调用”不能证明导出金额正确；把预期值设成当前返回值，也不能说明实现满足需求。

运行检查时保留代码版本、命令、退出状态与关键结果，确认结果对应最终交付版本。后续又改了相关逻辑，就补跑受影响检查。测试工具启动成功、日志中出现了“success”和用例全部通过，是不同层次的证据。

不能只检查最后一段回复

写文件任务检查实际文件及内容，建单任务检查业务记录与状态，页面功能检查用户操作后展示的结果。还要确认没有顺带改坏其他行为，例如导出测试通过，但权限判断被删掉。

执行轨迹用来解释问题：输入怎么理解、改了哪些文件、运行了哪些检查、失败后如何修复。它帮助定位原因，但不必要求每次使用完全相同的工具顺序；只要必要业务条件满足，合法实现可以有多条路径。

“可发布”还要看哪些条件

本地功能完成后，还要确认目标环境的依赖、配置、数据变更和回退方式是否准备好。发布后通过业务健康指标、错误率和关键流程验证真实效果，离线测试不能覆盖所有流量与环境差异。

这些检查应沿用项目实际交付流程。局部文案改动无需套用支付系统的验收强度；涉及权限、数据迁移或外部写入时，则重点验证对应风险。最终交付说明讲清完成内容、证据和仍存在的限制，便于决定下一步。

常见追问

Agent 自己生成测试、自己运行，可信吗？ 可以使用，但需要核对测试预期是否来自需求，并增加独立的业务样例或既有回归用例。实现和测试一起误解需求时，测试仍可能全部通过。

自动检查都过了，还需要人看吗？ 对明确规则，自动验证更稳定；对交互体验、业务取舍和无法充分形式化的结果，可以安排有针对性的审阅。分工取决于证据覆盖与风险，不是给每一步都增加人工确认。

对应教程

参考资料