衡量 AI 驱动工程的效果。被测量的东西才能被改善。
目的
没有指标，就无法知道 AI 是真正在加速团队，还是只是在增加复杂性。本章节定义测量什么以及如何测量。
核心指标
开发速度
- 周期时间：从需求到交付
- 各工作流阶段花费的时间
- 返工率（AI 输出需要大幅修改的频率）
AI 贡献比率
- AI 生成代码行数与人工编写代码行数的比例
- 包含 AI 生成初稿的 PR 占比
- 提示复用率（使用已有提示与新建提示的比率）
代码质量
- AI 生成代码与人工编写代码的 bug 率对比
- AI 生成成果的审查拒绝率
- AI 生成代码的测试覆盖率
交付效率
- 部署频率
- 变更失败率
- 平均恢复时间
指标收集方法
| 指标 | 收集方式 |
|---|---|
| 周期时间 | PR 创建到合并的时间戳（Git/GitHub 自动） |
| 返工率 | PR 中标注”重大修改”的比例（人工标记） |
| AI 贡献比率 | PR 描述中的 AI 解释字段（人工填写） |
| 审查拒绝率 | PR 被 request changes 的比例（Git 自动） |
| 部署频率 | CI/CD 部署日志（自动） |
从手动收集开始，逐步自动化高频指标。
审查节奏
- 每周：返工率、审查拒绝率 — 快速信号，问题在这一周内可以干预
- 每月：周期时间、AI 贡献比率 — 趋势信号，反映流程变化的效果
- 每季度：全指标回顾 — 判断当前阶段（参照 09-vision 演进阶段）
基线建立
引入 AI 工具前，记录：
– 平均 PR 周期时间
– 每周部署次数
– bug 修复与功能开发的时间分配比
没有基线，就无法判断 AI 是否真的在帮助团队。
计算方法
周期时间
周期时间 = PR 合并时间戳 − 第一次提交时间戳
月均周期时间 = 当月所有 PR 周期时间之和 ÷ PR 数量
数据来源：GitHub/GitLab API 自动获取，无需人工记录。
返工率
返工率 = 被标注"重大修改"的 PR 数量 ÷ 当期总 PR 数量 × 100%
"重大修改"定义：AI 生成初稿后，人工实质性修改超过 30% 的代码行
数据来源：PR 描述的 AI 解释字段（人工填写）。
AI 贡献比率
AI 贡献比率 = 包含 AI 生成初稿的 PR 数量 ÷ 当期总 PR 数量 × 100%
注意：这是中性指标，不是越高越好。结合返工率一起看：AI 贡献高 + 返工率低 = 正向信号。
审查拒绝率
审查拒绝率 = 被 Request Changes 的 PR 数量 ÷ 提交审查的 PR 总数 × 100%
健康指标参考范围
以下为参考起点，各团队应根据基线调整：
| 指标 | 早期目标 | 成熟期目标 |
|---|---|---|
| 周期时间（功能 PR） | ≤ 3 天 | ≤ 1.5 天 |
| 返工率 | ≤ 30% | ≤ 15% |
| AI 贡献比率 | — | 不作优化目标 |
| 审查拒绝率 | ≤ 25% | ≤ 15% |
| 部署频率 | ≥ 1次/周 | ≥ 1次/天 |
月度指标报告模板
## [年-月] 指标报告
### 数据
- PR 数量：
- 平均周期时间：
- 返工率：（/次标注"重大修改"的 PR）
- AI 贡献比率：
- 审查拒绝率：
- 部署次数：
### 与上月对比
- 改善项：
- 下降项：
### 原因分析
[简述改善或下降的原因，结合当月实际情况]
### 下月关注点
[基于本月数据，下月重点改善哪一项]
延伸阅读
- 人效评估：角色、能力与效率的推导框架 — 如何根据角色和能力推导合理的效率目标，以及 AI 对能力定义的影响
反指标：不应优化的指标
- AI 使用次数 — 频繁使用 AI 不等于质量更好，可能反而增加返工
- AI 生成代码行数 — 代码行数不是生产力指标
- 提示数量 — 提示多不如提示好；无效提示越多，维护成本越高