Clawdbot（最近改名叫 Moltbot）可以说是当下最受关注的 AI 项目之一。它不仅在 X 上“一夜成名”，在谷歌上的搜索量甚至一度超过了 Claude Code、Codex。
有 X 用户制作了一张 Clawdbot 在 GitHub 的标星增长趋势对比图，其增长速度几乎是一条直线，目前已接近 10 万星标。
Clawdbot 背后的开发者 Peter Steinberger 是一位非常有趣的人物。他是 iOS 生态系统最早的开发者之一，开发经验可以追溯到 iOS 2.0 时代，在开源社区贡献了大量项目。
2011 年，Steinberger 创立了 PSPDFKit，用 13 年时间将它从一款开发者工具打造成 B2B 软件巨头。在以超过 1 亿欧元的价格出售公司后，实现财富自由的 Steinberger 却感到空虚，甚至尝试用各种方式填补这种感受。
于是，“退休”三年后，Steinberger 带着对 人工智能 的浓厚兴趣回来了。在最近的采访中，他分享了众多关于AI智能体、开发范式及未来软件形态的犀利观点。
从个人痛点到一小时原型
主持人：你是怎么开始做 Clawdbot 这个项目的？
Steinberger： 说实话，我的核心信条就是“我要玩得开心”。学习这些新技术的最好方式就是去玩、去折腾。所以我做了很多有意思的小东西。
其实早在去年五月份，我就有了做个人智能体的想法。当时 GPT-4 被 GPT-4o 替代，我觉得模型还不够好，但又认为大公司很快会解决这个问题，所以我选择等待。
直到去年 11 月，我发现市面上依然没有我想要的个人智能体。尤其是在用 Codex 处理长时间任务时，我总得在旁边盯着，不断输入“continue”。我当时就想，为什么不能让一个 AI 来帮我做这件事呢？这基本上就是 Clawdbot 项目的起点。
主持人：所以是为了解决自己这个痛点？
Steinberger： 对。我当时想，能不能在 WhatsApp 上跟我的电脑聊天？这样当智能体在跑任务时，我去倒杯水也能随时查看进度或发送指令。
于是，我花了一个小时就搞定了基础的 WhatsApp 集成：接收消息，调用 Claude，然后返回结果，一次成功。所有的构建模块都是现成的，我主要写了一些“胶水”代码。基本功能实现真的只花了一个小时。
主持人：所以你其实是把现成工具组合了起来？
Steinberger： 没错。因为我喜欢用包含文字和图片的提示词，后来又花了几个小时加上了图片和音频支持。
有一次在旅行中，我下意识地给智能体发了一条语音消息。我看到状态显示“正在输入”，结果10秒后，它直接回复了我。我惊呆了，问它：“你到底是怎么做到的？”
它回复说：“你发来的消息里只有一个文件链接，没有扩展名。我检查了文件头，发现是 Opus 格式，就用你 Mac 上的 FFmpeg 把它转成了 Wave 格式。我想用 Whisper，但发现没装，安装还报错了。不过，我在你的环境变量里找到了 OpenAI 的密钥，所以就用 curl 命令把文件发给了 OpenAI，拿到转录文本，然后才回复了你。”
那一刻，我感觉就像被打通了任督二脉。只要你给这些模型足够的权限，它们真的是非常聪明、足智多谋的“野兽”。我认为这个项目既是技术，也是一种艺术和探索。
2025年，会是“个人助理”之年吗？
主持人：你的项目在一周内经历了现象级的爆火，过去几天你是怎么过来的？
Steinberger： 从睡眠上来说，很糟糕。但这也无比令人兴奋。我认为去年是“编程智能体”之年，而今年将是“个人助理”之年。我感觉我唤醒了人们对它的真实需求。
我不知道 Clawdbot 是否是最终答案，但它为人们指明了方向。我敢肯定这个领域会出现大量产品。
主持人：现在很多人都在追求能独立运行几十个小时的超长任务智能体。你怎么看？
Steinberger： 我觉得，那种“我们要做一个能独立跑20个小时的东西”的思路，有点像虚荣指标。我的瓶颈从来不是让智能体跑得更久，真正的瓶颈通常是我自己：我的提示词，以及我下一步该让它做什么的思考。
我更喜欢一种参与感更强、更迭代的方式来构建软件。我希望自己能 in the loop，随时测试它正在构建的东西。这种迭代的开发方式，远比你坐下来从理论上把一个功能规划到完美要好得多。
CLI优先，而非GUI
主持人：去年焦点好像都在浏览器智能体上。用了Clawdbot之后，感觉方向错了？
Steinberger： 是的。我在做这个项目之前，大部分的准备工作就是构建各种小巧、独立的命令行工具（CLI）。我的前提是：图形用户界面（GUI）扩展性不强。 人们围绕它做了各种奇怪的搜索功能，但真正具备扩展能力的是命令行。
智能体天生就懂 Unix 系统。你可以在电脑上放一千个小程序，它们只需要知道程序的名字，调用一下帮助菜单，就知道该怎么用了。
如果聪明一点，就应该按照模型已经习惯的方式去构建工具，为模型设计，别为人类设计。这是一种“智能体驱动”的开发思路。
大多数MCP都应该被做成CLI
主持人：MCP（模型上下文协议）这个话题最近也很有争议。你怎么看？
Steinberger： 我总说，MCP是唯一一种开发者比用户还多的软件。在大多数情况下，MCP只是对API的一层包装。大多数MCP都应该被直接做成CLI。 CLI是我可以调用并获得返回的东西，而且它是可组合的。
想象一下，你有一个天气服务，可以返回所有城市的列表。如果它是一个MCP，模型就得在上下文中处理全部500个城市的数据。但如果它是一个CLI，我就可以调用后通过管道过滤，可能只得到5个城市，节省了上下文开销，并且可以立刻把结果传给下一个工具。
所以，在几乎所有情况下，CLI都比MCP要好。MCP唯一的好处是它能保持状态，但这种情况你极少需要。MCP的存在更多是为了让市场部门高兴。
未来一大批应用会消失，提示词就是新界面
Steinberger： 同时，我还观察到一个非常有趣的现象：一大批应用将会逐渐消失。
比如，我为什么还需要MyFitnessPal这种健身应用？我只要拍张食物的照片，我的智能体已经知道我正在麦当劳做一个糟糕的决定。结合这些信息，它能完美匹配出我吃了什么，甚至可能会反过来调整我的健身计划。所以，我不再需要那个App了。
一大批应用都会消失，因为你与事物的交互方式会变得完全不同，大多数应用会被简化为API。
主持人：但非技术背景的普通人，真的会去自己部署这些吗？门槛会不会太高？
Steinberger： 我碰到一个来自设计机构的人，他没有写过一行代码。他说：“我们现在已经有了25个网络服务，我们可以为自己需要的任何东西构建内部工具。”他完全不懂代码，只是通过Telegram和他的智能体交谈，然后智能体就为他构建东西。
所以，这里有一个巨大的转变：你不再需要订阅那些只提供通用功能的初创公司的服务。你拥有自己超个性化的软件，它能精确解决你的问题，而且还是免费的。 非技术人员也在这样做，因为它非常自然。你只需要说出你的问题，然后这个东西就会为你构建解决方案。
开发者的新范式：Just Talk To It
Steinberger 作为一个资深工程师，常在博客中分享他做“Agentic Engineering”的经验。他提到一个非常有意思的观点，叫：“Just Talk To It”。
开发者不应该被编写复杂的“提示词工程”或者繁冗的工作流框架所限制住，更多地是应该学会“直接与AI交谈”。
他目前的方法通常是：开始与Codex对话，粘贴一些参考网站、想法，让它阅读代码，然后一起充实一个新功能。如果是棘手的问题，他会让AI先写成一份规格说明书（Spec），交给另一个模型审查，再把有用的部分贴回主上下文。
他特别推崇在做UI相关工作时采用迭代方式：从模糊的需求描述入手，看着模型构建，实时观察浏览器更新，然后不断加入修改，迭代打磨功能。这种方式让他可以把玩创意，看着它慢慢变得生动起来。
他常用的命令很少：
/commit：提交修改的部分，以获得干净的注释。/automerge：处理PR，等待CI变绿后压缩合并。/massageprs：与automerge类似，但用于并行处理多个PR。/review：偶尔使用的代码审查命令。
他的核心建议是：不要把时间浪费在RAG、子智能体或其他大多只是“花架子”的东西上。直接跟它对话。去把玩它。培养直觉。你与智能体协作得越多，你的结果就会越好。
Peter Steinberger 的故事和观点，为我们描绘了一个由智能体和自然语言交互主导的软件未来图景。这不仅仅是技术的进化，更是一种交互范式的根本性转变。对于广大 开发者 和产品构建者而言，理解并拥抱这种变化，或许是在下一个时代保持竞争力的关键。如果你想了解更多关于 AI 智能体、开源实战 和前沿开发理念的讨论，欢迎在云栈社区继续交流探索。
发表于 昨天 01:34
|
查看: 0|
回复: 0
