8 月 5 日，Rust 项目在官方博客发布内部通告，宣布 rust-lang/rust 仓库正式采用一套 LLM 使用政策，明确大语言模型在编译器开发流程中的边界。政策最核心的一条是：允许用 LLM 回答问题、分析、提炼、检查、提供建议以及审查代码，但禁止用 LLM 直接"创建"产出。
这番话不是泛指，而是直接写进了政策原文——"It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create."。换句话说，LLM 可以当个智能副驾做辅助，但不能替代开发者提交原始输出作为最终代码变更。
政策同时要求，如果贡献者在 PR 中使用了 LLM 生成的部分代码，必须事先征得审查者的同意，并且在提交时主动披露使用了 LLM。这种做法相当于把判断权交给人，同时留下可追溯的记录：谁用了、用在哪、审查者是否知情，一目了然。
这一思路与近两年开源社区的普遍焦虑一脉相承。生成式工具普及后，不少大型项目都遇到过来源不明、质量参差的 AI 生成补丁，审查者往往要额外花费精力甄别。Rust 项目组选择把规则写在明面上，而非依赖默契，算是给贡献者和维护者双方都划清了预期。
Rust 项目组对 LLM 的定位很务实：不妖魔化，也不盲目放开。把 LLM 框在分析和审查的辅助角色里，既保留了人工审查的最终决定权，又避免日后出现大量标注不清的生成代码混入编译器主干。对于体量庞大且对正确性要求极高的 rust-lang/rust 仓库来说，这种谨慎有迹可循——编译器一旦引入隐蔽缺陷，影响会顺着工具链传导到所有下游项目。
目前该政策主要适用于 rust-lang/rust 仓库本身，其他 Rust 生态项目是否会跟进类似准则尚不确定。不过作为编程语言核心项目率先明确态度，这套"辅助可以、代写不行、使用必须披露"的框架，很可能给其他大型系统软件项目的 LLM 治理提供参考模板。对于日常依赖 AI 编程助手的开发者来说，这类政策也释放了一个信号：工具用不用是自由的，但透明度和人工把关正在成为开源协作的底线要求。
