AI 写的代码能不能进代码库?一个开源项目说了不

一段 AI 写的代码，逻辑是对的，测试也全过，该不该收？

这个问题在很多团队里都悬着，一直没吵出结果。10 月 7 日，一个叫 QGIS 的开源项目给出了它的答案：不收。它通过了一份正式提案，名字直白得很，《不允许 AI 贡献》。一扇门，就这样关上了。

先交代 QGIS 是什么。它是一款开源的地理信息软件，做地图、管地理数据用的。政府机构、规划院、测绘公司里，很多人每天靠它干活，周边还长出一大片插件。这样一个被大量依赖的代码库，一直靠一群志愿者维护，谁都可以提交代码。

它做的这个决定，指向一个几乎每支团队都会撞上的问题：AI 写的代码，谁来审，审得过来吗。

一个开源项目，把门关上了

6 月，一位核心开发者 Nyall Dawson 在项目邮件列表里提出，要考虑收紧 AI 相关的提交政策。9 月 24 日，提案正式开出，编号 428。10 月 5 日开始投票，10 月 7 日通过，随即生效。

被它取代的，是之前那份提案，编号 408。那份政策其实并不排斥 AI，它允许 AI 辅助，只提了两个条件：一是打标签说明，二是人要留在流程里把关。

这套设计听起来挺合理。但它在实际运行里崩了。

新的这份提案，覆盖面宽得多。AI 生成的代码、文档、缺陷报告、讨论、提交说明，只要出现在项目里，都算违规。连提案仓库本身也不例外。

它也不是永久禁令。提案人自己说，这是一个初期的严格立场，往后会按个案慢慢放宽，编辑器自动补全、语言翻译这类用途，单独再议。

但在这之前，门是关着的。

五十个打了标签，四十个没进去

崩在哪里，数字说得很清楚。

在旧政策下，大约 50 个提交被标上了 AI 辅助的标签，其中大约 40 个没有合并就被关掉。这还只是打了标签的那一批，另外还有没打标混进来的。

项目委员会的一位成员 Julien Cabieces 在讨论里写得很直白：外部贡献者带来的 AI 使用量，给维护者压上了巨大而难以承受的负担。这些人本来就不好当，AI 之前就不好当。AI 涌进来的量，远远超过人工评审能认真处理的量。结果只有两个，要么是一长串没人看的提交排队，要么是没被完整看过就放进去的代码。

项目还因此流失了至少一位高价值贡献者。

这里有件事值得停下来想一下。旧政策的思路是打标签加人工把关，靠贡献者自觉申报，靠维护者最后兜底。这套思路本身没错，很多团队的代码库也是这么管的。它失效的原因，是产能两头不对等：AI 让产出那一头几乎不设上限，评审那一头还是原来那几个人。

信任契约，比标签先垮

数据之外，有位贡献者的话更扎心。

他提交过两个 AI 辅助的修复补丁。他说，当时没意识到这会给项目本已脆弱的评审社区带来伤害。他并不觉得自己已经强到能修 QGIS 这种复杂项目的缺陷，但 AI 给了人一种错觉，好像这事可以做。几行 Token 下去，问题看上去就修好了。

然后他写了这么一句：这么做，打破的是评审者和贡献者之间的信任契约。那份契约的意思是，你在这个项目里提交，就意味着你懂自己在干什么。

这段话的分量在于，它点出一件常被忽略的事。AI 能帮人更快地产出，却替不了人长出本事。一个拿着 AI 写完代码的人，可能自己都说不清这段逻辑为什么成立。评审的人一看署名，默认对方是懂的。这份默认一旦被打破，整条协作链就松了。

他还补了一层。因为写起来太容易，用 AI 的贡献者学到的也很少，长不出自己的本事，也就很难成长为一个能评审别人代码的人。时间长了，整个社区就停在那里。

规矩该划明线，还是划细线

这份提案不是所有人都赞成。

反对的声音集中在一处：措辞太宽。辅助和使用这两个词，几乎能把任何一次跟语言模型的接触都算进去。照这个解释，用 AI 帮忙做代码审查、安全审计、读陌生代码，好像也一起被禁了。提这个意见的人并不是要给 AI 唱赞歌，他同样认为这波热潮带来了很多问题。他只是觉得，把功能和逻辑都没问题、也经过人工审核的贡献一刀切掉，代价太大。

提案人 Dawson 承认了这个风险。他的回应是：我们知道，这么做可能会把孩子跟洗澡水一起倒掉。但这个孩子，可能根本养不活。

这句回应背后，是一个更硬的问题：规则该划在哪。划成明线，能自动判定，代价是会误伤；划成细线，能保住合法用途，代价是没法执行。

有点意外的是，执行这一关他们没有上工具，而是压在了自觉上。项目主席 Tim Sutton 说，合规的标准就是“你摸着良心回答，这段代码是不是你自己写的”，我们没打算去翻你的电脑。

靠自觉的规则，前提是大家都愿意认这个账。这份提案能不能站住，最后看的是这个。

AI 让产出变便宜，评审没变便宜

把这件事从开源社区里拿出来，放到任何一个团队里，都能对上号。

大家讨论 AI 提效，几乎都在说产出那一端：写得快了多少，省了多少人力。评审那一端的账，很少有人算。QGIS 这件事说明，真正卡住的往往就在这一端。

我的判断是，往后真正稀缺的，是能看懂、能把关的人。会用 AI 写东西的人只会越来越多，能对 AI 写的代码负责的评审者不会跟着多起来。买 Token 花不了几个钱，养出一批能签字的人，得花很多时间。

QGIS 不是孤例。在 AI 写的代码这件事上，开源项目正在集体收紧。Linux 内核在 2024 年就提醒过维护者，要小心 AI 生成的补丁，它们会白白占用评审的时间。之后，COSMIC 桌面、OpenJDK、GCC 也都陆续有了各自的规定。区别在于，别人给的还是提醒和指引，QGIS 把它写成了明确的政策。

新规矩里还有一条容易被忽略的。谁提交谁就得讲清楚自己做了什么，这其实是在做一件事：把署名和责任绑在一起。AI 生成的东西最容易出的毛病，是找不到一个能负责的人。责任一旦模糊，质量就没法指望。让每一段产出都有一个具体的人站出来说我负责，比换任何工具都更能兜住底。

管 AI 代码，先立三条规矩

如果你的团队也在纠结 AI 写的代码怎么进代码库，可以照着这三步走。

一、先把评审账算出来。数一数，你们每周新增多少 AI 产出的代码，负责评审的是几个人。产出这一头在涨，评审那一头没动，这笔账早就不平了。

二、把署名和责任绑死。每一段交给 AI 做的活，都指定一个具体的人签字。这个人要能说清这段东西为什么这么写，出了问题也找他。责任要落到一个名字上，不能停在“大家一起看看”。

三、划明线，别划细线。能自动判定、不需要自己证明的红线最好使，比如提交里不许出现整段 AI 生成的代码。需要靠人自证的规则，最后都会变成说不清的争论。

AI 代码进项目，记三句话 ① 先算评审账：产出涨了几倍，评审的人手有没有跟着涨。 ② 署名和责任绑死，出了问题能找到具体的人。 ③ 规矩划明线，不划需要自证的细线。一句话记住：评审判得过来，比写得快更要紧。

下一期希望我讲什么？欢迎评论区互动哟~