衡量 AI 是否真的在起作用¶
别用"写了多少代码 / 提了多少 PR"骗自己。AI 是放大器——放大团队既有的强项和弱项；ROI 来自流程改造，不是工具本身。
北极星：DORA + 质量护栏（团队级）¶
| 维度 | 指标 | 说明 |
|---|---|---|
| 速度 | 交付前置时间、部署频率 | 故事从开工到上线的时长 |
| 稳定 | 变更失败率、缺陷逃逸率、回滚次数 | AI 提速但常拉低稳定性，必须盯 |
| 瓶颈 | PR 评审时长趋势 | 行业数据：高 AI 采纳团队评审时长可涨 90%+，评审会成新瓶颈 → 优先投评审自动化（见 code-reviewer 子代理） |
AI 领先指标（辅助，别当 KPI）¶
- 每周自报"AI 省下的工时"（主观但有用）
- skill / 命令触发率：哪些范式真在被用、哪些没人用 → 月度治理时裁撤或改描述
- 对 AI 产出的信任分（1–5 自评）
各角色信号卡（吞吐 × 质量护栏）¶
| 角色 | 吞吐信号 | 质量护栏 |
|---|---|---|
| 技术/项目经理 | sprint 计划耗时 ↓ | 变更失败率、评审时长 |
| 产品经理 | 故事产出 / 就绪率 | 返工率（开发打回的故事） |
| 后端 | 故事交付数 | 缺陷逃逸、测试覆盖率、评审时长 |
| 前端 | 页面交付数 | 视觉 / 交互返工、控制台报错 |
| 测试 | 用例数 / 自动化覆盖 | 漏测率、误报率 |
| 运维 | 变更 / 部署数 | 变更失败率、MTTR |
自动采集（少靠手填）¶
让数据自己流出来，别全靠主观周报：
- 交付前置时间 / 部署频率：Gitee PR 时间戳（开 PR → 合并）+ CI/ArgoCD 部署记录；用 Gitee MCP 拉 PR 列表与合并时间。
- 评审时长趋势：Gitee PR「创建 → 合并」间隔的周中位数（盯是否随 AI 采纳变长——行业常见副作用）。
- 缺陷逃逸 / 变更失败率：PingCode CZTST 缺陷按"发现环境（测试/生产）"分类 + 回滚次数（czerp-gitops 记录）。
- 故事就绪率 / 返工率：PingCode CZKB/CZPRJ 故事状态流转 + 被开发打回次数。
- skill / 命令触发率：先约定各自每周粗记常用 skill；后续可接 Claude Code 使用日志。
落地：技术经理用
czerp-manager的status-digest命令把 Gitee + PingCode 的工作项活动/提交/PR 聚合成站会/周报草稿，作为月度指标复盘的原始素材；上文那套指标（前置时间、评审时长中位数、缺陷逃逸等）仍需人工或后续专门 skill 在此基础上汇总——能自动流出来的先交给 AI。
节奏¶
- 每月：AI 协作指标复盘 + skill 库治理（与
02流程图节奏一致）。 - 每季：工具栈大版本评估。
- 给 3–6 个月再判断 ROI，别用不足一个 sprint 的数据下结论。
反直觉提醒：个人产出大涨 ≠ 组织交付变快。若吞吐升、稳定性降，是在用债务换速度——这正是护栏
04要拦的。