你可能很难想象一个没有 GitHub 的世界。
今天我们打开浏览器，就能看到几亿个项目的源代码。你想用哪个库，一行命令就装上。想看看某个功能是怎么实现的，直接点进去读代码。发现了 bug，可以提交一个 issue，甚至直接发一个修复的 PR。你在开源世界里的行为，某种意义上和你用超市的自助结账一样自然——你需要什么，自己去拿，拿完了自己付账（贡献代码）。
但在 1990 年代之前，软件不是这样的。
那时候，软件是"二进制交付"的。你买到一个软件——通常是一张软盘或光盘——里面装的是编译好的 .exe 文件。你能用，但不能看它里面是怎么写的。如果要修改它的行为，你也只能按照开发者给你的那几个选项去操作。软件是黑箱，你付费买的是"使用权"，不是"知情权"。
而且，如果你是一个开发者，你想在别人的代码基础上做开发，除了自己从头开始写，几乎没有什么选择。你想开发一个文本编辑器？从零写起。你想做一个网页服务器？从零写起。你唯一能"复用"的是一本本编程教材里的示例代码——但那些代码只是为了教学写的，生产级的代码库不存在于公众视野中。每个公司都有自己的内部代码库，彼此之间互不可见。这意味着同一段"读取一个文件"的逻辑，全世界的开发者可能各自写了上万次，而且每次都略有不同——但从来没有人在别人的版本上改进过。
这种"各自为战"的状态带来两个后果。第一是极低的效率——大量时间花在重复造轮子上。第二是极差的质量——因为你的代码只有你（或你的团队）看过，没有同行评审，bug 的发现和修复完全依赖你自己的经验。一个开发者写的 bug，可能要等几个月才被发现，然后由下一个重新造轮子的人再次踩坑。
1983 年，MIT 人工智能实验室的研究员理查德·斯托曼发起了 GNU 项目。他的动机很个人化：他有一台打印机的驱动程序出了问题，想要修改它——但驱动程序只有二进制文件，没有源代码。他敲不开那个黑箱。
但这个故事比表面看起来要有意思得多。斯托曼不是"因为打印机不能用了所以愤怒"——他愤怒的是，他明明有能力修好它，但他被故意阻止了。供应商把代码藏起来了，不是因为技术上必须这样做，而是出于商业保护。对斯托曼来说，这是一种道德上的冒犯——就像你买了一辆车，引擎出了问题，但制造商告诉你"引擎盖是焊死的，你必须来我们的授权维修点"。
这段经历让他意识到了问题的本质：当软件只有二进制而没有源代码时，用户就被剥夺了对自己工具的控制权。 他后来创立了自由软件基金会，提出了"自由软件"的四项基本自由：
注意这四条自由的措辞。它不是"你可以免费获得软件"——Stallman 强调的分明是"free as in freedom, not free as in beer"（自由，不是免费）。自由软件可以收费——你卖一份 GNU Emacs 的拷贝完全可以——但你卖出去之后，用户仍然拥有上述四项自由。这份区别非常关键，因为后来的"开源"运动就是在这里和"自由软件"分岔的。
这四句话听起来有点理想主义，但它们是后来整个开源运动的哲学基础。而且它们不只是哲学——Stallman 同时做了一个非常实际的选择。他知道光靠"喊口号"没法让开发者把代码共享出来，所以他开发了一套法律工具——GNU 通用公共许可证（GPL）。GPL 的巧妙之处在于，它利用了版权法来达成与"无版权"相反的目的：如果你在 GPL 许可的代码基础上做了修改和分发，你的修改也必须使用 GPL 许可。这就是所谓的"copyleft"（左版）——用版权法的外壳来强制代码的开放。
到了 1990 年代末，"自由软件"这个术语被"开源"部分取代了。
表面上的区别是"开源"更强调商业友好——它去掉了 Stallman 那些带有道德色彩的措辞，换成了更务实的说法："让代码可见，制造更好的软件"。但这个命名的转变背后是真实的分裂：自由软件阵营认为这是原则问题——代码应该自由，这是对的事情。开源阵营认为这是效率问题——代码开放能做出更好的软件，这是聪明的事情。
虽然意识形态的底色不同，但两者的效果是叠加的。当许多人可以一起看代码、改代码时，软件的质量会更高，迭代会更快，创新会更多。 这个洞见被几个项目反复验证了：
但开源的成功不只是"更好的软件"这么简单。更深层的机制是它改变了"经济学"——开源把软件的边际分发成本降到了零，同时把协作的边际成本降到了历史低位。当任何人可以在任何地方、任何时候获取和修改你的代码时，你的软件就具备了"无需许可的创新"的能力。用户不需要等你来加功能，他们自己就能加。
这种模式还有一个意外的副产品：开源成了最好的人才市场。 一个活跃的开源贡献者，在求职时他的 GitHub 仓库比他简历上的任何一行都更有说服力。面试官可以去看他写的实际代码、他的代码审查习惯、他如何与社区协作。这比传统的"面试考算法题"要真实得多。
你可能会想："开源和 Vibe Coding 有什么关系？"
关系很大——比你第一眼看到的要大得多。
Vibe Coding 的核心体验是：你告诉 AI 你想要什么，AI 帮你生成代码。 但这段代码的质量，很大程度上取决于 AI 在训练时"读过"多少高质量的开源代码。
换句话说，开源运动在过去三十年中积累的庞大的、可公开访问的代码库——从 Linux 内核到 React 框架到各种工具库——是今天的 AI 模型能够写代码的核心原因之一。
我们来仔细拆解这个链条：
第一步：开源运动在过去三十年里积累了数百亿行的公开代码。这些代码是"有标准答案的"——好的代码和坏的代码之间有一条清晰的界限。
第二步：AI 模型在训练时"读"了这些代码。它读的不只是语法，还包括设计模式、命名惯例、注释风格、模块组织方式。它从成千上万个项目中学会了"一段好的认证中间件大概长什么样""一个优雅的 REST API 应该怎么设计"。
第三步：当你在 Vibe Coding 中说"帮我在用户登录时加一个 JWT 认证"，AI 调用了它在训练时"记住"的那些开源项目中的最佳实践，替你生成了代码。
这个链条的关键在于：如果没有第一步（开源的积累），第二步和第三步根本不可能发生。 AI 学写代码的方式和人学写代码的方式本质上是一样的——都需要大量高质量的示例。人的示例来自教材和同事的代码审查，AI 的示例来自 GitHub 上百万个开源仓库。
如果世界上所有的代码都是闭源的、藏在公司的内部仓库里，AI 模型就根本没有足够的数据来学习"代码应该怎么写"。开源运动无意中为后来的 AI 革命提供了训练教材——而且这个贡献可能是开源运动在历史上最重要的贡献之一，甚至超过了开源软件本身对行业的改变。
还有一个更微妙的角度：开源和 Vibe Coding 共享同一个价值观——"信任但验证"。开源社区的核心信条是"代码应该可以被所有人审查，但不是什么代码都值得信任"。Vibe Coding 的核心信条是"AI 生成的代码应该被审查，但不需要被怀疑到不敢用"。两者的背后的逻辑是一致的：透明度弥补不确定性——你看到代码，你就能判断它靠不靠谱。
开源运动的另一个遗产是关于协作的。你不需要认识 Linus Torvalds 才能给 Linux 提交代码。你不需要加入某个组织才能参与一个开源项目。协作可以跨越组织边界、地理边界、甚至竞争关系。
我从真实世界的例子感受一下这种"自由协作"的力量。你在谷歌做 Chrome 浏览器，你在微软做 VS Code，你们在公司的层面上是竞争对手。但你们同时在给同一个开源项目——比如 TypeScript——提交代码。而且你们在代码审查中互相提意见、互相修 bug。这是因为你们共享一个共识：TypeScript 越好，整个生态越好，你们的各自产品也能从中受益。这种"在竞争中协作"的模式，在开源出现之前是不存在的——公司之间要么彻底不共享代码，要么通过复杂的联盟协议来合作。
Vibe Coding 把这种协作模式又推进了一步：你正在和一个 AI 协作，而它的"知识"来自数百万开发者的集体智慧。你提需求，它调取它在训练时"记住"的最佳实践来替你实现。在这个意义上，每一次 Vibe Coding 的对话，都是在和开源社区积累的集体智慧对话。
不过这里有一个重要的区别需要注意：开源协作中，你看到的是直接的代码贡献——我写了一行代码，你看到了，你改了它，然后我看到了你的修改。这种"修改链"是透明的、可追溯的。但在 Vibe Coding 中，你看到的只是 AI 输出给你的结果，你看不到 AI 从哪个开源项目学到了这段模式。AI 在训练时"记住"了十万个开源项目，但它在生成代码时不会告诉你"这段代码我借鉴了 Express.js 的中间件模式"。
这意味着 Vibe Coding 的开发者在某种意义上成了"开源智慧的消费者"——你消费的是整个开源社区总结出来的最佳实践，但你和这个社区之间隔了一层 AI 的过滤。这种消费者的身份不如直接参与开源那么"有参与感"，但它极大地降低了消费门槛。
你不需要是一个资深的 C 语言开发者才能利用 Linux 内核的智慧。你只需要对 AI 说"帮我做一个高性能的文件缓存系统"，AI 就会把它在训练时从 Linux 内核、Redis 等项目中记住的模式组合起来生成给你。开源社区积累了智慧，AI 翻译了智慧，你应用了智慧。 这三者合在一起，形成了新的知识传递链条。
打开 AI 工具，问它：
"请举例说明三个知名的开源项目（比如 Linux、React、Python），并告诉我如果没有它们，今天用 AI 写代码这件事可能会有什么不同。"
追问它——"那第一个开源项目的出现呢？如果没有开源的传统，AI 的训练数据从哪里来？" 看 AI 如何回答这个"先有鸡还是先有蛋"的问题。这个追问的过程比答案本身更有价值——它在训练你"追问"的习惯，这是 Vibe Coding 中最重要的技能之一。