GHC 确立 LLM 辅助贡献政策，明确使用与披露边界

贡献者可以做什么、必须披露什么，以及我们为何认为这项政策合理。

GHC 现在已经制定出一项针对使用 LLM 辅助贡献的具体政策。到 10 月中旬，维护者已在审查讨论中直接引用该政策：Julian Ospald 引用了“AI 政策”的 P3，而 Andreas Klebinger 则将 LLM 生成的错误修复描述为“没问题，这是政策允许的”。

GHC wiki 页面本身早于今年夏天的这场争论，因此仅凭 URL 看不出改变了什么。当前文本则能看出来。

该政策沿用了 Simon Peyton Jones 通过 ghc-devs 讨论制定的文件，而不是 7 月提出的竞争性方案——“共同声明”。该声明的作者明确表示，它并非旨在取代贡献政策，Teo Camarasu 也主张不应将其视为贡献政策。

讨论期间，结构发生了变化。7 月 27 日，草案被概括为三个政策要点和一项建议：让合并请求易于审查，对贡献负全责，申报直接使用 LLM，并且最好亲自撰写最终版本。当前文件包含四个政策要点和一项强烈偏好。“优先考虑人和社区”现在是 P1；此前的要点移至 P2–P4；亲自撰写最终版本成为 P5，并且仍然是一项偏好，而不是要求。

我们与这场讨论有直接利害关系。Vladislav Zavialov 和 Andrei Borzenkov 在 Serokell 从事 GHC 相关工作，Andrei 参与了政策讨论。代码助手也已成为我们自身工程工作流的一部分。

对 GHC 而言，实际问题是审查成本。工具辅助的工作只有在不会让维护者替贡献者思考时才有用。

GHC 目前有超过 6,500 个未关闭工单。有些是棘手的编译器问题。另一些虽然日常但仍然有用：复现旧报告、缩减测试用例、补充缺失的基准测试，或检查某个错误是否仍然存在。

这项政策的内容

该政策并未对 LLM 总体上是好是坏表明立场。它明确指出，项目对于其成本和收益尚无共识。相反，它规定了对贡献和审查的期望。

共有四个政策要点和一项强烈偏好。

P1：优先考虑人和社区。贡献者可以使用 LLM，但与审查者的直接讨论应仍由真人进行。不应转述生成的文本，以取代贡献者自己的判断。允许使用 LLM 浏览代码库、翻译文本或调查问题，但该工具不应取代开源项目借以培养贡献者和维护者的对话。

P2：让合并请求易于审查。预计贡献者在一项贡献上投入的精力，应显著多于审查者理解它所需投入的精力。MR 应有明确目标、经过说明的设计、有用的示例和测试，并拆分成易于处理的片段。如果一个生成的补丁能够编译，却仍需审查者自行还原其中的推理过程，那么它就不符合这一标准。

P3：人类作者身份与全部责任。 每项贡献都必须有一位身份明确的人类作者，能够理解并解释提交审查的每一行代码和每一句文档。只要贡献者已充分审阅生成内容并足以对其承担责任，便可接受生成内容。对工单的要求相对宽松，因为一份有用的错误报告可能来自并不了解底层编译器故障的人。草稿 MR 也可以包含未完成或生成的内容，前提是明确标为草稿，且尚未请求维护者审查。

P5：声明直接使用 LLM 生成内容。 如果 LLM 生成了提交审查的代码、文档、测试或其他材料中的任何部分，就必须披露这种使用情况。贡献者无需公开提示词或说明每次交互。出于探索、调试或设计构想而私下使用 LLM 无需披露，不过政策鼓励披露。对于提交的材料，声明应出现在 issue 或 MR 描述以及提交信息中，通常会带有一行 Assisted-By:。

P5：最好亲自撰写最终版本。 仍然允许使用生成的代码。该文件认为，重写最终版本往往是确保贡献者已仔细思考每一行代码、让补丁保持精简并删去不必要文字的最简单方法。GHC Notes 会受到特别关注，因为它们保留了日后多年仍可能很重要的架构思路。只要生成内容经过充分审阅和修改以满足 P3，仍然可以提交。

LLM 辅助审查遵循相同的规则。该文件对“LLM”的使用范围也很宽泛，足以涵盖未来发挥相同作用的系统，包括智能体。

