在 AI Coding 时代，当我们说提升效能 50%，从老板的角度，那应该要干掉 50% 的人。

但又不能真这么干，这是一个简单的财务逻辑，也是一种本能的反应。

但研发又不是完全标准化的流水线。AI 在各环节都有提速，但对于需求理解的一致性，线上兜底，发布治理这些环节没法完全同步提速。

人是可以砍，但最终系统脆弱性、技术债务和交付风险一起放大。

以 AWS 为例，公众知道的类似线上故障发生不止两次了。

并且在一些大的公司，也出现了开发人员不知道自己写的是什么的情况，对于大公司一套巨大的工程体系，如果是一个完全的黑盒，没有人知道里面发生了什么，出现大的问题只是迟早的事情。

聊远了点，回到今天的主题，如何有效的度量研发效能。

当我们用上 AI Coding 之后，在上面所说的整体提效的逻辑中，我们需要细化这个效能的度量逻辑。

同样规模的团队，能不能交付更多有效价值，能不能把交付周期压短，能不能在不明显增加事故和历史债务的前提下，把过去做不到的事情做起来。

从指标的逻辑来看，DevOps 里那套大家已经很熟的「四个指标」——部署频率、交付周期、变更失败率、平均恢复时间依然是很能打的一组指标。尤其是 TTM，也就是从需求进入系统到真正产生用户价值的时间，还是王牌指标。

AI 时代，研发效能的核心指标体系要刷新，但不能推倒重来。

整个度量的逻辑不仅仅在于指标，同时也在于到底把指标绑在什么对象上，怎么解释，怎么防止它们被 AI 放大之后失真。

度量谁

一个问题，AI 产出要不要单独度量？

建议是：可以记录，不要单独考核。

因为 AI 没有责任主体。它不会背 SLA，不会参加事故复盘，也不会在需求失败时承担后果。

如果我们把「AI 生成代码占比」或者「AI 采纳率」当核心 KPI，很快就会把团队带进一个很熟悉的坑：为了优化指标而优化行为，最后牺牲真实交付质量。

研发效能度量一定要有清晰主体。这个主体通常有三层：

• 工程师个体
• 团队
• 价值流或产品线

在 AI 时代，我更建议把主分析单位放在团队和价值流，但个体数据也需要通晒，人与人还是需要比较，并且人的实际使用情况也需要观测和度量。

说到个体度量，可能会有人觉得开始卷了，回到了粗暴管理

我觉得个体数据要看，并且要公开到一定程度。否则团队里谁在真正把 AI 用进生产，谁还停留在传统写法，谁能稳定地产出高质量变更，谁在用 AI 快速制造垃圾代码，管理层根本看不见，辅导也无从下手。问题从来不在于能不能比较，问题在于拿什么比较，以及比较之后准备用它干什么。

可以把「个体可观测」和「个体直接考核」分开。前者要做细，后者要克制。个体层的数据主要解决三类问题：第一，识别使用差异。第二，识别能力短板。第三，识别风险人群。比如有的人 AI 使用频率很高，但交付周期没有改善，返工率还在上升，这通常不是工具问题，是任务拆解、约束描述、结果校验出了问题。还有一种人，表面上 AI 使用不多，但需求稳定、事故极少、关键模块掌控力强，这类人往往承担了大量隐性复杂度，单纯看「人均产出量」会被严重低估。

所以个体层该看的，不是「生成了多少」，而是「借助 AI 之后，个人交付行为发生了什么变化」。可以重点盯几组数据：需求从领取到合并的中位时长、PR 平均大小、评审往返次数、回退率、线上问题关联率、测试补充情况、跨模块变更占比、AI 建议采纳后的修改幅度。这里面真正有价值的，不是某个数字本身，而是前后变化和人与人之间的分布差异。一个人 AI 采纳率高，不说明他强；采纳率高、评审一次过、上线后稳定，这才说明工具真的转化成了产能。反过来，另一个人采纳率也高，但 PR 越来越大、review 来回打架、上线后热修频繁，这种数据就已经在报警了。

个体数据为什么要通晒？

团队协作里，很多能力本来就是相对的。谁的需求吞吐稳定，谁总能把复杂变更压在可控范围里，谁的变更老是把测试链路打爆，谁对 AI 的依赖已经超过了校验能力，这些不能永远藏在「一团和气」后面。通晒的价值是建立真实参照系。工程团队里最怕的一种状态，是大家都觉得自己做得差不多，实际上产出质量、稳定性、问题密度差了一倍以上。数据如果不拉平，组织就只剩印象管理。

