评估你的起点

哪些东西不该数

常见的起手问题是：多少工程师有许可证、装了哪些工具、大家是否觉得变快了。这些问题没有一个能告诉你级别，而且每一个都会往高处偏。

使用率已经分不出团队高下。在 DORA 2025 年的调查中，近 5,000 名受访者里有 90% 在工作中使用 AI，超过 80% 表示 AI 提升了他们的生产力。当几乎所有人都回答"是"，"你用 AI 吗？"这个问题就区分不了处在 L1 的团队和处在 L3 的团队。

许可证也不等于使用。在 Microsoft、Accenture 和一家《财富》100 强公司进行的三项现场实验，覆盖 4,867 名开发者，随机让其中一部分人使用一款 IDE 内置的代码补全助手。采用率"在三项实验中都明显低于 100%，约有 30%–40% 的工程师甚至没有试用过这个产品"（Cui 等人）。席位数衡量的是采购，不是实践。

自报不是证据。成熟度模型的规则 7 讲清了原因：用了 AI 后实测变慢的开发者，事后却相信自己变快了；而随着经验增加，全程自动批准的会话占比也在上升。团队对自身级别的感觉会随着放心程度一起上涨。一份建立在"大家感觉如何"的调查上的评估，记录下的是这份放心，而不是级别。

全组织一个分数会掩盖差异。是否愿意使用 AI，在不同阶段差别很大。在 Stack Overflow 2025 年开发者调查中，在回答该问题的人中，28.9% 不打算用 AI 写代码；对于提交与评审代码，这一比例是 58.7%；对于项目规划是 69.2%；对于部署与监控是 75.8%。能力在不同任务之间也参差不齐，这就是本站所说的锯齿状前沿。所以评估的单位是阶段以及阶段内具名的任务类型，绝不是整个组织。

四项读数

对每个阶段、以及其中每种反复出现的任务类型，在最近 30 天或 90 天的窗口内取四项读数。每项读数都指向一件持怀疑态度的人可以打开核查的东西。下表是本书的提议，由成熟度模型的规则组合而成。没有任何已发表的研究用结果验证过这套流程。

把这些读数与成熟度模型中的两条规则结合起来。第一，级别取评审读数与凭据读数中较高的那个。一个令牌能部署的智能体，对该令牌所及的一切都处在 L4，不管团队怎么称呼它。第二，声称处于 L3 或 L4、却没有一个智能体够不着的核验器，一律记为 L2。风险上限不改变级别，它标出级别最多能到哪里，并标记出已经越线的行。

凭据读数是分数最常上调的地方，也是团队了解得最少的一项。第 12 章《安全、权限与爆炸半径》迁移步骤的第 1 步给出了盘点流程。本站关于智能体清单的页面解释了为什么靠自行申报的清单，恰恰会漏掉你最需要找到的那些智能体：行之有效的清单，是从每个智能体都必须拥有的凭据、路由和预算条目中推导出来的。

把结果记进自评表模板，每个阶段和任务类型一行，并在该行写明所引用的证据。用意见而非产物作依据的行，只按其产物能支撑的最高级别打分。

逐个阶段看什么

第二部分的每一章都定义了本阶段的阶梯以及进入下一级的准入标准。判据以该章对应的网格行为准；下面每一条，是最常改变分数的那项读数。

