做出这个决定的核心原因，并非对AI能力的全盘否定，而是源于一个根本性的法律不确定性——即《开发者原创证书》（Developer's Certificate of Origin, DCO）的合规问题。简单来说，DCO要求代码贡献者必须证明他们有权根据项目指定的许可证贡献该代码。由于AI生成的代码，其版权归属非常模糊（它是属于AI工具的使用者？还是训练数据的版权方？），贡献者几乎不可能可信地做出DCO所要求的法律承诺 。

QEMU社区当时的表态非常明确：“我们不愿意，也没有能力承担不合规所带来的法律风险” 。

新提案的核心：一个分级化、有条件的开放体系

一年后的今天，风向开始转变。博尼尼提出的新方案绝不是“门户大开”，而是构建了一个精巧的“分级治理”体系。

他直言不讳地指出了僵化禁令的困境：“当大语言模型（LLM）的输出本身还很少能用时，搞一刀切的禁令很好维护；但随着这些工具日益精进，绝对的禁令已经越来越站不住脚了。” 更重要的是，一些其他开源项目开始接纳AI辅助的贡献，但人们此前担心的灾难性法律诉讼并未出现 。

新的提案根据贡献的风险和影响力，划出了清晰的边界：

• “绿灯”区（允许使用）：对于“那些万一出现版权违规问题，至少很容易回滚，且不太可能扩散”的任务，允许使用AI辅助 。这主要指的是文档更新和小型的错误修复。这些操作的潜在法律影响是可控的，一旦出问题可以轻松推倒重来。甚至像IDE自动补全一个变量名这样的琐碎用途，因为风险极低，可能都不需要正式披露 。

• “红灯”区（严格限制）：QEMU的核心代码（core code）仍是“非请勿入”的禁区。使用AI做任何核心代码的贡献都是禁止的，“除非事先获得维护者的同意” 。这个“安全阀”确保了那些高风险、基础性的代码，其来源依然清晰、可追溯，并且是经过人类严格审计的。

新规则下的“投名状”：强制披露机制

如果说分级是骨架，那么强制披露就是新政的灵魂。博尼尼建议，在任何AI扮演了重要角色的补丁（patch）中，都必须添加一个**'AI-used-for:' (AI用途) 的提交尾注** 。

这个小小的标签肩负着双重使命：

1. 对审查者和维护者透明：它清晰记录了AI工具的参与过程，为后续的代码审查和追责提供了依据。
2. 对贡献者进行约束：它就像是一个“宣誓”，表明贡献者已经阅读并理解了项目关于AI使用的政策。“这个标签本身也可以作为一个检查点，证明作者已经读过政策了”，博尼尼解释道 。

需要强调的是，使用AI并不会免除贡献者任何其他标准义务，最重要的就是仍然需要通过DCO认证 。

一石激起千层浪：对开源世界的深远影响

QEMU的这次政策抉择，不仅仅是它一个项目的“家务事”，更是整个开源社区都在密切关注的风向标。关于AI代码的法律核心问题——谁拥有它？它能以何种许可证进行贡献？它是否能满足DCO的要求？——法院至今没有给出明确答案 。

在这种法律真空中，每个项目都不得不自行制定风险管理框架。QEMU所探索的道路，可能成为许多其他大型项目效仿的“中间路线”。它既没有固守一个越来越难以执行的绝对禁令，也没有冒失地全盘接纳AI代码，而是开创了一种风险导向、披露优先的新模式。其他重量级项目，如FreeBSD，也正在与同样的问题角力，甚至有专门的行动计划出现，用于追踪被“LLM污染”的开源代码 。

通过允许在文档、模板等低风险领域借助AI的生产力，同时通过强有力的人类审查把住核心逻辑的关口，QEMU正在试验一种可能被广泛采用的模板。这条道路，也许正是在关键基础设施软件的安全性与利用AI提升效率之间，找到最佳平衡点的答案 。

