每月烧5万美元token的工程师是不是浪费，没人答得上来

那个一个月烧掉五万美元的工程师，该怎么办

Rippling有一位工程师一个月在token上花了5万美元。放到公司层面，AI token支出以每月80%的速度膨胀,一度冲上烧掉研发人力预算40%的轨道，高峰月流过6,050亿token。10%到15%的员工制造了60%的总支出（TechCrunch）。

难的不是把支出压下去，而是决定怎么处置那位烧5万美元的工程师。如果是浪费，就该拦；如果产出对得起这笔钱，正确动作恰恰相反：让其他人学着他那样用。只有支出排行榜分不出这两种情况，而大多数公司手里恰恰只有排行榜。

Rippling为了回答这个问题自研了内部工具，随后把它做成产品AI Spend Console（Rippling）。它把员工、团队、岗位粒度的支出，和GitHub、Salesforce这类业务系统的信号接在一起：PR数量、代码交付速度、代码评审里被要求返工的频率，甚至贡献的营收（Business Wire）。结果很说明问题。治理之后，Rippling七月的token用量是6,000亿个，接近峰值，成本却只有四月的37%。用量没有降，被去掉的只有浪费。

一家公司因为自己的痛自研的工具，本身就是品类成立的证明。不过Rippling的产品绑在自家HR套件上，重心也偏支出管控。把归因测量本身当产品卖的中立层，位置还空着。大厂可以自研，腰部公司自研不起，这层空隙就是生意。

在包月时代，这个问题根本不成立

去年之前这种测量根本不成立。按席位包月时，所有员工的AI成本一样，没有按人看的理由。转成按量计费后，同一岗位内个人支出拉开几十倍差距，“这个差距有没有体现在产出上”这个问题才第一次问得出口。

第一波应对已经过去了。预算上限、低价模型路由、团队额度，管控工具已经出齐，落地也完成了。管控一到位，下一个问题立刻到来：留下的支出里，哪些该保护，哪些该加码。Rippling的顺序就是如此，先拦住，再造测量工具。

产出数据也终于以可关联的形态存在了。工程组织的PR、周期时间、评审返工率全都有API，销售组织的管线沉在CRM里。支出日志有，产出日志也有，缺的只是两者之间的一次关联。缺的那次关联，就是产品。

把支出日志和产出日志接起来的那一次连接

flowchart LR
  A[网关·SSO<br/>使用日志] --> C[归因引擎]
  B[GitHub·Jira·CRM<br/>产出信号] --> C
  C --> D[团队·同组<br/>ROI视图]
  D --> E[该加码的地方<br/>和该削减的地方]
  E --> F[头部用户模式<br/>的内部推广]

采集层不用新建。多数公司已经用LLM网关或代理收拢调用，身份、模型、token从这些日志里拿，GitHub、Jira、CRM走现成API。难的不是管道而是对照设计：按同岗位、相近年资组队列，展示AI使用强度不同的人产出差在哪里。如果一上来就发个人排行榜，产品会被读成监控工具，一线马上开始污染数据。默认展示团队和队列，个人下钻放在权限后面。

第二层才是这个产品真正的差异点。把产出效率最好的头部用户在什么任务上用什么模型的模式提炼出来，变成其余组织可以照抄的手册。走到这一步，买单的人就变了。省钱是CFO的事，人怎么工作是CTO和人力部门的事。这个产品的站位是FinOps工具和人才分析之间的空格，不绑任何一家HRIS的中立性就是对Rippling的护城河。

把相关当因果卖，第一次数据复盘就垮

最危险的假设，是把支出和产出的相关性当因果卖。如果只是本来就强的工程师恰好也重度用AI，这个工具的建议在第一次认真的数据评审上就会塌。队列设计要保守，克制到只说”在这个团队这个时间窗观察到这个差异”，这份克制就是产品信誉的全部。

第二是古德哈特定律。PR数量一进考核，PR马上被切碎。要混入难刷的指标，返工率、周期时间、事故率，并定期轮换指标构成。最后是扩张顺序：从产出可测的工程侧起步，急着扩到测量模糊的岗位，数字的公信力会全盘崩掉。Rippling那个40%究竟是一家公司的事故，还是明年所有公司的默认值，答案决定这个市场有多大。