Linux 内核邮件列表这次争论的不是缩进、驱动接口或补丁拆分，而是 AI 能不能进入开发流程。随着 Sashiko 这样的 AI 代码审查系统逐渐活跃，加上软件自由保护协会（SFC）发布 AI 使用建议，一部分开发者公开表达抵触。Linus Torvalds 的回应把问题重新拉回工程判断：开发者可以不喜欢 AI，也可以拒绝自己使用，但不能仅凭立场阻止其他人使用。
这场争论真正值得关注的，并不是某一句措辞激烈的回复，而是大型开源项目该如何处理 AI 生成内容、自动审查意见和贡献责任。
争议焦点不是“喜不喜欢 AI”
在成熟的软件项目里，工具通常按产出接受审查。编译器、静态分析器、模糊测试器和代码生成器都可能产生错误，但项目不会因此讨论它们是否“有资格”参与开发，而是检查结果是否可复现、是否符合规范、最终由谁负责。
LLM 工具带来了几个更棘手的问题：
- 它可能生成看似合理、实际上并不存在的 API 或因果解释。
- 它的输出来源不透明，可能引出版权与许可证争议。
- 自动生成的审查意见可能制造噪声，增加维护者负担。
- 开发者可能提交自己无法解释的代码，把验证成本转嫁给社区。
这些风险都真实存在。不过，从工程治理角度看，“存在风险”不能自动推出“全面禁止”。更有效的规则应当约束可观察行为，例如补丁质量、信息披露、测试证据和提交者责任，而不是猜测开发者在编辑器里用了什么工具。
AI 审查不能获得特殊地位
把 AI 接进代码审查流程，不等于让模型成为维护者。它更适合扮演一种高召回率、低信任度的分析器：主动寻找遗漏，但每条结论都必须经过验证。
一条有价值的自动审查意见，至少应该包含以下信息：
- 指向具体文件和代码位置。
- 描述能够触发问题的条件。
- 给出可执行的验证方法，而不只是笼统地说“可能有风险”。
- 明确区分事实、推断和不确定结论。
- 允许开发者忽略误报，且不会自动阻塞补丁合并。
反过来，如果系统只是批量生成“请考虑线程安全”“这里可能为空”之类的通用评论，它消耗的是维护者最稀缺的资源：注意力。无论评论由人还是模型产生，这种噪声都不应该因为披着自动化外衣而被接受。
可以这样实践：把 AI 建议放进非阻塞 CI
下面是一个可改造的 GitHub Actions 示例。假设仓库中已经提供 tools/ai_review.py，它读取补丁并把建议写入 Markdown 文件。工作流只上传报告，不直接判定补丁失败，因此 AI 输出仍然只是辅助证据。
运行前需要把 tools/ai_review.py 替换为团队实际使用的审查客户端，并在仓库设置中配置 AI_REVIEW_TOKEN。不要把令牌写进代码或工作流文件。
name: Advisory AI Review
on:
pull_request:
types: [opened, synchronize, reopened]
permissions:
contents: read
jobs:
review:
runs-on: ubuntu-latest
continue-on-error: true
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Build patch
run: git diff "${{ github.event.pull_request.base.sha }}" HEAD > change.patch
- name: Run advisory review
env:
AI_REVIEW_TOKEN: ${{ secrets.AI_REVIEW_TOKEN }}
run: |
python3 tools/ai_review.py \
--input change.patch \
--output ai-review.md \
--require-file-line \
--label-unverified
- name: Upload report
if: always()
uses: actions/upload-artifact@v4
with:
name: ai-review
path: ai-review.md
if-no-files-found: ignore
如果代码不能发送给外部服务，可以先用本地静态分析建立同样的工作流边界。下面的命令会对本次提交涉及的 C 文件运行 clang-tidy，其报告同样应由开发者判断，而不是机械地全部接受：
#!/usr/bin/env bash
set -euo pipefail
base="${1:-origin/main}"
git diff --name-only --diff-filter=ACMR "$base"...HEAD \
| awk '/\.(c|cc|cpp)$/ { print }' \
| xargs -r clang-tidy -p build --
这种设计保留了自动分析的价值，也明确了信任边界：工具发现线索，人类确认问题，提交者对最终修改负责。
披露规则要解决责任问题
团队可以要求披露 AI 使用情况，但披露不应沦为身份标签。真正有用的提交说明应该告诉维护者哪些部分需要额外关注。
可以这样实践，在补丁或拉取请求模板中加入简短声明：
Automation disclosure:
- Tool used: AI-assisted review
- Scope: Reviewed error paths in drivers/example/device.c
- Generated code included: No
- Findings independently verified: Yes
- Verification: make M=drivers/example W=1; ./tests/device-smoke.sh
- Author can explain and maintain the submitted changes: Yes
这份声明没有把责任交给模型。它记录工具用途、影响范围和验证命令，同时要求提交者确认自己理解代码。对于内核这类长期维护项目，“谁能解释并维护补丁”比“补丁是否碰过 AI”更重要。
落地时守住四条边界
引入 AI 辅助开发时，可以用一份短清单控制风险：
- 提交者负责：不能把“模型生成的”当作错误、侵权或低质量代码的免责理由。
- 证据优先：审查意见必须尽量附带代码位置、复现步骤、测试或规范依据。
- 默认不阻塞：在误报率得到持续评估前，AI 建议不应拥有独立否决权。
- 保护代码与凭据：敏感仓库要确认数据保留、训练用途、访问权限和许可证边界。
这场内核邮件列表争论提醒开发者，AI 治理不能简化成支持或反对两派。禁止一种工具很容易，建立一套能够过滤噪声、追踪责任并验证结果的流程更难，却也更接近开源工程真正需要的答案。