开源贡献，靠 AI 一把梭也行吗？

在 AI 时代做开源贡献意味着什么

李
李承宰 · NHN AD
平台服务实验室 · 2026 年 10 月 · 约 6 分钟

前言

大家好，我是喜欢开源的开发者李承宰。我喜欢自己写的代码和做出的东西能对别人产生影响，说实话，说我是为了这份乐趣才做开发的也不夸张。

今天想写写我第一次体会到这份乐趣的经历、最近收到的一条反馈，以及这条反馈留给我的思考。

我爱开源的理由

我的第一次开源贡献是 exercism。那是我刚开始学开发时用来学习的网站，所以一直想有一天把得到的回馈回去。2024 年 11 月，我为 Java 赛道的 Parallel Letter Frequency 题目整理了解题思路，提交了 PR #2863。生疏的英语，再加上第一次见到的贡献规则，经过好几轮反馈之后才终于被合并。

之后我打开网站，发现我写的代码和说明原样挂在上面，贡献者的位置上印着我的名字。当时我还是学生，开心又激动，记得有一阵子反复点进去看了好多遍。

exercism 并行字母频率题目的解法列表。Fork/Join 和 Parallel Stream 两种解法都标注为 masiljangajji 编写
exercism Java 赛道并行字母频率题目的解法。两种解法都挂着我的名字。

借着这段经历，我还在社团 goorm-thon UNIV 的世宗大学×建国大学联合技术分享会上，以培养阅读开源代码的能力为题做过演讲。exercism 的记忆至今仍在，所以我现在也还在为开源做贡献。

LLM 贡献有意义吗？

为了更频繁地参与开源，我曾经给自己用的每个库和框架都配上 agent 和 skill，定期检查，一发现缺陷就提 PR。托这个的福，我确实做了很多贡献：光是在韩国电子政府标准框架就合并了 22 个，还给 Spring Data JPA、jjwt 和 LangChain4j 提过 PR。可是随着 PR 越积越多，不知从什么时候起，心里总有种说不清的别扭。

就在这时，我在提交给 Spring Boot 的 PR #51468 里收到了这样的反馈。

Did you use AI to produce the description? Regardless, it's unnecessarily verbose for a one-line change to main code and includes lots of details that are already available elsewhere.wilkinsona · Spring Boot 维护者

对方问我 PR 描述是不是用 AI 写的，并指出不管是不是，对于一行代码的改动来说都太啰嗦了，还写进了别处已经有的内容。

I use an LLM to look for bugs in projects I use, then check the bug is real and run the tests myself. … I still think it is good for open source, but I would like to know if you agree. Are LLM pull requests more tiring than helpful now? Or is it still worth it if it brings in more contributors?masiljangajji · 我

我回答说，我会用 LLM 在平时用的项目里找 bug 并修复，还补充说希望这样的贡献能让开源变得更好。然后我问对方，用 LLM 做出来的 PR 是否真的有帮助，作为维护者，又怎么看待贡献门槛降低、贡献者变多的现状。

回答是这样的。

As we have limited resources, we much prefer dealing with bugs that are causing real-world problems. The value of fixing these is much higher than fixing something that may technically be a bug but isn't have a negative impact on anyone.wilkinsona · Spring Boot 维护者

因为资源有限，他们更倾向于处理在现实中引发问题的 bug；技术上也许算 bug、却不会给任何人造成影响的问题，修了也没多大意义。

对方并没有怪罪 LLM 本身，说只要修的是现实中的问题，用什么都欢迎，打磨得好的话甚至看不出有 LLM 参与。不过对方强调，重要的不是贡献者的数量，而是贡献的质量，并补充了这样一段话。

The best way to contribute to an open source project is to use it in your day-to-day work in real-world situations. You can then propose bug fixes and enhancements that make your day-to-day work easier, benefiting both you and the rest of the community.wilkinsona · Spring Boot 维护者

最好的贡献方式，是在实际工作中每天使用这个项目，然后提出能让自己工作更轻松的修复和改进，这对所有人都有好处。

我也不认为用 LLM 找问题、改进代码有什么错。就算是 LLM 找到的 bug，判断它、决定采用哪种解决方案，仍然需要工程上的决策。可心里那种不痛快的感觉还是没有消失。

为了简历的开源

收到这条反馈后，我认真想了想。改进代码、摸清开源项目，到现在都还很有意思，PR 被合并也会开心。那为什么会这么别扭、这么憋闷呢？

想来想去得出的结论是：我一直在为了填满简历而贡献。我不是在解决自己真正遇到的问题，而是为了挂上名字，刻意去找缺陷来修。不知从什么时候起，我好像把开源贡献当成了一件非做不可的事。

要贡献的开源项目，我也只在 Java·Spring 生态里挑。我本来就是 Java·Spring 开发者，这个生态熟悉得多、用得也多，这确实没错，但我不能说自己没考虑过它在简历上更有分量。

