欢迎收听跨国串门计划，这是一档专注于让中文听众无障碍欣赏全球优质外语播客的节目。通过先进的 AI 声纹克隆技术，我们不仅将内容翻译成中文，还完美保留了原主持人和嘉宾的独特声音，为您呈现全球顶尖的 AI 财经、健康与科技领域精品内容。我是主播伊凯，一位热衷于 AI 领域的产品经理，很荣幸能为您搭建这座跨越语言障碍的桥梁。
接下来让我为您简单介绍本期我们克隆的这档节目。本期我们克隆的是知名播客 David Andridge 在二零二六年七月十七日更新的一期节目。主持人 David Andridge 与嘉宾 Kun Chen 进行了一场深度对谈。Kun Chen 是一位曾在 Meta、微软和 Atlassian 工作过的顶尖工程师。
他开发了 FirstMate 来管理自己的 AI 编程助手团队。这一期他们主要围绕 Kun Chen 极致的 AI 编程工作流展开，聊到了他如何用语音与主 Agent 对话，如何建立信任并处理复杂的决策。那我们就一起来听听这期的完整对话。我这边就是一个无边框的终端窗口，用的是 West Term。我喜欢 West Term，因为它高度可定制，基本上什么都能改。
我现在开的是一个 Herder 绘画，Herder 有点像 T Max 的现代版。我用了 T Max 超过十年，最近才发现 Herder。真的很喜欢它管理终端里多个绘画的方式更现代。这个跑在我的 Mac Mini 上，我还能用手机连上同一个绘画。对，所以我可以拿起手机通过 SSH 连上去，看到完全一样的终端窗口。
这也是 Herder 的一个好处，它理解 Agent 是什么。为了做更多事，人们得同时管理好几个并行的 agent 绘画，对对吧？因为一个 agent 干活可能要花不少时间，所以大家就开始多开几个绘画。有时候我看到有人开二十二十三十个绘画，但后来我简直要疯了，因为是啊，二十个绘画你得全记在脑子里。对吧？
没错。对这个痛点，促使我开发了 FirstMate，因为我觉得这不可能是最终形态。我不想整天就在不同标签页之间切来切去，还得记住每个是干什么的。我开发 FirstMate 是因为我觉得 Agent 能力越来越强之后，应该能替我去处理这些事儿。我几个月前开始用这套方案做实验，它真的管用。所以现在大多数时候，我只跟这一个 Agent 对话。
好，Kun，你曾在 Meta、微软、Atlassian 这些顶尖公司做过顶尖工程师。你现在的 AI 编程配置是什么样的？我现在基本上用 AI 来写所有我想做的东西，我几乎不会手动写任何代码了。顺便问一下，这个转变是什么时候发生的？我就是个渐进的过程。一开始大概是三年前，我们有了 GitHub Copilot。
对吧？代码补全，我们起初只是接受一行一行的代码建议，然后它进化了，开始能给出多行代码，一次给出一整个函数。对吧？再后来，我觉得改变局面的一个拐点是 Sonnet 3.5 v2 的推出，那是个改变游戏规则的时刻。那是第一次，我觉得一个 agent 可以领一个任务，然后开始替我们做事，对吧？并且带着一整套完整的结果回来。
所以，我差不多就是那时候开始用 agent 的。那段时间也很有意思，因为我当时在 Atlas 工作，我的工作就是开发编程 agent。所以我大量的试用那个模型，因为我当时我试过各种模型，从 GPT 三点五开始根本不行，让他编辑一个文件都费劲的很。GPT 四好一点，但还是差那么点意思。真正改变游戏规则的是 Sonnet 三点五 V 二，所以那是另一个拐点。
过去三年里，这么几个拐点真的极大的改变了我的工作流。那你能截个屏给我们看看你现在的配置吗？好啊，没问题，David。你是终端党还是图形界面党？我其实两个都用。真的有几周我只用终端，比如 C Max，有几周我可能就用 Codex 应用或者 Cursor 的 Agent 窗口，所以我是混合型的。好酷，我更偏向终端，我尽量把终端作为主要的开发环境，我在上面积累了太多肌肉记忆。
我这个配置用了超过二十年，一直在终端里写代码。我觉得他给我养成的习惯就是双手几乎时刻不离键盘。对那些害怕终端的人，你有什么想说的？你知道他们可能不是开发者，技术背景没那么强。你会对他们说什么？一开始确实有个学习曲线，去适应这种不同的工作流。你得用键盘来控制终端里的所有移动和操作，所以刚开始你会觉得生产力下降了，因为你不习惯，不确定怎么把每件事儿都做好，对吧？
有这个初始阶段，但一旦你跨过去，它就能让你保持心流，因为你可以双手放在键盘上，用键盘快捷键之类的方式控制一切。你的思绪是唯一在流动的东西。太棒了，那带我们看看吧。我们这儿有 Pi Agent，这是在做什么？我这儿就开着一个无边框的终端窗口，用的是 West Term。我喜欢 Westerm，因为它高度可定制，我几乎可以改掉它的一切。
这里我就把它设成了无边框，没有窗口边框，什么都没有，就是一个纯粹的终端窗口，还带着背景模糊之类的效果。我喜欢它，看起来好看，这样工作的时候眼睛看着也舒服。我现在开的是一个 Herder 绘画。Herder 有点像 T Max 的现代版。我之前用 T Max 用了十多年，最近才发现 Herder 一下就喜欢上了。
它管理终端窗口里多个绘画的方式更现代一些。那你试过 C Max 吗？C Max 和 Herder 有什么区别？对，Herder 更彻底地待在终端里。C Max 有一个 Gucci 框架，框架里面有一些面板是终端，但 Header 完全就在终端里。这样做的好处是，这个终端窗口就只是一个正在运行的程序，它跑在我的 Mac Mini 上，我可以用手机连上同一个绘画。
我拿起手机。通过 S S E 连接，就能看到完全一样的终端窗口，一切都保持一致。用其他 GUI 应用就很难做到，因为你没法直接远程桌面，体验也不会好。对我来说，这就是主要区别。明白了，我现在运行着一个 Herder 绘画，在这个绘画里，左上角你能看到有 Spaces，这个我待会儿再讲。它基本上就是 Herder 里的工作区，你可以用它来组织工作、不同的项目等等。
左下角是 Agents，这是 Herder 的一个优点，它理解 Agent 是什么。以前的终端附用器像 T Max 和 Zalish，他们不太理解 agent，他们理解你的终端窗口、标签页和面板，但不知道 agent 是什么。但 Herder 知道我这儿有个 P agent 正在工作，这个工作状态基本上告诉我，我不用盯着他看，他还在干活，不是在等我，这非常有用。
对，在这个 Herder 里，我用它来组织我的 agent。让我能在所有正在进行的绘画之间导航，这就是我喜欢它的地方。但大多数时候，我只在一个绘画里工作，就是这个 first mate。这个工作流大概是几个月前形成的，那是我意识到自己一直在管理太多绘画。我觉得大家用 C Max 和其他编排类应用时也一样，为了完成更多工作，就得同时管理好几个并行的 agent 绘画。
对，对吧？因为一个 agent 干完活可能要花点时间，所以大家就开始多开几个绘画。我有时候看到有人开二十二十三十个绘画，但后来我简直要疯了。因为是啊，二十个绘画你得全记在脑子里，对吧？你得记住这个绘画是干嘛的，那个在做什么。对这种痛苦，促使我开发了 First Mate，因为我觉得这不可能是最终形态。
我不想一整天都在标签页之间切来切去，还得记着哪个是哪个。我开发 First Mate，是因为我觉得随着 AI 能力越来越强，他们应该能替我处理所有这些事情。我几个月前开始用这套设置做实验，结果真的可行。所以现在大多数时候，First Mate 是我唯一对话的 Agent。我只跟 First Mate 聊，让他替我管理所有其他绘画。
我可以举几个例子，你看，现在已经有事儿在发生了，对吧？他在做一些工作，告诉我无需操作。我现在想起之前有项工作进行到一半，就可以直接问，嘿。苹果审核通过我们这个 APP 了吗？那是我在开发的一个 iOS App 提交了 App Store 审核，我不确定通过了没有，就可以直接问 First Mate。
First mate 不会自己去查，他会把任务委派给另一个 crew mate。原因是，如果 first mate 亲自去查，那他自己就忙起来了，对吧？就被占住了，我就没法再跟 first mate 说话了。你看，现在 captain 我正在查这个，他已经叫另一个 crew mate 去帮我查了。好处是，我现在还能跟 first mate 说话。
他不会被别的事卡住，我可以再问点别的。我记得 Treehouse 有几个不错的 PR 等着我审查，你能查一下吗？所以 First Mate 能访问他负责的所有项目。对对，他是所有事情的协调者，知道我所有的项目。我后面也会聊到一些扩展性的问题，但基本上我大概有二十到三十个公开的 GitHub 仓库，都挺受欢迎的。
人们会给我提 issue 和 PR，如果要我手动去处理这二三十个项目，我肯定会疯掉。所以，我基本上让 First Mate 替我管理所有项目。所以，当我说 Treehouse，First Mate 就知道是哪个项目。我主要的问题是，你是怎么建立起足够的信任？把这么多责任都交给 first mate 的信任是需要时间建立的，对吧？
我一开始也不是什么都信任他，我最初是把他当原型来玩的，然后慢慢让他帮我做越来越多的事，同时观察他做的怎么样。刚开始的时候，尤其是最早那会儿，问题还挺多的，比如他没把任务分给合适的组员，或者让好几个组员做同一件事，互相冲突，诸如此类。我就不断优化这个过程，最后终于调到了一个很舒服的状态，可以直接让 First Mate 帮我处理所有这些事，而且再也看不到什么错误或者不合理的任务分配了。
所以现在他也启动了一个任务去审查 Treehouse 的一些 PR，然后我可以继续跟他聊别的任何我想做的事。还记得之前我们在优化 Firstmate 的工作区组织吗？现在进展到哪儿了？我就可以这样不停的问这些脑子里冒出来的事。现在这种感觉真的很好。我最享受的就是我始终处于一种大脑清空的模式，我有了想法。
就直接导给 First Mate，让他去处理剩下的一切，我完全不用操心他需要经过哪些步骤才能把事情做完。那你会不会进到具体的子 Agent 里，看看他们在做什么，还是基本不看？现在很少了。一开始开发 First Mate 的时候，我经常看，就是为了观察嘛，看他做的对不对。First Mate 的沟通效率高不高，有没有把上下文准确的传给组员？
所以早期我自己做了很多观察，但现在不怎么做了。不过有时候我还是会觉得，怎么搞了这么久，有点像在真实的公司、真实的团队里工作。有时候经理还是会直接去找下属，对吧？可能绕过技术主管，就因为有时候直接沟通效率更高。所以如果我想这么做，我可以在 Herd 里调出一个视图，这个视图基本上能让我跳到任何一个 Agent 绘画里，我直接跳过去就行。
这个很棒。然后看看那边到底在发生什么？对，这个非常非常好。对，你看这里。First Mate 回答了我上一个问题，这是一个很重要的设计节点，好吧？我前阵子跟 First Mate 讨论过一个想法，但我们没有继续往下实现，因为我对这个方案不太确定，总觉得哪里不对劲。我给你看个东西，像这种技术设计有时候会复杂，对吧？
牵扯的环节很多，有权衡，有优缺点，所以这种情况我通常会用 Levis 一个交互式的 HTML Artifact 来帮我更直观地理解这个想法和其中的权衡。我现在就试一下，你能用 Leverage 跟我一起审查一下 Her 的工作区的设计吗？这个操作会让 First Mate 创建一个 HTML Artifact，把我们面临的设计决策用可视化的方式呈现出来，这样我们协作起来会更容易。
对，他正在用 Leverage X 来做这件事。创建 artifact 可能需要一点时间。你刚才是在打字，但你一直是语音输入的坚定支持者。你什么时候用哪种方式？我现在几乎一直用语音输入。你看到我打字，是因为我前阵子发现，如果开语音输入，它会跟我的麦克风有冲突。这个问题我还没解决。但大多数时候，我发提示词都是用语音。
唯一的例外，要我说，就是需要复制粘贴网址、文件路径这类东西的时候，把这些念出来实在没什么意义。对对，那当然，现在他正在用 HTML 写设计审查，我们应该很快就能在浏览器里看到了。所以你现在是用 5.6 作为你的主 agent。为什么选它？对，五点六在 X I 上就是我的 first mate。关于 first mate，我学到的一点是，它需要处理大量的上下文，它得理清很多不同的事情。
比如我现在在说哪件事？当我说 Herder 工作区试图设计时，它得知道哦，我们前阵子做过这个，我指的是那个。所以 First Mate 其实需要很强的推理能力，他必须能理清所有这些复杂性。然后我对不同的组员有不同的规则。当 First Mate 给组员派任务时，他有一套我告诉他的偏好设置，他会用这些偏好来分配任务。
你看这个文件就是我写规则的地方。这些规则会告诉 First Mate 什么情况下该用哪个 Agent，用哪个模型，以及用多高的推理强度。之前这里有一条规则是，对于任何高复杂度的技术设计和产品设计，在 Cloud Code 里用 Fable。我觉得 Fable
有我很喜欢的深度和创造力。所以，对于那些非常复杂的设计，我喜欢用 Fable 当组员，但默认情况下，现在用的是五点六，纯粹是因为订阅方案的实用性考虑。
我可以给你看，我有个东西在追踪我的配额，我的 Grok 配额用完了，正在等重置。我这周的 Fable 配额也快用完了。离重置还早着呢，所以我在省着这剩下的飞博配额，留给那些我真正非常需要飞博才能做的事。我们订阅拿到的这些大模型配额根本就不够用，我觉得我会建议大模型公司认真考虑推出更高等级的套餐。对。
五百，因为现在两百美元这一档根本不够用。我完全同意，我知道这么说肯定有人不爱听，但我们确实需要五百美元那一档。对对，所以你从来不用 API 按量付费。对我觉得对个人来说，用 API 按量付费不划算。真要按 API 价格算，我过去一个月干的活儿费用肯定超过一万美元了。根本撑不住，我觉得还有一个办法，也许能帮上忙。
像 GPT 五点五、五点六，还有很多云端模型都有快速模式，对对吧？快速模式基本就是多花钱换低延迟。我想要的反而是反过来，我想要更慢但更便宜的模式。因为有太多任务是那种后台任务，我根本不关心它是不是很快完成，对吧？我关心的是我总共能干完多少活，因为现在我的总额度才是瓶颈，所以我希望他们最终能开发出这样的东西。
对这个需求肯定有不同的任务需要不同的工具和设置，对吧？比如你在赶一个东西。十分钟后有个非常重要的会，手头有上周的会议记录，那你需要快速模式。但如果你只是派一个 agent 跑一晚上，那你就需要最慢最慢的模式，你根本不在乎它每秒跑五个 token，你只希望它把活干完。对，就是这样。我觉得整个光谱，理想情况下，这些选项都应该给我们。
让我们自己去做取舍，这就要回到我之前问的那个关于 herder 怎么组织的问题了。先交代一下背景，这个想法是关于 first mate 怎么用 herder 来组织他的 crewmates。现在所有东西都像是一个扁平的列表，有时候很难搞清楚哪个 agent 干什么，所以就有人提出来能不能组织的更好一点。
你看这里，它基本就生成了这个设计评审 artifact，它给了一个推荐方案。不过我来带你过一下实际的提案。对，这就是我们现在的层级结构。它用了这种树状图，对吧？来给我展示这是什么？这非常有用。不然的话，我们通常只能在终端里跟 agent 讨论，然后 agent 就会打印出一大长串文字，对吧？对。但在这里，我就能很直观的看到，这是一个树状结构，这是它现在的样子。
Native now report tree 和 work tree 的层级，对不同的 work tree 会按代码仓库来分组。然后这里有一个推荐的架构，这个也很酷。Levish 能让 agent 直接生成一块白板，这是一块生态白板。我基本上可以直接看到所有的图表，我还能调整它。我可以直接说这里不对，然后把框移来移去，再把反馈发回给 agent。
在这些 artifact 上能做的交互非常多，这就是我特别喜欢用这种基于 Levis 的工作流的原因。到最后，它通常会指出我需要做的决定，它还有一些不确定的开放性问题。所以他给出了几种方案，对吧？我需要选定一种，我想优先考虑 supervisor 归属这个方案，因为按 supervisor 来分组逻辑会更顺。
这里上下文信息太多了，我可能不会在这上面花太多时间，但我会把这个决定标记出来，然后发回给 agent。就这样，基本上做这种决策的工作流就是这样。那核心问题就是像你说的。这些不同的项目上下文信息太多了，你都很熟，那你怎么还能做到那种深度工作？怎么还能进入心流状态而不被搞疯？就算有了这套设置，你还是可能同时开太多东西，然后就会想，哎，那个项目怎么样了？
那个 agent 又在干嘛？你是怎么做到深度工作的？大多数时候，你想想，我在这次绘画里花在 first mate 上的时间，基本都花在了那些模糊的决策上。所以，我并不是在不停的切换标签，或者担心黑那个活还在跑吗？那个是不是在等什么东西？这些事儿我不用操心。我唯一花时间的就是那些真正模糊的决策，那些真正需要我来判断的事儿。
所以，基本上我整天在做的，一个是把我的想法。全部交给 First Mate，所有我想做的事儿，我就直接告诉 First Mate 我想做，然后我就可以把它忘了。他要么会自己做完，要么会作为一个待决策的问题回到我面前。这是我做的一件事，就是把我所有的想法都告诉 First Mate。另一件事就是处理那些我必须做但 First Mate 自己决定不了的决策。
我其实给 First Mate 写了很多指令，告诉他什么时候应该回来找我，因为这一点要调对其实非常难。有时候我们会看到 agent 直接放飞自我，在你没盯着的时候自主干了一大堆事儿，到最后你才发现他做错了。我觉得这一点是我们真正需要去调整 agent 行为的地方，去找到那个最佳平衡点。而且每个人可能你对这个点的偏好会稍微有点不一样。
所以这是需要我们跟自己的 agent 好好聊透的一件事。用这套设置，你一般一天要跑多少 token？我倒没算过 token 数，我主要看的是我用掉了额度的百分之多少。明白了。现在我会尽量保持一个不错的平衡。你看到我把 Claude 的额度用光，而且用的比正常快很多，原因是 Anthropic 告诉我们，哦对，飞波要下线了。
是啊，我甚至公开说过他们，我说这是在玩什么幼稚游戏，要么就留着，要么就删掉，别搞这种每周延期，你懂吧？或者像 OpenAI 那样给我们存起来的重置次数，对吧？对，这样我们就能自己控制了。所以情况挺惨的，Cloud 额度快用完了。好像还有几个人进医院了，你看到那个新闻了吗？因为他们连续熬了两天，以为飞博要没了，结果直接进了重症监护室。
是啊，说到透明度，我觉得这是 Anthropic 一个很大的问题。他们每次跟开发者沟通，还有过去处理很多重大变动的方式，就是不够透明，也没给大家足够的确定性来做决定。这算是我随口吐槽一下。不过，我通常就用这个来盯着自己的额度，尽量保证消耗速度跟重置周期匹配好。用 OpenAI 的时候，我可以稍微激进一点，因为我有几次重置机会可以用，而且他们给的重置次数非常多。
但你没发现 GPT 五点六号特别烧额度吗？尤其是在 Extra High 或 Ultra 模式下，至少头一两天或者头二十四到四十八小时是这样。这里面有几个原因：头几天 OpenAI 出了个错，他们把五点六的上下文窗口压缩阈值调到了三七二 K token。对吧？后来他们发现，任何超过二七二k token的请求都会被多收费哦，所以很多人token消耗的比正常快。
他们为此做了一次重置，所以我觉得他们正在修。但这是大家觉得五点六烧token比以前快的原因之一。另一个有意思的点是，Ultra是个特例。对，我觉得Ultra和Claude的Ultra Code。对吧？对，他们不一定是一个推理努力级别，只是子 agent。他们是一个提示词，告诉 agent 要激进的使用子 agent，对吧？
去把任务分发出去。而且有一段时间，可能现在也还是这样。OpenAI Codex 在用 Ultra 的时候，会启动特别多的子 agent，而且每个子 agent 都是 Ultra agent，这烧 token 的速度就太快了。我觉得 X High 和 High 就很不一样。X High 不会让我的 Token 烧得那么快。
X High 其实是我的最佳选择，因为虽然它叫 X High，但速度其实相当快。好的，我们刚才聊到的那些提示词，通常返回结果都很快。哦，说到这个，昨天我正好跟一些人做了测试，我观察到他们在跑 5.6 Luna，我当时就想。怎么这么慢？他们切换到五点六兆 medium 之后，速度就快多了。所以我不知道 OpenAI 那边是什么情况，但现在 Luna 确实比骚慢。
对你知道为什么会这样吗？这里有个基准测试，我可以给你看，叫 DeepSweep。我猜你可能也见过这个吧，DeepSweep，这大概是我目前最信任的基准测试了。对，因为它没被污染，它足够新，训练数据里还没有这个，所以也许最终它也需要更新。但现在我非常信任它。你可以看到这里有几个很有意思的异常值，看 Sonnet 五从 Low、Medium、High 一直到 F High，它的曲线都挺合理的。
对吧？这张图是左边更贵，上边更智能，所以右上角是最好的 Sonnet 五一直到 F High 都很合理。但如果你开到 Max，你看它就疯了。它是所有模型里最贵的，Sunny
物比飞博还贵。对，所以我觉得出现这种情况的原因是，当模型本身不够聪明的时候，它就会浪费大量计算周期去做错误的事情。尤其是你让它做 Max Reasoning 的时候，它会非常努力地思考，但还是不够聪明去解决问题，所以它只会浪费大量时间和 token。
我觉得 Luna 也是一样的情况。Luna 的独特之处在于它的曲线非常陡峭，意思是它从非常非常低的智能一直延伸到非常高的智能。所以我觉得 Luna 很可能也有类似的情况，就是你让它去解决一个难题，它解决不了，但会浪费大量 token 去尝试。对我观察到的正是这样，它会做太多工具调用来完成一件相对简单的事儿，然后五点六兆用 Medium 大概一分钟就搞定了。
没错，所以我现在这场任务基本只用 SoA。我可以调整 Soi 的推理级别，对吧？我找不到什么理由去用 Terra，因为我能直接把 So 的推理级别调低。为什么要用 Terra 呢？这样我能用更低的成本得到一个更聪明的模型。不过我在某些情况下会用 Luna，比如在我的家庭助手上，我有一个家庭助手在运行我的房子，我可以控制灯光和所有东西、音乐播放器等等。
那个我用 Luna，因为它快，我需要它非常非常快。那为什么不用个开源模型来做这个呢？比如 Kimi 二点七 Code 在 Open Router 上用带 Neutral 后缀的版本，你可以跑到每秒两三百个 token。对对，开源模型的话有几种方式可以搞，一种是本地跑。其实我觉得像这种家庭助手的场景，我完全可以在我的 Mac Mini 上本地跑一个，效果应该也还不错，对吧？
但问题是我的 Mac Mini 现在是非常宝贵的资源，因为我所有其他事情都在 Mac Mini 上做。我有很多任务要跑，我构建 iOS 应用，做其他所有事情都会消耗 Mac mini 的算力。我把手机连到它上面，把所有东西都连到它上面，Mac mini 就像我的个人算力中心。有道理。如果我在上面跑一个开源模型，它就会跟我做的其他所有事情抢资源，所以这是一个限制。
我也可以通过云服务商来跑开源模型，对吧？但我发现省下来的那点成本还不足以让我真的从 Luna 这样的东西切换过去。明白了，对，所以到目前为止，我还没有真正深入去搞本地大模型和开源模型。那在 Agent Harness 方面，Pi 是你目前最喜欢的吗？对我现在用几个不同的 Harness，目前我在用 Pi，因为我今天主要在用 GPT 5.6。
因为配额的关系，但我现在的做法是：如果我用 Anthropic 的模型，我就用 Cloud Code，因为他们把其他都精了；如果我用 GPT 五点六，我就在 P I 里用。原因是 CodeS CLI 作为 Harness 不是那么好。它有一些优势，比如它开箱就集成了图像生成功能，这非常方便。但很多其他能力，比如管理后台进程就没那么好。
它缺少很多能让 C I I 体验真正顺滑的功能。跟 PI 比起来，PI 的可定制性非常高。是的，所以我想实现的任何东西，基本都可以自己写个插件来实现。这就是我选择用 PI 而不是 Codex 来跑 GPT 模型的主要原因。Grok 是我用的另一个模型，因为我已经订阅了 X，里面有一些配额。我其实觉得 Grok 4.5 非常好用。
是啊，但我在欧盟。所以你知道我用不了，因为它在欧盟被禁了。哦，好吧，那太可惜了。不过，对，这确实是个很不错的模型。我对 Grok 4.5 的看法是，它就像是开了快速模式的 Opus。我去，对它基本上能干 Opus 能干的任何事儿，而且速度超快。用 Grok 还有一个有意思的地方，尤其是在 Grok
Harness，也就是 Grok Build Harness 里，它好像会给你免费的 X API 访问权限，让你能读帖子和搜索东西。
哦，不然这些是要花钱的，因为 X API 是收费的。所以这是另一个好处，我可以用 Grok Build 来帮我搜推文、梳理新闻之类的。我觉得它也是进步最快的 Harness 之一。对吧？对对，完全同意。他还很年轻，对吧？他非常新，而且他们也是最近才开始认真对待这件事，但他已经在一些后台进程轮询等方面比 Codex 做得更好了。
明白了。那你还用其他 Agent Harness 吗？我也经常用 Open Code，Open Code 也很流畅，我很喜欢它的 TUI 体验。不过我觉得随着时间的推移，我开始越来越多的倾向于用 P I 了。因为 PI 可以更深度的定制，你几乎可以改变 PI 的每一个方面，我挺喜欢这点的。所以你非常看重可定制性，对吧？
那你觉得未来会不会有越来越多的人拥有自己的专属设置，而不是用那些预先定义好的打包好的应用？我觉得很可能会有不同的偏好光谱。我认为会发生的是，会有一群人，他们对事情该怎么做没有太多自己的主见，他们会去寻求别人的帮助，比如别人给他们一套验证过的打法。所以他们只想要一个开箱即用的东西，他们不想整天为捣鼓这些东西操心。
我觉得这类人会一直存在，这挺好的。人们会为他们开发工具并发布出来，这样他们就能直接用那些开箱即用的东西。还会有另一群人，他们会开始对事情该怎么做有越来越多的个人偏好。这些人就需要那些真正能被深度定制和不断进化的东西。我之前给你看了一个东西，就是我菜单栏上的那个配额小部件，还记得吗？记得这个东西，我叫它 Baby Menu，这是我自己做的。
而且它可以自我修改。你现在能看到它上面有一堆东西，这些功能绝不可能同时出现在一个产品里。有我的 GitHub 统计数据，对吧？还有 CPU 和内存占用，然后还有我的 Cloud 和 Codex 配额。没人会做一个这样的产品，然后卖给其他人。这是属于我自己的东西。至于我为什么把它弄成这样，我是通过跟 Baby Menu 对话来实现的。
Baby Menu 一开始是个空的东西，我告诉他我想要什么，它就会自我修改，然后慢慢变成现在这个样子。我认为这就是未来很多软件会呈现的一种形态，他们会提供一个开箱即用的合理的体验，但现在每个人都有 agent 了。所以每个人都应该能跟自己的 agent 对话，来定制他们使用的软件，而且还会出现很多自我修复的循环。
你知道，很多软件都会有一个方便报告 bug 的途径，然后就会启动一个像 code CLI 这样的东西去实现修复，再提交一个 PR，你再用像 code rabbit 这样的工具去审查它。这个 bug 可能二十分钟内就修好了，完全不需要人参与。对对，完全正确。还有一件很有意思的事情正在发生，就是 first mate first mate，基本上就是一个 agents。
点 md 文件，这个 agents 点 md 文件规定了 first mate 应该如何行动，如何在一大群 crew mate 之间协调不同的任务，这就像是给 first mate 的指令。它还有一些脚本文件，在这个 binary 文件夹里有一堆 bash 脚本，这些 bash 脚本基本上处理了很多 first mate 本来需要一步步去执行的确定性步骤。
把它们打包成 Bash 脚本，这样 First Mate 就不需要花 Token 去走完那些确定性步骤了。这样做的好处是 agents 点 md 和这些 bash 脚本都在当前目录下，所以 first mate 可以修改它们，对吧？有一件很有意思的事，我甚至都没意识到会发生，就是当 first mate 出了个 bug，导致它没法正确的做某件事时，它会自己绕过这个 bug。
所以现在这个软件几乎是不可阻挡的，你没办法阻止 first mate 去做它需要做的事。即使这些脚本里有各种各样的 bug，也顶多会让 First Mate 的效率变低一点，但不会阻止它继续工作。这和传统软件相比是一个非常大的变化，对吧？在传统软件里，如果有 bug，那就是个 bug，它可能会让应用崩溃，让你完全没法用下去。
但现在我们有了这种智能软件，它几乎总是很灵活，你很难写出一个能阻止它工作的 bug。所以基本上挑战就变成了我们人类在哪些环节拖慢了 agent 的速度。以及我们怎样才能把自己从尽可能多的环节中抽离出来，只参与那些真正重要的环节？对对，完全正确。关于你的这套配置，还有什么大家应该知道的吗？我觉得可能还有一点就是 no mistakes。
我经常遇到这种情况，让 AI 帮我生成代码，对吧？Fable 和五点六写代码非常快，质量也很高，能做很复杂的改动。但问题是，如果 AI 做了一个复杂的改动，我怎么知道能不能合并呢？对，我给你看一个真实的例子。我打开另一个项目 Hybrid，这是我给孩子们做的一个 AI Agent 的工具，让他们学着用 Agent。
我刚做了一堆改动，你看这个 diff 是我昨天用 Fable 改的。现在这些改动就放在这儿，我该怎么办？一行一行去审查这个 diff 吗？那太花时间了，对吧？我们的时间真的很有限。如果我去审查 AI 生成的代码，那我每天能完成的工作量就有上限了，对吧？基本上就取决于我每天能审查多少代码而不疯掉。所以现在我的做法是把这些改动全部发给 No Mistakes。
他会跑一套流程，做对抗性审查和验证之类的，然后给我一个结果，让我更容易判断代码有没有问题。我的操作就是输入 N M，这是 No Mistakes 的缩写，加一个 Y，意思就是把当前工作目录里所有的代码改动放到一个分支上，交给 No Mistakes 处理。我跑一下给你看，No
mistakes会创建一个分支，让 agent 帮我建分支做提交，把所有必要信息放进去，然后把这个分支推到一个本地 Git 代理里，在一个隔离的工作树里做验证。
我们一会儿就能看到。好，提交已经创建好了，这就是 No mistakes 的流程。它首先会分析意图，它理解意图的方式是去分析产生这次改动的 agent 会话。Agent 绘画就是我跟 Fable 一起做这次代码改动的地方，对吧？我在那里输入了提示，最初表达了我想做什么，所以第一步就是理解那个意图，因为那才是应该被遵守的真正需求。
是我说过我想要的东西。他理解了意图之后，会在最新的远程主分支上做一次变基，这样我们后面就不会遇到合并冲突。现在他正在做对抗性审查，这里他用的是 GPT 5.6 So 的中等模式来审查改动。如果发现了问题，非常明显的 bug，他会自动修复；不够明显的就会升级给我审批。如果涉及产品层面的影响，有时候我们发现一个 bug。
修复方案会要求改动产品本身，对吧？这种情况我是希望自己有发言权的。我设了一些规则，规定这种情况要升级给我。我们也许能看到它是会自动完成，还是会升级什么？基本上这个审查步骤会持续一段时间，它会抓住几乎所有边界情况、bug 和遗漏的东西。最后，在对抗性审查结束后，他还会做测试，测试会产生一些可见的证据，能真正告诉我代码确实按预期在运行。
然后是文档代码检查，接着他会推送 PR，并一直盯着 CI 流程，直到 PR 变绿，然后他会告诉我，好了，现在你可以去看看了。所以通常我启动 No Mistakes 之后，就不会再看这个界面了。我会走开去做别的事儿。现在我甚至都不自己启动 No Mistakes 了，我让 First May 去做，是 First May 在帮我启动这个。
总之，我觉得这个东西帮了我大忙，因为如果没有它，No Mistakes 抓到的所有问题都会让我的代码库变得一团糟。但在大型项目上，它不会烧掉太多额度、太多 Token 吗？这让我想起 Versail 的 DeepSeek，它会有很多警告，说如果你在大型代码库上跑这个，会烧掉几万美元的 API 额度，因为它挖得太深了。
你是怎么在审查次数和消耗之间做平衡的？对，好问题。我觉得有一个方面是追求质量必然有成本。你想想，一个软件团队，如果我们去掉人与人之间的代码审查流程，每个人都能更快的合并代码，对吧？但之后就会出现各种质量问题，生产环境会出各种事故，最终你还是得用另一种方式付出代价。对。所以这部分是不可避免的。我觉得我们得做个权衡，我们对某个项目的质量到底有多在意？
有些项目，比如周末搞个展示用的 demo。质量其实没那么重要，对吧？这种情况我们可能就不用跑这种很重的验证流程。但如果是做生产环境的软件，会影响很多用户，甚至有客户会因为体验被搞坏而停止付费，那我们就得小心了。所以我觉得在哪些项目上用这套方法是需要权衡的。另外，我也不会把每一个改动都送进这个流程。有时候我只是做个很简单的修复，对吧？
对，我很有信心，它不会搞出问题。我可以自己判断一下，说这个改动直接合就行。对，所以也有这种情况，但绝大多数改动还是会走这个流程。我可以给你看看我的数据，我有个 No Mistakes 的统计，我会追踪所有发给 No Mistakes 的改动。我设了一堆计数器，帮我了解这些改动的情况。这也是 AI 特别棒的一点，你可以衡量很多以前很难衡量的东西。
多亏了 Agentic Engineering，你可以开始追踪你工作的几乎一切。对，这点说的特别好。如果是人类。追踪起来就难多了。比如我有一百个人给我干活，我想知道他们做的每一件事，这很难，对吧？除非我是马克扎克伯格会把所有东西都录下来。但用 agent 的话，一切都可以自动化。我们可以统计所有东西，这真的很棒。
这就是我的 no mistakes 数据，大概是过去三个月左右的，总共一千个改动，跨五十九个仓库，其中百分之六十三的改动都被抓到了错误。那你觉得原因是什么？如果让你猜是流程的哪一部分最有效，是不同模型做的对抗性审查吗？对，你看这个哦，不错。对，按步骤看修复情况，审查这一步发现并修复了最多问题。我注意到好像是从 GPT 5.5 开始。
GPT 模型在抓边缘情况上变得特别强。我比较过几个模型，最喜欢用 GPT 做审查，它非常细致，特别擅长识别那些在罕见场景下可能发生但确实会发生的问题。所以 GPT 这种对抗性审查在抓这类问题上帮助巨大。另一个大头是文档，我经常发现我做了改动或者 agent 做了改动，但它不会去更新，比如 readme 文件里面还写着一些过时的内容，跟我们做的改动冲突，对吧？
这些情况全被这一步抓到了，真的很有用，非常好。看到这种高级配置，我想到一件事儿，就是我观众里有很多人把所有时间都花在搭环境上了，对吧？他们搞了一套超复杂的 agentic engineering 配置。但从来不发任何东西。你是怎么让自己保持理性的？比如，可能只花百分之十、二十的时间去改进配置、写脚本、搭系统，剩下的时间真的在用它们做产品。
对这个话题特别好，因为我自己几个月前也在这个问题上挣扎，所有事儿都要花时间。当我做东西遇到阻力时，我就想做个工具来消除这个阻力，但做工具本身又会占用我的时间，对吧？然后工具又会出问题，我又得去修。有那么一小段时间，大概一两周，我发现自己基本全在搞工具，没在做真正要做的东西。这个情况在我开始用 First Mate 之后改变了。
First made的好处是那些琐碎的事，比如修 bug，或者我遇到一个问题，只需要改进一下。我根本不用花什么时间，我只需要跟 First Mate 说，嘿，有个问题，他就会去修好。真正占用我时间的，会自然转向那些更有趣、更模糊的决策，这些往往是新产品开发。所以现在有了 First Mate 帮我处理这些琐事，我就有更多时间去做我真正想做的产品，比如 Habit 和我的 iOS App。
这是我开始用 First Mate 之后一个无心插柳但自然出现的结果。对。我喜欢你配置的一点就是看到很多东西其实是从真实问题里长出来的，这让人耳目一新。因为 AI 圈里有很大一部分人做事只是为了做而做。就像我把这个和那个连起来了，或者我搭了这么一套，看它多能跑，看它能跑多少个
agent。但这并不是从第一性原理出发，不是因为他们需要完成工作，就只是觉得哇，让这两百个 reagent 并行跑不是很酷吗？
但听你讲下来，我能看到每件事背后的理由。对对，这绝对就是我的做法。一开始我其实根本不想做这些工具。就在三个月前，我刚从大厂辞职出来单干。我本来的打算是做几个我觉得有潜力的C端应用，比如给小孩用的AI家教之类的。我有几个特别想做的点子，计划是把所有时间都花在开发这些应用上。单干和在大公司工作有个很有意思的区别。
在大公司有很多其他的瓶颈会拖慢你，你得花时间开会跟别人协调。我做到了比较高的级别，结果就是我所有的时间都花在告诉别人该做什么。而不是自己动手做，所以我现在单干用 Agent 来跑任务完成工作，就不会有这种瓶颈。单干的时候，除了你自己，没有别的瓶颈。所有事情的瓶颈都在我自己身上，在我自己的工作产出上。
于是我就开始遇到各种问题：怎么验证 AI 生成的代码？怎么跟 AI 更互动的做规划，而不是盯着终端里一长串的文本？怎么同时处理二三十个绘画而不疯掉？我开始碰到这些问题，然后就被迫去开发这些工具，因为没有别的办法能很好的解决它们。结果我好像一不小心就成了开源项目的维护者。现在我还得处理开源项目的问题和PR，这挺好的，能让工具变得更好。
但现在我得平衡我的时间了，到底花多少在开源维护上，花多少在我原本计划要做的那些应用上？明白了。好，问个宽泛的问题。你觉得哪些类型的软件会变，哪些会留下来？对，对，这个问题问的真好。我觉得有几个大趋势正在发生，一个是很多软件，特别是过去二十年里做的那些 SaaS 软件。大部分都是为人设计的，他们本质上就是一个给人用的界面，后面接个数据库，再配一套还算可扩展的系统来管理。
我觉得给人用的这部分界面基本会消失。我们其实不想自己去点遍所有网站，像 Salesforce 啊，还有那些 SaaS 网站。大多数时候，我们想让我们的 Agent 去跟这些服务打交道，而 Agent 需要一套不同的接口来工作。所以，我觉得这些服务会迎来一次重建，一次非常大的重建。让他们变得更无头，去掉给人用的那部分界面，或者说把给人用的界面改成让人能和 AI 协作完成任务的东西。
所以我觉得会有一场大重建。那些能给 Agent 提供非常好接口的软件，让 Agent 能非常高效的跟这些服务协作，我觉得这些会留下来。所以现在，如果我们想想新一代的类似 Git Hub 的东西，我觉得不管谁最终胜出，成为新的 Git Hub，都必须把这一点做好。它需要是一个 Agent 可以操作的无头服务，而不是一个需要人去点击浏览的网站。
那这具体是什么样的？是更好的文档，还是稳定的 API 模式？对 Agent 来说，真正重要的是什么？对。对这个也很有意思，我给你看个网站叫 x 点 md。其实这是我开始给 agent 做工具时才深入研究的东西。我发现很多工具，包括 mcp 服务器和 cli，人们开发出来，但并没有真正为 agent 优化过。
拿 mcp 服务器来说，我觉得很多公司还在学习怎么给 agent 开发真正好的接口。结果就是有些 mcp 服务器效率真的很低。GitHub，我可能要直接点名了。GitHub 的 MCP 服务器可能是市面上效率最低也最没必要的 MCP 服务器，因为 GitHub 本身就有很好的 CLI agent，用 GitHub CLI 就能完成大部分工作。
我们为什么还需要一个 MCP 服务器呢？我实际跑了很多基准测试，我看看能不能找到那个 GitHub 的基准测试，就在这儿。我跑了个基准测试来评估同样的任务。如果只改变接口，影响到底有多大？这里我们可以看到，如果我们用 Git Up CLI，这是 Git Up，衡量的是 Git Up 操作；如果用 Git Up CLI，这是平均成本。
如果用 MCP 服务器，有几个变体，不带工具搜索的，带工具搜索的，带代码模式的，但完成同样的工作，它总是比 CLI 更贵。这就是 GitHub 操作的情况。这些基于 MCP 的方法更慢，需要更多轮交互，消耗更多 token，在各方面都更差。GitHub CLI 优化的更好，也更好用。我想可能是因为它存在很久了，大模型的训练数据里已经有大量如何高效使用它的例子。
所以它本来就已经很好了。我觉得对 GitHub 操作来说，除了某些服务器之间的集成，基本没有理由去用 MCP CLI 的问题在于，市面上大多数 CLI 都是为人类开发场景设计的，对吧？是人在跑那些 CLI，所以我觉得。这里大概还有改进空间，于是我给 agent 开发了一批 CLI，并且开始真正提炼出几条原则，能让 CLI 对 agent 来说极其顺手。
我的证据就在这里，除了 GitHub 的基准测试，我还按照自己总结的对 agent 友好的 CLI 原则做了一个 exe，它甚至能比 GitHub CLI 更便宜，成功率也更高。这是一个例子。我还给 Chrome DevTools。做了一个，因为浏览器自动化也是一个非常非常普遍的用例，对吧？很多人用 agent 跑浏览器去做各种事情。
所以，我给几种常见的把浏览器连到 Agent 的方法都做了基准测试，有 Chrome DevTools MCP 服务器，这个很流行，还有 Agent Browser Dev Browser 类似这样的几个工具。我按照自己定义并不断迭代的那些原则做了一个 Chrome DevTools
Xy，遵循这些原则，我写了一个封装，这个 Chrome DevTools Xy 就是对 Chrome DevToolsMCP的封装，所以功能上没有任何区别。
它做所有事情的方式都一样，底层就是那个MCP服务器。我只是改了接口，现在它的效率就高得多了，平均成本降低了超过百分之二十，什么都没损失，延迟也改善了很多。这就是浏览器这个用力的情况。我真正提炼出来的原则一共有十条，我整理成了文档，大家都可以去 x 点 md
这个网站看，它就是一套公开的标准。第一条是用 token 效率高的输出格式，很多 MCP 服务器和 CLI 工具，他们用 JSON 来输出数据。
对吧？JSON 在你有别的东西需要按结构化方式解析数据时非常有用，但大语言模型 Agent 的不是那样解析数据的，对吧？他们只需要理解数据的内容和语义，所以用 token 效率高的输出格式，一上来就能省下大量 token。然后是尽量精简默认的 schema。有些 CLI 工具，你问他要一点数据，他会把每一列、每一个字段都给你吐出来。
类似这样的各种问题，我把它们整理成了一套原则，能让一个接口对 agent 来说真的很好用。靠着遵循这些原则，我就能持续做出封装和工具，让他们比原来的版本对 agent 更高效。我在这边发布了几个，这里也有一个目录。我有 GitHub XE Chrome Dev Tools XE，Lavish 本身也是一个 XE。
我最近还发布了一个 quota XE，可以把 agent 的配额数据暴露给你的 agent，这是为了让 First Mate 能聪明一点。别去用一个配额快用完的订阅里的 crewmate，然后社区也贡献了一堆 axi 了，有 npm scrolite，很多我们常用的工具都已经有了 axi 版本，所以我绝对推荐那些正卡在 token 效率瓶颈上的人，开始考虑用更高效的工具。
天哪，这太棒了！我要把我所有的软件都跑一遍这个。确保他们是 agent 的原生的，对这个我能聊上几个小时。让我从产品层面问一下，我觉得咱俩大概都同意，很快百分之九十九点九的软件和工具都会是 agent 在用。再说一遍，我们会跟自己的主 agent 对话，不管我们给他起什么名字。对，为什么还有那么多人没意识到这点？
因为还有很多人他们关注的还是我要做一个给人用的原生网页界面。他们完全不去想后端，完全不去想命令行。你是在哪个瞬间意识到 agent 会运行所有软件，而我们只需要跟自己的主 agent 对话就行了？这个问题问得好，我觉得这其实是一个学习曲线的问题。每次出现新的技术变革，我们都会看到同样的规律。历次工业革命都是这样，对吧？
蒸汽机刚出来的时候，电力刚出来的时候，互联网刚兴起的时候，一开始总是只有一小批早期采用者，他们就是纯粹喜欢捣鼓，对吧？就是喜欢玩技术，哪怕这技术暂时还看不到回报。我觉得我们现在就处在这个阶段。很多领域的捣鼓确实还看不到回报，还有很多遗留项目，AI 能帮的忙很有限。它确实能帮上一点，但提升幅度远不如从零开始的新项目那么大，对吧？
所以那些领域的人试了 AI 之后，会觉得哦，好像也没那么有用，我干嘛要花功夫去认真用呢？这些想法是有道理的。但这也解释了为什么早期采用者通常都是那些纯粹为了玩而玩技术的捣鼓者。但正是这些人会摸索出真正管用的东西，正是这些人会摸索出工具，找出差距，找到真正能从新技术中获益的工作方式。然后，这些人会开始把这些工具和产品分享给别人。
这需要时间。早期采用者要真正证明某个东西好用，需要时间。他们要把这些经验提炼成别人也能用的好工具，需要时间。别人要被新工具说服，开始花时间去用，也需要时间。所以这一切都需要时间。我觉得指望一夜之间所有人都意识到同一件事，AI 来了，一切都会这样改变，这不现实。我觉得每个人处境不同，各自的约束条件、每天做的事儿、手头的项目等等，都会决定他们什么时候跨过那个拐点才最合适。
我觉得用这个观点来收尾太棒了。Kun，我完全同意，非常感谢你抽出时间。大家主要应该去关注哪些东西？可以去看看我的 GitHub 上面列了很多我开发和分享的工具，我基本上把所有东西都开源了。我工作流里所有帮我提高效率的东西都已经分享在我的 GitHub 仓库里了。我还有一个 YouTube 频道，做了一些视频完整展示我是怎么编程的，怎么用我开发的工具来高效构建新东西，这些也是很好的资源。
这几个可能是比较好的起点。如果你在用这些工具时遇到问题，或者有关于怎么更高效使用 Agent 的问题，我还有一个 Discord 频道，Discord 服务器那里有一个很棒的社区，大家互相帮助，非常热心。我也经常去那里跟大家讨论。太好了，我会把所有这些链接放在下面。好，好，谢谢你邀请我来，David。
彼此，彼此，彼此。