• 需求与设计（第 5 章《需求、规格与设计》；需求网格、设计网格）。被委派任务类型的每一份规格，是否都有具名的批准？其验收标准是否已冻结，使负责实现的智能体无法修改？对这个阶段的两半，公开记录中都没有 L3 的结果证据。
• 编码（第 6 章《编码》；网格）。智能体的拉取请求是否有署名、是否按任务类型跟踪？是否通过托管设置禁用了绕过模式和自动批准模式？一台运行在跳过权限确认模式下的开发机，就是一次没有记录的授权。
• 评审（第 7 章《代码评审》；网格）。有没有哪个机器人能批准合并？路由是否在合并系统中强制执行、且任何智能体都改不了？现在就记录等待时间、实际评审时间和未经评审的合并；它们是之后每一次攀升的基线。
• 测试（第 8 章《测试与验证》；网格）。对每种测试任务类型，谁能修改判据？统计删除、跳过或削弱测试的智能体 diff。一个没有测试的代码库，没有可供攀升的核验器。
• CI/CD（第 9 章《CI/CD 与发布》；网格）。哪些流水线作业运行着智能体、它们持有哪些密钥、智能体参与过的变更是否强制关闭了自动合并。一个一边读 issue 文本、一边持有发布令牌的 CI 智能体，就是一条危险行。
• 运维（第 10 章《运维与故障处理》；网格）。运维工具是只读，还是会动手？列出它的凭据，包括躺在文件里的令牌，并检查它能执行的缓解操作中有没有缺少撤销路径的。
• 维护（第 11 章《维护与迁移》；网格）。哪些反复出现的变更类别，已经有一套在智能体够不着的地方运行的构建与测试？确定性的 codemod 和更新机器人，无论多么自主，都按"对 AI 而言是 L0"打分。
• 安全，横跨所有阶段（第 12 章《安全、权限与爆炸半径》）。有没有智能体能改写自己的权限文件、MCP 配置、规则文件或指令文件？有没有智能体能触及生产环境？每一个"有"，都要先于网格中的其他任何项打分。

找出约束

四项读数告诉你每个阶段处在哪里，却不告诉你该在哪里攀升，因为只有缓解了工作排队的那个阶段，攀升才会有回报。第 1 章《当代码变便宜，瓶颈就会转移》引用了 DORA 的价值流示例：一个通过绘制价值流发现评审是瓶颈的团队，应当把 AI 用在评审上，"而不是用 AI 生成更多代码，那只会加剧瓶颈"。DORA 的后续指南（2025 年 12 月）称 AI 采用是"一场组织变革"，并建议做价值流图，使收益"不只是制造出在下游堆积工作的局部优化"。

用你手头已有的数字来画这张图，而不是凭研讨会上的印象。从工单到生产的每一步，在与读数相同的窗口内，分别记录工作等待了多久、被实际处理了多久。等待占主导的那个阶段就是约束。那一章的证据首先指向评审，其次是测试与发布，但最终以你自己的图为准。然后对照规则 6检查——这是一条经验法则，也是本书的提议：如果编码比评审与测试中较低者高出两级或更多，预计图上会在这两个阶段前出现队列，应先提升这两个阶段。

知道约束在哪里，会以两种方式之一改变试点。能缓解约束的候选——比如评审正是队列所在时，在 L2 运行、以精确度为先调优的 AI 评审——可以凭自身价值推进。会加重约束的候选——比如一个向同一条评审队列送入更多拉取请求的智能体——仍然可以推进，但它的产出必须限制在约束能消化的范围内。Google 的 JUnit 迁移团队正是这么做的：为了不压垮评审者，它限制了每周送出的变更列表数量（见同一章的阶段层面证据）。

读懂分数背后的团队

同样的分数，放在不同团队身上含义不同，因为用 DORA 的话说，"AI 的首要角色是放大器，放大一个组织既有的长处与短处"（DORA 2025 年报告）。报告给出了一种看清团队带着哪些长处与短处的办法。它对八个因素（团队绩效与产品绩效、交付吞吐量与不稳定性、个人效能、有价值的工作、摩擦与倦怠）做了聚类分析，得出七种团队原型（第 15–18 页）：

• 基础性挑战（Foundational challenges），10%：各项指标"一贯偏低"，倦怠、摩擦和不稳定性都很高。
• 遗留瓶颈（The legacy bottleneck），11%："处于持续被动应对的状态，不稳定的系统主宰着他们的工作，并侵蚀着他们的士气。"
• 受流程所困（Constrained by process），17%："尽管所用的系统是稳定的，他们的精力却被低效的流程消耗殆尽，导致倦怠高、影响小。"
• 高影响、低节奏（High impact, low cadence），7%：产品绩效强，但"软件交付吞吐量低、不稳定性高"。
• 稳健有序（Stable and methodical），15%："以从容、可持续的节奏交付高质量、有价值的工作。"
• 务实的执行者（Pragmatic performers），20%："速度与稳定性令人印象深刻"，只是投入度尚未达到顶峰。
• 和谐的高成就者（Harmonious high-achiever），20%："稳定、低摩擦的环境"，交付"不以倦怠为代价"。