与草案相比的变化

最终政策保留了 Simon 草案的核心立场：允许辅助式贡献，必须披露直接生成内容，责任仍由人类贡献者承担。

主要结构性变化是，社区成为一项独立的政策要点。7 月草案已经讨论了人类交流和贡献者社区的健康状况；当前文件将这一关切提升为 P1，并重新编号其下的操作规则。

由你自己编写最终版本的建议也保留了下来。讨论中，一些参与者认为这一措辞应当缓和。最终文本保留了原有强硬措辞，但清楚界定了边界：P5 是一项偏好。贡献是依据政策要点进行评判，而不是看每一个字符是否都由人类输入。

因此，这项政策避免试图解决围绕 LLM 的更广泛争论。它明确规定了贡献达到何种状态才算准备好，可以交由审阅者审阅。

审阅是稀缺资源

维护者的时间是主要制约因素。

GHC 目前待处理的工作量已远超可供审阅的人力。即使补丁生成成本更低，如果审阅成本变得更高，也不会有太大帮助。一个在二十分钟内生成的补丁，仍可能花费维护者两小时才能理解。

LLVM 将其中一种形式称为抽取式贡献，这一概念借自 Nadia Eghbal 的《公开工作》：贡献者因提交某些内容而获得收益，但项目在审阅和整合该内容上投入的精力，超过了该贡献本身的价值。

这个问题早于 LLM 就已存在。任何人都可以提交一个自己几乎没理解的 2,000 行补丁。如今生成这样的补丁要容易得多。

商业开发也呈现出类似模式。Faros 发现，AI 采用程度越高的团队，产出了更多且规模更大的拉取请求，同时审查时间也有所增加。这些数据属于观察性数据，而企业工程组织不能直接与 GHC 相比，但瓶颈是相同的：代码产出只是开发流程的一个环节。

GHC 的审查也高度依赖项目历史。一个补丁单独看可能是正确的，却与四年前的某项提案相抵触、重新引入旧有的性能回归，或者让计划中的编译器变更更难实现。人类贡献者在不充分了解相关历史时，也完全可能犯同样的错误。LLM 主要减少了某人在产出看似合理的内容之前所需的上下文量。

维护同样依赖于上下文。合并六个月后，关键问题在于是否还有任何人理解某一行代码为何存在。

那么，如何培养新的维护者？

开源贡献也能培养未来的维护者。

小问题之所以有用，部分是因为贡献者必须把它们梳理清楚。审查者会解释显而易见的解决方案为何失败，贡献者则会进一步了解系统的另一部分，经过足够多次迭代后，最终可能会审查其他人的工作。

Loris Cro 在解释 Zig 的政策时，将这称为 贡献者扑克。维护者的时间是一项投资，而 Zig 更愿意把它花在可能继续留在项目中的人身上，而不是用于通过 LLM 廉价生成的一次性补丁。

LLVM 采取了相同立场中范围更窄的版本。其政策不允许使用 AI 工具解决 good first issue 任务，因为这些任务旨在让人们了解该项目。

当生成的补丁挤占其他贡献者的位置，或占用审查者相当大一部分注意力时，这就会成为真正的问题。目前，我们在 GHC 中看不到多少相关证据。该项目面临审查者短缺，但并没有出现大量低质量的 LLM 提交，与一大群排队等待处理同一批工单的人类贡献者竞争。

如果这种情况开始发生，政策可以收紧。如今，全面禁令针对的是 GHC 尚未大规模出现的问题。

禁令难以执行

OpenJDK 采取了更严格的路线。其临时 AI 政策将全部或部分由 LLM 生成的贡献内容排除在外，但仍允许私下将其用于代码理解、研究、调试和审查。

OpenJDK 也承认了执行难题：通常无法可靠地区分生成内容与人工撰写的内容。

这项规则仍可能发挥作用。项目可能希望确立明确的规范，也可能存在法律和来源方面的顾虑，足以构成采用更严格边界的理由。实际操作上的激励就没那么明确了：披露使用模型的贡献者，其贡献可能会立即被拒绝，而另一个私下使用相同工具却未作说明的贡献者，则可能无法与之区分。

GHC 采取了不同的做法。披露情况能为审查者提供上下文，但不会自动取消贡献资格。

