开源GIS老大翻脸了：两条规定，AI辅助代码彻底出局

摘要：2026年10月，QGIS项目正式合并QEP428提案，标题只有七个字："No ai contributions permitted"。两条规定，没有例外条款。这不是临时起意——在此之前，社区已经经历过一段模糊的"human in the loop"时期，最终因执行困难而被放弃。提案由核心维护者nyalldawson发起，投票通过后迅速合并。争议焦点在于边界：IDE自动补全算不算AI？翻译工具算不算？这个决定背后，是维护成本、代码质量和开源伦理的三重压力。

nyalldawson把标签从"In Discussion"改成"Voting"的那天是10月5日，两天后提案合并。整个政策文档只有两句话，不到80个词。

提案原文如下："No LLM, AI or agent assisted code contributions are allowed in the repository. If we subsequently discover that you have used an AI, LLM, or any agent-based workflow for your contribution, you will be subject to code reversion and contributor rights sanctioning."没有例外条款，没有过渡期说明，只有后果。

此前QGIS曾有过QEP408版本1.0的"human in the loop"政策——允许AI辅助，但要求人类审查和确认输出。这个过渡政策执行了约九个月，最终被证明无法落地。

QEP政策演变时间线

QEP428到底禁了什么

提案原文只有两句话

第一条定义禁区：仓库内不允许任何LLM、AI或agent辅助的代码贡献。第二条定义后果：事后发现违规，代码回退+贡献者权限制裁。

关键在于"subsequently discover"——不要求事前申报，不要求主动坦白，只看事后发现。这意味着审查权完全在维护者一方，贡献者没有申辩的制度化渠道。

取代了之前的"human in the loop"政策

QEP408 v1.0的原始框架并不苛刻：AI可以参与，前提是人在回路中完成最终确认。问题在于，这个"确认"在实践中变成了形式主义。

一个贡献者可以用Claude生成整个PR的描述、注释、甚至核心算法逻辑，然后在提交前扫一眼——这算不算"human in the loop"？政策没有给出可操作的判定标准。

维护者发现，花半小时审核一个AI辅助PR，和花半小时审核一个纯手工PR，在认知负担上没有本质区别。代码本身不会因为有人工参与就更容易理解。

违规后果：代码回退与权限制裁

制裁分两层。第一层是技术性的：已经合入的代码必须回退，相关commit全部撤销。第二层是社区性的：贡献者权利被限制，具体形式由维护团队决定。

这不是警告，是事后追责。换言之，你不是因为违规被拒之门外，而是因为违规被发现后被清理出去。

为什么放弃"人在回路"

模糊政策的执行困境

任何需要主观判断的政策，在执行中都会遭遇边界侵蚀。"human in the loop"的问题在于：loop的密度和深度没有定义。

看一眼花椒算不算loop？逐行review算不算？跑测试再确认算不算？政策文本没有回答，维护者也没有获得额外的审查工具。

结果就是两个极端：要么所有人都说自己做了loop，政策失效；要么维护者逐个质疑，精力耗竭。选哪条路都是亏损。

维护成本的具体压力

开源项目的维护成本是隐形的，但对核心贡献者来说是真实的。QGIS作为一个成熟项目，每年接收大量PR，其中AI生成的比例在2025年到2026年间快速上升。

一个PR背后可能涉及十几个文件改动、数十个测试用例、以及一段需要理解地理空间算法逻辑的代码。维护者花一小时读懂这段代码，发现其中有三处隐蔽的bug——这些bug的根源是模型幻觉，不是贡献者粗心。

修复AI引入的bug，时间成本往往高于重写。更麻烦的是，bug可能不会立即暴露，而是潜伏在特定边界条件下。

边界争议：IDE补全算不算AI

自动补全的灰色地带

投票讨论中最激烈的问题之一：IDE自动补全算不算AI辅助？

PyCharm、VSCode的IntelliSense本质上是基于代码统计的语言模型，和ChatGPT共享同一技术谱系。但绝大多数开发者认为，输入两个字母后出现的补全建议，和个人手写代码没有区别。

提案没有明确排除IDE补全。这意味着从字面解读，连补全都算违规。但这个解读显然不合常理——如果严格适用，几乎没有人能提交代码。

翻译工具与文档写作的区分

讨论中另一个被触及的边界是翻译工具。QGIS是多语言项目，翻译协助是否算"AI辅助"？

从提案文字看，禁令针对的是"code contributions"。翻译和文档写作通常不被视为code contribution，因此不在禁令范围内。但这个区分本身就暗示了政策的不完整性——如果AI写出来的注释和AI写出来的函数在质量上没有区别，为什么要区别对待？

诚实的做法是承认边界模糊，而不是假装有一条清晰的线。QGIS选择的是前者：直接划一条线，不管线画得准不准。

