微软正在收回内部 Claude Code 许可，并引导开发者转向 Copilot CLI

微软正在对其自身的 AI 编码栈进行一次测试

根据所提供的来自

The Decoder 的报道，并引用了

The Verge 先前的报道，微软正在撤销大多数内部 Claude Code 许可，并将开发者转向 GitHub Copilot CLI。报道称，这一变化影响公司的 Experiences and Devices 业务组，该组织负责 Windows、Microsoft 365、Outlook、Teams 和 Surface，预计该组中的 Claude Code 使用将于 6 月底前结束。

这不仅仅是一次内部工具决策。它也是一个高曝光度的表态，涉及平台控制、产品政治，以及微软究竟会在多大程度上支持自己的命令行 AI 编码工具，即便员工似乎更偏好竞争对手。

这一举措为何引人注目

所提供的报道称，直到去年 12 月，数千名微软员工仍可使用 Anthropic 的 Claude Code，其中包括没有编程背景的设计师和项目经理。这个规模很重要，因为它表明 Claude Code 并不是一次小规模试验部署。按照报道所述，它是一项广泛的内部试用，而且变得极受欢迎。

这种受欢迎程度似乎正是问题所在。如果开发者更喜欢竞争对手的产品，而不是微软自己的 GitHub Copilot CLI，公司就会面临战略上的矛盾。它很难一边把 Copilot 描绘为 AI 辅助开发的未来，一边看到自家团队转向别处。

官方与非官方原因

据报道，微软给出的官方解释是战略整合。Experiences and Devices 业务组执行副总裁 Rajesh Jha 据称在一份内部备忘录中写道，Claude Code 曾是学习过程中的重要部分，但 Copilot CLI 让微软能够直接与 GitHub 合作，针对其代码仓库和安全需求定制产品，从而获得优势。

所提供的报道还称，消息人士指出了第二个驱动因素：成本。6 月 30 日是微软财政年度结束之日，取消 Claude Code 许可可在结账前降低运营支出。这个财务时间点很重要，因为它让更整洁的战略叙事变得复杂。此举或许与产品对齐有关，但预算压力似乎也是故事的一部分。

一个存在功能差距的替代方案

最关键的细节或许是，报道将 Copilot CLI 描述为仍然存在一些相较于 Claude Code 的功能缺口。如果这一点属实，微软并不是在把员工从一个等效工具迁移到另一个等效工具。它是在要求他们短期内接受一个较弱的内部产品，以便公司长期强化自己的生态系统。

这会带来执行风险。内部用户往往是企业工具最好的早期验证场景，但前提是他们信任产品，并相信自己的工作流正在改善，而不是受到限制。如果这次变更看起来更像政治性指令，而不是技术升级，采用可能会变成服从，而不是热情。

内部偏好为何重要

报道中对内部受欢迎程度的描述很重要，因为大型公司内部开发者的选择，往往比高层的宣传更能预测更广泛的市场走向。当工程师能够使用多种工具时，他们的习惯会揭示真正的实用性在哪里。如果 Claude Code 在微软内部赢得了那场比较，即便只是暂时的，该公司的产品团队现在也面临压力，必须尽快缩小差距。

The Decoder 明确表示，这种压力现在落在 GitHub 身上。微软仍然可以通过其他渠道提供 Anthropic 的模型，包括 Copilot CLI、Microsoft 365 应用，以及该报道中提到的 Foundry 合作协议。但仅有模型访问权限并不等于完整的首选产品体验。界面、工作流、权限和任务编排都很重要。

企业 AI 的更大趋势

这一事件反映出企业 AI 的更广泛趋势：大型平台希望掌控界面层，即便竞争对手提供了更好的体验。对用户每天打开的工具拥有控制权，在战略上比获取某一个底层模型更有价值。对于编码助手而言，这一点尤为明显，因为它们可能成为通往代码仓库、工作流乃至最终软件采购的入口。

因此，微软的决定看起来既是防守，也是进取。它在维护 Copilot 的内部合法性，同时也在真实使用压力下推动快速迭代。随着 6 月底截止时间临近，这一做法最终会带来更好的产品，还是引发内部怨气，很快就会见分晓。

对于更广泛的 AI 工具市场来说，信息很直接：即便在一家拥有多个模型合作伙伴的公司内部，围绕默认开发者界面的竞争也正在加剧。

本文基于 The Decoder 的报道。阅读原文。