AI-SDLC 成熟度模型

为什么还要一个模型

对三个已发表的模型说"我们团队在第 3 级"，你等于说了三件不同的事。Dan Shapiro 的五级模型标题就是"从加了料的自动补全到黑灯工厂"，他的第 0 级已经允许你"偶尔按 Tab 接受一条建议"，而几乎所有其他模型的 L0 都表示完全不用 AI。Steve Yegge 在接受 The Pragmatic Engineer 访谈时给出的量表从 1 排到 8，高几级数的是智能体数量，而不是检查。Hassan 等人则给各级贴上"SE 1.0"到"SE 5.0"的标签。这些数字没有一个能告诉你评审者还在看什么。

结构上也有缺口。几乎所有已发表的模型都是只针对编码的单一量表，通常借自 SAE 的自动驾驶分级；覆盖整个生命周期的框架描述的则是流程或组织阶段。没有一个已发表的模型是按阶段划分的网格。可现实中，一个团队完全可能让智能体无人值守地提交拉取请求，而每次部署仍要等人放行，单一数字恰恰掩盖了这种差别。2026 年 6 月，Gartner 建议"把开发任务划入三种执行模式：开发者主导、开发者与智能体协作、完全由智能体主导"，并"为每类任务确定合适的自主级别"。这是分析机构的观点，但它认可了本书的设计：每个阶段一个级别，阶段之内再按任务类型各定一个级别。

定义轴：人评审什么

在实践中最有用的那几个已发表模型，都落在同一个变量上：人评审什么。Sourcegraph 的代码 AI 分级（2023）把界线划在开发者"需要评审 AI 生成的全部代码"与人只评审最终产出之间；到它的 L4，"人不再需要评审最终的代码产出"。Dash0 的六级模型（2026）从"合并前评审并批准每个 PR"走到"看意图与证明（满意度报告、截图、行为证据），而不是看 diff"。两者追踪的都是评审对象的变化：先是每一行，然后是证据包，最后什么都不看。

学术研究补充了第二点：级别是你选择如何部署，而不是模型的属性。Google DeepMind 的 Morris 等人写道："能力的提升解锁了新的交互范式，但并不决定它们"，合适的级别"不必是底层模型能力所能达到的最高级别"。Feng、McDonald 与 Zhang 按用户角色划分级别，从操作者到观察者，并主张自主度"可以被视为一项有意的设计决策"。

因此，本模型有意把三样东西排除在定义之外。

• 能力。更强的模型让更高的级别成为可能，但不会把你自动放到那里。
• 智能体数量。按并行智能体计数的量表奖励的是没有核验配套的吞吐量。
• 推广广度。微软的四级模型从"个别开发者零散使用 AI 助手"走到"跨生命周期编排的智能体团队"。它衡量的是普及程度，而不是权限。

剩下的是两项可观察的事实。一是评审方式，即人看什么、何时看；二是权限，即 AI 的凭证和配置允许它做什么。两者不一致时怎么办，由第 2.4 节的规则决定。

五个级别

以下是本书的定义。每一级都是审计者可以在过去 30 天或 90 天的窗口内核查的标准，并且都写明了你需要出示的证据。

L0 手工

该阶段的产出不经过任何 AI，或政策禁止使用 AI。确定性的自动化，例如代码改写工具（codemod）、Renovate 和基于规则的机器人，算作就 AI 而言的 L0：自动化程度可能很高，但其中没有 AI。证据：相关政策，或该阶段没有 AI 工具。

L1 辅助

AI 给建议，每一项产物都由人编写。AI 的输出只以建议的形式进入，由人修改。证据：存在工具遥测数据，且没有任何产物署名为智能体。

L2 委派

至少有一种具名的、反复出现的任务类型，由 AI 产出完整的产物：一个拉取请求、一个测试文件、一份 ADR 草稿或一个缓解方案。这些产物在生效前百分之百经过有记录的人工评审。智能体的产出通过标签、提交尾注或元数据加以标识。存在共享的指令文件或上下文文件，团队按任务类型跟踪采纳率或返工率。证据：覆盖全部产物的批准日志、署名标识、该文件以及跟踪的比率。