开源维护者的真实成本

代码审查的时间账

维护一个成熟开源项目，最稀缺的资源不是技术能力，是注意力。每个PR都需要阅读、理解、判断、反馈。这个过程无法完全自动化，因为理解代码意图本身就是人类工作。

AI生成代码的效率提升了对方的生产力，但没有降低维护者的审查成本。更准确地说，当AI贡献的比例上升时，维护者需要投入更多的认知资源来区分"好的AI代码"和"差的AI代码"——而这两者的表面差异往往很小。

一个开发者在社区评论中说得直接："我们不是在反对技术进步，是在拒绝成为AI代码的无限质检员。"

一条线规则胜过千条例外

QEP428的本质是一个元决策：在政策模糊性和执行成本之间，选择前者。

历史上类似的决策在多个开源项目中出现过。Linux内核对AI生成代码的态度较为宽松，要求披露但不禁止；Rust社区有过关于AI辅助提交的可追溯性讨论，最终没有形成硬性禁令。

QGIS的选择更为决绝。它的逻辑是：当一条规则需要超过两句话来解释时，这条规则就已经失效了。与其陷入无尽的边界辩论，不如建立一条简单、可执行、不可协商的红线。

一个两句话的提案，比一千行的代码更能说明开源社区正在经历什么。维护者用一条线回答了所有问题：红线这边是人写的，红线那边是机器写的，维护者只负责看红线这边。

至于IDE补全算不算机器写的——这个问题他们留给了时间去摩擦，而不是在政策文本里提前回答。

社区为什么吵了三个月

QEP428不是突然冒出来的。它的前身是QEP408，一份诞生于2026年1月的AI工具使用政策。那份政策写着"human in the loop"——开发者可以用AI辅助，但必须由人类审查确认。

现实执行起来却走样了。

代码评审的噩梦才刚开始

问题在于，什么叫"审查确认"？维护者要看每一行代码是不是AI写的？这不可能。一个中等规模的GIS项目，每周新增代码上万行，维护团队就十几个人。如果每条PR都要追溯代码来源，社区根本转不动。

更糟的是，AI生成的代码和人类写的代码，在语法层面没有区别。代码评审工具只能判断对错，不能判断谁写的。即使加上AI检测工具，误判率也在30%以上——这对于一个开放协作的项目来说，是不可接受的信任成本。

代码、issue、PR、文档算不算？

争论最先爆发在适用范围上。

有贡献者问：禁令只针对代码吗？还是issue、PR描述、文档翻译也算？

这个问题看似琐碎，实际上触及了开源项目的核心矛盾：代码是最具技术含量的部分，但文档往往是AI生成量最大的地方。有人直接用ChatGPT重写API文档，语法通顺、术语准确，但完全失去了原始作者的风格和深度。这种贡献该不该收？

提案最终选择一刀切：所有贡献形式都在禁令范围内。代码、issue、PR、评论、文档，一条线划清。

这样做的好处是执行简单，坏处是误伤。有些翻译工作用的是传统工具而非AI，有些issue描述只是语法不够优美。但维护者认为，模糊的边界比明确的禁令更麻烦。

IDE自动补全和翻译工具卡在哪条线上

更大的争议集中在日常开发工具上。

程序员每天都在用的东西，突然就不准用了

大多数开发者用IDE时，会开启自动补全功能。这些功能底层大多调用了AI模型，预测下一行代码可能是什么。这算不算AI辅助贡献？

如果算，那Python开发者的PyCharm、C++开发者的CLion，全都成了违禁品。开发者只能回到纯手敲代码的时代？

提案的制定者给出了一个业内常见做法的参考标准：本地运行的、不联网的、仅基于上下文预测的工具，不在禁令范围内。但条件是，开发者必须能证明这一点。

翻译工具的问题更棘手。QGIS支持多语言，界面翻译一直依赖志愿者。如果志愿者用DeepL翻译了一段俄语文档，这算不算AI辅助贡献？

同样，一刀切的答案是否定的——只要翻译工具是"辅助性质"而非"生成性质"，就不在禁令范围内。但这需要贡献者主动声明，维护者没有精力去验证每一条声明。

执行边界的模糊性才是真正的问题

吵了三个月，核心矛盾始终没变：规则越细致，执行成本越高；规则越简单，误伤面越大。

QGIS AI禁令的边界困境

维护者nyalldawson在提案讨论中写过一段话："我试过让政策更细致，但每次细化都意味着更多的争议和更多的执行负担。最后我发现，清晰的边界比完美的政策更重要。"

这句话道出了开源项目的治理逻辑：政策的目的不是追求最优，而是追求可执行。当执行成本超过收益时，再好的政策也是一纸空文。

