Meta严限工程师使用Claude Code与Codex

一份可追溯至今年5月且仍在执行中的Meta内部管理文件，向工程团队使用外部AI编程工具这件事，明确画了一条线。时间标注的是2026年6月30日。这事的具体规定是：工程师在日常工作时，原则上不得调用Anthropic的Claude Code和OpenAI的Codex这两款模型，连带着相关依赖任务也得暂停。

当然，也不是一竿子打翻一船人。文件在允许范围上做了细化——日常事务里，外部AI工具还是可以有限使用的，比如搭个工作流、整理代码和文档、建个测试基础设施，这些非核心环节没问题。但真正划定的边界，才是关键所在：绝对不能用外部模型输出的东西，来设计验证Meta自研编程模型MetaCode的测试题目；也不能借助外部AI对源代码做漏洞分析或生成研发任务建议。所有用来训练和评估MetaCode的命题、场景以及挑战内容，都得由内部工程师一手包办。

还有一个细节值得注意：所有AI生成的文本、代码或方案，一律不许存进Meta内部模型能访问的数据容器或训练资源池。而且在任何实际应用之前，这些AI产出都必须经过人工全流程复核确认。

那么问题来了，Meta这么大阵仗，到底图什么？效率？成本？都不是。根源在于对“模型蒸馏”风险的警惕。所谓模型蒸馏，说白了就是收集竞品AI系统的输出，反过来用在自己模型的训练和优化上。这条路看着省事，能绕开大量原始数据积累、算力投入和基础研究，但代价是实质性违反第三方模型的服务协议，法律和商业的连锁反应随时可能引爆。

目前，OpenAI、Anthropic和谷歌都在服务条款里明确禁止把输出内容拿去开发或强化竞品系统。Meta内部文件特别点明了一件事：如果有工程师拿Claude Code或Codex生成的编程任务、测试逻辑，喂进了Meta模型的数据链路里，那外部模型的知识就可能间接渗入到自研系统的训练和评估流程中。这可不是小事——文件警示，一旦发生，合作伙伴那边的争议升级，可能会严重到不可控。

模型蒸馏这事儿，现在几乎成了行业里的共识性难题。之前就有公开讨论提到，有些新兴模型的能力构成，可能或多或少吸收了头部厂商模型的输出。技术声明和行业诉讼里，这条路也被反复提及。Meta这边的态度是，公司一直在推一套清晰、统一的AI工具使用规范，目的就是让团队把精力放在真正有创造性和战略价值的地方。从现有内部通信记录来看，暂时还没发现员工有明确违反外部模型服务协议的行为。话虽如此，这份文件本身，已经足够说明风向正在变了。