原文首发于本人博客：现在有了 Vibe Coding 生产代码，开源协作还有意义吗？ | 夜天之书
如题，一个常见的问题。正好近期针对问题和相关的议题，我有几个浓缩的观点，写出来以作分享。
参与开源的门槛降低了
首当其冲的问题是，参与开源的经验还是不是能为简历加分的经历？
一直以来，向开源项目提交代码，被开源项目接收补丁，成为开源项目的 Committer 或维护者，都是能彰显开发者能力的标签。
例如，向 Linux Kernel 提交代码，即使在今天也要求贡献者能够完成起码的 C 大型项目构建，读得懂 Linux 方言环境中的 C 代码，能够在内核开发邮件列表上沟通，将代码补丁打包成 patches 文件以供 Review 并响应 Review 意见修改。虽然读代码的部分和遇到具体的困难可能今天的大模型能够提供帮助，但是这一整个流程走下来，能够真的让 Kernel 接受一个 non-trival 的补丁，总是可以证明开发者的学习能力和基础知识掌握程度的。
不过，Linux Kernel 的例子过于特殊。随着软件开发不断扩展到更广泛的开发者群体，邮件列表的沟通形式也逐渐被 GitHub 这样完善的代码协作平台所替代。今天，GitHub 原生集成了 Copilot 作为大模型能力的平台接口，你甚至可以直接在 GitHub 网页界面上直接通过 Copilot 驱动 AI 编码，完成改动后直接 Commit 或者提交 Pull Request 到上游仓库。
GitHub Copilot 支持页面直接驱动 Agent 编码并提交 Pull Request
这样一来，传统的代码开发和评审过程，被 AI 几乎全面接管。前面提到的完成一个代码贡献需要掌握的技能，变成直接向大模型要求“请实现某某功能”。在这个过程里，开发者的价值就变得难以衡量了：似乎换一个人也能做到，要求大模型实现某某功能，然后等待大模型完成工作后提交变更。
对于这样的现象，我先下一个结论：软件开发向来是为了解决问题（Problem Solving），重要的是解决问题的结果，而不是解决的方式。
今天，我们通常不会在意一个开发者是用上古编辑器逐行手敲代码，还是借助 IDE 生成样板代码，自动补全代码。类似的，如果我们把大模型支持的 Code Agent 也当做是某种更新颖的 IDE 来看，我们也不应该在意一个开发者写出的代码到底是自己亲自写的，还是 Vibe Coding 驱使 Code Agent 完成的。如果一个开发者能够利用大模型的能力持续高质量地解决问题，这说明这个人 AI 用的好，正是这个时代需要的人才。
PS. 当然，Code Agent 生成代码相较于手写的代码，有一个额外显著的问题，就是所引用的代码可能存在产权问题，这个需要额外关注。
PPS. 其实，将 Code Agent 集成到 IDE 当中，或者围绕 Code Agent 打造集成开发环境，不是想象中的情景，而是正在进行时的当下。VS Code 早就深度集成了 Copilot 的能力，能够完成所谓的 Agentic Coding 任务。Cursor、Zed (ACP) 还有近期的 Antigravity 都是这一思路影响下的产物。即使是在 AI 时代稍显落后的 JetBrains 系 IDE 产品，至少也能够提供基础的 LLM-Driven Code Completion 能力。
Code Agent 融入集成开发环境
在当前普遍的开源治理模式下，合并代码补丁和邀请成为团队成员，还是由现有团队成员做出的决定。因此，即使尝试提交开源贡献的门槛变得更低了，但是真的有很多开源贡献被上游社群真实的资深开发者所认可，甚至本人表现出来的开发能力和协作能力，使得开源项目的维护团队信任并邀请你作为新的团队成员，仍然是有效的个人标签。
其实，在大模型之前的时代，也并不乏想要“刷开源贡献”来充实简历的开发者。例如，前段时间引起讨论的，向 Kubernetes 提交修复文档格式的 PR 之后发小红书广而告之的事件，其热议的根本就是大家对“给 Kubernetes 做贡献”和“原来只是修了个格式”之间的认知落差。
对此，我的观点是一贯的：只要是有效的开源贡献，无论大小都值得感谢。毕竟这是别人花了自己的时间（or token?）完成的工作，并且以开源的形式向所有人分享。
另一方面，同行评审能够快速捕捉到“给 Kubernetes 做贡献”的过度宣传，实际只是修复了任何项目都可能出现的文档格式小问题，积极公开反馈，也在维护行业对给知名开源项目做 non-trivial 贡献的价值的共识。
在没有 GitHub 和 IDE 的时代，任何开源贡献都暗含着你至少对行业有基础的了解，知道如何基于邮件列表协作和打包补丁协同修改。随着开发者数量井喷，海量大大小小的开源项目涌现，同行评审给某某项目做过贡献时，自然也应该留意到底是什么类型的贡献。如今，大模型支持下的 Code Agent 又极大拓宽了开发者能够完成的工作范畴。甚至在开发者对项目一无所知的情形下，大模型单凭本身的能力，就能把工作完成的很好。于是，同行评审的时候，自然也会把相关工作可能有 Code Agent 参与纳入考量。
随着工具变得越来越好用，开发者能做的事情也越来越多。因此，过去需要付出艰难努力才能取得的成就，现在或许变得轻而易举。古早的开发者有了解决问题的思路以后，不得不手写汇编代码考虑寄存器分配、指令跳转等等问题；现在的开发者能够直接编写高级语言源代码，甚至利用现成框架编写接近声明式的源码，不用关心底下编译优化细节即可实现所需功能。永远存在待解决的问题，能够利用手上的工具高效解决问题的能力，才是开发者的核心竞争力。即使有大模型加持，发现并定位问题，驱使大模型准确解决问题，评估大模型生产出来的代码是否正确，仍然需要人来指挥，人来判断，人来最终负责。
启动开源项目变简单了
随着大模型在编码任务上的智能不断提升，另一个肉眼可见的变化，就是更多的开发者能够轻易地启动自己的开源项目了。
以前，要想启动一个新的开源项目，且不说要如何找到一个待解决或没解决好的问题，光是下决心要花时间把项目的架子搭起来，完成解决各种核心问题以往的配套工作，例如软件发布、文档撰写、网站或产品前端的页面设计，就足以劝退绝大部分开发者。
这些繁琐的任务不太构成项目的核心价值，但却切切实实地要占据项目作者的时间去完成。成功的开源项目，自然有五湖四海的贡献者添砖加瓦完成这些工作。但是一个新的项目，在如今开源项目泛滥的环境下，又如何能够吸引到足够的早期参与者呢？
大模型至少在两个层面上大幅改进了新开源项目启动的体验，使得项目作者只要有好的点子，就能付诸实践进行尝试。
其一是项目作者能够直接用 Vibe Coding 的模式，仅描述自己需要的效果，让大模型尝试生成代码完成需求，而开发者只负责评估结果。这样，开发者只要知道最终需要的是什么效果，就可以不用提前全面学习要实现对应功能需要的知识的情况下，指挥大模型开始创建原型。开发者只要关注结果对不对，并对于 suboptimal 的效果继续要求大模型改进，或者在过程中让大模型自己解释代码，带领开发者学习调优特定问题的知识，就可以以最小的力气完成项目的开发。
这就是一段时间以来，自媒体所吹嘘的“超级个体”：只要你有一个好点子，大模型就能够帮你落地。
这当然有些言过其实。大模型的能力更多地是基于训练知识库，拟合用户描述的问题，重复已知的通解。既然是通解，也就意味着这是一个已经解决的问题。例如，一键建站这样的能力，早在大模型时代以前，WordPress 这样的方案就可以做到。真正让网站产生价值的，是网站的内容，包括文字内容或者精心定制的其他效果。
但是，如果开发者知道待解决的问题是什么，并且有一个尝试解决的思路，大模型就能帮你解决绝大部分繁琐的任务，包括相对样板化的编码任务。
Claude Code 的作者公开表示，他几乎已经不再手动编码，而是驱动 Claude Code 自己为 Claude Code 的新功能和缺陷修复编写相关代码：
Claude Code 也算是某种形式的自举了
不过，我想这也有些言过其实。毕竟大部分修改完成之后，人还是要验证一下，有些工作人上手微调比让 AI 做还是要高效得多。当然，不排除人家是 Code Agent 厂商员工，为了极限测试 Code Agent 的能力，即使人上手改更方便的场景，也尝试让 AI 自己改，或者接受 AI 生成的差不多得了的代码。
还有一些更近的例子，例如 Simon He 开发的流式渲染 Markdown 的工具 markstream-vue 就是重度依赖 Code Agent 开发的。我没有做过确认，但我想他把 markstream port 到 Vue2 和 React 的工作也是大部分让 AI 自己工作完成的。这些工作如果手写，就是那种很清楚应该怎么做，但是做起来真的烦的范畴。如果没有 Code Agent 这样的效能工具，真得等到哪一天心情好的时候，沐浴更衣才能好好完成。
又例如，Xuanwo 在开发 xlaude、lance-duckdb 和 gpui-ghostty 等项目的时候，也重度依赖 Code Agent 自主完成编码任务。开发者只需要定义好待完成的目标，即使在之前不了解 TUI 或具体数据库实现的情况下，大模型也能基于自己庞大的知识库拟合出一个像模像样的实现。而后开发者做针对性的学习和调优即可，不用从头了解整个领域知识才能上手。可以肯定的是，如果没有大模型加持，至少 gpui-ghostty 这样的项目，对当前的 Xuanwo 而言，是很难启动的。这不是能力问题，纯粹是从想法到落地所需的基础学习时间造成的阻碍。
再来一个更典型的例子。前几天我机缘巧合之下跟 DataAcquisition 的作者有了一次交流。这个项目是一个很早期的基于 C# 实现的前后端一体化工业级 PLC 数据采集系统，其灵感来自于作者在实际工作中积累的经验。放在以前，工作项目完成以后，即使想把工作经验抽成一个可复用的模块系统，真要上手也是困难重重。而这位半路出家学编程的作者，有了 Cursor 帮助以后，把自己对业务建模的理解对着 Cursor 一通输出，微调生成出来的代码细节，就能让大模型基于现有的前端实践、后端存储和通信的通解，大致把他核心的问题建模思路落地成一个完整的应用。虽然很多地方都有待改进，但是只要核心解决的问题能被验证，众人拾柴火焰高的改进正是开源协同擅长的部分。
最后，简单说说大模型带给新项目启动的第二个重大改变。不同于 Vibe Coding 直接生产出具体代码，大模型起初的 Chat Bot 形态对于帮助开发者厘清问题，设计问题解决方案也有显著的帮助。
很多时候，启动一个新开源项目的难处，在于你似乎发现了一个待解决的问题，但是你很难验证这个问题是否是一个别人尝试解决过，但是最终被证伪的问题。还有，实际上手解决问题的时候，每一步都有可能产生出新的衍生问题。要想搞明白这些衍生问题是否早已被解决，也需要花费巨大的精力。其结果是，想要解决 Node.js 现存问题的 Deno 出自 Node.js 作者之手，即你必须非常了解整个问题，才能开始创建一个替代方案。
大模型的知识库非常广博，当你产生想法之后，可以尽情的跟大模型交流验证，进一步地可以进入到 Vibe Coding 阶段做原型做详细验证。大模型就是一个不会疲倦，随叫随到的专家检索库，能够帮助开发者高效地决策剪枝，判断一件事情是否可行。
我在最近设计和实现 Rust 版本的异步并发原语库 mea 的具体功能的时候，就经常跟大模型做推演。我让它从知识库里找出其他语言、其他现有库是如何设计对应原语的，然后集中对比，理解取舍点，最终完成 mea 里面对应原语的设计，随后让 Chat Bot 生成一个实现计划，交付给 Code Agent 实现和测试。这些工作，我自己有能力做的。但是同样，我很难找到这么多时间，翻阅现有的实现逐一理解，最后得出跟大模型总结类似的结论。大模型极大压缩了调研分析的时间，当然最终人还是要自己做判断，对可疑之处要自己做验证，但是整个调研效率从集中的半周到一周时间，压缩成数个小时的集中交互，这也是一个极大的提效。
开源协同塑造共识信任
那么，话又说回来，如果开源参与的门槛降低，导致参与开源能够取得地认可贬值，大模型又极大提升了启动新开源项目的效率，其中也包括 fork 现有项目改动而不是向上游提交补丁，在这样的现状和前景下，开源协同共建一个项目，还有什么独特的意义呢？
标题就是我的答案：开源协同塑造共识信任。
举一个近期的例子。在开发 ScopeDB 的过程中，我们用到了各种各样的数据估算算法，例如 TDigests 和 Compressed Probability Counting Sketches 等等。基于算法定义和一些现有实现，我们很容易就自己定制了一个简单可用的版本。甚至，我们还想过要不要启动一个 sketches 项目，把用过的 sketches 整理开源出来，让其他人也能用上。当然，深层次的原因是，这些代码有更多人使用和改进，更多人“踩坑”，ScopeDB 依赖这些代码提供生产级服务，才更加可靠。而不是将通用能力全部闭源自研，这将导致更大的维护负担，代码一旦腐化，带来的工程债务将水涨船高。
在大模型的帮助下，把我们现有的代码整理一下，推出一个这样的库，实现差不多得了的能力，并不困难。但是即使如此，由于研究 sketches 的人本来就很少，我们自己又不太可能花非常多的时间钻研，真另起炉灶，是否真的持续，要打一个很大的问号。
在开源生态当中，其实有一个很好的现有实现，那就是 Apache DataSketches 项目。它包含了所有我们需要的数据结构和算法，其作者几乎将其毕生精力都投入到 Sketches 的研究，甚至包括其中几个前沿 Sketches 的论文作者。唯一美中不足的是，它只有 Java / C++ 和 Go 实现。即使利用大模型，我能更简单的理解这些现有代码，甚至开始上手做一些 port 工作，但是相比随手启动一个开源项目听天由命，真打算发起一个能持续经营下去的开源项目，要考虑的往往不止是写出代码的问题。如果只有我一个人推进这项工作，我是真没时间。
所幸，大约两个月后，Xuanwo 恰好也在开发 iceberg-rust 的过程里产生了对 datasketches-rust 的需求。他在群聊当中提问，而我正好告诉他 DataSketches 的项目现状和人员组成情况。于是我鼓励他直接在 datasketches 项目里提出 Rust 版本的请求，没想到很快就得到了社群的积极反馈。
当然，feature request 最简单的部分就是提出需求。大家都期待一个 datasketches-rust 从天而降，但是到底谁花时间让他变成现实，仍然是一件不确定的事情。
项目作者是老 Java 开发者，对 Rust 基本毫不了解。他很乐见 datasketches-rust 出现，但是又感到自己无力独自维持其持续发展。于是，他在评论里提到：“请无论如何不要只是三分钟热度，留下一地鸡毛之后就消失不见”。
这个当然没问题。我有充分的 Rust 开发经验，也知道 ASF 里面的规则。此前一直比较犹豫，主要是不确定上游的倾向性，不想花时间去做一件不确定的事情而已。既然可以搞，那就很好搞。
从月初到现在，我和 @notfilippo 一起完成了 datasketches-rust 项目的搭建和主体实现，共同定下了项目的基调。国内的好兄弟 @PsiACE 和 @ZENOTME 分别贡献了若干个具体 Sketches 的 Rust 移植版本。不日，datasketches-rust 将会做第一次符合 ASF 要求的发布，届时欢迎有需要的开发者使用。
在这个例子里，可以看到 Apache 软件基金会和 Apache DataSketches 项目在领域内的号召力。我可以想象，如果是我自己搞了一个 sketches 项目，几位 datasketches 的贡献者几乎很难第一时间信服并参与，国内的好兄弟即使相信我，也未必愿意投入时间支持一个野生项目。Apache 的品牌影响力和 DataSketches 项目经年的领域口碑，让大家相信为其添砖加瓦的努力不会白费。今天花时间写的代码，未来一年、三年、五年，乃至十年，依然会有人维护，有人使用。
现实世界里的问题总是解决不完的。大模型降低了开源参与的门槛，简化了启动开源项目需要的投入，但是对问题应该如何解决的共识，仍然是从业者不言而喻的一致追求。大模型截至今天仍然只是一个效率工具，它跟一个集成开发环境，一个编程框架，在问题解决的角色定位上没有太大的区别。或许针对同一个问题，广大的开发者群体最终不会合并成完全相同的共识，但是通常也会聚拢到少数几个普遍的共识。大模型的出现，并没有击碎开源协同的价值。它只是让问题探索和尝试变得更加简单，加速开源协同当中可能性的分裂，也加速寻得有效共识之后合作的收敛。
小结
大模型的出现让重复基础编码任务的意义快速贬值，但是开源协同的形态并没有因此发生巨变。对于个人而言，此时应该做的是尽快掌握大模型制导的编程能力，将自己从繁琐的重复编码任务里解脱出来，集中注意力投入到其他高价值目标上去。
否则，这就像十年前别人开发 Java 都用 JetBrains 自动生成模板，自动补齐代码，流畅 DEBUG，光速跳转定义；而你还在手敲每一个符号名，全局搜索文本找代码，不停吐槽为什么别人写的类名方法名都要全拼：你开马自达，怪不得你塞车 >~<
花絮
不过，如前所述，大模型的能力更多地是基于训练知识库，拟合用户描述的问题，重复已知的通解。对于知识库相关信息不足的领域，大模型还是力有未逮。比如 Linux Kernel 的开发，国内顶级内核工程师 @silsrc 就吐槽说多次想用 AI 解放自己，但是实在是搞不定。
所以不得不说，人工智能的底层代码，还是那个有多少人工就有多少智能。
如果知识库知识不足，只能靠 fine tune / skills / prompt 来救一救了。例如，Xuanwo 在 OpenDAL 里搞大模型能力竞赛，鼓励贡献者直接利用大模型参与拆分 services/layers 工作的时候，也得自己先做一遍示范，然后给出一个参考提示词，其他贡献者才能拿着提示词转自己的 token 去解决问题。直接让大模型闭眼睛实现，那很容易就过拟合一些乱七八糟的通解偏到不知道哪里去了。