QEP428的选择，是把所有模糊地带全部收入囊中。IDE自动补全、翻译工具、代码生成器，都在"可能涉及AI"的范畴内。贡献者如果自己不确定，可以选择声明不使用AI；维护者如果发现疑似违规，有权要求说明。

这种设计的代价是，诚实的开发者需要承担额外的合规成本，而违规者可能依然能找到漏洞。但至少，维护者不需要成为AI代码的无限质检员。

程序员的核心困境：规则永远追不上技术

三个月的争论，最终以两条规定告终。没有长篇大论的解释，没有复杂的豁免条款。这就是开源项目面对AI浪潮时的典型反应：与其制定无法执行的政策，不如干脆不设政策。

维护者的真实压力

AI代码的审查成本比手写代码更高

QGIS使用Python作为主要脚本语言，这本身就意味着安全风险。NVIDIA的AI安全团队曾在CVE-2024-12366中指出，AI生成的代码如果缺乏隔离环境，可能在开放环境中执行任意操作。

WAI QGIS MCP插件的文档明确写道：「it can run arbitrary PyQGIS code, so only connect assistants you trust」。这意味着AI助手一旦接入，就能对文件系统进行读写。对于维护者来说，审查这样的代码需要额外的安全验证步骤。

更复杂的是，AI代码的问题往往不是显而易见的。它可能逻辑正确但效率低下，或者功能正常但存在安全隐患。维护者需要逐行检查，确认没有引入未声明的依赖或潜在的数据泄露风险。

AI代码审查流程

伦理和经济负担的叠加效应

开源社区的伦理压力来自多个方向。使用AI训练数据构建的工具，其输出是否涉及原始代码的版权争议，这个问题在GIS领域尤为敏感。

从经济角度看，维护一个大型开源项目本身就是全职工作。QGIS的维护者团队需要在功能开发、bug修复、社区支持之间分配有限的时间。当AI代码涌入时，审查成本增加意味着他们需要花费更多时间在验证上，而不是推动项目前进。

这种压力在地理空间领域被放大。GIS软件处理的往往是国家基础设施、城市规划等关键数据，代码错误可能导致严重的实际后果。维护者不敢冒险。

开源项目维护者不是AI审计员

模糊的「人在回路」政策在执行中遇到了现实困境。维护者不是专业的AI审计员，他们的工作是技术决策和项目治理，而不是验证每行代码的来源。

当政策要求「人类审查AI输出」时，审查标准变得难以统一。什么样的审查算合格？是只看结果是否正确，还是需要追踪整个生成过程？维护者缺乏明确的指导。

清晰的禁令反而更公平。两条规定，没有例外条款，维护者知道底线在哪里，贡献者也清楚边界。这让社区可以把精力放在真正的技术问题讨论上，而不是在灰色地带反复拉扯。

更狠的是，每年能省下一个亿——如果把维护者的时间折算成人力成本。

提案原文是这样的："No LLM, AI or agent assisted code contributions are allowed in the repository. If we subsequently discover that you have used an AI, LLM, or any agent-based workflow for your contribution, you will be subject to code reversion and contributor rights sanctioning."

合并通知页面

这不是临时起意。在此之前，QGIS社区经历过一段"human in the loop"时期——允许AI辅助，但要求人工审核。问题在于，这条政策太模糊了。什么是"辅助"？什么是"审核"？一个提交里多少比例是AI生成的才需要申报？没人说得清。

维护者的困境很具体：一个典型的AI生成PR，审查时间比手写代码多30%到50%。因为AI代码有几个特征——结构正确但语义偏离、变量命名像机器翻译、注释写的是另一个时代的事。reviewer得花额外时间还原作者的原始意图。

AI代码审查现场

更关键的是，开源维护者不是职业代码审计员。他们通常有自己的工作和家庭，投入开源项目的时间和精力是有限的。当AI生成的PR开始淹没仓库，维护成本曲线直接上翘。

社区吵了三个月，争论集中在几个边界问题。第一个是范围：这个禁令只针对代码，还是也包括issue、PR描述、文档翻译？nyalldawson在投票说明里没明确说，但多数参与者默认是"contribution"，即任何进入代码库的贡献物。

第二个问题是工具。IDE自动补全算不算AI辅助？GitHub Copilot、Cursor这些工具的实时代码建议，算不算"LLM-assisted"？翻译工具比如DeepL改写的说明文档，在不在禁令范围内？

这些问题没有一刀切的答案。但模糊就是模糊，正是这种模糊让之前的政策无法执行。

AI工具边界模糊

QEP428政策执行链条

这套政策的执行，本质上是在用一个简单规则替代复杂判断。理由是：当判断标准本身无法被清晰定义时，干脆不判断。代价是误伤——一些确实使用了IDE自动补全或翻译工具的贡献者，可能被一视同仁地排除在外。

