OpenClaw 爆红之后,创始人却不再用它了

Signal产业信号 · Token 公园

 Peter Steinberger 承认：有一段时间，他停止使用自己的产品了。

事情的起点，恰恰相反。

他因为自己用得不舒服，做出了一个小工具；后来越来越多人涌进来，他忙着修问题、加功能、回应安全报告、处理组织事务，反而离最初的使用体验越来越远。

AI 让做出一个功能更容易，却没有让维护一个被很多人使用的产品同样容易。

最初的产品，就是少一次回到电脑前

按 Peter 的回忆，最早的问题很小：他想离开电脑去吃点东西，却又想通过手机继续指挥电脑上的 AI。

于是他做了一个 WhatsApp 消息中继，把手机消息和电脑上的智能体接起来。

这个原型的吸引力，并不来自一个新模型。原来需要坐在终端前操作的事情，被放进了熟悉的聊天界面。用户不用先进入一个工作台，再研究里面有什么功能，而是直接给它发消息。

后来，他试着在社交平台解释这种体验，效果并不好。直到把朋友拉进群聊，让他们自己与它交互，反应才变得强烈。

这里有一个朴素的产品道理：能让用户亲手完成的事，往往比一段宏大的未来描述更有说服力。

但也要给热情划一道边界。朋友惊讶、想用，说明体验有吸引力；并不等于已经验证了长期留存，更不等于用户愿意承担持续的模型费用和配置成本。

从好玩的原型到日常工具，中间还有一段很长的路。

爆红以后，添加功能开始变成负担

演讲中，Peter 讲到自己很难拒绝社区贡献。别人花时间免费做了一个功能，他觉得不好意思说不。

为了不破坏老用户的设置，新功能又常常附带一个开关。每个决定单独看都合理，累积起来，产品却越来越难改。

假设你新增一个自动回复功能。演示时，它只需要在一个聊天软件里，调用一个模型，成功回复一次。

发布后，你要回答的是：换成另一个模型还行不行？换个消息渠道会不会重复发送？没有权限时能否停下？旧版本升级后，用户原来的设置还认不认？

这不是多写几段代码的问题。你对用户许下了一个长期承诺：以后每次更新，这件事仍然应该能用。

AI 降低了新增代码的成本，也可能让团队更容易低估后续责任。因为今天实现起来不难，所以今天先加上；至于谁来维护、出现冲突时保留哪一种行为，留给以后再说。

我的理解是，Peter 后来失去的，不只是时间，还有产品判断的中心。原先的问题是“我每天用它时，哪里不顺手”；后来变成“这个新需求，能不能也兼容一下”。

一个服务不同用户的项目，当然不能只听创始人。但它仍然需要清楚的方向：优先服务谁，哪些体验必须简单，哪些需求应该交给扩展，而不是继续塞进核心。

开放贡献，不等于放弃取舍。

这也让竞争变得微妙。谈到 Hermes 时，Peter 承认对方抓住了他们最难受的阶段：OpenClaw 忙于加固和兼容，对手却更容易讲出一个简单、清楚的产品故事。这里是他的竞争复盘，不是本文对两款产品做出的性能排名。

从用户角度看，为维护付出了多少努力，并不直接等于体验有多好。复杂性如果全部留给用户处理，新进入者就有机会从一个更省心的入口切进来。

安全不是多余的工作，但责任边界必须清楚

复盘里另一种压力来自安全。

Peter 回忆，团队投入了大量时间加固产品，而用户更新后感受到的，有时却是原来能做的事不能做了、流程变慢了、设置更麻烦了。

这个矛盾很真实。权限收紧的收益，通常是某件坏事没有发生；权限收紧的代价，却可能是用户眼前多了一次确认，或已有流程直接失败。

但不能因此得出“安全拖累产品，所以少管一点”的结论。

Peter 对部分安全研究者的批评，是他的个人体验。编译稿中的恶意技能占比争议，也缺少本文能够核对的统一样本、时间点与判定标准，不能据此判定媒体全错、项目完全安全。

更有用的办法，是把产品保证什么讲清楚。OpenClaw 当前安全文档明确：一个网关假设处于同一个可信边界内，不是把互不信任的人放进同一个智能体后，仍能自动保证彼此隔离。

