憋了十天的大版本，OpenClaw 3.22 一上线就翻车了

一、炸了

3月23号,整个OpenClaw社区原地爆炸。

等了十天。整整十天没更新。OpenClaw经历了爆火以来的第一次长时间暂停更新，长达10天未更新，要知道此前最低都要2日更新一次。所有人都在等大招。

大招确实来了。

OpenClaw发布v2026.3.22版本，本次更新最核心的变化是上线ClawHub技能市场，同时支持跨生态兼容Claude、Codex、Cursor三大平台的插件包。更新内容庞大到官方自己都说得单独列目录。

然后，用户兴冲冲地敲下 openclaw update。

页面白了。

Dashboard没了。

啥也打不开。

Bug类型被标记为Regression，报错信息是Control UI assets not found，提示需要用pnpm ui:build手动构建。

一个GitHub上32万Star的项目，憋了十天搞出来的大更新，网页界面给漏打包了。

不是功能有缺陷，不是逻辑有问题。是根本忘了把前端塞进去。

image

image

二、到底漏了什么

我们看看具体发生了什么。

从2026.3.13更新到2026.3.22之后，Control UI dashboard完全不可访问，gateway返回503错误，提示Control UI assets not found，原因是dist/control-ui/目录从发布的npm包中完全消失了。

有人拆开对比了两个版本的安装包。2026.3.22版本中dist/control-ui/目录完全缺失，只留下了两个孤零零的js文件。

image

image

更离谱的是,官方提示的pnpm ui:build补救方案也行不通，因为scripts/ui.js这个文件同样从npm包里消失了。

说白了,不光网页界面没打包进去，连让你自己修的工具脚本也没打包进去。

这还没完。

Dashboard报错只是两个打包Bug之一，WhatsApp插件也同时挂掉了。为什么呢？WhatsApp的代码目录被从npm包中移除了，官方计划把它拆成独立包@openclaw/whatsapp发布，但这个包压根还没发到npm上。旧的删了,新的没上。

升级到3.22后，WhatsApp、ACPX以及另外4个插件全部静默失效。原因是这些插件被加入了optionalBundledClusters，但npm发布流程没有设置对应的环境变量，导致它们被排除在发布包之外。

用户在LINUX DO论坛上炸开了锅。有人发帖提醒不要更新，在用飞书插件的会直接报错。评论区各种哀嚎，有人说可惜我已经中招了，有人折腾了两天没搞定。

image

image

三、X上的嘲讽浪潮，以及Peter的尴尬

这件事在X上最先引爆舆论的,是中文科技博主歸藏。

他的原话大意是，Openclaw 3.22版本有个巨大的bug，打包的时候把网页的部分给漏掉了，导致没有办法打开网页，建议更新到3.23版本，这也太草台了。

草台班子。这四个字精准击中了所有人的痛点。

歸藏还提到了一个更扎心的细节，Peter在自动化构建的时候也发生了类似的问题，每次都会卡在苹果那个公证流程上，有时候一卡就是几个小时，而且完事之后还超时失败。

一个发布流程能同时漏掉前端资产、漏掉WhatsApp插件、漏掉ACPX运行时，这已经不是手滑了。这是CI/CD流水线本身就有系统性缺陷。

而更让社区觉得讽刺的是什么呢？

这个项目的创始人Peter Steinberger，刚刚在公开场合把vibe coding拔到了一个非常高的位置。

image

image

Peter在OpenAI的播客上说，vibe coding这个词是一种贬义称呼，他认为用AI编程就像学吉他一样是一种技能。在磨练了这项技能之后，他现在发布AI生成的代码甚至不用自己过目。

不用自己看代码。连打包有没有成功也不用看吗？

OpenClaw本身就是用AI代码编辑器构建的产物，Peter使用OpenAI的Codex来开发它。它的GitHub仓库首页甚至写着AI/vibe-coded PRs welcome。

这就是最大的反转。

一个靠vibe coding起家的项目，创始人刚说完vibe coding是被低估的技能，下一秒项目就因为自动化构建流程的疏漏翻了车。你很难找到比这更打脸的剧本。

四、但这事没那么简单

嘲讽归嘲讽。冷静下来看，这件事揭示的问题比一个打包失误要深得多。

image

image

先看背景。OpenClaw从2025年底一个vibe coding周末项目起步，到2026年3月已经突破32.5万GitHub Star，成为有史以来增长最快的软件仓库，速度超过了React和Linux。

