Vibe Coding 越来越普及之后，我遇到了一个问题。
Coding Agent 可以一次完成很多功能，还会在最后告诉我："已经完成了。"
但作为 AI 产品经理，我怎么确认它真的做对了？
我可以让另一个 Agent 检查，也可以要求开发 Agent 自己测试。但如果检查者只是阅读了一份开发总结，没有真正执行验证，我得到的可能只是另一份看起来合理的结论。
于是，我开始在 DeepSeek Harness（DSH）上开发一个小工具：dsh-acceptance，AI 交付验收台。
我想探索的不是如何让 AI 再多做一点事情，而是如何把一次 AI Coding 交付，变成一个可以逐项核对、有证据支持、能够记录历史的验收过程。
目前，这个项目已经实现了任务级验收、证据记录、验收轮次和人工决策等基础能力。但完整的自动交接、修复与重新验收闭环还没有全部打通。
这篇文章记录的，就是我为什么做这个工具、目前如何设计，以及还没有解决的问题。
一、为什么开发完成之后，还需要一套验收流程？
假设我们让 Coding Agent 开发一个包含搜索、筛选和数据展示的页面。
开发 Agent 完成任务后，报告说三个功能都已经实现。
接下来需要确认什么？
搜索是否真的有效？多个筛选条件组合起来是否符合预期？没有数据时，页面应该如何展示？修改过程中有没有影响原有功能？
这些问题并不会因为 Agent 说了一句"完成"就自动得到答案。
如果只修改一两个功能，人工检查可能还比较简单。但当一次开发涉及多个模块、多项需求时，验收者需要重新梳理需求、寻找检查入口，并逐一确认实际结果。
尤其对于非技术背景的产品经理来说，有些问题不是打开页面看一眼就能发现的。
我最初想到的办法，是让第二个 Agent 负责验收。
这个方向并不新鲜。AI 代码审查、自动化测试和多 Agent 协作已经有很多实践。问题在于，增加一个验收 Agent，并不自动等于增加了一份可靠的验收结果。
它可能只阅读了开发 Agent 的总结，没有真正运行检查；也可能执行了测试，却没有验证原始需求中的关键条件。
因此，我逐渐把问题从"是否应该安排第二个 Agent"，转向了：
如何确保每一项验收结论，都有明确的标准和可核对的证据？
这成了 dsh-acceptance 的设计起点。
二、我的设计思路：把交付验收拆成五个步骤
我希望将一次交付验收组织成一个明确的流程：
每一步关注的事情不同。
1. 保留原始需求，而不只看开发总结
一项交付是否符合要求，首先应该回到最初的需求。
如果我们只根据开发 Agent 的总结制定验收条件，就可能遗漏它没有提及的要求。
因此，dsh-acceptance 会保存任务的原始需求，并将每一条验收项关联到相应的任务契约。系统也会区分原始需求与后续补充的建议，避免把模型后来提出的建议混进原始要求。
这看起来是一个小细节，但我认为它很重要：验收的依据不应该被被验收者的自我描述取代。
2. 将需求转成明确的验收条件
原始需求往往并不是可以直接执行的测试用例。
例如，"健康检查接口正常工作"这句话还不够具体。
我们可以进一步将它拆成一条验收项：
| 字段 | 示例 |
|---|---|
| 原始要求 | 健康检查接口正常工作 |
| 验收项 | 健康检查请求返回预期结果 |
| 通过条件 | HTTP 状态码为 200，响应中 status 字段的值为 ok |
| 验证方式 | 发起请求并检查实际响应 |
这里的示例用于说明验收项如何设计，并不代表我已经用这组数据完成了某次真实测试。
这一步的重点不是让所有需求都变成接口测试，而是把每项要求转换成足够明确、可以检查的通过条件。
对于界面交互、视觉表现或复杂业务规则，验收方式自然会不同。
目前，dsh-acceptance 不会自动替用户生成并确认所有验收项。用户仍然需要检查验收标准是否真正符合原始需求。
3. 让验证结果带有可核对的证据
这是我在设计中最关注的部分。
假设验收 Agent 返回：
"健康检查接口验证通过。"
这句话本身并不能说明它做过什么。
它有没有实际发送请求？请求的结果是什么？响应字段是否正确？
所以，我希望验收记录不只保存一个结论，还要记录相应的观察结果和证据定位。
目前支持的证据类型包括：
- command：执行过的命令及其结果信息。
- file：文件路径与行号等定位信息。
- url：可以定位到的 URL。
- screenshot：截图文件及其定位信息。
- observation：带有定位信息的观察记录。
项目会在写入时校验证据的定位信息。对于无法定位的证据，不会因为模型写了一句确定的结论，就直接接受这份验收记录。
这里有一个我刻意坚持的原则：
证据不够，就不应该为了让结果看起来完整而补出一个肯定结论。
当然，可定位不等于绝对正确。一个命令可以真实执行，但它可能没有覆盖关键条件；一张截图可以真实存在，但它未必证明业务逻辑符合要求。
证据仍然需要结合通过条件进行判断，而不能只看有没有附件。
三、为什么我要保留五种验收状态？
在实现过程中，我发现，简单的"通过 / 失败"二元状态并不足以描述实际验收过程。
目前，dsh-acceptance 使用五种状态：
| 状态 | 含义 | 处理方向 |
|---|---|---|
| 待验收 pending | 尚未形成有效结论 | 开始验证或补充结果 |
| 通过 pass | 有本轮证据支持通过 | 进入人工决策 |
| 未通过 fail | 有证据表明不符合要求 | 生成修复说明 |
| 无法判断 unknown | 现有证据不足以判断 | 补充验证或人工核对 |
| 环境阻塞 blocked | 环境或依赖阻碍了验证 | 先解决阻碍，再重新验证 |
为什么要把"无法判断"和"环境阻塞"单独列出来？
因为这几种情况的含义完全不同。
假设测试环境无法启动，我们就无法确认功能是否正确。这不意味着功能一定失败，也不意味着它已经通过。
同样，如果验收 Agent 没有取得足够的证据，也不应该将其自动判为失败。正确的处理方式是保留不确定性，并明确指出还缺少什么。
因此，这五种状态是并列的分类，而不是五个等级。系统不会把它们压缩成一个通过率或质量分数。
我更希望使用者看到的是：哪些要求已经被证实符合条件，哪些被证实不符合，哪些还需要检查，以及哪些暂时无法验证。
这也是我想通过产品坚持的一条规则：
没有证据，不等于失败；但没有证据，也绝不等于通过。
四、两种取证方式：让独立 Agent 验证，或导入外部结果
在 DSH 环境中，我为验收设计了两种取证方式。
方式 A：委派独立 Agent 验证
用户确认验收项后，可以让 DSH 委派子 Agent 进行验证，并要求它按结构化契约返回验收项对应的结果和证据。
这里的重点不是让 Agent 自由地写一份审查报告，而是让它围绕已经确认的验收项提供结果。
即便如此，结构化返回也不能替代真实证据的判断。Agent 是否实际执行了检查、证据是否足以支撑结论，仍然是验收流程必须关注的问题。
另外，委派执行可能受到宿主能力、会话和环境的影响，因此它并不是任何情况下都能成功。
方式 B：在外部完成验证，再导入结果
有时，验证需要借助其他工具、人工操作或当前 DSH 会话之外的环境。
这种情况下，用户可以生成验收包，在外部完成取证，再把结构化结果导回验收台。
两种方式最后都会形成同一种验收轮次，并遵守相同的证据规则。
这对我来说很重要：不能因为结果来自外部，或者没有使用内置的 Agent 委派方式，就降低验收标准。
五、验收发现问题之后，如何处理？
验收的价值不应该止于记录一个"未通过"。
如果有证据证明某项要求没有满足，就需要将问题交还开发环节处理。
目前，dsh-acceptance 可以根据验收结果生成修复说明，将已证实未通过、无法判断、环境阻塞和待验收等情况分别整理，供开发 Agent 继续处理。
但这里需要明确一个边界：
生成修复说明，不等于已经自动完成修复；开发 Agent 回复"已修复"，也不等于问题已经通过复验。
理想的后续流程是：
验收发现问题
↓ 整理修复要求
↓ 开发 Agent 修改
↓ 针对相关验收项重新验证
↓ 记录新一轮证据与结论
↓ 由人决定是否接受交付当前产品已经具备多轮验收记录、问题整理和人工决策等基础能力，但开发、修复、重新验证之间的完整自动交接闭环还没有全部实现。
我不想把这条理想流程写成已经完成的能力。接下来需要通过实际使用，继续验证怎样串联这些步骤，以及自动化到什么程度才不会损害结论的可信度。
六、我刻意不做的几件事
在这个项目中，有一些事情我暂时没有选择实现。
不把验收变成一个总分
如果一个任务有十条验收项，其中八条通过、两条无法判断，那么"80% 通过率"并不能完整描述交付状态。
剩余两条可能涉及关键业务规则，也可能只是可选的边缘情形。没有明确的优先级与决策依据，单纯计算比例容易产生误导。
所以，目前的设计是并列呈现每条验收项的状态，不把它们折算成分数或完成率。
不将模型建议混入原始需求
验收过程中，Agent 可能提出一些原需求没有明确要求的检查项。
这些建议可能很有价值，但它们不应该悄悄变成最初的交付要求。
因此，系统会区分原始需求与补充建议，由用户确认哪些内容应该成为正式验收项。
不伪造代码版本指纹
这是目前仍然存在的一个边界。
dsh-acceptance 希望让验收记录能够关联到具体的代码版本，但当前 v0.1.2 尚未实现可靠的代码版本指纹，也未实现证据过期判断。
当系统无法取得可靠的代码版本快照时，会如实显示"版本未知"，不会用变更文件列表或时间戳生成一个看似可信的指纹。
接下来仍需要解决两个问题：怎样可靠地确认验收证据对应哪个代码版本，以及代码发生变化后，如何判断之前的证据是否仍然有效。
这并不妨碍当前版本记录验收任务与轮次，但意味着它还不能完整回答"这份结论究竟对应哪个版本的代码"。
七、目前做到了什么，还有什么需要验证？
目前，dsh-acceptance 已经具备以下基础能力：
- 记录原始需求与逐条验收项。
- 通过 DSH 子 Agent 委派或外部结果导入获取验收证据。
- 对证据定位信息进行校验。
- 保存多轮验收结果，并区分五种状态。
- 生成修复说明、导出验收记录，并由用户作出最终交付决定。
但它还不是一个全自动测试平台，也不是代码审查器。
我并不打算重新实现生态中已有的测试执行和代码审查能力，而是探索怎样把这些能力产生的证据，组织成围绕原始需求的交付验收记录。
接下来，我更想通过真实的 Coding Agent 开发任务验证三个问题：
第一，独立验收究竟能发现多少开发 Agent 遗漏的要求？
如果验收 Agent 只是重复开发 Agent 已经知道的内容，就没有带来足够的增量价值。
第二，证据记录能否降低人工复核成本？
记录证据需要额外的配置和处理。如果最终使用者仍然需要从头检查所有结果，验收台可能只是增加了一层流程。
第三，增加验收环节后，整体交付效率究竟是提高了，还是降低了？
独立验收需要消耗额外的模型调用、时间和人工复核。只有这些成本换来了更容易确认的交付结果，这种工作方式才有实际意义。
目前，我还没有足够的真实任务数据回答这些问题。
因此，与其把 dsh-acceptance 介绍成一个已经解决了 AI Coding 验收问题的产品，我更愿意将它看作一次正在进行的工程探索。
对我来说，这次开发最重要的阶段性认识是：
当 AI 能够越来越快地完成实现，我们可能也需要重新设计确认交付结果的方式。
让 Agent 写代码，是把实现工作交给它。
让 Agent 参与验收，则还需要定义标准、收集证据、记录不确定性，并让人能够基于这些信息作出最终决定。
"一个 Agent 开发，另一个 Agent 验收"是不是更好的工作方式，我还想继续通过实际任务验证。
项目地址：github.com/PolinniZhon...
如果你也在使用 Coding Agent，我很想了解你的实际经验：
你目前最花时间的是让 AI 完成功能，还是确认它完成的功能真的符合需求？
又或者，你已经有一套自己的 AI 交付验收流程？欢迎交流。