换成人话，你自己使用一个能够读文件、调用工具的助手，与让一群陌生人共同操纵它，不是同一种风险。

边界明确，团队才能区分哪些是必须修的缺陷，哪些属于不支持的部署方式；用户也才知道自己究竟授权了什么。

这不是把问题藏进免责声明。边界必须落实到默认权限、隔离措施和实际测试中，否则文档写得再严谨，也只是把责任推给用户。

“支持多个模型”，不代表随时换得动

Peter 在复盘中承认，OpenClaw 一度对 Opus 做了很深的优化。因此，当 Anthropic 调整第三方工具的订阅使用规则时，即便项目已经支持其他模型，也来不及无痛切换。

不过，这次经历揭示的问题不会随一次政策调整消失。

一个产品的实际体验，不只取决于模型能否接入，还取决于它是否听得懂已有指令、能否稳定调用工具、速度是否合适、持续使用的费用能否接受。

模型列表里多一个名字，是接入完成；用户换过去以后仍能完成原来的工作，才算替代方案成立。

对应用团队来说，最危险的依赖，往往不是完全不知道，而是知道有依赖，却把替代方案停留在“以后应该能换”。

当然，为所有模型同时优化也有成本。更现实的做法，是先选清楚核心任务，定期用第二种方案跑完这些任务，知道切换会损失什么，而不是等规则变化时才第一次尝试。

这也解释了为什么“开源”与“独立”不是一回事。代码可以开放，但模型服务、设备环境和持续算力，仍然可能受制于别人。

加入大公司，没有自动解决维护问题

Peter 加入 OpenAI，也不等于 OpenClaw 被收购后变成了闭源产品。

他在 2 月 14 日的个人公告中，分别说明了自己的去向，以及让 OpenClaw 转向基金会、保持开放独立的计划。他还明确表示，比起再建一家大公司，自己更想继续构建产品。

但按这次复盘的讲述，他一度同时承担新工作、开源维护与组织筹建，负担并没有因为资源增加而自然消失。

这对“一个人加 AI 就能做公司”的想象，是一个必要补充。

AI 可以帮一个人实现更多功能，却不会自动决定哪些问题今天必须处理、哪些承诺应该拒绝、哪些贡献值得合并。有人始终要为这些选择负责。

他后来重新找回乐趣，我更愿意理解为：当责任逐步有人分担，他才重新获得了亲自使用、发现问题、修改产品的时间。

这比“保持热爱就能成功”更有解释力。乐趣不是让人跳过测试的理由，而可能是团队仍有余力改进核心体验的一个信号。

下一步，要让“随时待命”变得负担得起

演讲后半段，Peter 把方向重新拉回始终在线、跨设备，以及语音和多模态。他提到的 FaceTime 尝试，应理解为当时的实验，不是本文已经验证过的稳定功能。

我认为，更值得看的是他在问答里提到的另一个问题：持续主动工作，会持续消耗算力。

假设你让助手留意一份合作文件。每隔一小时，它都重新阅读长长的历史对话，再判断“有没有新情况”。即使最后什么也没做，检查本身也可能产生费用。

OpenClaw 的心跳文档也提醒，定期检查会执行完整的智能体回合，更短的间隔意味着更多 Token；隔离会话、减少携带的上下文，是控制成本的办法。

这意味着，下一阶段的产品差异，不只是“谁的助手更主动”，还包括它能否判断什么时候值得行动。

没有变化时，能不能安静等待？有新事件时，能不能只取必要的信息？任务失败后，会不会反复重试、不断烧钱？用户是否需要随时回来救场？

模型越能干，这些问题越重要。因为自主工作的收益和浪费，都可以被放大。

这场复盘最有价值的提醒是：一个产品可以在周末被做出来，却要在接下来的很多个月里，证明它值得留下。

OpenClaw 曾经让人看见，把 AI 放进日常生活可以有多自然。接下来，它需要证明这种自然，不是靠开发者在背后没完没了地修补，也不是靠用户不断付出配置、等待和接管的代价。

让人惊讶一次，和让人放心地一直用下去，是两种不同的能力。

/Token 公园 · Signal 产业信号