Meta因蒸馏问题限用Claude Code与Codex

AI编程工具越强，像Meta这样的科技巨头反而越感到棘手。这听起来有些反直觉，但确实正在发生。

近日，外媒The Information曝出消息：Meta正在内部限制员工使用Claude Code和Codex这两款AI编程工具，主要顾虑在于——模型蒸馏（Model Distillation）。

简单来说，Meta真正担心的是，外部模型生成的内容一旦渗透进自家训练数据或评测体系，将引发难以澄清的合规风险。

模型蒸馏，成为Meta划定的边界

模型蒸馏是一种常见的模型优化手段——即利用一个模型的输出去训练或改进另一个模型。但对于AI公司而言，这条红线极为敏感。OpenAI、Anthropic、Google等服务条款均明确禁止用户用模型输出来构建竞争性系统。

Meta当前的困境，恰恰卡在这个环节。

今年早些时候，Meta内部成立了应用AI工程团队，任务之一是打磨自家编程助手MetaCode。要提升MetaCode能力，团队需要高质量数据集、设计编程挑战题，并用这些任务训练和测试代码模型。这些工作本身并无问题，但关键在于Meta同时也是Claude Code的大客户。工程师日常使用Claude Code、Codex写代码、查bug、梳理思路，这再正常不过。然而，一旦这些工具生成的内容——包括代码、测试题、分析思路——流入MetaCode的研发流程，风险便随之而来。

据The Information查阅的内部文件显示，Meta已对该团队使用AI工具划定了明确限制。公司允许工程师在搭建工作流、整理代码文件、构建测试基础设施等常规工作中使用AI，但即便如此，AI生成的内容也必须经过人工仔细核查。

更关键的是，文件明令禁止工程师使用外部AI模型生成编程挑战题来测试自家模型。Meta在内部文件中直言：这种做法会削弱工程师对任务设计的主导权——公司不希望任务本身来源于模型。

此外，Meta还限制工程师利用AI分析源代码查找漏洞，或基于代码分析生成测试任务创意。换言之，外部AI可以承担辅助性工程活，但不能帮助Meta决定“该测试什么问题”，更不能成为MetaCode训练和评测任务的来源。

内部文件还披露了一个细节：如果被测试的内部模型能够访问某些基础设施容器，则任何AI生成的内容都不允许放入这些容器中。基础设施容器通常包含应用运行所需的代码、库和环境。Meta担心，第三方模型输出一旦被内部模型接触，后续可能间接流入训练链路。

据The Information报道，一份Meta内部备忘录甚至要求团队暂停部分使用Claude Code和Codex的任务。原因十分明确：Meta担心外部模型的输出可能渗入自家训练数据。一旦被模型厂商认定为存在蒸馏风险，后续合作层面将面临问题——轻则模型访问权限被撤销，重则账号甚至公司层面被封禁。

不断攀升的AI账单

成本压力也是推动这一决策的重要因素。

Meta在全公司范围内大力推广AI工具，内部AI使用成本正飞速上涨。今年仅内部AI使用支出就可能达到数十亿美元。此前Meta曾鼓励员工多用AI提效，但随着token消耗量持续攀升，公司已开始限制员工的token使用额度。

因此，减少对外部AI编程工具的依赖，将开发工作迁移至自家MetaCode，变得愈发紧迫。但问题在于：Meta想要用自家工具替代Claude Code和Codex，必须先确保这个替代工具没有吸收过Claude Code和Codex的输出。

这形成了一个微妙的矛盾：Meta需要借助外部AI工具提升研发效率，同时又必须提防这些工具的贡献进入自家模型体系。

换句话说，科技公司可以使用竞争对手的模型辅助研发，但必须自证清白——这些模型的输出没有进入自己的训练数据、评测集和模型构建流程。

Meta发言人对此表示，公司已制定清晰的政策，规定团队如何使用AI工具，确保员工能够以负责任的方式专注于高影响力工作。

AI编程问题已不止于提效

然而，这件事真正值得关注的是，它揭示了AI编程时代的一个新痛点。

过去，AI编程工具更多是提效工具：帮助工程师写代码、补充测试、整理文件、修复bug。如今，Claude Code、Codex等工具能力不断增强，已经开始影响更上游的研发环节——包括任务设计、评测构造、代码分析和模型训练流程。

当AI工具生成的不再仅仅是代码，还包括测试标准、问题设计和工程思路时，企业就很难再轻松回答一个问题：自家模型的能力，究竟来自内部工程师，还是来自外部模型的输出？

Meta对Claude Code和Codex设限，表面上看是一次内部合规调整，背后却指向一个更大的行业变化——AI编程工具正从开发辅助工具，演变为模型研发供应链的一部分。公司越依赖前沿模型来搭建内部AI基础设施，就越难证明这些智能能力的真正来源。