团队与效能度量：怎么证明 AI 真的提效了

1. 本节产出

一套 AI 效能度量指标（不只是「用了多少次」）、一个 PoC 计划模板，以及三个常见的度量陷阱——这是本节最值钱的部分。

2. 前置依赖

3. 为什么「使用量」是一个糟糕的指标

常见的 AI 效能报告：

本月 AI 使用情况：
  - 调用次数：12,543（+45%）
  - 活跃用户：238（+30%）
  - 满意度：4.2/5

这三个数字都无法回答「有没有提效」：

指标	问题
调用次数	用得多可能是因为做得差（反复重试）
活跃用户	试用一次也算活跃
满意度	主观、且使用者倾向于给好评（新鲜感）

更严重的问题：这些指标会诱导错误行为。 如果考核「调用次数」，团队会为了数字而用 AI，哪怕没产生价值。

4. 核心原理

4.1 三个度量陷阱

陷阱	说明	例子
虚荣指标	好看但不反映价值	调用次数、注册用户数
自我报告偏差	用户主观高估节省时间	「我觉得省了 2 小时」，实际 20 分钟
分母错误	只算成功案例，忽略失败与返工	10 次里 3 次结果不能用，但只统计了 7 次

第二个陷阱最隐蔽。做法：用客观数据交叉验证（比如工单处理时长的前后对比），而不是只信问卷。

第三个陷阱最危险。做法：统计「采纳率」——AI 的输出有多少被真正采用。采纳率低说明产出质量有问题，再高的调用量也没意义。

4.2 四层度量模型

层	指标	怎么测
使用	活跃用户、调用量	网关日志（辅助指标）
质量	采纳率、返工率、用户纠错率	前端埋点（点赞/点踩/是否修改）
效率	任务时长前后对比、单位时间产出	业务系统数据
业务	成本节省、收入提升、客户满意度	业务指标

只有第一层是容易测的，但价值也最低。 真正有用的是第二、三层。

4.3 关键指标：采纳率

采纳率 = 被采用（未修改或仅微调）的 AI 产出 / 总产出

参考阈值：
  > 70%   → 质量很好，可扩大推广
  50~70%  → 可用，但有优化空间
  < 50%   → 质量有问题，先别推广

如何采集：

场景	采集方式
代码审查	开发者是否按建议修改了
文档问答	是否点击了引用（说明在核实）
客服辅助	坐席是否采用了建议回复
工单处理	Agent 的处理结果是否被人工改动

「是否点击引用」是一个很好的间接指标：用户愿意核实，说明他信任但需要验证；用户连引用都不点，说明根本没看。

4.4 效率度量的正确做法：前后对比

错误：问用户「你觉得省了多少时间？」

正确：
  1. 选一个可测量的任务（如「处理一类工单」）
  2. 记录 AI 上线前的平均处理时长（基线）
  3. 上线后记录同样任务的时长
  4. 对比，并考虑学习曲线（前两周数据不计）

建立基线是关键，而基线必须在上线前测。很多项目上线后才想起来没测基线，只能靠回忆估算——那数据就不可信了。

4.5 PoC 计划模板

markdown

# PoC 计划：<场景名>

## 1. 目标与假设
   假设：引入 AI 辅助后，XX 任务的处理时长从 A 降到 B
   
## 2. 范围
   场景：XX
   用户：XX 团队 N 人
   周期：4 周（前 1 周适应期不计）

## 3. 基线测量（PoC 开始前必做）
   - 任务平均时长：___
   - 任务准确率/质量分：___
   - 月任务量：___

## 4. 度量指标
   主要指标：任务平均时长
   次要指标：采纳率、质量分、用户满意度

## 5. 门槛条件（Go / No-Go）
   - 时长下降 ≥ 30%
   - 采纳率 ≥ 60%
   - 质量分不低于基线
   - 月成本 ≤ ___ 元

## 6. 风险与缓解
   ...

「门槛条件」是 PoC 模板最重要的部分：事先约定什么算成功，避免事后争论。

5. 代码走查

5.1 采纳率采集

java

// 前端在用户采纳/修改/丢弃时上报
@PostMapping("/api/feedback/adoption")
public void recordAdoption(@RequestBody AdoptionEvent e) {
    adoptionRepo.save(new AdoptionRecord(
            e.answerId(), e.tenantId(), e.userId(),
            e.action(),        // ADOPTED / MODIFIED / DISCARDED
            e.editDistance(),  // 改动幅度，0 表示完全采纳
            Instant.now()));
}

public enum Adoption { ADOPTED, MODIFIED, DISCARDED }

