GHC通过LLM辅助贡献政策 要求人类作者解释每行代码

2026年10月，GHC项目通过具体政策文件，明确允许LLM辅助代码贡献，同时规定人类作者必须能够解释每一行代码和文档。政策文件由Simon Peyton Jones起草，经ghc-devs邮件列表讨论后定稿，优先级第一条为“优先考虑人员与社区”。

政策四点核心要求

第一点要求贡献者与审查者的直接交流保持人类主导，LLM生成文本不得替代个人判断。第二点要求合并请求易于审查，贡献者需投入远超审查者理解所需的工作量，包括清晰目标、设计说明、示例与测试。第三点明确人类作者身份与全部责任，任何可识别人类必须能解释代码每一行。第四点要求披露直接使用LLM生成的情况。第五点为强烈偏好，即贡献者最好亲自编写最终版本，但这不是强制要求。

政策文件明确表示项目对LLM整体利弊尚无共识，因此仅定义贡献与审查的预期。

审查成本成为实际约束

GHC目前超过6500个开放工单，部分为复杂编译器问题，部分为常规但有用的任务。政策制定者指出，廉价生成的补丁若增加审查负担则无益处。一份20分钟生成的补丁仍可能消耗维护者数小时来重建推理过程。Well-Typed.com 2025年4月文章记录，开发者在GHC和Cabal任务中使用Cursor与Claude-3.7-sonnet等工具时，需结合Haskell Language Server提供上下文才能获得有效反馈。

与其他项目的差异

Explainx.ai总结指出，OpenJDK、Zig、Clojure和QEMU目前对AI生成代码采取限制或禁止态度，而GHC选择允许但附加披露与责任要求。政策不适用于工单报告，初步合并请求可包含未完成或生成内容，只要明确标记即可。

深层机制分析

政策调整源于2026年夏季社区辩论。早期草案曾被概括为三点政策加一项推荐，后演变为四点政策加一项强烈偏好。原“共享声明”作者明确表示其非贡献政策，因此未被采纳。实际驱动因素是维护者时间稀缺，政策通过提高贡献者前期投入来降低后续审查成本，而非对LLM技术本身做出价值判断。

产业影响判断

该政策为其他Haskell相关开源项目提供可复制模板：允许工具使用同时锁定人类责任边界。执行层面，工具能否实际执行取决于贡献者是否能用人类语言向审查者说明变更逻辑。成本收益方面，相同审查效果下，贡献者前期投入增加可降低维护者总时间消耗。政策未承诺LLM必然提升生产率，而是通过披露与责任机制过滤低质量生成内容。

独立判断：GHC政策在当前阶段平衡了工具可用性与社区可持续性，其效果取决于后续执行中审查者实际时间投入是否下降。