From Token Maxxing to Token Minimizing: Enterprises Start Counting AI Costs

0·8半年之内，Token Maxxing 结束。<br> 半年之内，Token Maxxing 结束。<br> 👩 作者: Shirley<br> 🥷 编辑: Koji<br> 🧑‍🎨 排版: NCon<br> 今年 3 月，Token Maxxing 兴起，一些公司甚至担心工程师用 AI 太少，纷纷搞起了内部员工的 Token 消耗排行榜。<br> 到了 6 月，公司们纷纷出台预算上限、动态配额和审批机制，掉头转向 Token Minimizing。短短几个月，没有产生 ROI 的 Token 用量变成财务系统里的警报。<br> 这场急转弯，恰好印证了**「十字路口」年初与真格基金管理合伙人戴雨森的**开年播客 ——他把 2026 概括为 The Year of R，并将商业回报 Return 放在第一位，企业会开始追问在 AI 上投资的 Return。<br> Tokenmaxxing：当消耗量成为 AI-native 的证明<br> 3 月 16 日，英伟达在 GTC 上把数据中心描述为生产 Token 的"AI 工厂"。三天后，黄仁勋做客 All-In 播客，把这套 Token 经济学推演到工程师身上。他说，如果一名年薪 50 万美元的工程师，一年的 Token 消耗不到 25 万美元，会令他深感不安。在他看来，这就像芯片设计师放着 CAD 不用，却只用纸和笔。<br> 在 Meta 内部，这场竞赛有了一块真实的记分牌。<br> 一名 Meta 员工自发搭建 Claudeonomics，把 8.5 万个内部账户的用量汇总成一张 Top 250 榜单。榜单不展示代码是否发布、产品是否上线，只根据 Token 用量授予「Token Legend」「Cache Wizard」「Session Immortal」等称号。The Information 的计算页显示，榜首员工 30 天消耗了 3,285 亿 Token，按默认模型组合和公开定价折算约 180 万美元，相当于黄仁勋所说年度标准的 7 倍。<br> 排行榜把 AI 采用变成了一场荒诞的"生产力表演"。<br> 一名微软员工向 Pragmatic Engineer 表示，他会让 AI 重读已有文档、起草不会落地的原型，只为避免显得"用得太少"。Salesforce 则把这种隐形压力直接搬到桌面上。Mac 桌面组件每 15 分钟更新个人 Token 支出，显示 Claude Code 和 Cursor 的最低消费目标，员工还能查看同事花了多少。<br> 同一套激励也出现在国内。今年 3 月，有员工在脉脉社区上爆料，腾讯为员工配置年均价值约 22 万元的 Token 资源。到了 3 月底，部分业务开始统计并排名 Token 用量。一些员工担心消耗不够，开始搭建没有实际意义的工作流，让 Agent 反复执行任务，甚至"接私活"，只为不在用量上落后。<br> Token Minimizing：账单开始接管<br> 排行榜在鼓励消耗，财务系统里的另一张表已经先报了警。<br> 传统 SaaS 多按席位收费，预算大致等于人数乘以单价。Agent 把这项相对固定的许可支出变成了波动的使用量支出：一项任务可能触发多次模型调用，携带不断增长的上下文，并在规划、生成、检查和重写之间反复循环。账单随任务复杂度、模型选择、上下文长度和重试次数波动，不再只跟人数走。<br> 从超支到限额<br> 4 月中旬，Uber 首席技术官 Praveen Neppalli Naga 公开透露，公司仅用四个月便耗尽了全年的 AI 预算，部分重度用户每月产生的 AI 账单高达 2,000 美元。<br> 一个月后，Uber 首席运营官 Andrew Macdonald 在 Rapid Response 播客中承认，Uber 上一季度约 25% 的代码提交来自 Claude Code，但并不意味着也多交付了 25% 真正有用的消费者功能。他补充，产出可能确实增加了，只是这条联系尚未建立。当他询问高级工程负责人，究竟有多少原本被搁置的项目因生产力提升而进入开发清单，对方仍无法给出答案。<br> 6 月 2 日，Uber 因预算告急开始踩下刹车，将 Claude Code、Cursor 等 AI 编程工具的月额度设为每人每个工具 1,500 美元。<br> 从工程团队到全公司<br> 两天后，这一转向出现在科技圈外。<br> 零售巨头沃尔玛把内部 AI 工具 Code Puppy 从不限量使用改为固定 Token 配额。据 Business Insider 报道，这款工具能让员工通过自然语言自行开发软件，过去一年间，用户从约 1,000 人增至 7.5 万人，采购、供应链、门店经理乃至按小时计薪的兼职员工都在使用，非工程师用户已与工程师相当。Token 治理从软件工程预算进入大型企业的日常运营。<br> 账单冲击也可能在用量没有增长时发生。同样在 6 月，一家 B2B 客服初创公司 Pylon 在超过 Anthropic Team 的 150 个席位后，需要迁移至 Enterprise，Token 改为按标准 API 价格另行计费。CEO Marty Kausas 称，这会让公司的 Anthropic 年化账单从 40 万美元飙升至 140 万美元，几乎一夜增加 3.5 倍。Pylon 随后要求客服团队追加 Token 必须经过审批。他认为工程团队使用最强模型"显然值得"，但其他岗位的回报并不明确：<br> "人们做出没人用的应用，重复开发别人已经做过的 Skills，根本没有实际 ROI。"<br> 国内大厂也沿着同一方向调整。据《经济观察报》报道，6 月，腾讯多个业务线员工的 Token 额度均有下降。混元大模型团队的员工月额度约 7,000 元，优图实验室约 5,250 元，另有腾讯娱乐外包员工透露自己的月额度只有 1,000 元。额度先进入部门池，再由管理者根据业务需要动态分配，有需求可以"举手申请"。<br> 额度缩减后，有员工调侃，"以前每天上班唯一要做的，就是狠狠鞭挞 Workbuddy；现在每天都要紧张地检查一下 Token 看板，生怕把它累着。"也有人感慨，"由奢入俭难，自己已经回不去古法编程了"……<br> 限额能止住账单，却回答不了钱该花在哪。企业需要把这张账单继续追踪到任务与交付结果上。<br> Token ROI：企业如何衡量 AI 回报<br> 7 月，Business Insider 援引 UBS 分析师的报告称，在近期与数十位企业 IT 高管的交流中，约 60% 的受访企业已经采取不同程度的管控措施来收紧 AI 支出。分析师把它描述为一个"健康的问题"：企业并没有停止部署 AI，Token 优化正在从预算超支后的应急措施变成持续性的工程纪律。<br> 理想情况下，核算口径大致是 Token ROI = 可验证的业务增量 ÷（模型成本 + 人工复核 + 重试/返工 + 工程治理成本）。但截至目前，公开实践中还没有一套被多家企业共同采用的标准。分子这侧，取决于各家的业务口径，很难有统一算法，不过已经有公司在朝这个方向逼近；分母这侧更确定，多数企业从这里入手，在任务和工作流层面进行核算。<br> 先看见支出：钱花在谁、什么任务上<br> 部分企业开始自建核算机制，服务商也把类似能力做成标准化工具。<br> Shopify 通过统一的大模型调用网关、用量看板和异常告警，按团队、项目和个人归集支出。单个用户一天的 Token 支出超过 250 美元会触发人工复盘，但高用量只会启动调查，不会直接被判定为浪费。<br> GitHub 与 Amazon 则试图把 AI 的使用与工程交付放在一起观察。<br> GitHub 7 月推出的 Copilot 使用指标影响面板按照 AI 采用程度将用户分组，比较合并的代码变更请求数量、合并速度和每日代码产出。<br> Amazon CloudWatch 的 Coding Agent Insights 更进一步，把 Token 用量与成本按模型、部门、团队和个人归集，与代码提交、活跃编程时间、建议接受率放进同一个面板。<br> 再验证结果：AI 最终留下了什么<br> 看板能回答谁花了多少 Token，还不能回答这些换回了什么。代码行数、提交次数、合并速度和建议接受率，依然停留在工程活动层。企业要继续往下追问的，是 AI 生成的代码有没有进入生产环境，有没有留在代码库里，又真正替代了多少人类工作。<br> Amazon 用于评估 AI 编程工具的指标之一是 normalized deployments，即标准化后的部署量。它把 AI 采用与团队的部署速度放在一起分析，同时观察回滚和人工干预。Token 消耗和代码生成量都不能直接记作产出；代码进入部署流程，并经受住生产质量检验，才算一次有效交付。<br> Cursor 观察的是 keep rate：Agent 生成的代码在一段时间后有多少仍留在代码库中。一次生成被开发者接受，只能说明它暂时可用；如果很快又被删除或重写，这部分消耗很难算作稳定回报。过去九个月，Cursor 一直用代码保留率和用户满意度评估模型更新与 Agent 工作流调整。<br> Cognition 走得更远。Devin 会评估每个已完成任务是否产生了有效结果，再估算同一项工作交给人类工程师需要多少时间。没有合并的代码变更，或者被判定为无效的任务，不计入有效产出。节省的工程时间随后被折算为金额，与企业的实际支出进行比较。<br> 这三种口径仍不能完整代表业务 ROI。代码上线不等于产生收入，节省工时也不意味着这些时间一定被重新投入到高价值工作。但它们把企业的观察对象从"AI 跑了多少"推进到了"最终留下了什么"——是否上线、是否留存、是否节省了真实的人力。<br> 有了这层结果口径，企业可以根据任务的质量要求、失败成本和预期价值，决定哪些请求交给轻量模型，哪些值得调用最强模型。<br> 在 Artificial Analysis 的最新综合测评中，国产模型 Kimi K3、Qwen 3.8 已经进入接近前沿模型的智能区间，但完成基准任务的平均成本明显低于 Claude Opus 5、GPT-5.6 Sol 等高价模型；DeepSeek V4 Flash 则处在成本更低的一端，为通过企业内部质量验证的常规任务提供了更便宜的选择。<br> 模型选择变多后，分配本身成了新的管理问题。缺少自动路由时，最熟悉或最强的模型仍会成为昂贵的默认项。<br> 腾讯云 AI 网关给出了一张直观的示意图。用户请求进入网关后，系统先识别它属于代码、数学、翻译、简单问答还是复杂推理，再将任务交给专项模型、轻量模型或旗舰模型。无法可靠识别或模型出现异常时，请求会回退到默认服务。<br> 这套路由逻辑也在成为云平台的标准配置。Amazon Bedrock、Microsoft Foundry 和 Google Vertex AI 都允许企业根据任务特征，在质量与成本之间动态分配请求。<br> 在 Coding 工具层，Cursor 也于 7 月 22 日推出 Router。它会结合请求内容、上下文、任务复杂度和所属领域，在 Intelligence、Balance 和 Cost 三种模式下选择模型。据 Cursor 官方披露，在覆盖数百万请求的在线 A/B 测试中，Router 在保持前沿水平质量的同时节省了约 60% 的成本。<br> 模型路由决定任务交给哪个模型，工作流设计则影响完成任务需要携带多少上下文、调用多少工具、经历多少轮循环。两者共同决定最终的 Token 支出。<br> 随着模型能力增强，一个问题开始变得具体：这些约束是能力不足时的补丁，还是与能力无关的工程纪律？<br> 7 月 25 日，Claude Code 团队的核心工程师 Thariq Shihipar 公开了一组数字：<br> 对于像 Opus 5 和 Fable 5 这样的最新模型，我们删除了超过 80% 的 Claude Code 系统提示词，且在最终的编码评估中没有任何可测量的性能损失。<br> 他给出的原因是「过度约束」。当他们阅读自己内部使用 Claude Code 的转录记录时，发现单个请求中出现了多条相互冲突的指令，比如"酌情添加文档"或"不要添加注释"，而往往 Claude 需要先分辨这些矛盾，才能决定怎么做。<br> 这些限制曾经是为了避免最坏情况而必要的，但团队现在发现，可以让模型依赖周围的上下文和判断来做出决策。他把这轮调整概括为以下几组前后对照。<br> 其中一组是从「给 Claude 定规则」到「让 Claude 自己判断」：过去系统提示词写明"默认不写注释，绝不写多段落文档字符串或多行注释块"，现在只留一句"让它读起来像周围的代码一样：匹配其注释密度、命名风格和惯用表达"。<br> 另一组是从「把所有内容都前置」到「采用渐进披露」：代码评审与验证被移进各自的 Skill，由 Claude 按需调用；部分工具改为延迟加载，Agent 在使用前必须通过 ToolSearch 搜索其完整定义。<br> 渐进披露不只出现在模型厂商一侧。Matt Pocock 那套在 GitHub 社区爆火的 Skill 库已积累超过 20 万星标，其中 The Main Flow 这条主工作流把从想法到交付的过程拆成五个阶段，每个阶段对应一个 Skill。<br> 想法还模糊时，先用 /grill-with-docs 接受追问，并把确认下来的决定记进文档；与 Agent 达成共识后，用 /to-spec 把对话变成一份书面规格；要开始动手，就交给 /to-tickets 拆成 Agent 能独立完成的小模块；进入编码，用 /implement 按测试先行的方式把规格变成代码；改动完成后，由 /code-review 对照团队标准和规格文档审一遍差异。<br> 五个 Skill 各自只在自己的阶段被调用，这正是 Thariq 所说的渐进披露：上下文不必一次铺满，需要时再加载。两人在这一点上并无分歧，关键在于约束本身。<br> Pocock 这条链仍在给模型定下硬规则，/implement 要求测试先行，/to-tickets 要求按用户功能垂直切分，明确禁止先把数据库建完再写后端。理由是，模型会习惯性地按技术分层推进，或在实现时走捷径。<br> 两种做法没有孰优孰劣。在 Thariq 那里，约束是能力不足时的补丁，模型强了就该拆掉；在 Pocock 那里，它是与能力无关的纪律，已经写进一套正在被使用的流程。<br> 从奖励消耗到限制预算，企业仅用几个月便完成了一轮 AI 成本校准。<br> 回到前文那个核算口径：Token ROI = 可验证的业务增量 ÷（模型成本 + 人工复核 + 重试/返工 + 工程治理成本）。<br> 其中，模型成本最清楚，调用与输出的价格都写在各家的官方页面上；人工复核难以准确计量，但工作流设计得当时理论上会下降；重试和返工同理，约束到位能够减少，具体减少了多少，企业正通过统一网关、用量看板建立归因；而工程治理成本，正是 Thariq 和 Pocock 各自在做文章的地方。<br> 我们不断追问的 Return，不仅是业务增长；如何降低模型成本、人工复核、重试返工和治理成本，同样值得企业优化。<br> 企业 AI 正从 Tokenmaxxing 转向 Token ROI maxxing。