---
author: Peter Pang
date: '2025-10-17'
guest: ''
layout: post.njk
source: https://www.youtube.com/watch?v=OBotS2j8fsQ
speaker: Peter Pang
tags:
  - versioning
  - ai-models
  - software-development
  - trust
  - semantic-versioning
title: '"当5不再大于4，我们还能相信什么：AI与软件时代的版本信任危机"'
summary: 本期视频深入探讨了软件版本号规则在AI时代和平台生态中的混乱现状，从Semantic Versioning的黄金时代到AI模型、小程序的基础库版本命名混乱，揭示了这种混乱如何侵蚀开发者和用户的信任，以及数字版本号作为传播工具被滥用的现象。
insight: ''
draft: true
series: ''
category: ai-ml
area: tech-engineering
project: []
people: []
companies_orgs:
  - WeChat
  - Microsoft
products_models:
  - GPT
  - Claude
  - Postgres
  - Linux kernel
media_books: []
status: evergreen
---
### 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** 之后，还是乖乖地回归了数字版本号。

数字的信息密度和传播能力大于一切文字。在宣发和研发一样重要的大众行业，这就是最锋利的武器。只不过这个武器已然成为被滥用的工具。不讲武德的商家纯粹为了新闻效果，让宣发凌驾于研发之上，故意混淆版本的命名。

某种程度上来说，这是一种“狼来了”的行为。每次发生，用户的信任都会被削掉一点。因为对于任何软件或硬件产品，用户永远都处于弱势地位，受到知识门槛、商业机密、时间成本等因素的影响，用户永远没有办法了解产品的全貌。我们只能选择相信：相信商家会自觉遵守那些约定俗成的规律，相信他们在一步一个脚印地优化自己的产品，相信接下来这个版本是值得掏钱的大更新。那么当信任被榨干之后，还能剩下什么呢？