“大公司要用好人工智能，需要先来一次大重构！”
“超级个性化助手，是反OKR的！”
拥有13年创业、3年“燃尽”经历的 Peter Steinberger，从去年5月开始构思Clawdbot（后更名为Moltbot）。起初他担心大厂会迅速跟进，结果大厂迟迟未动，他最终亲自下场。伴随着Moltbot的爆红，这位创始人严重睡眠不足，一边忙着产品更名，一边接受众多播客的采访。
在最近一场长达114分钟的《The Pragmatic Engineer》播客对谈中，Peter分享了大量反行业共识的观点。作为一个现象级AI产品的独立开发者，他非常不喜欢“Vibe Coding”这个词，更倾向于称之为“Agentic Engineering”。
他甚至质疑AI时代“架构师”的新定位，认为那种“提前写好详细设计文档（Spec），然后交给Agent自动执行”的模式本质上仍是行不通的瀑布式开发，只会带来一场“精致的混乱”。
他们可能花几个小时设计spec，然后机器用一天把东西“造”出来。我不信这套能行。这本质上还是瀑布式软件开发，我们早就知道它行不通。
Peter认为，高效使用Coding Agent的关键在于构建验证闭环。AI在写代码上表现出色，但在创意写作上平平，正是因为代码可以被验证：编译、运行测试、检查输出。
另一个反直觉的观点是，他认为大公司很难用好AI，除非进行彻底的组织重构。新世界需要的是具备完整产品视角、能力全面的复合型人才，数量更少但自主性极高。而大公司精细的岗位分工（如工程师与产品经理泾渭分明）恰恰抑制了这种角色的出现。
此外，Peter强调，在AI时代，代码PR本身的价值在缩水，Prompt才是更高信息量的载体。他要求团队成员提交代码时必须附上使用的Prompt。
“当我看到一个PR时，我更感兴趣的其实是prompt，而不是代码本身。”
而对于如何写Prompt，Peter表示这不是提前精心准备好的，而是在与Agent的协作规划中动态产生的。
“我通常从一个想法开始，甚至会刻意‘欠提示’Agent，让它做点出乎意料的事，给我新想法。”
Peter的工作流：从对Claude Code上瘾，到转向Codex
主持人：聊聊你现在的工作流。做Moltbot时，你用多少个终端？哪些工具？你的一天是怎样的？
Peter：回溯到四月，我开始用Claude Code，然后彻底上瘾了。后来试过Cursor、Gemini 2.5和Opus 4。我还把一群朋友都“拉下水”了，我们组成了“黑眼圈俱乐部”，凌晨五点还在玩。
真正震撼我的是一个意识转变：现在我几乎什么都能做出来了。摩擦感变了。如果你对系统有理解，就能形成一种品味，知道什么是对的感觉。
写代码时有摩擦感，这正是好架构诞生的方式。我在Prompt时也有同样的摩擦感。我能感知生成过程的时间、Agent的“抵抗”、产出代码的结构。这更像一种共生关系，我学会了如何跟它“说话”。
真正的拐点在夏天，AI已经强到可以在几乎不手写代码的情况下构建软件。而让我彻底买单的是GPT-5.2（指ChatGPT的模型），我认为它被严重低估了。OpenAI现在提供的东西非常强大，我几乎每个Prompt都能拿到想要的结果。
Peter：在Moltbot项目上，我通常同时运行5到10个Agent。如果你习惯了Claude Code，需要忘掉很多为了“哄”它而做的技巧。Claude Code定义了一个新品类，我至今每天还在用。但在复杂应用程序中编写代码，Codex要好得多，因为它会花十倍的时间去理解上下文。Claude可能读三份文件就开始自信地写代码，而Codex会安静地读十分钟文件。如果你只用一个终端，这种等待体验很差，但我更愿意要这种方式。
很多人没意识到：你并不是在‘指挥’它，而是在对话。我会说，“我们看看这个结构，有哪些选项？” 每一轮对话，模型对你的产品是零认知的，你需要给它指路标志。我不需要什么“计划模式”，就是一直聊天，直到我说“build”，它才会开始构建。
更多是和Agent一起协作规划
主持人：听起来，你的很多Prompt其实是在和Agent一起做规划。
Peter：对。比如我会提醒它，“我们还需要文档，放在哪合适？” 它给建议，我再决策。我做的是系统设计，对整体结构和形态有理解，Codex负责逐行代码的实现，我负责架构。
用AI特别顺的人，并不在意内部管道的细节
主持人：这听起来像过去的“大写A的架构师”，但现在你是架构者，下面是Agent写代码。
Peter：我不太用“架构师”这个词，更喜欢“构建者（Builder）”。我发现，用AI特别顺的人和特别痛苦的人，差异很明显。我更在意结果和产品体验，关心结构而非最小细节。另一类人热爱解决纯技术难题，但不喜欢做完整产品或营销，这类人往往最抗拒AI，也最容易沮丧，因为AI恰恰擅长解决那些“难问题”。
这一年里，我学到的系统架构知识比过去五年都多。这些模型塞进了巨量知识，几乎任何问题都能问到答案，前提是你知道该问什么。
我曾经有个Twitter项目卡在一个难以复现的bug上。模型擅长逻辑追溯，但这个bug是一个隐蔽的副作用。直到我问出那个“对的问题”：“这个地方有没有任何副作用？” 一下就找到了。一切都只差一个正确的问题，但这需要知识经验来指引方向。
所以，一类人会拒绝AI，而另一类人并不在意内部管道细节，只是对“把东西做出来”感到兴奋，这些人往往进展得很好。经营过公司、带过团队的经历对我帮助很大，你学会了“这段代码也许不完美，但它能推进目标”。这非常像重新当了一次老板。
Vibe Coding不太合适，应该叫Agentic Engineering
主持人：你与Agent工作一年后，回头看，哪些变化最大？
Peter：首先，我不太喜欢“vibe coding”这个说法。
主持人：那我们该怎么叫它？
Peter：我称之为“agentic engineering”。现在重复性的编码工作被自动化了，我的速度快了很多，但我要“唱的歌”（即思考和管理）也多得多。我依然能进入心流状态，但心理上其实更累了，因为我要同时管理五到十个在做不同事情的Agent，大脑需要不停切换上下文。
我的工作方式是高度并行的。我知道Codex做一个功能需要40分钟到1小时，就交给它去“煮”，然后转身去处理其他事情。我相信这只是过渡阶段，未来系统更快后，就不需要这样并行轰炸了。
高效使用Agent的关键：建好反馈闭环
主持人：这听起来像同时管好几个灶台。
Peter：对。你的大脑一直是满负荷的。高效使用Coding Agent的关键就一句话：你得把反馈闭环建好。它必须能自己测试、自己调试。这也是为什么AI在写代码上很强，但在创意写作上表现中等的原因——创意很难验证，但代码可以编译、lint、执行、验证输出。
我的基本策略是：做一个功能，就一定让它写测试，并确保测试真的运行。例如，调试Mac App问题时，我直接让Agent建一个用于调试的CLI，走同样的代码路径。你之所以可以不看代码，是因为验证闭环搭好了，你相信它，因为测试跑过了。这和大公司里所有测试通过是强信号一样。
在我最新的项目里，我让Codex设计一组集成测试：启动Docker容器，装好系统，跑循环，测试所有API key。它自己就解决了那些烦人的小问题。关键就在于我把验证闭环关上了。
软件的本质没变，但现在我能写出更好的代码
主持人：听起来，Agent逼着我们把架构想得更可验证。
Peter：是的。软件本质上没变。但有意思的是，现在我不再亲手写代码，反而写出了更好的代码。我以前就不喜欢写测试和文档。但现在，每当我设计一个功能，文档和测试都会自动成为流程的一部分。“如何关闭闭环”已经成了我思考的一部分，这会自然地将我推向更好的架构。
AI圈太多人只是在整花活，复杂的编排层本质还是瀑布式开发
主持人：如果今天让你用Agent重做PSPDFKit，你会怎么做？
Peter：我可以用原来30%的人手跑起来，前提是能找到足够资深的、愿意委托工作给AI的人。但说实话，这种人现在不常见。AI圈子里有很多噪音，各种奇怪概念层出不穷。
我看到很多人会先搭一整套复杂的编排层：自动建工单、Agent处理工单、再发邮件……堆出一坨“精致的混乱”。他们可能花几个小时设计spec，然后机器用一天把东西‘造’出来。我不信这套能行。这本质上还是瀑布式软件开发。
我通常从一个想法开始，甚至会刻意“欠提示”Agent，让它做点出乎意料的事，给我新想法。可能80%的结果不怎么样，但总有一两个点让我意识到“这个角度我没想过”。然后我不断迭代、塑形。好软件需要“品味”。我的构建方式更像雕塑：从一块石头开始，不断凿，雕像慢慢浮现。
规划的重要性在降低
主持人：这影响了规划方式吧？以前开发成本高，前期规划很重要。
Peter：我还是会规划，但投入没那么重了。现在更容易直接试、看结果，成本低太多。以前一个任务交给新人要一两天，现在是分钟级，就算“浪费”也没那么浪费。
在Moltbot一开始，我假设是单Agent，后来变成多Agent。如果我自己写，这种改动会非常痛苦。但Codex花了三个小时，我自己大概要两周。 这让我意识到，很多前期规划其实可以在过程中‘发现’。构建的过程会反过来塑造你的想法。
超级个性化助手，是反OKR的
Peter：说说动机。四五月时，我想要一个“超个性化”的助手，它真正理解我。比如见面后会问我感受，提醒我联系朋友，甚至注意到我见到某些人会情绪低落。这是非常私人的，几乎是反OKR的。我确信技术会走到那一步。
我一直想要一个跑在自己电脑上的助手，数据是我的。所以“超个性化助手”这个念头一直在，过去几个月我终于开始真正把它做出来。
Moltbot的诞生与进化
Peter：一开始它只是个WhatsApp中继器。后来在摩洛哥旅行时，我全程用WhatsApp和我的Agent对话：它带我逛城市、开玩笑、还能替我给朋友发消息。我就被“勾住”了。
有一次我发了条语音，它三十秒后直接回复了我的语音。原来它发现文件是OGG格式，用FFmpeg转换，在我电脑上找Whisper没找到，就用我的OpenAI key去服务器转写了。这是Opus 4.5，资源调度能力强得离谱。
我还拿它当闹钟，它通过SSH连到我的电脑，调大音量叫我起床。为了这个我加了心跳机制。从安全角度看这很疯狂，但真的像魔法。我发到Twitter上反应却很冷，感觉这像新品类，非得亲身体验不可。
我真正认真做也就最近两个月。名字从WhatsRelay改成Claudius，最后定为Clawdbot（后因法律原因更名为Moltbot）。
用CLI，而不是MCP：MCP没法规模化
Peter：为了让这套东西成立，我希望一切都是CLI。为什么用CLI，不用MCP（Model Context Protocol）？说实话，MCP最大的贡献是逼着公司把API打开了，但这概念本身挺蠢的。 你得在会话一开始就把所有工具函数塞进上下文，模型再返回JSON。问题是，模型特别擅长用bash。
MCP机制下，模型拿到500个城市列表后没法过滤；你问伦敦天气，它被迫吞下所有垃圾字段。CLI可以直接用jq过滤。MCP把一切都常驻在上下文里，这是个问题。而且我没法链式调用，没法写脚本。
当然，这只是时间问题。我甚至自己写了个工具make-porter，用TypeScript把MCP转成CLI。结论很简单：现在CLI效率更高。在Moltbot里，你可以通过make-porter使用任何MCP。
已跑通视觉版Agent，通话功能已可用
Peter：所以我一直悄悄把“军队”建起来，把一切都自动化。我建了个Discord，把我的Agent拉了进去，这很离谱。然后有人进来，看我现场用它：看摄像头、做家庭自动化、当DJ。视觉这块我还在优化，但现在已经能跑了：它在后台盯着屏幕，我要是干了什么蠢事，它还会吐槽。
然后项目就炸了：一周从100个star涨到3300个。最美妙的地方在于：技术消失了。你只是跟手机里的一个朋友聊天，它能访问你的邮箱、日历、文件，能帮你建网站、抓网页、给商家打电话——通话功能我正准备合并。你不需要理解任何复杂性。
Token消耗：本质是TypeScript在搬JSON
主持人：Moltbot的结构清晰吗？你考虑token消耗、效率这些问题吗？
Peter：token更多是Prompt结构和记忆设计的问题。说到底，这东西最后就是TypeScript在搬JSON。我在不同形态之间搬运文本，可能走不同provider，有不同agent，管道非常多，但没有哪件事本身特别难。
可以自我更新配置的魔法
Peter：我花了很多精力在体验上。现在你只要敲一行命令，我会引导你配置一切。接着问你要不要“孵化”你的bot，选yes，一个终端图形界面（TUI）就出来了。
我给模型加了一个bootstrap文件，告诉它：你现在“诞生”了，要建立身份和“灵魂”。那一刻魔法开始了，用户不再觉得是在和GPT-5.2说话，而是在和朋友聊天。
还有一个点：你根本不需要手动改配置，因为Agent能改自己的配置。你直接跟它说“更新你自己”，它会拉最新版本、完成更新，然后回来告诉你“我有新功能了”。这就是魔法所在。
大公司要用好AI，需要先来一次大重构
主持人：结合你的做法，你觉得大公司里的软件工程会怎么变？
Peter：我觉得大公司会非常难以高效地采用AI，因为这要求彻底重塑公司运作方式。 比如在Google，你要么是工程师，要么是经理；想同时决定UI，这个角色不存在。但新世界需要的是有完整产品视角、什么都能干的人，数量要少得多，但自主性极高。理论上，公司规模可以砍到原来的30%。
所以我一点也不惊讶现在的大公司用不好AI。他们确实在用，但要真正用好，得先做一次大重构——不只是代码库，还有公司本身。
代码库要面向Agent设计
Peter：我设计代码库的时候，已经不是只考虑“对我好不好”，而是要“对Agent好不好”。我会为模型优化摩擦最小的路径，因为最终是它们在跟代码打交道。
现在Pull Request对我来说，更像是Prompt Request。我会看看需求，然后和我的Agent从这个PR出发，重新设计这个功能。
给新人的建议：保持无限的好奇心
主持人：对那些即将毕业、几乎没有经验的新人，你有什么建议？
Peter：我会建议他们保持无限的好奇心。 进入这个市场会更难，你必须通过真正去做东西来获得经验。我不觉得一定要写大量代码，但你需要去接触复杂的开源项目，去读、去学。
你现在拥有一台“无限耐心的机器”，它可以给你解释一切。你可以不停地问：为什么要这么设计？通过这种方式建立系统层面的理解。但这种理解通常是通过“吃苦”获得的，不会轻松。
但他们也有一个优势：他们没有被过往经验‘污染’。他们会用Agent做出很多我们根本想不到的事情，因为他们并不知道“这原本是行不通的”。
Prompt才是更高信号量的东西，提交PR要求附带Prompt
Peter：你提到的那些点，比如不在乎PR、不在乎Code Review，对我冲击很大。这些东西在过去15年一直是我的工作基石。
但现在情况变了。当我看到一个PR时，我更感兴趣的其实是Prompt，而不是代码本身。 我会要求大家把用过的Prompt一起提交。我会花更多时间读Prompt，而不是读代码。
Prompt才是更高信号量的东西：你是怎么得到这个结果的？你具体问了什么？中间做了多少引导？这些比最终代码本身更能让我理解输出。
如果有人想要新功能，我会让他先写一个清晰的Prompt需求。因为我可以直接把这个issue丢给Agent，它就会帮我把功能做出来。真正的工作在于思考“它应该怎么工作”。
传统的上手文档，不再是优先事项
Peter：如果有人只提了一个修修补补的小PR，我会直接告诉他们别这么干。因为我花在Review上的时间，是直接在Codex里输入一句“fix”等几分钟的十倍。
现在我们甚至有一个“一行式”的 onboarding。前两周项目有热度时，我直接让大家把Agent指向仓库，让它自己配置环境。我没有写传统的onboarding文档，而是用Claude Code的方式：Agent会拉代码、读文档、写配置、把一切都setup好。
原因很简单：这个产品本身就是Agent构建的。它的结构、命名方式，完全符合Agent的预期。 这些模式在模型的权重里已经被“编码”过了。因此，传统意义上的onboarding就不再是优先事项。它最终变成了一句话：把这个Prompt输入给你的Agent。
哪怕是一年前，这听起来都会像科幻。
快速问答：保持清醒的方式
主持人：最后，有什么非技术工具或习惯帮你恢复精力？
Peter：让我保持理智的事情是去健身房，把手机锁在柜子里，拥有完整、不被打扰的一小时。有时候我还会把手机留在家里出去散步，这种“断联”的感觉很棒。
主持人：非常感谢。
发表于 昨天 00:46
|
查看: 0|
回复: 0
