# 和团队死磕 AI4SE 效能指标：从模糊「提效 %」到可对照的度量共创
别再用说不清分母的「提效 300%」焦虑彼此。把端到端角色拉齐，对齐 DORA 与精益术语，按两大组结对共创指标，再在同一团队、固定迭代与需求范围下用百分位做前后对照——附吞吐、多段 Cycle Time、质量与 Token 成本配方。
有研发经验的人凑到一起，话题很快会滑到「用了 AI 之后提效多少」。有人说 100%，有人说 300%，也有人脱口而出 1200%。这类数字听着热闹，分母却常常是空的：到底加速的是写代码、过评审、上线，还是从需求到用户可见的整段价值流？连说这话的人，有时也讲不清自己的百分比是怎么算出来的。
严谨的听众很容易在这种交流里对上焦灼：端到端看自己团队，并没有「故事里那么猛」的跃迁。问题往往不在「你们没用力用 AI」，而在提效指标定义模糊——没有可辩驳的尺子，就只剩情绪和攀比。
所以与其争论谁提效更多，不如把话题打开：和团队一起死磕——如何定义 AI 研发效能提升的度量指标，以及如何实施。框架层面的 DORA、SPACE、DevEx 全景，站内已有专文（可对照 从 DORA 到 DevEx、DORA 2025：AI 是放大器）；本文是工作坊剧本：怎么开会、怎么共创、怎么对照、起步量哪些数。
一句话先钉死纪律，后文会反复回到它：不控制变量的提效比较没有意义；可比性先于百分比。
一、先把「提效叙事」拆开
口头提效百分比有三个常见缺陷。
- 分母未定义：是个人编码耗时、迭代吞吐，还是变更失败率几乎不变前提下的交付前置时间？混谈无法复盘。
- 只谈加速、不谈稳定：编码变快若换来更脆的发布，组织层面未必算赢。Google DORA 近年研究反复强调：AI 首先是放大器——放大高绩效组织的优势，也放大薄弱流水线与薄弱质量护栏的短板；感知上的「写得飞快」不能代替交付结果。
- 跨条件攀比：不同团队、不同需求难度、不同迭代长度、不同 Definition of Done，直接比「提效 %」，科学上无效。
因此会议的第一目标不是产出又一个鼓舞人心的百分比，而是产出团队共同签字的度量语言：结果类优先、可采可算、能在可比条件下前后对照。活动量指标（生成行数、Commit 次数、PR 个数）在 AI 时代极易失真，理由见 AI4SE 时代的开发者生产力——本稿默认降权，除非小组能证明同口径对照且不被刷量支配。
二、度量基础知识会：先对齐语言
把产品 / BA、开发、测试、架构（必要时运维、安全）等端到端角色召到同一间房间。建议 60–90 分钟只讲术语、不对「我们提效了多少」下结论。场子怎么组人、怎么收敛，可借鉴 AI4SE 工作坊不是培训班 的纪律；本场议题专攻度量。
1. DORA 四关键指标（4KM）在聊什么
Forsgren、Humble、Kim 在 Accelerate 中沉淀、后由 DORA 持续演进的四类结果，适合当作讨论的护栏：速度与稳定要一起看，不能只报加速。
| 指标 | 常用内涵 | 对 AI4SE 讨论的用途 |
|---|---|---|
| Deployment Frequency | 多久向生产交付一次有意义变更 | 防止「只写得快、发不出」 |
| Lead Time for Changes | 从代码提交到生产可用的时间 | 对齐流水线与发布能力（注意口径很窄） |
| Change Failure Rate | 导致服务降级并需补救的变更占比 | 速度的质量底线 |
| Time to Restore / MTTR | 故障恢复到可用服务的时间 | 稳定性的另一半 |
务必当众说清：DORA 的 Lead Time for Changes 不等于精益意义上「客户提出需求到交付价值」的 Lead Time。混用这两个词，是后续数字对不上的第一大元凶。
2. 精益的 Lead Time 与 Cycle Time
- Lead Time（精益）：请求进入系统（或客户下单）→ 交付可用价值。覆盖等候与处理。
- Cycle Time：工作真正开始（如进入 In Progress）→ Done；或你们在 SDLC 上选定的任意两节点之间的历时。它更擅于诊断「系统卡在哪一段」。
Toyota / Lean Software 与 DevOps（DORA）对「Lead Time」起点不同，并不是谁对谁错，而是尺子不同。会后应贴出一页「术语对照表」：每个词在本团队的起止点写死，禁止在后续讨论里自由漂泊。
3. 和 AI 编码效率怎么衔接
Agent 压缩的往往是 Inner Loop（读懂、起草、局部修改）。这不自动等于精益 Lead Time 变短，也不自动等于迭代吞吐上升——评审、集成测试、环境、发布闸门可能成为新瓶颈。DORA 2025 语境下的关键提醒是：既要看吞吐，也要持续盯稳定性。基础知识会的产出不是 KPI 清单，而是：大家开始用同一种语言描述流动与风险，为下一场头脑风暴铺路。
三、分组共创：结对发散，TL 漏斗收敛
1. 编组与节奏
我们采用固定编组，方便后文「经验评估」锁住对照条件：
- 2 个大组（便于互相挑战口径）
- 每个大组内 2 个小组
- 每个小组 2 人结对
协作建议按四层推进：
- 结对发散：两人共写「指标卡片」，先求定义可算、数据可采。
- 大组内合并：两个结对互审，消歧、合并同名异义，产出大组候选集。
- 两大组对照：交换候选集，挑出分歧最大的 1–2 个定义当场对齐（通常卡在起止点）。
- TL 收敛：度量负责人 + TL 做漏斗——合并、剔除不可采、补齐必采缺口，锁定团队版指标集（建议 3–6 个，宁少勿滥），并书面化计算公式、规则与样例。
2. 投屏用的引导提示语
可直接投屏（也可用 Superpowers Brainstorming 或等价共创流程辅助）：
我希望与你一起深入探讨并确定合适的指标，量化 AI 编程助手对开发效率的提升。指标可以包括但不限于 Lead Time、Cycle Time 等结果类指标。
请帮助识别最适合衡量 AI 编码效率提升的关键 KPI，并详细讨论计算方法、数据收集方式、如何保证测量准确性。要求：
1）能向管理层展示效率提升的量化指标
2）每个指标有定义、计算公式、测量方法
3）可行的数据收集方案（Git、CI/CD、代码审查工具等）
4）如何建立基线并做对比分析
5）影响准确性的因素与对策
6）优先客观、可自动化收集的指标，避免纯主观判断
3. 「指标卡片」最少字段
| 字段 | 要写清什么 |
|---|---|
| 名称与业务问题 | 这个数回答管理层/团队的哪句话 |
| 精确定义 | 起止时间点、包含/排除什么工作项 |
| 公式与聚合 | By Story / 按迭代 / 人均；用总和还是百分位 |
| 数据源与责任人 | 看板、Git、CI、评审工具、账单；谁维护 |
| 基线与对比窗 | AI 前基线怎么建、对比多长一窗 |
| 误差与排除规则 | 假期、跨团队依赖、hotfix、学习成本是否入账 |
4. 硬约束（建议写进会规）
- 结果类优先于活动类；速度指标必须配至少一个质量/稳定性指标。
- 凡不能说明「AI 引入前后如何同口径对比」的提案，收敛时降权或退回。
- 收敛完成的标志不是热情，而是：每个入选集都有书面公式 + 样例计算。
四、经验评估五步法：有了指标再谈「提升了多少」
1. 可比性先于百分比（硬条款）
不固定变量的提效比较，不是「有争议」，而是直接无效。 只有在相同条件或环境下，观察引入 AI（或其他干预）前后的变化，比较才有意义。推荐的「好尺子」至少钉死一类，理想情况叠加：
- 同一团队：人不换、角色结构不换；
- 固定迭代：同一迭代长度与节奏；
- 固定需求范围：同一需求池或等价复杂度子集。
明确列为 anti-pattern 的做法：跨团队比百分比；用不同需求难度、不同排期、不同 DoD 拼出「提效故事」。向上汇报时，先展示对照设计（控了什么变量），再展示数字；没有对照说明的提效 %，建议管理层直接退回。
2. 统计上优先百分位
对 Lead Time / Cycle Time 这类历时指标，默认报 p50 与 p85，均值只作参考。平均数容易被个别「卡单故事」拖偏，掩盖多数故事的真实流动。吞吐类指标仍用「周期内故事点合计」或「人均同迭代点数」。
3. 五步流程
| 步骤 | 做什么 | 产出 |
|---|---|---|
| 1. 明确评估小组 | 固定两大组 / 结对人选与角色；评估期内尽量不换人 | 评估协议：谁、测什么窗 |
| 2. 需求池 + 古法估点 | 各小组都熟悉的需求池；仅用传统编程模式估点（刻意先不用 AI 估） | 需求池基线（故事点总量与分布） |
| 3. 经验法估 AI 前 | 按已锁定定义，回填采用 AI 前的吞吐、各段 Cycle Time 等 | AI 前基线表（含 p50/p85） |
| 4. 经验法估 AI 后 | 同口径、同需求池假设，估采用 AI 后的值 | AI 后对比表 |
| 5. 分析变化 | 相对变化、置信度、干扰因素脚注 | 可汇报的前后对照 |
古法估点是为了先统一复杂度尺子：AI 会改变「同样故事点意味着多少人力」的语感，若估点本身被 AI 重构，基线会漂移——这也呼应站内对 Story Points 在 AI 时代易失准的提醒。
诚实边界：经验法是快速诊断，不是生产遥测。协议跑通后，应用 Git、看板状态流转、CI/CD、评审工具与账单做自动化采集，对经验表做校验与校准。
防作弊清单（写进脚注）：只换工具不改流程却把收益全算给模型；评估窗短到只覆盖蜜月期；把学习与规范建设成本算进「变慢」却不写脚注；偷偷放宽 DoD 再宣称 Cycle Time 下降。
五、起步推荐的指标体系
在对照纪律与百分位方法之上，建议团队起步锁定四类（可裁剪）。每一类仍走「指标卡片」格式。
1. 团队吞吐量（效率）
- 定义：固定时间周期（同一迭代长度）内完成的故事点总数；或人均在同迭代完成的点数。
- 公式（示例）：
- 该迭代 Done 且纳入范围的故事点
- （ = 评估组人数）
- 对比：同一团队、同一迭代规格、同一「古法」估点尺子下的 AI 前 / 后。
- 数据：看板 Done 列表、迭代完成记录；故事点以评估协议锁定的值为准。
- 误差：范围蔓延、Done 定义漂移、跨迭代滞留项——用排除规则写死。
2. 多段 Cycle Time（效率，By Story）
- 方法：起点时间定义固定（例如进入 In Progress 的时间戳）；终点在 SDLC 重要节点上组合，形成多条 Cycle Time，例如：In Progress→Ready for Review、Review 开始→合并、合并→生产可用。
- 计算：按 Story 计算历时，再对故事集合取 p50 / p85，前后对照。
- 数据：看板状态流转、PR 创建/合并时间、CI 部署成功时间。
- 价值：回答「AI 到底加速了哪一段、瓶颈搬到了哪一段」——这比一个含糊的「整体提效 200%」更可行动。
- 误差：状态未真实更新、批量卡批、等待外部依赖——卡片里要有「暂停计时」规则。
3. 质量与稳定性（对齐 DORA）
建议直接采用（或轻适配）Change Failure Rate 与 MTTR / Time to Restore。速度指标与质量指标捆绑汇报：吞吐升而变更失败率恶化，不应包装成单维度成功。数据来自发布记录、事故单、回滚/hotfix 标记；定义「何为失败变更」必须先于统计。
4. Token / AI 增量成本（成本）
采用 AI 后会出现相对基线的额外投入：Token / API、席位订阅、私有化推理等。
- 定义：评估窗内 AI 相关增量成本合计（相对「无 AI」或「仅试点前」账单）。
- 粗口径效率：例如增量成本 / 同期吞吐，或增量成本 / 单位 p50 Cycle Time 改善——用于讨论投入产出，不必一次追求会计级精确。
- 数据：云账单、代理网关用量、座位 license。
- 决策信号：成本上升而吞吐与稳定性无明显改善，是停损或改实践的信号，不是需要藏起来的尴尬。
客观、可自动化优先：账单与流水线时间戳通常比问卷信度高；问卷可用于解释「为什么」，不宜单独充当「提效了多少」的主证据。
六、收束：先共创尺子，再谈百分比
可以按这条行动链落地：
- 开术语对齐会，贴出术语对照表。
- 按 2 大组 × 2 结对编组共创，TL 收敛出 3–6 个团队指标及书面公式。
- 签对照协议：同一团队、固定迭代、固定需求范围；历时类默认 p50/p85。
- 跑一轮经验评估五步法，形成可汇报的前后表（先对照设计，后数字）。
- 用自动化数据校验经验表，并把质量与 Token 成本与速度并置。
金句回收：可比性先于百分比；共创定义先于汇报数字。 模糊的提效叙事制造焦虑；可对照的度量语言制造改进。
相关阅读
- AI4SE 时代的开发者生产力：为什么传统指标正在失效
- 从 DORA 到 DevEx：AI4SE 度量框架的全景
- DORA 2025：AI 是放大器，不是银弹
- AI4SE 工作坊不是培训班：组人、节奏与漏斗收敛
参考
- Forsgren, Humble, Kim. Accelerate: The Science of Lean Software and DevOps.
- DORA. State of AI-assisted Software Development (2025) / DORA AI Capabilities Model.
- Lean / Lean Software Development 语境下的 Lead Time 与 Cycle Time（与 DORA「Lead Time for Changes」口径对照使用）。