Debian的开发者投票在8月29日出了结果:社区最终选择的是"负责任使用生成式AI",不是全面禁令。这和外界读这场投票时的预期不太一样——过去几周,GCC、QEMU、SDL、Gentoo、Zig、Ghostty纷纷宣布拒绝AI辅助贡献,Codeberg、Sourcehut、Flathub也跟进限制,舆论已经把这理解成"技术精英正在集体倒戈,反抗AI"。真实情况要碎得多:开源社区里没有出现一致反AI的浪潮,更像是一批各自面对不同问题的项目,分别在试验谁该为AI生成代码的验证成本买单。
Debian投票翻盘,悬念没有兑现
写这场投票预热报道时,禁令看起来像是社区情绪的自然出口。Debian的开发者社群素来对代码血统和版权链条极其在意,全面禁止AI贡献的提案摆在选票上,似乎顺理成章。
但3:1多数票的门槛没有被跨过,投票最终落在"负责任使用"这一档:允许AI辅助,但要求披露、要求人类对每一次提交负责。这个结果值得记一笔——即便是版权洁癖最重的社区,大多数开发者也没有走到"全面拒绝"这一步,他们要的是可追溯,不是禁用。
37/120这个数字,细看会松动
外界喜欢引用"120个开源项目里37个全面禁AI"这个比例,读起来像三分之一的开源世界已经拉闸。这个数字来自一份社区维护的政策目录整理,样本只覆盖已经公开发布过AI政策的项目,没发声明的项目根本不在统计范围里,选择偏差写在骨子里。
更麻烦的是"禁令"这个词被用得太宽。Linux kernel允许AI辅助贡献,只要求标注使用的模型和工具,人类仍必须签署DCO;GCC区分"有法律意义"和"没有法律意义"的贡献,测试用例这类内容标注后可以接受,这份政策还计划在2027年初重新审视;QEMU拒绝AI生成的代码进入最终提交,但允许用AI做调试、查API、做静态分析;真正接近"全面禁止"的是Gentoo这类项目。把这几种立场压缩成一个"禁"字,丢掉的信息比留下的还多。
两份研究,两个相反的结论
原文引用格雷格·克罗-哈特曼在Linux邮件列表上的说法——现阶段最好的AI工具,生成结果里至少三分之一是错的或有害的。这句话有分量,但缺一个可验证的实证支撑,恰好有两份研究能拿来对照,而且结论正好相反。
METR做过一次随机对照实验:16名经验丰富的开源开发者,在自己熟悉的成熟代码库里用AI工具完成246个真实任务。结果是用AI反而慢了19%。更值得记住的是,实验前这些开发者预测AI会带来24%的提速,实验做完之后,他们仍然主观相信自己被AI提速了20%——变慢了,却感觉更快了。
GitHub自己做的对照研究给出的是另一个画面:202名有经验的Python开发者做同一个封闭式API任务,用Copilot的一组通过全部单元测试的概率高53.2%,专家评分在可读性、可靠性、可维护性上都有小幅但统计显著的提升。
两份研究测的不是同一件事——METR测的是经验开发者在自己最熟悉的代码库里干活,GitHub测的是陌生任务从零写起。这提示一个容易被忽略的变量:AI在生疏领域帮你起个头,和在你早就摸透的系统里让你分心审查,是两种完全不同的成本结构。前者省时间,后者偷时间。
安全维度的数据进一步压低了乐观空间:Veracode测试上百个模型完成安全相关任务,在没有专门给出安全提示的情况下,约45%的生成代码样本能被检出OWASP相关漏洞。这也解释了为什么Tidelift对344名维护者的调查会显示,64%的人表示一旦确认某个贡献是AI生成的,会降低而不是提高审查和接受它的意愿——只有9%的人是反过来的。
谁该为验证成本买单
- 结论.验证成本正在从提交者转移到维护者,开源社区提前把这个问题摆上了台面,企业内部的软件团队大概率也在承受同一笔账,只是还没人公开量化。
各家的应对方式其实是同一道题的不同解法。Linux kernel选择标注制,把责任留痕但不设禁区;GCC按贡献的法律意义分级处理,并计划在明年初重新审视政策;QEMU把AI挡在"入库"这道门外,但放行调试和调研这类不进代码库的用途;Gentoo和多数"全面禁止"的项目更接近一种社区文化选择——与其甄别每一份贡献的真假,不如直接不收。Codeberg和Sourcehut则是平台层面的治理,针对的是"整包AI自动生成、无人维护"的项目,而不是追溯性地封杀所有用过AI的仓库。
- 风险.如果验证成本只能靠维护者个人的耐心去消化,而不是靠制度分摊,规则最终会拖垮愿意认真审查的那批人,而不是拖垮AI本身。
对普通开发者来说,能带走的判断很直接:提交代码前先想清楚,自己的理解和投入是否配得上让别人花时间读它。对企业技术团队来说,开源社区试出来的"标注+人类签署"这套办法,值得提前抄作业,总比等到审查负担压垮团队才想起来治理要划算。