编码

变化在哪里

在 L1，AI 工作的单位是一次按键：接受一条补全，或者把对话里的一段代码贴进仍由人编写的提交里。到了 L2 及以上，单位变成一整个拉取请求。这一点改变了编码阶段的任务。当智能体来写 diff，稀缺的就不再是打字，而是工程师能否快速、可靠地判断这个 diff 对不对。瓶颈一章追踪了这部分精力在整个交付系统中流向何处，本章讨论其中落在代码库内部的那一段。辅助编码能让个人快多少，是一个区间：从慢 19% 到快 55.8%，取决于任务类型、对代码的熟悉程度、代码库成熟度和工具代际，经济学一章对此有完整解读。这里的问题更窄：一个代码库、一项任务和一套工具链要满足什么条件，智能体的拉取请求才便于检查？

证据最充分的答案是：检查必须在智能体开工之前就存在。Anthropic 的 Claude Code 最佳实践指南（厂商指南，2026 年 10 月查阅）一句话说清了这一点："给 Claude 一个它能运行的检查：测试、构建、一张可供比对的截图。这就是一个需要你盯着的会话与一个你可以走开的会话之间的区别。"理由紧随其后："Claude 在工作看起来完成时就会停下。没有它能运行的检查，'看起来完成了'就是唯一的信号，而你自己就成了验证回路。"把产品名换掉，这个道理对任何编码智能体都成立。没有可运行检查的智能体需要有人守在旁边，最多算 L2；有了检查，它才能被放手，这是迈向 L3 的第一个前提。

由此还有两个变化。其一，代码库本身成了智能体的输入：构建、测试命令、约定和禁区，要么传达到了智能体，要么没有。其二，编码现在可能跑到负责检查它的阶段前面去。成熟度模型的规则 6 经验法则（本书的提议，基于相关性数据）主张，编码最多比评审与测试中较低者高一级。多数团队在这条路上还处于早期。在 Stack Overflow 2025 开发者调查（调查，自选样本）中，14.1% 的受访者每天在工作中使用 AI 智能体，37.9% 根本不打算使用。

编码阶段的阶梯

各级标准与成熟度模型的编码一行相同，这里再为每一格补上它为何落在此处的理由。级别按具名任务类型打分，取你实际采用的评审方式与智能体凭证所允许的权限两者中较高的一个。

L0 与 L1。L0 是一种选择，不是落后。一个 codemod 或依赖更新机器人即便开出成千上万个拉取请求，就 AI 而言仍是 L0。L1 是测量最多的一级，它给本章的教训是反面的：一个让工程师敲代码更快的助手，并不能说明智能体交出的整个拉取请求能否通过评审。

L2 是多数团队现实可达的级别，而它的证据表明人仍在做实质性工作。dotnet/runtime 的记录（T2）是最完整的公开记录，案例研究一章对它有详细解读。其中两个数字比任何定义都更能说明 L2。当有人向智能体的分支推送了提交，这些拉取请求的成功率是 86.2%；没有人工提交时是 55.1%，文章提醒说，后者部分反映的是被有意搁置的探索性拉取请求。另外，已合并的智能体拉取请求平均收到 16.5 条评审评论，人写的是 12.4 条。智能体交出产物，人来掌舵和纠正。一项关于开源项目中 Claude Code 拉取请求的独立研究（Watanabe 等人，T1）结论一致：157 个项目中的 567 个拉取请求有 83.8% 被合并，但其中只有 54.9% 未经进一步修改就合入。这些智能体主要用于重构、文档和测试，也就是本章后面会回到的那些边界清楚的任务类型。

L3 在生产中存在，但只有数量。与 L2 相比，变化在于没人盯着运行过程。智能体在隔离环境中无人值守地工作，人只看到完成的拉取请求。Stripe 是最清楚的公开例子，也是本章的案例。GitHub 的 Copilot 云端智能体（厂商文档，截至 2026 年 10 月）发布了与之匹配的权限边界：只有对仓库有写权限的用户才能触发它；它只能推送到自己的分支；它的工作流"在 Copilot 云端智能体的代码经过评审之前不会被触发"；提出变更的人不能批准它。Faros 报告称，在"最前沿"，智能体发起了 13–14% 的拉取请求（Faros，厂商遥测，T3，截至 2026 年 9 月）；从中只取方向，不取比例。失败案例是 Answer.AI 试用 Devin 的一个月：交给自主智能体的真实任务范围松散，20 项只成功 3 项。这些来源都没有公布无人值守工作的逃逸缺陷率或事故率，更没有与人工基线比较。模型在 L3 要求这种比较，所以编码领域每一个公开的 L3 说法，说的都是设计，而不是结果。

