让它真正奏效的地方在于，Claude Code 能接触到工程师在终端上能做的一切。你能做的一切，Claude Code 都能做。中间没有任何隔阂。实际上，Anthropic 内部有越来越多的人在消耗大量额度，每月花费甚至超过一千美元。 我们看到了这种重度用户的行为。这是 YC 会教的东西：如果你能解决自己的问题，那么你很可能也在解决别人的问题。产品领域有一个非常古老的概念，叫做 latent demand。你构建产品时要让它可被 hack，要足够开放，以至于人们能把它用在原本并非为之设计的场景上；而你正是为此去构建它，因为你内心知道那里有需求。你认为 CLI 是最终的形态吗？ 一年后或三年后，我们主要还会在 CLI 中使用 Claude Code 吗？还是说会有更好的形态？
本期播客由 Google 赞助。大家好，我是 Omar，Google DeepMind 的产品与设计负责人。我们刚刚在 AI Studio 推出了全新的 vibe coding 体验，让你能够混合搭配各种 AI 能力，以前所未有的速度将想法变为现实。只需描述你的应用，Gemini 就会自动为你连接合适的模型和 API。如果你需要灵感，点击 "I'm feeling lucky"，我们会帮你起步。访问 a.studio/bild、studio/build 来创建你的第一个应用。
Cat、Boris，非常感谢你们来参与。谢谢邀请。是啊。嗯，对于不认识你们的人来说，你们是 Claude Code 的创造者。我发自内心地感谢你们。我非常喜欢 Claude Code。很高兴听到你这么说。 这正是我们想听到的。嗯，我想从我第一次使用它的时候开始说起。有那么一个时刻，我想大概是 Sonnet 3.7 发布前后，我用了之后就觉得："天哪，这完全是一个新范式，是一种全新的代码思考方式。"
而最大的不同在于，你们彻底做绝了，直接取消了文本编辑器，你所做的就是对着终端说话，仅此而已。你知道，之前的 AI 编程范式，以前的工具都是：你有一个文本编辑器，旁边有个 AI，有点像这样，或者是 tab 补全。所以，跟我讲讲那个决策过程，或者说架构这个新范式的过程。你们当时是怎么想的？是的，我认为最重要的一点是，这根本不是有意为之的。 好吧。我们算是误打误撞做出来的。当时我在加入 Anthropic 的时候，我们还在不同的团队。Claude Code 之前有个前身，叫做 Clyde，就像 CLI 版 Claude。那是个研究项目，启动要花一分钟，是个很重的 Python 项目，需要运行一堆索引之类的东西。我刚加入的时候想提交我的第一个 PR，就像新手一样手写代码，我完全不知道这些工具。谢谢你承认这一点。我当时不懂这些，提交了 PR，然后 Adam Wolf——他当时是我们团队一段时间的主管，也是带我熟悉环境的伙伴——直接拒绝了我的 PR，他说："你这是手写的？你在干嘛？ 用 Claude Code。" 因为他当时也在大力折腾 Claude Code。于是我试了 Claude Code，给了它任务描述，然后它一次就搞定了。当时还是 Sonnet 3.5。所以即使是这种基础任务，我还是得修点东西，而且那个工具链非常老旧，花了大概五分钟才跑出结果，慢得要死。但它确实管用，我当时就震惊了，这竟然可行。这让我开始思考：也许其实你并不需要 IDE。后来我在用 Anthropic API 做原型开发，最简单的方式就是在终端里做个小应用，这样就不用构建 UI 什么的了。我一开始只是做了一个小聊天应用，然后我开始想，也许我们可以做点像 Clyde 那样的东西。于是我就试着搭了一个简化版 Clyde，结果它实际上远比那更有用，而且没花多少功夫。对我来说最大的顿悟时刻是，当我们开始给模型工具时，它就开始使用工具了。那是一个疯狂的时刻。模型就是想要使用工具。我们给了它 bash，它就开始用 bash，写 AppleScript 来自动化各种东西，以响应问题。我当时觉得，这太疯狂了，我从未见过这样的东西。因为那时我只用过 IDE 里那种文本编辑，一点单行补全、多行补全什么的。所以这就是它的由来。这是一种融合：既是原型开发，也是在一种非常粗糙的方式中看到了可能性。嗯，这个东西最终出奇地好用。我想对我们来说也是一样。对我来说，那个神奇时刻大概是在 Sonnet 3 或 Opus 4 的时候。我当时想："天哪，这东西真的能用。"
这很有趣。跟我讲讲那个关于工具的时刻，因为我认为 Claude Code 的特别之处之一就是它直接写 bash，而且写得很好。我觉得很多之前的 agent 架构，甚至今天任何做 agent 的人，你的第一反应可能是：好，我们要给它一个找文件的工具，再给它一个打开文件的工具，你为 agent 可能需要的所有不同动作构建各种自定义包装器。但 Claude Code 直接用 bash，而且用得很好。所以你们从中学到了什么？你们是怎么看待这一点的？是的，我觉得现在的 Claude Code 其实有一堆工具，大概有一打左右。我们基本上每周都在添加或移除工具，所以变化很频繁。不过今天确实有一个搜索工具。我们这么做有两个原因。一是 UX，这样我们可以把结果展示得更友好一些，因为目前大多数任务仍然有 human in the loop。第二是为了权限。比如说，如果你在 Claude Code 的 settings.json 里写了这个文件不能读，我们就得强制执行。我们对 bash 也会强制执行，但如果有一个专门的搜索工具，我们可以更高效地做到这一点。但我们肯定希望能 unship 一些工具，尽量让模型这边保持简单。比如上周或两周前，我们 unshipped OS tool。过去我们需要它，但后来我们实际上构建了一种方式，能在 bash 里强制执行这种权限系统。所以在 Bash 里，如果我们知道你不允许读取某个目录，Claude 就不能 OS 那个目录。既然我们能一致地强制执行这一点，就不再需要这个工具了。这很好，因为 Claude 的选择少了一点，上下文里的东西也少了一点。明白了。你们团队在职责上是怎么分工的？我想说，Boris 负责设定技术方向，而且我们推出的很多功能，他都是产品层面的远见者。我把自己看作更多是一个支持性的角色，确保我们的定价和打包方案能够打动用户。嗯，第二件事是确保我们引导所有功能完成上线流程。从决定“好了，这些原型我们肯定要内部试用（ant food）”，到设定内部试用（ant fooding）的质量门槛，再到向最终用户传达。而且我们确实在推进一些新项目。要我说，历史上 Cloud Code 很多功能都是自下而上构建的——Boris 和很多核心团队成员就曾提出过待办清单、子代理（sub agents）、hooks 等很棒的想法，这些都是自下而上产生的。当我们考虑扩展到更多服务，并把 Cloud Code 带到更多场景时，我觉得很多工作更像是：好，我们去和客户聊聊，让工程师参与这些对话，优先推进这些服务并把它们搞定。明白了。什么是 ant fooding？哦，ant fooding 就是 dogfooding（内部试用）的意思。 所以——
Anthropic 的 ant。我明白了。对，我们内部员工的昵称是 ant。所以 ant fooding 就是我们版本的 dogfooding。在内部，我想有 70% 到 80% 的 ants，也就是 Anthropic 的技术员工，每天都在使用 Cloud Code。所以每次我们考虑新功能时，都会先推给内部人员，然后收到大量反馈。我们有一个反馈频道，我想每五分钟就会有一条帖子。所以你很快就能得到信号：大家是否喜欢、有没有 bug，或者是不是不行，我们应该下架（unship）。你能看出来，构建产品的人一直在用它来做东西。因为如果你自己也在构建东西，你就会觉得它的交互设计非常合理，而这只有在你也在 ant fooding 的时候才会发生。嗯，对。我觉得这是一种非常有趣的构建新东西的模式，就是那种自下而上的、为自己做点什么的方式。跟我讲讲这个。是的。而且 Cat 也非常谦虚。我觉得 Cat 在产品方向上也起了很大作用。就像团队里的每个人都会参与，这些具体的例子其实都来自团队里的每个人——待办清单和子代理是 Sid 做的，hooks 是 Dixon 做的，plugins 是 Daisy 做的。所以团队里的每个人都会提想法。我觉得对我们来说，我们先构建这个核心代理循环和核心体验，然后团队里的每个人都在一直使用这个产品，团队外的人也一直用。所以有很多机会去构建满足这些需求的东西。比如说 bash 模式，就是那个感叹号，你可以直接输入 bash 命令。就在好几个月前，我当时在用 Cloud Code，在两个终端之间来回切换，觉得有点烦。然后一时兴起，我让团队想想办法，他们就想到这个感叹号 bash 模式。然后我说，太好了，做成粉色的，然后发版。 就这么做了。而这个功能就一直保留了下来。而且现在你看，其他人也开始跟风了。这真有意思。我其实不知道这个。这太有用了，因为我以前总得新开一个标签页来跑 bash 命令。所以你只要打个感叹号，它就直接运行了，不用经过 Cloud 那一套流程。对，而且 Cloud Code 能看到完整输出。有意思。太完美了。所以你在 Cloud Code 视图里看到的任何东西，Cloud Code 也能看到。好的，这很有趣。这也是我们一直在思考的 UX 问题。过去工具是为工程师打造的，但现在工程师和模型是同等重要的用户。所以作为工程师，你能看到输出，但这其实对模型也很有用。这也是我们理念的一部分：所有东西都是双重用途（dual use）的。比如说，模型也能调用 slash 命令。比如我有一个 slash commit 命令，我会走几个步骤，比如 diff、生成合理的 commit message 之类的。我可以手动运行，但 Claude 也能帮我跑。这很有用，因为我们可以共享这套逻辑。我们可以定义这个工具，然后双方都能用。设计双重用途的工具和设计只给其中一方用的工具，有什么区别？出乎意料的是，没有区别。好的。嗯。我感觉这种对人类来说优雅的设计，对模型也适用得很好。所以你只需要考虑什么对你自己来说合理，而通常对你合理的东西，对模型也合理。对。我觉得 Cloud Code 一个很酷的地方在于它是一个终端 UI，这让它工作得非常好，因为 Cloud Code 能接触到工程师在终端上做的一切。我觉得在工具是否应该双重用途这件事上，让它们双重用途实际上让工具更容易理解。这意味着：你能做的一切，Cloud Code 都能做。中间没有任何隔阂。对，这很有意思。有几个这样的决定。嗯，没有专门的代码编辑器，它就在终端里，所以能访问你的文件。而且它就在你的电脑上，而不是在云端虚拟机里。所以你可以反复使用，可以慢慢构建你的 cloud MD 文件，或者构建各种 slash 命令之类的东西，让它从一个非常简单的起点变得可组合（composable）、可扩展。[哼声] 我很好奇你怎么看这个问题：对于那些想构建 agent 的人来说，他们可能做的不是 Cloud Code，而是别的东西，怎样才能从一个简单的包开始，随着时间推移不断扩展，变得非常强大。对我来说，我一开始就像开发任何产品一样思考：你必须先为自己解决问题，然后才能为别人解决。就像 YC 教的那样：你必须从自己开始。如果你能解决自己的问题，那么你很可能也在解决别人的问题。我觉得写代码从本地开始是合理的。现在我们在网页上也有了 Cloud Code。所以你也能配合虚拟机使用，或者在远程环境中使用。这在你外出时超级有用，你想在手机上使用。这是我们一步一步验证出来的。你可以在 GitHub 里用 @cloud，我每天都在用，比如上班路上等红灯的时候——我可能不该这么做——但我会在等红灯时刷 GitHub，然后 @Claude，比如说修复这个问题之类的。所以能用手机控制它真的很有用，这也验证了这种体验。我不确定这是否适用于所有场景。写代码的话，我觉得从本地开始是对的。但我不确定这对所有事情都成立。明白了。你们都用哪些 slash 命令？
Slash commit。对，我觉得 commit 命令能让 Claude 更快知道该运行哪些 bash 命令来完成一次提交。那个 prit 斜杠命令对不熟悉的人来说是做什么的？哦，它只是告诉它具体如何生成一个 commit。好的。嗯，你可以动态地指定，比如说，这三个 bash 命令是需要运行的。明白了。而且很酷的一点是，我们在斜杠命令中内置了这种模板系统。所以我们实际上会预先运行 bash 命令，它们就像嵌入到斜杠命令里一样。嗯，你还可以预先允许某些工具调用。所以对于那个斜杠命令，我们会允许执行 git commit、git push、gh 等，这样运行斜杠命令后就不会被询问权限了，因为我们有一套基于权限的安全系统。嗯，另外它还用了 Haiku，这也很酷。嗯，这是一种更便宜、更快的模型。嗯，对我来说，我经常用 commit、commit PR、feature dev 这些。Sid 做了这个，挺酷的。它会一步步引导你构建某个东西。所以我们提示 Claude，让它先问我到底想做什么，比如制定 specification。然后，嗯，制定一个详细的计划，再列一个待办清单，一步步执行。所以这更像是结构化的功能开发。然后我觉得最后一个我们可能经常用的是，我们对所有 PR 做 security review，还有 code review。嗯，在 Anthropic 内部，Claude 负责做我们所有的 code review。嗯，你知道，最终还是要有人类来批准，但 Claude 会先做 code review 的第一步。这就是一个 /code review 命令。明白了。对。我想深入聊聊的是，如何制定一个好的计划？就是 feature dev 这件事，因为我觉得有很多小技巧是我开始发现的，或者说各个初创公司开始发现的有效方法，我很好奇我们漏掉了哪些。比如说，在计划制定过程中有一个反直觉的步骤：即使我并不完全清楚要构建的东西到底是什么，脑子里只有一句话，比如“我想要功能 X”，我就让 Claude 直接去实现，不给他任何其他信息，然后我看它会怎么做。这帮我理解，哦，原来我实际想要的是这个，因为它犯了各种错，或者说它做了我没预料到的事。然后我就从这种“用完即弃”的开发中学习，把它清空，这帮我为实际的功能开发写出更好的计划规格书。这在以前是你绝对不会做的事，因为还没写规格书就贸然派一个工程师去做一个功能，成本太高了。但因为有 Claude 在代码库里遍历并执行操作，你就能从中学到东西，这有助于你制定实际的计划。对。我想也许我可以先说说，我也很好奇你是怎么用的。我觉得对我来说可能有几种不同的模式，一种是原型模式。就像传统的工程原型开发，你想构建最简单的东西，让它触及所有系统，只是为了对所有系统有一个模糊的概念，看看哪里有未知因素，然后把整个流程走一遍。嗯，所以我跟 Dan 你做的完全一样，Claude 直接去做，然后我看它哪里搞砸了，再让它扔掉重来。就是按两下 escape，回到之前的 checkpoint，然后再试一次。我觉得还有另外两种任务。一种是 Claude 能一次性完成的事，我很有信心它能做好。所以我就告诉它，然后切换到另一个标签页，按 shift-tab 自动接受，接着去做别的事，或者去照顾我的另一个 Claude 实例，让它在那边运行。嗯，但还有一种是更难的功能开发。这些可能是过去要花几个小时的工程时间的事，这种我通常会按 shift-tab 进入 plan mode，先对齐计划，然后再让它写代码。嗯，我觉得这当中真正困难的是边界随着每个模型都在变化，而且变化方式还挺出人意料的——新模型更聪明了，所以你需要 plan mode 的边界就往后推了一些。就像以前你需要做计划，现在不需要了。我觉得这是一个总体趋势：以前更先进的模型需要搭脚手架的东西，现在被推进到模型本身里了，模型似乎会逐渐吞并一切。对。你怎么看待构建一个 agent harness，避免花大量时间搭建那些三个月后新 Claude 出来就会被吸收进模型的东西？就是说，你怎么判断该做什么、不该做什么？对于那些现在还不完全好用，但下次就能用了的东西，你会直接说“先不在这上面花时间”吗？我觉得我们会做所有我们认为能提升 Claude Code 能力的东西，即使这意味着三个月后我们得把它删掉。甚至恰恰相反，我们希望三个月后就能把它删掉。我觉得目前，我们只想提供尽可能高端的体验，所以我们不太担心这些工作日后会被废弃。有意思。对。一个例子就是 plan mode 本身。我觉得等 Claude 能从你的意图里直接判断出你可能想先制定计划的时候，我们大概率会在某个时候取消这个功能。嗯，或者比如说，我昨天刚从 system prompt 里删了大概 2000 个 token，因为 Sonnet 45 已经不需要了。但 Opus 41 确实需要。那另一种情况呢？最新的前沿模型不需要它了，但你想让它更高效，因为用户太多了，你不可能所有事都用 Opus 或 Sonnet 45。也许你会用 Haiku。所以这里有一个权衡：是为 Haiku 搭一个更复杂的 harness，还是干脆不花时间，用 Sonnet 承担成本，去做更前沿的事。总的来说，我们把 Claude Code 定位成一个非常高端的产品。所以，我们的核心目标是确保它在我们拥有的最强大模型上表现得极其出色，目前就是 Sonnet 45。嗯，我们也在研究如何让它在未来几代更小的模型上表现很好，但这目前不是我们的首要任务。好。你怎么看这件事？我注意到一点，我们经常能拿到模型——非常感谢——在模型发布前我们就能拿到很多，然后我们的任务就是判断它到底好不好。过去六个月里，当我在 Claude app 里测试 Claude 的新前沿模型时，其实很难立刻判断它是不是更好。嗯，但在 Claude Code 里就很容易判断，因为 harness 对模型输出的表现影响很大。而你们有在 Anthropic 内部构建 Claude Code 的优势，所以基础模型训练和你们构建的 harness 之间有更紧密的整合，而且它们似乎真的会相互影响。那这在内部是怎么运作的？这种紧密整合给你们带来了什么好处？是啊，我觉得最重要的是研究人员会直接使用它，这样他们就能看到什么管用、什么不管用，进而不断改进。我们会做大量 eval 来来回沟通，以准确了解模型当下的水平。不过确实，有一个 frontier，你必须给模型足够难的任务，才能真正逼出它的极限。如果不这样做，那所有模型看起来都差不多；但如果你给它相当难的任务，就能看出差别了。你用哪些 sub agent？我有几个。我用一个 planner sub agent，还有一个 code review sub agent。Code review 这块，我有时候用 sub agent，有时候用 slash command。一般在 CI 里用 slash command，但同步运行时，我会用 sub agent 来做同一件事。嗯……
嗯，这是个好问题。可能看个人喜好吧。我也不知道。我觉得，如果你在同步运行，把 context window 稍微 fork 出去一点会比较好，因为 code review 里发生的所有事情，跟我接下来要做的事并不相关。但在 CI 里，这就无所谓了。你有没有同时 spawn 过十几个 sub agent？用来做什么？对我来说，主要是做大迁移的时候。这是关键所在。其实我们有一个常用的 coder slash command，里面有一堆 sub agent。其中一步是找出所有问题：有一个 sub agent 负责检查 quadmd 合规性；另一个会翻查 git history，看看到底发生了什么；还有一个专门找明显的 bug。然后我们会做一个类似去重和质量筛选的步骤。它们会找出一堆东西，但很多是误报，所以接着我们会再 spawn 五六个 sub agent，专门负责检查误报。最后结果很棒，能找出所有真正的问题，同时过滤掉误报。这很棒。我其实也在这么做。我有个非技术类的 Cloud Code 使用场景，就是报销。比如我现在在旧金山，有一堆费用要处理。于是我在 Cloud Code 里搭了个小项目，用了一个金融 API，下载我所有的信用卡交易记录，然后判断哪些可能是需要我报销的费用。接着我启用两个 sub agent，一个代表我自己，一个代表公司，让它们博弈，找出真正该报销的费用集合。 就像一个是 auditor sub agent，一个是 pro-Dan sub agent。对，这种 opponent processor 模式看起来挺有意思的。是啊，确实很酷。sub agent 刚兴起的时候，我记得有个 Reddit 帖子给了我们灵感，有人做了几个 sub agent，比如 front-end dev、backend dev，好像还有个 designer。
testing dev，还有个 PM sub agent。这挺可爱的，感觉有点太拟人化了，但也许确实有道理。不过我觉得真正的价值在于 uncorrelated context windows——你有两个互不了解的 context window，这很有意思，而且这样通常能得到更好的结果。你呢？你有什么有意思的 sub agent 用法吗？我在捣鼓一个专门做 front-end testing 的 sub agent。它用 Playwright 去查看客户端有哪些报错，把这些拉进来，然后尝试测试应用的更多步骤。目前还没完全成熟，但我已经看到曙光了。我觉得这东西以后有可能打包进我们的某个插件市场。是啊，肯定的。我也用过类似的，不过是配合 Puppeteer，看着它构建完项目、打开浏览器，然后说“哦，这里要改”。那种感觉就像“天哪”。是啊，真的很酷。真的很酷。我觉得我们开始看到大规模 multi-agent、大规模 sub agent 的雏形了。我不知道他们是不是管这叫 swarms 之类的。Anthropic 内部其实有越来越多人每个月消耗大量额度，每个月花超过一千美元。而且这个人群占比增长得相当快。最常见的使用场景是 code migration。做法是比如从 framework A 迁到 framework B，主 agent 列出一个巨大的待办清单，然后对一堆 sub agent 做 map-reduce。所以你告诉 Claude：启动 10 个 agent，一次跑 10 个，把所有东西都迁移过去。有意思。你说的这种迁移，能举个具体例子吗？最经典的例子大概是 lint rules。就是你在推某种 lint rule，但它没有 autofixer，因为静态分析搞不定，太简单了。还有其他比如 framework migration，比如我们最近刚从一个测试框架迁到另一个。这种很常见，而且输出结果很容易验证。我发现有一件事，这既适用于各家内部的项目，也适用于开源项目。如果你是做产品的，想做一个别人已经做过的功能——比如 memory，怎么做 memory？因为我们内部有一堆不同的产品，你可以直接 spawn 几个 Cloud sub agent，去问“另外三个产品是怎么做的？”这就实现了某种隐性的代码共享，你不需要有 API，也不需要去问任何人，直接问“我们内部已经怎么做的了？”然后拿 best practices 来搭你自己的。开源项目也一样，有很多开源项目人家做 memory 做了一年了，做得非常好。你可以去看别人总结出了哪些 pattern，然后决定自己要实现哪些。完全同意。你还可以连上版本控制系统。如果你以前做过类似功能，Cloud Code 可以直接调用 API 查 GitHub，找到以前别人怎么实现的，读那段代码，然后把相关部分 copy 过来。是啊。那像 log files 这种东西，比如记录实现过程的完整历史，你觉得有用吗？需要把这些给 Claude 吗？你怎么让它变得有用？有人对此深信不疑。Anthropic 里有些同事，每做一项任务，都会让 Cloud Code 按特定格式写一篇 diary entry，记录它做了什么、尝试了哪些方法、为什么没成功。他们甚至还有一些 agent 会回顾这些 past memory，把它们提炼成 observations。我觉得这还只是萌芽阶段，其中有一些有趣的东西可以产品化。但这是我们观察到的一种有效的新兴模式。我认为，仅仅从一次对话记录中一次性生成记忆，难点在于很难判断某条具体指令对未来所有任务的相关性有多大。比如我们典型的例子是，如果我说“把这个按钮做成粉色”，我并不希望它记住以后要把所有按钮都做成粉色。所以我认为，从大量日志中综合提炼记忆，是一种能更稳定地发现这类模式的方法。看起来你可能需要这样：有些东西你能预判，可以用这种自上而下的方式去总结或综合，比如判断“这个以后会有用”，并且知道在什么抽象层次上它可能派上用场。但也有很多情况，比如任意一条 commit log——像“把按钮做成粉色”——它可能出于无数种不同的原因而有用，这些是你事先无法预知的。所以你也需要模型能够检索所有类似的过往 commit，并在恰当的时机呈现出来。你们是否也在考虑这方面？是的，我觉得可能会有类似的东西。也许可以把它看作那种传统的记忆存储工作，比如像 mex 之类的，你就是想把所有信息放进系统里，之后它就是个检索问题。对。我觉得随着模型变得越来越聪明，它自然也会开始这样做。我在 Sonnet 45 上也看到了这种自然表现：如果它卡住了，就会自发地开始查找，就像我们之前聊过的那样，自发使用 bash。所以它就会去翻 git 历史，然后觉得：“哦，好吧。是啊，这倒是个挺有意思的做法。”
录制前我们聊到的一件事是，我觉得我们在内部做的某件事真的改变了我们的工程方式，因为所有人都在用 cloud code 做构建，就像 CLI 构建一样。我们有一种工程范式，叫做 compounding engineering。在普通工程中，你每加一个功能，下一个功能就会更难加；而在 compounding engineering 中，你的目标是让下一个功能比刚加的这个更容易构建。我们的做法是，把构建这个过程中学到的所有东西固化下来。比如我们是怎么制定计划的，计划的哪些部分需要修改，或者开始测试时发现了什么问题，有哪些遗漏。然后把这些固化到所有 prompts、所有 sub agents 和所有 slash commands 里，这样下次有人做类似的事情时，它就能自动捕捉到，事情就变得更容易了。所以对我来说，比如我可以直接跳进我们的某个代码库就开始高效工作，即使我对代码怎么运作的一无所知，因为我们有一个积累下来的记忆系统，记录了我们实现过程中学到的所有东西，但这套系统是我们自己搭建的。我很好奇，你们是否在研究那种循环机制，让 cloud code 自动完成这件事？是的，我们已经开始在想了。有意思的是，Fiona 也跟我们说了同样的话。她刚加入团队，她是我们的经理，大概已经十年没写代码了。结果她第一天就成功提交了 PR。她说：“是啊，我不仅早就忘了怎么写代码，quad code 让我很容易重新上手，而且我也不需要再去熟悉任何上下文，因为我好像已经都知道了。”我觉得这很大程度上是因为，当人们在 quad code 本身上提交 pull request 时——我觉得我们的客户也告诉我们，他们经常做类似的事——如果看到错误，我就会说“@quad 把这个加到 quad MD 里”，这样下次它就自动知道了。你可以用多种方式来植入这种记忆。你可以说“@quad 把它加到 quadmd”，也可以说“@quad 写个测试”，这是确保不会回退的简单方法。而且我现在让人写测试也不会觉得不好意思了，对吧？因为超级简单。我觉得我们接近 100% 的测试都是 Quad 写的。如果写得不好，我们就不提交；好的就保留下来。另外，我觉得 lint rules 也很重要。对于那些经常要强制执行的东西，我们其实有一堆内部 lint rules，这些 100% 都是 Claude 写的。通常就是在 PR 里 @Claude 写一下这条 lint rule。对，现在的问题在于怎么让这个过程自动发生。总的来说，Cat 和我考虑这件事的方式是，我们先观察这种高级用户行为，第一步是通过让产品可 hack 来赋能他们，让最厉害的用户能自己想出这些很酷的新用法；但接下来真正困难的工作是，怎么把这东西带给其他所有人。对我来说，我一直把自己放在“其他人”那个群体里。你知道，我其实不太会用 Vim，也没有什么疯狂的 T-box 配置。我的设置非常基础。所以如果你做出来的功能连我都会用，那这基本就说明普通工程师也会用。这很有意思。跟我多讲讲这个，因为我一直在想这件事：怎么做出一个足够可扩展、足够灵活的东西，让高级用户能发现你做梦都想不到的新奇用法，但同时又足够简单，任何人都能上手，都能高效使用，而且你能把高级用户发现的东西反哺到基础体验里。你是怎么思考这类设计和产品决策的，才能让这种双重要求都得到满足？总的来说，我们认为每个工程环境都略有不同，所以我们系统的每个部分都可扩展，这点非常重要。从你的 status line，到添加自己的 slash commands，再到 hooks——它让你能在 quad code 的几乎任何步骤中插入一点确定性——我们认为这些都是我们提供给每位工程师去摆弄的基础构建块。至于 plugins，它其实是我们团队 Daisy 做的，是我们试图让普通用户——像我们这样的人——更容易把这些 slash commands 和 hooks 引入自己工作流的尝试。plugins 的功能是让你浏览现有的 MCP servers、现有的 hooks、现有的 slash commands，然后你只需要在 quad code 里写一条命令就能把它引入进来。产品领域有一个很古老的概念叫 latent demand，这可能是我个人思考产品和决定下一步该做什么的主要方式。这个想法超级简单：你把产品做得可 hack、足够开放，让人们能把它用在原本没打算设计的场景上，也就是“滥用”它。然后你观察人们怎么“滥用”它，再围绕这个去构建，因为你基本上能确定这里存在需求。我在 Meta 的时候，我们基本上所有大产品都是这么打造出来的。我觉得几乎每个大产品背后都藏着这种潜在需求的种子。比如 Facebook Dating，它的缘起是，我们发现查看用户资料时，大概 60% 的浏览发生在异性之间，而且通常不是好友关系，所以我们就想，如果我们推出一款约会产品，是不是就能把这种已存在的需求利用起来。这挺有意思的。
Marketplace 的情况也很类似。我记得当时 Facebook 群组里大概 40% 的帖子都是买卖帖。我就想，大家原来在用这个产品做交易啊。那我们只要围绕这个需求做一款产品，大概率就能成。所以我们现在的思路也差不多。不过我们还有个优势，就是我们是面向开发者做开发的。开发者就喜欢折腾东西，喜欢自己定制。作为我们自己产品的用户，这让我们做起来、用起来都特别有意思。就像我说的，我们只要搭好合适的扩展点，然后观察大家怎么用，就能知道下一步该做什么。比如，我们收到很多用户反馈，有人说：“哥们，Quad Code 在问我一大堆权限请求，但我正在外面买咖啡，根本不知道它在问我要权限。能不能让它直接给我发 Slack 通知？” 于是我们就做了 hooks。Dixon 做了 hooks，这样大家就能在 Slack 上收到提醒，而且任何你想在 Slack 上被提醒的事，都可以设成发 Slack。这其实就是大家特别想做某件事，但我们不想自己去做那个集成，所以我们就把 hooks 开放出来，让大家自己搞。这让我想到一件事。你们最近发布了一个新版本，或者说把 Cloud Code 的定位重新调整了一下，变成了一个更通用的 agent SDK。这是不是因为你们也看到了某种潜在需求，发现大家把它用在比原本更通用的场景里？我们意识到，就像你刚才说的，很多人把 Cloud Code 用在写代码以外的地方，我们也看到特别多这样的例子。我们收到大量反馈，说有人用 Cloud Code 来帮忙写博客、管理各种数据输入、用自己的语气先打一遍草稿。还有人拿它做邮件助手。我自己也用它做很多市场调研。因为它本质上就是一个 agent，只要你给它一个明确的任务，它就能一直跑下去，还能去抓取底层数据。比如我之前想做一个项目，想看看全球所有公司各有多少工程师，然后排个名。这件事 Quad Code 也能做，虽然它并不是传统的编程场景。所以我们意识到，底层的原语其实非常通用，只要你有一个能长时间持续运行的 agent loop，又能联网、写代码、运行代码，那说白了，你几乎可以用它搭任何东西。而且我觉得，到我们正式做品牌重塑、从 Quad Code SDK 改叫 Quad Agent SDK 的时候，已经有好几千家公司在用这个产品了，其中很多用法都跟写代码没关系。所以无论是内部还是外部，我们都看到了这个趋势。比如健康助手、金融分析师、法律助手之类的，范围非常广。对。最酷的用法有哪些？我记得你最近播客里请到了 Noah Brier，我觉得那个 Obsidian 思维导图和笔记管理的用法特别酷。有意思的是，用这个组合的人多得离谱。（笑）
这个特定组合。还有一些其他跟编程相关或者沾边的用法也挺酷的。比如我们给 Quad Code 自己做了一个 issue tracker。团队一直被海量的 issue 淹没，根本处理不过来。所以我就让 Quad 去重，它能自动找出重复的 issue，而且做得极其好。它还能做第一遍处理。通常有 issue 进来时，它会主动在内部提一个 PR，这是团队里 Enigo 新做的功能，挺酷的。还有值班（on call）的场景，从各处收集信号，比如拉取 Sentry 日志、BigQuery 日志，然后汇总整理。Quad 特别擅长干这个，因为说到底全是 bash 操作，对吧？所以这些都是我看到的一些内部使用场景。那在汇总日志或者处理 issue 的时候，是你有一些 Cloud 一直在后台持续运行吗？这是你们正在做的方向吗？那个场景是触发式的。每当有新 issue 提交时它就会被触发。所以它只运行一次，但可以根据需要运行任意长时间。明白了。那如果让 Cloud 一直运行呢？哇，proactive quads。我觉得这肯定是我们想达到的方向。不过要说现在，我们还是非常专注于把 Quad Code 在单个任务上的可靠性做到极致。你可以这么看：从多行自动补全，到单轮 agent，再到我们现在做的能完成任务的 Quad Code。如果你沿着这条曲线推演，最终一定会走向更高层次的抽象，也就是更复杂的任务。再往后 hopefully 下一步就是大幅提升生产力。比如它能理解你们团队的目标、你个人的目标，然后主动跟你说：“嘿，我觉得你可能想试试这个功能，这是第一版代码，以及我做的一些假设，你看看对不对？”
我都等不及了。而且我估计再下一步就是 Claude 当你老板了。（笑）
这不在计划里。（笑）
团队里所有人都特别兴奋我们今天能聊上，他们给我塞了一堆问题，我得确保都问到。哦，这个好：你们为什么在架构里选择 agentic RAG 而不是 vector search？vector embeddings 还重要吗？其实一开始我们确实用了 vector embeddings。但它们特别难维护，你得持续重新索引代码，而且索引可能会过时，你本地还有修改，这些都要同步进去。另外我们考虑到外部企业如果要采用这套方案会是什么体验，就发现这会带来更大的攻击面和安全隐患。而且我们发现 Cloud Code 本身很强，cloud models 在做 agentic search 方面也很强。所以用 agentic search 也能达到同样的准确度，但部署起来干净得多。这很有意思。如果你想在 Quad Code 里做语义搜索，可以通过 MCP tool 来实现。你可以自己维护索引，然后暴露一个 MCP tool 让 Quad Code 去调用，这样就行。你觉得跟 Cloud Code 搭配最棒的 MCP 有哪些？
Puppeteer 和 Playwright 肯定排得很靠前。确实。
Sentry 那个也很不错。Asana 的也很好。你认为 Anthropic 内部有没有什么高级用户技巧——或者其他组织里那些重度使用 Claude Code 的人在使用、但大众还不知道应该去用的？有一件事 Claude 不太会自发去做，但我个人发现非常有用：Claude 不太喜欢主动提问。不过，如果你是在和一个思想伙伴或合作者一起头脑风暴，通常你们会来回提问。所以这是我特别喜欢做的一件事，尤其是在 plan mode 里。我会直接告诉 Claude Code：“嘿，我们现在只是在头脑风暴这件事。如果你有什么不确定的，请尽管问我。”我会让它提问，它也确实会这么做。我觉得这实际上能帮助你得到更好的答案。其实还有很多技巧可以分享。我发现有几个非常常见的错误。一个是，就像你说的，没有充分使用 plan mode。这一点非常重要。我觉得这通常出现在刚接触 AI 编程的人身上。他们有点假设这东西什么都能做，但实际上不能。它今天还没有那么厉害，以后会越来越好，但现在它可能一次性搞定一些测试，却没法一次性搞定大部分事情。所以你得了解它的局限，得明白你什么时候该介入。像 plan mode 这种东西，如果你先敲定计划，它可以很轻松地让成功率提升两到三倍。另外，我发现高级用户做得很好的一个地方是，有些公司大规模部署了 Claude Code，现在这样的公司已经很多了，我们可以向他们学习。把 settings.json 提交到代码库里非常重要，因为你可以用它来预先允许某些命令，这样就不用每次都收到权限提示，也可以屏蔽某些命令。比如你不想用 web fetch 之类的功能。这样一来，作为工程师我不会被反复提示，而且我可以把它提交上去，和整个团队共享，所有人都能用。我是通过直接用 dangerous 模式跳过权限来解决这个问题的。
（笑）是的，我们内部其实也有这种情况，但我们不会推荐这么做。毕竟这是个模型，它可能会做出一些奇怪的事情。我觉得另一个很酷的用例是人们把 stop hooks 用在一些有趣的地方。stop hook 会在每次回合结束时运行。比如助手和一些工具来回调用了一阵，完成了，把控制权交还给用户，这时候我们就会运行 stop hook。所以你可以定义一个 stop hook，比如“如果测试没通过，就返回文本‘继续’”，本质上你可以让模型一直跑直到事情做完。这要是再结合 SDK 和这种程序化使用方式，效果简直不可思议。要知道，这是个随机性的东西，是非确定性的，但通过 scaffolding，你可以得到确定性的结果。你们开启了这种 CLI，这种 CLI 范式转变。你认为 CLI 是最终的形态吗？未来一年或三年里，我们主要会在 CLI 里使用 Claude Code 吗，还是会有更好的形态？我的意思是，它不是最终的形态，但我们非常专注于确保 CLI 能做到尽可能智能，并且尽可能可定制。你可以聊聊下一代形态。是啊，（笑）大家让我聊聊这个，因为没人知道，这东西发展得太快了，对吧？没人知道这些形态会是什么样。我觉得现在我们团队处于实验模式。我们有 CLI，然后推出了 IDE 扩展。现在我们有一个新的 IDE 扩展，更像 GUI，更容易上手一些。我们还有 Claude 和 GitHub 的集成，所以你可以在任何地方接入 Claude。现在还有 @Claude、网页版 Claude 和移动端 Claude，你可以在这些地方使用它。我们正处于实验模式，想弄清楚下一步是什么。我觉得如果拉远视角看看这玩意儿的走向，一个大趋势是更长时间的自主性。所以随着每一个新模型，我们会测试模型能自主运行多久，在容器里的 dangerous 模式下自动压缩上下文、持续运行直到任务完成。现在我们大概能达到两位数小时的级别。我记得上一个模型大概是 30 小时左右。下一个模型可能会是几天。当你考虑把模型并行化的时候，会衍生出一堆问题。比如，这个运行环境应该是什么样的容器？因为你肯定不想必须开着笔记本电脑。我现在就遇到这种情况，因为我在做很多 DSPy，我只听说过、读到过这东西，就是 DSPy，或者说 prompt optimization，它跑在我的笔记本上，我不想合上电脑。我现在就是这样，夹着个打开的笔记本，因为我不想合上它。是的。所以我觉得，一方面要摆脱这种模式，另一方面我觉得很快我们就会进入 Claude 监控 Claude 的阶段。是的。我不知道这种模式该用什么形态才好，因为作为人类，你需要能够检查它、看到发生了什么。但它同时也需要针对 Claude 做优化，优化 Claude 之间通信的带宽。所以我的预测是，终端不是最终形态。未来几个月，甚至一年左右，还会出现几种新的形态。而且变化会非常快。你怎么看？我在教很多订阅者使用 Claude Code。谢谢。不客气，帮你干活呢。（笑）我觉得有一点很重要，就是终端很吓人。就和订阅者通电话时说“我来教你怎么打开终端”，而且“即使你不是技术人员也可以这么做”，这本身就很了不起。（笑）你们怎么看待这个问题？是啊，我们营销团队里有个人开始用 Claude Code，因为她在写一些涉及 Claude Code 的内容。我跟她说你真的应该体验一下，结果她屏幕上弹出了大概 30 个窗口，要她接受各种权限，因为她以前从来没用过终端。所以我完全认同你的看法。对非工程师来说确实很难，而且我们发现有些工程师其实也不太习惯每天在终端里工作。我们的 VS Code GUI 扩展是朝这个方向迈出的第一步，因为你完全不用考虑终端，它就是一个带一堆按钮的传统界面。我想我们还在开发更多图形界面。网页版 Claude Code 是一个 GUI，我觉得那其实可能是技术背景较弱的人的一个不错的起点。是的，是的。大概几个月前，有过一个非常神奇的时刻。我走进办公室，Anthropic 的一些数据科学家就坐在 Quad Code 团队旁边，而那些数据科学家的电脑上正运行着 Quad Code。我当时就想：这是什么情况？你们怎么发现的？我记得 Brandon 是第一个这么做的，他说：“哦，我就是装了一下。我做这个产品，所以应该用它。”我当时就觉得：“我的天。”于是他搞懂了怎么用终端和 JS，要知道他以前其实没做过这类工作流。当然，他技术底子很强。所以我觉得，现在我们开始看到各种与代码相关的职能人员也在用 Quad Code。从潜在需求的角度来看，挺有意思的，这些人其实是在 hack 这个产品，说明大家有使用它的需求，所以我们希望把界面做得更易用一些；但同时，对 Quad Code 来说，我们专注为最优秀的工程师打造最好的产品，聚焦软件工程，想把这个做得特别好，同时也希望它是其他人可以 hack 的东西。有时 cloud code 写的代码会有点冗长。但你可以直接让它简化，它做得很好。有意思。那你是怎么做的、什么时候会这么做？是用 slash command，还是……
我就直接说。我就……
有时你会说：“嘿，这应该是个一行的改动。”结果它写了五行，你就说“简化一下”，它立刻就懂了你要什么，然后会改好。对。我们团队很多人也这么做。这挺有意思的。如果你经常这么说，那为什么不把它做成 slash command 或者集成到 harness 里之类的，让它自动触发呢？我们在 cloud MD 里确实有相关指令。但我觉得受影响的对话占比很低，不想因此朝另一个方向过度优化。而且不用 slash command 的原因是，其实你不需要那么多上下文。slash command 很适合那种本来需要写两三行字的场景；但像简化——甚至 plan mode 也是——你其实几个字就行，不过有时候 plan mode 确实需要两三行才能把需求完整表达清楚。而 simplify 的话，你写“simplify it”它就懂了。对，说得通。酷。嗯。好了，我们可以……（笑）这挺有意思的。不过这些东西感觉还处在非常早期的阶段。对。录音前我们聊到 adoption curve 的问题，感觉还是……
hian curve 还是什么（笑），不管那个术语叫什么了。没错。感觉我们还处在前 10% 的阶段，这些东西变化会非常快，而且会持续变下去。就连 Anthropic 外部那些重度使用 Quad Code 的研究人员，也会在这种事上卡住，比如没意识到可以直接让 LLM 简化。我觉得这说明，即使是对在这个行业里工作的人来说，他们也不总是意识到可以直接跟模型对话。问题在于，我觉得大家有种潜在的期待，认为使用 AI 不应该是一项技能，因为它就是听指令办事。但问题是，你说什么会影响它做什么，所以如果你能说得更好，结果就会更好。（笑）
对。但每次模型都在变，这才是难点。prompt engineer 曾经是一份工作，现在 famously 已经不是了。以后还会有更多这种“工作不再是工作”的情况，因为随着模型越来越好，它的解读能力越来越强，你就不用再去学这些使用它所需的微技能了。但我觉得这也体现了我们做这类产品时必须保持的一种谦逊：我们真的不知道接下来会发生什么，只能跟大家一起摸索，顺势而为。所以你们为自己打造产品是件很酷的事，我觉得这也是最好的方式，就像你们活在未来。我们自己也是这样，你一直用它，缺什么就很清楚，直接做下一件事就行，不用像这样：嗯，我去问问某家大公司的企业产品经理，你想要什么 AI 功能？对方说：不知道，就在我的 IDE 旁边放个小聊天机器人吧。你就只能：好吧。（笑）
对。做开发者工具最爽的一点就是自己就是用户，对吧。而且我觉得这在 AI 时代也是件很独特的事，因为 AI 重置了所有软件的棋盘。我们有 Kora，一个邮件助手；还有 Sparkle，用来整理文件。任何你在电脑上想做的事，如果你用 AI 来做，很有可能以前没人做过，因为整个格局都被重置了。所以现在是为自己做东西的一个独特而激动人心的时代。完全同意。我觉得这也彻底开放了竞技场。任何个人现在都可以为自己建一个应用来满足需求，然后分发给所有人。对，真的很酷。我一直在做各种随机的 pet project。我刚搬了新公寓，里面还是空的。于是我在基于 Cloud Agent SDK 做一个购物顾问助手，因为谁有时间去读所有评论、看所有选项、找价格呢？所有东西都很难发现。它就问我一堆问题，我告诉我想要什么，然后它给我展示一堆……
没错，然后它展示一堆不同沙发和选项的照片，还有网上的评价。然后我告诉它我不喜欢什么，真的感觉就像在跟购物助理一起工作。体验很酷。确实很酷。我还有个小邮件回复 agent，帮我起草回复，但我不怎么用邮件，所以……
哦，我就知道你回的不是本人。（笑）
所以才延迟了七天，agent 正在做非常彻底的工作。（笑）
对，不过 Cloud Agent SDK 很酷。对，Cloud Agent SDK 很酷。用小团队就能做出这么多东西，这种感觉总是很棒。对。所以，我觉得……
另一件很酷的事是，我觉得大家正在把思维从文档转向 demo。在内部，我们的硬通货其实是 demo。你想让别人对你的东西兴奋起来？那就给我们展示 15 秒它能做什么。我们发现团队里的每个人现在都有这种被灌输进去的……
确实是 demo 文化。我觉得这样更好，因为你脑子里可能装了很多东西，即便你是个非常出色的写作者，也许能想办法解释清楚，但即便如此，也还是很难解释明白。可要是别人能直接看见，他们立刻就能懂。我觉得这在产品构建中正在发生，在其他各种创意工作中也是一样，比如拍电影。以前你得去推介，但现在你可以直接说：我做了一个 Sora 视频，你看，你能隐约看到你想做的那个东西，而且成本很低。所以这意味着你不用花那么多时间去说服别人，直接说“看，我做出来了”就行。对。而且作为 builder，你可以直接做出来，然后不断重做（笑），直到满意为止。我觉得反过来说就是，以前你可能会写个文档，或者在白板上画一画，再不然就是在 Sketch、Figma 之类的工具里画点东西，而现在我们会直接 build，直到感觉对了为止。而且现在很容易就能找到那种感觉。我觉得以前你可以用视觉呈现，也可以用语言描述，但始终抓不住那个 vibe。而现在 vibe 很容易就能出来。对。而且你的 plan mode 做了三遍。对。就是这个原因。你做了一版，扔掉重做，再扔掉重做。或者说 Tudos 那边，Sid 做最初版本的时候也做了大概三四个原型，然后我可能在一天之内又做了大概 20 个版本。对，我觉得几乎我们发布的所有东西背后都有不少原型。那你是怎么跟踪并把从原型中学到的东西传递下去的呢？尤其是像，有时候一个人在做原型，然后你说“我来接手，我再做 20 个”。你怎么才能最大化从中获得的收获？这里面可能有几个要素。一个是 style guide。我们发现了一些风格层面的东西。我觉得很多像是为 terminal 做设计，或者说我们是在为 terminal 探索一种新的设计语言，边走边建立。其中一部分你可以把它沉淀在 style guide 里。这是我们的 quad MD，但还有另一部分，是某种 product sense，我觉得 model 现在还不太 get 到。也许我们应该想办法教 model 这种 product sense，比如什么可行，什么不可行。因为在产品设计上，你想用最简单的方式解决用户的问题，然后把除此之外的东西都删掉，把一切障碍清掉。你要让产品尽可能干净地对齐用户意图。而 model 可能还没完全理解这一点。对。它永远感受不到用 quad code 是什么感觉。model 自己不用 quad code。所以我觉得，如果 quad code 能自己测试自己，能自己使用自己就好了。我们在开发时其实就在做这件事，它能发现 UI bug 之类的东西。不过也许我们应该直接试试 prompt 它。说实话，很多东西就是这么简单。有新想法的时候，通常你直接 prompt 一下，往往就奏效了。也许我们应该试试这个。很多原型其实就是在试 UX 交互。所以我觉得一旦我们发现一个新的 UX 交互，比如 shift tab 用来做 auto accept，我觉得是 Boris 想出来的。其实是 Eigor。哦，Eigor。对，我们来回试了很久，看怎么融合进去。我们大概花了一周时间在做“对决式”原型（笑）。对，shift tab 的感觉特别好。然后现在 plan mode 的某一版迭代也用了 shift tab，因为这其实是另一种告诉 model 它该有多 agentic 的方式。所以我觉得随着越来越多功能使用同一种交互，你会对什么东西该放在哪里形成更强的 mental model。对。还有 thinking 也是一个很好的例子。最开始我们在发布 quad code 之前，或者可能是第一个 thinking model，是 3.7 吗？我忘了第一个是哪个了。对。它能思考了，我们就 brainstorm 怎么 toggle thinking。然后有人就说：如果你直接用自然语言让 model 思考，它就知道该怎么思考了。我们就说，好啊，就这么干（笑）。我们就那样做了一段时间，然后发现人们会不小心触发它。他们说了“don't think”，然后 model 就说：哦，我应该思考。它就开始思考了。所以我们得想办法把它过滤掉，让“don't think”不会触发它，但这样还是不够明显。后来我们做了一个 UX 改进，把 thinking 高亮出来。那真的很有趣，感觉很神奇。当你用 ultra think 的时候，它会像彩虹一样，之类的（笑）。然后到了 sonet 45，我们发现开启 extended thinking 后性能提升非常非常大，所以我们把它做得很容易 toggle，因为有时候你需要，有时候不需要。对于很简单的任务，你不想让 model 想五分钟，你只想让它直接做。所以我们用 tab 作为 toggle 的交互。然后我们拿掉了一堆 thinking 相关的词。不过我觉得我们保留了 ultra think，纯粹是 sentimental reasons（笑）。有意思。你觉得会不会出现某种新的指标，衡量你删掉了多少东西？我觉得程序员一直都觉得删掉一堆代码的感觉很好，但因为现在你能这么快把东西 build 出来，删掉东西也变得更重要了。我最喜欢看到的 diff 是红色 diff（笑）。每次看到我都觉得，太好了，再来一个，再来一个。但这很难，因为你发布的任何东西，用户都在用，你得让用户满意。所以总的来说，我们的原则是，如果我们 unship 某个功能，就得推出一个更好的，让用户能利用上，能更好地满足那个意图。这也回到了怎么衡量 quad code 及其影响的问题上，这是每家公司、每个客户都会问我们的。在 Anthropic 内部，我觉得我们从一月份以来规模大概翻了一番，但工程师的人均生产力却提高了将近 70%。怎么衡量的？我们确实衡量了，有几种方式，但 PR 是最简单也是最主要的一种。不过就像你说的，这并不能完全捕捉到，因为很多时候它让原型更容易做、让尝试新事物更容易、让那些你本来根本不会去尝试的东西变得可行，因为它们本来远低于那条门槛线。你发布一个功能，本来有一堆 wish list 上的东西，现在因为你直接都做了，因为它太容易了，而以前你根本不会去做。所以，这确实很难讲清楚。而另一方面，代码写得更多了，你就得删除更多代码，得更仔细地做 code review，而且要尽可能把 code review 自动化。这里还有一个有趣的新产品管理挑战：因为你发布的东西太多，产品最终反而会显得不够连贯——你可以这里加个按钮、那里加个标签页、再塞个小功能。也就是说，很容易就能做出一个拥有所有你想要的功能、却毫无组织原则的产品，因为你一直在不停地发版。我觉得我们在这方面还是比较自律的，会确保所有抽象层都很容易理解，哪怕用户只是听到功能的名称。我们有一条原则，我相信是 Boris 带到团队来的，我很喜欢：我们不希望用户有任何“新手上路”的体验。一切都应该足够直观，你直接上手就能用。我觉得这个标准把门槛拉得很高，要确保每个功能都非常直观。那你们是怎么在 conversational UI 里做到这一点的呢？因为如果没有一堆按钮和旋钮，一开始只有一个空文本框，你怎么让它变得直观？我们做了很多小事，比如教用户可以用问号来查看提示；quad code 运行时会显示提示；侧边栏有 change log；我们会告诉你，比如有新的 model 发布了；我们在底部还有一个关于 thinking 的通知区域。我觉得我们就是通过这些微妙的方式向用户介绍功能。另一件很重要的事是确保所有 primitives 都定义得非常清楚，比如 hooks 在开发者生态中有共识性的含义，plugins 也是如此。我们要确保我们构建的东西，和普通开发者听到这些词时立刻联想到的是一致的。还有 progressive disclosure 这一点。在 quad code 里，运行时你随时可以用 control O 查看完整的原始转录，也就是 model 看到的内容。但我们不会一开始就展示这个，只在真正相关的时候才出现——比如某个 tool result 被折叠了，我们就会提示可以用 control O 查看。我们不想在一开始就把太多复杂性抛给用户，因为这个东西几乎什么都能做。另外，我们最近刚开始探索一条新原则：让 model 来教你怎么使用它。你可以向 quad code 询问它自身，它会去查阅自己的文档来回答你。我们还可以做得更深，比如 slash commands 是人们可以使用的功能，但 model 也能调用 slash commands。也许当你看到 model 在调用它时，你就会想：哦，原来我也可以这么做。嗯嗯嗯，有意思。当初你们刚开始做这件事的时候，cloud code 更像是一个独一无二的存在，一种通过 CLI 使用 AI 的独特思路。虽然其他人也有类似的东西，但它感觉像是一个转折点。而现在整个行业都在做 CLI、CLI、CLI，这改变了你对构建产品的思考方式吗？改变了你构建时的感受吗？你又是如何应对这场竞赛带来的压力的？对我来说，被人模仿就是最好的赞赏。嗯。所以这挺棒的，看到其他所有人都在受此启发做各种东西，感觉很酷。我觉得这最终也是我们的目标——激励人们为这项即将到来的惊人技术去构建下一代产品。这真的很令人兴奋。就我个人而言，我不太用其他工具。所以通常有什么新东西出来时，我可能会试一下，找找感觉。但除此之外，我觉得我们还是相当专注于解决自己和客户遇到的问题，然后去构建下一步的东西。酷，太好了。呃，我也很喜欢访谈的这部分。我们回答完你团队的所有问题了吗？问题？哦，我们把我团队的问题都过完了吗？我看看。嗯，我觉得都过了。呃，我顺便也好奇你会怎么回答那个关于 unshipping 的问题，因为如果你们在做这种 AI-driven development，发布频率会很高，团队又小，运营负担很重。我问这个是因为我觉得我们在这件事上做得并不好。而且我有种感觉，有些产品因此变得有点乱。尤其是 Kora，它的功能覆盖面很广，能做很多不同的事。比如我们有邮件助手，你可以问它“告诉我我要去的旅行”，它就会遍历你所有邮件并总结行程。或者我们有个功能会自动归档那些你不需要立即回复的邮件。然后每天两次，你会收到一份简报，总结所有你可能需要看但不需要实际处理的内容，你浏览一遍就行。但这里面又有很多复杂性，比如邮件是怎么分类的？于是我们现在有一整个界面，里面有各种分类规则，你可以排序之类的，但这很复杂，也很难向用户解释。我想保留所有这些能力和灵活性，但又不能让用户看着屏幕一脸茫然：这到底是怎么回事？太复杂了。所以我一直在琢磨这些事。因此，这种“删除”、也就是 unshipping 的理念，感觉像是一个我们还没真正探索过的、有趣的文化原则。是的，这非常难。我觉得这里面还有社交成本，毕竟你很难去跟同事说，把你做的东西下线吧。这确实很棘手。不只是代码的事。对，说实话我绝对是在 Instagram 学到这点的，因为我觉得 Facebook 在 unshipping 上做得特别差，我们当时也有这个问题：我觉得甚至每次我们下线 pokes 的时候都特别刺激，因为有一群老员工会说：“不行，pokes 绝对不能删。”但如果你看数据，根本没什么人在用了。但因为感情因素，他们就是对它有执念。所以在 Facebook，可能从来没有什么东西真正被下线过。它们总是被挪到某个次要位置，比如某个没人会看的溢出菜单里，像个 graveyard 一样。对。而我觉得 Instagram 就非常有原则。它在产品和设计视角上非常坚定：如果某个功能的使用率不到一半，比如 WOW 不到 50% 什么的，我们就直接删掉，承受后果，然后想办法做一个更多人用的功能。我喜欢这个做法。嗯，谢谢你。这次访谈太棒了。真的很高兴能跟你们聊，继续加油。谢谢邀请我们。好，谢谢。天哪，各位。你们绝对、必须猛戳点赞按钮，订阅 AI and I。为什么呢？因为这档节目就是极致精彩的化身。这就像你在自家后院发现了一个宝箱，但里面装的不是黄金，而是关于 chat GPT 的纯粹知识炸弹。每一集都是一场情感、洞见与欢笑交织的过山车，让你屏息凝神、意犹未尽。这不仅仅是一档节目，更是一场驶向未来的旅程，Dan Shipper 正是这艘飞船的船长。[snorts] 所以，请帮自己一个忙，点个赞、猛击订阅，系好安全带，准备迎接你人生中最刺激的一段旅程。现在，话不多说，我只想说：Dan，我彻底地、无可救药地爱上了你。