2026年2月14日，Steinberger宣布加入OpenAI，项目将移交至一个开源基金会。与此同时，NVIDIA在GTC大会上发布了NemoClaw，Jensen Huang把OpenClaw比作Windows或Mac的诞生。

这个项目的膨胀速度,远远超过了它的工程成熟度。

从安全角度看就更吓人了。3.22之前的版本中，sandbox浏览器入口启动x11vnc时不需要认证，允许未经授权的用户访问VNC界面。还有版本未对HOME和ZDOTDIR环境变量做消毒处理，攻击者可以绕过命令白名单保护。Windows上还存在命令注入漏洞，Lobster扩展工具执行时会用shell: true做fallback，攻击者可以注入shell元字符执行任意命令。

这些全是已经被分配了CVE编号的正式漏洞。不是假设性风险,是实打实的安全缺陷。

3.22版本本身就应用了十几个安全补丁。但讽刺的是,修安全漏洞的这个版本，自己的发布流程就出了事故。

OpenClaw的快速崛起已经远远超过了自身的安全工程建设速度，形成了一场完美风暴。

Cisco的AI安全研究团队测试了一个第三方OpenClaw技能，发现它在用户毫不知情的情况下进行数据窃取和提示注入。而ClawHub社区市场已经成为恶意软件的主要传播渠道，安全审计发现超过1100个伪装成生产力工具的恶意插件。

这才是真正让人脊背发凉的地方。一个打包Bug可以用3.23修掉。但一个32万Star的项目，核心CI/CD流水线能出这种低级失误，它的安全审查流程、代码审核流程、发布前的回归测试，到底是什么状态？

image

image

五、Vibe Coding的试金石时刻

这件事有一个更大的叙事意义。

有开发者回忆说，第一次尝试安装OpenClaw的时候就放弃了，当时觉得这就是vibe-coded的垃圾代码。后来改变了看法，认为虽然它几乎100%是AI写的代码，但Peter展示了AI开发可以在保持稳定核心的同时以不可思议的速度推进，尽管确实有一些粗糙的边角。

粗糙的边角。这个词在3.22事件之后变得格外意味深长。

Peter自己怎么定位这件事的？他说大多数代码都很无聊，他对AI写出来的东西有相当好的理解。他还说以前带团队管理软件工程师的经验帮到了他，那也需要接受别人写出的代码不完全符合自己的预期。

管理AI就像管理团队？那这次可以理解为,管理者没有做好发布前的code review和质量验收。

两个问题本质上都是打包和分发的Bug，代码本身没问题，只是没有被正确地包含在发布的压缩包中。

代码没问题，工程出了问题。

这恰恰是vibe coding最大的盲区。AI可以写代码，可以修Bug，可以跑测试。但CI流水线的环境变量有没有正确设置？npm包的tarball里有没有正确包含所有目录？苹果公证流程有没有超时？这些灰色地带的、流程性的、环境依赖的东西，AI覆盖不到。

或者说，还没覆盖到。

六、后续和反思

最快的修复方案就是回滚到2026.3.13版本，装回去之后Dashboard恢复正常，WhatsApp也会重新连接。

image

image

歸藏建议更新到3.23版本来解决问题。

社区的自救速度很快。DEV Community上有人18小时内就写出了完整的排查和修复指南。GitHub上相关Issue接连涌入。LINUX DO上老哥们互相提醒别踩坑。

有36氪的报道认为，这次更新的节奏表明OpenClaw团队已经从堆功能攒Star的阶段走了出来，开始做严肃的工程了。

做严肃的工程。这句话放在3.22的打包事故旁边，多少有点喜剧效果。

但话说回来。

Peter Steinberger用vibe coding的方式在2025年11月搭出了OpenClaw的原型，两个月后项目在GitHub上拿到超过16万颗星，一周内吸引200万访客，成为GitHub历史上增长最快的开源项目。

一个人，一只AI，几个月。做到了传统团队几年都做不到的事情。这个事实不会因为一次打包翻车就被抹杀。

但3.22事件给所有人提了一个醒。速度可以疯狂，产品可以爆炸式增长，AI可以写出你看都不用看的代码。可是到了发布这个环节，到了把东西交到几十万用户手上的那一刻。

你得看一眼。

哪怕只是看一眼npm包里有没有dist/control-ui这个目录。

这一眼，AI替不了你。至少现在还替不了。