当 AI 替我们写程序时的开源愿景

当 AI 能写代码，修改与延伸开源的成本大幅下降。那些过去因为必须从零打造而做不到的事，如今变成别人数万、数十万小时的成果，我们可以轻松拿来改进、延伸使用！！问题于是从「我们写得出来吗」变成「我们知不知道有什么是可以直接拿来用的（而且免费）」。当然，如果缺少那种努力想清楚该建什么的领导力，怎么做都成不了事。

在与开源打交道的二十多年里（既靠它赚了不少，也省了不少），我从管理者口中听得最多的问题是：「拿来用了，谁来帮我们维护？」这个问题始终合理。接受开放软件，意味着要自行承担修改与后续维护的责任。一个没有人手、也无意具备采购与管理技术能力的组织，最终只能被迫花钱买闭源产品，让别人承担全部责任。付高价，图个稳妥（在能稳妥的范围内）。

而在 AI 能替我们写程序的今天，这道算式已发生显著改变。再往下走不久，就可以称之为「彻底且永久地改变了」。

真正改变的不是「谁写代码」

改变的是——进去修改既有之物的成本。

从前，要修改一个开源软件，需要一个能读懂别人代码的人，理解自己并未参与设计的结构，并且有足够的时间把它做完（通常还得是最强的那几个人）。那才是真正的瓶颈，而不是授权费。

今天这个瓶颈消失了。AI 阅读大量代码比人类更快，能解释它所读到的内容，并且能持续不断地动手修改而不知疲倦。「免费吸收上千万行程序，并把它变成我们自己的」这种能力，正在成为幸存者的常态。（如果不会这么做，还真能竞争、真能活下来吗？如果还那样含糊地相信着，我只能笑了——那表示他从来没问过 AI，这个世界到底用了多少开源。）

当我们能有系统地修改与延伸，就会变得更难被打败

这一点我想给予最重的分量。无论个人、工作、学习，还是组织发展，同一个原则都适用。

如果我们能对既有之物进行有系统、有智慧、且持续不倦的修改与延伸，我们就会处在一个更难被打败的位置，因为这三者结合起来，会产生竞争者难以复制的结果。

• 有系统 — 不是凭情绪修改，而是有工作方法、有测试、有改了什么以及为什么改的轨迹。
• 有智慧 — 选择在能创造差异的地方修改，而不是能改的全都去改。
• 持续 — 优势并非来自一次性的修改，而是来自不停歇的小改进的复利累积。

最后一点正是 AI 改变最大的地方。持续性过去是最昂贵的一件事，因为人会累、会离职、会换工作。今天，持续的成本低了很多。

也有人问我：如果 AI 真的这么厉害，我们还需要开源软件做什么？我的回答是：正是我们这些人类，做不了这么难、这么大量的工作……那么，谁来免费替我写这些软件规格呢？Data Mining、Logistics/Shipping/Freight Forwarder，或者 Computational Fluid Dynamics（CFD）。我拿去交给 AI 就好……嘿嘿。

工具并不能取代知识与理解

我不希望有人读完这篇文章，以为 AI 会把一切都处理好。

AI 能写代码，但它不知道我们的客户在不满什么。它无法在不产生幻觉的情况下，自行知道我们业务中哪些环节绝不能出错。它也不知道哪些东西做出来根本没人在意。

因此，仍然需要同样投入、甚至要投入更多的，是：

• 持续求知与更新自己 — 技术移动得更快，停止学习的人会越来越不会指挥 AI，因为他不知道该要求什么。
• 看清楚客户价值在哪里 — 这是无法交给工具的部分。

当这两件事扎实，我们才能设计并开发出好系统。若这两件事不扎实，AI 只会帮我们更快地造出没人需要的东西。

那么，哪一种授权才真正能自由修改与使用

（这部分如果还没开始实际动手，读个观念先跳过也行，要做的时候再回来看。）

这一段是我看到误解最多的地方，而在 AI 替我们改代码之后，它变得重要得多。

第一类 — 最自由（MIT、BSD、Apache 2.0、ISC）

可以修改、可以商用、不必公开我们修改的代码，也可以与我们自己的闭源产品结合。

• MIT / BSD — 条件几乎只有一条：保留原有的著作权声明。
• Apache 2.0 — 多了两件组织应当在意的事：明确的专利授权（降低日后被诉的风险），以及必须说明做了哪些修改的规定。

对组织而言，我认为 Apache 2.0 是最均衡的选择，因为专利是人们往往忽视到为时已晚的风险。

第二类 — 部分开放（MPL 2.0、LGPL）

• MPL 2.0 — 以文件为单位约束。改了哪个文件就公开那个文件；我们自己新写的文件可以保留。
• LGPL — 可以当作函式库调用而不必公开自己的代码，但若修改了函式库本身，就必须公开。

第三类 — 必须回馈开放（GPL、AGPL）

• GPL — 如果我们分发延伸后的成果，就必须以相同授权公开所修改的代码。
• AGPL — 更严格，因为它把透过网络提供服务也算作分发。如果在做 SaaS，这一条要仔细读。

人们最常搞错的一点

GPL 的义务发生在分发之时，而不是内部使用之时。一个把 GPL 拿来修改、自己内部使用的组织，并不会被强制向公众公开代码。重要的例外是 AGPL，它把网络服务也算在内。

正是这个误解，让许多组织从一开始就把开源排除在外，而其实他们自己真实的使用情境根本没有触及任何限制。

让 AI 改代码时，还要多留意两件事

其一 — AI 可能在我们不知情的情况下引入授权严格的代码。我们不能含糊了事、不做检查。生活已经轻松了 99.9%，拜托，别在剩下的 0.1% 上偷懒。当代码更快地涌入项目，查验代码来源也必须成为一套制度。（如果不打算建立这套制度，它就不会存在——因为它的本质是：在使用之前先筛选。）

其二 — 当 AI 修改得又频繁又大量，组织需要一种人类还追得上的记录方式（说真的，这部分还是让 AI 来帮忙），而不是指望有人记得住。

我希望泰国各层级的领导者都具备的愿景

开源曾经是关于「免费的东西」，后来是关于「开放标准」。今天我认为，它正在成为关于——掌握自身命运的能力。

当我们能够接触到源代码，并且拥有真正能修改它的工具，我们就不必等着谁来替我们做功能，不必被迫支付高昂费用，不必接受中途改变的条款，也不必担心供应商停止维护。

对泰国而言，我认为这是前所未有的、最清晰的一次机会。我们不再需要拥有与全球型公司同等规模的工程团队，才能拥有高阶技术。但这个机会要成真，前提是我们懂得选择授权、理解随之而来的义务，并认真投资于人的知识。

工具已经变便宜了。剩下的是：想让它成真，就来真的。