让AI隔夜迁移代码，如何划定审核边界

让 AI 连夜改几十个项目，最容易漏掉的未必是代码，而是任务范围。作者把第三方错误库迁移交给 agents，第二天看到 26 个 merge request（MR），对照自己记得的 40 多个项目，立刻发现少了一类模块。

这次经历的价值在于：AI 可以正确执行一份不完整的指令，人也不必靠逐行读完所有 diff 才发现问题。真正有效的监督，是先划清权限，再用任务之外的信息检查结果，最后接住需要业务判断的决定。

为什么可以让 AI 连夜干活，却不能直接合并

晚上大约 9 点半，作者给会话留下指令：继续推进迁移，为 waves 1-5 创建全部 MR，但不要合并，第二天一起审查。

任务是把几十个模块使用的第三方错误库迁到自有实现。这类修改重复、机械，适合交给 agents 批量处理，也容易在缺少监督时悄悄出错。

作者敢去睡觉，是因为他把停止点放在了合并之前。分支建错了可以删除，MR 不满意可以关闭。即使一夜留下 40 个不合适的 MR，最坏也只是早上清理，再损失一些计算资源。

无人值守可以走多远，要看出错后收拾残局有多难。

三晚后，作者又授权 AI 在自己睡觉时创建一个私有仓库，第二天，skillup 已经从零建好。这里允许执行的动作更多，因为一个可丢弃的私有仓库容易撤销。两次授权遵循同一原则，只是停止位置不同。

26 对 40 多，为什么比先看 diff 更有用

第二天，作者没有马上打开任何 MR，而是先问：只有 26 个？明明有 40 多个项目，是不是有些使用了 stdlib errors，而非 cockroachdb/errors？

问题就在这里。

原指令要求迁移使用第三方错误库的模块。agents 把这些模块都迁好了，每个模块一个 MR，而且全部保持未合并。按任务描述验收，这次执行没有问题。

但另外一批模块使用的是标准库错误处理，同样需要迁到自有实现，却没有被纳入任务。作者晚上布置工作时漏想了这个分类，结果就少覆盖了十来个模块。

这不是修改质量的问题，是范围定义的问题。对于这次任务，换一个更强的 agent，也不能保证补回指令里缺失的前提。

作者花了大约 4 秒，用「26 个结果」对照「40 多个项目」，发现了缺口。项目总数来自他长期建设这些项目的记忆，并不在 agents 的上下文里。执行方知道自己被指向了多少项目，却不知道这个数字是否等于整个项目群。

执行正确，不等于目标完整。

作者因此更重视一些便宜的整体检查：数量对不对，汇总结果像不像自己熟悉的项目群，为什么某个改动的体积是其他项目的 3 倍？这些检查未必需要深入代码，却可能用到执行方没有的信息。

人留下来判断什么，还要负责怎么收尾

数量核对之后，作者还处理了 agents 主动留下的 3 个 MR。

第一个引入了弃用处理，作者改成直接删除。原因是被处理的代码本来就是一个很新的临时补丁，而且撤销删除的成本很低。代码存在多久、当初为什么写、改错后多难恢复，这些信息不能只靠 diff 判断。

第二个修改了面向用户的错误文案，而旧文案只在前一个版本中发布过。作者接受了修改，因为项目仍处于 pre-release 阶段，发布间隔也短，兼容性要求与成熟产品不同。

第三个通过添加依赖允许名单条目，让测试通过，涉及一个尚未迁移的相邻模块。作者审查时，会话已经把它改成了带「绊线」的临时许可：依赖一旦消失，冗余条目就会触发失败，提醒团队清理。

这里有个可借鉴的细节：临时例外如果必须存在，就让它在失去必要性时主动暴露出来。

真正费脑子的收尾，是合并和发布 40 多个相互依赖的模块。如果随意合并，每次变更都可能让下游自动创建依赖升级 MR，彼此抢跑，引发大量无效 CI。

他们采用 leaves first，沿依赖图逐步推进，让每个模块发布时，它所依赖的模块已经稳定。理解这段不要只记「叶子优先」，因为图的箭头画法可能不同；实际要守住的是依赖方与被依赖方的发布顺序。

我的判断

我认同作者把人工监督放在范围、例外和发布顺序上。这些位置需要全局信息，单个 MR 的代码质量无法代替它们。

但原文没有给出模型、提示词全文、测试覆盖率，也没有对照数据，不能据此断言逐行审查通常只是走过场。这是作者对一次机械迁移的经验判断。涉及错误类型、堆栈或调用方可观察行为的变化时，仍要检查相关实现和测试。

作者把合并视为不可恢复的分界，也应结合场景理解。Git 合并通常可以回退，但发布、下游升级和用户可见变化会增加恢复成本。他选择的停止点适合这次任务，并非所有仓库的固定边界。

此外，「只有作者知道项目总数」可以解释这次发现，却不该成为长期流程的依赖。相比每次靠人脑记账，更稳妥的做法是提供项目清单和分类，让 agents 逐项报告已处理、无需处理和待确认。人再检查清单是否覆盖真实范围。

能拿来做什么

• 给 AI 安排跨仓库迁移时，先列出完整项目清单和现有实现分类。检查目标应是哪些项目需要统一，而不只是哪些文件包含旧依赖名。
• 夜间运行前，明确允许创建分支、提交和 MR，以及在哪个动作前必须停下。第二天先核对覆盖数量与遗漏原因，再进入代码审查。
• 对迁移中的临时依赖许可，考虑增加自动失效检查，让不再需要的条目触发失败，避免临时例外长期留存。
• 处理相互依赖的包或模块时，先整理依赖图与发布顺序，再批量合并，减少下游升级请求和重复 CI。