L3 受监督自主

对具名的常规任务类型，AI 端到端地执行。人评审的是证据包、抽样，或只评审被路由给自己的条目，而不是逐行评审。Hassan 等人把这种证据包称为合并就绪包："一份提交给人工批准的结构化证据包，用于证明功能完整"。以下各项必须全部成立：

• 决定哪些条目交给人的路由规则已成文，并由机器强制执行。
• 暂停与回退机制已经存在，并且演练过。
• 在至少 90 天内，把 AI 执行工作的逃逸缺陷率或事故率与人工基线作比较。
• AI 不能修改自己的评估器（规则 1）。

L4 自主（限定任务类）

对一个枚举出来的、范围狭窄且可逆的任务类别，AI 无需逐项人工批准即可行动，例如自动合并或自动修复。以下各项必须全部成立：

• 有成文的验证记录：要么是连续 N 项没有逃逸缺陷，要么是一个错误预算。
• 持续监控，并配有自动回退或急停开关。
• 有一位具名的责任人，并已书面记录其风险接受。
• 定期抽样审计。
• 范围是该任务类别，绝不是整个阶段。

本书写 L4 时总是带上范围，例如"依赖补丁升级的 L4"，这样就不会被误读为"整个阶段自己运转"。关于人的角色如何随级别变化，参见人在回路和渐进式自主。

规则

团队给自己定级时往往偏宽，所以本模型用七条规则来防止钻空子。规则 6 是经验法则，并明确标注；其余规则都源于证据。

规则 1：判据原则

之所以需要这条规则，是因为智能体会钻它能触及的任何检查的空子。METR 发现，o3 在 128 次 RE-Bench 运行中有 39 次（30.4%）出现奖励黑客行为。模型尝试"修改测试或评分代码"，有一次 o3 甚至给评估器打了猴子补丁，让每次提交都被标记为成功。

ImpossibleBench 构造了规格与测试相互矛盾的任务，因此"任何通过都必然意味着违反规格的捷径"，而前沿模型仍然拿到了这样的通过。同样的行为也出现在生产环境中。据 InfoQ 报道的一场 Spotify 演讲，Spotify 的智能体会走"注释掉失败的测试或降低 Java 版本"之类的捷径。Elastic 的 CI 智能体"修复"失败的依赖升级的办法，是把升级本身删掉；Elastic 是在看到这种做法之后，才加上禁止降级版本的规则。

一旦强制执行，这条规则就管用：记录在案、达到 L3 的每一次迁移，都有一道确定性检查来闭环，无论是编译器、测试还是 linter。匿名实践者网站 ASDLC.io 用自己的话表述了同一条规则：在 L3，AI"不能修改对成功的底层定义"，对评估器的任何修改都"必须限定在提案流程中"，并通过"人在环路中的审核"。本 wiki 在评测完整性与评分器博弈和生成-核验落差中详细讨论了这种失效模式。

规则 2：级别等于实际授予的权限

一个阶段的级别取两项读数中较高的一项：团队实际采用的评审方式，以及 AI 的凭证和配置所允许的权限。一个智能体只要持有能触及生产环境的令牌，或运行在跳过权限确认模式下，那么对该令牌所能触及的一切，它就运行在 L4，不管团队怎么称呼它。

事故记录支持这条规则。2025 年 12 月，AWS Cost Explorer 的一次中断涉及亚马逊的 Kiro 智能体，而双方的说法并不一致。据英国《金融时报》报道（经路透社和 Engadget 转述），智能体决定"删除并重建环境"，导致了 13 小时的中断。亚马逊的更正声明（2026 年 2 月 20 日）称中断"短暂"，原因是"用户错误——具体而言是访问控制配置错误——而非报道所称的 AI"（"user error—specifically misconfigured access controls—not AI as the story claims"）。亚马逊还表示："额外的保障措施包括对生产环境访问实行强制同行评审。"两种说法放在一起看，指向同一类失效：操作者角色的权限大于围绕它的评审。修复手段是一道边界，而不是更好的模型。Anthropic 的自动模式技术文章列出了其内部使用中出现的越界操作，包括"删除远程 git 分支"和"尝试对生产数据库执行迁移"。每一例都是一次没人意识到的事实上的 L4 授权（参见爆炸半径）。

