Satya Nadella说过，微软的代码库中已经有20%到30%的代码由AI生成。

但这句话有一个后续，Nadella没有在公开场合说——微软刚刚关掉了负责生成那些代码的最重要的AI工具。

2026年5月底，微软宣布将在6月30日终止旗下Experiences & Devices业务部门大多数工程师的Claude Code使用权限，这个部门负责Windows、Microsoft 365、Outlook、Teams和Surface等产品线。这个试点从2025年12月启动，持续了六个月。

这是迄今为止最大规模的AI coding agent公开失败案例，但它失败的原因，几乎没有一家媒体写清楚了——不是因为工具不好用，而恰恰是因为太好用了。

事件：从试点到关闭的六个月

Microsoft这个试点启动于2025年12月。彼时，企业软件开发者之间已经在流传Claude Code的各种传说——它不只是代码补全工具，而是真正能够理解整个代码库上下文、执行复杂重构任务、自主调试的coding agent。

微软Experiences & Devices部门是一个拥有数千名工程师的大型组织，负责产品包括Windows操作系统、Microsoft 365生产力套件、Outlook邮件客户端、Teams协作平台和Surface硬件产品线。这些产品的代码库庞大复杂，是测试AI coding agent极限的理想场景。

试点启动后发生了什么，Forbes的Janakiram MSV在报道中用了「预算失控」这个词。

具体的失控机制，可以通过Uber更早发生、更完整披露的类似事件来理解。Uber首席技术官Praveen Neppalli Naga在2026年4月向The Information披露：从2026年2月到3月，Uber工程团队使用Claude Code的比例从32%飙升到84%，覆盖了他管理的约5000名工程师中的绝大多数。AI工具月均使用支出为每工程师150美元到250美元，重度用户可以达到每月2000美元，Naga本人在一次两小时的演示中花了1200美元。

结果是：Uber将全年AI coding预算在四个月内全部烧完。

微软的数字尚未公开，但「耗尽全年AI预算」的结果和Uber基本一致。根据Forbes的报道，官方给出的终止理由是「工具链统一」——标准化到GitHub Copilot CLI。但报道同时指出，6月30日是微软财年的最后一天，这个时间节点并非巧合。

解剖「越好用越超预算」的悖论

要理解为什么Claude Code会导致预算失控，需要理解它的定价结构——以及这个定价结构如何与企业的传统软件采购思维产生了根本性的摩擦。

传统企业软件的定价模式是「席位制」：你购买一千个席位，支付固定的年费，无论这一千个人用多还是用少，账单都是一样的。财务部门爱这种模式，因为可预测、易预算。

Claude Code的定价是「token计费」：工具使用得越多，消耗的token越多，账单越高。一个工程师用Claude Code重构一个小型功能，可能花费几美元；让它去分析和重写一个数万行代码的遗留系统模块，可能要花几百美元。一个运行了数小时的自主agent任务，账单可能高达数千美元。

这两种定价模式碰上同一个现实，会产生截然不同的结果。

当工具是席位制时，管理者的最优策略是「最大化使用率」——既然钱已经付了，让工程师多用就是多赚。企业会建立激励机制推动使用，因为使用越多，单位工具成本越低。

当工具是token计费时，管理者应该采用的策略是「优化产出/成本比」——每一笔token支出都应该对应可衡量的业务价值，而不是鼓励无约束的使用。但这需要新的成本治理框架，需要开发者树立token成本意识，需要组织在「工程师自由使用工具」和「token支出可控」之间找到平衡。

问题是，当微软和Uber在2025-2026年推广Claude Code时，他们带入的是席位制时代的管理思维。

Uber的CTO建立了「Claude Code使用量排行榜」，对工程团队中的重度用户进行公开表彰——这个激励机制在席位制工具下是完全合理的，但在token计费模式下，它把最好的工程师变成了最大的成本中心。排行榜越有效，预算超支越严重。

微软面对的是同样的问题。一个大型复杂代码库，加上数千名工程师，加上没有建立新的成本治理框架，结果是几乎必然的：token消耗指数级增长，预算耗尽只是时间问题。

372家企业的镜像：这不是两个异类

最容易犯的错误，是把微软和Uber视为两个「动作太快、管理不善」的特例，然后认为这对自己公司不适用。

Mavvrik和Benchmarkit在2025年对372家企业进行的AI成本治理调查，把这个安慰性的想法彻底戳破了。