做出这个决定的核心原因，并非对AI能力的全盘否定，而是源于一个根本性的法律不确定性——即《开发者原创证书》（Developer's Certificate of Origin, DCO）的合规问题。简单来说，DCO要求代码贡献者必须证明他们有权根据项目指定的许可证贡献该代码。由于AI生成的代码，其版权归属非常模糊（它是属于AI工具的使用者？还是训练数据的版权方？），贡献者几乎不可能可信地做出DCO所要求的法律承诺 。

QEMU社区当时的表态非常明确：“我们不愿意，也没有能力承担不合规所带来的法律风险” 。

新提案的核心：一个分级化、有条件的开放体系

一年后的今天，风向开始转变。博尼尼提出的新方案绝不是“门户大开”，而是构建了一个精巧的“分级治理”体系。

他直言不讳地指出了僵化禁令的困境：“当大语言模型（LLM）的输出本身还很少能用时，搞一刀切的禁令很好维护；但随着这些工具日益精进，绝对的禁令已经越来越站不住脚了。” 更重要的是，一些其他开源项目开始接纳AI辅助的贡献，但人们此前担心的灾难性法律诉讼并未出现 。

新的提案根据贡献的风险和影响力，划出了清晰的边界：

• “绿灯”区（允许使用）：对于“那些万一出现版权违规问题，至少很容易回滚，且不太可能扩散”的任务，允许使用AI辅助 。这主要指的是文档更新和小型的错误修复。这些操作的潜在法律影响是可控的，一旦出问题可以轻松推倒重来。甚至像IDE自动补全一个变量名这样的琐碎用途，因为风险极低，可能都不需要正式披露 。

• “红灯”区（严格限制）：QEMU的核心代码（core code）仍是“非请勿入”的禁区。使用AI做任何核心代码的贡献都是禁止的，“除非事先获得维护者的同意” 。这个“安全阀”确保了那些高风险、基础性的代码，其来源依然清晰、可追溯，并且是经过人类严格审计的。

新规则下的“投名状”：强制披露机制

如果说分级是骨架，那么强制披露就是新政的灵魂。博尼尼建议，在任何AI扮演了重要角色的补丁（patch）中，都必须添加一个**'AI-used-for:' (AI用途) 的提交尾注** 。

这个小小的标签肩负着双重使命：

1. 对审查者和维护者透明：它清晰记录了AI工具的参与过程，为后续的代码审查和追责提供了依据。
2. 对贡献者进行约束：它就像是一个“宣誓”，表明贡献者已经阅读并理解了项目关于AI使用的政策。“这个标签本身也可以作为一个检查点，证明作者已经读过政策了”，博尼尼解释道 。

需要强调的是，使用AI并不会免除贡献者任何其他标准义务，最重要的就是仍然需要通过DCO认证 。

一石激起千层浪：对开源世界的深远影响

QEMU的这次政策抉择，不仅仅是它一个项目的“家务事”，更是整个开源社区都在密切关注的风向标。关于AI代码的法律核心问题——谁拥有它？它能以何种许可证进行贡献？它是否能满足DCO的要求？——法院至今没有给出明确答案 。

在这种法律真空中，每个项目都不得不自行制定风险管理框架。QEMU所探索的道路，可能成为许多其他大型项目效仿的“中间路线”。它既没有固守一个越来越难以执行的绝对禁令，也没有冒失地全盘接纳AI代码，而是开创了一种风险导向、披露优先的新模式。其他重量级项目，如FreeBSD，也正在与同样的问题角力，甚至有专门的行动计划出现，用于追踪被“LLM污染”的开源代码 。

通过允许在文档、模板等低风险领域借助AI的生产力，同时通过强有力的人类审查把住核心逻辑的关口，QEMU正在试验一种可能被广泛采用的模板。这条道路，也许正是在关键基础设施软件的安全性与利用AI提升效率之间，找到最佳平衡点的答案 。