禁止LLM代码
摘要
git-annex宣布一项政策,禁止在其项目中包含LLM生成的代码,原因是版权不确定性,并提供了一个构建标志以避免依赖包含此类代码的依赖项。
<p><a href="https://lobste.rs/s/4h3zn9/no_llm_code">评论</a></p>
查看缓存全文
缓存时间: 2026/07/03 02:18
# 无 LLM 代码
来源:https://git-annex.branchable.com/no_llm_code/
自由软件中的 LLM(https://en.wikipedia.org/wiki/Large_language_model)生成代码是一个潜在的雷区。这些代码的版权归属尚无定论,而当前对该问题的任何答案,都有可能在未来某个时刻发生变化。
对于 git-annex 来说,这尤其是个问题,因为**面向未来的设计**(https://git-annex.branchable.com/future_proofing/)是其设计中的一个重要方面。
因此,git-annex 不包含由 LLM 生成的代码,并且保证永远不会包含此类代码。
然而,git-annex 所依赖的库及其他组件,一般并没有这样的保证。如果它们也有类似保障,那将非常令人感激。
git-annex 目前支持使用早于任何 LLM 生成代码引入前的依赖版本来构建。要这样做,请启用 `NoLLMDependencies` 构建标志。使用 stack 构建时,请使用 `stack-NoLLMDependencies.yaml`。(目前默认构建方式并不启用该标志,但欢迎进行此类构建。)
不幸的是,无法保证在 git-annex 的新版本中,这种方式还能继续工作。这是目标,但可能变得不可行。关于某些依赖可能出现的未来问题,详见下文。
请注意,如果安全漏洞只能由某个依赖的新版本修复,那么 `NoLLMDependencies` 构建标志仍会使用旧版的、不安全的版本进行构建。
需要持续进行额外工作,来审查 git-annex 的依赖,以检测是否加入了 LLM 生成的代码。
欢迎协助发现此类情况。请编辑此页面和/或在 git-annex 中提交错误报告,如果无法在不使用 LLM 生成代码的情况下构建 git-annex 的话。
## 已知包含 LLM 生成代码的依赖
1. ghc(https://git-annex.branchable.com/no_llm_code/#index1h3)
2. ram 及其反向依赖(https://git-annex.branchable.com/no_llm_code/#index2h3)
3. persistent(https://git-annex.branchable.com/no_llm_code/#index3h3)
4. yesod(https://git-annex.branchable.com/no_llm_code/#index4h3)
5. Cabal(https://git-annex.branchable.com/no_llm_code/#index5h3)
6. git(https://git-annex.branchable.com/no_llm_code/#index6h3)
### ghc
这个提交(https://github.com/ghc/ghc/commit/a5ec467ee3d4e77c026437a545981269acde3434)很可能就是第一个,并将在即将发布的 ghc 9.15 中发布。
git-annex 仍然可以使用早至 9.6.6 的旧版本 ghc 进行构建。
这很可能将阻止 git-annex 未来利用 Haskell 语言的大部分新改进。这非常令人遗憾。这是 git-annex 无法保证永不依赖 LLM 生成代码的主要原因,因为切断所有未来 Haskell 语言改进的途径,可能比替代方案更糟糕。
### ram 及其反向依赖
ram(https://hackage.haskell.org/package/ram)从 0.21.0 版本开始。
特别值得注意的是大量 LLM 生成的代码变更(https://github.com/jappeace/ram/commit/3a0c034648f1cb7e60e96a681fd74066ff5944fe),其中 0.21.0 中明显有问题(怎么个问题?)的更改在 0.21.1 中被回退。
git-annex 并未使用 ram,而是继续使用已被放弃的 memory(https://hackage.haskell.org/package/memory),而 ram 正是从 memory 分叉而来。
但 ram 是其他依赖的依赖,尤其以下这些依赖了 0.21.0 或更新的版本:
- crypton 从 1.1.0 版本开始
- tls 从 2.3.1 版本开始
ram 的反向依赖(https://packdeps.haskellers.com/reverse/ram)
`NoLLMDependencies` 构建标志依赖于旧版本的 ram,以防止此类依赖使用较新版本。
### persistent
persistent(https://hackage.haskell.org/package/persistent)从 2.15.0.0 版本开始。
第一个 LLM 生成的代码(https://github.com/yesodweb/persistent/commit/ac0a8698f38ae3b07acdacf0ce236d7fc73bb077)
git-annex 支持使用旧版本构建。
### yesod
yesod(https://hackage.haskell.org/package/yesod-core)从 1.7.0.0 版本开始。
第一个 LLM 生成的代码(https://github.com/yesodweb/yesod/commit/1b033c741ce81d01070de993b285a17e71178156)
LLM 生成的提交,包含 1489 行的提交信息(https://github.com/yesodweb/yesod/commit/1ee25122d82f8f94136bf1496a825c6c00b74fcf)以及超过 10,000 行的改动。
(请参阅 ditch yesod(https://git-annex.branchable.com/todo/ditch_yesod/))
### Cabal
第一个 LLM 生成的代码(https://github.com/haskell/cabal/commit/da8b314563feb15a3df7bc1baeef4b7aa08f7578)
构建 git-annex 需要 Cabal,但 Cabal 并不链接到 git-annex 中。风险在于,新版本的 Cabal 可能需要对 git-annex.cabal 进行修改,从而导致旧版本无法构建。
### git
从 2.53 版本开始。
第一个 LLM 生成的代码(https://github.com/git/git/commit/d7971544fe17378f44f49983010dbfc1834f7bef)
git-annex 支持回退到 git 2.22。
相似文章
依赖中无LLM代码
git-annex 维护者详细介绍了移除包含LLM生成代码的依赖项的努力,表达了对代码质量和伦理影响的担忧。
NLNet Labs LLM 政策
NLNet Labs 宣布了一项限制在代码和文档贡献中使用 LLM 的政策,要求披露 LLM 的使用情况,并禁止 AI 生成的代码。
LLM智能体能够查看代码仓库
本文首次系统性地实证研究了使用可视化仓库表示来增强基于LLM的编码智能体,结果表明,将可视化图作为补充模态集成,可以在保持或提高问题解决准确率的同时,将令牌消耗降低高达26%。
LLM编码时代的软件工程最佳实践
一篇讨论软件工程最佳实践如何随着LLM编码工具的整合而发展的文章,为开发者提供指导。
- -危险地跳过阅读代码 – olano.dev
文章认为,随着组织采用大语言模型进行代码生成,工程实践必须从审查生成的代码转向关注规格说明和测试,同时需要组织层面支持新流程。