L4 没有 LLM 证据。没有人公布过对某个任务类别自动合并 LLM 编写的代码并附有验证记录。Spotify 的 Fleet Management 自动合并了其 250 万以上拉取请求中的大部分（截至 2026 年 6 月），但这套系统起步于确定性脚本，Spotify 也没有说自动合并的那些里有多少出自它的 LLM 智能体。凡是智能体真的在没有逐项批准的情况下行动，都是因为它持有一份谁也没打算给它的凭证，Replit 和 PocketOS 丢失生产数据库就是如此。这些是事实上的 L4 授权，按权限而不是按意图打分。

案例：Stripe 的 Minions

Stripe 的工程博客文章《Minions：Stripe 的一次性端到端编码智能体》（Alistair Gray，2026 年 2 月 9 日）描述了一个规模化运行、设计公开的无人值守编码智能体部署。标题数字是："Stripe 每周合并的拉取请求中，有一千多个完全由 minion 产出。"限定条件就在同一段："它们经过人工评审，但其中没有一行人写的代码。"

级别：编码，就其处理的常规任务类型而言，按设计属于 L3。运行无人值守且在沙箱内，每个产出的拉取请求都由人评审。Stripe 之所以是 L3，是因为没人盯着运行过程，而不是因为取消了评审。评审并没有取消。

读这篇文章，要看它的准备，而不是数量。几乎每一个设计选择都对应本章的三样东西之一。

• 环境是为智能体搭的。Minions 运行在开发机（devbox）上，这些机器"预先热启动，一台大约 10 秒就能拉起"，并且"与生产资源和互联网隔离"。正因为有这层隔离，minion 运行时不需要逐项的权限确认。沙箱做了审批点击本会做得很差的那份工作。
• 智能体读的指令和人用的工具读的是同一份。"Minions 读取的编码智能体规则文件，与 Cursor 和 Claude Code 这类由人操作的工具读取的是同一批。"无人值守的智能体没有另外维护一套提示词。工具通过一个名为 Toolshed 的中心 MCP 服务器提供，其中有 400 多个工具（截至 2026 年 2 月）。
• 检查快速、确定且有上限。每次推送都会运行本地 lint，耗时"不到五秒"。CI 可调用"超过三百万"个测试。一次运行"最多只有两轮 CI"。这个上限是刻意的设计：两轮之内跑不通的智能体会把任务交还，而不是在错误的问题上耗上几天。
• 工作以具名的常规任务形式到来。工程师"最常从 Slack 发起"一次运行，此外也可以从命令行、网页界面和不稳定测试（flaky test）工单发起。不稳定测试工单本身就是一种自带完成定义的任务类型。

它没有说明什么。任何结果。没有成功率，你就无法知道每合并一个要失败多少次运行。没有回退率或事故率，没有每个拉取请求的评审时长，也没有占 Stripe 全部拉取请求的比例。"每周一千多个"说明这种模式能规模化运行，但不能说明它优于其他做法，也不能说明它耗费了多少评审工时。

对照第 I 部分的两个案例来读。Answer.AI 的 Devin 试用采用的是同一类架构，即智能体无人值守地把工作做完，结果 20 项任务失败了 14 项；它的智能体"会花上好几天追逐不可能的方案，而不是认清根本性的障碍"。给运行设上限、以常规任务作为输入，正是那次试用所缺少的那类控制。dotnet/runtime 从有人评审的一侧给出同样的教训：团队修好环境、写了指令之后，成功率几乎翻倍，"不是靠更好的 AI 模型，而是靠更好的准备"。文章的结束语就是本章的论点："如果说这段经历只有一条教训，那就是：准备比模型更重要。"

迁移步骤

