衡量有用的进展

先定义结果，再选择指标

AI 工具可以快速生成代码。有用的结果则是一项达到所需质量水平、满足用户需要的修改。二者衡量的是不同事物。

生成行数、接受的建议数量和智能体运行次数描述的是活动。这些数据可以帮助理解工具的使用方式，但不能证明服务有所改善，也不能证明团队更快地交付了有用成果。

从一个问题开始。例如：“这套工作流能否减少完成小型维护任务所需的总投入？”收集结果前，先定义完成条件，纳入必要的测试、审查和文档。

考虑一个虚构的报表筛选修改。不使用 AI 时，实现需要 60 分钟，审查需要 10 分钟。使用 AI 时，实现需要 30 分钟，审查需要 45 分钟。

实现更快了。但这两个阶段测得的投入从 70 分钟增加到 75 分钟。两种结果都不包含准备、后续修正或发布后缺陷。应明确说明这些限制。

这些数字用于说明计算方法，不是研究结果，也不是对团队的预测。审查时间增加，可能源于更大的 diff、不熟悉的代码或缺失要求。修改工具策略前，先调查原因。

投入衡量的是人员实际工作的时间。总历时还包括等待。智能体可以在开发者处理其他任务时执行检查。不要重复计算同一段人工时间。也要记录修改等待审查或环境的时间。

工作流可能减少投入，却没有缩短交付时间。当审批队列决定完成日期时，就可能出现这种情况。节省的投入仍可能有价值，但组织需要另行决定如何利用它。

询问开发者，这套工作流是否帮助他们理解系统并保持专注。将回答作为体验数据，不要把“感觉更快”换算成已经验证的提升百分比。

METR 在 2025 年初针对有经验的开源开发者开展了一项研究，并报告了速度下降。该研究没有证实所有开发者或任务都会受到同样影响。其 2026 年 2 月的更新说明了后续实验中的选择效应和测量问题。

有用的启示在于测量方法。工具版本、任务选择、质量要求和参与者行为，都可能改变结果。不要把某个历史百分比作为 AI 开发的永久规律。

DORA 的 2025 年研究也提醒读者关注工具周围的组织条件。团队需要有效的开发实践，才能把工具能力转化为有用的交付成果。

使用有代表性的任务和相同的完成标准。记录模型与工具版本。计入失败尝试和审查投入。比较多项任务，而不是只选择效果最好的演示。

报告结果范围和主要限制。如果修改减少了投入，却增加了缺陷，应先调查，再扩大使用。如果结果有好有坏，就将建议限定在已有有效证据的任务类型上。

良好的测量为下一项具体决策提供依据。不需要证明 AI 在所有情况下都好或都不好。