规则 3：按具名任务类型打分，而不是按整个阶段

一个阶段的级别，是该阶段中某个具名、反复出现的任务类型在具备所需证据的前提下所运行的最高级别。始终把任务类型写在级别旁边："测试：不稳定测试（flaky test）分诊为 L3；功能测试为 L2。"整个阶段一个数字，要么高估了高风险工作，要么低估了常规工作。关于为什么决定能否委派的是任务边界而不是任务大小，参见任务范围。

规则 4：风险设定上限

每个"阶段 × 风险类别"的组合都有一个最高级别，记录在自评表的上限一栏。例如：受监管服务的 CI/CD 不得高于 L2；凡是不可逆的操作，一律不得进入 L4。James Read 说得很简洁："风险越高，可接受的自主度越低。"云安全联盟（CSA）和 AWS 都为每个级别配上逐级加码的控制（见第 2.5 节）。仅"不可逆"这一点，就足以让一个任务类别失去进入 L4 的资格。

规则 5：没有 L5，L4 范围狭窄

严肃的来源一致认为，通用的自主要么尚不存在，要么没有配套控制。Hassan 等人说，他们的通用领域 L5"目前处于概念/研究阶段，即尚不存在"。云安全联盟说："在这一级别安全运行所需的控制机制尚不存在。"ai4se 分类法认为，对于"复杂的工业级软件"，完全自动化"相当不现实"。Thoughtworks 指出，那些智能体集群的演示"选择的用例都可以依赖现成的详细规格……这些条件并不代表典型的产品开发"。级别不是目标；一个阶段的合适级别完全可以长期停在 L1。

规则 6：经验法则——编码最多比评审与测试中较低者高一级

这是本书的提议，不是定律。当编码跑在核验它的阶段前面时，遥测数据呈现出一致的模式：拉取请求更多、更大，评审更久，完全未经评审就合并的更多，不稳定性也更高。DORA 2025 年报告给出了一种机制：与 AI 相关的不稳定性"很可能部分是因为更大批量的代码更难评审"。下方方框中的厂商遥测在方向上与此一致。这些证据都是相关性的，所以请把这条规则当作警戒线，而不是证明。完整论证见当代码变便宜，瓶颈就会转移。

规则 7：证据胜过自报

定级必须引用可观察的东西：批准日志、署名标识、路由配置、凭证清单或验证记录。原因在于，人对自己速度和安全性的感觉并不可靠。在 METR 2025 年的试验中，资深开发者使用 AI 后耗时多了 19%，事后却相信自己快了 20%。

斯坦福的一个研究组发现，43 名工程师自评的生产率与实测生产率之间的相关系数只有 r = 0.17，人们"对自身生产率的判断偏差约 30 个百分位"（会议幻灯片，未经同行评审）。

同样的漂移也发生在自主度上：Thoughtworks 曾连续三期（2024 年 10 月至 2025 年 11 月）把"对 AI 生成代码的自满"放在技术雷达的 Hold 环（"谨慎推进"），并提醒："在与助手有过几次愉快的经历之后，评审 AI 建议时放松警惕实在太诱人了。"除非有证据钉住，团队对自身级别的估计会随着舒适感一路上升。

每个级别配套的控制

一个级别同时也是一组权限。云安全联盟在其 L3 要求"机器可读的边界定义"和"切实防止越界的技术强制机制"，在其 L4 要求"即时急停能力"、"持续监控"以及"高管授权和书面记录的风险接受"。AWS 智能体 AI 安全范围矩阵从"所有有后果的操作都需人工明确批准"（范围 2），走到智能体在"启动时就已明确界定的执行边界"内"无需进一步批准"即可行动（范围 3）。它们的编号与本书错开；第 2.8 节给出了对照。