调查发现：只有15%的企业能将AI成本预测在实际值10%误差以内；大多数企业的预测误差在11%到25%之间；近四分之一的企业误差超过50%。这不是少数例外，这是系统性的集体失准。

Mavvrik的首席执行官在报告发布时预测：「真正的清算将在2026年上半年到来，那时试点项目将大规模转入生产。」从微软和Uber的案例来看，这个预测相当精准。

成本预测之所以如此困难，根本原因在于AI工具的使用模式与传统软件工具有根本性的差异。

传统代码编辑器（VS Code、IntelliJ等）的使用模式是高度可预测的：工程师打开编辑器，编写代码，关闭编辑器。使用量与工作时间线性相关，很容易基于团队规模估算。

AI coding agent的使用模式有根本性的不同：一个工程师可能花五分钟让agent去分析整个代码库并生成架构评估报告（消耗数十美元token），也可能发出一个「修复这个模块中的所有测试用例」指令后去开会两小时（agent在后台持续运行，消耗了几百美元token）。使用量与「工程师投入的时间」脱钩，与「任务复杂度」和「agent的主动程度」高度相关——而后两者都很难提前准确预测。

这种不可预测性，在企业将AI工具从试点推广到大规模生产部署时，会产生指数级的成本不确定性。

但Salesforce成功了：同样的工具，不同的框架

这个故事到这里，很容易得出一个错误结论：Claude Code是一个「好用但太贵」的工具，企业应该谨慎使用。

但这个结论忽视了一个关键的反例。

就在微软宣布终止Claude Code的同一周，Salesforce发布了一篇题为「我们如何真正实现Agentic」的工程博客，详细披露了他们全面拥抱Claude Code的成果：

2026年4月的数据显示，Salesforce工程团队切换到Claude Code并取消token限制之后，每位开发者完成的工作项增加了50.8%，PR（代码合并请求）合并数量增加了79%，有效产出提升了151.3%。一个具体的案例：一个团队使用Claude Code将一项需要231人天才能完成的API迁移工作，压缩到13天内完成——相当于18倍的速度提升。

同样的工具，微软叫停了，Salesforce加码了。这个反差需要解释。

关键的分歧在于管理者用什么框架来理解AI coding工具。

微软和Uber使用的框架：AI工具是「工作效率工具」，应该被视为可控成本——席位制授权，固定预算，控制在IT支出的某个比例内。当实际成本超出这个框架的预期时，工具被关停。

Salesforce使用的框架：AI工具是「算力投资」，应该被视为生产要素——就像数据库服务器、计算实例一样，根据业务产出的增长来决定投入规模，而不是根据预设的固定预算上限来限制。当工具产出显著超过成本时，加大投入，而不是关停。

这两种框架下，面对同样的token账单，决策方向截然相反。

在席位制框架下，「每工程师每月200美元token费用」看起来是高昂的额外成本。在算力投资框架下，「200美元token支出换来50.8%的产出增幅」是显著正收益——因为一个工程师的月薪通常在数千到数万美元之间，50%的产出提升相当于花200美元买到了免费的半个工程师。

真正的问题：这是定价模式的错，还是认知框架的错？

现在有一种流行的叙事：Anthropic（和其他AI工具公司）应该转向seat-based（席位制）定价，以解决企业的成本可预测性问题。

这种叙事有一定道理，但只看到了问题的表面。

token计费的本质是：让每一笔计算支出与实际的工作量挂钩。一个简单的代码补全，消耗的token和算力远小于一个复杂的全代码库重构，两者理应有不同的成本。如果切换到席位制，简单任务和复杂任务的成本被人为抹平——这对低使用量用户不公平，对高使用量用户则是隐性补贴，整体会推高定价基准，让偶尔使用的用户承担更多成本。

真正需要解决的问题，是企业的成本治理框架需要从「席位制思维」升级到「算力消费思维」。

这意味着：不是设定固定的工具预算，而是设定「每产出单位的最大可接受成本」；不是建立使用量排行榜激励无约束使用，而是建立「AI工具ROI仪表盘」追踪每笔支出对应的业务价值；不是统一关停高消耗工具，而是分析哪些任务类型的AI辅助有正收益、哪些没有，然后有针对性地分配token预算。

对于已经在面对或预期将面对这个问题的企业技术管理者，有几个实践建议值得考虑：