java

// 计算采纳率
public AdoptionRate rate(String tenantId, LocalDate from, LocalDate to) {
    long total = repo.count(tenantId, from, to);
    long adopted = repo.countBy(tenantId, from, to,
            List.of(Adoption.ADOPTED));
    long modified = repo.countBy(tenantId, from, to,
            List.of(Adoption.MODIFIED));

    // 微调（改动小于 20%）也算采纳
    long minorEdit = repo.countMinorEdit(tenantId, from, to, 0.2);

    return new AdoptionRate(total, (adopted + minorEdit) / (double) total,
            modified / (double) total);
}

5.2 效率对比报表

java

/** 任务时长前后对比 */
public EfficiencyReport compare(LocalDate cutover) {
    double before = taskRepo.avgDuration(cutover.minusDays(30), cutover);
    double after  = taskRepo.avgDuration(cutover.plusDays(14), LocalDate.now());

    return new EfficiencyReport(before, after, (before - after) / before);
}

cutover.plusDays(14) 跳过适应期是重要细节：刚上线时用户不熟练，数据会偏悲观。

5.3 度量看板

AI 效能看板（给管理层）：
  第一行：采纳率趋势、活跃用户、周调用量
  第二行：任务时长前后对比（柱状图）
  第三行：成本 vs 节省（双轴）
  第四行：按场景的采纳率排行（找出好用的和不好用的）

第四行最有行动价值：采纳率低的场景要么优化、要么砍掉，而不是继续投入。

6. 跑起来

bash

git checkout ch04-08-metrics
mvn spring-boot:run

bash

# 1. 上报采纳事件
curl -X POST http://localhost:8080/api/feedback/adoption \
  -d '{"answerId":"a-1","action":"MODIFIED","editDistance":0.15}'

# 2. 采纳率
curl "http://localhost:8080/api/metrics/adoption?from=2026-09-01&to=2026-09-30"
# 期望：{"total":1243,"adoptRate":0.68,"modifyRate":0.24}

# 3. 效率对比
curl "http://localhost:8080/api/metrics/efficiency?cutover=2026-09-01"
# 期望：{"before":18.4,"after":11.2,"improvement":0.391}

# 4. 按场景排行
curl "http://localhost:8080/api/metrics/adoption/by-case"

检查项	通过标准
采纳率可算	区分完全采纳/微调/大幅修改/丢弃
基线已测	PoC 开始前有基线数据（不是事后回忆）
适应期跳过	上线后前两周不计入
门槛明确	PoC 计划写了 Go/No-Go 条件
看板可用	四行指标都能出数

7. 生产避坑

不要用「调用次数」作为主要指标。它不反映价值，还会诱导为数字而使用。主要指标应该是采纳率和任务时长前后对比。
基线必须在上线前测。上线后才想起测基线，只能靠回忆估算，数据不可信，后面所有对比都站不住脚。把「测基线」写进 PoC 计划的第一阶段，作为硬性前置条件。
低采纳率的场景要么优化要么砍掉，不要继续投入。采纳率低于 50% 说明产出质量不达标，继续推广只会消耗预算和用户信任。按场景看采纳率，而不是只看整体。

8. 延伸与锚点

04 篇完成。剩下的都是「随时要查」的东西——速查表、踩坑合集、FAQ、变更日志。进入 99 参考区
代码锚点：git checkout ch04-08-metrics
对应课件：L04-08 效能度量

团队与效能度量：怎么证明 AI 真的提效了 ​

1. 本节产出 ​

2. 前置依赖 ​

3. 为什么「使用量」是一个糟糕的指标 ​

4. 核心原理 ​

4.1 三个度量陷阱 ​

4.2 四层度量模型 ​

4.3 关键指标：采纳率 ​

4.4 效率度量的正确做法：前后对比 ​

4.5 PoC 计划模板 ​

5. 代码走查 ​

5.1 采纳率采集 ​

5.2 效率对比报表 ​

5.3 度量看板 ​

6. 跑起来 ​

7. 生产避坑 ​

8. 延伸与锚点 ​

团队与效能度量：怎么证明 AI 真的提效了

1. 本节产出

2. 前置依赖

3. 为什么「使用量」是一个糟糕的指标

4. 核心原理

4.1 三个度量陷阱

4.2 四层度量模型

4.3 关键指标：采纳率

4.4 效率度量的正确做法：前后对比

4.5 PoC 计划模板

5. 代码走查

5.1 采纳率采集

5.2 效率对比报表

5.3 度量看板

6. 跑起来

7. 生产避坑

8. 延伸与锚点