QGIS 禁止 AI 辅助贡献：首次政策失败后关上大门

尽管此前允许对 AI 参与进行标注，QGIS 仍在 2026 年 10 月 7 日通过了一项严格政策，禁止 AI 辅助贡献。这个开源制图项目现在禁止提交由 LLM、AI 系统或基于智能体的工作流创建的代码。违规行为可能导致代码被回退，并对贡献者的权限实施制裁。

这一决定不只是又一项针对低质量自动化补丁的规定。QGIS 此前曾尝试更宽松的做法，以披露和人工责任为基础。项目参与者最终认为，这种做法既无法保护维护者免受过度审查工作的影响，也无法维护社区开发所依赖的信任。

这一经历让 QGIS 站在开源社区分歧不断扩大的其中一端。QEMU 同样拒绝 AI 生成的贡献，而 Linux 内核则允许在人工承担责任的前提下披露相关辅助。争议的核心在于：是在项目边界处加以限制，还是在审查过程中落实问责。

首次政策失败后，QGIS 禁止 AI 辅助贡献

决定性的变化在于，披露信息已不再让 AI 辅助代码具备被纳入项目的资格。

获采纳的 AI tool policy 规定，主 QGIS 仓库不允许任何由 LLM、AI 或智能体辅助生成的代码贡献。政策还警告称，若事后发现违规，可能导致代码回退及对贡献者的制裁。

QGIS 通过 QGIS Enhancement Proposal（即 QEP）采纳了修订后的措辞。QEP 是该项目用于讨论和记录重大技术或治理变更的流程。贡献者 Nyall Dawson 于 9 月 24 日发起该提案，并将其描述为正式转向“NOT ALLOWED”。

该提案于 10 月 5 日进入投票阶段。10 月 7 日，随着四名具名项目参与者投下支持票，提案被宣布通过。Dawson 当天将这一变更合并至项目的 enhancement-proposal 仓库。

这一措辞至关重要，因为 QGIS 此前实行的是更宽松的政策。AI 的参与可以披露、标注，并在人工参与审查的机制下接受评估。贡献者仍需承担责任，而标签则向审查者说明补丁的生成方式。

据政策讨论参与者表示，这一折中方案在实际运作中失败了。一名审查者估计，大约有 50 个拉取请求获得了“AI Assisted”标签。其中约 40 个在未合并的情况下关闭，不过这些数字来自讨论，而非正式审计。

此前的流程还曾设想为过度消耗社区精力的贡献设置“extractive”标签。一名参与者表示，该标签从未创建。这一缺口让维护者拥有了一项政策概念，却未能在日常仓库工作中得到一致落实。

讨论中提及的四个 AI 辅助拉取请求于 10 月 2 日关闭，涉及分类逻辑、PostgreSQL 监听器、共享地理空间数据集以及并行 provider 创建。这一范围表明，冲突并不局限于表面性的改动。

该政策专门适用于主 QGIS 仓库中的代码贡献。获采纳的文本并未明确禁止所有 QGIS 渠道中每一种 AI 辅助的 issue、评论、翻译或文档修改。

一些贡献者希望规则覆盖书面互动。另一些人则希望措辞更窄，区分生成代码与研究、自动补全、翻译或私下审查。最终文本保留了更宽泛的表述：“AI or agent assisted code contributions”。

这一尚未厘清的边界将影响执行。自主编程智能体显然属于禁令范围。将模型生成代码复制进补丁的贡献者，看起来同样受到涵盖。

机器学习自动补全、AI 辅助调试或设计头脑风暴的地位则不那么明确。这些活动可以影响代码，却未必会提供一段可辨识的生成文本。

目前，QGIS 选择了封闭边界。贡献者无法仅通过标注、审查或承诺个人负责，就让被禁止的代码变得可接受。

维护者时间成为稀缺资源

QGIS 将审查注意力视为有限的社区资产，而非附加在每个提交补丁上的免费服务。

AI 编程系统生成看似合理的改动，速度可能远快于经验丰富的维护者完成评估。审查者仍须理解受影响的子系统、测试假设、检查边缘情况，并考虑后续维护。