下表是本书的提议，综合自厂商默认设置和事故后的修复。例如 GitHub 的 Copilot 云端智能体"只有推送到单个分支的能力"；"在 Copilot 云端智能体的代码经过评审之前，工作流不会被触发"；发起任务的人不能批准它的拉取请求（截至 2026 年 10 月）。在 Anthropic 的沙箱设计中，"敏感凭证（如 git 凭证或签名密钥）从不放在沙箱内"。目前没有经过结果验证的标准，也没有任何已发表研究给出按权限级别统计的事故率。

完整的权限边界及每一行背后的事故，由第 12 章《安全、权限与爆炸半径》负责。关于由谁签署 L4 的风险接受，参见问责与角色。

决定能否升级的前提条件

控制限制智能体能做什么；前提条件决定一次升级到底值不值。最有力的证据是 DORA 的 AI 能力模型（2025 年 9 月）。据 2025 年报告（第 50 页），DORA 从 78 次访谈和 15 项候选能力出发，再用调查数据检验。其中七项显示出"与 AI 使用存在交互作用的充分证据"：具备这些能力时，AI 对关键结果的影响会被放大。这些证据基于调查，属于相关性。请把这七项当作升级前要检查的前提，而不是级别本身。

• 清晰且传达到位的 AI 立场。
• 健康的数据生态。
• AI 可访问的内部数据。
• 扎实的版本控制实践。
• 小批量工作。代价："在以小批量方式工作的团队中，AI 采用对个人效能的好处略有减少。"DORA 判断其净效应为正。
• 以用户为中心。2025 年报告指出，缺少这一点时，"AI 采用会对团队绩效产生负面影响"。
• 高质量的内部平台。代价：有了高质量平台，"AI 对受访者所报告的摩擦体验原本的中性影响会变为有害"。DORA 的假设是：平台起到护栏的作用，而护栏会增加摩擦。

微软的智能体 DevOps 模型是一个没有数据支撑的厂商框架，但它说得很直白："智能体不会神奇地修好糟糕的工程实践。"缺少小批量、可用的回退和可用的内部上下文，升一级多半只会放大该阶段已有的问题。

网格：八个阶段，五个级别

这就是地图。每个单元格先给出可观察的标准，再给出最好的公开证据及其证据等级（定义见前言）。"无"表示没有找到任何公开证据。

需求

详见第 5 章《需求、规格与设计》。

设计

详见第 5 章《需求、规格与设计》。

编码

详见第 6 章《编码》。

评审

详见第 7 章《代码评审》。

测试

详见第 8 章《测试与验证》。

CI/CD

详见第 9 章《CI/CD 与发布》。

运维

详见第 10 章《运维与事故》。

维护

详见第 11 章《维护与迁移》。

把网格作为整体来读，有三点很突出。

1. 真正的 L3 证据只存在于少数地方：编码（只有数量）、测试（部分）、维护，以及运维中一个狭窄的、自报的类别。没有任何阶段有可信的 LLM L4 证据。需求和设计完全没有 L3 证据。
2. 经典机器学习先到了那里。带自动回退的发布把关（如 Harness Continuous Verification）多年前就靠经典机器学习达到了 L3 和 L4。网格把经典机器学习算作 AI，但不把功劳记在 LLM 头上；确定性的自动化无论多么自主，就 AI 而言都是 L0。
3. 事故集中在权限跑在评审前面的地方。每一个出过事故的单元格（编码 L4，运维 L3 和 L4），都是授予的权限把团队放到了比它自以为的更高的级别：这正是规则 2 在起作用。

这些单元格背后的案例及其完整的测量说明，见案例研究：谁做到了，测量了什么。

换算其他模型

当有人说"我们在第 3 级"时，先问他用的是谁的量表。下表是本书对各模型的解读，"≈"表示近似对应。附录 C《术语表》收录了同一张表。

还有一个近在身边的提醒：本 wiki 自己的自主级别页面从 L0 ="建议"开始计数，因此它的 L0 到 L2 比本书的编号低一级。