以前只想给 Java·Spring 生态里的开源项目做贡献 Java·Spring 生态 电子政府标准框架 Spring Data JPA Spring Data MongoDB Spring Boot Spring AI jjwt LangChain4j 其他生态 0 没有 PR
以前我只想给 Java·Spring 生态里的开源项目做贡献

说到底，让我别扭的不是 LLM，而是目的。我意识到为什么贡献远比在哪里贡献重要，于是下定决心要去解决真正的问题。

为了自己的开源

下面介绍两个修复我亲身遇到的问题的 PR。第一个是 sqlglot。工作中我在做基于 Athena 的 text-to-SQL 功能，会在执行前用 sqlglot 校验 LLM 生成的查询，结果像 LIKE 'QA3\_%' ESCAPE '\' 这样在 Athena 上跑得好好的查询，却被 TokenError 拒绝了。查下来发现，Athena dialect 会把 Hive 和 Trino 的规则合在一起分词，然后才决定发给哪个引擎；而在 Hive 里 \ 是转义字符，'\' 就成了没闭合的字符串，还没轮到 Trino 就失败了。我提交了 PR #8629，让合并规则分词失败时改用各引擎自己的规则重试，当天就被合并了。

Athena 按语句类型分别使用 Hive 和 Trino SQL DDL 或查询 合并规则分词 Hive + Trino · 决定发往的引擎 Hive DDL · CREATE TABLE … Trino 查询 · SELECT … 在 Trino 中合法的 '\' 却被拦下 之前 合并规则分词 失败就直接报错 TokenError ✗ Hive 规则下 '\' 没闭合 之后 按引擎规则重试 仅在合并规则失败时 按 Trino 规则分词 ✓ 仅用于发往 Trino 的查询 SELECT '\' SELECT '\'
Athena 用 Hive 处理 DDL、用 Trino 处理查询，因此会合并两套规则分词；我把它改成合并规则失败时按各引擎的规则重试

第二个是 Strands Agents SDK。我在 Bedrock 上用 Claude 运营 LLM 服务时，在错误日志里发现了 ValidationException：模型把 stopReason 设成了 tool_use，却没有带上工具调用信息。SDK 看到 tool_use 就想执行工具并返回结果，可没有工具可执行，于是附上了一条空的 user 消息来代替结果，下一次请求就报错了。我提交了 PR #5145，让没有工具调用信息时直接结束这一轮，目前还在等待 review。

模型响应 assistant 消息 只有 text 块 没有 toolUse 块 之前 尝试执行工具 因为是 tool_use 没有可执行的工具 只有空的 user 下次请求报错 ✗ 之后 改为 end_turn 没有 toolUse 块时 结束这一轮 ✓ 直接以模型响应收尾 stopReason: "tool_use" ValidationException user assistant 给模型的输入 · 工具结果也在这里 模型之前的输出
当以 tool_use 停止却没有工具调用信息时，改为不进入工具执行，直接结束这一轮

这两个 PR 是我第一次走出 Java·Spring 生态、给基于 Python 的开源项目做的贡献。使用 LLM 的方式和以前一样，但想到是在解决自己亲身遇到的问题，那种别扭感减轻了不少。

我也想过以后怎样才能做出更有意义的贡献。第一是像现在这样，修复自己亲身遇到的问题；第二是不止于按 feature 去分析和贡献，而是在弄清模块和整体架构之后再贡献。我想，如果一直给同一个模块做贡献，至少在这个模块上能积累起专业性吧。Spring Data 的模块化似乎做得很好，我也想写一篇分析它的文章。

没有无意义的贡献

我认为任何形式的贡献都有意义。不管出于什么意图、用没用 LLM，代码最终都变好了。正如前面所说，找问题也许 AI 一把梭就行，但在保持与现有代码兼容的同时说服维护者、通过 review，仍然是工程师的事。只是正如维护者所说，修复在实际使用中遇到的问题，价值要大得多，意义也更能打动人。

最近除了开源贡献，我还在做一些对简历毫无帮助的东西。最具代表性的是在桌面上陪我一起动来动去的 Chiikawa 宠物，可爱到爆炸，做起来真的特别开心。

终端上方桌面的右下角站着几只 Chiikawa 宠物，头顶显示等级和状态，对话气泡里显示正在做的工作
在 Claude Code 工作时，用对话气泡显示当前任务的宠物们

随着“AI 一把梭”时代的到来，很多开发者都在为职业发展发愁。开发的定义变化得如此之快，有人难以找到方向，有人失去了兴趣，市场更是冷到结冰，想方设法展现自己成了迫切的事。我也一样，比起刚开始学的时候，乐趣确实少了。即便如此，还是希望大家试着开发一些没用的东西。大家好像都活得太紧绷、太没有余裕了。不如做一只超级可爱的 Chiikawa，喘口气怎么样？为 AI 开拓时代的所有开发者加油。

感谢阅读。