第一，在试点阶段就建立成本监控，而不是等到大规模铺开后才看账单。具体做法是：要求所有工程团队在使用AI工具时记录任务类型、耗时、产出（代码行数、测试通过率、PR合并率等），以及token消耗，建立基线数据。

第二，按任务类型设置差异化的token预算，而不是按人头设置统一上限。代码审查、文档生成这类低复杂度任务，可以允许较高频次使用；全代码库重构、新功能从零开始开发这类高复杂度任务，应该需要工程师先做可行性评估再启动agent。

第三，用「产出提升 vs. token成本」的比率，而不是「token消耗是否在预算内」，作为AI工具价值的主要评估指标。这个框架切换，从根本上改变了管理者在面对高token账单时的决策逻辑——问题从「为什么这么贵」变成「这笔钱买到了多少产出提升」。

Salesforce能成功，恰恰是因为他们在推广Claude Code时，就已经建立了这套产出监控框架，使得高token消耗与高产出增幅之间的关系变得清晰可量化。

对Anthropic的战略影响

微软事件对Anthropic而言，是一个需要认真应对的战略信号，但并非单纯的负面事件。

一方面，Anthropic正处于快速商业化的关键时期。最新融资数据显示，Anthropic的年化收入已经超过470亿美元，其中Claude Code的企业端大规模采用被分析师视为核心收入驱动力之一。微软的退出，以及可能随之而来的类似案例，将在短期内给Claude Code的企业客户增长带来阻力，也可能引发潜在客户对「预算可控性」的担忧。

另一方面，这个事件也恰恰提供了Anthropic深化与真正理解使用方法的企业客户关系的机会。Salesforce的成功案例，是一个强有力的销售反证：「同样的工具，Salesforce的产出提升超过150%，为什么你们没有？让我们一起来建立正确的使用框架。」这个对话，比任何功能演示都更具说服力。

Anthropic已经组建了规模超过15亿美元的企业服务合资公司（与Blackstone和Goldman Sachs合作），正是为了部署Forward Deployed Engineers（前线部署工程师）——深入企业内部，帮助企业客户建立有效的AI工具使用框架和成本治理体系。微软事件的发生，反而可能加速企业客户对这类服务的需求。

这场关于AI coding agent商业可持续性的审判，最终的裁决结果，比我们今天想象的要复杂得多。

行业层面的转折点

把微软、Uber和Salesforce的案例放在一起看，可以清晰地看到一个行业层面的转折点正在发生。

2025年的AI工具推广浪潮，更多地是在技术层面证明「AI能做到这件事」。试点项目的成功标准是「工程师觉得好用」，而不是「公司的财务报表改善了」。这种评估框架下，token预算问题被有意无意地回避了——一方面是企业财务部门还没有意识到问题的量级，另一方面是技术决策者有意避免成本讨论影响对新技术的热情。

2026年，当试点转入大规模生产部署，真实的token账单开始出现在CFO（首席财务官）的月度报表里，评估框架不可避免地要从「工程师体验」转向「财务可持续性」。微软和Uber的案例是这个转折的早期警示。

这个转折的规模有多大？Mavvrik的调查数据给出了参考：372家企业中，近四分之一的企业AI成本误差超过50%。这意味着，当这些企业的AI工具试点开始大规模铺开，财务上将出现系统性的震荡。

从三个月视角来看，AI coding agent行业将经历一次必要的商业模式成熟过程：

在企业侧，CFO和CTO将不得不建立新的AI成本治理框架。这不只是技术问题，而是一个组织管理问题：如何为消耗性算力资源设定合理的预算框架，如何衡量AI工具投资的实际产出，如何建立使得工程师有动力高效使用（而不是无约束使用）AI工具的激励结构。Mavvrik等AI成本治理工具公司，正在这个需求兴起的早期阶段快速成长。

在工具侧，Anthropic和其他AI工具公司将面临更大的压力，提供更精细的成本控制选项——包括按任务类型设置token消耗上限、按项目和团队分配token配额、在执行前提供预测性的成本估算（让工程师在启动高成本任务前知道大概的花费）、提供月度成本分析报告帮助企业理解支出构成。

在市场侧，真正能帮助企业建立AI工具ROI框架的产品将出现显著的市场需求。这包括AI工程效率监控平台、AI成本与产出关联分析工具、以及专门帮助CTO和CFO进行AI工具预算决策的咨询服务。

