AI到底有没有提升产出，没人真正知道：测产出，别测使用量

问题是什么

公司逼着大家用AI，然后用使用量来衡量结果：多少个席位、多少次提示、代码建议被采纳的比例是多少。麻烦在于，使用量不等于产出。用得多并不保证工作变好，而在强制之下，使用量指标恰恰是最容易被灌水的地方。管理者看着仪表盘上的蓝线往上爬，就相信一切顺利，可真正的问题，也就是团队的成果有没有变好，却无人回答。

证据直指这种错觉。一项覆盖约6,000名高管的NBER调查显示，超过80%的企业感受不到AI对生产力的明显影响。开发一侧的遥测更为严峻。Faros AI追踪了2.2万名开发者两年，发现虽然75%的人使用AI工具，多数组织却测不出绩效提升；吞吐量上升了66%，但事故和缺陷上升得更快：每个合并PR引发生产事故的概率同比翻了三倍多，人均缺陷增加了54%。使用量上升、质量下降，就在同一段时间里同时发生。管理者正是在这中间蒙着眼睛做判断。

为什么是现在

眼下两股潮流叠在一起。一是AI强制推行已成主流。越是从上而下逼着用，越渴求一套衡量真实效果而非单纯使用量的办法。二是现有工具的盲区。工程领域已经有测量：Faros AI和DX的DX Core 4，从git和PR遥测中读取吞吐量与质量。但仍有两处空白。第一，这些工具大多依然在报告使用量和吞吐量，很难在因果上分辨某个人是否真因AI而变好。第二，销售、客服、运营、市场、法务这类没有git日志的知识工作，几乎没有对应工具。强制落在所有这些职能上，测量却止步于工程团队。

flowchart LR
  A[引入前基线<br/>每人的产出与质量] --> C[因果测量<br/>留出组·分阶段推广]
  B[使用AI后的产出<br/>速度·返工·错误率] --> C
  C --> D[每人的真实提升<br/>质量校正后的差值]
  D --> E[给管理者的诚实信号<br/>产出而非使用量]

怎么构建

从一个产出看得见的职能开始，做窄。以客服为例，产出就是解决时长、二次咨询率和质检评分。关键有三点。第一，为每个人留下引入前的基线。第二，做因果测量：用有人先开、有人后开的分阶段推广，或者留出组，从中取出真实的改善量，而不是相关性。第三，用质量做校正：如果变快了但返工、错误或事故增加了，就把这部分损失从产出中扣掉。由此得出的每人差值，安静地交给管理者。要把访问权限和展示方式收窄，让它被当作辅导信号，而非监控。

收入用团队或按席位订阅比较自然。想降低落地初期的抵触，就不要第一天就给人排名。先画一张团队层面的地图，展示哪类工作AI真正见效、在哪里空转。个人排名等信任建立之后再说。

成功条件

两个条件要同时成立。第一，你得能为每个职能定义一套抗刷、经过质量校正的产出指标。指标一旦松散，这个工具最终也会沦为又一块使用量仪表盘。第二，组织得能接受”这次强制没起作用”的诚实信号。把”没效果”甩到推动AI的高管面前，在政治上很不舒服，缺了容忍这种不适的文化，工具就会被塞进抽屉。跨过这两关的团队，才能剥掉使用量的游戏，第一次为AI究竟在哪里真正让工作变好而定价。接下来只剩一个问题：在我们团队里，AI此刻真正改善的工作，有几项。