昨晚，开源项目 OpenClaw 发布了新版本 v2026.3.22。然而，这个发到 npm 的包却漏掉了控制台的前端文件。全球用户升级后打开浏览器，迎接他们的只有一个冰冷的 503 错误。
问题出在哪里？
v2026.3.22 本是一个大版本更新，包含了插件市场上线、工具链重构和安全加固等众多特性，Release Notes 写了几十条。但热闹之下，用户升级后却发现控制台“消失”了。
根本原因在于，发布到 npm 的包里，整个 dist/control-ui/ 目录不翼而飞。上个版本 v2026.3.13 还是正常的，到了这个版本就直接丢了。
更让人哭笑不得的是，报错信息提示用户运行 pnpm ui:build 来自行编译前端。但问题是，scripts/ 目录同样没有被包含进发布包中。这相当于官方指了一条走不通的路。
祸不单行，同一个版本中的 WhatsApp 集成功能也出了问题——相关模块被拆到了独立的包 @openclaw/whatsapp，但这个新包当时根本还没发布到 npm 上。两个打包事故叠加，让通过 npm 安装的用户直接“团灭”。相比之下，通过 Docker 或 Git 安装的用户则安然无恙。
历史总是惊人的相似
翻看 GitHub Issues 记录，你会发现 OpenClaw 在 npm 发布这条路上并非首次翻车。
今年一月，v2026.1.29 版本中，UI 资源文件虽然存在于包内，但路径解析逻辑错误地假设 process.argv[1] 指向包内部的 dist/ 目录，导致 npm 全局安装时找不到资源。资源明明在，代码却看不见。
二月，又有用户报告 scripts/ui.js 不在 npm 包中，使得 pnpm ui:build 命令无法执行。
到了三月，则是直接将整个前端产物目录遗漏。
三个月，同一条发布流水线，踩了三个不同的坑。这说明了什么？说明在 npm publish 之后，没有任何自动化的冒烟验证流程。 既没有人，也没有 CI 流水线去检查“安装完后，软件到底能不能正常运行”。
哪怕只写一个简单的四行脚本进行验证：
npm pack
npm install -g ./openclaw-2026.3.22.tgz
openclaw doctor --non-interactive
curl -s http://127.0.0.1:18789 | grep -q "<!DOCTYPE html>"
就能拦截住昨晚的事故。遗憾的是，这样的脚本并不存在。
AI 能写代码，但管不了流程
微博评论区有一条高赞评论一针见血：
“这全是 AI 写的代码，人都看不懂，出点问题只能修 AI。也提醒一下想开了程序员的老板们，以后出了问题你们只能和 AI 扯皮了。”
查看 GitHub，确实有些 Issue 标记着 “Generated via Claude Code agent”，一些 PR 也是由 Codex 生成的。这本身不是问题——高效的开发确实可以借助 AI。
但关键在于，AI 能帮你生成代码，却不会帮你建立和优化工程流程。AI 不会主动建议“我们应该在发布前加一个冒烟测试”，也不会在你拆分新包时提醒你“新包还没发布到 npm”。代码层面的 Bug，AI 或许能写能修；但流程和工程实践层面的缺失，AI 目前还“看不见”。
这次事故让我感触颇深，因为就在前一天，我刚发布了自己维护的项目 Pigsty 的 v4.2.2 版本。那个版本升级了数十个系统软件包，其中有一个不起眼的改动：将 ETCD 从 3.6.8 升级到 3.6.9。按照语义化版本约定，这只是一个 Patch 版本，理应只包含向后兼容的 Bug 修复。
然而，在跑冒烟测试时，整个集群“炸”了。原因在于 ETCD 3.6.9 悄然为其 Member List API 添加了认证要求，而之前版本是允许普通用户直接调用的。这一改动直接导致 Pigsty 的健康检查和成员管理全部失败。
这种问题，你看 Changelog 未必能看出来，看代码 Diff 也未必能立刻反应过来。 唯一的发现方式，就是在干净的环境中真实地安装、运行、让所有组件交互一遍。
发现问题后，我做了三件事：将 ETCD 版本回滚至 3.6.8；在发布配置中锁定此版本；在更新日志中明确记录未跟进新版的原因。这并非多么高深的技术，只是一套笨办法：安装、验证、出问题则回滚、确认无误再放行。过程有点慢，有点麻烦，但它是对用户信任的一份责任。
回过头看 OpenClaw 这次事故，如果在发布前，能有人简单地执行一次安装、启动、然后打开浏览器看一眼控制台——这一切就根本不会发生。
做基础设施的，发布前装一遍、跑一圈、测一下，真的很难吗？
这不仅是对自己项目的负责，更是对社区用户的尊重。成熟的 DevOps 实践里，发布流水线的最后一步永远是验证。希望这次“翻车”能成为一个提醒，推动更多项目将自动化冒烟测试纳入发布流程。毕竟，在 云栈社区 这样的技术论坛里，我们分享的不仅是代码，更应是可靠与信任。
发表于 1 小时前
|
查看: 2|
回复: 0