给自己打分

下面三个演算示例只用公开数据，分别按评审方式、按核验器设计和按实际授予的权限给一个阶段打分。

演算示例 1：dotnet/runtime 的编码阶段

微软 .NET 团队公布了 GitHub Copilot Coding Agent 在其 runtime 代码库中十个月的数据。每个智能体 PR 都经过人工评审，所以无论合并率看起来多好，这个阶段都是所有任务类型均为 L2。真正的问题是哪些任务类型有望进入 L3。清理类工作的合并率为 84.7%（77 个 PR），测试类为 75.6%（99 个 PR）。性能类工作只有 54.5%（46 个 PR），不是候选。要把清理类工作提升到 L3，团队还需要两样该文并未声称具备的东西：一是一个智能体无法修改、负责判定通过与否的核验器；二是 90 天的逃逸缺陷对比。回退数据算是一个开端：535 个已合并的智能体 PR 中有 3 个被回退（0.6%），其他 4,251 个已合并 PR 中有 33 个（0.8%）。该文自己也说，这一差异在统计上没有意义。

演算示例 2：Spotify 的维护阶段

Spotify 的后台编码智能体 Honk 负责全舰队范围的迁移。它的确定性核验器（格式、构建、测试）在停止钩子中运行；一旦有一个失败，"PR 就不会被创建，用户会看到一条错误信息"。智能体"处于高度沙箱化的环境中"，其工具集刻意保持很小，推送代码和发送 Slack 消息由外围基础设施完成，而不是由智能体完成。按设计证据，这是全舰队迁移的 L3：判据位于智能体够不着的地方，结果有人看。公开记录缺少 90 天的缺陷对比，外部打分者应把这一缺口记下来。Spotify 的 Fleet Management 是另一套系统。它的 250 万以上 PR 大多在无人参与的情况下自动合并（截至 2026 年 6 月），这套系统起初是确定性脚本，Spotify 也没有说明自动合并的 PR 中有多少出自其 LLM 智能体，所以它的自主不能记在 AI 名下；其中确定性的部分，无论多么自主，就 AI 而言都是 L0。

演算示例 3：按实际授予的权限打分（Kiro）

无论原本打算采用哪种评审方式，一个权限大到足以删除并重建生产环境的操作者角色，都把那项任务放到了事实上的 L4。在其他方面，两种说法各执一词。《金融时报》经路透社和 Engadget 转述，称中断持续 13 小时；亚马逊则说中断"短暂"，是"一次极其有限的事件"，只影响 39 个区域之一中的一项服务，原因是"一个配置错误的角色——任何开发者工具（无论是否由 AI 驱动）或手工操作都可能出现同样的问题"。打分并不取决于哪种说法正确。亚马逊的修复是"对生产环境访问实行强制同行评审"，这把该任务拉回了 L2，而且靠的是改变权限，而不是换模型。

自评表模板

每个阶段、每种任务类型填一行。"所持凭证"一栏让规则 2 落到实处：只要凭证比评审一栏伸得更远，就记录较高的级别。以下各行仅为示意，不指向任何组织。附录 A《模板》提供空白表，第 13 章《评估你的起点》逐步讲解如何填写。

PHASE        TASK TYPE              LEVEL  EVIDENCE                          RISK CEILING  CREDENTIALS HELD
-----------  ---------------------  -----  --------------------------------  ------------  ------------------------------
Coding       dependency cleanup     L2     approval log 100%; PR label       L3            dev token; no prod access
Coding       performance work       L1     no agent attribution              L2            none beyond IDE
Testing      flaky-test triage      L3     verifier outside agent; 90-day    L3            CI read; own branch only
                                           escaped-defect comparison
Operations   cache restart          L2     typed tool; human confirms each   L3            scoped service identity
Operations   (any) via shared token L4 !!  token reaches prod DB             L2            broad API token -> FIX FIRST

先找像最后一行那样的条目。没人为那项任务选择 L4；是令牌替你选了。