不是所有升级都值得追：我为什么开始给开发工具锁版本

开发工具锁版本，不是拒绝升级，而是把已经验证的稳定工作流从 latest、全局自动更新和不可控依赖变化里隔离出来：日常只启动固定版本，真正需要升级时再单独解锁、验证并保留回滚路径。

我以前对开发工具升级这件事，态度很简单：只要不是明显的测试版，新版本通常意味着修复更多、能力更多，跟上去就行。

后来我越来越少这样做了。

不是因为我开始排斥新东西，而是因为我真正把一套工具用进了日常工作以后，才意识到：版本本身不是资产，稳定工作的链路才是。

这次把 CodexPro 固定在当前稳定版本，就是一个很具体的例子。前面几轮升级和连接调整里，我遇到过 401、502、固定隧道不稳定、连接正常但工具不执行、启动后行为和预期不一致等问题。单独看，每一个问题都不算灾难；但它们叠在一起以后，影响的是整条工作链：读项目、改文件、跑脚本、发布网站、做多平台分发，都可能被一个看似普通的升级打断。

我最后做的事情反而很保守：确认当前版本能稳定工作以后，把它独立复制出来，给它一个固定启动入口，再把运行目录和启动脚本都设成不可写。以后即使误执行全局更新，日常工作仍然走已经验证过的那一份。

这个过程让我重新理解了“升级”这件事。

最新版并不等于生产力更高

对一个刚安装、还没形成依赖关系的工具来说，升级成本很低。坏了，重装就行。

但当一个工具已经嵌进真实工作流，情况就不一样了。

它可能依赖固定端口、固定隧道、认证方式、允许访问的目录、脚本参数、浏览器会话，甚至依赖你已经训练出来的使用习惯。一旦这些接口在新版本发生变化，升级成本就不再是“下载一个包”，而是重新验证整条链路。

这也是为什么我现在不再把 changelog 里的“新增 8 个功能”自动换算成“应该升级”。

如果那 8 个功能我一个都不用，而升级可能让已经稳定的发布流程重新排查半天，这个版本对我来说就是负收益。

我现在只接受三种升级理由

第一种是安全和兼容性。比如依赖存在明确高危漏洞，系统版本或浏览器更新以后旧版已经无法工作，或者外部协议发生了必须跟进的变化。这类不升级反而会积累风险。

第二种是解决我现在真实存在的问题。不是“可能更快”，而是当前版本确实有一个阻塞工作的 Bug，而新版本已经有可以验证的修复。

第三种是新能力带来的收益明显大于迁移成本。比如一个新版本把原来需要大量手工步骤的事情变成稳定接口，并且这个能力正好是当前工作流的瓶颈。

除此以外，我更愿意保持不动。

“不动”不是懒，它意味着我可以把时间花在真正产出内容、代码和产品的地方，而不是反复修昨天还能工作的环境。

我开始把“升级”和“启动”彻底分开

这是这次最重要的改变。

以前一个启动脚本如果顺手带着 latest、npm update、git pull 或自动下载，我会觉得很方便：每次启动都能用到最新版本。

现在我认为这在生产环境里是一个坏设计。

日常启动应该只做一件事：启动那个已经被验证过的版本。

升级则应该是另一条完全独立的流程：解锁当前版本，备份，安装新版本，跑自检，验证关键工作流，确认没问题以后再切换默认入口。如果任何一步失败，旧版本应该还能立即恢复。

这和网站发布其实是同一种思路。不能因为代码已经写完就默认线上一定正常，仍然要经过 build、门禁、线上 200 验证和回滚边界。开发工具本身也应该被当成基础设施来管理。

真正需要锁住的，不只是版本号

只在 package.json 里写一个精确版本，还不够。

我这次真正想保护的是四样东西：

第一，当前能工作的完整副本。 它不能依赖全局包下一次会不会被覆盖。

第二，固定入口。 日常执行的命令必须明确指向这一份稳定版本，而不是跟着 PATH 里谁排在前面就运行谁。

第三，启动规则。 启动脚本只能启动，不能顺便升级。

第四，回滚路径。 真需要升级时，要知道怎么解锁；升级失败，也要知道怎么一条命令退回稳定版本。

当这些东西都存在以后，“锁版本”就不是拒绝变化，而是把变化变成可控事件。

独立开发最贵的资源不是服务器，是注意力

一个人做项目以后，我对“稳定”这两个字的理解和以前不一样了。

团队里某个开发环境出问题，还可以让别人继续推进；一个人做项目时，工具坏半天，很多工作就全部停在那里。你会从写文章跳去查 npm，从修页面跳去看端口，从做产品跳去排 Cloudflare，最后一天过去，真正产生的东西很少。

所以我现在越来越愿意为“少出意外”付一点保守的代价。

这和我之前写 从空想到现实：我一个人把 XBSTACK 做上线后的复盘 是同一条线：个人项目不是把所有新东西都装上，而是逐渐建立一套能长期运行、出了问题也能恢复的系统。

我也越来越少把 AI 工具理解成单独的软件。无论是 Chat、Work、Codex，还是我自己接起来的本地工具，它们真正有价值的时候，都是进入稳定工作流以后。关于这些工具各自应该承担什么，我在 ChatGPT Work、Chat 和 Codex 到底有什么区别 里做过一次更具体的拆分。

那什么时候应该解除版本锁？

版本锁不是永久封印。

如果出现安全问题、系统兼容问题、关键 Bug 已经确认修复，或者一个新能力确实能解决当前瓶颈，我仍然会升级。

但顺序会变成：

先知道为什么升级，再升级；先准备回滚，再测试新版本；先验证关键链路，再切换默认入口。

如果只是看到“有新版了”，我现在更愿意先问一句：

这个升级到底解决了我什么问题？

回答不出来，就先不动。

过去我把“保持最新”当成一种技术洁癖。现在我更愿意把“保持可控”当成生产习惯。

对长期项目来说，真正值得追的从来不是版本号，而是连续、稳定、可恢复的产出。