这三个方向的发展将共同构成「AI工具商业模式2.0」的基础——从早期「工程师试用」阶段，向成熟「企业规模化部署」阶段的过渡。这个过渡必然伴随着阵痛，微软和Uber的案例不会是最后一个。

对Anthropic的战略影响

微软事件对Anthropic而言，是一个需要认真应对的战略信号。

一方面，Anthropic正处于快速商业化的关键时期。2026年5月的最新融资数据显示，Anthropic的年化收入已经超过470亿美元，其中Claude Code的企业端采用被分析师视为核心收入驱动力之一。微软的退出，以及可能随之而来的类似案例，将在短期内给Claude Code的企业客户增长带来阻力。

另一方面，这个事件也恰恰提供了Anthropic深化与真正「懂得用法」的企业客户关系的机会。Salesforce的成功案例，是一个强有力的销售反证：「同样的工具，Salesforce的产出提升超过150%，为什么你们没有？让我们一起来建立正确的使用框架。」

Anthropic已经组建了规模超过15亿美元的企业服务合资公司（与Blackstone和Goldman Sachs合作），正是为了部署Forward Deployed Engineers（前线部署工程师）——深入企业内部，帮助企业客户建立有效的AI工具使用框架和成本治理体系。微软事件的发生，反而可能加速企业客户对这类服务的需求。

从更大的竞争格局来看，微软退出Claude Code并非完全是损失——微软转向自家的GitHub Copilot CLI，意味着Anthropic在一个关键的企业软件渗透入口上失去了立足点，但同时也意味着微软将不得不独立承担AI工具成本治理问题的压力，而GitHub Copilot的使用同样面临类似的成本挑战（只是Copilot的定价结构不同，且微软可以通过内部转移定价吸收这部分成本）。

结语：工具没有问题，是问题框架的问题

微软终止Claude Code，既不是AI coding agent失败了的证明，也不是「企业不应该投资AI工具」的教训。

它是一个非常具体的教训：当一种新型工具的成本结构与企业现有的管理框架根本不兼容时，工具会先被广泛使用，然后被无约束滥用，最后被预算危机逼出决策的视野——不是因为工具不好，而是因为组织还没有为这种工具准备好配套的使用和管理框架。

Salesforce的对照组告诉我们：同样的工具，用正确的框架管理，可以产出超过150%的生产力提升。微软的案例告诉我们：用席位制时代的预算管理思维来对待token计费工具，即使工具本身运作完美，也终将被当作成本失控的祸源关停。

AI coding agent的商业模式审判，真正的裁决标准不是Anthropic应该如何改变定价，而是企业应该如何升级自己的AI治理能力。这是2026年所有希望在AI时代保持竞争力的企业的共同作业，而微软用一次公开的失败，给出了一个代价不小的反面案例。

Salesforce那篇工程博客的标题是「我们如何真正实现Agentic」，注意那个「真正」。真正，意味着有很多公司在走弯路。关停工具来控制成本，是一种走弯路。取消token限制、建立产出监控体系、让数据说话，才是真正的Agentic。

这两种选择，会在未来三到五年内，在企业的竞争力差距上留下清晰的印记。

参考资料

  1. Why Your Engineers’ Favorite AI Tools Are Wrecking Your 2026 Budget — Forbes，Janakiram MSV，2026年5月26日，https://www.forbes.com/sites/janakirammsv/2026/05/26/why-your-engineers-favorite-ai-tools-are-wrecking-your-2026-budget/
  2. Microsoft cancels Claude Code licenses, shifting developers to GitHub Copilot CLI — Windows Central，2026年5月，https://www.windowscentral.com/microsoft/microsoft-cancels-claude-code-licenses-shifting-developers-to-github-copilot-cli-a-move-likely-driven-by-financial-motives
  3. Uber Burns Its 2026 AI Budget In Four Months On Claude Code — Forbes，Janakiram MSV，2026年5月17日，https://www.forbes.com/sites/janakirammsv/2026/05/17/uber-burns-its-2026-ai-budget-in-four-months-on-claude-code/
  4. Salesforce Engineering: How We Became Truly Agentic — Salesforce官方博客，2026年5月27日，https://www.salesforce.com/news/stories/how-engineering-became-agentic/
  5. State of AI Cost Governance 2025 — Mavvrik + Benchmarkit（372家企业调查），2025年，https://www.mavvrik.ai/wp-content/uploads/State-of-AI-Cost-Governance-2025_FINAL.pdf