给团队定一个真能执行的 AI 编程预算

按人头封顶最先崩

每人一刀切的封顶是所有团队的第一反应，也是最先失败的方案，原因是结构性的：agent 开销随任务走，不随人走。同一个开发者仅仅因为任务变了——一次几百轮的大重构，或一个缓存行为很差的代码库——一周就能跑出平时五倍的花销。封顶罚的是工作量，不是人，三种标准崩法随之而来：

1. 封顶掐死了重任务——而那正是你当初买这些工具要干的事。
2. 轻度用户永远碰不到线——平均值失去意义，财务开始不信任整行预算。
3. 执行落在表格里，晚好几周，钱花完了、架也吵完了才被发现。

按工作量做预算，不按人头

拿真正决定 agent 开销的三个变量——轮次、重发上下文、缓存命中率——在团队尺度上做分配：

1. 用真实形状建模人均月成本，别用平均数：每日轮次 × 上下文大小 × 缓存行为。两周观测数据胜过任何行业基准。
2. 按项目或任务类型分配，不按人头：样板维护和硬架构活该走不同的通道，按此分流本身就是最大的诚实节省。
3. 封顶线设在观测形状的 80 分位，不是均值——正常一周就撞上的线，没人会当真。

在计量发生的地方执行

靠表格执行的预算是愿望。每个请求反正都在某处被计量——模型、tokens、缓存命中、费用，逐笔可查——预算就该住在同一个地方：每 Key 配额到点限流而不是默默超支，异常才告警而不是每行都叫，组织级汇总让财务看到一个能和账单对上的总数。当给你计费的东西同时也是执行预算的东西，预算就不再是吵架素材。

每周十五分钟的复核

每周三个问题，预算就能一直活着：缓存命中率趋势是平的还是下滑的？哪个 Key 或项目动得最多，工作量真的变了吗？有没有人马上要因为正当理由撞线、需要先调额度？这不是开会——是扫一眼三列的明细，它整个取代季度救火。