这种不对称改变了开源参与的经济逻辑。生成一个补丁可能只需几分钟，而判断它是否适合纳入成熟的地理空间应用程序，则可能需要数小时甚至数天。

QGIS 并非一个小型演示仓库。其项目概览介绍了面向制图与地理空间分析的桌面端、服务器、Web 和移动端应用。社区还维护着超过 2,000 个插件。

对该环境的改动可能影响数据格式、坐标系统、渲染、空间数据库和自动化工作流。一个局部看来正确的补丁，可能引入超出贡献者即时测试用例的后果。

因此，审查依赖的不只是通过自动化检查。维护者需要确信，贡献者理解周边代码，并能在提交后回答问题。

一名参与者对这种信任问题给出了格外直接的描述。该贡献者曾在利用 LLM 调查 bug、建议变更及审查代码后，提交两个 AI 辅助的回归修复。

这位贡献者写道，这些补丁制造了一种能力假象。该工具让人看似可以修复复杂代码库，而无需形成足以独立支撑这些工作的知识。

这一坦承概括了 QGIS AI 贡献政策背后的核心关切。补丁并非孤立而来。它会在作者、审查者以及日后维护受影响代码的人之间建立一种关系。

具备相关知识的贡献者能够解释改动为何安全，在收到反馈后进行修订，并识别关联故障。转交模型输出的人，可能无法做到其中任何一项。

届时，审查者就成为真正承担推理工作的作者。他们必须重新构建问题、验证拟议方案，并向提交者讲解补丁所声称已经理解的内容。

当这种工作反复消耗的项目知识多于其创造的知识时，它就变成了掠夺性的负担。仓库获得了一项拟议变更，但社区失去了原本可用于支持发布、现有贡献者或精心准备的修复工作的时间。

风险并不只是 AI 生成代码会包含错误。人工编写的补丁同样可能无法通过审查、忽略边缘情况，或引入回归问题。

区别在于提交能力。编程智能体降低了生成又一个看似合理补丁的成本，却没有降低证明该补丁值得信任的成本。

QGIS 贡献者还将这种压力与社区延续性联系起来。开源项目需要新人逐步成长为审查者、维护者、培训者或支持提供者。

如果 AI 让人们跳过学习过程，这些贡献者可能永远无法获得审查他人工作的知识。项目收到更多提交，却没有培养出更多维护者。

这会形成不健康的漏斗。更宽的一端不断扩张，因为更多人可以生成代码；最窄的一端却维持不变，因为经验丰富的人类仍要作出接纳决定。

维护良好的工程知识库可以减少反复梳理架构和既有决策的时间，但无法将陌生补丁的责任从其作者转移给志愿审查者。

QGIS 的回应是限制进入这个漏斗的内容。该政策牺牲了潜在有用的 AI 辅助改动，以保护那些负责决定最终发布内容的人。

真正的分歧在于限制与人工问责

开源项目都认同人类仍应承担责任，但对于仅凭责任是否足以控制 AI 生成内容的规模，彼此存在分歧。

QGIS 现在采用限制性模式。项目在维护者评估披露、测试和人工审查能否让某个补丁被接受之前，就排除了 AI 辅助代码。

QEMU 也采用了类似边界。其 code provenance policy 拒绝其认为包含或源自 ChatGPT、Claude、Copilot 和 Llama 等工具生成内容的贡献。

QEMU 部分从来源可追溯性出发制定这项规则。贡献者通过 Developer Certificate of Origin（通常称为 DCO）证明自己有权提交补丁。DCO 是人类就贡献来源及提交权利作出的法律证明。

QEMU 认为，当前的生成工具使版权和许可状态难以确定。训练材料可能包含适用不兼容条款的代码，而生成输出的法律待遇仍未明确。

其政策在一个重要方面更为狭窄。当生成输出不进入贡献内容时，QEMU 允许将 AI 用于研究应用接口、静态分析或调试等活动。

QGIS 并未提供一份等同的可接受辅助活动清单。其简洁政策倾向于明确禁止，而不是列出详细例外。

Linux 内核选择了另一条路径。其 assistant guidelines 允许 AI 参与，但将认证与审查责任交给人类提交者。

