Debian 吵翻的不是 AI 代码质量，是谁来签名背锅
Debian 的投票页上现在同时挂着四个提案，讲的是同一件事，AI 到底能不能给 Debian 写东西。
四个互相排斥，从「一个字都不许」到「随便用，但你自己签名负全责」，光谱两头全占齐了。更有意思的是联署名单。提出「全面禁止」那份提案的人，转头在另一份「尽可能拒绝但承认全禁不现实」的提案上签了名；而在「全面禁止」上签过名的另一个人，自己又提了第四份，主张承认现实、放行、把责任整个压回提交者身上。
这不是内讧。这是连最懂这件事的一群人，也没觉得这题是非黑即白。
提案 7 月 22 号交上去，7 月 24 号进讨论期，投票期还没定。官方投票页上四个选项全文都挂着，谁都能翻。
先说个彩蛋。主张全面禁止的那份提案，文档最后专门缀了一行，说明本文由两位撰写，organically and without language model assistance，纯人手写，没用语言模型。
好家伙。写一份禁 AI 的文件，要在末尾自证这份文件本身不是 AI 写的。
我读到这行的时候先是笑，笑完有点凉。这行注脚说明，「你怎么证明这段字不是模型吐的」已经变成一个得当场表态的问题了。以前没人需要在文末声明自己是人。
四张选票，一张一张过。
A 是全禁。提案人 Matthias Geiger，要往 Debian 社会契约里加第 6 条，白纸黑字写上，不接受任何借助大语言模型或生成式 AI 工具写出来的直接贡献。范围划得很清楚，Debian 源码包、lintian 这种项目自研软件、官方网站资源、贡献者写的文档和翻译、项目官方沟通，全算。上游项目自己怎么用不管，AI 相关软件本身不管，上游打的补丁和安全修复不管。
A 给了四条理由。版权状态不明，Debian Policy 里关于版权的那章和 DFSG 要求许可绝对清晰，人写的东西许可不清都进不来，模型产出凭什么开特例。质量，模型永远不「知道」自己对不对，它只是在拼语法上像样的组合，而每个 Debian 源码包都是独一份的，打包语法和最佳实践这些年一直在变，模型吐出来的包会是各个年代语法的大杂烩，watch 文件跑不通，override 脱离上下文，copyright 是编的。社区，新人把模型产出丢给评审看，是在消耗评审员，评审员会 burnout，而这个新人自己什么都没学到，将来接不了退坑那位的班。伦理，AI 爬虫无视 robots.txt 满网抓，把 Debian 的公共站点压到部分设施完全不可达，逼得他们上 JS 校验。
B 是有条件放行。提案人 Lucas Nussbaum。承认这些担忧都成立，但也承认很多贡献者确实觉得这些工具有用，所以定规矩而不是关门。条件有六条，工具的服务条款不能跟 Debian 的分发和修改冲突；产出里混进第三方版权材料的，提交前得确认自己有权按对应开源许可交出去；贡献者对技术质量、安全、许可合规负完全责任，得能解释、能辩护；显著使用要披露，还给了具体姿势，commit 上加个 Generated-By: 或者 Assisted-By: 的 Git trailer；批量或自动化提交要事先讨论，参照 mass-bug filing 那套流程；敏感和非公开数据不许喂给不可信的服务商。
C 是劝退加硬线。提案人 Ian Jackson。开篇罗列了一长串问题，然后写了句挺实在的话，理想状态下模型产出不该出现在我们依赖的软件里，但相当一部分外部世界包括很多上游不这么看，所以现阶段全面禁止不现实。于是它变成三条请求加五条要求。请求所有贡献者避免使用，请求决策者尽可能劝阻，请求所有人包括 Debian 之外的人都别用。要求那部分才是硬的，其中最狠的一条是，给人看的消息必须完全由人类撰写，bug 报告、邮件列表、Salsa 上的讨论、Planet Debian 上的博客，全在内。任何使用必须披露，违规按行为准则处理。个别项目和维护者可以完全禁止，这种禁令必须被尊重。
C 里还有一条，我看的时候停了很久。它说，任何觉得自己英语写不好的贡献者，可以直接用母语写，读者请自便用翻译工具，人写的英文摘要很欢迎但不强求，无论如何我们承诺不因为语言错误羞辱任何人。
一份措辞最强硬的反 AI 提案，专门留了一条给英语不好的人兜底。因为它很清楚，禁掉 LLM 之后最先被挤出去的是谁。这个细节比整份提案的立场更让我服气。
D 是认账加归责。提案人 Pierre-Elliott Bécue。开头就说，Debian 作为项目不背书也不推荐用生成式 AI 助手，但这些实践已经在发生并且会一直在，与其搞一个既不现实又执行不了的禁令，不如把责任明确压给贡献者。只管 Debian 自己的活，不管上游。要求提交者必须充分评估、真正理解自己要交的东西，能解释能辩护；Signed-off-by 和 GPG 签名必须提交者本人打；任何最终会进生产环境的内容，主分支、包上传，必须由本人显式提交；AI 辅助要在 commit message 或 changelog 里标注，Copilot 那种 tab 补全可能贡献者自己都没意识到用了，所以拿不准就标；涉及项目敏感或非公开数据的一律不许用云端 AI。
四份看完，我最直接的感受是，这四拨人吵得很凶，但他们其实在同一个坐标系上站不同的点。
铺天盖地的转述都是「Debian 要禁 AI 代码了」，把它当一条禁令新闻。但你把四份原文摊开对着看，会发现关于「模型写的代码质量到底行不行」这件事，只有 A 认真论证了，而且那还只是它四条理由里的第二条。B 一句都没花在质量上，C 那一长串问题清单里质量只是其中一项，D 干脆连提都不提。
真正在四张选票上都出现的公约数只有一个词，责任。
B 的第三条叫 Accountability，贡献者对提交负完全责任，得能解释能辩护。C 的第五条要求任何使用必须披露，违规按行为准则处理。D 整份提案的骨架就是「submitter is solely responsible」，提交者独自负责，签名自己打，出事自己扛。连 A 那份最强硬的，落到条文上写的也是「不允许直接贡献」，是入口管控，不是质量判定。
顺着这个再想一层，你就明白为什么这题吵不完。质量问题是会自己消失的，今年模型打的包全是错的，明年可能就对了，A 的第二条理由三年后大概率站不住。但责任问题不会消失，模型再强，出了事总得有个人来解释这行代码为什么这么写、为什么可以合并、谁来修。这个位置上必须站一个能被追责的人，而且这个人得真的看懂了。
所以吵的从来不是机器写得好不好，是人还愿不愿意为机器写的东西背书。
D 提案里那句话我觉得写到了根上，Signed-off-by 和 GPG 签名必须提交者本人打。这句话技术上是废话，签名当然得本人打，不然叫什么签名。但它出现在 2026 年的提案里就不是废话了，它是在提前堵一件事，别到时候搞一个 agent 自动跑、自动 commit、自动签名、自动推送，然后所有人假装那个签名还有意义。
签名的意义从来不在密码学上，在于名字后面站着一个人。
回头说开头那个让我觉得有意思的事，联署名单为什么会交叉。
提 A 的 Matthias Geiger 在 C 上签了名。在 A 上签名的 Pierre-Elliott Bécue 自己提了 D。Ian Jackson 既 second 了 A，又自己提了 C。
不是叛变，是 Debian 用的 Condorcet 排序投票。你投的不是「我选哪个」，是「我把这几个选项排个序」，第一志愿 A、第二志愿 C、最后才是 B，这套完全成立。所以 Geiger 的实际立场大概是「最好全禁，退一步至少劝退加硬线」，而 Bécue 的立场可能是「我理解全禁的诉求，但真要落地我认为该走归责这条」。
坦率讲，这套机制有点子牛逼，比二元投票诚实太多了。它逼你承认自己的立场是有梯度的，而不是逼你在一个二选一里假装自己很确定。
我们做技术决策的时候特别缺这个东西。要不要上某个框架、要不要允许某类提交，会上一举手，通过或不通过，中间那些「我勉强同意但有条件」的信息全丢了。Debian 至少把这个梯度留在了票面上。
我平时的活是给模型搭能真正干活的那层工程，工具链、评测、调度、上下文这些。天天看的就是模型在生产环境里怎么跑、怎么翻车。所以 A 提案里「评审员会 burnout」那条，我看着一点都不抽象。
现在一个人配上 agent，一晚上能产出的 PR 量比过去一个小团队一周还多，厉害了，但这事只厉害了一半。产出侧的成本塌了，但评审侧没塌，评审还是得一个活人一行行看懂。这个比例一旦失衡，瓶颈立刻从「谁来写」变成「谁来看」，而「谁来看」这个位置在开源项目里通常是几个熬了很多年的老维护者，没有备份，也没有工资。
这才是 A 那条社区理由的真正分量。它讲的不是新人交上来的代码烂，是新人交上来的东西消耗的是一种没法补充的资源。
A 的第四条伦理理由我原本以为是最虚的，读完发现它是最实的。它写的是 AI 爬虫把 Debian 的公共站点压到部分设施完全不可达，被迫上 JS 校验。这不是价值观表态，这是运维账单。一边是模型公司抓着开源社区的产出去训练，另一边是同一批爬虫把这个社区的服务器打趴下，最后社区还得自掏腰包上防护。你要说这些维护者心里没气，那不可能。
这一条也不只有 Debian 在写。Gentoo 的 AI 政策、GNOME 那边 Loupe 项目不再接受生成式 AI 贡献的讨论、Codeberg 的 AI 政策，A 提案的参考来源里明明白白列着这三个。开源社区在这件事上已经串起来了，Debian 只是块头最大、程序最正式的那个。
说真的，Debian 投出什么结果，对大部分人的日常影响没那么大。但这四条路线本身，是每个团队两年内都要在自己仓库里做的同一道选择题。
我自己的判断是这样的，不一定对，你可以拿去骂。
全禁那条路，在公司里基本走不通。不是道德问题，是执行问题。你没法验证一段代码是不是模型写的，A 提案自己也承认了这点，它给的回应是「这是一份意向声明，我们相信社区会善意遵守」。开源社区靠信任可以这么办，公司里靠信任外加 KPI，通常办不成。
C 那条「给人看的消息必须完全由人类撰写」，我第一眼觉得矫情，越想越觉得它可能是四条里最值得抄的一条。代码是给机器执行的，机器不在乎作者是谁；但 bug 报告、评论、设计讨论是给人看的，人是要根据这些字去判断「对面那个人到底想清楚了没有」。一段模型润色得很漂亮但作者自己没想明白的评论，比一段磕磕巴巴的人话有害得多，因为它把「没想清楚」这件事藏起来了。
真要落地，我觉得多数团队会抄 B 和 D 的骨架，三条就够。
一，谁提交谁全责，能解释能辩护，评审时被问到答不上来就打回。这条一写，滥用自动生成的成本就上去了。
二，显著使用要标注，用 B 给的那个 Git trailer 就挺好，Assisted-By: 一行的事。别搞成道德审判，就当成一条元数据，将来出问题回溯的时候你会感谢它。
三，批量提交先说一声。这条最被低估。单个 PR 大家都能审，一次五十个自动生成的 PR 砸过来，评审侧直接瘫痪。Debian 拿开发者参考里 mass-bug filing 那套老流程来套这件事，是个很朴素但很有效的复用。
至于敏感数据不进云端模型这条，不用等投票，现在就该是硬规矩。
我一直觉得开源社区有种特别的价值，它是少数会把分歧完整地、带署名地摆在公开页面上的地方。四份提案，八九个联署人，谁支持谁、谁改了主意，全在那儿挂着，任何人都能点进去读原文。这套东西在别的地方几乎绝迹了。
我们这行现在最容易发生的事，是所有人一起假装某个问题已经有共识了，然后闷头往前走。Debian 这次做的恰恰相反，它把「我们内部没有共识」这件事本身，做成了一份正式文件。
回到开头那行注脚。organically and without language model assistance。
它现在读起来像个笑话，一份禁 AI 的文件要自证不是 AI 写的。但再过两年回头看，它可能是这一整份文件里最重要的一行。因为到那时候，一段文字后面还站不站着一个具体的人，这件事本身就需要被专门声明了。
罗盘不能替你决定往哪儿开，但它至少让你知道自己正在偏。
四张选票，选的从来不是要不要用 AI。选的是我们还打不打算为自己交出去的东西署名。