尼亚尔·道森（nyalldawson）向 QGIS 增强提案（QGIS-Enhancement-Proposals）仓库提交了第 387 号拉取请求（Pull Request #387），提议新增编号为 QEP428（QGIS Enhancement Proposal 428）的文件。QEP428 提出在 QGIS（Quantum GIS）项目中不允许存在人工智能（AI）生成的贡献，规定所有代码与文档提交均须为人工完成，不接受任何 AI 代写内容。此拉取请求已开启，等待项目维护者审核与合并。
正文
nyalldawson 提交了拉取请求 #387，标题为“添加 QEP428：不允许 AI 贡献”。他从自己的分支 qep_428 向 qgis:master 合并了 2 个提交，改动涉及 1 个文件，共增加 7 行、删除 140 行（+7-140）。该 PR 于 2026 年 10 月 7 日合并，最初被加上了 Policy 和 In Discussion 标签。
讨论
nyalldawson（2026年9月24日）
nyalldawson 表示，后续的相关讨论在 qgis-developer 邮件列表中进行（邮件列表链接）。他说明，这次正式将 AI 政策改为严格的“不允许”（NOT ALLOWED）政策。首个提交的信息就是“添加 QEP428：不允许 AI 贡献”，且带有已验证签名。
haubourg（2026年9月24日）
haubourg 认为这个强硬立场需要一些背景，解释为什么要比之前的“人在环路”（Human in the loop）政策更进一步：
- 外部贡献者使用 AI 给维护者带来了巨大且难以承受的压力，而在 LLM 时代之前，维护者的工作本来就已经很艰难。
- AI 产生代码的速度远超人工认真评审的能力，结果要么是积压更多未被评审的 PR，要么是代码未经充分评审而带来质量问题，这两者都是项目不愿看到的。
- 自由软件社区建立在人际网络之上。QGIS 受到各类组织信任，是因为他们知道可以回馈贡献、可以雇佣贡献者提供支持、培训和开发特性。作为社区项目，必须保护这一点，并保持足够带宽来欢迎人类贡献。
因此他强烈支持（+1），并感谢 nyalldawson 在压力下提出这个 QEP。他还想另开话题讨论使用 LLM 进行评审、审计和安全用途，但认为那是非常独立的线索，会先在用户大会上讨论，眼前先处理这个 QEP。
timlinux（2026年9月24日）
timlinux 感谢 nyalldawson，认为用短短一段话而不是长篇大论，应该能消除困惑。
vpicavet（2026年9月24日）
vpicavet 提问：这是否包括 issue 内容、评论、PR 的任何贡献？此外，至少也应该把 QEP 仓库本身包括进来。
Amalvir（2026年9月24日）
Amalvir 说自己直接受到这项新政策影响，也投 +1。他提到自己曾创建过 2 个 AI 辅助修复回归的 PR，用来调查 bug 原因、建议修复和审查代码，当时没意识到会对 QGIS 本就脆弱的评审社区造成伤害。他坦言自己技能还不足以修复 QGIS 这样复杂项目中的 bug，但 LLM 给人一种可以做到的幻觉，几个 token 之后 bug 就好像被修好了。这样做破坏了评审者和贡献者之间的信任契约——即要向这么大的项目贡献，你得知道自己在做什么。另一个影响是，用 AI 的贡献者学不到什么东西，也无法在项目中积累技能，永远别指望自己成为评审者，社区会因此停滞。作为一个热情的开源用户但初学者开发者，他认为 AI 并没有真正让事情变简单，大家要先学会走再学跑。
haubourg（2026年9月24日）
haubourg 回复 vpicavet，同意把 issue 和评论等内容纳入，不过他也提到，自从采用当前系统以来，100% 提交的安全公告都是用 AI 写的（尽管大多涉及的是网站，而非 QGIS 核心）。
kannes（2026年9月24日）
kannes 先声明不要误解他的批评：他认为当前围绕“AI”的疯狂在伦理、社会、经济等诸多方面都是巨大问题，也看到其滥用给维护者和开发者带来的巨大且不公平的压力，他但愿这一切从未发生，但事已至此。不过他想强调一些技术上的好处，而这些好处按他的理解会被这项政策禁止。他故意在此忽略其他所有方面。
他问道，这项政策的意图到底是减轻开发者压力，还是对“AI”作出强硬表态？无论哪种，他认为都可以写得更清楚、也更强。按目前的写法，他会理解为连“使用 LLM 进行评审、审计和安全目的”也不被允许。“assisted”（辅助）和“used”（使用）这两个词非常宽泛，他担心会“把婴儿和洗澡水一起倒掉”——如果这里的婴儿是指那些功能与逻辑上都适合整合进 QGIS、经过人工评审、且不会比纯人类头脑产物带来更多合并后维护麻烦的 AI 使用。
作为一个有时敢在 QGIS 核心的 C++ 世界里迈一小步的人，他发现 LLM 对于发现代码中额外的、非显而易见的上下文很有用。LLM 经常出错，但他坚信其结果可以被人类用来进一步理解代码，从而真正帮着做出更好的贡献。他有时也用 LLM 来模拟评审者：把代码丢给它审查，拿回一些列表，丢弃其中垃圾或不相关的部分，看看剩下的，也许能发现一个实际问题并修好，然后再带着一个稍微不那么差的 PR 去找同事。IDE 里像“Clippy”那样的辅助，给出有时有用的反馈或批评，也能帮助减少错误、提高健壮性。就像网络搜索会同时给出真假信息一样，LLM 也是如此，人类有责任批判性地验证其输出的任何东西。而这样的用途，按他对政策的理解，都会被禁止。
rouault-on-strike（2026年9月24日）
rouault 回应 kannes 说，他们知道可能会把婴儿和洗澡水一起倒掉，但这个婴儿可能本身就无法存活，所以……这个 QEP 只是一个权宜之计。两年前（还没有 AI 的时候）世界没现在这么糟，因此没有理由在没完全理解后果的情况下允许它。也许要等到 AI 泡沫破裂，才能完全理解什么是公平的 AI 使用。
uclaros（2026年9月24日）
uclaros 请求提供更多背景。邮件列表里提到社区受到伤害，以及在不同频道（例如 Mastodon）上提出的观点，这些都很模糊，每个人可能有不同理解。他主要想知道：我们到底要防范什么？是机器人？过客？随机变成常规贡献者的人？现有常规贡献者？还是核心开发者？他也想知道之前的政策为何失败——比如“extractive”标签从未被创建，约 50 个 PR 被标为“AI Assisted”，其中约 40 个未合并就被关闭，还有几个只是被关闭、从未打标签。
nyalldawson 更新文件（2026年9月24日）
nyalldawson 更新了 qep-408-ai-tool-policy.md（第二个提交）。随后他回复 kannes 说，这并不打算成为“刻在石头上、永远不变”的政策，而是“先关上大门，之后如果/当安全且经过适当讨论后，再选择性地开一点”。所以先从极度严格开始，以后再由别人为个案来争取，比如“AI 可以替代 IDE 自动完成”或“AI 可用于语言翻译”等，所有这些都按个案单独考虑。
nyalldawson（2026年9月24日）
nyalldawson 回复 uclaros 说，这是对早先 QEP 的纠正。早先那个显然没起作用（正如 uclaros 指出，流程在现实中并未发生，而且他们因此已经失去了至少一位极有价值的贡献者）。所以如前所述，他们通过猛关上门来纠正，之后再决定想把它开多大。
进入投票阶段（2026年10月5日）
nyalldawson 宣布，讨论期已结束，进入投票阶段；PR 的标签也从“讨论中”变为“投票中”。3nids 请求能否在周末前保持开放，因为贡献者会议正在进行，而且他自己想回复（承认自己来晚了）。nyalldawson 表示会让 timlinux 决定。到了 10 月 6 日，3nids 说今早已和 Tim 讨论过，他同意推进到投票，并将另开一个 QEP 来提出另一场讨论，自己投 +0。
elpaso（2026年10月6日）
elpaso 提醒大家，这个 QEP 只是为了确立初始政策，并不意味着 AI 贡献会被永远、以任何形式禁止。他投 +1。
02JanDal（2026年10月6日）
02JanDal 道歉来晚了，并表达了对政策的一项大担忧：它并不清楚到底禁止什么。用 Claude Code、GitHub Copilot CLI 等当然明确不允许。但 LLM 支持的自动完成呢？非 LLM 的 AI 呢（比如 Jetbrains 系列 IDE 长期用 ML 模型对自动完成结果排序）？用 ChatGPT 头脑风暴设计方案？搜索某个错误信息时无意中看到 Google 的 AI 答案？问 Claude 帮忙解决某个 PyQGIS 的 issue，结果意识到那其实是 QGIS Core 的 bug，然后手动去修？如果想不出某个英文术语，用 Google 翻译从母语译出并用在代码里呢？他理解大家担心给一点点余地就会导致问题持续，但他认为政策必须非常清晰，尤其是考虑到违规的惩罚。他建议改为：“qgis/qgis 仓库中不允许由 LLM 或 AI 代理编写的代码贡献。”（这样去掉了宽泛的“AI”一词，也明确写出了“编写”，使得搜索、头脑风暴等被允许。）最好政策再附上哪些允许、哪些不允许的说明性例子。
timlinux（2026年10月6日）
timlinux 回复 02JanDal 说，合规的衡量标准是“你是否本着良心自己写了代码”——他们不会去窥探你的电脑看你在做什么。你会知道是你自己的大脑写了你要分享的代码，还是别人的大脑写的。
timlinux（2026年10月6日）
timlinux 又对 nyalldawson 和其他关注者说，正如 3nids 提到，他们在 UC2026 现场就此做过讨论，让我们按计划投票。如果这个通过，肯定会有新的 QEP 试图把门打开……但让我们一次处理一个用例，这样大家能待在同一条船上、朝同一方向划。
adamjstewart（2026年10月6日）
adamjstewart 针对 02JanDal 的建议补充说，强烈建议把文档、bug 报告、讨论、PR 描述、评论，以及基本上 GitHub 上的所有书面互动都包括进去。这些往往比代码本身更冗长、更具榨取性。
signedav（2026年10月6日）
signedav 说，正如他在邮件列表写的，他相信争取时间的暂停（moratorium）不会有坏处，直到为每个个体找到好的解决方案。所以投 +1。
02JanDal（2026年10月6日）
02JanDal 回复 timlinux 说，后者的表述里用了“write”（写）这个动词，而当前提案里并没有这个词。也许它是被暗示的，但明确比暗示更好（引用《Python 之禅》）。他澄清说自己并不介意政策的意图（尤其当它只是关于“编写”时），只是担心措辞。
投票与合并（2026年10月7日）
alexbruy 投了 +1。rouault-on-strike 投了 +1（署名 Even Rouault）。vpicavet 也投了 +1。nyalldawson 随后宣布该 QEP 获得批准，投票来自 rouault-on-strike、alexbruy、signedav 和 elpaso；PR 的标签变为“已接受”（Accepted），并移除了“投票中”标签。nyalldawson 将提交 167fde2 合并入了 qgis:master，并删除了 qep_428 分支。10 月 8 日，gacarrillor 也补上了自己的 +1，并感谢 nyalldawson。
评论
多数评论质疑并嘲讽 QGIS 禁止 AI 辅助贡献的决定，认为政策定义模糊、难以证明，且只给可信维护者开例外的做法显得双标，会加速项目被 AI 取代；少数评论支持禁令，认为在没有资本压力时拒绝 AI 垃圾、把维护注意力放回代码质量是合理选择。
认为政策对“AI 辅助”缺乏可操作定义，执行只会吓退贡献者并变成猎巫
- 很多贡献者指出，手写最终代码前用 AI 做原型、或用机器翻译参与社区交流，算不算“AI 辅助”根本说不清；如果不主动声明，维护者几乎无法证明一段代码是否由 AI 生成。与其用禁令区分工具，不如收紧测试、静态检查、风格指南等贡献要求来卡质量。结果却是连愿意纯手写的贡献者也会因担心误触“AI 雷达”而远离项目，执法只会演变成猎巫。（较多人） > 反 AI 政策就像 GPL 里“衍生作品”的概念一样含糊，连愿意手写的贡献者也会因怕踩到别人的 AI 雷达而避开项目，最终无法阻止执法变成猎巫。（@perrygeo）
认为只给可信维护者开 AI 例外是在保护自身利益，而非关心代码质量
- 有评论翻出 QEP 429 为“可信贡献者”增加 AI 政策例外，质疑这等于只有维护者能用 LLM 提速，普通贡献者被排除；QGIS 自称要保护“组织可回馈、可雇人做支持培训”的社区价值，也被解读成在担心放开贡献会削弱维护者的专家价值和就业机会。换句话说，禁令看似反 AI，实际在保护人类贡献者的饭碗。（少数人） > 看他们的另一个 PR，只给可信维护者开 AI 例外，也就是只有维护者能用 LLM 提速，其他人只能忍着？维护者的行为真成熟。（@rfgplk）
认为禁令会加速 QGIS 被边缘化，开源贡献模式也随之走向终结
- 批评者认为，AI agent 几小时内就能重写整个代码库，LLM 脚本已经能替代 QGIS 的部分使用场景；维护者自己用 LLM 生成并审查比等外部贡献者更省时间，导致能省事的贡献者越来越少。贡献者可以选择分叉或私下用 AI 实现功能，不再向上游提交，项目等于自我边缘化，外部开源贡献也随之走向终结。（较多人） > 看来是时候用 AI 从零克隆他们了。（@freakynit）
认为贡献价值与是否用 AI 无关，禁令是拒绝评审的懒惰，高质量辅助应被接受
- 有价值的 PR 就是有价值，与是否用 AI 无关；问题在于项目不想逐条评审，而不是 AI 天生低质。用多个模型互相审查的 AI 辅助贡献反而可能质量更高，项目应该用测试和评审卡质量，而不是一禁了之；维护者不要，贡献者大可分叉。（较多人） > 有价值的贡献就是有价值，“禁止 AI 贡献”就像说 AI 绘画不是艺术；这其实只是项目不想逐条看 PR，跟 AI 无关。（@_antoniwan）
认为真正的瓶颈是维护者的注意力与对齐成本，理解禁令动因但不应一刀切
- 现在瓶颈不再是写代码，而是始终与代码对齐、确认它真的做了你以为的事；对维护者来说，审查陌生人的大 PR 认知负担极重，GIS 复杂内部机制又进一步放大评审成本。因此能省时间的贡献者变少，开源项目收到的请求却涌向单一个人。禁令虽严，但可理解为维护者在节省注意力；更该做的是建立过滤 AI PR 的机制，而非完全关闭。（较多人） > 现在的瓶颈早已不是写代码，而是始终与代码对齐、知道它到底做了什么；对维护者来说，审查陌生人的大 PR 更痛苦，所以禁令虽严，但我理解他们是在节省注意力。（@jcolot）
认为禁用 AI 贡献是保护代码质量和维护专注力的合理选择
- 支持者认为 AI 只是工具，并非处处适用；在没有风险投资带来的高增长压力的开源项目里，为了速度接受 AI 辅助会牺牲对代码的理解并引入 AI 垃圾，项目更应把有限精力放在理清逻辑、测试与长期质量上。也有人认为 QGIS 本身已经够乱，维护带宽更该用来让它变合理，而不是应付不懂原理的 AI 辅助提交；另有评论补充它已用于关键基础设施，质量更需稳妥。（少数人） > AI 是有用工具，但不代表必须随时随地使用，尤其当它可能危及最终质量时。（@imnotr0b0t）
有价值的补充
- QGIS 是免费的 GIS，用于创建、管理、分析、存储和可视化地理空间信息，也就是处理（3D）地图等的软件（@Hendrikto）。
- QGIS 不只是可视化工具，实际还被用于水利管道规划与故障预测等重要基础设施工作；这正对应 XKCD 2347《Dependency》里承重的底层项目（@proxysna）。
- 反直觉的一点：开源项目拒绝 AI 贡献，反而替 AI 公司保住了干净的人类手写训练数据；若放任 AI 生成代码进入代码库，AI 工具将来只能吃自己产出的垃圾（@mangecoeur）。
- GIS 内部机制非常复杂，若缺少清晰抽象，高层推理和人工评审的认知负担会极重；一些历史悠久的开源代码库是有机生长出来的，并没有后来者的抽象红利（@vitorsr）。
- 从抽象演化看，任何（超）智能都会缓存工作成果并追求稳定抽象，但抽象是有损的，最终仍需有人维护；长期可能出现少数实验室瓜分开源项目所有权，或把产品做得过度耦合、让人无法脱离（@sigbottle）。