4 篇博文 含有标签「metrics」

仪表板显示，你的工程师在上个季度采纳了 45% 的 AI 建议。管理层将其解读为“节省了开发人员 45% 的时间”，并签署了续约合同。与此同时，工程师们正在悄悄重写他们采纳内容的一半，调试另一半，并纳闷为什么他们的 Sprint 看起来还是和以前一样长。双方都在看同一个数字，但只有其中一方看对了数字。

2025 年引用次数最多的这项研究，本应单枪匹马地终结“厂商仪表板时代”。METR 衡量了经验丰富的开源维护者在有无 AI 的情况下，处理自己代码库中真实问题的表现。开发者预测 AI 会让他们提速 24%。实验结束后，他们仍然认为 AI 让他们提速了 20%。但秒表显示他们慢了 19%。故事与数据之间存在 39 个百分点的差距——而季度评审中采用的正是那个“故事”。

你的 LLM 幻觉率是 3%。但你的用户仍然讨厌它。这并不矛盾 —— 而是衡量标准错误的症状。

幻觉率已成为 LLM 质量的默认头条指标，因为它很容易向利益相关者解释，且在基准测试（benchmark）中计算起来非常简单。但在生产环境中，它与用户真正关心的东西相关性很低：任务是否完成、结果是否值得信赖并足以据此行动、以及系统是否为他们节省了时间？

你的 AI 功能满意度评分是 4.2/5，用户点赞率高达 68%，A/B 测试显示任务完成率提升了 12%。团队决定上线。六周后，用户已悄然绕开它，遇到真正重要的事情时不再使用。

这就是指标表演。你优化的是看起来像成功的信号，而不是真正的成功。你收集到的反馈来自那 8% 愿意评分的用户——偏向极度满意和极度不满的两端，对那沉默的大多数一无所知——他们发现该功能时不时不可靠，于是悄悄停止信任它了。

构建 AI 功能需要一套与传统软件不同的度量哲学。你从第一天起就埋下的信号，决定了你是否能足够快地学习并改进，还是花六个月追着一个纹丝不动的满意度分数跑。

大多数采用 AI 编程工具的团队都会遇到同样的瓶颈。第一个月看起来像是成功案例：PR 吞吐量上升，Sprint 速率在攀升，工程经理正在制作幻灯片准备向领导层汇报。到了第三个月，事情悄然发生了变化。事故率开始回升。资深工程师在代码审查上花费了更多时间。一个简单的 Bug 修复现在需要理解一段团队中根本没人写过的代码。生产力的提升已经消失殆尽 —— 但衡量体系从未捕捉到这一点。

问题在于，大多数团队最先关注的指标 —— 生成的代码行数、合并的 PR 数量、消耗的故事点数 —— 对于 AI 辅助开发来说是错误的衡量单位。它们衡量的是产出代码的成本，而不是持有代码的成本。AI 让产出几乎变得免费，却让持有成本保持不变。