其他项目采取了不同的做法。GCC 拒绝包含或源自生成材料且具有法律意义的贡献，同时允许将 AI 用于调查和审查。LLVM 允许辅助生成的贡献，前提是人类检查结果并承担责任。GraalVM 要求提交者充分理解变更，以便回答审查者的问题并在此后维护它。

Linux 内核有明确的 编程助手指南。允许 AI 辅助贡献。人类贡献者审查代码、对其负责并确认 DCO；辅助情况通过 Assisted-by: 标签记录。

函数式语言项目也存在分歧。OCaml 在特定条件下允许 AI 辅助贡献，并要求在贡献的重要部分由生成时予以披露。Clojure 拒绝 LLM 生成的代码。Agda 曾讨论全面禁止生成式贡献，但该提案未获采纳便告关闭。

GHC 没有可直接照搬的既定社区标准。

一些更严格的立场是由法律顾虑驱动的。GCC 将界限划在“具有法律意义”的贡献上，因为 FSF 的许可主张依赖于清晰的来源脉络。OpenJDK 也指出，贡献者协议中存在关于所贡献材料所有权的要求。GHC 的讨论在 8 月触及了同一问题，当时一名贡献者请求 Haskell Foundation 资助法律咨询，以确定模型提供商的内容权利豁免是否站得住脚。董事会拒绝了这一请求，理由是这个问题并非 Haskell 特有，而且尚未在法院得到充分检验。

采用版权转让或贡献者协议的项目，在这里有更强的理由保持谨慎。GHC 采用不同的许可模式，并选择了不同的平衡点。

政策也会过时

与当前模型质量密切相关的规则可能很快就会过时。

QEMU 是一个有用的例子。其已公布的政策仍然拒绝 AI 生成的贡献，但 Paolo Bonzini 一直在制定替代方案。5 月，他指出，在 LLM 输出鲜少能在不进行大量重写的情况下派上用场时，禁止该类贡献更容易被合理化。到 9 月，该提案已扩展为一项更广泛的政策，其中包括针对在仓库内运行的 AI 代理的说明。

替代方案仍在讨论中，但讨论的范围已经改变。问题不再只是是否应将生成产物排除在外；它还涉及当代理在代码树内被使用时，代理应如何行事。

curl 的转变甚至更快。2026 年 1 月底，该项目关闭了漏洞赏金计划，因为维护者被质量低劣的安全报告压垮，其中许多与使用 AI 有关。历史上，超过 15% 的报告最终会成为已确认的漏洞；这一比例已降至 5% 以下。

curl 于 3 月重返 HackerOne，不是因为赏金计划恢复，而是因为 HackerOne 比 GitHub 更适合处理安全报告。4 月 22 日，Daniel Stenberg 在 “更高数量，更高质量”一文中写道，几乎每一份收到的安全报告似乎都以某种方式涉及 AI，但低质量的粗制滥造已不再是主要问题。已确认漏洞的比例已回升至约 15–16%。

大约两个月内，AI 辅助生成的报告从参与决定关闭悬赏，发展到达到更接近该项目历史常态的质量水平。我们无法区分是模型更好，还是对这些模型的使用更好，但这一区别对政策影响不大。输入质量迅速发生了变化。

一项主要基于“当前工具会生成糟糕输出”这一说法的规则将需要频繁修订。

广泛的限制也有机会成本。Bun 维护着自己的 Zig 编译器分支，并称在加入并行语义分析、将 LLVM 代码生成拆分到多个单元后，调试编译时间大幅缩短。团队表示，他们不打算将这项工作提交到上游，因为 Zig 禁止由 LLM 编写的贡献。

需要注意的是。后来，一位 Zig 核心开发者指出 Bun 的实现存在技术问题，包括并行语义分析中的非确定性行为。这并不是一份打磨完善的补丁，因此即便不是由 AI 编写的，Zig 也未必会接受。

尽管如此，Zig 的政策仍使该实现以当前形式被排除在正常的上游审查流程之外。其中一些想法或许能通过审查；也或许一个都不能。Zig 接受这一代价。GHC 做出了不同的选择。

速度在这里参考价值不大

关于编程助手的讨论常常将生产力简化为一个百分比：快 20%、任务数量翻倍，或额外完成若干个拉取请求。

