“写代码更快”只是局部感受。若评审、返工和线上修复时间增加，总交付效率未必提升。评估应覆盖从需求开始到稳定上线的完整过程。
1. 周期指标
记录任务从开始到合并的时间、等待评审的时间和首次可用结果的时间。按任务类型比较，避免把简单任务与复杂任务混在一起。
2. 质量指标
观察回归缺陷、紧急修复、测试失败和评审返工。生成代码的接受率不能替代质量，因为被接受的代码仍可能有隐患。
3. 体验指标
定期询问开发者是否减少了重复劳动、是否更容易理解陌生代码，以及提示和修正是否造成新的疲劳。
4. 成本指标
统计工具费用、额外审查时间和培训投入，再与节省的人时比较。小规模试点通常比全员一次铺开更容易看清效果。
常见误区
- 只看代码生成量
- 不区分任务复杂度
- 忽略质量和返工
- 试用周期太短就下结论
执行检查清单
- 存在可比较的基线
- 同时记录速度和质量
- 按任务类型分组
- 每月复盘并调整规则
总结
提效应体现为更稳定、更快地交付有价值的软件，而不是让某个局部步骤看起来更忙。