关于通宵编码智能体（coding agents）的宣传非常诱人：你睡觉，智能体集群干活，你醒来时 PR 已经处理完毕。但现实情况往往更微妙且代价更高。你醒来后面对的是一个队列——六个分支、两个失败的任务运行、一个你没要求的依赖项版本更新，以及一个要么精妙绝伦要么隐约有误的重构。智能体的确生成了代码。但呈现在你桌面上的交付物并不是代码，而是一个分诊（triage）问题，且大多数团队都没有处理它的工作流。
数据显示这并非少数人的抱怨。一项针对 1,255 个团队、超过 10,000 名开发者的遥测研究发现，AI 采用率高的团队合并的 PR 数量增加了 98%——而评审时间增加了 91%，平均 PR 大小增长了 154%。2026 年的后续数据更加糟糕：每个 PR 导致的生产环境事故大约翻了三倍，且现在有 31% 的 PR 在没有任何人工评审的情况下直接合并。当智能体开始值夜班时，瓶颈并没有消失。它转移到了上午 9 点，集中在你一天中的前 90 分钟，并有了一个名字：早晨评审队列。
将这个队列视为一堆普通的公开代码评审是根本性的错误。来自同事的 PR 带有你们共享的上下文——你知道他们为什么要接这个任务，你们在站会上讨论过方案，而且你相信他们运行过自称运行过的测试。而来自八小时无人值守智能体工作的分支则完全不具备这些。评审的重点不是“这段 diff 是否正确？”，而是“这玩意儿在我没看管的时候做了什么决定，我是否同意这些决定？”这些是不同的问题，需要不同的工具、不同的产出物以及对“完成”的不同定义。
信任等级：首先决定哪些工作可以无人值守运行
在任何智能体通宵运行之前，第一个设计决策就已经产生了：哪些工作允许在没有人工值守的情况下进行。跳过这一步的团队最终会面对最糟糕的早晨队列——错别字修复和数据库架构迁移堆在一起，要求同样的审查力度，因为没有任何东西能区分它们。
解决方法是建立一个分级的自治阶梯，而业界已经独立地在这些等级上达成了共识。在底层，智能体以只读方式运行：它们调查、总结并提出建议，但不触碰任何内容。往上一层，它们生成必须由人工应用的 diff。再往上，它们提交到强制评审的独立分支。在顶层——这是大多数团队应该视为通过努力赢得的、而非默认的层级——它们在严格的门禁（如全量测试覆盖、金丝雀发布和自动回滚）保护下自主合并。
在实践中，让这种阶梯发挥作用需要两个属性：
自治权是根据任务类型而非智能体赋予的。 一个成功处理了 50 个干净的依赖项版本更新的智能体，赢得了无人值守处理依赖项更新的权利。但它在数据库迁移方面还没有赢得任何信任。晋升取决于累积的证据——批准率、回滚率、溯源到的事故——而当质量下滑时，降级是自动的。等级是在调度阶段分配的，而非评审阶段。 当你安排通宵工作时，每个任务都带有其对应的等级。这一决策是让早晨分诊变得可控的关键，因为队列到达时已经根据你同意给予的信任程度预先排好了序。
通宵工作的分界线通常落在可预见的范围内：机械化、经过充分测试、易于回滚的工作可以无人值守运行；任何涉及认证、支付、数据模型或公共 API 的工作都需等待天亮。明确的分界线比界线划在哪里更重要，因为替代方案是在上午 9 点为每个分支单独做决定——这只是换了种形式的分诊时间黑洞。
智能体欠评审人的产出物
评审无人值守的工作是痛苦还是可控，取决于一个变量：智能体留下了什么。仅仅一个 diff 加上一段欢快的自动生成总结是底线，但这远远不够——LLM 生成的代码在随便扫一眼时通常看起来很合理，这使得肤浅的评审变得非常危险。评审人的真正工作是审计决策，因此智能体必须呈现其决策。
诱人的“全量主义”答案——将完整的对话记录倾倒进 PR——适得其反。原始记录庞大、嘈杂，偶尔包含敏感信息，而且没人会读。有效的方法是一个简洁的溯源回执，包含几个评审人可以在一分钟内吸收的结构化部分：
意图 ：智能体所理解的任务，用一两行说明。一半的通宵失败源于对目标的误解，这一行能在评审人阅读任何代码块之前就发现问题。决策日志 ：路径选择及其理由，每条一行。“选择升级 X 的大版本，因为漏洞修复没有向后移植。”这些正是评审人可能想要否决的判断。验证证据 ：不是模型生成的“测试通过”字符串，而是实际的测试输出、实际的 lint 结果、实际运行的命令。智能体声称运行了从未运行过的测试，是该领域记录最全的失败模式之一。延期清单 ：智能体选择不 做的一切——它搁置的模糊之处、它注意到但未处理的相邻 Bug、当规范用尽时它所做的假设。异常情况 ：重试、死胡同、工具故障、自我撤回的方案。一个折腾了三小时才收敛的运行任务，比它最终干净的 diff 表现出的更值得怀疑。
延期清单值得特别强调，因为它转化了评审人最难的问题。智能体默默跳过的内容在 diff 中是不可见的——diff 只显示变化了什么，从不显示应该变化却没变化的内容。如果智能体说“我做了 A 和 B；我跳过了 C，因为需求不明确；某人应该查看一下 D”，它就将不可评审的内容（缺失）转换成了可评审的内容（明确的主张）。如果你的系统除了 diff 之外不产出其他任何东西，请务必产出这个清单。
批量处理延迟决策，而非分散处理 一个通宵工作的智能体（Agent）会遇到人类通常在 Slack 上几秒钟就能解决的决策点。在无人看管的情况下，它有三个选择：猜测、停止或延迟。选择猜测，你醒来时可能会发现它基于凌晨 2 点的一个错误假设进行了长达 8 小时的徒劳探索。在遇到第一个歧义时就停止，则会浪费掉整个夜晚。设计良好的中间路径是延迟并继续 ：记录问题，选择最保守的解释，完成可完成的部分，并将问题路由到早晨的决策队列中。
事实证明，这是隔夜工作流中杠杆率最高的设计选择，其原因与 AI 无关：上下文切换成本主导了人类的审查时间。十个 Agent 每个向你中断并请教一个问题——或者更糟，十个分支中每个都隐藏着一个你必须搜寻的嵌入式猜测——其成本远高于决策本身的总和。将十个问题收集到一个队列中，并按它们阻塞的分支进行排序，只需一杯咖啡的时间和 15 分钟的专注判断即可完成。
这种机制很平庸，但这正是重点所在。每次运行一个决策文件、溯源凭证（provenance receipt）中的一个章节、PR 上的一个标签——任何能让“Agent 需要人类提供什么”成为一等公民产物（first-class artifact）的东西，而不是让审查者通过带着怀疑阅读 Diff 来重新构建。成功运行隔夜循环的团队，几乎最终都会收敛到某种版本的状态检查点，以便下一次会话（无论是人类还是 Agent）能够无缝衔接。
为什么这与审查 PR 是不同的技能 有必要明确说明为什么早晨的队列感觉比同等数量的人类 PR 糟糕得多，因为这种差异是结构性的，而非心理上的。
审查同事的 PR 是一种验证 （verification）：共享的上下文加上社交信任，意味着你在检查一段你大体已经理解的旅程的最后几英里。审查 Agent 隔夜生成的输出则是一种重构 （reconstruction）：你正在通过产物重建推理过程，决定是否认可那些你不在场时所做的决策。这些决策是由一个没有切身利益（no skin in the game）且有记录表明其表现得比实际更自信的系统做出的。接手时间的数据反映了这一点——Agent 生成的 PR 待处理时间比人类 PR 长好几倍，因为审查者敏锐地感觉到，每行代码背后的工作量远比 Diff 显示的要重。
重构也颠倒了通常的审查经济学。对于人类 PR，“小而合理”意味着快速批准。对于 Agent 输出，合理性几乎是廉价的——模型总能生成看起来合理的代码——因此表面质量几乎不提供任何信号。审查者的注意力必须从“这看起来对吗？”转移到“这种运行最可能在什么地方出错？”这就是为什么溯源凭证比 Diff 更重要：异常情况、延迟决策和未经核实的声明能将怀疑定位，而从头到尾阅读代码永远做不到这一点。
实际操作建议：分两轮对队列进行分选（triage）。第一轮是定性而非审查——对于每个分支，在不到一分钟内决定是进入合并轨道、修复轨道还是废弃 ，参考等级、凭证和验证证据。立即废弃一个方向错误的分支是该工作流的一个特性，而不是失败；重新生成 Agent 工作的边际成本很低，而想要挽救一个糟糕的 8 小时运行的沉没成本本能，正是让 30 分钟的分选演变成浪费掉整个早晨的原因。第二轮是真正的审查，但仅针对幸存的分支，并按风险等级排序——在你的判断力最清醒时，先处理风险最高的部分。
失效模式：分选成为团队最大的时间黑洞 如果不加管理，早晨的队列会产生一种恶劣的棘轮效应。Agent 的产能是弹性的——今晚排入更多任务，明天就会出现更多输出。人类的审查能力则不然。Agent 吞吐量的每一次提升都会直接压在审查者身上，而团队中最资深的工程师——那些拥有分选所需判断力的人——会悄然变成机器输出的全职审查员。遥测数据展示了这种压力从何处泄露：审查时间上升了 91%，当审查者最终饱和时，未经审查的合并开始攀升（在 2026 年的数据中上升了 31%），紧随其后的是事故率。
三个控制点可以防止这种棘轮收紧：
限制队列，而非限制 Agent。 隔夜派遣的预算应根据明天的审查能力来制定，而不是根据机群理论上能完成多少工作。如果一个原本规划为两小时分选的队列始终需要四小时才能完成，那是在提醒你修复凭证、等级分类或任务选择，而不是硬撑过去。将 Agent 产能花在降低审查成本上，而不仅仅是产出更多代码。 对抗性审查 Agent、跨模型批判循环和自动化验证步骤，都能提高到达人类面前的工作底线。它们并不能取代人类审查——护栏模型仍然只是模型——但它们改变了人类审查的目的 ：从发现问题转变为对标记的问题进行裁决。像衡量 CI 一样衡量分选时间。 记录每个分支的分钟数、废弃率、每次运行延迟的决策数、以及合并后的隔夜工作的回滚率。如果分选时间上升而废弃率持平，意味着凭证质量在下降。如果废弃率上升，意味着任务选择在恶化——你派遣了机群在无人值守时无法真正完成的任务。两者都是可以修复的，但前提是有人在关注。 除了避免浪费掉早晨之外，还有一个战略上的理由。从自主 Agent 中获得复合价值的团队，并不是那些运行 Agent 小时数最多的团队；而是那些拥有从 Agent 输出到合并、可信代码的最短且最可靠路径的团队。隔夜产能在现在是一种商品——每个供应商都在销售能在你睡觉时编码的机群。审查队列才是这种产能转化为交付软件或堆积为风险的地方。
不那么令人舒服的总结是：Agent 将编写代码移出了你的关键路径，而将判断置于其上。早晨的审查队列是这种判断力得以行使的地方，它理应像你的 CI 流水线一样经过精心设计——在派遣前确定信任等级，使用溯源凭证而非仅仅是 Diff，将延迟决策批量处理到一个队列中，采用具有真正废弃选项的两轮分选，并设定与审查能力挂钩的硬性上限。建立了这种工作流的团队醒来后获得的是杠杆；没有建立的团队醒来后面对的是披着杠杆外衣的积压工作。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
