这两个月，产品经理圈子里讨论最多的词不是某个新模型，而是一个名字——OpenClaw。它在GitHub上的星标数量超过了React，登顶全球榜首；深圳出现了"上门装虾"服务，装一次收499元；全国两会都有代表拿它举例。
但我发现，大多数讨论都集中在"这东西真牛"或"这东西太难装"。没有人认真问一句：它到底做了什么产品决策，让它走到今天这一步？
这篇文章，我想认真拆一拆。
如果你让我用一句话解释OpenClaw，我会说：
它是一个让AI在你已有的App里干活的开源框架——而不是让你再装一个新App。
具体来说，OpenClaw是一套AI Agent框架。它可以接入微信、飞书、钉钉、Slack等50多个通讯平台，让AI直接在这些平台里帮你执行任务：查资料、写文案、处理表格、回复消息、调用工具……
你不需要打开一个新的AI对话框，不需要切换App，不需要复制粘贴。你在微信群里@一下它，它就开始干活。
爆火的节点发生在2026年2月初。一夜之间，它的GitHub星标从几万冲到30万，超越Linux、React，登顶全球开源项目榜首。字节跳动火速跟进，推出云端版ArkClaw。深圳出现上门装虾服务，收费499元。这个速度，甚至快过了当年DeepSeek爆火的节奏。
OpenClaw爆发时间线：
但我想说的不是这些热闹。我想说的是，在这场爆发之前，有几个产品决策，几乎注定了这个结果。
我问过不少人：OpenClaw为什么没有自己的App？
大多数人的第一反应是：”开源项目嘛，做不了App很正常。”
但我认为这个判断完全错了。“没有自己的界面”，是OpenClaw最核心的产品决策，而且是一个主动的、深思熟虑的选择。
让我们还原一下，如果OpenClaw做了自己的App，会发生什么：
用户想用AI帮他处理微信里的消息，他需要先打开OpenClaw App，把消息内容粘贴进去，等待回复，再回到微信发出去。每次操作，至少5步，切换2个App。
这不是产品体验，这是惩罚。
传统AI产品 vs OpenClaw的用户路径对比：
传统产品的逻辑是：我有一个功能→我做一个界面→我让用户来用我的界面。
OpenClaw把这个逻辑整个翻转了：用户已经在哪里→AI就去哪里→用户零迁移成本。
这个决策背后有一个对用户行为极其准确的判断：注意力不会迁移。
微信、钉钉、飞书，这些通讯工具已经占据了用户每天注意力最密集的位置。用户不会因为一个AI工具更好用，就愿意改变自己的工作流入口。这件事ChatGPT花了三年时间证明：它确实很好用，但绝大多数人用完就关，没有把它嵌入日常工作流。
OpenClaw的答案是：既然用户不来，AI就去找用户。
这让我想起微信小程序当年的决策。小程序最大的产品主张，不是”我做了一个更好的App”，而是”我让用户永远不需要离开微信”。OpenClaw把这个逻辑扩展到了AI层：我让AI永远在用户已有的场景里工作。
结果是什么？用户的使用门槛从”下载App、注册账号、学习新界面”，变成了”在现有群里@一下”。这个差距，在用户决策层面是天堑。
一个产品的用户规模上限，往往由它的启动成本决定，而不是由它的功能数量决定。
OpenClaw把启动成本压到了接近零。
让我们做一个对比。
Manus，同样是2025年爆火的AI Agent产品，被称为”通用Agent鼻祖”。它的路径是：闭源→融资→增长→最终以数十亿美元卖给Meta。
OpenClaw的路径是：开源→GitHub 30万星→字节、腾讯等大厂跟进→成为行业事实标准。
两条路径的战略逻辑对比：
两条路，哪条更值钱？这不是本文要讨论的问题。但从产品影响力的角度，OpenClaw的选择有其深刻的逻辑。
先问一个问题：OpenClaw的核心竞争壁垒是什么？
不是代码本身。Agent框架的实现思路已经是公开知识，字节可以做ArkClaw，腾讯可以做自己的版本，任何团队两个月内都能仿出一个功能相近的产品。
OpenClaw真正的壁垒是生态——是那50+个平台的接入、是社区里成千上万个开发者贡献的插件、是用户习惯中”Agent=OpenClaw”的心智绑定。
这些东西，靠闭源是建立不起来的。
当你选择闭源，你在保护自己的代码，但同时也在阻止别人帮你建生态。你的每一个功能都要自己做，每一个平台接入都要自己谈，每一个用户都要自己获取。
当你选择开源，你放弃了代码壁垒，但你得到了更宝贵的东西：每一个在GitHub上star你的开发者，都可能成为你的生态贡献者；每一个基于你的框架做了自定义部署的团队，都在帮你验证产品方向；每一个衍生版本的出现，都在给OpenClaw这个名字做背书。
ArkClaw出现的时候，很多人说”字节要干掉OpenClaw了”。我的判断恰恰相反：字节做ArkClaw，是OpenClaw赢了的标志。 因为字节选择以OpenClaw为基础来做，而不是从零重写，说明OpenClaw已经成为了这个领域的协议层。协议层不会被应用层干掉，只会因为应用层的繁荣而更值钱。
这让我想起一句话：当你无法阻止别人复制你，不如让别人帮你传播。
Manus保住了代码，但失去了生态的主导权，最终只能卖身。OpenClaw放弃了代码的独占，但拿到了整个行业的话语权。
OpenClaw最常被诟病的一点，是部署门槛太高。
你需要有服务器，需要懂命令行，需要配环境变量，需要理解Docker。对于大多数普通用户来说，装虾比学英语还难。这就是为什么深圳会出现499元上门装虾的服务——有人在帮那些”想用但装不上”的人解决问题。
【这里需要配{{社交媒体上”上门装虾”服务的截图或宣传图，展示499元定价和服务内容描述}}】
正是看准了这个痛点，MuleRun在3月中旬发布，主打”零门槛，普通人也能用Agent”，直接对标OpenClaw的弱点。
按照传统产品逻辑，这是OpenClaw的致命缺陷：你劝退了99%的潜在用户。
但我想给出另一个角度：OpenClaw早期劝退的那99%，可能恰恰是它走到今天的原因之一。
高门槛的筛选机制：
高门槛完成了一次精准的用户筛选。能够独立完成部署的，是开发者、是技术PM、是有能力贡献代码和反馈的人。这批人是早期开源项目最需要的用户——他们不只是消费者，他们是共建者。
一个早期开源项目如果迅速吸引了大量零技术背景的普通用户，会发生什么？issue区充满了”怎么安装”的问题，开发者疲于应付初级答疑，真正有价值的功能讨论被淹没。社区质量急剧下降，核心贡献者流失。
相反，OpenClaw早期的社区，聚集的是能看懂代码、能提出改进建议、能做出新插件的开发者。这个社区产出了50+平台接入、数百个功能插件。这是OpenClaw真正的护城河，不是任何一行代码能复制的。
MuleRun的零门槛解决了“让更多人用上”的问题，但它同时也稀释了社区的技术密度。 这两款产品最终可能走向不同的用户群和商业路径——MuleRun做大众市场，OpenClaw守住开发者生态——而这两个市场并不冲突。
三款产品的定位分化：
这给我们一个反常识的产品启示：早期产品的“不友好”，有时候不是失误，而是一种社区质量的隐性保障机制。 不是所有增长都值得追求，不是所有用户都是你现阶段需要的用户。
我把上面的分析提炼成三个框架，供你在日常产品决策中直接套用。
在用户已有的场景里解决问题，优于让用户迁移到你的场景。
怎么用：下次你在讨论是否要新做一个入口、一个Tab、一个独立页面之前，先问一句：用户现在在哪里完成这件事？我能不能在那里完成，而不是把他拉过来？
功能入口越少，用户的决策成本越低。有时候最好的UX，是没有新UX。
当产品壁垒不在代码本身，开源是效率最高的分发策略。
怎么用：在判断一个产品要不要开放时，先想清楚你的护城河究竟在哪里。如果核心壁垒是数据、是生态、是品牌心智，那么保护代码的意义就很有限——你保住了代码，但失去了让别人帮你建生态的机会。
对内部工具、SDK、基础设施类产品，这个逻辑尤其适用。
早期产品的高门槛，有时是社区质量的隐性保障，而不是增长的障碍。
怎么用：在拉新增长之前，先想清楚你现阶段最需要的是哪类用户。如果你需要的是高质量的共建者、深度用户、种子用户，那么降低门槛不一定是对的——筛选出来的那批人，可能比十倍数量的泛用户更有价值。
增长永远可以后做，但早期社区的质量一旦被稀释，就很难再收回来。
OpenClaw让我想到一个更大的问题。
如果AI的最佳状态是”无界面”——嵌入现有场景，悄无声息地完成工作——那么我们花了十年时间打磨的那套界面设计方法论，还有多少是有效的？
也许未来的产品经理需要思考的，不只是”这个功能放在哪个页面、用什么交互方式”，而是”这件事根本不需要界面，AI直接在后台完成就行”。
从做界面，到设计工作流。从管理用户路径，到编排Agent行为。
这个转变，可能比我们想象的来得更快。
本文由 @阿Q的AI日记 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。