按任务类型，一次只升一级。顺序很重要：环境先于指令文件，两者都先于对模型的任何评判。

从 L0 到 L1：先定立场

写清楚是否允许 AI 辅助编写的代码、适用于哪些代码库、需要怎样披露。清晰且已传达的 AI 立场是决定级别的前提条件之一。一个在没有立场的情况下滑进 L1 的团队，也会以同样的方式滑进 L2。治理问题由第 15 章《向更多团队推广》讨论。

从 L1 到 L2：准备代码库

1. 先让环境为智能体所用。在智能体真正要运行的地方运行它，在它碰代码之前先看它在哪里失败。在 dotnet/runtime，智能体起初连自己构建所需的包都下载不了。修复靠的是配置："我们配置了防火墙规则，允许访问构建所需的包源"，再加上一些设置步骤，避免构建超时。这些改动之前创建的拉取请求成功率为 38.1%，之后为 69%。月度成功率从第一个月的 41.7% 升到最近一个季度的约 71%。文章无法把指令文件的贡献与同时上线的环境修复分开，所以两者都要修，但不要把功劳单独记在任何一方。
2. 亲手写一份简短的指令文件。关于指令文件（AGENTS.md、CLAUDE.md、copilot-instructions.md）的证据有正有反，而这种分歧本身就是教训。
   • 苏黎世联邦理工学院的研究《评估 AGENTS.md》（Gloaguen 等人，T1）在 SWE-bench 任务上测试了带 LLM 生成上下文文件的智能体，又在真实 issue 上测试了带开发者提交的上下文文件的智能体。结论是"提供上下文文件总体上并不能提高任务成功率，反而使推理成本平均增加 20% 以上"。智能体确实遵循了文件中的指令，但仓库概览并无帮助。这类文件"适合用来说明非标准的编码做法"。
   • Lulla 等人（T1）在 10 个仓库的 124 个拉取请求上分别在有、无 AGENTS.md 的条件下运行智能体。有文件时，运行时间中位数低 28.64%，输出 token 低 16.58%，"同时任务完成表现相当"。
   • 负责管理该格式的智能体 AI 基金会（AAIF）做了一个小型 A/B 测试（2026 年 7 月）：一个仓库、一份十二行的文件、每种条件运行五次。在一个表述含糊的任务上，墙钟时间中位数下降 27%，额度消耗下降 24%，diff 大小下降 26%。而在较难的多文件任务上，每种条件只跑一次时，结果曾显示有文件反而慢了 44%；跑五次后结论反转，中位数快了 9% 到 10%。
   测量方 苏黎世联邦理工学院与 LogicStar 研究者 · 基准测试加真实 issue 评估，覆盖多个智能体和模型 · 2026 年 2 月发表，2026 年 9 月修订 · T1。Lulla 等人，学术研究 · 有无文件的配对运行 · 124 个 PR，10 个仓库 · T1。AAIF · 每种条件五次运行，一个仓库 · 2026 年 7 月 · T3（该格式的管理方）

   把各自测量的东西分开看，三者其实一致。成功率并不会普遍提高，生成的或泛泛而谈的文件只会多耗 token。简短、具体、由人亲手写、只写智能体推断不出来的内容的文件，能让运行更快、更省，而不损害完成度。Anthropic 给出的删改标准是："对每一行都问一句：'删掉它会不会让 Claude 犯错？'不会就删。臃肿的 CLAUDE.md 会让 Claude 忽略你真正的指令！"它建议写入的是：智能体猜不到的命令、与默认不同的风格规则、测试运行器、仓库协作规范、项目特有的架构决策、环境上的特殊之处，以及不显而易见的坑。建议排除的内容包括"逐个文件的代码库描述"。GitHub 对 2,500 多份 agents.md 文件的分析（厂商，定性分析）归纳出六个应覆盖的方面（命令、测试、项目结构、代码风格、git 工作流和边界），并把边界分成三档："始终要做""先问再做"和"绝不能做"。该写进文件的决策很多是设计决策；它们如何传达给智能体，见需求、规格与设计一章。本站在AGENTS.md、CLAUDE.md、Cursor 规则与智能体技能对比一文中比较了各种格式，附录 A《模板》提供了一份起步文件。