在这一流程下，AI 智能体不能添加 Signed-off-by 标签。人类必须审查生成的代码、确认许可合规、添加认证，并为贡献承担责任。

内核还要求添加 Assisted-by 标签。其工作流要求可复现的 bug、经过测试的修复、对缺失验证的明确披露，以及由人类控制的提交。

这一模式试图保留有用的自动化能力，同时不将智能体视作法律或社会意义上的参与者。机器可以帮助产出工作，但人必须拥有最终结果。

QGIS 在转向现行政策前曾考虑过这一原则的一个版本。其经历表明，当负责的人无法独立解释或维护生成补丁时，人类责任会变得薄弱。

两种策略都承认同一个根本问题：模型输出并不会自行验证，而仓库也无法将责任归于软件服务。

它们的分歧在于项目应在何处承受不确定性。Linux 允许补丁进入常规流程，并要求更强的人类问责；QGIS 则在补丁能够占用审查者注意力之前，阻止这类补丁进入。

限制性方法为维护者提供了简单的拒绝依据。他们无需争论补丁中有多少内容来自模型，或人工编辑是否已对其进行了充分改造。

然而，执行仍在很大程度上依赖贡献者的诚实。生成代码并不带有可靠标记，而自动化 AI 检测器也无法以实施制裁所需的置信度确定作者身份。

问责路径避免了不可验证的纯粹性测试。它评判测试、来源、说明与责任归属，而不是试图还原开发过程中使用过的每一种工具。

然而，在高吞吐量下，这一流程仍可能失效。一份措辞严谨的披露不会缩短复杂审查所需的时间，人工签名也无法凭空创造缺失的专业能力。

因此，两种模式针对的是不同风险。Linux 在保留人类责任的同时，保护 AI 辅助开发的准入空间。QGIS 则通过排除一种广泛的生产方式，保护稀缺的审查能力。

这两项政策都没有为开源领域整体的问题给出定论。每个项目都必须让自身边界与其治理方式、维护者供给、法律容忍度和贡献者文化相匹配。

明确禁令仍会形成模糊边界

QGIS 的规则在核心上很简单，但在边缘地带存在不确定性，因为现代开发工具会将辅助与作者身份交织在一起。

很少有贡献者会误解：要求编码代理实现某项功能后提交其结果，是被禁止的。真正棘手的情况始于 AI 改变了一个人获得独立编写代码的方式。

在提案讨论期间，贡献者举出了自动补全、代码审查、翻译、研究和调试等例子。即使用户从未打开聊天机器人，现代开发环境也可能使用机器学习。

编辑器可能用模型对补全选项排序。搜索引擎可能在常规结果之前展示 AI 生成的答案。翻译服务可能帮助贡献者写出英文标识符或注释。

开发者可能要求 LLM 解释一个陌生的子系统，随后关闭聊天窗口并手动编写补丁。另一位开发者可能将模型作为私下的审查者，只接受一条警告，同时舍弃数条错误建议。

这些情况并不能简单归入生成代码或人工创作代码。它们涉及人在不同阶段与系统之间传递的信息和判断。

一名参与者提议将禁令限定为由 LLM 或 AI 代理“编写”的代码。这样的措辞会为头脑风暴、搜索或分析留下空间，同时不接纳生成式实现。

项目领导者在批准前拒绝缩小规则范围。Dawson 将禁令描述为一扇关闭的门，未来的提案可在特定用途经过适当讨论后，有选择地重新打开这扇门。

另一名贡献者称该政策是权宜之计。一位项目领导者同样表示，这项限制未必是永久性的，也未必具有普遍适用性。

这一过程揭示了一项有意为之的权衡。QGIS 接受边缘案例中的模糊性，以消除其当前默认立场的不确定性。

这种做法带来即时缓解，但也引发了正当程序问题。该政策允许在事后发现存在被禁止的辅助时，对贡献者权利施加制裁。然而，它并未规定调查程序、证据标准或申诉渠道。

它也没有说明，AI 影响达到何种程度会使代码成为“辅助完成”的代码。复制一段函数是容易判断的情况；改变开发者思路的架构说明则更难界定。

