AI模型版本困境
在制作本期视频时，我希望通过AI了解一下版本号的发展史。打开 copilot，我看到了15个可供选择的 大模型，但我不知道该选哪个，因为我已经搞不懂它们有什么区别了。有时候 GPT-4 的回答比 4.1 和 5 更详细，有时候 3.7 的答案会比 3.5 和 4.5 更精准。所以每次我都要挨个问一遍，再货比三家得出结论。我十分怀念那个什么软件都可以无脑使用最新版本的时代。约定俗成的版本命名规则，在 AI 时代已经荡然无存。
软件版本号的黄金时代：Semantic Versioning
在计算机行业，一直以来我们都有一个默契：用统一的表达方式来传达产品的迭代更新，这个表达方式就是 版本号。Semantic versioning（语义版本控制：由major、minor、patch三个数字组成）就是一个很优秀的版本号格式。当一个产品的新版本包含影响重大的更新时，major 就会上升一个数。比如 Python 圈子花了12年才完成的 2.7 到 3.0 的交接，这是因为代码不兼容，需要集体大规模重构。如果这个更新只包含一些可有可无的小功能，就会在 minor 上加一。如果发布的是某个 bug 的修复补丁，顾名思义，patch 就会加1。Semantic versioning 通过三个数字的组合，浓缩了几乎所有产品迭代更新的情况，这也让它成为业内几乎默认的版本号格式。
版本号的变体与可预测性
在这个基础上，不同产品也会根据自己的特殊情况进行调整。成熟的项目管理能让产品的发布周期稳定下来。比如 10.0 之后的，世界上最好的数据库 Postgres，会集中在每年的9月到10月左右发布新版本。所以他们会使用相对简洁的 major 加上 patch 的双数字格式：每年9月份 major 加一，剩下的时间里不定时发布补丁。作为 Postgres 的使用者，或者基于 Postgres 进行二次开发的程序员，都能有明确的预期管理，让整个 Postgres 生态更加稳定健康。
又比如 Linux 内核也有固定的发布周期，但因为它的周期只有8个星期，所以 major 号膨胀的特别快。作为一个已经运作了30多年的项目，版本号码太大会很影响交流和传播。所以聪明的 Linus 决定把三数字格式当双数字格式用：2011年开始，每过大约20个周期，Linus 就会让 minor 数归零，major 数加一，就像加法那样进位。所以那些不太熟悉 Linux 生态的人，可能会误以为 4:20 到 5:0 或者 5:19 到 6:0 都是什么重大的系统更新，其实并不是，只是 Linux 刚好那天起床气比较重，决定 cosplay 一下归零者。
有用短号的，自然也有用长号的。尤其是在 CI/CD 成熟的团队，一天发布10次也不为过。版本号自然复杂一些，但不管这些数字多长，有一点是不变的：开发者承诺了某种迭代更新的规律，用户由此可以更放心地按需升级。
依赖生态与信任的基石
这种默契可以驱动非常大型的技术生态，比如大多数编程语言都有的 package/dependency 机制。在一个项目里引用成百上千个依赖，每个依赖都有自己的依赖，无穷无尽。如果要程序员自己去逐一管理，逐一检查每个依赖的更新，再去决定要不要升级依赖，那将会是不可能完成的任务。这个机制能存活下来，正是因为大家对于 Semantic versioning 版本号的默契。作为依赖的使用者，我们能大胆地接受所有依赖的所有 patch 版本更新，因为大大小小的新功能我们可能用不上，但现有功能的补丁修复总是需要的。
当然，这种默契也会被不怀好意的人所利用。比如每隔半年左右， nodejs 生态里就会出现被黑客攻陷的工具库，种下木马后以 patch 的形式发布，然后全世界千千万万的软件，在第二天上班时自动更新依赖，集体中招。但我认为，这更多的是 npm 这些包管理框架的安全机制上的缺陷。版本号只是一个导火索。
开发者承诺的脆弱性：以微信小程序为例
默契真正脆弱的地方，其实来自于开发者的承诺。版本号这个东西，说白了就是一串数字，它没有任何国际标准，也没有任何法律约束力。它不像 license 那样，什么可以做、什么必须做、什么不可以做，做了之后有什么法律后果，都有非常明确的定义。版本号的定义遵循与否，只在开发者的一念之间。
微信 生态圈就是一个教科书式的反面案例。就拿小程序的 基础库 来说，虽然它的版本命名表面上遵循了 Semantic versioning，但是版本号和变更的关系、变更的内容范围，都和 Semantic versioning 的定义没有一毛钱关系。在它的 patch 版本更新中，你可能会看到全新渲染引擎的发布，或者让基础组件的行为完全改变的功能改动，让人防不胜防。
所以基础库每次发布更新公告，我们都得认真阅读、逐一核实，再决定要不要升级。但就算这样，你还是会被打个措手不及，因为小程序的运行底层实际上是一个黑箱。公开发布版本信息的基础库只是其中的一小部分，还有不少更新是不公开、不定时、不提醒的。而且这些更新会被直接推送到用户的微信上。这也意味着，哪天醒来，你随时可能收到用户愤怒的反馈，说你的小程序出故障了，不能用了。你 debug 半天无果，到微信开发者社区发帖询问，半天后才会有官方工作人员在评论区留下一句：“这个功能昨天改了/删掉了/不兼容了。”
这也是为什么到了今天，即使已经成为（中国）国内 C 端软件的半壁江山，小程序的技术生态还是那么差，因为没有几个人想为这种丝毫不尊重开发者的平台做工具。
AI模型：重蹈版本混乱覆辙
而视频开头提到的大模型也走到了这个阶段。当纯粹的堆叠数据不再带来可观的性能跃升，大模型的版本号也开始变得混乱。GPT 的 4.1 不一定比 4 好，5.0 不一定比 4.1 好。Claude 同时存在的 3.5、3.7、4.0 和 4.5，并不是同一个模型的四次跃升，更像是四个完全不同的模型。AI 公司彻底推翻了软件行业多年建立的认知体系，“新版是旧版的上位替代品”这个概念不再成立。而且所有版本的模型同时存在，同时提供服务，也让用户患上了选择困难症。
其实这也不能完全怪罪开发者，因为大模型本质上就是一个千亿维度的黑箱，谁也说不准那些权重数字改动之后，到底影响了哪些地方。没有人能写出一个准确的大模型“更新日志”。开发者能做的，只有围绕几个 Benchmark 做测试，然后以他们的结果作为迭代的成果。这也是为什么有些人抱怨新模型更差了，有些人觉得新模型更好了，因为这完全取决于你的使用场景，是不是和 AI 公司优化的那个部分，刚好在同一个 local minima 的坑里。
而随着大模型的竞争开始进入下半场，各大公司疯狂发布新版本的模型，又几乎不下架那些旧版本，只会让更多的人不知所措。
数字的诱惑：为何版本号仍被滥用？
既然这么误导人，为什么还是硬着头皮用数字版本来命名呢？无非就是因为，普通消费者看不懂那些技术名词，那些专业的更新公告，但大家都能看懂数字。对于任何软件和硬件的消费，“买新不买旧”一直以来都被奉为真理。怎么判断什么是新的呢？数字越大，它就越新呗。这也是为什么，微软 折腾了 XP 和 Vista 之后，还是乖乖地回归了数字版本号。
数字的信息密度和传播能力大于一切文字。在宣发和研发一样重要的大众行业，这就是最锋利的武器。只不过这个武器已然成为被滥用的工具。不讲武德的商家纯粹为了新闻效果，让宣发凌驾于研发之上，故意混淆版本的命名。
某种程度上来说，这是一种“狼来了”的行为。每次发生，用户的信任都会被削掉一点。因为对于任何软件或硬件产品，用户永远都处于弱势地位，受到知识门槛、商业机密、时间成本等因素的影响，用户永远没有办法了解产品的全貌。我们只能选择相信：相信商家会自觉遵守那些约定俗成的规律，相信他们在一步一个脚印地优化自己的产品，相信接下来这个版本是值得掏钱的大更新。那么当信任被榨干之后，还能剩下什么呢？