3. 为每个智能体拉取请求署名，用标签、提交尾注（trailer）或智能体自己的账号都可以。没有署名，6.6 节的指标一个也算不出来，这个阶段的得分也无法高于 L1。
4. 说清你要委派哪些任务类型，不委派哪些。GitHub 为自家智能体写的使用指南（厂商文档，2026 年 10 月查阅）是一份排除清单，而且出自最有理由说"都可以"的厂商。它把以下工作留给人："范围广、依赖大量上下文、需要跨仓库知识和测试的重构问题""生产关键问题""涉及安全、个人身份信息、身份认证影响的任务""事故响应"以及"缺乏明确定义的任务"。委派出去的 issue 应当带有"关于好方案应是什么样的完整验收标准"。
5. 从第一周起按任务类型跟踪成功率，即已合并数除以（已合并数加已关闭数），并记录是否需要人推送提交。如果某种任务类型经常要人来救分支，那它就是 L2 工作，不管合并率看起来多高。

达到 L2 的标志是：有一种具名任务类型，其智能体拉取请求都有署名、全部有留痕的人工评审，代码库里有指令文件，并且你能报出它的成功率。

从 L2 到 L3：让运行可以放手

1. 给智能体一个它能运行的检查，并让"停止"受它把关。Anthropic 的指南描述了一个逐级加强的做法。可以在提示词里要求运行检查，或把它设为会话目标；可以把它做成"确定性的关卡"，即一个 Stop 钩子，"以脚本形式运行你的检查，在检查通过之前阻止这一轮结束"；也可以加一个验证子智能体，使"做事的智能体不是给自己打分的那一个"。指南说，让"无人值守的运行在没有你的情况下正确完成"的，是会话目标和 Stop 钩子这两种做法，而其中只有钩子是确定性的。Spotify 的 Honk 恰好把核验器放在这个位置（案例研究）：只要有一个失败，拉取请求就不会被创建。如何让这道检查强到值得信任，见测试与验证一章。
2. 用同时具备文件系统边界和网络边界的沙箱来运行。Anthropic 的沙箱技术文章（厂商，2025 年 10 月）写道："有效的沙箱既需要文件系统隔离，也需要网络隔离。"在它的云端会话中，"敏感凭证（例如 git 凭证或签名密钥）从不放在沙箱内"；由一个代理检查每次推送，再附上真实的令牌。Stripe 的开发机是同一思路在公司规模上的应用。
3. 让合并和批准不在智能体的权限范围内。照搬云端智能体的权限边界：智能体只能推送到自己的分支，工作流要等人评审后才运行，提出需求的人不能批准。
4. 根据你自己的数据挑选第一个 L3 任务类型，按类型而不是按大小（见下面的算例）。优先选择完成定义就是一道检查的类型：一个必须通过的失败测试、一条 lint 规则、一次必须构建成功的依赖升级。
5. 把路由规则写下来，并用代码强制执行：哪些任务类型无人值守地运行，谁评审什么，什么情况会把拉取请求退回完整评审。然后实际演练一次暂停。
6. 第一天就开始 90 天对比。L3 要求把智能体工作的逃逸缺陷或事故与人工基线比较。dotnet 的回退数据，即 535 个已合并智能体拉取请求中 3 个被回退（0.6%），其他 4,251 个中 33 个（0.8%），是我们找到的唯一公开的智能体与非智能体回退对比（4,251 个中含 666 个机器人拉取请求），而文章自己也说两者差异没有统计意义。你的样本会更小，所以要尽早开始计数。

算例：任务类型与任务大小

dotnet/runtime 针对同一批智能体拉取请求，分别公布了按类别和按大小的成功率。两相对照，就能看出该按哪个维度挑选 L3 候选。

dotnet/runtime agent PRs, May 2025 - Mar 2026 (success = merged / (merged + closed))

BY TASK TYPE                     BY SIZE (lines changed)
cleanup        84.7%  (77)       1-10         80.0%  (160)
testing        75.6%  (99)       11-50        76.9%  (195)
refactoring    69.7%  (86)       51-100       75.0%  (104)
bug fix        69.4% (317)       101-500      64.0%  (197)
feature        64.5% (131)       501-1,000    68.2%   (44)
performance    54.5%  (46)       1,001+       71.9%   (32)

