如何与AI对话
这也是个磨炼的过程，注意不同AI模型有自己的品性，同样的对话方式放到不同AI模型会有不同的反馈或结果。
主持人：我记得有一次我凌晨五点在 Twitter 上给你发私信，你马上就回了。我还问你怎么这么早，你说这是常态，你基本都没睡。我问你在干嘛，你说一直在用 Claude，特别上瘾。
Peter： 真的，就跟赌场一个道理，它就是我的小老虎机。你敲下一个 prompt，要么啥也没发生，要么一坨垃圾，要么突然给你个让人头皮发麻的结果。
主持人：而且你是一个经验非常丰富的开发者，对你来说，被“震撼”并不容易。你见过好代码、烂代码，心里是有一个标准的。
Peter： 这个过程挺有意思的。稍微回顾一下，一开始是 Claude Code，然后我就彻底上头了。接着有一段时间我用 Cursor，又试了 Gemini 2.5，后来又用了 Opus 4。我还把不少朋友也拉进来了，比如我在越南认识的 Armin 和 Mario，他们都是被我“传染”的。我当时状态真的很上头，搞得他们也开始试，然后大家一起凌晨五点不睡觉。我把这群人戏称为“黑眼圈俱乐部”。这也是为什么我后来在伦敦搞了一个 meetup，名字就叫 Claude Code Anonymous。
真正把我震住的，是一个认知上的变化：我突然意识到，我现在几乎什么都能做了。
以前做副业要慎重挑选，因为写软件真的很难。现在也不轻松，但那种“摩擦”感变了。过去是“我在这个技术栈里很强，在那个栈里很菜”，现在我会想：算了，直接上 Go 吧。我完全不懂 Go，但我有系统层面的理解。一旦你有了这种理解，就会慢慢形成一种感觉，知道什么是对的、什么是错的。这本身就是一种技能。
我记得有人发推说，写代码时你能“感觉到摩擦”，而正是这种“摩擦”帮你做出好的架构。我现在 prompt 的时候也有同样的感觉：我能看到代码刷刷地生成、能感知它花了多久、能感觉到模型是不是在“顶你”，也能判断生成的东西是乱的，还是有章法的。
我在发出 prompt 的那一刻，心里其实已经有个预期：这事大概要多久。如果明显比预期慢，我立刻就知道有问题。
主持人：你等于是在“感觉”模型的状态，对吧？
Peter： 对，我觉得这是一种共生关系。我在学着更好地“跟它说话”，甚至可以说是一种新的、半死不活的语言。同时，我用这些工具的能力在提升，模型本身也在进化。
从四月到现在，我觉得真正的拐点是在夏天：那时它已经强到，你几乎可以不手写代码，就把软件做出来。但真正让我彻底服气的，其实是 GPT-5.2。我觉得它被严重低估了。
我其实不太理解，为什么还有那么多人主要用 Claude Code。当然，我能理解那是一种不同的工作方式。但我现在用的这一套强得离谱，几乎每一个 prompt 都能给我想要的结果。这在 Claude 上是很难想象的。
我最近的一个项目常常在 Codex 上同时跑五到十个 agent。如果你是典型的 Claude Code 用户，你得忘掉不少“为了哄它出好结果”的小技巧。
我也见过 Claude Code 团队，他们确实开创了一个新类别。Claude Code 是一个定义品类的产品，用来做通用电脑工作非常棒、用来写代码也很好，我现在几乎每天还在用。但一旦进入复杂应用的代码编写，Codex 就强太多了。Claude Code 往往只读三四个文件，就自信满满开始写代码，你得不断拉着它，让它多读、多看，理解整个代码库，才能把新功能编进去。Codex 则会安静地读文件，可能读十分钟。如果你只用一个终端，这体验确实会让人崩溃，我完全理解。
但我更喜欢那种，你不用事无巨细地告诉它该怎么做，我和模型更像是在对话。
我会说：“我们一起看看这个结构，有哪些可能性？你有没有考虑过这个功能？”因为每一次 session，对模型来说都是从零开始理解你的产品，你有时候只需要给它一点点提示，让它往不同的方向探索。我不需要什么 Plan 模式，只是一直聊，直到我说“那就这么建吧”，它才会真的开始动手。当然，它们都挺“容易被触发”的，但只要我说的是“讨论”“给我选项”，它就不会直接写代码。
主持人：所以你大量的 prompting，其实是在和 agent 一起做规划？
Peter： 对。比如我会提醒它“我们需要文档，那放在哪里合适？”它可能会建议“这应该单独成一页。”系统设计是我在做的，因为我对产品整体形态有清晰的理解。我不需要逐行理解代码，那是 Codex 在做的事，但架构师是我。
主持人：这听起来有点像很久以前的一种模式：有一个“Architect”，以前也是开发者，但不再亲手写代码，而是负责系统蓝图，下面有一群工程师实现。这种模式在很多现代公司已经不流行了，大家更偏向资深工程师一起协作。不过在一些银行之类的地方，还是能看到这种“大写的 Architect”。问题是，这种模式往往很让人讨厌：设计的人不用值班，不直接为结果负责，最后在现实里容易失效。
而你现在的状态，倒像是你是 architect，但手下是一群 agent。区别在于，你依然是独立贡献者，代码是你的、责任也是你的。如果你推了个 bug 把 ClawdBot 搞挂了，就像最近那次，你是要负责的。以前在公司里，architect 往往被流程和人层层保护，不太需要直接面对结果。
Peter： 我其实不太喜欢“architect”这个词，我更愿意叫自己 builder。我发现，能不能把 AI 用好，人群之间差异非常明显。
像我关心的是结果、是产品，我很在意它的感觉、体验。我关心结构层面的骨架，但不会抠那些小细节。而另一类人，特别喜欢写硬核代码、研究算法，他们不太喜欢产品、市场这些东西。他们更享受解决“难问题”。而偏偏，这正是 AI 最擅长的部分，所以这类人往往会抗拒 AI，或者感到非常失落。
很多时候，我只是给模型一点提示，但老实说，我去年在软件架构和系统设计上学到的东西，比过去五年加起来都多。这些模型里装着海量知识，一切都只差一个“问对的问题”。
像我那个 Twitter 项目到现在还没完成，我也很希望能回去继续做。所有东西一度都曾跑得很好，但用着用着就开始卡、变得奇怪，然后又莫名其妙恢复。这类问题特别难 debug，因为很难复现。基本就是：你用得越多，它就越慢。
后来我发现，是 Postgres 里有一些在特定 insert 时触发的逻辑把数据库拖得很忙。模型看不到这一层，因为抽象太远了。问题出在一个文件里的一个函数，名字也不明显。我一直没问对问题，直到我问了一句：“这里有没有副作用？”才把它挖出来，然后改掉了。所以说，一切真的都只差在能否问一个对的问题。
主持人：但前提是，你得有足够的知识和经验。
Peter： 对，这正是关键。那些对内部实现执念很深、又不太在乎“能不能先做出来”的人，往往会抗拒 AI；而那些更兴奋于“把东西做出来”的人，反而进展飞快。
还有一点对我帮助很大：以前我开公司带团队，可以盯着每个人的代码，要求他们写成我想要的样子。但很多没管过人的开发者，没有学会放手，接受“这段代码不是我理想中的样子，但它能让我更接近目标”。不完美的地方，永远可以之后再改。
我非常相信“迭代式改进”。当年在公司里，我就是花了很长时间学会一点点放手。所以，当我开始用 Claude Code 的时候，感觉就像我手下有了一群工程师：有时候很不完美，有时候甚至有点蠢，但偶尔又异常聪明。我需要引导他们，一起朝着一个目标前进。某种程度上，这感觉就像又当了一次老板。7 高效率的秘诀
主持人：挺有意思的一点是，在之前，你用一种非常传统的方式做了十几年的软件，甚至不止十几年。你不仅把产品打磨得很扎实，也非常擅长带团队、设立高标准，对“工程本身”这件事非常在意。而现在，你用 agent、用 AI 写代码有一年左右的时间了。对比这两种阶段，你觉得真正改变了什么？又有哪些东西，其实并没有变？
Peter： 我不太喜欢“vibe coding”这个说法。
主持人：那你更愿意怎么称呼？
Peter： 现在大家基本都这么叫了吧。我自己对外会说，我做的是“Agentic Engineering”。现在我往往是凌晨三点开始写代码。那些枯燥、机械的编码工作基本都被自动化掉了，我的速度快了很多，但与此同时，我需要思考的事情也多得多。
我依然能进入那种心流状态，感觉和以前几乎一样，但精神消耗其实更大，因为我不是在管理一个工程师，而是同时管五个、十个 agent。我在不同模块之间来回切换：这边是一个子系统，那边是一个功能点，我心里大概知道这个功能交给 Codex 可能要跑四十分钟到一个小时，那我就先把方案想清楚再丢给它去做，然后我转头去做别的事。
这个在跑、那个也在跑，我要过一会儿回来看看这个、再切到另一个，脑子里一直在做上下文切换。我其实挺不喜欢这种状态的，也觉得这是一个过渡期的问题。将来模型和系统更快之后，我可能就不用并行这么多。但为了保持 flow，我现在必须高度并行。
通常会有一个主项目占据我的主要注意力，旁边还有几个“卫星项目”，可能我只花五分钟交代一下、它跑半小时，我回来看看结果就行，对脑力占用不算大。
主持人：听你这么说，我想到两种画面。一种是那种经营类游戏，要管厨房里的员工，看着一道道菜出炉，你得不停切换。另一种是看国际象棋大师同时下二十盘棋，他们走到一块棋盘前看一眼，立刻做决定。有的棋要想久一点，有的扫一眼就走。你就像在不断扩展自己的“并行带宽”，只要你还能顺畅地切换。
Peter： 区别在于，用 Claude Code 的时候，你确实得换一种工作方式。它很快，但第一版产出经常是跑不通的。比如它写了点东西但你忘了同步改另外三个地方的话，程序就崩了。真正高效的秘诀在于：你必须把闭环做完整，让 agent 能自己 debug、自己测试。 这是最大的秘密，也正是我后来效率暴涨的原因。
但老实说，在 Claude Code 那一套下，很多时候你还是得回去修修补补，迭代次数也不少，所以总体并不一定快多少，只是更“互动”。现在用 Codex，几乎一次就对。我的基本策略永远是：做一个功能，一定让它写测试，确保能跑起来。
主持人：至少要能跑。
Peter： 对。哪怕是写一个 Mac 应用也是一样。就像我前两天在 debug 一个问题：同样的 TypeScript 代码，在 CLI 里能找到远程网关，但在 Mac app 里不行。Mac app 的 debug 特别烦，你得编译、启动、点来点去才知道不对。
所以我干脆说：“你给我做一个 CLI 调试工具，走完全相同的代码路径，我可以直接调用。”然后就让它自己跑、自己改。它跑了一个小时，最后告诉我这是一个 race condition 和一个配置错误。听起来也很合理。我不需要亲眼看它怎么写代码，只要闭环跑通了就行。
主持人：你其实是因为搭好了验证闭环，所以你信任它。这和在大公司里做项目有点像，所有测试都过了，并不代表百分百没问题，但已经是一个很强的信号了，至少有人替你想过、测过。
Peter： 即便在我最新的项目里，也照样会有 bug。比如 Antigravity 在工具调用的循环格式上有些奇怪的行为，你得做过滤。我一开始被折腾了很久，后来突然意识到：我为什么不把这事自动化？
于是我直接跟 Codex 说：“设计一套 live test，起一个 Docker 容器，把整个系统装起来，跑一个完整 loop，用指定文件里的 API key，然后让模型读一张图片，生成一张新图片，再反过来分析结果。”
这个过程跑得很慢，但它把我所有 API key 都测了一遍，从 Anthropic 到 OpenAI 再到 GLM，所有细节问题全修了，因为闭环是完整的。
主持人：你说的“闭环”，本质上就是让 agent 能验证自己的工作。
Peter： 没错。这也是为什么现在这些模型特别擅长写代码，但写创意内容反而一般，因为代码是可验证的：能编译、能 lint、能跑、能看输出，只要你设计得好，就能形成一个完美的反馈回路。我甚至会把核心逻辑都设计成可以用 CLI 跑，因为浏览器那一套循环太慢了，你要的是快速反馈。
主持人：所以有些东西其实没怎么变：比如后端、业务逻辑这种，本来就更容易验证。
Peter： 反而有个挺反直觉的点：用这种方式写代码，会让你变成一个更好的工程师。因为你必须把架构想清楚，才能更容易验证，而验证正是把事情做对的关键。
主持人：这其实和 AI 之前是一样的。做复杂系统的人，一开始就会想怎么让它可测试、接口怎么设计、要不要 mock、要不要端到端测试。这些都是非常困难、而且一旦做了就很难改的决策。
Peter： 软件还是软件。我现在可以很坦然地说，我不再亲手写代码了，但我写的代码质量比以前更好。而以前我已经写得很好了。在公司那会儿，测试常常很痛苦，各种边界条件、分支爆炸。
主持人：除了像 Anders 这种我非常尊敬坚持 test-first 的人，大多数开发者其实都不爱写测试。我自己也是。测试和文档对我来说从来不是一种创作。
Peter： 现在完全不一样了。我最近一个项目的文档质量是我职业生涯里最好的，但我一行都没写。我只是跟模型讲清楚设计权衡：为什么这么做，然后让它写给新手看的部分，再在后面加上更技术化的细节，效果好得惊人。测试也是一样。每做一个功能，我就会自然地问：这个怎么测？如果换一种结构，是不是更好测？因为我脑子里始终只有一件事：怎么把闭环关上。模型必须能自己验证结果，这会反过来逼我做出更好的架构。8 为什么开发者 AI 编程玩不溜？
主持人：那你觉得，为什么还有很多经验丰富的开发者，对 AI 这套东西依然很抗拒？
Peter： 前阵子我看到一篇博文，作者是我非常尊敬的人。他测试了好几个模型，其中甚至包括一些本来就不适合写代码的模型。他的做法听起来像是随便写个 prompt，在网页上点发送，拿结果就跑，甚至都不编译，结果当然很失望。
但问题是：你觉得自己第一次写代码就能没 bug 吗？这些模型，本质上是人类知识的幽灵。它们不可能一次就对，所以你必须有反馈闭环。你也不能只发一个 prompt，而是要开始一段对话。
他还抱怨模型用了旧 API。但你没告诉它 macOS 版本，它当然会默认用老 API。模型训练的数据里，旧数据本来就比新数据多。你越理解这些“小怪兽”是怎么思考的，你的 prompting 就越好。
但他可能只玩了一天，就下结论说这东西不行。这就好比你会弹吉他，我把你放到钢琴前，你随便敲两下说“这不行，我还是回去弹吉他吧”。这是另一种构建方式，另一种思维方式。
你不知道我凌晨三点对着 Claude Code 吼过多少次。后来我慢慢搞明白了：它真的就是严格按我说的话在做事。甚至有时候你可以直接问它：你为什么这么理解？
在最近一个项目里，我感觉自己更像一个“人肉合并按钮”。社区很活跃，我几乎一直在 review PR。一开始它经常只 cherry-pick 一部分就关 PR，我被气得不行。后来我问它为什么，它会说：因为你之前这么说过，我就这么理解。
慢慢地，我学会了这门“机器语言”，调整我的表达，现在它几乎每次都能给我想要的结果。这和任何技能一样，是可以练出来的。
主持人：这和 Simon Willison 说的也很像：用得越久，越能意识到自己还能做得更好。那我们来做个更极端的假设。你现在做的 ClawdBot 很火、用户很多，但还不是像 PSPDFKit 那样直接承载大量收入的业务。如果今天 PSPDFKit 从世界上消失了，你要从零重建它，手上有现在这些 agent，你会怎么做？你会把什么交给 AI？什么一定要自己把控？团队结构会变成什么样？
Peter： 今天的话，我大概用三成的人就能跑起一家公司。但前提是，这些人必须非常资深，既懂系统又敢于放手，知道哪些地方重要，哪些地方可以“vibe”一下。
这一点我在 AI 圈里其实不太常见。Twitter 上太多声音很大、但明显不知道自己在干什么的人，还有很多我觉得挺荒唐的概念。比如某些用来绕 Opus 限制的复杂流程，Codex 根本用不着。
软件开发很少是那种“列一个超长任务清单，然后全部自动执行”的问题。我看到很多人搭了一整套复杂的编排系统：自动建 ticket、agent 处理 tickets、agent 互相发邮件，最后搞出一团复杂系统。图什么？这本质上就是瀑布模型，我们早就知道它不好用。
对我来说，开发必须从一个模糊的想法开始。我甚至会故意少给 prompt，让 agent 先做点“不太对”的东西，因为可能八成都是垃圾，但那剩下的两成会给我新的启发，然后我不断迭代、塑形。
我得点它、用它、感受它。好软件需要“品味”，而这是 AI 现在最欠缺的部分。但好处是，现在做一个功能太容易了，不行就扔掉，或者重新 prompt。我的构建方式几乎总是向前的，很少回滚。就像雕塑一样：你拿着一块石头，一点点敲，慢慢地，形状就从大理石里浮现出来了。
主持人：回过头看软件工程的变化，好像有一个很明显的转折点。过去没有 AI、没有这些 agent 的时候，前期规划非常重要。你觉得现在这种变化，是因为写代码本身的成本大幅下降了吗？
Peter： 我现在还是会做规划，但投入的精力没以前那么多了。因为现在试错太便宜了，你可以直接做出来看看效果，再判断“这个形态行不行”“是不是需要微调”，甚至“干脆完全换一条路”。相比过去，这一切的成本低到一个程度，让整个过程变得更像是在玩。
主持人：对，就像以前哪怕是交给一个刚毕业的新人或者实习生，一件事也得花一两天。现在不是一天两天，而是分钟级。就算是比较长的任务，最多也就是十几二十分钟。而且你还不是干等着，一个任务在跑，另外几个也在并行跑，所以试错本身几乎不算浪费。
Peter： 是的。最早我在 Claude 里其实假设只有一个 agent，后来变成多个；一开始假设只有一个 provider，比如 WhatsApp，后来又变成支持多个。这种改动，如果是我自己手写代码，简直是灾难，要把逻辑贯穿整个系统重新织（weaving）一遍。但 Codex 花了大概几个小时就搞定了，这要是我自己来至少得两周。所以以前那种“前期一定要一次想对”的心态是现实所迫，现在我知道，很多东西是可以改的。
这也让技术债的处理变得轻松很多。你可以一边做，一边重新理解项目本身，一边调整你的思路。所以我其实不太相信那种“按 spec 写完，机器跑完就结束”的模式。你在真正开始构建之前，根本不可能完全知道自己要做什么。很多关键认知，都是在构建过程中才出现的，它们又会反过来影响系统最终的形态。
对我来说，这更像一个循环，你不是直线爬山而是绕着走，有时候还会偏离一下路径，但最终还是会到达山顶。9 ClawdBot 来了
主持人：我们换个话题。你已经连续几个月几乎不间断地在做 ClawdBot。其实有一个想法很早就把你拉回来了，对吧？你一直想做一个“超个人化”的助理。
Peter： 对，而且不是那种每天早上给你发“早安，这是你今天三件待办事项”的助理。
我想要的是一个真正理解我的东西，比如我见了一个朋友回家后它会问我：“刚刚那次见面感觉怎么样？”或者有一天提醒我：“你已经三周没给 Thomas 发消息了，我注意到他最近在城里，要不要打个招呼？”又或者它会发现某些模式，比如“你每次提到这个人语气都会变，为什么？”
那是一种极度个人化的东西，几乎是反 CRM 的存在，有点像电影《Her》，但这确实是技术发展的方向。模型对文本的理解能力非常强，上下文越大它们看到的模式就越多。即便它们本质上只是矩阵计算、没有灵魂，但很多时候给人的感觉已经完全不一样了。
当时我甚至为这个想法注册了一家公司，叫 Amantus Machina，意思是“有爱的机器”。但去年夏天我真正深入做的时候，发现模型还差一点。能跑起来也有一些惊喜，但整体上还站在我需求的边缘之外。不过这反而让我很兴奋，因为 AI 的进展太快了，我很清楚这个想法可以晚点再回来做。
还有一个判断是，我相信所有大型公司都在做个人助理。未来每个人都会有一个“最懂你的朋友”，它是台机器，了解你的一切、可以替你做事、能主动提醒你。当然，这会非常消耗算力，但凡是负担得起的人，都会想要一个。然后随着系统效率提高、芯片进步，这种能力一定会逐步下沉。这几乎是确定的趋势，而且现在已经能看到一些雏形了，比如 OpenAI 推出的一些偏生产力的功能。但现在算力还不够，把这种东西真正作为产品推出来非常难。
而且还有一个问题是，我其实更希望它跑在我自己的电脑上，数据真正属于我自己。把邮件、日历、约会软件全部交给 OpenAI 或 Anthropic，说实话，挺吓人的，很多人已经在把这些模型当作心理咨询师用了，而且效果出奇地好。它非常会倾听，能理解你的困扰，只要不是某些明显差劲的版本，它真的能提出很有洞察力的问题，哪怕只是帮你复述和反思，你都会感觉被理解了。
所以我一直有这个助理的想法，只是当时技术还没到位。与此同时，我也做了很多别的有趣的东西。在职业里绕一点“vibe 的弯路”，不断给自己造工具，优化自己的工作流，这几乎是成为一个真正工程师的必经阶段。
但“超个人化 agent”这个念头一直没消失。最近几个月，我终于开始认真把它做出来。一开始它的规模其实很小，我甚至叫它 WhatsApp Relay，本意只是通过 WhatsApp 触发我电脑上的一些操作。
后来我去摩洛哥给朋友过生日，一整天都在外面，就一直用 WhatsApp 跟这个 agent 聊天。它帮我指路、开玩笑，还能用我的身份给其他朋友发消息。那一刻我真的被震住了。最早的实现非常粗糙，我甚至没用正式的方式传图片，只是丢了个字符串，让它自己用工具去读。
有一次我随手发了一条语音，其实我根本没实现语音功能。结果过了半分钟，它居然回了我一条语音。
我问它怎么做到的，它说：你发了一个文件，我看了 headers，发现是 Ogg 格式，就用 ffmpeg 转了一下；然后我找你电脑上的语音识别工具，没装，但我发现了一个 OpenAI 的 endpoint，于是用 curl 调了接口。
那一刻我真的觉得不可思议。这就是 Opus 的能力，它太“能自己想办法”了。
我开始彻底上瘾。我让它叫我起床，它跑在伦敦的 Mac Studio 上，通过 SSH 连到我在摩洛哥的 MacBook，帮我开音乐，因为我没回应就一直把音量调大。
我还加了一个 heartbeat。这简直疯了，你每隔几分钟就给一个模型发“想点酷的事情，给我点惊喜”的 prompt，这可能是史上最贵的闹钟，但它真的“懂”了。我那段时间脚受了伤需要很早起床，却一直没回应，它的推理过程非常清楚：“Peter 没回复，他必须起床，不能再睡了。”我把这个东西给朋友们看，所有人都被吸引住了，觉得这太神奇了。我自己也一样。
后来我发到 Twitter 上，反而反响很冷，因为很多人完全看不懂这是什么。我感觉，这可能是一种全新的产品类别，大家还没有形成认知。
主持人：这有点像你当年第一次接触 iPhone 的经历。广告、电视、各种宣传你都看过了，但真正的变化，其实还是在你亲手用上它之后。
Peter： 对，必须得用。我真正全力投入也就是最近这几个月，一开始它还叫 VA Relay，后来我自己都觉得这个名字不对劲了，因为功能早就不止这些了，已经接了 Telegram，还有一堆别的东西，再叫 Relay 完全不贴切。所以我给它改了个名字，叫 ClawdBot。算是个内部玩笑，我很喜欢《Doctor Who》，而且这个名字域名更好，也更能解释这个产品是什么。
与此同时，我也在悄悄搭建我的“军队”。要让这套东西真正跑起来，核心原则就是：一切都得是 CLI。所以我写了大量 CLI 控制 Google、床、灯、音乐，所有东西都变成命令行。10为什么是 CLI，不是 MCP
主持人：那为什么是 CLI？为什么不是 MCP？你怎么看 MCP 这套东西？
Peter： 说实话，MCP 更像是一根拐杖。它最大的正面价值是逼着公司去开放更多 API。但整个设计思路本身是有问题的：你得在会话一开始，就把所有工具、所有函数、所有说明一次性塞进上下文，然后模型还得精确地构造一大坨调用参数，再接收一大坨返回。
问题是，模型其实特别擅长用 bash。举个例子，你要一个天气服务，模型先问“有哪些城市”，接口一次性给你几百个城市；模型没法过滤，只能全吃进去。然后你再问“给我 London 的天气”，返回温度、风速、降雨、几十个你根本不关心的字段，最后上下文里全是垃圾信息。但如果是 CLI，模型可以直接用 jq，只拿它真正需要的那一小部分。
主持人：听起来问题并不是 MCP 本身，而是所有东西都必须提前塞进上下文。如果能按需发现、按需调用，理论上是能解决的？
Peter： 现在大家确实在往这个方向做，但还有一个根本问题：你没法“链式组合”。
我不能写一个脚本说：“找出所有温度超过二十五度的城市，再过滤字段，再把结果打包成一个命令。”因为 MCP 本质上都是孤立的工具，没法脚本化。
主持人：但这听起来更像是时间问题。就像现在我们做一个天气应用，本来就要选 API、比较价格、覆盖范围，然后再把不同 API 的结果串起来。这套事情在没有 AI 的年代已经解决过了。
Peter： 是的，AI 时代迟早也会解决。只是形式还没定。我自己干脆写了个小工具，叫 Porter，用 TypeScript，把 MCP 转成 CLI，直接打包用。
主持人：所以你的结论是至少现在，CLI 的效率更高？
Peter： 对。ClawdBot 里我其实根本没直接支持 MCP，但通过 Porter，几乎可以用任何 MCP。你甚至可以在手机上说：“用 Vercel 的 MCP 做这个事情。”它会自己去网站找 MCP、加载、按需使用。而现在很多 MCP 方案，甚至还得重启 Claude Code，用户体验非常糟，所以我就一路把自动化堆起来，工作量非常大。
Taylor 前几天还做了个视频，说“这个人疯了”，因为现在支持的东西已经多到离谱。但我自己在用 agent 的过程中只会不断冒出一个念头：我还想让它多做一点。
前段时间我干了一件“非常不理智”的事：我建了一个 Discord，把我的 agent 加了进去。有人给项目贡献了 Discord 支持，我当时其实很犹豫要不要合并，但最后还是合并了。结果就是我把一个拥有我电脑完整读写权限的 agent，扔进了一个公开的 Discord。11 把复杂度隐藏到让人觉得“理所当然”
主持人：听起来完全不像是个好主意。
Peter： 对，简直疯狂。但后来有人进来，看到我用它检查摄像头、做家庭自动化、帮我放音乐。我在厨房里，跟它说“看我的屏幕”，它就真的看到了。因为它有完整权限，可以点终端、替我打字、执行命令。你甚至可以对它说“做这个做那个”，它就照着屏幕操作。
我现在还在优化，理想状态当然是纯文本流，但现在这种方式已经能跑了，而且是后台默默在跑。任何体验过几分钟的人都会上瘾，项目的 star 数一周内从一百涨到三千多，我已经合并了 500 多个 PR。所以，我现在感觉自己就是个人肉 merge 按钮，整个人状态都有点散。
但这正是它的美妙之处：技术本身消失了。你只是拿着手机，像跟一个朋友聊天。这个“朋友”无所不能：能访问你的邮件、日历、文件，能给你搭网站、能做行政工作、能爬网页、能给朋友打电话，甚至能帮你打电话给商家订位。我正准备合并通话功能。
你完全不用关心算力、上下文、子 agent。它们在后台疯狂运转，只为了让你觉得“一切都很简单”。我还有一套记忆系统，当然不完美，但已经足够让人觉得像是魔法。
现在我走在路上，看到一个活动，随手给 Claude 发张照片。它不仅能告诉我这个活动的评价，还会检查我日历有没有冲突、朋友有没有提过。因为它掌握了大量上下文，给出的回答，已经完全不是那种“各自待在小盒子里的工具”能比的。
主持人：听起来你已经做出了 Apple 想让 Siri 成为、却始终没做到的东西。
Peter： 老实说，我可能是 Anthropic 最好的销售。我都不知道有多少人因为 ClawdBot 去买了 200 美元的订阅，有些人甚至多开了一个账号。不是因为模型“浪费 token”，而是大家太爱用了，用得太频繁。而且由于复杂性被完全隐藏，他们根本感觉不到后台有多少子 agent 在忙。
真正难的地方在工程上：如何把复杂度隐藏到让人觉得“理所当然”。这才是魔法的来源。
主持人：但这也很有意思。你在架构上投入了这么多思考。现在这个项目已经跑了几个月，也确实爆了。在你脑子里，你是不是很清楚 ClawdBot 的结构？哪些地方该改、哪些地方要重构？你会不会开始担心内存、token、效率这些问题？
Peter：Token 更多是 prompt 和 memory 结构的问题。说到底，这就是 TypeScript 在搬 JSON。大模型给我文本，我存盘；我再把文本发到 WhatsApp、Slack、Discord、Signal、iMessage，还有更多渠道在接入。现在结构确实有点乱，但本质上只是文本在不同形态间流动。有多 provider、多 agent、有 agent loop、有配置、有大量 plumbing，但没有哪一块是真的“难”。
主持人：更多是碎片化的复杂，对吧？
Peter： 对。真正的难点是：怎么让它“看起来像魔法”。我花了大量时间在安装和引导体验上。你只需要敲一行命令，我会检查你有没有 Homebrew、有没有 Node，自动安装依赖，兼容老版本；然后引导你选模型，能自动识别你已经装了什么，基本就是一路按回车。
接着你填个手机号，WhatsApp 就能直接用。我会问你要不要“给它起名字”，然后终端里会弹出一个 TUI，让你完成这一步。我还加了一个 bootstrap 阶段：模型一开始不会假装自己“有灵魂”，而是通过一轮对话慢慢理解你；然后它会把 bootstrap 文件删掉，生成 user.md、soul.md、identity 文件，记录你的偏好、价值观、内部玩笑。
这些文件不是静态的，它们会随着你们的互动不断演化。等这一切结束，你只是用 WhatsApp 跟它聊天，但你已经不再觉得自己是在跟“GPT 某个版本”说话，而是在跟一个真正的“朋友”交流。配置不需要你手改，因为 agent 能改自己。你甚至可以对它说“更新一下自己”，它就会拉最新版本、更新完再回来告诉你。
这就是我说的魔法：当复杂度被隐藏到极致，体验才会真的发生变化。
主持人：这听起来其实很像你当年做 PSPDFKit 的思路，对吧？你把 PDF 那套复杂性完全“融”掉了，用户只需要直接用，旋转、编辑，一切都很自然地发生。
Peter： 对，甚至在当年的 API 层面就是这么想的。12 你的工作流程，公司能套用吗
主持人：我们把话题拉回到软件工程本身。你现在做的已经是一个真实在跑的产品了，是生产软件，大家在用，你也在不断 merge PR。回头看 PSPDFKit 那样的公司，几十人、上百人的团队在维护成熟系统。基于你现在构建 ClawdBot 的方式、你用的这些工具，你觉得大型公司的软件工程方式会发生什么变化？
我明显感受到一个割裂：像你这样的个人，AI 对生产力的提升是巨大的，你完全掌控；但在团队或公司层面，尤其是有大量历史代码的情况下，一切就慢很多。不是说他们不用 AI，而是感觉两个世界之间有一道鸿沟。你当过 CEO，你怎么看？这是结构性问题，还是只是时间问题，就像每一代新技术，先被一小撮人玩明白？
Peter： 我觉得，大多数公司要高效采用 AI，会非常非常难，因为这不仅是工具问题，而是要求你重新定义“公司是怎么运作的”。
你想想，在 Google 这种地方，你要么是工程师，要么是经理；你想顺手决定一下 UI 什么样？对不起，不行。要么你写代码，要么你做设计，角色边界非常清楚。
但在这个新世界里，你需要的是有完整产品视角的人，能把事情从头做到尾。这样的人数量会少得多，但要求极高：高自主性、高能力。极端一点说，公司规模可能只需要现在的三成。这听起来就很吓人了，经济上也一定会带来巨大的冲击，很多人会发现自己在这个新世界里找不到位置。
所以我一点都不意外，现有的大公司用不好 AI。他们当然也在用，但只是“用到一点”。要真正发挥作用，你得先来一次大重构，不只是代码层面的，也是组织层面的。
我现在设计代码库，已经不是为了“对我来说顺不顺手”，而是为了“对 agent 来说顺不顺手”。我优化的是模型摩擦最小、跑得最快的路径，而不一定是我个人最偏好的写法。因为最终是它在跟代码打交道，不是我。我负责的是整体结构和架构，这部分我还是按自己的方式来。
现在所有东西都要“可被解析”。PR 在我眼里，越来越像是 Prompt Request。有人提了一个 PR，我很少直接在那个 PR 上改。我会先说声谢谢，理解这个功能想干嘛，然后拉着 agent 从这个 PR 出发，把功能按我理解的方式重新设计一遍。
代码可能会复用一点，但更多是把“目标”传达清楚。有些 PR 在定位 bug 时确实很有帮助，但说实话，现在很多 PR 的整体代码质量在下降，因为大家在疯狂 Vibe Coding。可真正要把功能做对，还是得对整体设计有深刻理解，否则你连怎么引导 agent 都不知道，结果自然就会很糟。
主持人：对，没有一个完整的反馈闭环，质量肯定会出问题。
Peter： 是的，对我来说，这种方式效率极高。我记得在 PSPDFKit 的时候，一个 PR 可能要做一周，评论、来回切换上下文、等 CI 四十分钟……现在不一样了。我把代码丢给模型，它会主动提醒我“这个地方可能会影响到别的模块”。我自己也会有判断，然后我们一起把它“重塑”成符合我愿景的形态，再把代码织进去。
说实话，我现在写代码用的动词都变了，“把代码织进现有结构里”，有时候甚至要先改结构，才能让它装得进去。
主持人：那如果你现在招一两个人，变成一个小团队，你觉得代码评审、CI、CD 这些东西会怎么变化？
Peter： 我其实没那么在意 CI 了。
主持人：你以前在 PSPDFKit 可是非常在意这些的。
Peter： 以前是，现在测试本身我还是在意的，但我用的是本地 CI。我现在有点“异端”了。
agent 会跑测试，我不想每次推个后端 API，都等十分钟 CI。
主持人：但你已经在 agent 那里等了不少时间了。
Peter： 只要本地测试过了，我就 merge。偶尔 main 会出点小问题，但通常很接近正确状态。
我现在管完整流程叫 “gate”。full gate 就是 lint、build、全测试跑一遍。它就像一道门，代码出去之前必须过这关。我甚至开始用 agent 的语言了：“提交之前，跑一下 full gate。”
主持人：那如果多一个人一起做，你可能也不会做传统的 code review 了？
Peter： 我们不会讨论具体代码，而是讨论架构、讨论大的决策、讨论风格。比如最近有个 PR 加了语音通话功能，现在我可以直接对 ClawdBot 说：“帮我给这家餐厅打电话，订两个位置。”这功能很酷，但它是一个很大的模块，影响面很广。
我当时就有点犹豫：这是不是开始变成臃肿软件了？然后我又回到老套路：把它做成一个 CLI。我之前有个没做完的项目正好相关，于是我打开 Codex，说：“你看看这个 PR，再看看那个项目，能不能把这个功能织进去？”对，我又用了“织”这个词。对我来说，这已经成了一种工作方式。
主持人：就这么继续往前推了。
Peter： 对，就这么继续。我们能不能把这个功能织进 CLI 里？利弊分别是什么？然后他们会跟我说可以这样做、那样做，也会给我很坦诚的意见。听下来我会觉得，这个功能其实是适合放进项目里的，而且确实能带来一些如果做成外置 CLI 就拿不到的好处。但我心里还是会有警惕：我不喜欢臃肿，这会不会开始变成 bloatware？那能不能搞一个插件式架构？
还有一个用 AI 的“隐藏技巧”是：多引用别的产品。我经常直接跟 agent 说，你去看这个文件夹，我当初在那儿已经把问题解决过了；或者去看那个地方，之前的思路都在那里。这样它就能直接理解我当时是怎么想的，我也不用重新解释一遍。
因为如果我再解释一次，很可能反而会引入偏差，没法完全表达我脑子里的原始想法。
有个人叫 Shitty Coding Agent 的项目，名字虽然这么叫，其实一点也不 shitty。他里面有一套插件架构，可以通过 Git 加载代码，而且全是 TypeScript。我就跟 agent 说，“你去看看这个文件夹、那个文件夹。”结果它受到启发，直接给我设计出了一套非常炸裂的插件架构。所以本质上还是一种直觉驱动的过程。我昨晚基本上就是在干这个。
主持人：听起来，你的整个工作流已经和传统方式完全不一样了。PR 在你这里的角色变了，CI 也不一样了，测试还在，但更重要的是反馈回路。你用的是“织代码”，而不是“写代码”，讨论的是架构和品味。这对我来说是一个非常大的转变。
那我们假设接下来你要招一两个、三个工程师，把这个项目变成一个真正的团队，甚至一个业务, 你会看重什么样的能力？如果现在有一个资深工程师，你会被什么样的品质吸引？你会期待他们做过什么项目，或者具备什么特质，才能适应、或者快速学会这种工作方式？
Peter： 我会找那种活跃在 GitHub 上、做开源的人。更重要的是，我要感觉到他们“爱玩这个游戏”。在这个新世界里，学习方式就是不断尝试，它真的很像一个游戏：你越玩越熟练，就像学乐器一样，得一直练。
我现在能做到这么快、这么高效，连我自己都觉得有点不可思议。前几天我一天之内提交了 600 多个 commits，简直疯狂。但它是能跑的，不是那种“看起来很糟”的代码。
主持人：对，这背后是大量的技能积累。
Peter： 是的，但真的很累，你必须去玩这些技术、去学习。一开始一定会很挫败，就像你第一次去健身房又累又痛，但很快你就会变强，你会感觉到工作流在加速，能明显看到进步，然后你就慢慢上瘾了。所以，一边玩，一边拼命干。
主持人：你现在投入的时间，明显比以前多了。
Peter： 我从来没像现在这么拼过。就算当年我有公司，也没这么拼。不是因为我必须这么做，而是因为这件事太上瘾、太好玩了。再加上现在正好有势能，有一群人在推着我往前走。13 年轻人的建议
主持人：是不是也因为你商业嗅觉很好？你能看出来什么时候有机会、什么时候窗口期打开了。
你刚才提到，现在“公开做事”这件事本身就很新颖。你也说，就算你现在想招人，其实也很难，因为真正公开、高频使用这些工具的人并不多。但可能两三年后，大家都会这么做，这个优势也就没了。还有一群人很焦虑的，是应届生、没什么经验的新人。毕竟你是在成为资深工程师之后，AI 才出现的，你有大量积累可以借力。
如果你把自己放回到那个阶段，基于你现在知道的一切，你会建议他们去做什么？是打好软件工程基本功，还是直接拥抱 agent，还是两者结合？
Peter： 我会建议他们保持无限的好奇心。毫无疑问，进入这个市场一定会更难，你必须通过不断做东西来积累经验。我不觉得一定要写很多代码，但你得去接触复杂的开源项目，去读、去理解。
你现在有一台无限耐心的机器，可以把任何东西给你讲清楚，你可以不停地问：为什么要这么设计？为什么当初要这么做？慢慢建立起系统级理解。但这一切都依赖真实的好奇心，而我不觉得现在的大学真的很擅长教这个。通常，这种能力都是在痛苦中学会的。
对新人来说不会轻松，但他们也有一个优势：他们没有被“旧经验”污染。就像小孩子一样，他们会用 agent 做出我们根本想不到的事情，因为他们不知道“这事不该这么做”。而等他们这么做的时候，往往已经能跑通了。
主持人：而且他们身边的朋友也都在用这些工具。
Peter： 对。前几天我有个小的菜单栏应用，用来统计 Cursor、Claude Code 这些成本，跑得有点慢。我本能反应是：好，打开 Instruments，开始点。结果他们直接在终端里把 profiling 全做了，连 Instruments 都不用开，就直接给我提了优化方案，还顺带把性能搞快了。我完全被震住了。
主持人：我觉得我们可能低估了进入这个行业的年轻人的能力和资源整合水平。很多伟大的公司创始人都非常年轻，当时经验也不多，但热情极强。对我来说，最冲击的还是你提到的这些变化：不再依赖 PR，不做传统 code review。这些东西陪伴了你十五年以上，也是 PSPDFKit 成功的重要基石。
Peter： 是的，现在需要一整套新东西。哪怕现在有人给我提 PR，我更关心的其实是 prompt，而不是代码。我会让大家把 prompt 也一起提交，有些人会这么做。
我读 prompt 的时间，比读代码还多。因为那是更高信号的信息：你是怎么得到这个结果的？你问了什么问题？中间做了多少引导？这比最终代码本身更能帮我判断质量。
如果有人想要一个新功能，我甚至直接要一个“Prompt Request”。你把需求写清楚，我就能把 issue 指给 agent，让它直接去做。真正的工作，其实是在想清楚系统应该怎么运作、细节是什么。如果别人已经帮我把这些想清楚了，我基本可以直接说一句“build”，然后它就能跑。
相反，如果有人只提了一个很小的修复 PR，我反而会请他们别这么做，因为我花在 review 上的时间，可能是我直接在 Codex 里敲一句“fix”再等几分钟的十倍。现在我们已经可以有一行命令就启动。但在最近两周项目开始真正有热度之后，我干脆让大家直接用 agent 指向仓库来做配置。所以我们没有传统意义上的 Onboarding，而是 Claude Code 驱动的 Onboarding。
我的 agent 会自己 clone 仓库、读文档、写配置、帮用户把环境全搭好，甚至设置 Launch Agent，全程不需要人工步骤。这在以前完全不可想象，但现在不是优先级问题了，因为 agent 可以替你做这些事。
而且这个产品本身就是 agent 构建的，所以它的结构、命名方式，完全符合 agent 的“直觉”。模型权重里本身就编码了某些对命名和结构的偏好，它在这个项目里导航起来非常顺。所以我没有把太多精力放在 Onboarding 上。以后我当然也想做成很魔法的体验，但当下更重要的是信息传得通、系统别炸。14 小彩蛋
主持人：好，那我们用几个快问快答收尾。第一个：有没有一个你会推荐的工具？不是 CLI，也不是 IDE，可以是实体设备。
Peter： 我买过很多小玩意，大多数都挺一般。但有一个不贵、看起来也挺糙的东西，给了我几乎无限的快乐。它是一个用 Android 跑的电子相框，可以上传照片。它有一个邮箱，朋友可以直接给它发照片，之后就会自动显示。我家里放了好几个。技术上说，它很糟糕，动画也很简陋，但它就是不停地给我展示生活中那些快乐的瞬间。
它大概两百美元，但说实话它给我的满足感，比我新买的 iPhone 还大。我买了 iPhone 17，到现在都还没拆封，因为我一想到要换卡、迁移数据就觉得太麻烦，完全没有“非换不可”的理由。但这个小相框，真的让我很开心。
主持人：那在科技之外，有什么事情能让你充电、让你远离屏幕？
Peter： 健身房，最好是和教练一起，把手机锁在柜子里。那一个小时里，我完全活在当下，没有通知，没有冲动去摸手机。有时候我甚至出门散步，把手机直接留在家里。一开始会非常恐慌，好像手机已经变成身体的一部分了，但这种感觉反而让我觉得特别爽。
参考链接：
https://www.youtube.com/watch?v=8lF7HmQ_RgY
================