把原型当作诊断工具，而不是阶梯。它们描述的是团队如何工作，而不是团队的 AI 握有多少权限。其中两种会改变评估应给出的建议。在遗留瓶颈型团队里，不稳定的系统主导着日程，而放大器会放大这种不稳定；先让系统稳定、让回退可靠，才谈得上任何攀升。在受流程所困型团队里，系统是稳定的，流程却不是。往低效的流程里生成更多工作，只会让这台跑步机转得更快，所以上一节的价值流图是第一项交付物。

还有两项检查能让判断更准确。第一是代码库。斯坦福生产力研究组的"参考性"矩阵把棕地、高复杂度工作的收益定为 +0–10%，是该矩阵中最低的一格，不过同一页幻灯片的标题给出的是 5–10%（T3；第 4 章《经济性、风险与度量》给出了完整区间及其注意事项）。主要在这类代码上工作的团队，应当对任何攀升都降低预期。第二是前提条件。成熟度模型中列出的 DORA 七项 AI 能力，是要与分数并排检查的先决条件。批量大、版本控制实践薄弱、或没有明确 AI 政策的团队，应先补上这些，再提升级别。七项中有两项带有明确代价，所以要把它们记为权衡，而不是打勾了事的选项。

从分数到起点

评估的产出是每个团队一页纸，而不是一个成熟度数字。下面的顺序是本书的提议。

1. 先修危险行。凭据伸得比评审更远的每一行，都是一个没人选择过的级别。在讨论任何攀升之前，要么收回凭据，要么加强评审。修正后某个阶段的级别可能会下降；把它记为一次更正，而不是一次挫折。
2. 标出超过上限的行。把它们降到上限，或者写明是谁接受了这项风险、为什么接受。
3. 找出合格的候选。一种任务类型有资格攀升，需要满足：已经有一个智能体够不着的核验器，它的操作可以撤销，并且下一级不超过其风险上限。大多数行至少有一项不达标，这些不达标项就成了待办清单。
4. 对照约束给候选排序。优先选能缓解约束的。如果最好的候选会加重约束，就在试点开始前定好上限。
5. 只选一个。一个阶段、一种任务类型、一个团队。反复出现的维护工作通常排在最前面，因为编译器和测试套件就是现成的核验器。这正是第 11 章《维护与迁移》被本书推荐为第一级台阶的原因。

下面这张表仅作示意，不涉及任何组织。它展示了产出的样子，包括最佳候选会加重约束的情形。

ASSESSMENT SUMMARY (illustrative)                 window: trailing 90 days

PHASE        TASK TYPE            REVIEW  VERIFIER (AI can edit?)   CREDENTIALS     CEILING  LEVEL
-----------  -------------------  ------  ------------------------  --------------  -------  -----
Coding       feature work         L2      tests (yes, same branch)  dev token       L3       L2
Review       PR comments          L2      none                      comment only    L3       L2
Testing      unit tests           L1      none                      IDE only        L3       L1
CI/CD        release pipeline     L1      n/a                       prod deploy !!  L2       L4 !!
Maintenance  dependency upgrades  L2      build + tests in CI (no)  own branch      L3       L2

CONSTRAINT  review: wait time far exceeds active time
FIX FIRST   CI/CD agent token can deploy to prod -> remove; rescore at L1
HOLD        Coding stays at L2 until Testing rises (Rule 6)
CANDIDATE   Maintenance / dependency upgrades: verifier out of reach, reversible,
            within ceiling; feeds review -> cap open agent PRs per team
ALSO        Review at L2, precision-tuned, to relieve the constraint

候选行就是第 14 章《90 天试点》的输入。这里记录的基线（评审等待时间、回退、同一任务由人完成时的逃逸缺陷）就是试点的比较对象，也是第 17 章《衡量成效，以及何时回退》中回退触发条件的参照。每个季度重新评估一次。分数会随着放心程度向上漂移，所以每次都要重新要证据。如果由一个治理小组负责重新打分，本站的治理实践页面说明了如何让它与风险相称，而不是一刀切。附录 A《模板》收有一份空白自评表。