当然，个体通晒有前提。第一，口径必须统一。第二，不能只晒单一指标。第三，必须配上下文。比如一个人长期负责遗留系统改造，变更失败率高一点、交付周期长一点，很正常；另一个人长期做边缘功能，吞吐高也不稀奇。脱离任务难度做横向比较，最后一定会逼着大家抢简单活。我的经验是，个体层至少要把任务类型、系统风险等级、需求大小这几个维度一起带上。不然表面上是在做精细化管理，实际上是在奖励投机。

团队层和价值流层还是主轴，因为真正的交付结果最终只能在这两层闭环。一个工程师再强，也没法单独决定发布窗口、联调效率、测试环境、跨团队依赖和灰度策略。AI 时代尤其如此。代码写快以后，瓶颈更容易从个体编码能力转移到团队协作和系统机制上。所以如果一个团队整体 TTM 没降、变更失败率在升、MTTR 也没有改善，那就算团队里有几个人个体数据很亮眼，也不能说明这个组织真的变快了。很多管理者容易被「明星工程师 + AI」的局部高产迷惑，这是很危险的。效能度量最终看的是系统，不是看谁在局部冲得猛。

价值流这一层更关键，因为它决定了管理层看到的是局部繁荣，还是真实效率。一个需求从业务提出到用户可用，中间穿过产品、研发、测试、运维、合规、数据、客服，任何一个环节卡住，前面所有 AI 提速都白搭。很多团队以为自己效能不差，问题出在开发不够快；把价值流拉直一看，开发可能只占整个周期的 20%。剩下 80% 都耗在等待、确认、返工和协调上。这个时候你还在研究个人 AI 采纳率有没有上去，说实话，方向已经偏了。

所以，三层都要度量，但角色不同。

• 个体层，解决的是识别差异、暴露问题、推动辅导。
• 团队层，解决的是交付责任和工程能力。
• 价值流层，解决的是端到端效率和组织瓶颈。

如果非要再说得更落地一点，可以这样处理：

• 个体层数据全量采集，有限通晒，谨慎用于绩效
• 团队层数据作为正式经营指标，进入月度复盘
• 价值流层数据进入管理层决策，用来推动跨部门改造

这里还有一个问题：AI 使用情况本身，确实会逐渐演化成个体能力差异的一部分。今天还可以说是工具习惯差异，再过一段时间，它会越来越接近工程生产方式差异。有人能用 AI 快速完成问题拆解、方案比选、代码生成、测试补全、文档整理，再自己完成严格校验；有人只是把 AI 当高级补全，甚至生成什么就提交什么。两者的产出质量和成长速度，一定会拉开。这个差异如果不观测，组织是在主动放弃识别新能力结构的机会。

还是那句话，观测不等于迷信，比较不等于唯排名论。个体层数据要服务于两件事：培养更强的人，提前发现风险。它不能把团队带回那种老派的、只会按数字压人的管理习惯。因为 AI 时代最不缺的，就是表面上很漂亮的数字。真正缺的，是能把这些数字放回具体工程语境里解释清楚的人。

量结果

我一直不太赞成把研发效能拆成「过程指标 vs 结果指标」两个完全对立的东西。工程里没这么清楚。很多大家嘴里的结果指标，实际上掺了很多过程含义。代码行数就是典型例子。

很多人说 LOC 已经过时，这话只说了一半。更准确一点：LOC 从来就不是好的一线效能指标，在 AI 时代更差。

原因有三个。

• 生成成本塌了：过去一个人写 500 行和写 50 行，投入成本通常不同。现在 AI 补全、生成、重构、搬迁代码，几分钟就能吐出成百上千行。代码行数和人类投入的相关性被打穿了。
• 噪音变大：AI 很容易生成「看起来很完整」的实现：参数校验、日志、适配层、重复样板、冗余抽象全都给你带上。LOC 涨得飞快，但业务价值未必增加。
• 债务被掩盖：最麻烦的是第三点。AI 会让代码库存增长速度明显快于架构治理速度。表面上看，产出变高了；往后看，维护成本、理解成本、回归成本都在涨。LOC 会把这个问题盖住。

所以代码行数其实没有啥意义，只当成代码影响范围的辅助信号，别当产出指标。

那真正该量什么结果？

可以分三类。

交付结果

这是最基础的一层：

• 需求交付数量
• 需求交付周期
• 按期上线率
• 有效发布次数
• 版本回退率

这里要提醒一下：上线需求数也很容易失真。
因为需求切得越碎，上线数越好看；但碎到一定程度，用户感知价值可能没有提升，反而多了协调成本。