项目领导者承认，他们无法检查贡献者的电脑。其中一人建议采用善意测试，核心在于代码是否确实由贡献者自己的头脑写成。

这一标准体现的是社区信任，而不是技术检测。它要求贡献者即使很容易隐瞒，也要遵守政策。

基于信任的执行在开源领域很常见。维护者本就依赖贡献者如实报告来源、测试限制、利益冲突和第三方代码。

当一项政策包含制裁措施时，风险会变得更高。错误指控可能会劝退合法贡献者，尤其是在代码风格显得通用或异常精致时。

一刀切的限制也可能排除有用的无障碍支持。翻译、代码解释和个性化辅助能够帮助跨语言工作或存在认知障碍的贡献者。

这些代价并不会否定这项政策。它们表明，这项限制应被理解为一项暂停措施，而非一套已经完成的 AI 辅助开发理论。

QGIS 立场最有力的版本是操作层面的：其第一项政策未能充分降低负担，因此项目选择了一条维护者能够迅速执行的规则。

最薄弱的版本则会声称，所有受 AI 影响的代码本质上都有缺陷。项目自身的讨论并未得出这一结论。

一些参与者描述了真正有用的私下审查和代码探索。即使是支持者也承认，禁令可能会在排除有害用途的同时，舍弃有益用途。

QGIS 选择了可预测的治理，而非逐案优化。在压力之下，这一选择具有可辩护性，但其正当性将取决于执行是否一致且合乎比例。

禁令保护的是人类贡献者培养链条

这项政策归根结底是为了维护一个能够培养维护者的社区，而不只是筛选出能通过测试的代码。

QGIS 服务于使用地理空间软件开展工作的组织，而这些工作远远超出代码仓库本身。其用户制作地图、分析空间数据、发布服务，并连接众多格式和数据库。

这些组织也可以从 QGIS 社区聘请人员从事开发、培训和支持。这种关系让用户获得专业知识，同时帮助经验丰富的贡献者维持长期参与。

当 AI 辅助的开源开发将代码产出与专业能力分离时，可能会扰乱这一循环。生成的补丁或许能解决眼前问题，却不会培养出一个之后真正理解该子系统的人。

这种损失会在后续回归问题中显现。维护者需要有人记得最初的约束条件、能够调查新症状，并能判断修订是否保留了预期行为。

模型会话没有持续的社会责任。提交其输出的人，也可能在眼前补丁被接受后消失。

开源项目一直都会收到偶尔的“一次性贡献”。真正令人担忧的是规模。编码代理能够把偶发模式转变为持续涌入的大量实质性改动。

这种涌入同时给技术审查和社区判断带来压力。维护者必须判断，新来者是希望学习，还是只想让项目为生成的工作背书。

这种区别会影响投入多少教学是否合理。审查部分是质量控制，但它也是项目培养未来协作者的方式。

花时间帮助一位积极参与的贡献者理解某个子系统，可能成为一项投资。花时间修复无法讨论其提交内容的人所提交的代码，往往不会带来这样的回报。

这正是为什么 QGIS 的决定不能被简化为对自动化的恐惧。该项目捍卫的是一种特定交换：贡献者带来投入和不断增长的理解，维护者则提供审查和指导。

AI 编码改变了表面上的平衡。它让贡献者在建立通常与该工作相对应的知识之前，就能提交看似更完整的成果。

补丁可能可以编译，也能解决可见症状。但它仍可能依赖虚构的假设、不完整的测试，或只有经验丰富的审查者才会发现的偶然行为。

对于地理空间软件而言，隐藏假设的代价可能格外高昂。坐标参考系统、几何有效性、提供程序行为和数据库语义，可能让一项小改动演变为广泛的兼容性问题。

自动化测试有所帮助，但测试编码的是已知预期。它们并不能保证生成的修复尊重每一种工作流、平台、数据源或性能约束。

该禁令要求贡献者在提交之前跨越这道知识鸿沟。他们仍可以学习代码、查阅文档、讨论设计，并准备人工编写的改动。

这一要求提高了准入门槛。它可能让那些谨慎使用 AI、并理解每一行提交代码的有能力开发者感到挫败。