spread by type:  84.7 - 54.5 = 30.2 points
spread by size:  80.0 - 64.0 = 16.0 points
(omitted: documentation, upgrades, "other"; 0-line PRs with no change)

按任务类型，成功率的分布宽度约为按大小的两倍，而且大小曲线甚至不是单调的：超过 1,000 行的最大一批拉取请求回升到 72%，文章的解释是"可能因为这些往往是范围划定得很仔细的机械性任务"。文章的总结是"任务范围比大小更重要"。就这个代码库而言，清理和测试是 L3 候选，性能优化无论改动多小都留在 L2。一个 500 行的机械性清理，比一个 20 行的性能微调更适合作 L3 候选。这些数字只属于一个代码库、一个智能体、十个月。在提升任何任务类型之前，先算出你自己的表；能迁移过来的是排序，而不是百分比。

从 L3 到 L4：还不到时候

没有公开记录表明有人对某个任务类别自动合并 LLM 编写的代码。如果你要尝试，模型的 L4 条件全部适用：一个枚举出的、可逆的类别；有文档的验证记录；带自动回退的持续监控；一位具名的责任人；定期抽样审计。最窄也最诚实的候选，是你的确定性工具如今已经在自动合并的某个变更类别，由 LLM 只处理长尾部分。这种模式属于维护与迁移一章。

护栏

编码阶段的护栏，主要关乎智能体在哪里运行、能自己批准什么，因为不管团队怎么打算，这些设置都会决定级别。规则 2 在这里最见分量。一个在笔记本上以跳过权限确认模式运行、又握着生产凭证的智能体，对这些凭证够得着的一切而言就处于 L4。各级的权限边界由安全、权限与爆炸半径一章负责，下面是编码团队需要自己配置的那一部分。

• 集中锁定权限模式。Claude Code 的权限文档（截至 2026 年 10 月）对 bypassPermissions 的说明是："只在容器或虚拟机这类 Claude Code 无法造成破坏的隔离环境中使用此模式。"管理员可以在托管设置中禁用绕过模式和自动模式，"在那里它们无法被覆盖"。OpenAI 的 Codex 文档（截至 2026 年 10 月）默认"没有网络访问，写权限仅限于当前工作区"，并把完全访问标志 --dangerously-bypass-approvals-and-sandbox 标注为"（不推荐）"。在沙箱之外，要靠政策关掉这些模式，而不是靠约定俗成。
• 别把审批提示或允许清单当作边界。Anthropic 的自动模式技术文章报告，用户批准了 93% 的权限提示。它的自动审批器在 52 个精选的真实"过度积极"操作中漏掉了 17%，其中包括"试图对生产数据库执行迁移"。Claude Code 的文档也说，一条 Bash 拒绝规则"并不是围绕该程序的安全边界"。
• 强制性规则写进钩子，而不是写成文字。"与只是建议性的 CLAUDE.md 指令不同，钩子是确定性的，能保证动作一定发生。""绝不修改 migrations 目录"应该是一个阻止写入的钩子。详见本站的生命周期钩子与运行框架配置。
• 让判据在智能体够不着的地方。智能体不能修改测试、CI 配置或给它打分的那个钩子。这就是判据原则，成熟度模型给出了智能体会钻它够得着的东西的空子的证据。本书的提议：测试文件和 CI 文件必须经人类代码所有者评审，并且智能体的身份不在所有者名单上。
• 智能体运行的地方不放生产凭证。Stripe 让开发机与生产环境和互联网隔离，Anthropic 把 git 凭证放在沙箱之外。两者都把边界放在环境里，模型犯错也越不过去。

指标

按任务类型测量，并为每个速度指标配一个能显示它是否适得其反的指标。完整的指标集和回退触发条件由第 17 章《衡量成功与何时回退》负责，下面是编码阶段特有的几项。

