[measurement] | 2026-08-05 | 10 min

# 提效比较的三锚点：可比性、可分离性、诚实性

AI 介入软件工程后，提效比较常掉进鸡同鸭比。本文提出三锚点——可比性（固定 backlog / 团队 / 窗口）、可分离性（冻结复杂度基线）、诚实性（预期而非伪装实测）——并给出吞吐、周期时间（速度口径）与配对汇总的读数纪律，附常见反模式。

[dev-productivity][measurement][cycle-time][throughput][ai4se]

有人问「用了 AI 之后提效多少」，期待的答案往往像换了一台更快的机器：同一条流水线，产量上去了。现实更别扭——AI 改变的是工作的组织方式：需求拆到多细、编码与验证怎么分界、人和机器各管哪一段，都发生了结构性位移。于是真正要回答的，常常不是「同一件事做得更快了吗」，而是「更快做的事情，还是同一件事吗」。

传统生产力度量——代码行数、功能点、故事点/人天——隐含一个前提：工作单元的定义和完成路径，在不同团队、不同时期之间大致稳定。当 AI 成为开发链路的积极参与者，这个前提动摇了。Spec-Driven Development 把规格前移，用结构化 Spec 驱动生成与验证，其交付单元的粒度和流转方式，与「古法」故事交付并不天然对齐。若直接用新交付单元个数或生成代码量来比提效，比较双方甚至不在同一度量空间——这就是常见的鸡同鸭比。

站内已有一篇效能指标共创剧本，讲怎么开会、怎么共创、起步量哪些数。本文补另一半：在前后对照里，哪些设计决策决定了数字能不能信。 每一次「该不该这样比」，都可以压回三个锚点——可比性、可分离性、诚实性。

一、度量之难：三个结构性困难

第一，度量空间可能不对齐。 Before 按故事统计，After 按新的交付切片统计，两边的分布形态不可比。活动量指标（生成行数、Commit、PR 个数）在 AI 时代更容易失真，理由见开发者生产力为何失效。

第二，效果高度依赖流程成熟度。 同一套 Spec 驱动流程，在刚上手与高度共识两个阶段，产出可以差出数倍。不区分前置条件，你不知道数字量的是能力上限，还是学习曲线上的瞬时快照。

第三，混杂因子太多。 Backlog 复杂度不同、团队并行度不同、迭代窗口长短不同，都会直接拉动吞吐与完成概率。变量不钉死，差异无法归因于方法本身。

三锚点正是对着这三道坎：用固定条件钉住比较基准，用冻结的复杂度尺子统一度量空间，用「高度共识下的可承诺预期」锚定成熟阶段——产出可审计、可被后续实测校验的方向性结论，而不是一场会上的魔法百分比。

二、可比性：钉住三个变量

Before 与 After 之间，唯一允许变化的，应是开发方法本身。至少钉死三类外部条件：

固定条件	约定	为何不能变
Product Backlog	同一份需求清单	复杂度分布不同，产能差无法归因于方法
团队规模	角色结构与人数固定	并行度直接决定吞吐
迭代窗口	同一长度（如 2 周）	窗口越长，完成概率天然越高

备选方案里有人想固定「代码复杂度」或功能点。问题在于：这些量在 Spec 驱动模式下本身可能系统性变化——生成代码的结构与手写未必同形——反而引入新的不可比。固定三个外部条件，是工作坊或经验评估约束下，最干净的对照近似。

向上汇报时纪律很简单：先展示控了什么变量，再展示数字。 没有对照说明的提效 %，建议直接退回。这也呼应 DORA 一贯提醒——吞吐要与稳定性成对看，单一速度数字极易被游戏；见 DORA 软件交付绩效指标与站内 DORA / SPACE / DevEx 全景。

三、可分离性：冻结复杂度基线

这是最关键、也最容易被误解的决策。

在估点阶段，各组对同一份 Backlog 独立估故事点，结果在组内冻结；Before 与 After 共用同一套点。After 不允许因为交付方式变了而重估点。

为什么？故事点度量的是需求的固有复杂度——它应尽量独立于实现方法。若 After 重估点，你无法区分「提效」来自方法改进，还是来自估计口径漂移。冻结 SP，是把「这件事有多复杂」和「这件事做得有多快」强行分开。

这不是完美分离。Spec 驱动确实可能让某些模式化任务「实际上更简单」。但允许重估的代价更大：双方失去共同的复杂度基线，提效数字将永远悬在「是更快了，还是重新定义了快」的疑问里。两害相权，冻结基线是可分离性在工程约束下的最佳近似——这也与姊妹篇里「古法估点」的纪律一致。

四、诚实性：预期而非伪装实测

经验评估或专家共识框算，产出的是可承诺预期，不是交付系统里已经落地的 ROI。这个区别必须贯穿所有对外表述。

两个极端都危险。一端是「乐观试探」——数字写成最好情况下可能达到的，管理层无法对齐资源规划。另一端是「已落地 ROI」——把估算说成实测，过度承诺；一旦后续遥测对不上，同时损害方法论信誉与团队信任。

可承诺预期的含义是：在团队对流程、工具与角色分工已形成高度共识的前提下，这个量级的提效是合理目标。它既不保守到失去参考价值，也不激进到无法兑现。后续用看板流转、Git、CI/CD 等实测数据校验——显著偏离时，回头看是落地有差距，还是共识假设不成立。预期 → 实测 → 校验，才是度量应有的姿态。