QGIS 接受这种排除，因为维护者已经体验过另一种选择。该项目将审查者的可持续性置于最大化候选补丁数量之上。

这一立场也向在内部采用编码代理的组织发出信号。公共代码仓库并不是为私下生成的工作提供无限下游验证的服务。

一家公司可以为自己的部署生成 QGIS 改动，并在自身环境中进行测试。向共享项目提交，会将新的义务转移给志愿者和由社区资助的维护者。

希望获得上游接受的组织，需要提供可追责的人类专业能力。这可能意味着更深入的内部审查、资助一位成熟贡献者，或培养理解 QGIS 架构的员工。

结果是在使用开源软件与参与其生产之间划出更清晰的边界。AI 降低了尝试后者的成本，但 QGIS 坚持认为，它并不会降低所需的理解水平。

三项信号将表明政策是否奏效

下一项检验并不是 AI 辅助的拉取请求是否消失，而是 QGIS 能否在不削弱正当参与的前提下获得审查能力。

第一个信号是项目在未来数月内的拉取请求积压情况。维护者采纳禁令，部分原因在于生成的提交可能比人工审查的速度更快地涌入。

更短的队列、更快的决策或更少的大型补丁，都将支持该政策的操作性论点。若过载持续存在，则说明 AI 辅助贡献只是审查压力的一个来源。

这一指标需要结合背景理解。QGIS 的开发量可能随着发布计划、贡献者可用性和重大功能工作而变化。

因此，维护者应比较相似时期，并区分被拒绝的提交与被接受的工作。仅凭原始拉取请求数量，无法显示审查质量是否改善。

第二个信号是后续 QEP 对允许用途的界定。项目领导者一再将该限制描述为起点，未来的提案可以有选择地放宽它。

针对私下审查、翻译、研究或自动补全的狭窄例外，将表明 QGIS 能够区分有害的提交模式与风险较低的辅助。它也将澄清“辅助”在实践中的含义。

若没有后续提案，则表明临时边界正在成为长期默认立场。这一结果仍可能降低工作量，但会让边缘案例主要由非正式判断来治理。

第三个信号是贡献者留存。QGIS 应关注经验丰富的维护者是否保持活跃，以及新的人工贡献者是否能逐步承担更深入的职责。

如果该政策在保护既有审查者的同时，保留了新来者学习的路径，它将显得成功。若参与者减少，却没有相应提升维护者能力，则它的说服力会减弱。

执行案例将在这一信号中提供另一项重要细节。对承认违规行为的透明回应，与基于代码风格怀疑而实施制裁，并不相同。

一致性将决定贡献者把规则视为清晰的社区边界，还是不可预测的作者身份测试。公开说明能够帮助界定先例，同时不暴露私人信息。

与 Linux 和 QEMU 的比较也将继续具有参考价值。Linux 正在测试披露、可复现性和人工认证能否控制与 AI 相关的成本。QEMU 正在测试一项以来源为基础、范围更精确的禁令。

如果宽松项目能够在不耗尽审查者的情况下维持质量，要求 QGIS 重新打开大门的压力将会增加。如果它们反复遭遇无法验证的补丁洪流，QGIS 的早期限制将显得更具说服力。

开发者不应将这项政策视为对 AI 编程的普遍裁决，而应将其理解为针对一次失败治理实验、且仅适用于该代码库的回应。

如今，在贡献代码前，开发者需要判断自己的工作流程是否能够真诚地遵守这项规则。如果不能，披露使用情况也无法挽回该提交。

基于 QGIS 进行开发的组织，也应审视谁能够为任何拟议的上游变更提供支持。缺乏持续人类责任归属的生成式实现，如今将面临被直接拒绝的风险。

QGIS 禁止 AI 辅助贡献，原因在于该项目认定：获取代码生成能力的门槛，已经远低于开展负责任审查的能力门槛。未来几个月将显示，弥合这一差距究竟是在保护社区，还是只会将模糊性转移到其他地方。

请关注积压事项、下一项政策提案以及贡献者渠道。这些信号结合起来，将揭示 QGIS 是否找到了可持续的边界，还是仅仅为一场更艰难的辩论争取了时间。