# 别再用 N× 讲 AI4SE 成效：诚实评估需要成熟度与度量一起看

赞助人问「用了 AI 之后提效多少」，期待的答案往往是一个干净的倍率：2×、5×，偶尔还有「上千个百分点」一类口号。数字越响亮，越像已经完成的交付证据。

现实更别扭。开发者生产力是多维的——SPACE 早就提醒：满意度、表现、活动量、协作与效率/心流可以朝不同方向动；把一切压成一个吞吐口号，决策质量通常更差，而不是更好。更糟的是，感知可以和实测背离：METR 对早期 2025 AI 工具的一项 RCT 里，有经验的开源开发者预报会更快，允许使用 AI 后却大约慢了 19%。

组织真正缺的，往往不是又一个更夸张的 N×，而是一套管理上可用的评估纪律：能同时回答「能力有没有在制度化」和「吞吐 / 周期时间我们能期望什么」，并诚实标明每个数字是怎么来的。下面是我们在咨询实践里整理的读法——成熟度与度量一起看；倍率口号不能替代这一对。

一、倍率口号的三处失败

1. 把编码局部加速当成端到端 ROI

构建（写代码 / 生成）阶段变快，不等于从需求到可交付的全链路同比例变快。计划、评审、测试、发布仍可能停在「人速」瓶颈上——Anthropic 的 AI-native SDLC playbook 也强调：build 加速时，周围阶段可能成为新卡点。管理叙事若把「某段写码快了 N×」直接写成「交付快了 N×」，分母已经换了。

2. 缺明确对照与固定条件

任何 N× 都需要：比的是谁、在什么条件下比。没有对照，数字不可解释。AI4SE 还会改变工作怎么拆、怎么验、怎么交——「同一件事更快」的框架，在交付单元本身位移时容易塌掉。站内提效比较的三锚点把纪律压成三条：可比性（固定 Product Backlog / 团队 / 迭代窗口）、可分离性（冻结故事点，After 不得重估）、诚实性（高共识下的可承诺预期，不是伪装实测 ROI）。没有这些钉子，百分比只是幻灯片装饰。

3. 缺信号类型标签

成熟度打分、工作坊专家估计、需求平台上的实测吞吐/周期时间，是三种不同强度的证据。混进一张「ROI」表里，而不标明每一格是什么，就会发生最危险的叙述替换：把共识预期写成已实现收益，或把能力域均值当成业务回报。公开实验里常见的，多是有条件的中等增益（例如现场实验里完成任务数大约 +26%，企业级任务 RCT 里时间大约短 21%、置信区间很宽），与组织级「到处 N×」的民俗叙事本就不是一类东西；缺标签时，民俗数字最容易上场。

二、双轨看板：成熟度与度量一起看

赞助人其实在问两张脸：

轨道	回答的问题	诚实读法
能力成熟度	效率相关能力有没有被制度化？	短试点里域均值只动 +0.3～+1（1–5 编码）常常是预期发现，不是自动失败
交付结果信号	在固定条件下，吞吐 / 周期时间能期望什么？	工作坊数字先当可承诺预期；同一定义下再用平台遥测校验或证伪

只报成熟度，答不全「吞吐 / CT 多少」；只报指标，看不见制度化有没有发生。两轨并排、各用各的尺度，才挡住「合成一个未经验证的倍率」。

成熟度侧，我们用过程能力画像（例如 6 域 × 18 项、L1–L5）做前后对照——细节见成熟度模型设计。它跟踪的是组织能力变化，不是产品质量或商业结果，也不是平台实测 ROI。

度量侧，起步通常看两个不同构念（配方与共创流程见效能指标共创）：

• 吞吐（体积）：固定迭代窗口内完成故事的 $\Sigma$ Story Points（团队与窗口固定时，与 points/人天单调等价）。
• 周期时间（速度）：故事在两个工作流端点之间的历时——例如 CT1（开发接卡 → 相关 last commit）与 CT2（同起点 → 测试完成）。分位主报（如 P75），先配对算 $\Delta$，再跨组报 median + IQR，不用均值套均值，更不用最大值当组织 headline。

