#writing_sample 
# Moltbot (ClawdBot) 是对的，但它不是未来

`2026-01-29`

如果说 Claude Code 是 Unix 哲学在 AI 时代的文艺复兴，那 Moltbot（前身 ClawdBot）就是这场运动里的激进突击队。

名字本身就是致敬，毫不掩饰的继承。但它没止步于"辅助编程"，而是把 Claude Code 的边界野蛮地推向了操作系统的深处。

看着 Moltbot 的运行日志，你会有种强烈的直觉：方向对了。但当你真正试图用它重构整个生活时，又会隐约感到——它还不是终局。

## 大脑与躯体的解耦

Moltbot 做了件非常性感的事：它把 Skill 变成了对整个电脑的操作权限。

它打通了操作界面，无论 Telegram 还是 Slack，都成了它的终端；它打通了数据接入，无论硬盘里的 PDF 还是邮件里的账单，都成了它的输入流。

这设计极其精妙地诠释了 AI 时代的系统架构：本地运行的各种工具和脚本是"身体"，AI 是"大脑"。

过去我们犯了个错误，总想造一个自带身体的机器人（全能型 App），结果造出来的东西既笨重又封闭。Moltbot 告诉我们，身体早就存在了——就是现在的操作系统、Shell、那些早已写好的 Python 脚本。我们要做的，仅仅是把 AI 这个大脑嵌入到已有的工作流中。

当你把大脑接入身体，原本死板的 Shell 脚本突然有了灵性，原本孤立的文件系统突然有了记忆。这种自动化是自然流淌的，它不需要迁移数据，不需要改变习惯，只需要给 Shell 授予一个思考的权限。

爆发出的力量是惊人的。它让 Unix 的管道不仅能传递数据，还能传递意图。

## 撞墙了

为什么我说它还不是未来？

因为它撞上了一堵墙，一堵名为"业务逻辑"的墙。

Moltbot 的演示视频总是令人心潮澎湃：订机票、查天气、发邮件。但当你试图让它处理更复杂、更私人的问题时——比如"分析我过去三年的体检报告并结合最近的饮食给出建议"——你会发现，Moltbot 卡住了。

场景的复杂性，注定了工具的非通用性。

Moltbot 作为通用框架，无法预知你的体检报告是 PDF 还是 Excel，也不理解你的饮食记录存在哪个 App 里。为了实现这功能，你不可避免地要写新工具，定义新数据结构，编写新的 Python 函数告诉 Moltbot 如何读取这些数据。

这就回到了原点：AI 可以帮我们写代码，但无法替我们定义需求。

数据的组织方式、工具的接口定义、流程的异常处理，这些都需要人类深度参与。即使 Moltbot 把 API 调用封装得再好，也改变不了一个事实：要处理复杂场景，你依然需要像工程师一样思考。

## 工具的尴尬

这种对使用者的依赖，注定了 Moltbot 难以走出极客圈子。

指望工具能解决所有问题的普通用户，会在 Moltbot 面前碰壁。因为 Moltbot 本质上不是开箱即用的产品，它是个没填满内容的空框。

反而是那些优秀的工程师，或者爱钻研的技术爱好者，能从 Moltbot 身上看到金矿。

他们不会直接用 Moltbot，因为通用往往意味着臃肿和妥协。他们会借鉴 Moltbot 的架构——那种通过聊天软件控制本地 Shell 的思路，那种将 Python 函数注册为 AI 工具的设计模式——然后去打造属于自己的、更轻量、更垂直的工具。

Moltbot 的尴尬在于：懂它的人会自己造一个更好的，不懂它的人永远用不明白。

## 过渡形态

Moltbot 基于 Claude Code 做了次精彩创新。它很有吸引力，让我们看到了"操作系统智能化"的雏形。

但它只是过渡形态的标本。

真正的未来，不属于 Moltbot 这样的通用外壳，而属于那些理解了它本质、并在此基础上深度定制的"超级个体"。

超级个体不会等待完美的 Moltbot 来拯救效率。相反，他们会拆解 Moltbot，取其精华，构建那个真正懂自己数据、懂自己习惯、甚至懂自己价值观的专属系统。

在这条路上，Moltbot 是盏明灯，但绝不是终点。