所以需求数量一定要配合需求粒度标准化。最少要把需求分成几类：小修复、小功能、中型功能、跨系统项目、技术治理项。不同类型分开统计，不然一张表里什么都看不出来。

业务结果

如果团队做的是业务研发，最终还是得往用户影响上落。常见的：

• 某类功能从提出到用户可用的时间
• 用户覆盖范围
• 功能使用率
• 转化率变化
• 关键漏斗改善
• 客诉下降
• 线上稳定性对收入的影响

很多技术管理者不敢碰业务指标，怕研发背锅。我反而觉得该看，但不要简单归因。业务结果可以做关联分析，不要粗暴做责任归因。比如某个推荐功能两周上线了，但实验效果一般，这不等于研发效能差。研发效能差，应该体现在 TTM 过长、试验成本过高、回滚困难、迭代慢，而不是实验结论本身不好。

工程结果

如果团队做的是平台、基建、中间件、工具链，不能硬套 GMV、转化率这种业务指标。这个场景下我更看这些：

• 接入团队数
• 接入周期
• 平台能力调用成功率
• 构建时长变化
• 测试时长变化
• 故障发现提前量
• 资源成本变化
• 事故数和事故影响面
• 研发人均可支撑服务数

基建团队最吃亏的一点，是价值释放往往滞后，而且分散在别人的效率提升里。如果你只盯上线需求数，这类团队会被系统性低估。

TTM 还是核心指标

如果只能保留一个指标，我还是会选 TTM。

这里说的 TTM，不是立项到上线的日历时间，而是价值从进入研发系统到到达用户手里的有效时间。很多公司嘴上讲敏捷，实际上量的是开发开始到提测结束，这根本不是 TTM。

为什么 TTM 在 AI 时代更重要？

因为 AI 最直接改变的，就是局部生产速度。代码写快了，单测补得快了，文档初稿也快了。问题是，这些加速会不会真的传导到业务价值交付，完全不确定。

我见过最典型的一种情况：

• 开发编码时间下降 40%
• PR 数量上涨 2 倍
• 评审负担上涨 60%
• 测试回归时长上涨 35%
• 发布前冻结窗口变长
• 最终需求上线周期几乎没变

如果你只看编码侧的数据，会得出一个完全错误的结论：AI 大幅提升了效能。
如果你看 TTM，问题一下就暴露了：加速发生在局部，瓶颈转移到了下游。

所以 TTM 的价值就在这里。它不关心你用了什么先进工具，它只看最终有没有把价值更快交出去。

TTM 怎么拆

TTM 不能只看一个总时长，否则只能看热闹。要拆段看：

• 需求澄清耗时
• 方案设计耗时
• 开发耗时
• 评审耗时
• 测试耗时
• 等待发布耗时
• 灰度验证耗时

拆完之后，你才知道 AI 真正帮到了哪一段，堵在了哪一段。

另外，在 AI 时代，这种拆段是否合理，是否可以合并不同阶段或角色，让一些信息的流转内化为个人的思考逻辑，实现端到端的 AI 化。

比如，产品经理直接从需求到前端代码的实现。

看分布，不看均值

TTM 最忌讳只看平均值。平均值非常会骗人。正确看法至少要有：

• P50
• P75
• P90
• 超过阈值的长尾需求占比

因为 AI 往往会优先优化简单需求。这样 P50 可能很好看，P90 反而更差。原因也简单，简单需求被快速吞掉之后，系统里剩下的都是复杂需求、遗留系统改造、跨域联动项目，长尾会更长。

如果你只看均值，会误判整个系统在变快。

四个指标

DevOps 四指标在今天依然能打，但口径需要有一些升级。

部署频率

部署频率比 LOC 强太多。因为它至少是靠近真实交付动作的。代码写了多少行没人关心，真正有意义的是你有没有把变更安全地推到生产环境。

但部署频率也不能裸看。

高频不等于高效

AI 上来之后，一个常见变化就是团队更愿意切小 PR，发小版本。这个方向本身没问题，小批量交付通常更安全。问题在于，有些团队把一个正常需求拆成大量低价值、低独立性的碎发布，频率上去了，用户价值没上去，测试和发布成本反而更高。

所以我一般会同时看三个维度：

• 单位时间部署次数
• 每次部署的有效变更量
• 每次部署的独立可验证价值

没有后两项约束，部署频率很容易变成表演数据。

适用场景不同

业务团队和基建团队的部署频率口径也不能完全一样。

