3 篇博文 含有标签「engineering-metrics」

你的仪表盘从未如此好看。合并的 Pull Request (PR) 数量几乎翻倍。每个工程师的提交次数正在攀升。代码行数源源不断。每一个活动图表都呈现上升趋势，你在六个月前引入的 AI 编程工具看起来是公司今年最划算的一笔支出。

然后，你检查了一个没人会放在幻灯片里的数字：客户从提出需求到实际拿到东西需要多长时间。这个数字纹丝未动。在某些季度，它甚至变得更糟。团队正在产出更多的一切，除了业务真正买单的东西。

这就是“速度幻象”。容易统计的指标上升了，而真正重要的结果却在悄然下滑。这是目前工程领域最昂贵的衡量失败之一，因为它看起来完全像是成功。

一位工程负责人（Head of Engineering）在周一早晨打开了研发速率仪表盘。每周合并的 PR 数量：持平。完成的故事点：持平。改动的代码行数：低得可疑。图表显示，AI 团队在这个季度表现平平。而在两个楼层之外，那支团队在三周内重写了七次系统提示词（System Prompt），更换了一个让工具调用准确率翻倍的工具描述，增加了六个新的 few-shot 示例，并不断调整重排序（Rerank）指令，直到产品感觉像是一个完全不同的应用。所有这些工作都没有出现在 PR 图表中。但对用户来说，这些改变无处不在。

AI 团队所做的改动与工程仪表盘所测量的指标之间的不对称，已成为 2026 年最具影响力的误判。在重度依赖 AI 的产品中，行为的改变正日益与代码的改动解耦，而支配了软件组织十五年的指标——PR 吞吐量、提交量、涉及的代码行数——衡量的都是代码的改动。一个团队可能每周都在重塑线上响应的分布，但在领导层信任的每一张图表上，他们看起来却无所事事。

这里有一个应该让你感到不安的数字：根据《2025 年 DORA AI 辅助软件开发现状报告》，人均合并的开发者 PR 增长了 98%，而每个 PR 导致的事件增长了 242.7%。部署频率看起来处于“精英”水平。但系统的单位变更故障率比 DORA 测量过的任何时期都要高。

你的仪表盘是一片绿色。你的值班工程师却精疲力竭。测量尺度出了问题。