AI产品经理终知了：没有证据就不算通过的Coding Agent验收设计
AI产品经理终知了在掘金分享其在DeepSeek Harness上开发dsh-acceptance工具的设计思路。针对Coding Agent报告完成但缺乏独立验证的问题，他提出将验收依据锚定原始需求、拆解为可检查的通过条件、记录可定位证据，并用待验收、通过、未通过、无法判断、环境阻塞五种状态保留不确定性，明确拒绝将无证据折算为通过或失败。
重要性实质性证据E3 可检验写法快讯
Vibe Coding普及之后，Coding Agent能一次完成多个功能并报告
已完成
。AI产品经理终知了遇到的问题是：如何确认它真的做对了？让另一个Agent检查，如果检查者只阅读了开发总结而没有真正执行验证，得到的可能只是另一份看起来合理的结论。
他在DeepSeek Harness（DSH）上开发了dsh-acceptance工具，核心思路不是让AI多做一点事情，而是把一次AI Coding交付变成可以逐项核对、有证据支持、能够记录历史的验收过程。设计起点是将问题从
是否应该安排第二个Agent
转向
如何确保每一项验收结论都有明确的标准和可核对的证据
。
具体设计分五步。第一步，系统保留任务的原始需求，将每条验收项关联到相应任务契约，区分原始需求与后续补充建议，避免验收依据被被验收者的自我描述取代。第二步，将模糊需求转成明确的验收条件，例如把
健康检查接口正常工作
拆解为HTTP状态码200、响应中status字段值为ok、验证方式为发起请求并检查实际响应。
第三步是确保证据可核对。验收记录不只保存结论，还关联命令执行结果、文件路径与行号、URL、截图或带定位信息的观察记录。系统在校验时坚持一条原则：证据不够，不应该为了让结果看起来完整而补出一个肯定结论。可定位不等于绝对正确，证据仍需结合通过条件判断。
第四步，dsh-acceptance使用五种状态而非简单的通过/失败二元分类：待验收、通过、未通过、无法判断、环境阻塞。作者认为这几种情况含义完全不同——测试环境无法启动不意味着功能失败也不意味着通过，验收Agent未取得足够证据也不应自动判为失败。系统不会将它们压缩成一个通过率或质量分数。
第五步，验收发现问题后生成修复说明交还开发环节，但明确区分
生成修复说明
与
已自动完成修复
，开发Agent回复
已修复
也不等于问题已通过复验。目前完整的自动交接闭环尚未全部实现。
取证方式有两种：委派DSH子Agent按结构化契约返回结果，或在外部完成验证后导入结果。两种方式遵守相同的证据规则，不因来源不同而降低标准。
作者刻意不做几件事：不把验收折算为总分，不将模型建议混入原始需求，不在当前v0.1.2版本伪造代码版本指纹——无法取得可靠快照时如实显示
版本未知
。他提出三个尚未回答的问题：独立验收能发现多少开发Agent遗漏的要求、证据记录能否降低人工复核成本、增加验收环节后整体交付效率是提高还是降低。目前没有足够的真实任务数据回答这些问题。
这篇记录的价值在于它把
没有证据，不等于失败；但没有证据，也绝不等于通过
这条原则落到了具体的数据结构、状态定义和校验规则上，为正在使用Coding Agent的团队提供了一个可参照的验收框架，同时也诚实地标注了哪些环节仍停留在设计意图而非已验证的能力。