QEMU 对 AI 生成内容开了一扇门：非关键领域可接纳 LLM 贡献

去年 QEMU 项目明确禁止任何包含或衍生自 AI 生成内容的贡献，态度堪称行业最硬。如今这道墙有了裂缝——红帽虚拟化工程师 Paolo Bonzini 在邮件列表发布补丁，提议将"全面禁止"改为"分区管理"：非关键领域允许 AI/LLM 辅助产出，关键路径仍需人工把关。

这不是随意的妥协，而是对 LLM 能力边界重新评估后的务实调整。

从一刀切到分区管控

QEMU 最初禁令的逻辑很直接：LLM 会生成看似正确但暗藏缺陷的代码，而虚拟化栈是系统最底层的一环——hypervisor 的 bug 直接威胁 guest 安全。全禁是最省心的风控。

但实际运作一年后，问题显现：文档、注释、测试脚本、构建辅助工具这些"外围"内容，用 LLM 生成后再人工校验，效率明显高于纯手写。一律拒绝等于把低风险区域也锁死了。Bonzini 的补丁本质上是在问：能不能只锁高风险的门，让低风险的窗开着？

补丁的核心思路是把 QEMU 代码库分成两类区域：

• 关键区域：TCG 加速器、KVM 接口、设备模拟核心逻辑、内存管理、安全相关补丁——这些仍禁止 AI 生成内容直接进入。
• 非关键区域：用户文档、man page、测试用例骨架、构建脚本、注释润色、QAPI schema 的非安全部分——这些允许 LLM 参与，但贡献者必须声明 AI 使用情况并承担审核责任。

声明机制：透明比禁止更有效

补丁要求贡献者在提交时明确标注 AI 使用情况，而不是假装"我没用"。这和很多项目"悄悄用、悄悄改"的灰色地带不同——QEMU 选择把灰色变成白色，用流程约束替代一刀切。

具体做法是在 commit message 和补丁描述中加入 AI 使用声明。一个合规的提交大概长这样：

# 假设你用 LLM 辅助生成了 QEMU 文档中的一段描述
# 修改文件后，提交时必须在 commit message 中声明

git add docs/system/qemu-manpage.rst
git commit -s -m "docs: clarify -accel option usage in man page

AI-assisted: initial draft generated by Claude 3.5, then
manually reviewed and corrected. Final text differs from
LLM output in 3 places: removed incorrect TCG fallback
description, fixed KVM enable syntax, added missing
-machine accel=tcg example.

Signed-off-by: Your Name <your@email.com>"

几个要点：

• -s 签名行不可少，它代表你确认补丁合法且你有权提交。
• AI-assisted 标注说明 LLM 参与了哪个环节，以及你做了哪些人工修正。
• 关键区域的补丁即使加了声明也会被拒；声明只对非关键区域有效。

哪些是"非关键"？看 QEMU 的划分

理解分区边界对贡献者很实际。以下是基于补丁讨论和 QEMU 代码结构的划分判断：

边界不是绝对的——比如 tests/ 中如果测试的是 KVM 安全特性，那它就归入关键区域。判断标准是内容出错时的最坏后果，而不是文件路径。

实践：用 LLM 辅助改进 QEMU 文档

下面是一个完整的可运行示例，展示如何合规地用 LLM 辅助改进 QEMU 文档，然后提交补丁：

# 1. 克隆 QEMU 仓库
git clone https://gitlab.com/qemu-project/qemu.git
cd qemu

# 2. 找到你想改进的文档（非关键区域）
# 比如用户手册中关于 virtio-blk 的描述偏简略
cat docs/system/device-emulation.rst | grep -A5 "virtio-blk"

# 3. 用 LLM 生成初稿（在本地或任何 LLM 工具中）
# prompt 示例：
# "为 QEMU 的 virtio-blk 设备写一段 RST 格式文档，
#  说明 -device virtio-blk-pci 的常用参数：
#  drive、bus、addr、num-queues、queue-size。
#  目标读者是运维工程师。"

# 4. 将 LLM 输出写入文件，然后人工审核修正
vim docs/system/device-emulation.rst

# 5. 验证文档构建无误
make sphinxhtml  # 或 ninja sphinxhtml，取决于构建系统

# 6. 提交补丁，带 AI 声明
git add docs/system/device-emulation.rst
git commit -s -m "docs: expand virtio-blk-pci parameter description

AI-assisted: initial structure generated by GPT-4o,
manually reviewed. Corrected num-queues default value
(from 1, not 4 as LLM suggested), added queue-size
range constraint per spec, removed inaccurate
multiqueue performance claims.

Signed-off-by: Developer <dev@example.com>"

# 7. 生成补丁文件发送到邮件列表
git format-patch -1 -o /tmp/patches/
sendmail /tmp/patches/0001-docs-expand-virtio-blk-pci-parameter-description.patch

关键步骤不是"用 LLM"，而是第 4 步的人工审核和第 6 步的声明。补丁审核者会看到你标注了 LLM 参与范围和修正点，这比隐瞒更可信。

为什么这次松动值得关注

QEMU 不是第一个调整 AI 政策的开源项目，但它的做法有几个独特之处：

分区而非配额。有些项目用"AI 内容占比不超过 X%"来管控，但百分比难以衡量且容易钻空子。QEMU 按风险分区，边界清晰，审核者判断成本低。

声明即合规。不要求证明"这段代码不可能由 AI 生成"，只要求如实声明。这降低了贡献者的合规负担，也让审核者聚焦在内容质量而非来源鉴定上。

红帽背书。Bonzini 是红帽的虚拟化核心工程师，KVM 维护者。他的提议不是社区边缘的声音，而是主流维护者的判断。红帽内部对 LLM 的态度也在从保守转向审慎开放，QEMU 的政策变化是这一趋势的具体投射。

给贡献者的检查清单

如果你打算向 QEMU 提交含 AI 辅助的补丁，走一遍这个清单：

1. 确认区域——补丁涉及的文件是否属于非关键区域？不确定就先在邮件列表问。
2. 声明 AI 使用——在 commit message 中写明哪个环节用了 LLM、用了什么模型、你做了哪些修正。
3. 验证构建——文档补丁要跑 make sphinxhtml；测试补丁要跑对应测试套件。
4. 不要在关键区域试探——即使你声明了，KVM/TCG/memory 相关补丁中的 AI 内容仍会被拒，别浪费审核者的时间。
5. 保留人工修正记录——如果 LLM 生成了 10 行你改了 3 行，在声明中写清楚，这比笼统说"我审核过了"更有说服力。

QEMU 的这次政策调整，本质上承认了一个事实：LLM 的输出质量不是均匀的——在低风险区域，经过人工校验的 LLM 辅助产出可以比纯手写更快且质量不差；在高风险区域，任何自动化生成的代码都不值得信任。分区管理比全禁更精确，也比全放更安全。