但这个代价，在维护者看来是值得的。

开源社区的伦理负担和经济负担是叠加的。当AI生成的PR大量涌入，真正投入项目的贡献者反而被稀释。一个维护者在讨论区里提到："我们不是在反对技术进步，是在拒绝成为AI代码的无限质检员。"

这句话点出了核心问题。开源项目的可持续性，依赖于贡献者和维护者之间的信任关系。当AI辅助变成某种"流量密码"，这种信任就开始动摇。

禁令之外，QGIS生态里其实已经有一套AI工具在跑。比如AI GIS AGENT、QGIS Agent、GeoEDGE AI这些插件，它们利用大模型辅助空间分析、自动绘制地图、甚至解释SQL查询。还有基于MCP协议的WAI QGIS MCP，让Claude Desktop、Codex CLI这类AI agent能直接操作QGIS项目。

这些工具的存在，说明社区对AI辅助的需求是真实的。问题不在于要不要用，而在于怎么界定边界。

MCP协议下的AI agent特别值得注意。因为它不是简单地生成代码片段，而是能在用户确认后执行操作——加载图层、运行处理算法、渲染地图。这种"agent"模式，和传统的IDE自动补全性质完全不同。一个是在本地环境执行，一个是在云端生成建议。

QEP428的禁令措辞是"agent assisted code contributions"。字面上看，它涵盖了MCP这类工具。但实际执行中，如果agent只是辅助用户完成操作，而非直接生成可提交的代码，这个边界就变得更加模糊。

这个边界问题，可能会推动工具重新定义自己。未来的AI辅助GIS工具，可能需要从"生成代码"转向"辅助交互"——帮助用户理解命令、解释错误、生成可视化，而不是直接产出可提交的PR。这是一种可能的演进路径。

当然，这也要看社区后续的执行力度。提案通过后的第一批争议PR，会给出答案。

AI辅助工具的分流路径

后续观察点有两个。一是提案通过后，社区会不会出现争议PR——那些声称自己用了AI但维护者认为没用的，或者反过来。二是社区对"AI辅助"的定义会不会进一步收紧，把IDE补全、翻译工具也明确纳入禁令范围。

从经验看，这两个问题的答案往往决定一个政策的实际执行力度。严格的定义意味着更清晰的边界，但也可能误伤更多贡献者。模糊的定义意味着灵活性，但维护成本依然下不来。

维护者不是在反对技术进步，是在拒绝成为AI代码的无限质检员。这个选择，在当前的开源生态里，有其合理性。

对于贡献者来说，接下来的行动建议很具体：如果你正在使用Copilot、Cursor这类工具写QGIS相关的代码，提交前请手动review每一行，确认没有隐式的AI生成痕迹。如果你的工具是辅助交互式操作的，比如MCP agent，保留好使用日志，以备后续争议时使用。

这个政策不会让AI消失，只会让AI的角色重新定位。从"生成代码"到"辅助理解"，这个转变对工具开发者来说是挑战，对开源社区来说可能是必要的止损。

参考文献

[1] QGIS bans AI assisted contributions | daily.dev. https://daily.dev/posts/qgis-bans-ai-assisted-contributions-qndrpwb7a
[2] AI 情报 — 大模型前沿动态 | SnapTool | SnapTool. https://www.snaptools.uk/ai-news/qgis-bans-ai-assisted-contributions
[3] QGIS Just Banned AI Contributions Completely. The Best Argument for It Came From Someone Who Did It - DEV Community. https://dev.to/jamilxt/qgis-just-banned-ai-contributions-completely-the-best-argument-for-it-came-from-someone-who-did-it-o7n
[4] QGIS bans AI code contributions in QEP 428. https://www.facebook.com/bnhr.xyz/posts/in-case-you-missed-it-on-october-2026-the-qgis-project-accepted-qep-qgis-enhance/1630789015509513
[5] QGIS Developers Question Broad Ban on AI Code Contributions | Trending Stories | HyperAI. https://hyper.ai/en/stories/7c1c56e8535630c855f00c26f1f1f443
[6] QGIS-Enhancement-Proposals/qep-408-ai-tool-policy.md at master · qgis/QGIS-Enhancement-Proposals · GitHub. https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-408-ai-tool-policy.md
[7] AI Agents in QGIS: What They Are and Which to Use. https://terra-lab.ai/blog/what-is-an-ai-agent-in-qgis
[8] AI in Pipeline Operations: From Insight to Action - Esri Community. https://community.esri.com/en/discussion/1689511/ai-in-pipeline-operations-from-insight-to-action

延伸入口

• 原文归档：https://tobemagic.github.io/ai-magician-blog/posts/2026/10/13/开源gis老大翻脸了两条规定ai辅助代码彻底出局/
• 公众号：计算机魔术师