一份可追溯到今年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工具使用规范，旨在让团队将精力集中于真正具有创造性和战略价值的工作上。从现有内部通信记录来看，尚未发现员工有明确违反外部模型服务协议的行为。尽管如此，这份文件本身已足以说明风向正在发生变化。
