AI 研发基建怎么度量
给团队接上编码 Agent、沉淀了一批 Skill 和规则、把内部系统包成 MCP 工具链之后，接下来的问题一定是"这到底有没有用"。而这个问题最容易判断错，因为 AI 会把所有产出侧的指标一起拉高——提交数、PR 数、代码量，全都是绿的，但速度之外的东西没人看。
这篇讲该测什么、不该测什么，以及为什么几乎每一条指标都必须成对出现。
1. 先说不该测什么
代码行数。 更多代码不是更多价值，是更多要评审、要测试、要维护的表面积。AI 极其擅长产出更多代码，这本身可能是负担。
建议采纳率。 它测的是"有人按了 Tab"，不是这段代码有没有上线、有没有活过评审、下个迭代有没有被改掉。采纳率是厂商指标，因为它永远好看。而且开发者经常先接受再重写，数字只会更虚。
坐席数与功能开通率。 这是采购指标，不是生产力指标。买了多少和有没有用起来是两件事。
自报节省时间。 自我报告和实测值是两个不同的变量，而 AI 会显著抬高前者。有对照实验出现过"开发者觉得快了、实测慢了"的结果。自报数据只能当佐证，不能当结论。
2. 该测的四层
第一层：交付是否真的变快。 用 DORA 那四项：部署频率、变更前置时间、变更失败率、恢复时间。它们的价值在于测的是端到端的流动，而不只是"写代码"这一段——而大多数团队的瓶颈从来不在打字速度，在评审、测试、协调、集成，这些恰恰是自动补全不碰的部分。
第二层：质量有没有跟着坏。 变更失败率、30 天内返工率、缺陷逃逸率，并且要按 AI 参与与否分开统计。不分组的话，AI 带来的质量变化会被人工代码的数字平均掉，你什么也看不出来。
第三层：人受不受得了。 满意度、认知负荷、心流状态。AI 会让输出变多，同时让"审一遍看似合理但其实是错的代码"成为高负荷工作——这一项很容易被低估。资深工程师的评审负荷要单独统计：如果他们每周多审 30% 的 PR，这是真实成本，而且它不出现在部署频率里。
第四层：有没有推动一个付工资的数字。 上线的功能有没有人用、事故有没有减少、新人上手时间有没有变短、工单有没有被拦掉。这一层是真正会被买单的，也恰恰是大多数汇报里缺的那一层。
3. 速度必须配质量，理由是 AI 会拆开它们
正常情况下速度和质量大致同向：做得糙，很快就出问题。AI 打破了这个耦合——它可以在质量不变甚至变差的同时，把产出侧拉得很高。
所以有一条硬规则：任何速度指标都不单独汇报。 前置时间配变更失败率，吞吐量配稳定性，AI 代码占比配 AI 代码返工率。只有前者改善，那不是收益，是把成本推到了下游——今天借的速度，下个季度用事故还。
4. 度量的对象是团队，不是个人
这一条是纪律问题，不是技术偏好。一旦把任何产出指标挂到个人身上，数据立刻失效：统计提交数，提交就变多；统计 PR 数，PR 就变小。而且它会摧毁第三层依赖的信任——没人会在一份会影响自己考核的问卷里说真话。
个人数据只在匿名聚合到团队级之后才有意义。
5. 基线怎么取
同一批人和自己的过去比，不要团队和团队比。 跨团队比较会被资历、业务域、季节性淹没。同一个人、启用 AI 前后对比，才能把 AI 的效应分离出来。
给 3 到 6 个月的学习期。 第二周测到的是生疏，不是能力。有效使用 AI 是一项技能，有学习曲线，而且常见的是先降后升的 J 形——提前把这个形状讲清楚，否则第一个月的数字会让人做出错误结论。
分阶段冻结基线。 模型版本、Skill 集合、工具链都会变。基线要标明是在什么配置下取的，否则你无法解释半年后的变化。
6. 研发基建本身也要有指标
前面讲的是"AI 有没有让团队变好"。另一件经常被漏掉的事：你搭的那套基建本身好不好用。沉淀了一批 Skill、规则、MCP 工具之后，至少要看四个数：
- 覆盖率：仓库里有多少比例的常见改动被规则或 Skill 覆盖到了
- 命中率：这些规则/Skill 实际被触发的比例。写了没人用，等于没写
- 误触发率：触发了但结果是错的、需要人工回滚的比例。这个数比命中率更重要，因为它直接决定开发者会不会开始习惯性忽略提示
- 护栏拦截数：人机确认挡下了多少次高危操作。这个数长期为 0 只有两种可能——要么没人用，要么护栏形同虚设
第三个数字是这套基建的生命线。一次误触发的代价远不止这一次：它会让开发者养成"先点允许再说"的习惯，而护栏一旦被习惯性绕过，就再也建不回来了。护栏的分级设计见《护栏要做在基础设施层》。
Skill 与规则的加载层数、什么时候该放进上下文，见《Agent Skills 三层加载》；工具集规模对命中率的影响见《工具有多少才合适》。
7. 一个最小可跑的看板
不需要一上来就铺满。下面这些从 CI 和代码托管里就能取，先跑两周：
交付 部署频率 / 变更前置时间中位数
质量 变更失败率 / AI 代码 30 天返工率 / 缺陷逃逸率
负荷 资深工程师每周评审 PR 数 / PR 首评等待时长
基建 Skill 命中率 / 误触发率 / 护栏拦截数
体验 季度匿名问卷：满意度、认知负荷、心流
其中"基建"那三行是很多团队完全没有的，而它们恰恰是你能不能持续改进这套东西的依据。
8. 好数字长什么样
一套真的跑通的 AI 研发基建，数据上会呈现一个特定形状，而不是"全线飘绿"：
- 前置时间下降，变更失败率持平或下降
- AI 代码占比上升，但 AI 代码返工率不高于人工代码返工率
- AI 辅助的 PR 合并周期快于纯人工
- 满意度持平或改善，认知负荷没有恶化
- Skill 命中率上升而误触发率持平
如果看到的形状是"产出涨了、返工率也涨了、评审负荷也涨了、满意度掉了"，那不是提效，是把工作量从写代码搬到了改代码——只是搬到了更难被发现的地方。
度量这件事做起来很枯燥，而且经常给出不好听的答案。但它是唯一能区分"真的变好了"和"看起来变好了"的手段，也是判断要不要继续投入的依据。这一条和测试那边的经验是同一个道理：覆盖率数字高不代表测对了（见《测试分层比覆盖率数字重要》），产出数字高也不代表真的提效了。