一次生产发布中，我交给 AI 智能体的工作，以及自己保留的三项决定

一周开始时，每次生产操作都要等我按下 y。一周结束时，智能体已经能够核对授权内容、放行检查点，我只保留三类决定：什么时候发布，是否执行最终切换，以及生产环境可以承受多少验证负载。

精确比较可以交给智能体，发布时间、最终切换和生产负载则由我决定。等待的代价、不可逆操作和预算，仍需要有人负责。跨厂商审查也确实有价值：约 60 份结论中，约 40% 阻止了改动继续，拦下了几个本会在生产环境暴露的问题。不过，审查不能替代真实平台演练，也需要明确的停止条件。

从每次按 y，到明确授权范围

最初，每次生产写入都停在 Proceed? [y/N]。协调智能体写好 Shell 脚本，交给我运行，让我比较一段 64 字符的摘要值，只有完全相同才输入 y。

我问：为什么精确比较还需要我来做？其实智能体比我更适合比较字符串，缺的是授权。说清这一点后，我们调整了分工：

• 我不再代跑智能体写的脚本。已经委托的步骤由智能体执行；尚未委托的步骤，我批准一句范围明确的操作说明。
• 授权提示交给上一篇介绍的精确匹配执行器。
• 检查点交给协调智能体放行，每次批准绑定证据哈希。

每天数小时的交接因此省掉了，也让我看清了真正需要自己负责的决定。

逐条回看我的真实指令

下面保留我在发布期间发出的原话，包括拼写错误。多数指令有效，也有几条没有限定好范围。

“why you do not have the confidence to check whtehre the prompt exactly matches, why you need a human to verify that”——问得对。 这区分了能力和权限。智能体并非不会比较，而是没有得到许可。一旦明确授权，精确匹配执行器就接管了确认步骤，不再需要数小时的人机交接。

“why you keep delaying it to tomorrow. do it today”——要求得对。 智能体优先避免出错，但总得有人承担等待的成本。那天晚上就开始执行，夜里碰到了一个新的平台限制。再等一天也不能避免这个限制，只会晚一天发现。

“auto-approve the fresh plan if counts match”——这条最有效。 授权附带了程序能检查的条件：对象数、引用数、零阻塞项、零删除。智能体知道何时可以批准，何时必须停止。

“why do you need so many passes” / “It causes me upstash memory if you pull very oftent”——预算意识对，术语说错了。 消耗的是请求额度，不是内存。但验证确实需要预算：原计划对线上网站完整检查五轮，每轮约一小时，每轮都会读取数据存储数千次。

“you shall just do it yourself, drive it from there”——只对了一部分。 委托下一步操作是对的，但那一步会删除生产数据存储中的 379 个键，我没有说清范围。之所以没有失控，是因为智能体自行将授权绑定到了试运行（dry run）得到的精确摘要值和键数。更完整的要求应该是：“run the reset yourself; approve only deletions=379 and this digest; stop on anything else.” 委托操作时，同一句话就应该说明边界。

“pause any codex run”——不太妥当。 “Any”包含了另一个智能体与这次发布无关的后台工作。协调智能体用 SIGSTOP 冻结了这些进程，另一个会话里的看门狗将其中两个判定为卡死并终止。更好的说法是：“stop starting new Codex runs; let the in-flight ones finish.” 必须明确是哪些任务、以什么方式停止。“暂停”对不同进程可能有不同含义。

有效的指令往往有两类：追问原因，暴露隐藏的假设；或者给出可以核验的授权条件。最弱的几条只指定了动作，没有限定范围。

我保留的三项决定

第一，发布时间窗口。 智能体的谨慎不断把计划往后挪：重新固定版本、重做计划、等明天早上。我要求当天执行后，它们发现有一个阶段当晚就能开始，也确实开始了。避免出错有价值，但等待也有成本，需要有人决定如何取舍。

