让 AI 并行干活，验收比派活更重要

以下场景为虚构，用于说明方法，不是我真实项目的经历。

假设要在一周内开发一个社区团购接龙小程序：用户接龙下单、团长统计、到货通知。为了赶时间，派 4 个 Agent 并行：A 做后端接口、B 做小程序前端、C 做统计与通知、D 做测试验收。活派出去只用了十分钟，但最后真正花时间的地方，全在验收上。

一、派活之前，先把任务书写到“可验收”
每个子任务只写一句话目标加一条验收标准。比如 A 的任务不是“做一下后端”，而是“提供接龙下单接口，返回订单号、下单时间、当前接龙人数，异常时返回明确的错误码”；B 的任务不是“做一下页面”，而是“接龙页点提交后能看到自己的订单，团长页能看到汇总人数”；D 的任务是“跑通下单、统计、通知三条用例，全部通过才算完成”。没有验收标准的任务不派——“做一下”这种话，四个 Agent 会做出四个版本，最后合并时才发现对不上。

二、并行时的三条纪律
第一，接口契约先行。字段名、状态码、错误格式先定死，写进一份所有人都能看到的文档，谁都不能中途单方面改。并行开发最怕的不是慢，是各改各的契约。
第二，各干各的分支。A 改接口、B 写页面，互不直接改对方代码；合并前先通读对方的改动，而不是直接点合并。
第三，进度看交付物不看汇报。“写完了”不算，接口能调通、页面能点通才算。汇报可以乐观，运行结果不会。

三、验收三关
第一关是交叉检查：A 的接口由 B 来调，不许自己测自己。自己测自己的接口，等于自己给自己批卷子，字段少一个、边界错一处都发现不了。
第二关是端到端跑通：从用户接龙下单，到团长看到统计，到到货通知发出，全链路走一遍。每个环节单独通过不等于整条链路通过，问题往往藏在环节之间——比如统计读的是旧表，通知发的是旧状态。
第三关是回归清单：改一处，旧功能清单重跑一遍。并行开发后期最常见的返工，就是修好一个坏三个，而回归清单就是防这件事的。

四、结果对不上时以什么为准
不以 Agent 的汇报为准，以实际运行结果和日志为准。A 说接口没问题、B 说页面没问题，但链路就是不通——这时不要在两个汇报之间猜，直接查原始记录：接口返回了什么、数据库里写了什么、日志里报了什么。原始记录是唯一的裁判。
还有一点：延迟、晚同步是常态。统计数字晚一会儿更新、通知晚一会儿到达，不代表链路坏了。验收时以最终一致的结果为准，别在中间状态下结论，也别因为一次中间状态就把能跑的链路拆了重做。

五、一张可直接抄的验收表
交付物、验收标准、验证方法、负责人，四列就够。四个 Agent 每人一行：A 的接口调通了打勾，B 的页面点通了打勾，C 的统计和通知跑通了打勾，D 的三条用例全过了打勾。表上有一项没勾，这个版本就不算完成。

结尾：并行省的是等待时间，不是验收时间。派活一分钟，验收两小时，这不是浪费——验收省了，并行省下的时间，全会以返工的形式还回来。