Meta说Muse是“从零构建”的，但它同时承认，这款AI助手“重度受OpenClaw启发”——连工作区文件名和内容都撞了。
发生了什么
据TechCrunch报道，Meta在回应外界质疑时给出了一个自相矛盾的说法：一方面强调Muse是独立从零开发的产品，另一方面又承认它“重度受OpenClaw启发”，并具体到部分工作区文件名与内容层面。这意味着相似并非停留在交互理念或功能布局的“灵感”层面，而是落到了工程实现的细节上。Meta没有否认这些相似点的存在，只是把它们归入“启发”的范畴。
为什么重要
AI助手赛道过去一年的竞争，很大程度上是产品形态的竞争。OpenClaw作为一类以工作区、文件与任务编排为核心的助手形态，先一步把“AI如何嵌入真实工作流”这件事做成了可被感知的产品。当后来者快速跟进时，行业默认的叙事是“趋同”——大家面对相似的用户需求，自然会收敛到相似的解法。
但“趋同”和“借鉴到文件名”是两回事。文件名属于实现细节，通常不承担用户体验层面的必然性。它撞上，往往说明参考的不是抽象理念，而是具体的工程产出。这恰恰是开源与闭源、先发与后发之间长期存在的灰色地带：理念可以自由流动，实现细节的复制却会触及原创性与合规的边界。
Meta的措辞也值得注意。它选择承认“启发”而非否认相似，说明这些相似点已经难以用巧合解释。对一家体量如此大的公司而言，这种承认本身就是一种姿态管理——把问题限定在“灵感来源”而非“代码来源”的框架内。
影响与看点
对开发者而言，这件事的直接意义是：如果你在构建AI助手类产品，工作区结构、文件命名、任务编排方式这些“看起来不重要”的细节，可能比功能列表更容易成为原创性争议的证据。开源项目被大厂产品“重度启发”时，社区通常缺乏有效的追责手段，但舆论和品牌层面的成本是真实存在的。
对用户来说，短期内产品体验不会因此改变，但这件事会强化一个认知：AI助手的产品形态正在快速标准化，差异会越来越集中在模型能力、工具生态和可靠性上，而不是界面与工作区设计。
对行业而言，值得关注的是Meta后续是否会调整Muse中与OpenClaw高度相似的部分，以及OpenClaw一方是否会就此发声。如果双方都选择沉默，这类“承认启发但不承认复制”的处理方式，可能会成为大厂面对开源相似性质疑时的默认模板。
一个独立判断：当“从零构建”和“重度启发”可以同时出现在同一份声明里，原创性在AI产品语境下已经变成一种需要主动举证的主张，而不是默认成立的事实。