第二，不可逆的域名切换。 将域名指向新部署，需要我明确批准。我提前给出一次授权，范围只覆盖那次会话的切换。这样就不会在周六中午因等待我回复而卡住，同时决定权仍然由我保留。

第三，生产负载预算。 切换后，原计划对线上网站进行五轮完整验证。每轮向站点函数发送数千次请求，每次又会读取有月度请求额度的 Upstash。我问为什么需要这么多轮，才发现原计划假设每轮只要几分钟，实际却要一小时。完成两轮无误的检查后，我结束了重度监测，改为每 30 分钟检查十个 URL。验证会消耗资源，预算负责人必须明确何时停止。

独立审查值在哪里

这次由 OpenAI Codex 实现，另一家厂商的 Claude Opus 审查；只有 CRITICAL 或 HIGH 问题会阻止推进。

它拦下了几个会影响发布的问题：

• npx 在伪终端内等待安装确认。这会卡住首次上传，留下需要人工修复的预留记录。
• 回滚处理程序收到 SIGTERM 时，会和日志管道一起退出，恰好在需要回滚时失去保护。
• 回滚报告成功，却没有重新读取别名验证实际指向。
• 恢复命令无法接着完成封存过程中崩溃的操作。

但它没能发现真实平台上的 Upstash Lua 限制和 Vercel 保留查询字符串的重定向行为。审查读取代码、运行本地测试，真实环境的依据仍然要通过演练补足。

每轮审查花 10–20 分钟，部分改动要审两三轮。审查模型也曾出错：它建议增加一项回滚后永远无法通过的检查，又在下一轮拿出证据，指出了自己建议的问题。要求每条发现提供证据，才能让错误的审查意见也被纠正。

可复用的审查提示骨架

Review <commit> (parent <sha>) in <repo>. It runs against PRODUCTION <when>.
Do it yourself, synchronously. READ-ONLY w.r.t. production: never run <list of write commands>.
Context (verified facts): <what's already proven, with numbers>.
Focus, highest stakes first:
  1. <the failure that would hurt most, phrased as a question to answer>
  2. <rollback / fail-closed paths: signals, pipes, partial failure, readback>
  3. <is every guard actually tested? mutate 3-4 guards, report killed/survived>
Output: findings tagged CRITICAL/HIGH/MEDIUM/LOW with file:line and a concrete fix;
at most ~8 real findings; MEDIUM/LOW get a one-line "why not blocking".
End with exactly: VERDICT: READY TO COMMIT — <C>C/<H>H/<M>M/<L>L  or  VERDICT: NOT READY — …

这里最重要的是三个要求：

• 先说最担心哪类失败， 让审查把时间用在高风险问题上。
• 要求实际改动防护条件来验证测试。 测试通过，不代表防护失效时测试一定会失败。
• 以脚本能解析的结论行收尾， 让是否放行由程序检查。

审查何时可以结束

• 只有 CRITICAL 和 HIGH 阻止推进。MEDIUM、LOW 放入遗留事项清单，每项用一句话解释为什么当前可以接受。
• 如果一轮阻塞项全部只是测试完整性问题，没有发现生产缺陷，就停止无限补测。列出已有测试通过变异验证覆盖的不变量，请审查模型指出一类确实新的不变量，或者接受现有测试。总能再想到一个测试，并不意味着需要无休止地迭代。
• 审查深度随风险调整。只改一行的配置连接修复，可以做十分钟的定向审查；新的授权机制，则需要完整审查。

下次仍会沿用的分工

智能体可以承担生产发布中的绝大多数工作。等待多久、接受何种不可逆后果、花多少预算，把这三项决定写清楚，明确交给一个人负责；能够通过精确比较完成的工作，则交给智能体。

这三篇记录的是同一套分工如何逐步形成：第一篇补上真实后端演练，第二篇让执行器在条件不满足时停止，这一篇则明确哪些比较可以委托，哪些决定由我承担。