五、度量模型：吞吐与周期

5.1 吞吐量（Throughput）

现场友好的主报口径，是观测迭代内可完成故事的 $\Sigma$ Story Points。团队规模与窗口固定时，Person-days 近似常数， $\Sigma$ SP 与「Points / person-day」单调等价，需要时可换算。选 $\Sigma$ SP 作主报，是因为它更直观：一眼看懂「迭代内完成了多少故事点」。

完成定义必须与周期时间的终点对齐。 一个故事只有达到约定完成态（例如测试完成，或语义等价状态）才计入吞吐——避免「计入产能的故事还没走完验证」的口径错位。

5.2 周期时间（Cycle Time）

建议至少报两条变体（名称可本地化）：

名称	起点	终点
CT1（编码侧）	开发接卡 / 首次进入开发	该故事关联的 last commit
CT2（交付侧）	同上	测试完成（或约定 Done）

生产上线变体往往受环境、灰度等非开发因素支配；在经验框算里噪声大，可留给后续实测，不必硬塞进第一轮对照。

统计粒度锁定故事。 无论 Before 还是 After，Cycle Time 都按故事算分位。若 After 以更细的变更切片组织交付，必须先折回故事粒度再算——否则 Before 按故事、After 按切片，分布不可比。

分位主报。 历时类指标用百分位，不用均值。现场估算粒度较粗时，P75 往往比 P50 更能反映「多数故事可达到的周期上沿」；也可 P50 / P75 并报。姊妹篇默认 p50 与 p85，原则相同：抗极端值，看真实流动。

5.3 Cycle Time 的「提效 %」用速度口径

吞吐提效分母取 Before，直觉顺畅：

\Delta TP = \frac{TP^{A} - TP^{B}}{TP^{B}} \times 100\%

周期时间若仍用「缩短比例」 $(B-A)/B$ 却对外称「提效」，会系统性低估能力变化。4 天降到 2 天，缩短 50%；但同样窗口内能做完的工作量接近翻倍。把周期倒数为速度 $\mathrm{Speed}=1/\mathrm{CT}$ ，再算相对 Before 的提升，才与吞吐的「能力变强」叙事同语义空间：

\Delta CT^{\text{提效}} = \frac{CT^{B} - CT^{A}}{CT^{A}} = \left(\frac{CT^{B}}{CT^{A}} - 1\right) \times 100\%

同一对数字，三个口径勿混名：

口径	公式	4 天 → 2 天
缩短比例（相对 Before）	$(B-A)/B$	50%
提效 %（速度，推荐主报）	$(B-A)/A$	100%
速度倍数	$B/A$	2×

口述优先说「提效 X% / 快了 Y 倍」，必要时补「时长缩短 Z%」。三者同事实、不同分母。

示意（单组，非实测）：

指标	Before	After	提效 Δ（主报）
Throughput $\Sigma$ SP	20	30	+50%
CT1 P75（天）	8	4	+100%（2×；缩短 50%）
CT2 P75（天）	10	6	+66.7%（缩短 40%）

六、怎么读结论：配对 Δ，再汇总

先算组内相对变化。 同一组同时估 Before / After，共享对 Backlog 与团队能力的判断；组内 $\Delta$ 比绝对水平更稳——这是配对设计的基本要求。

跨组用中位数 + IQR，不用均值硬凑精确感。 小样本下均值对极端值极度敏感；专家估算又常见系统性乐观偏差。中位数配合四分位距传递的是：「多数共识落在附近，分歧有多大」——这正是管理层需要的信息。

三个「不要」：

不要先平均各组 Before、再平均 After、再算一个总 Δ——破坏配对，放大偏差。
不要跨组混合故事后重算全局分位——各组 SP 尺度未必可比，混合后分位含义不清。
不要把「缩短 50%」与「提效 100%」当成两个事实——同一对数字，口述时分清口径。

默认不因「数字不够好看」剔组。 仅当确认未遵守固定条件（换了 Backlog、改了团队规模、After 改点、按错误粒度统计等）时，才标为不合格并注明原因；明细仍保留。这是诚实性锚点的硬条款。

七、反模式速查

反模式	违反锚点	为何有害
After 重估 SP	可分离性	「改点」伪装成提效，基线被污染
Before / After 用不同统计粒度	可比性	分布形态不可比
团队或窗口不一致	可比性	差异无法归因于方法
先平均水平值再算总 Δ	可分离性	破坏配对，放大偏差
只报单一提效 %、不报分歧区间	诚实性	伪造精确感
用缩短比例却称「提效」且不分母	诚实性	误导管理层对量级的判断
把框算写成已落地实测 ROI	诚实性	过度承诺，损害信任

收束

提效比较不是先抛百分比，再补故事。顺序应反过来：先钉住可比条件，再分离复杂度与速度，再诚实标明数字处在预期还是实测。 三锚点是判据，不是装饰——每当你犹豫「该不该这样报」，回到它们检验一遍。

金句回收：可比性先于百分比；可分离性守住基线；诚实性守住信任。 模糊的提效叙事制造焦虑；可对照的度量语言制造改进。

若要落地开会共创指标集与起步配方，继续读姊妹篇：和团队死磕 AI4SE 效能指标。

参考

DORA. Software delivery performance metrics.
Lean / Lean Software Development 语境下的 Lead Time 与 Cycle Time（与 DORA「Lead Time for Changes」口径对照使用）。