对于编译器工作而言，这些指标很难解读。你无法在完全相同的条件下两次解决同一个问题，因为第一次尝试会改变你对该问题的认识。即使实现所需时间缩短一半，这也几乎无法说明未来三年的审查成本或维护情况。

对于 GHC 的待办清单，问“这项任务原本究竟会不会被完成”往往更有用。

拿一份旧的错误报告来说。有人得在当前的 GHC 上复现问题，发现问题已不再出现，找到修复它的变更，梳理历史脉络，然后关闭工单。或者拿一个 500 行的复现程序，将其缩减到另一位编译器工程师能够据此推理的程度。

GHC 有大量这类工作。它们很重要，却无法可靠地吸引贡献者。如果某个助手能让一个人愿意花一个下午处理此事，那么即使无法为结果附上一个明确的生产力百分比，这也仍然很有用。

有些问题比清理待办事项难得多。GHC 最近就有一个例子：模型辅助介入了一个此前已有多位经验丰富的编译器工程师研究过的问题。

强制转换消除

类型级计算繁重的程序会使 GHC 的 Core 表示中的强制转换变得极其庞大，编译器性能也会相应变差。Ben Gamari、Adam Gundry、Sam Derbyshire 和 Richard Eisenberg 已经探索了多种方案。有些方案对特定情况有效，但会在其他地方引入回归问题。

在 July，Sylvain Henry 使用 Claude Fable 制作了一个概念验证。Well-Typed 报告称，该方案融合了此前多次尝试中的若干思路。其中一项新思路是在可变变量中跟踪强制转换变量之间的依赖关系，从而不必对正在消除的强制转换本身进行强制求值。

随后，Sam Derbyshire 从头重写了这一实现并继续调查，在 GHC 的类型族重写器中发现了进一步的优化。

模型并非独立解决了这个研究问题。问题定义、此前的尝试，以及评估结果所需的判断，全部来自熟悉该编译器的工程师。这个概念验证为他们提供了另一条路径，以处理此前各种方法均陷入停滞的问题。

还有更多常规示例。Simon Jakobi 一直在发送 GHC 补丁，尾部带有 Assisted-by: Claude Fable 5 和 Assisted-by: Claude Fable 5.1 等内容。这些只是普通的编译器和测试套件改动，与其他补丁一样接受审查。

AI 辅助也开始出现在补丁之外。最近有人询问一项进展停滞的 GHC 计划的状况时，Simon Peyton Jones 说，它因缺少开发周期而一直停滞：他正深陷于大量 bug 报告之中，其中许多由 AI 生成，但几乎全部准确无误。在这里，模型更接近测试或分析工具，而不是代码生成器。这些报告仍需由那一小群维护者阅读并据此采取行动。

我们自身的经验仍然有限。Serokell 关于可见 forall、RequiredTypeArguments、指定命名空间的导入，以及迈向依赖类型的更广泛路径的工作，大多早于我们如今使用的编码助手工作流。查看一个过去的高难度补丁，并询问当前模型是否可能生成它，对我们帮助不大。

因此，我们不会把自己的 GHC 工作当作 AI 改变编译器开发的证据。我们目前还没有足够的经验。

我们的看法

我们认为当前政策是合理的。

GHC 有超过 6,500 个未解决工单，维护者的时间有限，还有大量有用的工作未能吸引足够的志愿者。编码助手无法解决这些积压工作。禁令同样无法解决根本性的短缺问题。

贡献的门槛应保持不变。贡献者需要充分理解补丁，能够说明其设计，并说服审查者它适合纳入 GHC。使用模型并不会把这份责任转嫁给审查者。

该政策给维护者留下了充分空间，以拒绝质量不佳的辅助产出。一个由无法解释它的人提交的大型补丁，就是糟糕的贡献。一个外观精致、但作者并不理解其所描述的不变量的 Note，同样如此。用模型复现旧有 bug、缩减测试用例、构建基准测试或探索编译器问题则另当别论：单凭这一工具，并不会使最终成果的实用性降低。

标准仍应保持常规要求：贡献者理解所做的工作，补丁可供审查，并且改动在改善 GHC 的同时，新增的维护债务不高于所消除的维护债务。