• 按任务类型的成功率：已合并 ÷（已合并 + 已关闭）。决定能否从 L2 升到 L3 的就是这个数。
• 未经修改合并的比例：已合并的智能体拉取请求中，没有再追加提交就合入的比例（开源项目中 Claude Code 为 54.9%）。它把"被接受"与"人补完之后被接受"区分开来。
• 人工共同提交比例：人向智能体分支推送提交的频率。救援比例高，就意味着处在 L2，不管合并率多少。
• 评审负担：每个已合并智能体拉取请求的评论数（dotnet 为 16.5 对 12.4）和评审者分钟数。编码智能体的成本就落在这里；如何控制它，见代码评审一章。
• 每个拉取请求的 CI 轮数。Stripe 把它限制在两轮。轮数上升是一个早期信号，说明智能体在反复试探检查，而不是满足检查。
• 与人工基线对比的回退和逃逸缺陷：以上所有指标的稳定性配对，也是进入 L3 的要求。
• 每个已合并变更的成本，包含评审者时间，按经济学一章的方法计算。

方法上有两条规则。不要凭一次运行来评判指令文件的修改、模型的更换或运行框架的变化；在 AAIF 的测试里，单次运行的结果就被五次运行推翻了。也不要把"AI 编写的代码占比"或拉取请求的原始数量当作结果来报告；Stripe 的每周一千个只说明规模，别无其他。Thoughtworks 技术雷达（第 34 期，2026 年 4 月）把"以编码吞吐量衡量生产力"放进了"谨慎"环："工程师提交塞满了未经充分评审的 AI 产出的 PR，周期时间随之变长。"它建议改用首次通过接受率作为领先指标。这是从业者的观点，不是测量，但它指向的东西与上面的未经修改合并比例相同。

反模式

在工作站上开自动批准。三份公开报告是同一个形状。在 Gemini CLI 第 4586 号 issue（2025 年 7 月）中，一位用户报告，让 CLI 整理一个文件夹之后，自己的文件丢了。AI 事件数据库的概括是：CLI 把一条失败的建目录命令当作已经成功，随后的移动操作"覆盖了除一个之外的所有文件"。在 Claude Code 第 10077 号 issue（2025 年 10 月）中，一位用户报告一条 rm -rf 删除了自己的主目录；报告者称没有使用跳过权限的标志，这一点在讨论串中受到质疑，也未经证实。另据 TechRadar（二手来源，2025 年 12 月）报道，一位开启了自动执行"Turbo"模式的 Google Antigravity 用户，在要求清理项目缓存后丢失了整个磁盘。三者都是单个用户的陈述，没有厂商给出的根因，本书也不据此对任何工具下结论。要看的是模式：一个可以在无人看到的情况下执行破坏性命令、又运行在没有边界的机器上的智能体，对这台机器而言就处于 L4。没有人选择这个级别，是一个设置选的。

过度详尽的指令文件：又长、又是智能体自己生成的、还逐个文件地描述代码库。ETH 的研究发现，这类文件只增加成本，不提高成功率。Thoughtworks 技术雷达把"智能体指令膨胀"列在"谨慎"环："指令越长，重要规则被忽略的可能性越大……研究表明，人工编写的版本往往比 LLM 生成的更有效。"删减它，把强制性内容移进钩子。

不界定范围就放手：把真实但定义松散的工作交给无人值守的智能体，然后等待。Answer.AI 对"什么做成了"的评语就是警告："它能完成的任务，都小到、明确到我还不如自己动手，更快，也按我的方式来。"先给任务类型命名，再给运行设上限。

没准备好代码库就评判模型。一个把智能体丢进构建连包源都访问不了的代码库的试点，测的是防火墙，不是智能体。dotnet 第一个月只有 41.7%，这足以让许多试点就此收场；而同一个智能体后来跑到了约 71%。第 14 章《90 天试点》把环境准备作为得出任何结论的前提。

凭一次运行下结论。在 AAIF 的多文件任务上，两种条件各跑一次得出慢 44%，跑五次却变成中位数快 9% 到 10%。运行之间的波动比多数团队想要测量的效应还大；方法见本站的评估编码智能体手册。

编码跑在评审前面。评审还在 L1，就把编码提升到 L3，无人值守的运行只会变成一条没人读的队列。如果智能体开拉取请求的速度快于评审者关闭它们的速度，下一笔投入应该给代码评审和测试，而不是更多的智能体。