越来越多的开发者开始使用 LLM 等 AI 工具，过去半年我看到不少相关讨论：有人非常反感使用 LLM 工具，有人保持中立，但确实有相当数量的 AI 生成 PR 给开源项目维护者带来了负担和困扰。

现在出现了一些新苗头，比如 GitHub 账号也开始“养号”。我推测大概有以下几个原因：

为了加密货币空投

2023–2024 年类似的情况比较多，有些加密货币项目会根据开发者的 GitHub 公开提交记录进行空投。如果一个账号给项目方关注的项目提过 PR，就更容易获得。例如 Rust 在区块链领域用得比较多，所以 Rust compiler 项目是比较容易获得空投的。我自己也因为一些开源记录拿到过空投，当时兑换了 1 万多人民币。我看到不少 Rust 社区维护者也得到了空投，不过他们对加密货币普遍不感兴趣；也有个别人因此换到了不少钱，觉得很惊讶。有同事给以太坊提过几个 PR，他的空投价值大约 15 万人民币，因此还出现了有人收购 GitHub 空投资格的情况。

但我认为这只是短期现象。现在再为了空投去养号是否还有机会？我不敢确定。因为“养号”的特征很明显，其实很好自动识别。而且到了 2025 年类似空投已经很少了，即使有，也会要求复杂的钱包交互，不是币圈的人通常不会折腾这些。

为了丰富简历

很多开发人员都知道，一个拿得出手的 GitHub 账号应该会对找工作有帮助。但我对此保持怀疑，因为养出来的 GitHub 账号一眼就能看出，从面试官的角度，我认为加上一个这样的 GitHub 账号到简历里是减分项。

总之，如果只是为了以上两种目的去“养号”，我都建议停手，因为这通常是费时费力但得不偿失的事情。

为了参与到开源项目

另外一部分人是真的想参与开源项目，他们可能认为使用 LLM 能降低难度。

现在的 AI 工具确实比以前更强大了。你可以把一个 GitHub issue 给它，稍微写点 prompt，AI 就能自动生成 PR，甚至自动发 PR。AI 的确比我原本想象的好用很多，我在日常开发中也会使用，但主要把它当成增强版搜索引擎或自动化工具。

例如我会让 AI 帮我做一些自动化流程：我有一个 prompt 模板，只需要给一个 issue 号，LLM 就能帮我解析问题，把相关的 bug 重现代码放到测试目录，创建对应的 Git branch，尝试在本地重现问题，然后从 backtrace 定位可疑代码。这确实省了我不少时间。但这建立在我自己按这个流程做过很多遍，能找出一套比较稳定的方法。

正如我之前说的，如果你想用好 AI，你必须具备项目的 domain knowledge，才能判断 AI 有没有“骗你”。

在 Rust compiler 项目里，目前 LLM 生成的 PR 基本只有 typo fix 之类的会偶尔被接受。只要涉及稍微复杂一些的代码修改，一眼就能看出不是人写的。

如果真的想参与开源项目，最好的方式还是从项目中简单的 issues 开始。如果不懂就多问，多看文档和代码。每个人都是从新手阶段慢慢走过来的，维护者一般对真心想参与的贡献者会更有耐心。

即使用 LLM 生成代码，我们依然要逐行 review，确保正确、可维护、简洁。如果你丢一堆机器生成的代码，让 maintainer 帮你审核，这会引起极大的反感。

比如这位开发者，在 maintainer 审核后对代码发出质疑的时候也承认是 AI 写的代码:

建议大家可以去看看上面那个 PR 里的讨论，我觉得有些评论挺有价值。OCaml 的维护者 gasche 表达的观点很明确：

The fact that you were able to generate large amount of code that passes test is interesting, but that’s only 20% of the work, the other 80% are to get the feature discussed, reviewed and integrated, and this work will be paid by you and others. But you only focus on the initial writing phase and you personal success, over-communicate on this, and do not appear to realize that this has very real costs on others.

在多人协作的开源项目中，稍微复杂一点的功能，写代码其实只占很小一部分，更多的是协作与讨论。一个 PR 是否能 merge，还要考虑长期维护成本。

另外，LLM 生成的代码其实是非常容易检测的，比如现在就有类似的工具可以以比较高的准确度判断代码是否是 AI 写的： AI Code Detector by Span

还有一些开发者 (尤其是非英语母语者)，他们可能对自己的英语不够自信，所以使用 LLM 来帮忙写 PR description 和 comments。有的开发者就是偷懒，认为 LLM 总结的即全面又好。但从维护者的角度来说，这是不友好的，因为 LLM 生成的内容过于冗长:

The comments left by you are significantly too verbose. While being detailed is good, please be respectful of reviewer time and avoid verbose text that mostly doesn’t convey any useful content.

在 Rust maintainer channel 里也讨论过这点，看起来很多人是反感读 LLM 生成的东西的，大家期待的鲜活的人类讨论，而不是机器生成的文字。

其实英语稍微差点的开发者，只要写的内容不是过于离谱，其他开发者也能理解，不用太在意 typo 之类的错误，因为人的大脑纠正的功能过于强大。后来我在 rustc-dev-guide 上加了这么一段：

If you’re not a native English speaker and feel unsure about writing, try using a translator to help. But avoid using LLM tools that generate long, complex words. In daily teamwork, simple and clear words are best for easy understanding. Even small typos or grammar mistakes can make you seem more human, and people connect better with humans.

AI 工具在开源项目中的过度尝试，只会让更多人反感，比如 zig 项目明确表明:

No LLMs for issues.
No LLMs for patches / pull requests.
No LLMs for comments on the bug tracker, including translation.

我不知道未来会怎样。也许 AI 工具最终会更智能。但至少现在，它还处于一个尴尬的中间地带：用得好能帮你节省时间，用不好反而不如不用。