关键纪律：吞吐 improve $\Delta$ 与 CT speed-improve $\Delta$ 不能合成「到处大约 2×」。 一个是窗口内完成体积，一个是历时加速；叙事上要分开写。

联合读法只有三句：

1. 能力 lift ≠ ROI
2. 估计 ≠ 平台实测
3. 两轨都要带着标签出现在同一页决策材料上

三、信号类型：每个格子都要贴标签

对外发布的每一个数字，建议带上信号类型：

signal_type	含义
process_maturity	引导式过程能力成熟度评估（域 / 能力等级）
metric_estimate	吞吐 / CT 来自专家或结对判断——可承诺预期
metric_platform	同一套吞吐 / CT 定义，从需求管理平台（及必要时 Git 时间戳）在真实迭代中算出

诚实评估在这里的意思很具体：每个已发布的格子都有标签；吞吐 / CT 的中位数在「估计 → 实测」晋升路径上保持承诺态，直到匹配的 metric_platform 值校验或证伪它们。平台格还空着，本身就是信息——不要用更响亮的 N× 把它盖住。

一个常见可信度陷阱：Before 也是估计。为了在「同一份 Product Backlog、同一团队、同一时间盒」下对比方法，工作坊有时会把传统交付与新方法（例如高共识下的 Spec-Driven）两端都收成 metric_estimate。这时 Before→After 是估计对估计的对照，不是「历史平台基线 → 工作坊预测」，更不是平台对平台。间隙里既可能有真实方法预期，也可能有共享乐观（「想象落差」）——所以在讲 ROI 之前，metric_platform 校验仍是强制项，不是可选项。

四、赞助人决策树（防误引）

当现场出现「成熟度只动一点、工作坊 median $\Delta$ 却很大」的组合——短 enablement 试点里很常见——建议按下面顺序读，而不是合成一个胜利故事：

1. 资助下一阶段的方法沉淀与埋点，不要宣布 ROI。
2. 先排 metric_platform 校验（同一定义），再把任何「大约 +100% $\Sigma$SP」或「大约 2× CT」写进已实现生产力幻灯片。
3. 主报 median + IQR；禁止把某一对的最大值复述成组织 headline。
4. 问清双轨看板的所有权（工程负责人 + 交付负责人共同签署标签），以及什么激励会惩罚「诚实区分估计与实测」。
5. 拒绝在没有明确对照与固定条件时，把构建阶段或工作坊 N× 叙述成端到端生命周期 ROI。
6. 质量仍是红线前置：效率叙事默认建立在既有质量门禁不降级之上；缺质量轨道不等于质量不重要，而是「质量已由客户既有指标治理」时，不要用吞吐口号偷换质量结论。

执行层叙事可以圆整成「工作坊条件下大约 +100% $\Sigma$SP（承诺态）」；精度留在表与 CSV 里。

五、反模式与最小行动

方案失败，如果：

• 发布行去掉了 signal_type
• After 重估故事点（可分离性被拆掉）
• 工作坊最大值取代 median + IQR 成为主声称
• 估计行在未与平台实测对质前被晋升为 ROI

enablement 失败，如果：

• 后来同一定义下的 metric_platform $\Delta$ 接近零，而方法「高度共识」仍被宣称
• 与方法包绑定的成熟度域在多轮复评中平坦，又无资产采纳证据
• 效率叙事推进时，质量红线指标被知情地突破或移出治理

这两种失败都是可报告的新闻——不是发明一个倍率的理由。

最小行动（一页幻灯片就能开始）：

1. 同一页报：成熟度域均值（process_maturity）+ 工作坊 median/IQR（metric_estimate）。
2. 点名谁拥有 estimate→measured 晋升路径，以及下次平台校验排期。
3. 写死禁令：不把两轨合成一个 N×；不把极值对当组织数字。

收束

公开文献里的点估计，已经足以反驳民俗组织级倍率；感知与实测还可能反向。可迁移的不是又一个「全行业 2×」，而是评估纪律：成熟度与带标签的度量并排；每个格子标明怎么来的；空着的平台格保持可见，直到被填上或被证伪。

倍率很适合做口号。它很少适合做阶段门证据。