【一位成员评论】 这是否也包括对 issue 内容、评论、PR 的任何贡献？
我同意这一做法，不过自我们启用这个系统以来，提交的安全公告100%都是用 AI 撰写的（不过大多涉及我们的网站，而非 QGIS 核心）。
【一位用户的长篇评论】 请不要误解我下面的批评。我认为当前围绕"AI"的疯狂在伦理、社会、经济等诸多方面都是一个巨大的问题。我也看到这种滥用给维护者和开发者带来了巨大且不公平的压力。我真希望这一切从未发生，但事已至此。
不过我想强调一些技术层面的好处，而按照我的理解，这项政策将禁止这些用途。我在这里刻意忽略其他所有因素。
我也完全可以理解，如果这更多是一种将某些被视为不道德的事物加以禁止的"政治性"举动。但这是初衷吗？是为了减轻开发者的压力？还是为了对"AI"表明强硬立场？无论如何，我认为它可以更清晰，或许也会更有力。
按照目前的写法，我理解该政策同样不允许将 LLM 用于审查、审计和安全目的。“assisted（辅助）“和"used（使用）“这两个词非常宽泛，我担心它们可能会把孩子和洗澡水一起倒掉（如果这个"孩子"是指那些在功能和逻辑上适合并入 QGIS、经人工审查、且不会比100%出自人脑的代码带来更多合并后维护负担的 AI 用法的话）。
作为一个有时敢于尝试踏入 QGIS 核心 C++ 世界的人，我发现 LLM 对于发现代码中额外的、非显而易见的上下文很有用。它们经常出错，但我坚信其结果可以被人类用来进一步理解代码，并切实帮助产出更好的贡献。
我有时还发现 LLM 适合用作一个"模拟审查者”。把你的代码丢给它审查，收回一份清单式反馈，丢弃其中垃圾或无关的部分，看看剩下的，也许发现一个真正的问题，修复它，然后带着一个稍微不那么糟糕的 PR 去找你的同事。IDE 里一个"Clippy”，能为你的开发提供一些——有时有用——的反馈或批评，也可以帮助减少错误、提高健壮性。就像网页搜索会同时返回真假信息一样，LLM 也会如此。批判性地验证其输出是人类的职责。
按照我对这项政策的理解，这类用途也会被禁止。
【回复】 “assisted"和"used"这两个词非常宽泛，我担心它们可能会把孩子和洗澡水一起倒掉——
是的，我们知道可能会把孩子和洗澡水一起倒掉，但这个孩子可能根本无法存活，所以……
这份 QEP 是一项权宜之计。两年前，没有 AI 的世界运转良好，也不像今天这么糟糕，因此在完全理解其后果之前，没有理由允许它。我们可能得等到 AI 泡沫破裂之后，才能完全理解怎样才算公平的 AI 使用。
【uclaros 于2026年9月24日审查并评论】 能否为这项提案提供更多背景信息？
邮件列表的帖子提到社区受到了伤害，以及在不同渠道（如 Mastodon）提出的观点，这相当模糊，我担心我们每个人对此的理解都不尽相同。
我主要想知道我们到底想防范什么：是机器人？路人？随机访客变成常规贡献者？现有的常规贡献者？还是核心开发者？
我还想知道此前的政策为何失败——extractive 标签从未被创建，约50个 PR 被打上 AI Assisted 标签，其中约40个未经合并即被关闭。还有其他一些直接被关闭，甚至从未被打上标签。
【nyalldawson 于2026年9月24日评论（提案作者）】 @kannes 我们的意图并不是让这成为"刻在石头上、永远不变"的政策。更准确地说，是"让我们先关上门，等将来安全且经过充分讨论后，再选择性地开一条小缝”。
所以我们先从极度限制开始，之后再由某个人（可能是别人）为诸如"AI 可以作为 IDE 自动补全的替代品”/“AI 可以用于语言翻译"等情形辩护，所有这些都将逐一按个案考虑。
@uclaros 这是对早先那份 QEP 的修正。那一份显然没有奏效（正如你所指出的，该流程在现实中并未执行，并且我们已经因此失去了至少一位价值极高的贡献者）。
所以如上所述，我们通过把门猛然关上来进行纠正，之后再选择要把门缝推开多远。
【2026年10月2日被引用的关联 PR（均已关闭）】
- 修复错误的 Natural Breaks (Jenks) 分类
- [Postgres] 连接断开后重新连接 NOTIFY 监听器
- 读取工程时在图层间共享 OGR 数据集
- 为 WFS provider 启用并行创建
【nyalldawson 于2026年10月5日评论】 该提案现已通过讨论期，进入投票阶段。（标签由 In Discussion 更改为 Voting）
【3nids 于2026年10月5日评论】 能否让它保持开放到本周结束？理由是……
@nyalldawson 我今天早上和 Tim 讨论过了。我同意推进到投票阶段，并将另开一份 QEP 来发起另一场讨论。
请记住，这份 QEP 旨在确立一项初始政策，并不意味着 AI 贡献将被永远、以任何形式地禁止。
【一位核心开发者评论】 抱歉我也来晚了……
我对这项政策有一个很大的担忧：它并没有说清楚究竟什么被禁止。使用 Claude Code / GitHub Copilot CLI 等？当然，这显然不被允许。但基于 LLM 的自动补全呢？非 LLM 的 AI 呢（例如，基于 JetBrains 的 IDE 长期以来一直在使用机器学习模型对自动补全结果排序）？用 ChatGPT 头脑风暴设计方案呢？搜索一条报错信息，无意中在 Google 的 AI 回答里看到答案呢？向 Claude 请教某个 PyQGIS 问题，结果发现其实是 QGIS Core 的 bug，然后手动去修复它呢？如果我想不出某个英文术语，用 Google 翻译从我的母语翻译后再用到代码里呢？
我明白，人们担心哪怕给出一点点宽松空间，问题就会持续存在，但我认为政策必须非常明确，这一点极其重要，尤其是考虑到处罚的情况下。
一个可能的措辞是： “No code contributions written by LLM or AI-agents are allowed in the https://github.com/qgis/qgis repository."（在 QGIS 仓库中，不允许提交由 LLM 或 AI 智能体编写的代码贡献。）
（这去掉了非常宽泛的"AI"一词——它会让 JetBrains 的排序模型等都变得可疑——并明确使用了"written（编写）"，从而使搜索、头脑风暴等被明确允许。）
最好政策中还能包含一些说明性示例，明确哪些行为允许、哪些不允许。
【回复】 我认为合规的标准是"你是否凭良心亲手写下了这些代码”——我们并没有能力窥探你的电脑、查看你做了什么。你自己清楚，是你自己的大脑写出了你想分享的代码，还是别人的大脑写的。
【另一位成员评论】 @nyalldawson 以及关注这份 QEP 的各位——正如 @3nids 提到的，我们在 UC2026 上就此进行了一些讨论——让我们按计划继续进行投票。如果这份提案通过，肯定还会有一些新的 QEP 试图把这道门撬开……但让我们一次只处理一个用例，这样大家才能待在同一条船上，朝着同一个方向划桨。
【最后一条评论】 “No code contributions written by LLM or AI-agents are allowed in the https://github.com/qgis/qgis repository.”
我强烈建议把文档、bug 报告、讨论、PR 描述、评论以及 GitHub 上基本上所有书面交互都纳入禁止范围。这些内容往往比代码本身更加冗长、更具"抽取性”。