业务团队可以看：

• 每周或每日生产发布次数
• 灰度发布次数
• 从功能完成到触达用户的次数

基建团队更适合看：

• 核心服务变更发布频率
• 非工作时段紧急发布占比
• 配置变更自动化发布比例
• 平台工具链版本迭代频率

基建团队很多时候更强调稳定和兼容，追求极端高频未必合理。比如数据库、中间件、网关这类系统，频率太高反而可能说明变更管理有问题。

交付周期

交付周期本质上是 TTM 在工程流水线里的展开版。通常从代码提交到生产运行，也有人从需求进入开发开始统计。具体口径可以按团队定，但必须固定。

AI 时代交付周期最容易出现两个假象。

• 提交变快了，交付没变快： 这是前面说的局部提速问题。AI 让提交更快，但后续验证没跟上，周期不会实质下降。
• PR 变多了，周期看起来更短：如果团队把一个需求拆成多个极小 PR，每个 PR 周期都很短，报表会很好看。但从需求视角看，整体仍然很慢。所以我建议同时维护两套口径：一个是 PR 级交付周期，另一个是需求级交付周期。PR 级用于观察工程流水线摩擦，需求级用于看真实业务交付。只看其中一个，都会失真。

变更失败率

这个指标在 AI 时代的重要性实际上上升了。

因为生成式编码提高了变更速度，也提高了「错误以正确形式出现」的概率。以前很多错误是写不出来，现在是能很快写出一个逻辑闭环、风格统一、还能过部分测试的错误实现。它更隐蔽，也更容易通过表面检查。

可以把变更失败率定义得更工程化一点，至少包含这些事件：

• 发布后触发回滚
• 发布后引发 Sev 事故
• 发布后触发热点修复
• 发布后造成核心指标异常
• 发布后引起客户可感知故障

如果定义太窄，只算重大事故，这个指标会钝化。定义太宽，又会把正常试错算进去。团队需要自己定边界，但边界一旦定了就别频繁改。

AI 对失败率的影响机制

这里有几个常见来源：

• 生成代码对边界条件覆盖不足
• 引入不必要抽象，增加理解偏差
• 与历史代码风格和隐式约束不一致
• 测试代码同样由 AI 生成，出现「同源缺陷」
• 变更面比工程师主观预期更大

我自己比较警惕第四点。很多团队现在喜欢让 AI 顺手补测试，看起来很完整。但如果实现和测试都建立在同一段错误理解上，测试通过并不能证明正确。

所以在高风险变更里，测试不能只依赖生成。关键路径一定要有人做反例设计。

平均恢复时间

很多团队对 MTTR 的重视程度不够，尤其是业务团队。实际上，AI 时代恢复能力的重要性在上升。

当代码生成速度变快，进入生产环境的变更更多、更碎、更频繁，系统面对故障的概率和复杂度都在变化。你不一定能把每次变更都做得完美，但你必须能快速止血。

MTTR 的价值在于衡量团队是否真正具备工程韧性。这个指标背后对应的是一整套能力：

• 监控和告警是否有效
• 变更是否可追踪
• 是否支持快速回滚
• 灰度和开关能力是否完善
• 值班机制是否靠谱
• 故障定位信息是否充分

很多团队前面三个指标都好看，MTTR 很差。这样的系统经不起规模化 AI 变更。因为一旦出事，恢复慢会把前面所有频率和周期优势全吃掉。

历史债务

AI Coding 真正会在一年后把团队拉开差距，这里的差距在于谁更早处理历史债务。

这个问题现在还没有被足够重视。但是实际中已经越来越严重了。

因为短期内 AI 会制造一种繁荣感：交付更快，PR 更多，需求吞吐上升。可如果代码库质量、模块边界、测试资产、文档一致性没有同步改善，债务会以更快速度积累。

AI 会怎样放大债务

几个很典型的模式。

• 重复实现增多：工程师直接让 AI 在局部上下文里生成功能，很容易绕过现有抽象和公共能力。短期最省事，长期就是重复轮子到处长。
• 中间层膨胀：AI 很擅长生成 adapter、wrapper、facade 这类看起来规整的中间层。问题是很多层根本没有必要，只是为了让局部代码更顺。半年后系统会变得非常厚，排障和重构都很痛苦。
• 测试资产劣化：生成测试很快，真正有效的测试不快。团队如果只追求覆盖率，很快就会积累大量低价值测试：断言脆弱、依赖实现细节、执行慢、维护成本高。最后 CI 时间越来越长，大家开始跳过测试。
• 文档与实现漂移更快：AI 可以快速生成设计说明、变更记录、接口文档初稿。但只要流程里没有强约束，这些文档过几周就过时。文档数量增加，不代表知识管理更好。
• 债务怎么量：技术债务很难精确，但不代表不能量。至少看四组信号：
  • 重复代码比例或重复能力点数量
  • 关键模块复杂度变化
  • 测试执行时长与稳定性
  • 历史模块变更失败率和恢复时长

