笑川：【深度聊】Moltbot：正在改写 AI 创业者和 Agent 产品的底层范式

笑川：【深度聊】Moltbot：正在改写 AI 创业者和 Agent 产品的底层范式 笑川：【深度聊】Moltbot：正在改写 AI 创业者和 Agent 产品的底层范式 Modified March 3 • 要么是某个 SaaS 里的工作流机器人，帮你点点按钮、发发通知。 Moltbot 做的，则是： “把整个电脑当成一个可以被脚本控制的世界，把 Agent 放在这个世界的最中心的位置。” 你给它一段指令，它会自己问自己： • 要不要开个终端跑 cli？ • 要不要去看一个文件头？ • 要不要转一下格式？ • 要不要调一个云服务？ • 要不要写个新脚本再跑一遍？ 换句话说，它更像是一台 “个人 DevOps + RPA + 助理” 的混合机。 只是这台机器的“大脑”是 Claude / Codex 这一类模型，而“手脚”是你的本机环境。 有一个细节挺值得注意： Moltbot 爆红之后，很快阿里云、腾讯云都跟上了， 搞出了各种一键部署方案、云端环境、模板。 这说明一点： 真正有价值的，不是那个“能说会道的对话 UI”， 而是背后那一整套：如何把 Agent 安全地、稳定地、可运维地接到现有系统里的工程功夫。 而这些，过去在公司里，往往是最不容易拿来当“卖点”讲的工作。 什么是Prompt Request？ 再往下走一点，就会看到另一个有意思的发明：Prompt Request。 他现在看一个改动，不太想看 PR 里那一堆代码 diff， 而是更想看——生成这些代码的 prompt 是什么。 如果你想要某个功能，他会说： 你别先写代码，先写一份尽可能详细的 Prompt Request，把需求背景、边界条件、预期行为、失败情况、兼容性要求都写清楚。 写好了，再丢给 Agent，让它去“build”。 你会发现，这实际上是把原来那些“藏在资深工程师脑子里”的东西，强行拉到文本层面、显性化： • 原来你看一眼就懂的暗号（“你照着上一个接口那样搞一下”）， • 现在要变成能被一个语言模型读懂的说明书。 这个变化，其实挺痛的。 因为“写好说明书”这件事， 比“自己上手写一段代码”在短期里更别扭——你得忍住不去直接开写，要先想清楚。 但一旦你习惯了，收益也很直接： • 人可以下线一阵，Agent 还能按着这张说明书干； • 说明书沉淀下来，团队少一个人也能接得上手； • 版本回溯也更容易：你不只知道“代码变成这样了”，还知道“是基于什么样的一组假设生成的”。 从这个角度看，Prompt Request 其实是一种“组织习惯”的重构： 你把“交付物”从代码，扩到“代码 + 思路文档”。 这件事对做 Agent 产品的人来说也很重要—— 你到底是想做一个“更智能的 IDE”， 还是想做一套“帮团队建立 Prompt Request 规范和协作机制”的东西？ 这两条线的天花板，差异很大。 放在国内，会怎么发展？ 说到这里，再扯一下「国内创业环境」 坦白讲，把电脑完整交给一个 Agent，在大多数国内公司，是很难想象的。 从安全、合规，到责任划分，每一条都很现实： • 公司 IT 不会放心给任何程序这么大的权限； • 合规会问一堆：日志怎么存、出了事故怎么回溯； • 老板会有直觉上的担心：“机器搞坏了谁背锅”； • 一线工程师自己也会有心理门槛：“它会不会乱删我文件”。 所以，从短期来看，在中国要出现一个“原汁原味的 Moltbot”， 可能性其实不大。 但这不代表我们学不到东西。 反过来想一下： 如果你不可能像 Peter 那样“直接把本机交给 AI”， 那在我们的环境里，最合理的落地形态是什么？ 可能是这样一种路径： 不从操作系统权限入手，而是从业务闭环入手。 举个具体一点的版本： • 在一个比较清晰的业务域（比如电商运营、跨境广告投放、客服、法务合同审核）， • 把所有用到的内部系统、第三方 API、数据库、报表工具，先拼成一个“虚拟工作台”； • 再让 Agent 在这个工作台上跑：查数、写草稿、触发动作、建任务。 权限边界非常清楚，安全可控， 但内部自动化程度可以做得很高， 而且效果能被直接用钱算出来——比如节省多少人力、缩短了多少交付周期。 这类东西，说白了就是那几个老关键词： DevOps、RPA、内嵌 Agent、自动化测试、灰度发布、风控。 听上去一点也不酷， 却恰恰是决定“一个 Agent 在企业里能不能真的跑起来”的基础设施差异。 Peter 一天能做 600 次提交， 并不意味着他比别的工程师多敲了多少键盘， 而是意味着他把这套基础设施打磨到可以“放心交给机器去折腾”的程度。 说说个人 最后，回到个人。 看完这些故事，很多人脑子里飘过的是类似的问题： “我也想用 AI 帮我写点代码，可我又不是这个水平，我能做什么？” “我不是创业者，只是在公司里打工，这些东西跟我有什么关系？” “这波 Agent 大潮，错过就错过了吧，感觉已经太晚了。” 我反而会从另一条线去想： 你不一定要做一个新的 Clawdbot， 但你完全可以借着这个机会，去重构你自己的一小块工作。 比如，你可以从很小的地方开始练习—— 第一件事：有意识地把“写代码”换成“造系统 + 写说明书” 不管你现在是不是工程师，有没有写代码， 都可以先做这样一件小事： 把你最近一次比较复杂的工作， 拆成两个清单： • 清单 A：哪些环节理论上可以丢给 Agent 先试一把？ • 清单 B：哪些环节是“即使 AI 给了结果，也一定要你自己看一眼才能放心”的？ 然后，你刻意训练自己去写几份“说明书”： • 假设你要让一个 Agent 帮你写周报，那你得把“什么算好”“哪些数字必须要有”“不能在哪里瞎编”，先写下来； • 假设你要让 Agent 帮你写代码，那你得把接口、输入输出、边界条件、性能要求、风险点，先说清楚。 这件事刚开始会很费劲，因为它逼着你把过去那些“靠经验带来的直觉”， 拆成显性的文字。 但这个过程，本身就是“从功能型选手，向系统型选手”迈半步。 第二件事：刻意参与一次“闭环搭建” 如果你在公司里，多少能碰到一点 AI 项目的边， 可以主动去争取参与一件看起来不那么“酷炫”的活：建设闭环。 不管是： • 搭一套自动化测试，让 Agent 改的代码都要过这一关； • 搭一个日志与回溯系统，让 Agent 的操作可被追踪； • 还是在某个业务里，帮大家梳理“从需求到上线”的整个链条，把 AI 能参与的环节串起来。 你会发现，当你从“只在聊天框里问问题”这个状态， 变成“参与设计 Agent 出手的边界和验证机制”的那一刻， 你和 AI 之间的关系就微妙地变了： 你不再只是用户，慢慢变成了“合作者 + 设计者”。 这一步，往往是很多人职业路径真正拐弯的起点。 结语 再看回 Peter 和 Moltbot。 几个月前，他还只是一个“从退休状态里爬出来”的老工程师， 睡不着觉，在凌晨五点跟朋友狂聊 Claude Code。 今天，他成了一个“别人要排队去采访”的人， 一个很多工程师口中的“新工作流样本”。 他自己做的事情，并不比很多在公司里兢兢业业搭工具链的人高多少维度； 区别只是： • 他愿意把这套东西往前再推一步， • 把自己的电脑交出去， • 把自己的实践写出来， • 然后任由整个圈子来围观、模仿、批评。 我觉得，这才是这个故事真正有意思的地方： • 不是一个人多会写代码； • 也不是一个产品多炫酷； • 而是，在 AI 长出来的这个时间点上，有人愿意用自己的电脑、自己的 GitHub、自己的工作流，当一次“样本”。 对我们大多数人来说，也许没必要走到那么极端。 但至少可以问问自己： 在你所在的小世界里， 有没有一块地方，可以让 AI 先伸进来一只手？ 你愿不愿意，哪怕只是在这一小块地方， 学着像他那样，把位置往后退半步： • 少一点“我要亲自写每一行”的执念； • 多一点“我来设计系统、写说明书、搭闭环”的耐心。 等下一次再看到类似的爆款项目， 你可能就不会只是在社交媒体上点个“收藏”， 而是能心平气和地说一句： “哦，这条路，我大概知道该怎么走了。” • 要么是某个 SaaS 里的工作流机器人，帮你点点按钮、发发通知。 Moltbot 做的，则是： “把整个电脑当成一个可以被脚本控制的世界，把 Agent 放在这个世界的最中心的位置。” 你给它一段指令，它会自己问自己： • 要不要开个终端跑 cli？ • 要不要去看一个文件头？ • 要不要转一下格式？ • 要不要调一个云服务？ • 要不要写个新脚本再跑一遍？ 换句话说，它更像是一台 “个人 DevOps + RPA + 助理” 的混合机。 只是这台机器的“大脑”是 Claude / Codex 这一类模型，而“手脚”是你的本机环境。 有一个细节挺值得注意： Moltbot 爆红之后，很快阿里云、腾讯云都跟上了， 搞出了各种一键部署方案、云端环境、模板。 这说明一点： 真正有价值的，不是那个“能说会道的对话 UI”， 而是背后那一整套：如何把 Agent 安全地、稳定地、可运维地接到现有系统里的工程功夫。 而这些，过去在公司里，往往是最不容易拿来当“卖点”讲的工作。 什么是Prompt Request？ 再往下走一点，就会看到另一个有意思的发明：Prompt Request。 他现在看一个改动，不太想看 PR 里那一堆代码 diff， 而是更想看——生成这些代码的 prompt 是什么。 如果你想要某个功能，他会说： 你别先写代码，先写一份尽可能详细的 Prompt Request，把需求背景、边界条件、预期行为、失败情况、兼容性要求都写清楚。 写好了，再丢给 Agent，让它去“build”。 你会发现，这实际上是把原来那些“藏在资深工程师脑子里”的东西，强行拉到文本层面、显性化： • 原来你看一眼就懂的暗号（“你照着上一个接口那样搞一下”）， • 现在要变成能被一个语言模型读懂的说明书。 这个变化，其实挺痛的。 因为“写好说明书”这件事， 比“自己上手写一段代码”在短期里更别扭——你得忍住不去直接开写，要先想清楚。 但一旦你习惯了，收益也很直接： • 人可以下线一阵，Agent 还能按着这张说明书干； • 说明书沉淀下来，团队少一个人也能接得上手； • 版本回溯也更容易：你不只知道“代码变成这样了”，还知道“是基于什么样的一组假设生成的”。 从这个角度看，Prompt Request 其实是一种“组织习惯”的重构： 你把“交付物”从代码，扩到“代码 + 思路文档”。 这件事对做 Agent 产品的人来说也很重要—— 你到底是想做一个“更智能的 IDE”， 还是想做一套“帮团队建立 Prompt Request 规范和协作机制”的东西？ 这两条线的天花板，差异很大。 放在国内，会怎么发展？ 说到这里，再扯一下「国内创业环境」 坦白讲，把电脑完整交给一个 Agent，在大多数国内公司，是很难想象的。 从安全、合规，到责任划分，每一条都很现实： • 公司 IT 不会放心给任何程序这么大的权限； • 合规会问一堆：日志怎么存、出了事故怎么回溯； • 老板会有直觉上的担心：“机器搞坏了谁背锅”； • 一线工程师自己也会有心理门槛：“它会不会乱删我文件”。 所以，从短期来看，在中国要出现一个“原汁原味的 Moltbot”， 可能性其实不大。 但这不代表我们学不到东西。 反过来想一下： 如果你不可能像 Peter 那样“直接把本机交给 AI”， 那在我们的环境里，最合理的落地形态是什么？ 可能是这样一种路径： 不从操作系统权限入手，而是从业务闭环入手。 举个具体一点的版本： • 在一个比较清晰的业务域（比如电商运营、跨境广告投放、客服、法务合同审核）， • 把所有用到的内部系统、第三方 API、数据库、报表工具，先拼成一个“虚拟工作台”； • 再让 Agent 在这个工作台上跑：查数、写草稿、触发动作、建任务。 权限边界非常清楚，安全可控， 但内部自动化程度可以做得很高， 而且效果能被直接用钱算出来——比如节省多少人力、缩短了多少交付周期。 这类东西，说白了就是那几个老关键词： DevOps、RPA、内嵌 Agent、自动化测试、灰度发布、风控。 听上去一点也不酷， 却恰恰是决定“一个 Agent 在企业里能不能真的跑起来”的基础设施差异。 Peter 一天能做 600 次提交， 并不意味着他比别的工程师多敲了多少键盘， 而是意味着他把这套基础设施打磨到可以“放心交给机器去折腾”的程度。 说说个人 最后，回到个人。 看完这些故事，很多人脑子里飘过的是类似的问题： “我也想用 AI 帮我写点代码，可我又不是这个水平，我能做什么？” “我不是创业者，只是在公司里打工，这些东西跟我有什么关系？” “这波 Agent 大潮，错过就错过了吧，感觉已经太晚了。” 我反而会从另一条线去想： 你不一定要做一个新的 Clawdbot， 但你完全可以借着这个机会，去重构你自己的一小块工作。 比如，你可以从很小的地方开始练习—— 第一件事：有意识地把“写代码”换成“造系统 + 写说明书” 不管你现在是不是工程师，有没有写代码， 都可以先做这样一件小事： 把你最近一次比较复杂的工作， 拆成两个清单： • 清单 A：哪些环节理论上可以丢给 Agent 先试一把？ • 清单 B：哪些环节是“即使 AI 给了结果，也一定要你自己看一眼才能放心”的？ 然后，你刻意训练自己去写几份“说明书”： • 假设你要让一个 Agent 帮你写周报，那你得把“什么算好”“哪些数字必须要有”“不能在哪里瞎编”，先写下来； • 假设你要让 Agent 帮你写代码，那你得把接口、输入输出、边界条件、性能要求、风险点，先说清楚。 这件事刚开始会很费劲，因为它逼着你把过去那些“靠经验带来的直觉”， 拆成显性的文字。 但这个过程，本身就是“从功能型选手，向系统型选手”迈半步。 第二件事：刻意参与一次“闭环搭建” 如果你在公司里，多少能碰到一点 AI 项目的边， 可以主动去争取参与一件看起来不那么“酷炫”的活：建设闭环。 不管是： • 搭一套自动化测试，让 Agent 改的代码都要过这一关； • 搭一个日志与回溯系统，让 Agent 的操作可被追踪； • 还是在某个业务里，帮大家梳理“从需求到上线”的整个链条，把 AI 能参与的环节串起来。 你会发现，当你从“只在聊天框里问问题”这个状态， 变成“参与设计 Agent 出手的边界和验证机制”的那一刻， 你和 AI 之间的关系就微妙地变了： 你不再只是用户，慢慢变成了“合作者 + 设计者”。 这一步，往往是很多人职业路径真正拐弯的起点。 结语 再看回 Peter 和 Moltbot。 几个月前，他还只是一个“从退休状态里爬出来”的老工程师， 睡不着觉，在凌晨五点跟朋友狂聊 Claude Code。 今天，他成了一个“别人要排队去采访”的人， 一个很多工程师口中的“新工作流样本”。 他自己做的事情，并不比很多在公司里兢兢业业搭工具链的人高多少维度； 区别只是： • 他愿意把这套东西往前再推一步， • 把自己的电脑交出去， • 把自己的实践写出来， • 然后任由整个圈子来围观、模仿、批评。 我觉得，这才是这个故事真正有意思的地方： • 不是一个人多会写代码； • 也不是一个产品多炫酷； • 而是，在 AI 长出来的这个时间点上，有人愿意用自己的电脑、自己的 GitHub、自己的工作流，当一次“样本”。 对我们大多数人来说，也许没必要走到那么极端。 但至少可以问问自己： 在你所在的小世界里， 有没有一块地方，可以让 AI 先伸进来一只手？ 你愿不愿意，哪怕只是在这一小块地方， 学着像他那样，把位置往后退半步： • 少一点“我要亲自写每一行”的执念； • 多一点“我来设计系统、写说明书、搭闭环”的耐心。 等下一次再看到类似的爆款项目， 你可能就不会只是在社交媒体上点个“收藏”， 而是能心平气和地说一句： “哦，这条路，我大概知道该怎么走了。” 🔗 原文链接： https://mp.weixin.qq.com/s/4Yp aYUz... https://mp.weixin.qq.com/s/4Yp aYUz... 原创 笑川 AI产品 笑川 AI产品 笑川AI进化论2026年1月31日 10:02 浙江 🧑‍💻 小伙伴们可以通过阿里云百炼Coding Plan 来部署： 首购低至 7.9 元，续费 5 折起，支持Qwen3.5、Qwen3 max、Qwen3 coder、GLM 5、GLM 4.7、Kimi k2.5等模型 👉戳链接直达：https://t.aliyun.com/U/0iiOuy 👉查看详细部署教程：https://t.aliyun.com/U/MNkA9b 最多三步，即可拥有 7x 24小时在线、随时响应的AI助手 小伙伴们可以通过阿里云百炼Coding Plan 来部署： 首购低至 7.9 元，续费 5 折起，支持Qwen3.5、Qwen3 max、Qwen3 coder、GLM 5、GLM 4.7、Kimi k2.5等模型 👉戳链接直达：https://t.aliyun.com/U/0iiOuy 👉查看详细部署教程：https://t.aliyun.com/U/MNkA9b 最多三步，即可拥有 7x 24小时在线、随时响应的AI助手 过去这一周，如果你混迹在程序员圈、AI 圈，基本绕不开一个名字：Peter Steinberger，以及他那只“会自己折腾”的机器人——Clawdbot（现在改名 Moltbot）。 Peter Steinberger 和他的那只Moltbot，在开发者圈子里刷屏到有点夸张。 一个已经卖掉公司、退休三年的前 iOS 开发老兵，重新打开电脑，用 Claude、Codex 这些工具，把自己变成了一个“每天 提交600次任务”的人； 顺手做了个个人 Agent“Clawdbot”（现在叫 Moltbot），把自己的电脑交给它，任它读写文件、跑脚本、连 API，全球工程师一顿疯转，GitHub star一直在上涨！ GitHub 地址： https://github.com/clawdbot/clawdbot 你要说这是“又一个 AI 爆款产品”，也对； 但如果只停在“好用 / 炫酷 / 爆火”这些形容词上，其实对我们没什么用。 更有意思的是： 这个人身上，那种“AI 时代新创业者”的气质； 这只 Agent 身上，那种“真的跑得起来的产品路径”。 这两个东西，叠在一起看，很值得慢慢品味。 先说人。 如果把 Peter 的履历抽掉那些光环标签，只留下几个关键节点，其实很朴素： • 少年时期，因为一台电脑迷上编程，偷学校的游戏盘，自己写防拷贝程序卖钱； • 上大学，全职工作、边啃 MFC 这种“老旧技术书”； • 被一款约会 App 气到，在地铁上打了一长段话，因为前端实现太烂，信号断了整段话没了——回家下载 Xcode，自己写 App，第一个月赚 1 万美金； • 后来接了个修杂志阅读 App 的活，一脚陷进 PDF 渲染这个“看起来冷门、实则极硬核”的坑，13 年做出 PSPDFKit，跑到 10 亿设备上； • 公司从一个人变成七十多人，全远程，最后卖掉股份，整个人 burnout，三年不想碰电脑； • 直到 Claude Code、Codex 这一代工具出现，重新点燃了他那种“整夜不睡、钻进去折腾”的劲儿。 这条线，跟很多我们习惯想象的“AI 创业者”其实不太一样。他不是那种“顶会论文挂满墙”的科学家型；也不是那种“背后有一整支博士队”的模型创业者。 更像是一种：懂底层技术、又真的把系统跑到现实世界里去的人，然后现在突然拿到了一把新的工具「Agent」然后顺势往前迈了一步。 你会发现，他讲自己这一轮回归的时候，有几个细节很有意思： 他其实不懂 Web； 不知道怎么搞那一套现代前后端栈； 但不是先去报个班，把 React / Next.js / Node 啃一遍，而是干脆把一个 1.3MB 的 GitHub 文档扔给 Gemini，让它先写一份 specification，再把这份说明书扔给 Claude Code，说一句“build”。 然后，他就在那里 点“继续、继续、继续”。 最后程序跑崩了。 但他自己说了一句——大意是：“这对我来说已经足够了，我看到的是一个‘工作方式会被重写’的未来”。 很多人会把注意力放在“600 次提交 / 天”这种数字上。 但真正值得盯住的，其实是他这个“把自己位置往后退半步”的动作：“我写代码”； 现在变成“我搭一个系统，让 AI 去写代码、改代码、验证代码”。 以及，他开始非常认真地思考一个问题： 既然机器来写代码， 那我应该盯的是哪一层？ 他自己给出的答案，是那种典型“老派工程师”的回答： 不再太在意每一行代码的细节， 开始更在乎系统结构、技术债、可扩展性、模块化、风险点摆在哪里。 这其实就是一个很朴素的转变： • 从“行数和变量名”， • 转到“架构、接口、边界”。 你会发现，他身上那种“新创业者”的质地，不在于他 Have AI，而在于： 他已经很自然地接受了“我的工作内容要被重塑”这件事。 再说产品 再说产品 Moltbot 的诞生其实非常的神奇，下面是作者亲身描述！ • 在摩洛哥旅游，用 WhatsApp 跟自己的 Agent 聊天，让它帮忙带路、讲笑话、给朋友发消息； • 某次无意识发了条语音，本来系统根本没有语音能力，Agent 却自己想办法把语音文件认出来、用 ffmpeg 转码、去本机找 OpenAI 的 key，再 curl 一下，把语音转文字，然后再回复你； • 把这个 Agent 放到公共 Discord，给它自己电脑的读写权限，让别人远程体验“直接操控我电脑”的那种感觉； 这些故事好玩，但并不玄幻。 本质上，它们都在证明一个简单的东西： 这不是一个“聊天机器人”，而是一个坐在你操作系统和所有工具中间的“自动化层”。 我们过去几年在国内看到的大多数“Agent 产品”， 本能会往两个方向走： • 要么是 UX 很花哨的 Chat Bot，多几个工具、多几种消息类型；