“如果你的工作用不上当前的 AI 工具，那是一个发现，而不是一种失职。”亚马逊在一份给软件工程师的备忘录里这样写道，CNBC 报道了此事。对一家向其他企业卖 AI 的公司来说，这句话相当少见，也很容易被压成一条标题：亚马逊让工程师少用 AI。
这份备忘录比标题谨慎得多，而围绕它的争论比备忘录本身更重要。Token 如今已成为工程预算里的一行，各地的管理者都被问到亚马逊刚刚公开回答的问题：你怎么知道这笔钱真的买到了东西？下面我们会讲备忘录说了什么、没说什么，四款主流工具里一个席位实际花多少钱，以及上限在哪些情况下有用、哪些情况下有害。
Tokenmaxxing 本质上是排行榜问题
CNBC 把 tokenmaxxing 定义为开发者“尽可能多地使用 AI，却不太在意产出”。这个词在亚马逊内部有一段小小的来历。据 CNBC 报道，公司今年早些时候关闭了一个内部排行榜，因为发现员工为了爬榜在刷 tokenmaxxing。I-Programmer 的报道引用了 Financial Times 的消息，称这个榜单叫 Kirorank，只运行了几周，也从未获得官方批准。人们编造琐碎任务让 AI agent 去跑，token 的钱由亚马逊来付。
亚马逊并不是个例。同一篇报道说，Meta 今年早些时候关闭了一个员工自建的榜单，员工在上面争夺 Token Legend 之类的头衔，排名依据是在 Claude Code 里烧掉的 token 数量。报道还提到亚马逊高级副总裁 Dave Treadwell 早先泄露出的一条消息，他要求员工别再“为了用 AI 而用 AI”。
这种事不需要任何人不诚实。把一个数字摆在屏幕上，按它给人排名，这个数字就会往上涨。
备忘录说了什么，没说什么
据 CNBC 报道，这份备忘录在亚马逊发布到官网之前就已在内部流传。它修订了亚马逊对软件开发工程师及其经理职责的描述。核心结论与衡量方式有关。备忘录称，token 用量、AI 工具的采用率，以及代码变更或评审的数量，仍然都是评判团队 AI 使用情况的“严重有缺陷”的方式，因为它们可能推高成本、造成过度复杂。
它并没有禁止这些数字。它们应当“谨慎并带着判断”，与其他数据对照着看，备忘录偏好的衡量标准也说得很直白：“我们认为，最好是以长期成果来衡量，也被长期成果衡量。”
亚马逊一位发言人告诉 CNBC，公司并未对 token 用量设置上限。这一点很重要，因为“少用 AI”说过头了，超出了报道的范围。我们读到的报道里，没有任何内容提到配额、人均预算或具体金额。亚马逊没有说过自己花了多少，报道也无从得知。
AWS 副总裁兼杰出工程师 Marc Brooker 向 CNBC 分两层讲了其中的逻辑。公司看的是功能交付速度这类指标（上线了多少功能、有多少变更成功进入生产环境），并把这笔支出视为投资。他说，公司不想看到的是花在无关紧要问题上的“无效投入”，同时他承认，有时很难判断哪些问题无关紧要，所以仍然保留一定的试验空间。
这样看，这份备忘录更像一项绩效考核政策，而不是降本政策。我们会划线的是开头引用的那句话。在备忘录的措辞里，一个能说清 AI 在哪些地方暂时帮不上忙的工程师，是在“展现我们所期待的判断力”。这是公司在告诉管理者：别因为有人关掉了一个工具就惩罚他。
为什么卖 AI 的公司也要收手
最直白的答案是成本，而且数字增长得比预算快。为工程团队做工具的 Jellyfish 发布了一份关于 agentic 编码工具的报告，TechCrunch 做了报道。在 Jellyfish 的客户中，Claude Code 及其他基于 Anthropic 模型的工具的支出自年初以来增长了 10 倍，目前约占工程总成本的 2%。2% 不算多，但 Jellyfish 首席科学家 Nicholas Arcolano 对 TechCrunch 说：“这 10 倍的增长，是大多数 CFO 没有预料到的。”
Anthropic 自己的文档给个人成本划了一条底线。在企业部署中，Claude Code 的平均成本约为每位开发者每个活跃日 13 美元、每月 150 到 250 美元，90% 的用户每天花费低于 30 美元（Claude Code 文档）。这是供应商自家客户的平均值，所以真正该信的是你自己试点得出的数字。
还有两个原因是我们的推断，报道里并没有说明。一个以代码变更和评审数量为基础的指标，可能让评审者淹没在没人要的产出里。而一个追着用量数字跑的工程师，几乎没有理由去问这个任务到底需不需要模型。无论是备忘录的报道还是相关报道，都没有提到安全是原因之一，所以我们也不会假装它是。
微软的买断，和一个卖计量表的供应商
亚马逊的备忘录和另外几则公司如何让 AI 与账本对得上的新闻发生在同一周，但它们并不是同一个故事。微软向约 60,000 名符合条件的员工（约占其员工总数的 27%）提供了自愿买断，同时要在昂贵的 AI 基础设施建设与资本效率之间取得平衡。CNBC 把这件事和基础设施及现金流联系在一起，而不是任何人的 token 使用。同一篇文章确实提到，微软正尝试按客户实际使用的 AI 量收费，这相当于把计量表倒过来。
然后是那家最希望你多花钱的公司。Anthropic 发布了报告工具，管理者可以查看某个团队在一段日期内产出了什么、花了多少钱、工作流在哪里卡住，还有共享的团队预算池，方便团队管理 token 支出。TechCrunch 称这显然是在证明投资回报。不论你怎么看它的动机，这个产品反映出买家现在想要的东西：按产出算成本，而不是按席位算成本。
先搞清楚一个席位到底花多少钱
先找一个试点小组，建立基线，并且在任何人写下上限之前就做。供应商都转向了按用量计费，所以席位的标价每年能告诉你的东西都在变少。下面是各主流工具计量的内容，来自供应商自己的页面。
| 工具 | 计量对象 | 在哪里设上限 |
|---|---|---|
| GitHub Copilot | Token 按每个 $0.01 折算成 AI credits。Business 每用户每月共享 1,900 credits，Enterprise 为 3,900 | 用户、成本中心和组织层面的美元预算 |
| Cursor (Teams) | 每个付费席位每周一份额度，用于 Cursor 自家模型。第三方模型从共享的预付余额中扣费 | 团队月度上限，另有默认上限和单成员上限 |
| Claude Code | API token。Teams 和 Enterprise 使用席位额度 | 管理设置中的支出上限，或 Console 工作区上限 |
| Codex (ChatGPT) | 与 ChatGPT Work 共享额度，用完后用 credits | 自行购买的 credits，以及用来观察消耗节奏的用量面板 |
文档里有几个细节，是价格页不会告诉你的。Copilot 的付费用量策略对 Business 和 Enterprise 默认开启，所以超出共享 credits 的部分会继续计费，除非管理员明确关闭（GitHub 文档）。即使预算设为 $0，行内补全也依然不限量。Copilot 代码评审按力度档位定价：GitHub 估计 Lite 为 $0.05 到 $1，Max 为 $1.50 到 $25，平均约 $10，另加 Actions 分钟数（GitHub 模型与定价）。这些只是估算，文档也说 pull request 的大小会影响结果。
如果你在比较编辑器本身，Cursor vs GitHub Copilot vs Windsurf 有详细对比。Cursor 的 Teams 方案按每月 $30、$100 和 $200 出售 Premium、Super 和 Ultra 席位，每个席位都有自己每周的 Cursor 自家模型额度，队友之间不能转让。第三方模型（包括 Claude）不在额度内：它们从共享的预付余额中扣费，按 API 标价再加每百万 token $0.25 的 Cursor 费率（Cursor 文档）。Claude 的 Enterprise 方案是每席位每月 $20，外加按 API 费率计费的用量（Claude 定价）。Codex 定价页明确说了，API token 价格与订阅用量是分开的，不应拿来估算包含的任务量。
把常规工作交给更便宜的模型
文档里最大的杠杆不是上限，而是模型。在 Anthropic 的 API 价格表上，对于不超过 100,000 token 的 prompt，Claude Haiku 5.5 每百万输出 token 收费 $0.50（超出后升至 $2.50），Sonnet 5.5 为 $10，Opus 5.5 为 $20，Fable 5.1 为 $50。同一产品线从底部到顶部相差 100 倍，GitHub 和 Cursor 的表格列出的输出价格也一样。
Anthropic 自己的成本指引与这笔账一致。它说 Sonnet“能很好地处理大多数编码任务，而且比 Opus 便宜”，Opus 留给架构决策或多步推理，简单的 subagent 任务用 model: haiku（Claude Code 文档）。我们对按任务匹配模型档位的更完整看法在哪个 AI 模型档位适合哪类任务里，终端 agent 的对比则在 Claude Code vs Codex vs Gemini CLI。
下面按标价算能省多少，小模型能承担的工作占比由你自己估计。价格为 Anthropic 针对短 prompt 的标价。
输出 token 只是账单的一部分，小模型占比这个假设也得靠你自己的任务去验证。重命名变量、写测试脚手架大概可以。支付服务的迁移方案大概不行。
我们建议的上限设置顺序
- 为试点小组开启用量报告，先看两周数据，再决定任何数字。
- 先设提醒。GitHub 可以在预算达到 75%、90% 和 100% 时发邮件并显示横幅（GitHub 文档）。
- 再设一个全公司的月度上限，数额以“即使每个席位都用满也能承受”为准，这样失控的 agent 循环最多花多少是可知的。
- 然后才加团队或个人限额，工具允许的话尽量设成软限制。GitHub 的用户级预算总是硬性停止，其文档还警告说，预算重叠可能让人用不了自己依赖的工具。
- 把常规工作的默认模型下调一档，让高端模型成为刻意的选择。
Claude Code 文档还按团队规模给出了每用户速率限制的起点，例如 100 到 500 名用户时每人每分钟 15,000 到 20,000 token。这些是限流，不是预算，文档也说它们只是建议，需要自行调整。
什么时候限额是明智的，什么时候是假节省
我们的原则是限制浪费，但不限制尝试。如果一个上限能让开发者在把整个代码仓库贴给顶级模型之前多想一下，它就在发挥作用。如果它让同一个开发者跳过 AI 生成的测试运行，或者在最适合用 agent 的疑难重构上不敢用它，那它花的比省的多。
算一下账。如果像 Jellyfish 报告的那样，agentic 工具约占工程成本的 2%，那么把账单砍一半，只省下 1% 的工程成本。一个工程师效率被拖慢 1%，就把这点省下的钱吐回去了。限额只有在砍掉了毫无产出的支出时才划算，这正是亚马逊关于无效投入的观点。
对没人看的后台自动化、对常规任务用顶级模型，以及对个人排行榜，限额是明智的。对代码评审、测试和新人上手，限额是假节省。如果正是 AI 评审这一步拦住了有问题的合并，限制它就是在拿你自己的安全网下注。在你砍掉任何东西之前，我们的 AI 代码评审工具指南和评审与测试方向的 ToolRank 榜单可以让你看到有多少替代方案。
我们不会砍的东西
无论代码由哪个模型写的，人工评审都要保留。亚马逊的备忘录提醒不要用评审数量来衡量，但并没有建议跳过评审。培训也要保留，因为知道什么时候该用便宜模型的人，是被教过每个模型适合做什么的人。试验也要保留，因为 Brooker 自己承认，没人能提前知道哪些问题重要。
要像备忘录那样追踪成果：上线数量、成功进入生产环境的变更、从提出需求到合并的时间。原始 token 数应该放在成本栏里，绝不要靠近绩效评估。如果你还没写下团队能和不能把什么喂给这些工具，我们的 AI 使用政策模板可以作为起点，定价模式详解和技术栈审计则涵盖订阅方面的内容。
读完 GitHub Copilot、Cursor、Claude Code 和 Codex 的定价页，我们只得出一条规则：席位价格只是入场费。从你在用的工具里拉出最近一个月每个人的用量，排好序，看前五行。如果他们是你最好的工程师，别去动他们。如果是某个循环里跑的一个脚本，你就找到了该设的那个上限。