指标落地

说一堆指标，如果最后只是做一张月报，那基本没用。研发效能度量要落地，大概可以看三点：统一口径、自动采集、和决策绑定。

统一口径

很多团队最大的问题不是没数据，是每个人嘴里同一个词代表不同意思。

比如「交付周期」，有人从排期开始算，有人从开始开发算，有人从代码提交算。你拿这三种数据做横向比较，结论一定错。

所以第一件事就是给每个指标下工程定义：

• 起点是什么
• 终点是什么
• 谁负责标记状态
• 异常情况怎么处理
• 统计周期是什么
• 看均值还是分位数

这一步很枯燥，但躲不过去。没有口径统一，报表越华丽越危险。

自动采集

凡是靠人手填的效能数据，最后都会漂。

我建议优先从这些系统自动取数：

• 需求系统
• Git 仓库
• CI/CD 平台
• 测试平台
• 线上监控与事故系统
• 发布平台
• 值班和告警系统

AI 时代还可以补一些辅助数据，比如：

• AI 建议采纳率
• AI 生成代码在最终提交中的占比
• AI 相关变更的回退率
• AI 生成测试的失败分布

但这些只建议做诊断维度，不建议直接进核心看板。

和决策绑定

指标如果不进入真实决策流程，就只会变成汇报材料。

可以把不同指标绑定到不同节奏：

周维度

团队看流水线摩擦：

• PR 周期
• 构建失败率
• 测试时长
• 发布次数
• 热修次数

月维度

管理者看交付和稳定性：

• TTM 分布
• 部署频率
• 变更失败率
• MTTR
• 技术债务信号

季度维度

看结构性问题：

• 跨团队依赖导致的等待占比
• 核心系统复杂度变化
• 自动化覆盖关键路径的比例
• 平台能力复用率
• 人均支撑规模变化

只有当指标驱动了人力投入、架构治理、流程调整，度量才算产生价值。

常见误区

• 误区一： 拿 AI 使用量替代研发效能。 比如：人均每天调用 AI 多少次，AI 生成了多少代码，采纳率多少，这些数据可以看工具渗透率，不能代表团队变快了，更不能代表交付变好了。高采纳率有时候只是因为团队在写更多样板代码。
• 误区二：把效能问题当管理问题。 一看到周期长，就加日报、加审批、加同步会。这个思路在 AI 时代更危险，因为编码加速之后，组织摩擦会成为主要瓶颈。继续加管理动作，只会让非编码时间更长。效能最后还是要回到工程根上：架构边界、测试自动化、环境一致性、发布能力、可观测性、模块治理。
• 误区三：把所有团队放在一套指标下排序。业务、基建、平台、安全、数据团队的工作性质差异很大。统一看板可以有，统一排名很容易把组织带偏。
• 误区四：只看短期提速，不看长期维护成本。 AI 最容易制造的错觉就是这个月吞吐上涨了，于是大家默认效能提升。可如果未来三个月回归变慢、故障变多、重构困难，这个月的漂亮报表只是透支。
• 误区五：只看平均值。平均值会把长尾、异常、结构性阻塞全部抹平。工程管理里，很多真正该解决的问题都藏在 P90 之后。

最后

研发效能从来不是一个分数问题，它是一个约束系统问题。得回答下面的问题：

• 价值有没有更快交出去
• 变更是不是足够安全
• 出问题能不能快速恢复
• 现在的速度有没有透支未来

这四件事里，TTM 仍然是排第一的。因为业务不会为你写了多少代码买单，也不会为你调了多少次 AI 买单。业务只关心一件事：价值多久能到用户手里。

AI Coding 改变了工程生产函数。

但它没有改变研发效能的基本物理规律。局部速度不等于系统速度，生成能力不等于交付能力，短期吞吐不等于长期效率。

不要急着发明一套全新的效能宗教。先把工程里的主干指标守住，把主体放对，把业务团队和基建团队分开看，把技术债务纳入视野，再去观察 AI 到底在哪些环节真的创造了增益。

这样量出来的数据，才能指导决策。否则报表再热闹，也只是另一种噪音。

以上。