眼见他起屎山，眼见他屎山塌了——OpenClaw大崩溃

一个靠AI写出来的明星项目，被AI亲手写垮了

我打开3月22日OpenClaw的更新日志，第一反应是：这帮人疯了吗？

发布推文洋洋自得，更新内容庞大到需要单独列目录。我从入行第一天就知道，一个开发者但凡吹嘘自己搞了个大的，背后往往是拉了坨大的。果不其然，不到48小时，社区里哀鸿遍野：飞书断了，WhatsApp挂了，控制台界面404，Docker镜像拉下来根本对不上版本号。这场被官方自吹的史诗级更新，变成了一场史诗级事故。

一把梭，梭进了坑里

翻开这次的Release Notes，就明白为什么会炸了。

一个版本里，同时塞了四项核心变更：彻底废弃旧的插件API体系、抛弃npm依赖模式、收紧安全沙盒、推出全新模块化SDK。四件事，每一件单独拿出来都是大手术，合在一起没有任何兼容层，没有迁移方案，直接发出去了。所有基于旧接口开发的第三方插件，全部当场失效。

官方对此的解释是：旧接口设计太松散，索性全干掉。

我只想说——接口是合同，不是草稿。你签了合同，别人基于这份合同做了事，你不能过几个月说这合同我觉得写得不好，作废。Windows几十年前的远古API到现在都还保着，很多甚至从bug转正成了feature。兼容性是资产，不是负债。只有大家信任你的接口不会随便消失，才会给你生态，给你插件，给你用户。

OpenClaw把这层信任，一次清零了。

工程常识，不是选修课

软件工程里有一条基本规律：改动越大，风险呈指数级增长，不是线性的。你同时动10个模块，不是10倍风险，是100倍——因为模块之间的耦合、依赖和你根本预想不到的交叉，会在你最意想不到的地方爆炸。

正经的工程团队不是不知道这个道理，他们的做法是拆：理清依赖关系，每个版本只发一小部分变更，出了问题马上知道是哪次引入的，范围可控，损失可控。

但OpenClaw选择了一把梭。

更让我皱眉的是深挖之后看到的工程状态：大量PR在CI/CD没有跑通的情况下被合并，code review几乎完全由AI代劳，核心开发者已经近一个月没有亲自参与审查。这不是效率，这是放任。一个标榜Vibe Coding的明星项目，连最基本的工程门槛都撤了。

我去翻了一下近两周的PR列表，发现现在都是社区贡献者在review，其中不少人一天能批几十个PR——这种速度，能认真看什么？开发者不看代码在干什么，合并的时候也不看，最终超过任何个体能理解的规模之后，整个项目就变成了一个没有人真正掌控的黑箱。

AI写、AI审、AI合——瞎子给瞎子带路。

Vibe Coding屎山的生命周期

观察这个项目的发展轨迹，我觉得它走了一条相当典型的路。

第一阶段是打地基，这个阶段最考验创始人自身的架构能力。Peter本身是有经验的程序员，不是纯小白，这让OpenClaw的早期框架还算扛得住。

第二阶段是疯狂堆功能。世界上所有初级功能都有无数实现，AI的工作就是从记忆里把不同语言、不同框架的实现搬过来拼起来。这个阶段效率惊人，项目看上去狗模狗样，有点能用的意思，创始人开始产生幻觉：AI是真的懂我的架构。

这个幻觉来得快，但只是因为项目规模还没超过框架的承载极限。

等到大量贡献者带着各自的AI助手蜂拥而入，每个人都在屎山上继续拉屎，项目就进入了第三阶段：任何改动都可能引发连锁崩塌，屎山没塌完全是因为各种互相冲突的bug形成了神秘的动态平衡。这时候，创始人的本能反应往往是——重构。

于是就有了2026.3.22。

屎山没塌完，重构把剩下的人一起冲走了。

AI不是问题，是放大镜

我不想把这次事故的锅完全甩给AI Coding，那样的结论太简单了。

AI确实可以写代码，可以补测试，可以做初步review。但"写代码"从来不是软件工程最难的部分。真正难的是：怎么让系统在各种奇葩环境下稳定运行，怎么保证几十个模块联动改完之后整体还是一个整体，怎么在升级时不把用户炸飞。

这些事，没有任何AI能替你负责。它能做的，是帮你更快地堆出问题，也更快地把问题引爆。

原本一个慢慢烂的项目，现在可以直接炸。原本需要半年暴露的工程债，现在一个版本就能集中清算。AI不是问题的来源，是问题的放大镜和加速器。

这就是OpenClaw 2026.3.22真正告诉我的事：在没有工程治理的情况下，Vibe Coding只会让系统失控得更快、更彻底。

最后说一句

现在全网都在喊"程序员要被AI取代"，这种论调让很多人惶惶不可终日。我一直觉得这个命题本身就是错的，但懒得争。

OpenClaw 2026.3.22已经帮我说清楚了。

AI能帮你实现，但不能帮你收住。系统能不能长期稳定，不取决于你能堆多快，而取决于你能不能把它控住。真正稀缺的能力，从来不是"把东西做出来"，而是"把东西做对，然后让它别垮"。

这件事，目前只能靠怀着敬畏心的程序员来做。