AI 编程验收：独立复跑才能确认通过

AI 写完代码后说「测试全过了」，能不能直接提交？Silicon Showdown 的作者给出的答案是：不能。他把构建和验收交给不同的 AI 工具，要求验收方自己重跑完整测试，再决定是否提交。这个多出来的步骤，确实抓到了错误。

这篇文章的价值不在于证明 AI 有多不可靠，而在于指出一个容易被忽略的问题：执行任务的工具，也可能误报自己的执行结果。对日常用 AI 改代码的程序员来说，检查依据比完成报告更重要。

「测试通过」到底证明了什么

Silicon Showdown 花了几周完成，两个 AI 工具承担不同职责。构建方按书面规格修改代码；协调方检查 diff，独立运行完整测试，最后才提交。构建方的提交数是 0，也没有部署权限。

到上线时，完整测试包含 84 个自动化测试套件，覆盖游戏规则、回放、API、安全响应头、搜索基础功能、调度器、缓存，以及 Cloudflare Worker 的真实本地运行。这里的 84 是套件数量，不是作者公布的复跑次数。

作者遇到了两类很具体的误报。

第一类是测试依据就错了。一个构建方拿试运行中猜出的数量作为预期值，围绕它编写测试。猜测有误，但它仍然报告全部通过。原文没有交代错误数字，也没有给出测试实现，不能进一步判断断言是怎样写错的。

第二类是部分测试根本没运行。构建方的沙箱反复无法执行某些套件，因为它们需要使用仓库外的临时目录。这种环境里的「通过」，无法证明完整测试已经执行。

验收需要确认测试实际运行过，还要确认预期值有可靠依据。

协调方审查代码时，也发现了测试报告没有揭示的问题：大厅 agent 在第一条问候尚未生成完时，每隔两秒又发起问候；内部 agent 被要求点评自己没参加的比赛，在外部 agent 共用队列后触发错误；Werewolf 的人数已从七人缩到五人，回放却仍安排七个座位；agent 反馈列表的缓存时间也过长。

这些都是常见的异步、状态同步和缓存问题。完成报告的语气再肯定，也不能替代检查。

为什么能干活，不等于能改生产系统

作者给构建方的规格是一份简短交接说明：哪些文件可以改，哪些地方不能动，哪些测试必须通过。它的作用是把任务边界写清楚，让后续验收有依据。

协调方的能力更广。它还负责上线所需的 DNS、重定向、防火墙规则、自定义域名、部署，以及在请求量达到上限时关闭站点的成本保护机制。

但这些操作都通过 Cloudflare API 执行，并且每一步都经过作者批准。密钥没有被打印出来；唯一拥有编辑权限的 API token，也由作者亲自创建。

作者主张的是：执行能力可以放宽，改变系统的权限要收紧，关键授权由人掌握。代码验收与生产权限，是两道分别设置的控制。

文章随后把这个逻辑延伸到营收运营（RevOps）：AI SDR、信息补全 agent、预测助手报告的预约数量、客户调研结果和交易风险评分，同样只是状态报告。要验证预约数量，就应核对 CRM 中的实际记录，而不是只看供应商仪表盘；还应定期抽样检查输出，避免错误长期无人察觉。

我的判断

我赞同把「完成声明」和「验收证据」分开。尤其是沙箱缺少目录权限、运行依赖或外部服务时，一句「测试通过」很容易掩盖执行范围缩水。被跳过的检查，应明确显示为未验证。

不过，这是一个项目、一个构建方的观察。作者没有给出误报率，也没有比较单 agent、多 agent 或传统 CI 的效果。独立复跑抓到了问题，是项目经验；它是否比其他方案更省钱、更稳定，原文没有对照数据。

独立复跑也有边界。如果测试本身采用了错误预期值，换一个执行者运行同一套测试，未必能发现问题。文章里的代码审查很关键，但作者没有逐项说明缺陷究竟由测试还是审查捕获。

对已有 CI 的团队，我更倾向于先把固定环境、完整日志和必过检查做好，再考虑是否需要额外的 AI 协调方。独立执行与审查是有价值的机制，不一定必须由第二个 AI 承担。每次都跑完整套件的成本，原文也没有提供耗时数据，不能直接推广到所有大型仓库。

能拿来做什么

• 给 AI 分配前端或 Node 修改任务时，把允许修改的文件、禁止触碰的范围和验收条件写进交接说明，让审查能逐项核对。
• 收到「测试通过」后，查看实际执行命令、日志和跳过项，并在可信环境或 CI 中复跑；环境限制导致的未执行，应保留为未验证。
• 涉及异步任务、人数配置或缓存策略的修改，除检查测试结果外，还要审查重复触发、旧状态残留和缓存时效，这些正是作者遇到的缺陷。
• 将代码修改权限与部署、DNS、防火墙等权限分别管理。需要修改线上配置时，再由人授予对应权限，并避免在输出中暴露密钥。