验收分级：哪些交付只验证据，哪些必须本人深审

一、为什么写这篇

旗舰文讲了协调者模型：bot 拆任务、写 brief，真活派给家里一台常开的机器上的 worker。这篇讲另一半：活派出去以后，交回来的东西怎么收。

派活这半边，我已经把 brief 固定成「背景、任务、红线、交付物」。收活这半边，我一开始是靠感觉。有时让协调者把代码从头读一遍，有时 worker 说「做完了」我就信了。前一种烧额度又读不出结果，后一种出过事。

后来我定下一条规则：验收按风险分级。低风险的交付只验证据，高风险的交付我本人审。

二、第一级：交活必须附证据，协调者只验证据

规则很简单：执行模型交活时，必须同时交一份可核对的证据。「我改好了」不算交付。

我常用的证据有三类：

• 构建结果：build 是否通过，输出里有没有 warning 或报错，原样贴出来，不接受概述。
• 线上验证：改动上线后，对线上页面发请求，贴状态码和关键内容，证明新东西真的在线。这里的地址在 brief 里指定，交付物里只给结果。
• 截图：页面类改动要有截图，而且要覆盖小屏。上线批量工具站的复盘里有一条教训：新页面不能只 curl 一下就算过，小屏上布局崩了，curl 看不出来。

协调者拿到这些，只做三件事：

1. 证据齐不齐？缺哪一类，退回去补。
2. 证据和 brief 对不对得上？比如 brief 说只改说明页，diff 的文件列表却出现了别的目录，那就是越线。
3. 证据本身可不可信？

第三条要多说一句。证据也会骗人。我踩过的一个例子：抓取某个排行站，结果是 0 条，差点判断成「这个站没数据」，后来发现是被站点防护挡了。「0 条」是真实的输出，但结论是错的。所以我要求证据里带上过程信息，比如状态码、响应长度，而不只是最终的数字。

为什么协调者不通读代码？原因有两个。一是协调者的上下文要干净，几千行 diff 塞进去，后面的判断会变差。二是通读也读不出什么：对低风险改动，构建通过、线上可见、截图正常，已经覆盖了大部分会出的错。把读代码的精力省下来，留给下面第二级。

三、第二级：这五类，一律本人批、本人深审

下面这些交付，不走「只验证据」这条路：

• 支付
• webhook
• 数据迁移
• 密钥
• DNS

共同点是：出错的代价大，而且不好回头。这五类我不让协调者代批，也不让另一个 agent 代审，必须是我自己看。

具体怎么做，举几个通用场景：

支付和 webhook：光有构建通过没用。我的验收顺序是：店铺审核通过 → 我用自己的真卡下一单 → 逐项核对 webhook 是否到达、订单是否生成、权益是否到账。这几步里没有一步能让 bot 代劳。另外，没做好的付费选项不要摆在定价页上，改成「即将开放」，因为灰掉的按钮既劝退用户，又量不到点击。

数据迁移：顺序是先备份并记下可回退的时间点，再迁移，最后才打开功能开关。新功能先保持支付关闭，迁移确认没问题再放开。

密钥：密钥只放进专用保险库，聊天和笔记里永远只写路径，不写值。出过一次事：轮换服务账号时旧 token 被删，各处报「服务账号已删除」。从那以后，凡是涉及密钥的改动，我都要先看清影响了哪些机器、哪些调用方，再动手。

DNS：改之前先确认这个域名归属哪个账号。我曾经把一个工具误部署到了个人的托管账号上，后来只能删掉重建。个人和其他工作的流水线必须隔离，判断归属这一步放在部署之前，而且由我来判。

深审的意思是我真的读代码、读配置，不是扫一眼。这类改动不多，所以我负担得起。

四、agent 互审：可以，但要限轮次

让一个 agent 审另一个 agent 的产出，我觉得有用，能抓到一些我不一定会注意的问题。但它有个副作用：两个 agent 互相提意见、互相修改，可以一直转下去，额度就这么烧掉了。我这个人本来就要控制成本，AI 与基础设施每月至少 1000 美元左右，不能再被这种事消耗。

我的做法：

• 互审只用于低风险、可自测的改动。
• 轮次写死，到上限就停，只留少数几轮，剩下的分歧交给我定。
• 互审不替代第二级。支付、密钥这类，agent 审过，我照样要审。
• 互审用便宜的模型就够了，贵的模型只留给关键判断。

五、部署说明：固定写 Testing / Risk / How to revert

每次交部署说明，格式固定三段：

• Testing：做了哪些验证，对应哪份证据。
• Risk：这次改动可能影响什么，没验证到的地方也要写出来。
• How to revert：出问题时怎么退回去，一步一步写清。

这三段对我有两个用处。第一，写不出 How to revert，说明这个改动还没准备好上线。第二，Risk 那一段是诚实度的检验：全写「无风险」的说明，我会直接退回去。

最终上线仍然由我拍板，部署这一步不交给 bot 自动做，这一点和旗舰文一致。

六、可执行清单

1. brief 的交付物段落里，明确列出要附的证据：构建结果、线上请求结果、截图（含小屏）。
2. 协调者只做三件事：证据齐不齐、对不对得上 brief、证据本身可不可信。
3. 证据要带过程信息（状态码、长度），避免「0 条」这种数字误导判断。
4. 支付、webhook、数据迁移、密钥、DNS，一律本人批、本人深审，不让 bot 代批。
5. 支付类用真卡下单，核对 webhook、订单、权益三处；迁移类先备份再迁移再开开关。
6. agent 互审只用于低风险改动，轮次上限写死，到了就停。
7. 部署说明固定三段：Testing / Risk / How to revert，写不出回退方法就不上线。
8. 部署前先判归属账号，个人和其他工作隔离。

七、和旗舰文的关系

旗舰文管派出去：协调者怎么拆任务、写 brief、划红线。这篇管收回来：交活要带什么、什么只验证据、什么必须我自己审。两边合起来，才是一条完整的流程。

我会继续写这类踩坑记录。想跟进的话，可以订阅 RSS，目前 /posts 下有三条内容线，Agent 协作是其中一条。