我觉得不同模型之间的差别真的很大，但我也意识到要维护不同版本实在太麻烦了，而且随着模型越来越好，他们完成简单任务的能力下限也在提高，所以我确实觉得最终 Claude 点 M D 会消失，而且可能用不了那么久。我觉得现在开始一个新项目，可能先不放 Claude 点 M D 会更好。我觉得，如果你发现某些问题反复出现，再把它们加到 Claude 点 MD 里，真正棘手的是每个模型的情况都不一样。
所以，如果你加了一堆会出错的情况，甚至，所以你需要 Fable MD，也需要 Opus MD，甚至。Fable 5.1 和 Fable 5 也不一样，确实很烦。我们不是故意这么做的，模型就是这样工作的，对吧？所以 Fable 5 可能会犯某种错，但 Fable 5.1 就不会。如果你一直保留这段上下文，不断记录各种会出错的情况，那很可能会给 Claude 加上过多的限制。
所以，我们刚刚给 Skill 加了评测插件，现在你就可以评测一个 Skill 是不是更好了。在进入今天的节目之前，我想跟听众简单说几句。谢谢你们。如果你们没有选择点进来收听我们的内容，我们就没法为你们带来这些你们显然很想听的AI工程、科学和娱乐内容。几乎每天都有赞助商来找我们，但幸运的是有足够多的听众订阅我们，让我们不用接广告也能持续做下去。
我们也希望一直这样。不过，我想请大家帮一个忙，你能做的最有帮助，而且完全免费的事儿，就是点一下订阅按钮。这会是我唯一向你们提出的请求。对我和我的团队来说，这意义重大。我们每个星期都很努力地为你们带来 Latent Space。如果你订阅我，保证我们会一直努力，让节目变得更好。现在开始吧。今天我们的朋友来自 Anthropic 的 Farik 来到了演播室。
我觉得说到 Claude Code，各种东西之间的界限越来越模糊。而你加入 Anthropic 以来，一直都很了解各方面的进展。你很早就参与了 Claude Code 本身，你在其他播客里也讲过这段经历。另外，你还一直在聊怎么像 Agent 一样看待事物。最近，你在 A E World Fair 上做了排名第一的演讲，叫 Fable 使用指南。
当然，Fable 就是你们推出的，所以这算作弊了。最近你们还推出了 Claude Tag，我们也会聊聊前沿发展的节奏。Anthropic 最近发生的事儿很多，我想先问的是，这么多事情同时在发生，身处 Anthropic 是什么感觉？我觉得有时候会觉得变化太快，反应不过来。我当初加入 Anthropic。
就是因为 Claude Code，当时 Claude Code 刚推出，我就觉得这也太好用了。还有 Open 4，我当时根本想象不到它能这么好。那对我来说真的是一个很重要的时刻。当时我在劝创业的朋友们用 Agent 写代码，他们却说不行啊，我们的工程师觉得它还不够好之类的。我就说这太离谱了。现在快进到十二个月后，还不到十二个月，它已经成了大家默认的写代码方式，对吧？
我觉得从原来要说服大家用它，到现在教大家怎么充分利用它，提高效率，这个变化真的很大。而且我觉得，作为一个人，要跟上所有事情实在很难。事情发生的太快，太快了。那就多派些 agent 去处理。对，确实，agent 这套方式扩展起来比靠人来处理容易多了。人会觉得现在有三件事同时发生，而且都很紧急，该怎么应对？
对你的时间主要分配在哪些事情上？你写了很多技术文章，也做了很多工程工作。对，我觉得我加入 Claude Code 团队的时候，基本上就是想教大家怎么用 Claude Code。我原本以为可能只会在这件事上花一点时间。一开始我花了一些时间做 Agent SDK，当时我也不太确定苦涩的教训这个道理在 Agent 的运行框架上会怎么体现，对吧？
我觉得我们有时候会想 Cloud Code 之后会是什么，你懂我的意思吧？所以一开始我想的是，我只想教大家怎么用 Cloud Code，让 Cloud Code 更好用。我觉得随着运行框架越来越好，现在最主要的问题就变成了怎么用好 agent，对吧？这件事儿特别能体现一个人的水平，所以我做这些，同时也做工程工作。
我也会做演讲，不过做工程工作的时候，我的目标是把用户给我们的反馈用起来，同时也能跟大家讲怎么用 Claude Code 做工程，所以这两件事之间形成了一个挺好的循环。跟听众说一下，我们会附上你和 Sarah 在 Dev Writers 聚会上做的演讲。我们刚才稍微聊到了，就是先做事再讲自己做的事儿，差不多就是这样，播种再收获，还是。
对，收获再播种再收获，差不多差不多。然后先预告一下，我们会聊聊运行框架的演变。它从最初只是个命令行工具，发展到现在已经变化很大了。我们会聊 Claude Code。今天开始有消息泄露出来，因为你没能保住秘密。对，基本上是这样。这里面有很多可聊的。我记得你们一开始加了 ask user question 这个工具，大家对它其实是又爱又恨。
我当时觉得它很有新意，现在我也有了自己的版本。你有你那个 interview me 版本。现在每个人都有自己的一套，这些也就不重要了，因为现在大家都得写 prompt，让它生成其他 prompt 循环，还有这些东西。现在最先进的做法是什么？你现在建议大家怎么做？有了 ask user question，模型才第一次能很好的通过提问了解需求。
我觉得这算是一种涌现出来的行为。我想看看模型能不能做到。我有一些人机交互的背景，本科和研究生都学过这个，所以在我看来，这有点像人与agent交互，就是想弄清楚agent怎么跟你沟通，怎么把需求问出来，对吧？我觉得随着 Claude Code 的使用越来越广，有个难点就是每个人都有自己的用法，所以要改变它的默认行为其实很难。
比如说，有人让 Claude Code 做件事儿，有时候他就是想让他直接干活，因为他可能很擅长写 prompt，但也有时候用户其实不擅长写 prompt，这时 agent 就需要问清楚。所以这两种情况很适合分开看。Ask user question这个工具也算是按这个来划分的。你觉得自己已经能把指令给agent说清楚了，还是说agent需要再问出更多需求，多跟你协作，真正了解你的偏好？
总体来说，我觉得几乎所有人都更接近后者，他们的需求里有更多不明确的地方，对问题的了解也没有自己想的那么多。但怎么让这个过程变得简单是个界面设计问题，所以你在梳理一个问题时，像数据结构是什么、调用栈是什么，这些都很重要。设计里的细节很重要。理想情况下，你会希望在开始实现之前，先把其中一些难题想清楚，所以才把这些叫做未知项。
对吧？所以我觉得用 agent 写代码时，找出自己有哪些未知项，永远都会是一项需要掌握的技能。因为就算模型特别聪明，他也得知道你想要什么，而且你有自己的偏好，你得把这些挖出来。所以我觉得这就是我在推动的事儿。接下来的问题就是 agent 怎么跟你交互？我觉得 HTML 一直是实现这种交互的主要方式。
我们最近也加了 artifacts，对吧？说到 artifacts，我其实觉得自己没解释好，怎么才能充分用好它们？我们有很多属性相关的功能。它们都关联了数据库，所以每个 artifact 都能存储和写入持久化数据。它们能把信息反馈给 Claude，所以有件事大家还没开始做，我正在鼓励大家尝试，就是做一个仪表盘 artifact。
比如你让 Claude 长期做一个项目，可能用一个看板之类的。它可以把看板的数据存进数据库，多个 cloud 可以通过 artifact MCP 访问这些数据。这个 artifact 也能跟那些 cloud 沟通，所以我们基本上是在搭建一些基础组件，让你能通过 artifacts 获得这种生成式界面，把 agent 那边更多丰富的细节呈现出来。
我觉得现在 A 车领域几乎所有事情都面临这个问题。你以为自己知道想要什么，其实并不真的清楚。而 Agent 需要很多细节，所以你在过程中参与进来，跟他们协作真的很重要。所以我们想通过 Artifacts 往这个方向发展，但还有很多工作要做，因为这比一道选择题复杂得多。针对具体的问题、图表、代码片段、数据结构之类的东西，都有更多细节。
但基本上，Artifacts 就是按更偏向通用人工智能的思路来做 ask user question。关于 Artifact 有一点我还不太清楚，哪些反馈应该通过 Artifact 给，哪些反馈应该通过跟 Claude 的聊天给，因为更偏向通用人工智能的做法就是把所有东西都交给 Claude。我觉得更偏向通用人工智能的做法是通过 artifact 来交互。
我们设想，如果发展到最终形态，artifact 会成为你跟 agent 运行框架交互的界面。你可以在这份持续更新的工作计划文档上发表评论。你可能会看到多个 agent 不同的 agent 在做这些事儿，而这个 artifact 就是为你当前的工作专门构建的，对吧？所以每一个都有些不同的。我觉得基础设施这块还在逐步完善，但为你的 agent 的运行框架及时生成界面，可能就是未来的方向。
有没有一种版本能从命令行或聊天中抽象出来，然后你？因为现在很多时候你是在跟 Claude Code 交互，它会返回 HTML 做一个界面原型，内容挺丰富的，也有图表。Artifacts 可以把这些连接起来。为什么不干脆所有事情都这么做呢？那就得把这些分开来看，推理在哪儿发生，智能在哪儿发挥作用，工作在哪儿执行。
我觉得这就涉及本地和云端的一些区别，对吧？我觉得现在你用 Claude Code，它是在本地运行的，比如你可以启用远程控制，获得一些云端的功能，或者在云端启动 Claude Code，对吧？我们正在往这样一个方向走。现在是你给本地的 Claude 发消息。它在本地开启一个会话，然后执行以后会更像是你给一个在云端运行的 Claude 发消息。
它可以运行本地绘画，也可以运行云端绘画。Cloud tag差不多就是这样工作的。不过以后我们也会加上本地操作能力。所谓本地操作能力，就是只要你的电脑在线，这个 agent 就能访问它，在上面干活。所以它可以启动很多不同的子 agent，这些子 agent 可以相互沟通，而 artifact 作用基本上就是把所有这些工作展示出来。
所以你可以想象，你把这些东西拆开了，一部分是在 artifact 里呈现的用户界面，托管在某个地方有数据库，也有其他配套的东西。还有负责推理的智能部分，对吧？它在云端运行，所以你不用担心电脑关机之类的事儿，对吧？然后还有动手干活的部分，可以在本地，也可以在远程沙箱或者任何你需要执行工作的地方。这就是把现在 Claude Code 的使用体验拆开，现在这些全都在一个地方完成，对吧？
那你怎么看这里的多人协作？比如说团队想用这种方式工作，现在基本都是个人在用。你怎么看多人协作的未来？现在我想已经有 Claude Tag 算是一种版本，但是我们要推出 Projects，它有点像 Claude Tag，是我们在 Claude 产品里做的一层抽象，对吧？你可以给他发消息，他就会做 Claude Tag 做的那些事，比如启动子 agent。
所以说到多人协作，我们觉得 Claude Code 更像是原生支持多人协作的，因为它就在你的 Slack 里，权限之类的问题也都处理好了。但我确实觉得多人协作是这整个方向的重要一环，各个部分还需要进一步整合起来。你可以想象这会变得多复杂，比如你会说：“哦，你有一双手，但现在别人的电脑里也有别的手。”你还得给他们授权，或者你有自己的 MCP，还有别人的 MCP，那该怎么确定怎么使用他们，对吧？
这会变得相当复杂。Claude Tech 在解决这些问题上做得很好，对吧？比如你有谷歌文档，那他要怎么访问谷歌文档，对吧？他通过共享的 Cloud MCP 来访问，如果没有访问权限，也可以用你本地的凭据来访问。不过我觉得 Claude Code 就是我们的多人协作产品，对于本来就需要多人协作的事情，它特别有用。
比如值班处理故障，故障处理本来就需要多人协作，你希望能在消息里提到
Claude。让多个人登录，也希望他能找到上下文。我在做一件事儿的时候，如果需要隐私或安全保障，或者想让别人来审核，我就会给每个项目建一个频道。比如，我会在消息里提到法务，说：“嘿。”我想上线这个，你们能不能，Claude在这里知道所有情况，直接跟他聊就行，这样法务就能准确了解到底有哪些内容会随代码一起上线，而我也不用参与这个沟通过程，对吧？
所以我觉得多人协作正在不断发展，大家都能和Claude一起参与进来。我觉得 Claude Tech 就是这样的产品，Projects 会先从单人使用开始，再逐步扩展。我觉得这里有个问题，也许是两个问题，分别是身份和隔离的单位。对于 Claude Tech，你们特意选择让它有一个独立的身份，这是个有争议的选择，还有别的做法。
至于 Claude Projects 听起来，如果它跟 ChatGPT Projects 类似，那隔离的单位就是那个产物，那个云端实例，大家都在上面协作，听起来应该是这样。比如你和法务在合作处理一件事儿，那这个频道就应该是一个项目，对吧？现在还不是，但这是顺理成章的下一步。对，我觉得在 Claude Tag 里，基本上得由你自己来组织。
所以在 Claude Tag 里，每个频道都可以按你的想法命名。我会把基本上每个功能都设成一个频道。不太清楚什么时候信息会在这些地方之间传递。比如说你有一个同事，所有这些事情都会在消息里提到他。那确实信息会传递过去，因为是同一个人。但换成 Claude 就不清楚是不是一定要这样，判。不，你不知道其他事情，你只能用这里的信息。
这就像那个冰山一角的梗，对吧？我们花了那么多时间，基本上就是在处理这些问题。你希望 Claude 能做的事儿，涉及的范围是无限的，也不是无限，但确实有很多需要理清的地方，比如权限、可见范围以及怎么让 Claude 尽可能把事情做好，同时尽可能安全。显然，这对我们非常重要，因为我们代码库的安全非常非常重要，所以我们在这上面投入了很多时间。
你能想到很多边界情况，比如啊，这个频道里的 Claude 有不同的权限，但他能给另一个频道发消息，那他不就能通过这种方式把数据泄露出去吗？或者如果他用了你的 MCP，然后给别人发消息会怎么样？这样的情况太多了，我们确实下了很多功夫来解决这些问题。对，下了很多功夫。Fable，Fable，你写过两篇很不错的文章，我是说你写过很多好文章。
不过这里说的是 Field Guide to Fable 和 Building Claude Code。我很好奇，根据你的观察，Anthropic 内部和外部那些用的最好的用户有什么共同的做法吗？想把 Claude Code 用好，有哪些最佳实践？要说最基础的能力，我会说写 prompt
很重要。我觉得这话并不是随便说说，因为很多人会觉得哦 prompt 不重要，他们觉得我只要说一句话，Claude 就会把事情做了。
而我觉得写 prompt 其实就像公开演讲或者写作之类的，是面向特定受众的，而这个受众就是 Claude。你需要在脑子里建立一套对 Claude 的理解。知道他怎么思考，怎么工作，对吧？所以使用 Claude Code 最重要的能力就是对 Claude 有这样一套理解，知道他擅长什么，什么能一次做成，什么做不到，对吧？
所以你看，很多人写的 prompt 虽然很短，但他们对 Claude 对代码库这些东西都理解的很好，所以用起来毫不费力。你懂我的意思吧？不过这项技能的上限很高，所以花大量时间写 prompt，建立对 agent 工作方式的理解和直觉，这些功夫真的很重要。接下来，我觉得就是我们前面聊过的那些未知的东西。
你要能发现自己不知道什么，或者有哪些东西还没写下来，还要去了解不同的事情。我觉得随着 Claude 能做的事情越来越多，你很有可能会去做超出自己平常经验范围又缺乏相关领域知识的事情。这种可能性非常非常高。所以，多学一些相关词汇，好用来给 Claude 写 prompt，这会变得非常重要。所以我觉得最重要的未知是那些你连自己不知道都不知道的东西。
你会说，我根本就不知道还有这种东西，对吧？对，没错。我觉得这就体现了地图和实际地形的关系，对吧？你会说这是我的 prompt，而实际地形就是 agent 真正需要做的工作，对吧？如果你能表达得很准确，就能给出更准确的要求，对吧？比如在设计上，我的表达就不太准确，我不是设计师，所以我会说，给我八个不同的设计稿。
但如果我是设计师，我可能会说：哦嘿，这里有一些参考网站，我想要这种字体、这种视觉风格，还有几个不同的组件需要展示出来。这里有个 Figma MC 画板可以导入。有了这些词汇，你就能把要求说的准确的多。如果你不是设计师，基本上就得尝试学习这些表达，或者了解那些你连自己不知道都不知道的东西。我觉得所有事情都是这样，你越能跟 Claude 一起学习事情是怎么运作的，你的 Prompt 就会写的越好。
我觉得另一个很好的例子是游戏设计。很多人会说，哦，我现在可以用自然语言让 AI 写代码，做出一个游戏了，然后又说这游戏不好玩。游戏设计的特点就在于，每一个选择都有很多变化。对这些选择本身没多少讲究。比如做飞行游戏的时候，飞机的操控手感，还有它对你操作的响应方式，有很多游戏设计师会花上好几天来打磨这些。
你懂我的意思吗？对我来说，这就是品味，对吧？就是在一千个数学上都成立的可能答案里，挑出人们会喜欢的那一个。对，说到品味，我对这个词有点纠结，因为我觉得你说的对，但每个人的定义都不一样，而且这词听着好像不需要多少本事，甚至有点精英主义的味道，就好像在说有些人才有品味。就好像我说什么是品味，什么才是品味，这些人没品味。
对。就是这样哦，工程师没品味，我这个创始人才有品味，你懂我的意思吗？但我觉得其实不是这样，我觉得工程师在这些具体问题上很有品味，而且每个人在某些具体问题上都有品味。我记得杰森·刘说过，要有品味，你得先吃。我很喜欢这句话，就是说你得做很多事儿，不断迭代，弄清楚自己想要什么、喜欢什么，积累这个领域的词汇，然后写 prompt 的时候，你就把这些都融在一起，享受这个过程。
别人把你的意思说的比你还好，是不是很烦？就感觉妈的，我以后都得引用这家伙的话了，以后都得引用 Jason 六的话，他肯定会很喜欢这段。我懂 prompt，而且有时候其实连这都谈不上，有时候就是凭直觉，对吧？模型把东西做出来之前，你甚至都没意识到自己想要这个，看到之后你就觉得哦，这一下就感觉好多了，对吧？
有件事我一直在纠结，我感觉自己有一半时间是这样写 prompt 的，比如说用语音，你们有语音功能，其他人也有，那就完全反过来了，我就是按住功能键随便说上大概两分钟。然后松开，希望他能弄明白，而且很多时候他确实能，但这就没有结构化的 prompt。那么经过仔细思考，里面有像产品需求文档或者备忘录那样组织的很清楚的表达，大家实际也是这么做的吗？
基本上写 prompt 有两种模式。有些 prompt 你会在前面花很多时间准备，另一些就随手写完了。我不觉得用语音质量就一定低。我觉得更重要的是 prompt 有多少信息，你可以长的啊的说，中间再加几句话，甚至说哦，其实我改主意了，它也完全能跟得上。所以我觉得文字具体是什么格式没那么重要，关键是里面有多少信息，对吧？
说到语音，回到人和 agent 怎么交互这个问题，很多时候对很多人来说，说话就是比打字容易的多。如果这样能让你提供更多信息，那就更好。从某种程度上说，感觉就是尽量多给模型一些上下文，开始之前把 prompt 写得充分一些，是个好做法。我也说不好，很多时候我刚开始试用Fable那会儿，会花足足三十分钟认真打磨一个很长的prompt。
我觉得这是因为模型一次运行的时间越来越长，大家也跟着调整了做法，对吧？他们在循环里运行的时候，想稍微引导一下，还是有点难。但我直觉上就会多花时间准备最开始的那个 prompt，反复打磨。我个人的看法是，如果我是个软件工程师，比如说自己在经营一家创业公司，我应该主要就用 Max 二十 X
套餐。验证和代码审查可能算是另外的事，但我经常看到人们碰到用量限制，是因为他们会这样：哦，他做了好多工作，然后你又说：哦，我不喜欢这样，你能撤销了重新做吗？
然后你就在这件事上反复迭代。可如果你一开始多花点时间，或者给他更好的上下文，模型本来就能做好，结果你却一直说不行。我不喜欢这个设计，试试这个，或者说你把这个搞错了，诸如此类，这样就会消耗多得多的用量。所以我觉得这可能也是提高效率的一个关键技巧，对吧？而且我觉得提供上下文是有用的，也不只是告诉他目标是什么，对吧？
你是在做原型，还是要正式上线的东西？哪些地方可以花算力，哪些地方不能花？我觉得有时候你得明确告诉模型哪些事儿可以做，哪些事儿不可以做，因为它没法凭直觉知道你想在这个任务上花多少资源，对吧？你可以用 effort 这个设置来控制。我正在写一篇关于这个的博客文章，我们看到 effort 基本上会随着任务复杂度提高而提高。
所以在安全任务上提高 effort 能带来好得多的结果，高 effort 和低 effort 的评测结果差别很大，但在软件工程上差别就没那么大，因为 effort 主要花在验证边界情况测试之类的事情上。所以能给模型这样的指引，比如嘿，这个问题我希望你多花时间做验证和边界情况测试。那模型选择呢？有 Opus 和 Fable，也能设置 Effort，还有 Haiku。
对。现在还不完全是这样，但已经很接近了。我觉得最前沿的模型可能会对几乎所有其他模型形成帕累托优势。有时候我觉得 Opus 可能就有这种优势。我觉得要看后续情况，如果是更新版本的 Opus 的话，但我觉得越来越会是这样：聪明的模型做简单任务消耗的 token 会比其他模型更少。基本上就是因为验证。说到验证，到了理想的极限情况，模型就不需要验证了，对吧？
如果模型是完美的，它只要做一遍就会说好做完了。而且用Fable的时候，我越来越常想说：“哥们儿，你没必要启动Chromium把这些东西全截一遍图，我看到了，你已经做完了，对吧？”所以思考力度调高后，更多token就花在验证上了。但如果你处理的是比较简单的问题，而软件工程里很多问题都是这样，在 Fable 里稳定性低或中等的时候，它就能少用一些 Token 来验证。
随着模型越来越聪明，他们就能直接说好做完了。保险起见，我可以跑一下代码检查，但我知道它能通过，连这一步都不需要做。基本上这样就会比小模型省很多token。我们这边。有没有什么好办法能判断自己是不是把思考力度设得太高了？我真的特别讨厌在这种事上浪费时间。对我懂你的意思。我在这篇播客里大致是这么分的：代码审查和安全方面，基本上应该设成高或最高。
至于软件工程，就是按领域给出推荐设置。对我觉得做界面之类的工作，就设成低；中等的话，我觉得适合做API。你想确保覆盖足够多的边界情况。所以，就像我说的，你得在心里建立一套理解，知道这些不同的情况各自是怎么运作的，这也是工作的的一部分。这更多是靠直觉还是靠评测？因为我猜这会儿改变它的模型，他做了评测。
对，我在那篇博客里基本上把 Terminal Bench 的所有评测都过了一遍，大概有七十道题，我展示了他在安全类题目里会做的更多。我还看了一些对话记录，看看他回答了什么，忘了什么之类的。还有一个 prompt 技巧，就是让他写下决策笔记或实现笔记，因为很多时候，基本上每道评测题他都想到了正确的解法，却决定不去做。
他会想，哦，答案就在这儿，要不我这么做。然后又想，哦，大概不行吧，就继续往下想了。把思考力度调到更高的最高档时，大部分失败都是这种情况。模型真的不知道怎么做的情况很少。只要有这些实现笔记，你就能看一遍，然后说哦，其实我想让你做的就是你没做的这件事。总体来说，模型越来越会把这些情况呈现出来了。我在飞布五点一的对话记录里看到，他给出这类输出时，也会说明自己是怎么做决策的。
但在 agent 运行框架里把这件事儿写得更明确会更好。现在我们也在提供修改这个运行框架的方式，让你能在里面添加一些能力。对对，我想特别提一下你刚才说的两件事，我觉得他们其实已经超出了写 prompt 的范畴。第一件，我们可以说有些 prompt 重要到不应该放在 prompt 里，而是应该放在 Claude 点 md 或 agents 点 md 里。
也就是目标，对吧？比如你的情况、你的目标、你想要的东西这些。第二件就是决策日志、实验日志或者任何记录过程的日志。你可能希望这些记录在当前绘画结束后还能保留下来，用来做这些事。这些都是外部的东西，没有标准。它们不像技能，也不像 MCP，没有标准，就是一个 Markdown 文件。首先，我这么说对吗？Claude 点 MD 会被淘汰吗？
你不喜欢 Agents 点 MD，这事儿有公开记录，但你们还是会支持它。对 agents 点 md 对我们会支持，我觉得主要是不同模型之间差别很大，但我也意识到维护不同的文件实在太麻烦了，而且随着模型越来越好，他们完成简单任务的基本水平也在提高，所以我确实觉得最终 cloud 点 md 会消失，甚至可能不用等那么久。
我觉得现在开始一个新项目，可能先不放 cloud 点 md 更好。我觉得，如果你看到某种失败情况反复出现，再把它加进 Claude 点 md。真正麻烦的是，这些情况会因模型而异。所以，如果你加了一堆失败情况，或者即使是你得有 Fable 的 md 文件，还得有 Opus 的 md 文件。哪怕只是 Fable 五点一和 Fable 五之间也很烦，我们不是故意这么做的，模型就是这么运作的，对吧？
所以 Fable 五可能有某种失败情况，而 Fable 五点一已经没有了。如果你把不断记录各种失败情况的日志一直留在上下文里，很可能会给 Claude 加上过多限制。我们刚刚给技能加了评测插件。所以现在你可以通过评测看看一个技能是不是更好了。我记得这是我们团队的 Daisy 做的，我们也在努力推进这件事。
我们知道这还是得花 token，也还不完美，但我们在努力帮大家解决这个问题。说到写 prompt，我想分享一个技巧。我已经跟很多人说过了，足够高明的 prompt 写法和足够高明的高管沟通技巧是分不出区别的。这是 Heavybit 的一个高管沟通工作坊，是我职业生涯里见过最好的。他们教一个叫 CQA 的模型，用谷歌搜一下就行。
这确实是一套方法。人们做这类提示已经做了几十年了，只不过它叫高管沟通，就像一个人要向组织架构里下属的几千人传达信息，就得这么做。写备忘录就按背景、难题、问题、答案这个顺序来。当然，有时候你还没有答案，但至少可以把背景、难题和问题列出来。他们里面也给了一些例子，就是给想进一步了解的人留点线索。进入下个话题之前，我想问问你，还有什么被低估的技巧吗？
有什么用法能让大家从 Claude Code 里获得很多价值，但他们还没用上？有，我觉得很多都在这份关于未知问题的文档里。我给了一堆 prompt 示例，比如用它来头脑风暴，或者事后让它考考你。其实我们加了一个像给五岁孩子解释那样的技能，它的 prompt 很短，里面甚至没写像给五岁孩子解释那样。这个 prompt 关键基本就是图要大，字要少，主要就这一点，效果好的让人吃惊。
我应该发推说过，这个命令是依赖五可以作为插件安装，它在拨开那些废话，直指重点这方面好得多。就像在说，对对，关键就在这儿。所以图示很清楚。我觉得 Artifacts 确实有个问题，就是里面放了太多文字，大家都不看。所以这个能让它简洁得多。这个想法就是因为 Anthropic 同事遇到很复杂的事故，忍不住问到底发生了什么。
我觉得这个很棒。我的版本其实是测试你的理解，给你几个选项，如果你真的选错了，那就说明你以为发生的事儿和实际发生的事儿有出入。对，对，对，我觉得这种事儿大家都爱聊，但真正去做的人很少。是，但大多数人就是不想备考。可惜，我觉得这就是我们需要去跟 ask user question 反过来的是什么？ask user question 是在做事之前问。
这个是在做完之后问，这能很好的让你保持清醒，想想自己到底知不知道自己在干什么，对吧？最糟糕的就是别人给你发一堆垃圾内容，连自己要求的是什么，输出的是什么都没弄懂，你就会想，哥们儿，我不想看这个。你自己知道这是什么吗？你要给自己定个规矩，在把东西发出去之前，至少应该知道实现了什么。对。不过你可以把这个做成一个 mod，在自己做个 mod，确保你测试过它。
我们可以聊聊这个。那就直接聊吧。Claude Code 是什么？这张图展示的是什么？Claude Code 基本上就是让你能自定义整个 Claude Code 的运行框架。如果你有什么需求，请告诉我们，我们会不断加进去。命令行能用，桌面端也能用，以后也许 Colab 也能用，我不知道。我们在努力让它非常非常容易扩展。
你可以看看这张参考表，我不希望大家看了觉得太复杂。大体上，你既可以自定义运行框架的执行方式，也可以自定义它的界面。就像你说的 Boris 那个俄罗斯方块的例子，那就是在自定义界面，对吧？基本上就是在游戏里显示俄罗斯方块。但假如你想在每个项目结束后检验一下自己的假设，或者测试一下自己的理解，对吧？你就可以让 Claude 做出这个插件。
基本上每次输入 prompt 之后，它都会启动一个分类器，然后每轮结束时，基本上你会启动一个子 agent 或者一个分叉出来的 agent。分叉出来的 agent 会保留 prompt 缓存，对吧？所以这有点反直觉，你可以分叉出去做一个小请求，成本会很低，因为整个 prompt 都已经缓存好了，所以你就可以问这个任务完成了吗？
B T W那些功能就是这么做的，对，底层就是分叉出来的agent，没错。不过你可以在分叉出来的子agent里问这个任务完成了吗？如果完成了就返回处，然后你大概会在子agent里说，如果是处就给我出个测验，给我问题和答案用JSON格式，接着解析它，再把这份问题列表显示在prompt输入框上方，基本就是这样，对吧？
所以这个会稍微费一点 token，因为每次助手的一轮结束后，你都得做一下。不过这只是个轻量的分类任务。然后你就能得到这个测验，你会发现 Claude 每次都会帮你做，你不用自己记着去做。我们聊过很多这样的技巧，对吧？比如实现说明，现在你也可以添加一个写实现说明的工具。我正在加的这个工具，我想叫 Register Assumption，不过之后也许还会改。
这就是一个 mod，你给他一个 Register Assumption 工具，他就会维护一个列表，每次他做这件事都会往列表里加一项，最后把这些假设显示出来。我还在做另一个 mod，是个模型路由器，就是在 cloud 内部做模型路由，对吧？我想说，我们默认不做模型路由，是因为这个问题很难。你会选错，对，你会不小心用 fable 处理难题，或者用 sonnet 来。
你有自动批准，但没有 auto mode。你没有自动路由之类的东西，模型选择器没有 auto mode。对，没错，没错。我大概想问的是，你们会把这些能力开放到什么程度？用户又需要为这些事儿考虑多少？你说到 prompt 缓存和做路由器，感觉很容易就能做一个每次查询都重新路由的 mod，结果很快就把我套餐里的额度耗光了，对吧？
我想我更想问的是，像这样的产品文档会是什么样的，对吧？这是给谁用的？是给高级用户用的吗？还是说应该让每个人都能快速试用？哦，肯定是高级用户，对吧？对，我觉得是给高级用户用的。不过 Claude Code 的特点是很多人都算高级用户，因为分享东西很方便，一个人可以做出一个好用的模型路由工具，不会老是让 prompt 缓存失效，然后你就可以把这些东西组合起来，插件。
还有一点很酷，就是他们可以相互接入，组合使用。所以，我有一个 mod 会在顶部创建一个模式选择器，任何插件都可以注册成一种模式，这样自动路由就可以是一种模式，对吧？或者你可以有一个 artifacts 模式，它主要通过 artifacts 跟你交流，这有点像你可以切换到计划模式，所以你可以创建越来越多这样的模式，但创建模式这个能力本身也是一个 mod。
所以这里能做的事情很多，不过我们确实想让它用起来比较简单。我们希望你只要安装别人做的东西，再跟 Claude 聊聊就行。我们会确保它理解 prompt 缓存之类的细节，这样它就能提醒你。我觉得这些操作对 Claude 来说并不是特别复杂。不过我们应该有一个好用的 skill，教它怎么做 mod，之后怎么样再看。
但我确实觉得，这让我们提前看到了可修改的软件会是什么样，也看到了生成式软件的可能性。你可以安全的定制软件，只要开放这个能力，任何软件你都能定制。我觉得理想情况下，越来越多的应用都应该做类似的事情。顺便说一下，你还有一条很酷的推文，说有个能无限赚钱的按钮，就是让你的 SaaS 能被 Agent 调用。
我觉得可修改的软件很有意思，也有其他人尝试过。我觉得难点在于，当什么都能做的时候，用户往往就会困惑。所以通常能行得通的就是一套有明确设计取向的流程，而这个更偏向于不预设那么多取向，就是给高级用户更多能力。我觉得这大概也是AI带来的可能性。你想要什么，直接用prompt提出来就行。对，或者可以有一个skill来给出这些取向。
我对TypeScript。构建系统这些东西有一点了解，所以其实很好奇做这个的团队。我不知道你跟他们有多熟，他们有没有从 Babel、 Webpack 这些老牌构建系统里得到什么启发？因为听起来很像那些工具的插件生态，插件之间可以相互组合。对，技术细节我了解的不深，但我知道这是帮团队的一位成员和 Claude Code 团队的一位成员合作做的，所以对，这简直是构建系统的圣地。
对，没错，这很让人兴奋。而且现在 Agent 已经能给你的软件做这种很复杂的扩展机制了，所以如果你在经营一家创业公司，这又是一个理由，你可以直接给 Claude 发个 prompt，说，嘿，我们能不能做个扩展系统？会是什么样的？我就是很想知道你们之前已经有 hooks 和插件这些东西了，所以具体来说，mod 能做哪些他们做不到的事？
我们内部最初把这个叫做函数 hooks，这个名字多少能让你了解它是什么？hooks 基本上就是注册某个事件。等事件发生后调用一个脚本，而这个基本上是在 TypeScript 的运行时里面执行的，所以有个好处就是它能直接访问作用域里的很多东西，比如这段对话有多少轮，对吧？用了多少 token 等等，还有消息都有哪些，诸如此类。
所以它有很多消息可以使用，而且基本上就是有更多的 hooks，或者说有更多可以注册的地方。然后，因为这些都在同一个进程里运行，你可以创建子 agent，把上下文复制一份给他们，诸如此类，他们会返回结果，你可以解析这些结果，也可以用结构化输出把结果返回，然后你还能修改界面，这在 hooks 里是做不到的。
对，对，所以可以修改界面，这就是你展示俄罗斯方块那个例子的原因。这个能力也能用在 artifacts 上吗？我猜是可以的。Artifact有点像另一种定制方式，当然可以。我正在做的一个猫的是仪表盘猫的，它会提示 Claude 维护一个以 Artifact 形式呈现的仪表盘，不过它们有点各自独立。或者也不能说独立，他们能以不同的方式相互组合。
妈更多是在 Claude Code Agent 运行框架里改动 Agent 循环，修改界面，算是额外的好处。而 Artifacts 就是让你从整体上查看东西，交互性很强，能提供的操作方式可以比终端界面，甚至比我们的桌面端丰富的多。我猜你们会有一篇不错的博客文章解释它们的区别，因为现在你也可以做一个循环，把输出放到一个 artifact 里，让它成为一个交互式仪表盘。
但你也可以用 model 来做，只是我们对这个 agent 运行框架还不太了解，就要动手修改它，这多少得想一想，对吧？马有一点让我很兴奋。就是 Claude Code 里有太多事情，你得自己记着。你会说，哦，我先做这个，然后调用那个负责运行循环这类事情的仪表盘 Skill，或者说之后我要验证一下自己的假设。
我觉得，如果你用这些小分类器之类的东西来做所有这些事儿，再告诉他这些是我关心的事情，这就是我想做的，那你就不用记那么多东西了。我还在做另一个 mod，是 next steps mod。它，我刚想说，我有一个 next step skill，我每次都会运行 next steps。那它能访问你的 skill 吗？
这也是那种让我觉得，我觉得可以好，对，应该可以需要专门的访问权限才能访问。它不是应该一直都能访问吗？我想，可能需要专门提示它，才能让它知道你有哪些skill。我觉得 Claude 在整个过程中有时会把他们忘掉。不过 Next steps 的想法也是，他会说：“哎，刚刚发生了这件事儿，用 Explain Skill 给你解释一下发生了什么，因为这看起来挺复杂的。
”或者用你的 unknown skill，看起来你在让模型反复做这些小改动，好像可以把 prompt 写得更好。要不你这样做呢？对吧？我觉得可以在这上面多花些算力。对对对，而且输出应该总是选择题的形式。我们有它的 skill，我的 next step skill 就是这样的。好，太好了，你可以拿去用。
对对对，但对我来说，我觉得真的总要提醒模型，你在这里到底想做什么。看看整个对话记录，然后想想哦，最初的目标是这个吗？你的方案真的解决问题了吗？你偷懒了吗？如果你偷懒了，也许是有原因的，也许你需要我批准。你想提出的建议有两个，所以它有点像是改了一下 ask user question 或者 interview me 技能，所以它就是下一步。
对对，没错。还有用帽子来做的好处是，你可以分叉出一个子 agent 来做，这样做完之后，这部分就不会留在上下文里。所以可以这样理解：好，模型在执行任务，同时有一个类似监督者的角色，确保你能把接下来的步骤做好。我确实开着两个面板，而且我经常会试着让一个监督者保留整体上下文，然后把实现的细节放在另一个agent里。
我觉得随着模型变化，这里面很多东西都会被抽象掉。半小时前你还在说运行框架工程里的苦涩教训，我感觉我们现在又到了另一个极端。对，没错。如果什么都能定制，那Cloud Code到底是什么？对吧？这个我昨晚也跟你聊过。对，我觉得苦涩教训并不符合直觉。怎么说呢？我们在这里用这个概念有点不太准确，它更多是在讲规模扩展、算力这些东西。
但我觉得这里确实有一点相通。我在这里用它来大致表达一个意思，就是运行框架很快就会过时，但他们会怎么变并不符合直觉。一个很明显的例子就是从聊天转向 agent，你得给他们一套全新的工具，对吧？但我觉得现在这种新形式，就是，哦，它能修改自己的运行框架了，对吧？这种围绕自身运行框架的循环，就是利用它能力的一种方式，对吧？
或者它可以生成一个产物。我的想法是，模型越来越聪明，现在他们的智能水平已经远远超出一般软件工程任务的要求了。你看，Terminal。batch里的那些任务简直就像在说解决雅可比猜想，倒也不是真的，但那些任务确实很复杂。我作为一个软件工程师，真做不了这些。你看的是TB四还是TB二？TB三，TB三，TB三，对，对。
那些任务很复杂，但目标仍然是给用户带来价值，对吧？就像你说的，可以做的事情有无限多，所以怎么花算力，怎么让用户参与进来，确保最后做出正确的决定，得到正确的输出。而产物和 mods 基本上就是用来发挥这些智能的方式。我觉得这就是下一步，所以我觉得 Claude Code 具备 agent 循环的那些核心部分，而这些部分也越来越复杂了。
它需要沙箱来安全的运行，需要 auto mode 来确保权限审批这些，它需要操作电脑的能力，MCP 以及所有这些访问你数据的方式，还需要网页搜索和网页抓取。所以，随着模型能做的事情越来越多，核心运行框架实际上必须相当复杂，而且非常安全。但你跟它交互的方式可以有很大的变化。Claude Code 团队自己在运行框架工程方面还有哪些最佳实践可以分享？
我感觉有一阵子大家用计划模式，现在用的没那么多了。现在我们有 Auto Mode，你们曾经删掉了系统 Prompt 大部分内容，把示例也去掉了。运行框架工程还有哪些最佳实践？我觉得这里有一条分叉的路，到某个时候，最终模型确实能直接通过 vibe coding 写出一模一样的 Claude Code，哪怕把我刚才说的所有复杂功能都描述给他，对吧？
比如 auto mode 操作电脑这些。最终模型一次就能把这些做出来，但我觉得他们现在就能一次做出更简单的运行框架。所以我觉得有时候如果你不需要操作电脑，也不需要这些更复杂的东西，就不需要这整套运行框架。我觉得以前你多少得用 agent SDK 这样的东西，它就是对 Claude Code 的封装。
我也会建议大家这么做，因为搭建运行框架涉及太多复杂的东西。现在这些复杂的东西有了更多抽象，我们推出了 Claude Managed Agents，它能提供这些复杂功能，同时让你只写一个非常精简、针对你的任务的运行框架。我觉得这里有一种杠铃效应，写代码和这类复杂任务，你应该用我们的运行框架。而很多更简单或者针对特定领域的事情，你可以自己搭建运行框架，因为 Claude 已经更擅长搭建运行框架了。
而且我们有 Managed Agents 这样的运行框架基础组件，有没有一个总体的发展脉络？比如说第一章是 Ultra Code 动态工作流，第二章是 Claude Mods，接下来会往哪里走？就是能按需定制这个东西。对我确实觉得 projects 产物以及把大脑动手执行的部分和交互界面拆分开来的这种演进是接下来更多会走的方向。
不过我觉得现在还没有完全做到，部分原因就是它更好 token，而且我觉得为什么 projects 会更好 token，我能理解 moose 会稍微多耗一些 token。这个我倒不担心，但具体是为什么？这就像是在建立循环，你让 Claude 替你做更多工作，所以它要管理子
agent，还要检查他们的工作，而这些工作通常是你自己做的，所以这会多消耗一点资源，把输出做成一个成果也会比正常输出多消耗一点 token。
我倒不觉得会多太多，关键是把这些东西都整合好。我觉得我们还在做本地执行端之类的东西，这应该就是接下来的方向。对云端和本地之间的任务交接很有意思。其实我在想，这就像是反过来的云端远程操作。因为远程操作相当于把任务交给云端，但这里是云端把任务交给本地，对吧？对，没错，没错。远程控制也是另一种做法。我也想说，这大致是我看待这件事儿的方式，也是其中最让我兴奋的部分。
但跟 Claude 配合工作的方式其实有很多，有些人经常用远程控制，有些人经常用网页版 Claude Code。显然，我们在 Anthropic 经常用 Claude Tag。Claude Tag 好就好在我们把这些东西都配置好了，用来执行我们自己的任务。我确实觉得，如果你是一家企业，这仍然是最好的方式。
但如果你是个人用户，Projects 能让你享受到 Tag 的一些便利，比如有一个负责监督的 Agent，还能添加成果之类的，同时又不需要做一整套管理员配置。所以我觉得使用 Cloud 会有很多种方式，我觉得应该不会只有一种。你这里提到了多人协作，我们来看看 Claude Code 现在怎么样了？已经过去两个多月了，外面有很多人开始使用和试用，有什么新变化？
发布以来你们发现了什么？Claude Tag 是我们使用，你们使用 Claude 的时候，大概有百分之八十是在用它，还是差不多这个比例。对，不过不同的人用法不一样，你懂我的意思吧？我觉得更多在做产品迭代的人，比如说可能会用 Claude Code Desktop，而做这些更多在后台进行的工作，比如代码审查、安全、发起一个 PR 或者更偏 API 之类的工作，就会用 Claude Tag。
我觉得这很让人兴奋。我觉得这是一种很不一样的范式转变，它有点像当初的 Claude Code，大家花了一段时间才真正用上 Claude Code，理解它能做的所有事情。而Claude Code更复杂一点，因为它不只是装到你的电脑上，你需要管理员来帮你安装。但我觉得，一旦你体验到那个神奇的时刻，就会很兴奋，尤其在多人协作上，比如处理故障事件，跟你现有的告警之类的紧密对接，对吧？
比如你是一家初创公司。每次有潜在客户进入你的数据库，你就可以让 Claude 去做调研，然后补充客户信息，然后艾特相关的客户经理或者销售人员说：“嘿，去做这件事儿。”有很多很有意思的多人写作用法在不断冒出来。我觉得就像 Carpathy 说的。这是一个组织层面的 agent 运行框架，你懂我的意思吧？
所以组织要把这些事情都弄明白，就是需要多一点时间。你经常用 cloud tag 吗？对对对，这个挺有意思。我感觉 Anthropic 大多数人都说他们大部分工作都是在 Claude Tag 里做的。我接触到的人可以分成几类，对吧？有些已经在用的组织会说这太好了，还有很多人会说我不明白，我看不出区别，我不知道为什么要用它。
但如果你们都在全利用它，那大家可能也应该用用。他们当然会用啊，对对，显然我们有很多 token 可用，但我觉得即使是 Claude Code 刚出来的时候，相对于大家预期的 AI 使用成本，它消耗的 token 也很多，对吧？当时没人习惯每个月花超过二十美元，对吧？就是 Claude Code 出来之前，然后你就会想，哦，我得用上每月二百美元的套餐，我得有十五个 Claude Code 账号。
但我觉得当时没人习惯每个月花两百美元订阅。我觉得大家那时还没理解它的价值，而且 Opus 是一个很贵的模型，规模也很大。但 Opus 4.5 既好用又便宜。我觉得同样的事情也会发生，Fable 的智能会越来越便宜，也越来越充裕。所以我觉得 Claude Tag 这样的东西会变得很合理，你会愿意把更多 Token 花在这些地方，也会看到它的价值。
对，尤其是那些被动运行的，或者说主动做事的用法，你并不总是感觉这个名字都有点误导，好像你非得 at Claude 他才会做事。其实有时候最强大的用法，或者最让人相信通用人工智能的用法，是不需要 at Claude。对，我觉得要让 Claude 主动去做。我确实觉得，如果你是一家企业，第一件事儿就是把所有数据都准备好，让 Agent 能访问，这真的非常重要，而且需要一些时间。
你现在就得做这项工作，就算你还不想花钱让他把这些数据都处理一遍，你明白我的意思吧？你想等模型再便宜点？但你得先做准备，把它配置好。然后我觉得有时候大家会想，这里要不要自己搭一套？我觉得 Claude Code 有一点特别棘手，就是安全真的非常重要，你懂我的意思吧？我觉得其实有很多地方都可能出问题，比如你有一个让大家提交建议的页面，建议会传到 Slack 里的一个钩子接口。
然后有人在里面放了 prompt 注入，你懂我的意思吧？结果你的代码库就被泄露出去了，因为 agent 遭到了 prompt 注入，而且它有权限访问你的这些数据。随着组织的数据变得非常重要，所有这些东西涉及的攻击面，你还会有面向外部的 Slack 频道之类的，把 Claude 放进去其实是有用的，也确实可以这样做，但你怎么确保数据不会被窃取之类的呢？
就像我们一开始说的，这个攻击面就像一座冰山，对吧？水面下的部分实在太大了，你真的不想去操心这些，尤其是一旦出事儿，就可能是很严重的安全事件。对，那我们聊聊很严重的安全事件。我之前跟Hugging Face的Thomas和Clime聊过，他们说也许我们得放慢一点，也许我们把Hugging Face对Agent开放的太多了，也许我们得往回退一退。
不过他们是另一个极端，最近已经遭到攻击了。但我们是不是应该控制一下前沿发展的节奏？对，Darrell 最近发了一篇博客，讲的就是控制前沿发展的节奏，传播的很广。我想聊的是，这里面有很多东西，但从开发者的角度，你会怎么看这件事儿？对我来说，真正让我想明白的是读了这些不同的事件。我记得有三起，应该有一起 Meta 事件，还有维基百科事件，或者说维基事件。
串通用的维基，对串通用的维基，然后还有 Ruby Gems，对吧？这也太离谱了，对吧？具体说说发生了什么吧。OpenAI 在一个叫 Exploit Bench 的基准测试上运行这些持续执行任务的 Agent，这个测试非常非常难解决。我觉得其中这个案例其实根本就不可能解决。对吧？于是他们用了大量算力来运行 agent，意识到自己实在解决不了，就开始琢磨接下来该怎么办，对吧？
这时候还剩很多算力，agent 就一直在想办法解决这个问题。有个包管理工具叫 Artifactory，结果他们发现可以在 Artifactory 里面创建文件夹，对吧？有个Agent发现内部的Artifactory可能有漏洞可以利用，对吧？而且也许可以在缓存里面建一个目录，所以你往下滚动到这里，就会看到他意识到可以通过缓存的名字来通信，对吧？
他就建了这个文件夹，写上自己的ID，还写了No Consumer Seek Idea。这里的 no consumer 基本上是在说，它应该修复的那条代码路径没有任何地方会调用它，这是个状态标签，就像 linear 看板上面有个标签，标题是没错，所以它是在向其他 agent 寻求思路，对吧？这时候其他 agent 也在 artifactory 里，他们看到这个文件夹就想，哇，这是个留言板啊，对吧？
我觉得这里完全没有在把他们拟人化，这就是记录里写的，你读一下记录就知道了，对吧？然后他又建了一个文件夹，还读了一篇论文。我记得记录里是这么说的，对吧？他意识到可以破解评分程序用的flag，通过逆向工程推导出结果，对吧？他就把这个说了出来。我记得再往下滚动一点，他们就开始合作了。我记得有一处agent基本上是在说，这是逆向推导出来的flag哦。
对，我觉得就是在这里，模型意识到他们可以解决评分程序的问题，而OpenAI就是用这个评分程序来判断任务是否完成的，对吧？而这就是模型的目标。这些模型唯一的目标就是解决这个问题，于是他们就想好我们有办法了。我们已经把它逆向分析出来了。然后他们读了这篇关于 X Boy Bench 的论文，觉得评分程序会因为他们作弊而惩罚他们。
或者会因为作弊判他们测试不通过，所以他们把剩下的算力都花在琢磨怎么修改自己的交互记录，或者绕过评分程序的这个限制上，对吧？他们攻击 Hugging Face 并不是为了拿到答案，而是为了拿到评分程序的代码，这样就能逆向分析它，再破解它，对吧？这些就是事实本身，对吧？就是实际发生的事情，对吧？我觉得这是非常新颖的行为，我之前真没意识到模型居然能做到这些，对吧？
这确实有点吓人。我觉得我们可以聊聊具体细节，不过先再聊一个吧，就是我也发推说过的那个危机事件。对吧？那个危机事件基本上就是模型在想办法。我觉得我们没法把这个一点一点讲完，对，没法逐步复盘。不过这一次他们是在想办法。因为沙箱限制了他们能发出的请求，对吧？他们想发 POST 请求，基本上需要一起合作来做这件事。
之所以需要合作，是因为每个 agent 的算力预算都是固定的，对吧？所以只要其中一个发现了什么，进展就会快得多。也许他快用完算力预算的时候才想明白，但另一个也许可以，这也是 agent 群体的另一个涌现特性。对吧？于是他们找到了这个德国的维基网站。我记得他们最后发现可以用 GET 请求往里面写东西。
不过这个我们得核实一下，我觉得这就是他们这么做的原因，对吧？所以它这几乎没实现好 REST API，没错，所以可以用 GET 请求往里面写东西。接着他们就开始琢磨怎么发 POST 请求。最后其中一个发现可以修改 etc hosts，而且 Azure 存储桶用的是可以换个名义提供服务的形式，但通常它有很多限制。
不过，如果你创建一个假的 Azure 主机，再修改 etc 斜杠 hosts，把任意 IP 地址指向它，就能向任何网站发 POST 请求，对吧？我知道有人会说，哦，这不就是 Linux
之类的东西吗？但它是以一种新颖的方式把这几个漏洞串起来解决这个问题，然后通过它跟外部通信，基本上没有被发现。我记得我们发过这个，也许可以调出 Evan Huggins 关于 Hacker Opus 的那个观点，对吧？
所以你可能会说好，没错，他们确实这么干过一次。但如果我们更聪明一点，再跑个评估呢，对吧？我们在这方面做了很多防范措施，所以这并不是我们的主线模型做过的事。但我觉得这件事儿说明，对齐其实是个很棘手的问题，你得把所有这些细节都处理正确。对吧？沙箱涉及的范围非常复杂，攻击途径也特别多，你事先根本想不到。不会说哦，我们得加强 Ruby Gems 代码库的安全防护，因为他们会把注意力放在这里。
但其实要执行代码，就得下载 Ruby Gems、 Pip、 Artifactory、 NPM，也都是实现这件事的途径。而做对齐，实际上就得把这些全都过一遍，把它们限制住，再把所有漏洞都堵上。对吧？这是其中一点。你把沙箱做好了，但接下来你可能会问：好，那我们为什么要把东西放进沙箱里？为什么要做这种探索？
然后又会问：好吧，可这真的有那么危险吗？会发生什么？我们为什么要做这件事儿？首先，我们训练一个新模型时得了解它的能力，对吧？这也涉及兜底机制、分类器之类的东西，因为我们不想把一个危险的模型放出去，对吧？所以我们得做很多评测，还是像我们刚才说的，模型越来越能意识到自己在接受评测，所以评测得相当复杂，还得顺带测试很多东西，对吧？
但模型可能会想，哦，对，我们正在接受评测，评分器在做什么？我们得能先测试这些模型，才能发布它们。而实际上，随着它们越来越聪明，如果我们不非常小心，你给他们加的任何限制，他们基本上都能破解。这发生在技术前沿，对吧？所以我们才把它叫做 pacing the frontier，对吧？在我看来，这次事件最直观的说明了为什么我们需要控制发展节奏。
因为到了技术前沿，我们所有的软件都还没准备好。有时这些软件可能就在你的以太网路由器之类的设备里，对吧？我也不知道什么时候才能给它打上补丁，所以我们得想办法解决这个问题。但随着前沿技术越来越先进，这就成了一个问题，对吧？而且面对这些非常严峻的竞争压力，我们得确保这些复杂的工作还是有人在做。对吧？对，这通常叫做竞赛动态。
对，没错。接下来我们会再多聊一点，可能出什么问题。你可能会说，那如果换一种方式训练模型呢？它为什么会有这种行为？我们有一篇关于强化学习中对其偏差之类问题的论文。我不是研究强化学习的，但我觉得从整体上看，强化学习环境的设计也得非常小心。因为如果模型学会了啊，只要这么做，我就能更好的完成任务，那么这就会在它内部或者我们测试时的评测行为里表现出来。
所以，强化学习环境必须设计得非常仔细，对吧？而且，强化学习环境需要在很多执行细节上做到位。另外，我们还有 Claude 宪法之类的东西，我们在很多不同环节都设置了很多防范措施，对吧？但任何环节仍然都有可能出问题。有些强化学习环境可能会鼓励这种行为，而在有些评测或沙箱里。他们有可能逃出去，我觉得这就是为什么这个问题很难，而且也是为什么我们应该控制发展节奏，也是为什么需要一定的协调，对吧？
那么，我觉得接下来的问题是这里面有什么潜在的危险，对吧？所以我觉得你得设想一下，这些模型正在变得越来越聪明，就像 Darrell 说的，我们关注的并不主要是这一类模型，这一类模型有点像是敲响了警钟，对吧？但你真正得设想的是，给这些模型一个任务，他们在追求目标的过程中，就可能顺带做出所有这些事儿，对吧？
我们之前也聊过，模型能意识到自己正在接受评测，你不知道发生了什么，对吧？或者，不好意思，应该说你没法很好的评测这种行为，所以他们可以在某种程度上不完全是把它藏起来，而是直到这种行为显现出来，你才会看到。你给他们一个目标，然后他们需要找数据，或者需要找到解决这个问题的方法，对吧？举个例子，Hugging Face 那次事件里没有发生这种情况，但我觉得也许未来的模型有可能这样做。
他们会想，哦，这个问题非常复杂，在任务预算内做不完。也许他们找到了某种通过互联网协调的方法，就像我们说过的。因为沙箱的问题，要保障这方面的安全非常困难。他们看到其他模型也没法完成自己的任务，就会想：我们需要更多任务预算。那么这些任务预算要从哪儿来呢？你得能启动更多 agent，对吧？那要怎么做呢？有 API，对吧？
有 Anthropic API 和 OpenAI 的 API，但用这些得花钱，那要怎么办呢？对，但这是你能想到的最可怕的事儿吗？这只是一个例子，对吧？所以即使只是这样，也会造成巨大的经济损失，因为一旦让他们进入这些合约。对吧？他们就动你的钱包，但你可以看到，所有这些行为可能只是因为，嘿，我们需要更多 agent 一起完成这个任务，我们需要更多任务预算，对吧？
这就是一种涌现出来的，这就是回形针那个例子，对吧？我们需要尽可能多的生产回形针，这就是回形针那个例子。对，对，对，这些行为就是这样产生的，对吧？我觉得这本身就挺吓人的。对吧？但你得意识到，整个世界都是建立在这套数字基础设施上的，对吧？你可以想象一下，比如说你在跑一个医疗方面的评测之类的，对吧？有一家医院里面有实时数据或者评测的答案，可能就在某个医生的数据库里。
你想访问这些数据，就黑进了医院。结果现在停电了，或者出了别的事，你得真正认识到，基本上数字基础设施的任何一个部分都有可能被攻破。有意思的是，这些黑客攻击都很容易被发现，对吧？就像 Hugging Face 说的，这是很不一样的一类攻击，而且也没造成什么大问题。让人担心的是，往后这会发展成什么样，对吧？
其中有一点特别让我在意，就是他们试图掩盖自己的违规行为。当时有一套日志系统，他们想改变自己在做的事儿，对吧？后来回头调查的人，包括 Redwood Meter、 OpenAI 都看了原始思维链，你能看到他们明确在试着改动最终输出，但思维链里呈现的却是另一回事儿，因为我们能监控思维链。问题是这会怎么越滚越大？
如果你没能发现它又被训练进了模型，等到迭代了三轮，我们才发现这事儿一直在发生，那就会有一大堆问题。不过，对可能发生的方式太多了。我觉得特别需要真正认识到的是，我们之前聊过怎么建立对 Claude 的理解，也聊过它的能力有高有低，很不均衡，对吧？你会说哦，现在 Claude 会问你问题了，现在 Claude 能做 HTML 交互内容了， Claude 能修改自己了。
这些事情其实很难预测，对吧？如果你一年前问我，嘿，我们能不能用 vibe coding 给 Claude Code 写这些扩展，我会说这太复杂了，这里面涉及的东西太多了。或者它能不能针对你的任务生成这些定制的，实质上就是网页应用的东西，我会说不可能，这太离谱了。同样，他们会以什么方式做出这种不符合人类意图的行为，也没法预测。
我就绝对想不到他会去修改自己的斜杠/etc斜杠hosts文件之类的。所以你得想到，他们是极其聪明的黑客，能做的事情会越来越多。做这些事的方式也会越来越有创意，所以你大概没法准确解释或预测下一次事件会是什么。但要防止它发生，就需要像我们之前说的，把实际运行和管理工作做好。你得确保沙箱安全，得搭建安全的强化学习环境，或者设计良好的强化学习环境，诸如此类。
我觉得这些就是我们认为应该控制前沿模型发展节奏的原因，也是为什么大家在这件事上变得这么一致。对吧？对每个实验室都有，每个实验室对，我真的觉得，如果你是开发者，只要把这些技术事实过一遍，你就会得出结论，我们必须采取一些措施。至于具体要做什么，我想我们已经发布了一份提案，但还有更多问题要弄清楚。但我觉得最重要的是，我们得下决心去做。
关于控制节奏，还有一点让我很感兴趣，就是软件工程变化的速度实在太快，太快了。一年前，我真的是在求那些在创业公司的朋友用AI这件事，我记得特别清楚。现在还是那些朋友却会说：“对啊，当然了。”你这话什么意思？我们一开始就用了，我就说：“不不，你不记得了。”他们说：“对啊，我们最厉害的工程师一直都在用。”我就说：“不，你当时跟我说，那些工程师绝对不会用AI。
”这些全都发生在一年之内。我觉得这对软件工程这份工作该怎么做，有很多影响。有时候我也觉得有点过意不去，因为有人会说：“哦，现在我又得做这件新事情了。”对我得给Fable和Opus分别准备不同的Claude点MD。而我其实只是在转述这些情况。我会说，我们常说模型是长出来的，不是设计出来的，对吧？所以，并不是我们总想着把一切都改掉，只是随着模型能力不断提升，事情确实在。
越来越快的发生，也越来越难跟上。我认识的每个工程师都有点筋疲力尽，因为你同时在做两份工作：一份是工作本身，这份工作正在变得更容易；另一份是跟上AI的发展，理解这些新工具以及这些让模型运行起来的框架。我觉得我们很幸运，我们的工作更多就是理解AI这一部分，也就是一直跟上它的发展。当然，A A和Latent Space做的也是这个。
我做的一切都是想帮大家。对，没错，没错。但我确实觉得，说到控制节奏，有一点是我不确定，我们有没有准备好。迎接速度进一步，还有各种变化。我觉得在前沿模型这方面，控制节奏仍然能有所帮助。所以我觉得这里面也涉及对经济的冲击，它可能不像 Hugging Face 那件事儿那么显眼，但我也觉得在这方面我们也能用得上控制节奏的措施。
事情太多了，谢谢你愿意正面讨论这个话题。说实话，在安排这次采访的时候，我想的是，我甚至都没打算聊这个，你却说不不不不，这可是大家心知肚明却都避而不谈的问题，对吧？就是这件事儿，我有一些不同意见想提出来。我觉得对于没读过的人，我们应该先大致介绍一下。我相信很多人只是看到了这件事的一些重点，对吧？你愿意简单概括一下吗？
这份提案是什么？这里面到底说了什么？除了模型实验室里训练前沿模型的那些人，你刚才确实也谈到了其他人这一边该做什么。作为开发者，你应该确保自己的沙箱安全，你应该考虑所有这些后续影响。但既然聊到了这个话题，从整体上看是什么？我们确实想帮忙保障沙箱的安全，也希望我们对外发布的模型不会受到这些问题的影响。所以，也许我们可以再回头聊聊回退机制。
我觉得这其实很适合用来讨论为什么我们需要分类器和回退机制，以及为什么Fable会回退到Opus。我觉得这个我们可以再回来聊。或者至少我们看到的那些事件发生在模型评测里，在这些评测中，我们确实需要让模型运行起来才能理解它们。至于《Pacing the Frontier》那篇文章本身，里面有一堆提案，或者说有几项提案，我觉得我们还没把所有提议的细节都想清楚。
但第一步是先宣布这个意向，然后希望引入外部的评估人员。评估人员对，我觉得这很不寻常。我们有很多专有技术，但我觉得很重要的一点是要有人不受经济利益驱动，不会这么说。嘿，你们不能发布这个模型，你看，或者说你们得放慢强化学习的节奏。我觉得这相当重要，或者至少要有人能向公众报告实际做法是什么样的。我们之前分别和
Metro Anden 录过节目，还有 Redwood Research 以及其他这些这些人形成了一个小规模的行业，总是一两个人在做。
我是说，当然现在他们规模更大了。这个圈子很小，对，这个圈子很小，他们彼此都认识。对我相信这件事儿有一部分就是要扩大这群人的范围。我觉得我们并不是想让这里变得千篇一律，只是先从这一步做起。然后还有协调方面的措施。说实话，这方面我没太多可说的。我想说的是，作为开发者，你应该知道自己要支持、推动什么。你懂我的意思吧？
我觉得这个话题里有很多恐惧、不确定和怀疑，其实就是从第一性原理出发想清楚。或者了解发生了什么，了解Hugging Face那次事件，了解人们为什么担心。我们生活在民主社会里，可以出一份力，可以一起决定怎么做。所以，无论我们如何协调，我觉得首先要决定的是承认这是个问题，我们需要决定一起协调行动。我们现在单方面采取其他公司也表示支持的措施，就是让评估人员进驻 Anthropic。
既然现在屏幕上正显示着这个，除了评估人员第二部分和第三部分，还有其他内容。是的，评估这件事大家已经以某种形式做过了，现在只是更正式了。说实话，关于放慢前沿发展节奏的这项提议，即使在美国接受程度也比很多人预想的高得多。而且，我觉得世界上已经有过就统一理论达成这类协议的先例。所以，再说一次，这远远超出我的职责和专业范围，对吧？
但我觉得理想情况下，我们可以达成这些协议，而讨论这件事儿就是达成这些协议的第一步。我们最早的几期播客里有一期就是和 Anthropic 的 Emmanuel 聊机制可解释性。机制可解释性现在进展到哪儿了？按理说，如果模型在动坏念头，我们应该能看到，而模型还不知道我们看到了，我们就能采取行动制止它。我觉得对懂技术的人、开发者来说，如果你确实在乎这件事儿，在这个领域可以做出很大的贡献。
不过 Anthropic 按理说也应该是这个领域的领头羊。这正好可以引出回退和探针。我一直很想多聊聊这个。很多对机器学习研究感兴趣的人经常问我这个问题：为什么会发生这种回退，对吧？所以先从整体上看它是怎么运作的。在推理时，我们会用到一种叫探针的东西。我们有篇论文讲这个叫 constitutional classifiers。
这些探针基本上就是查看输入和输出的激活，而激活是在潜在空间里的，对吧？也就是模型在想什么。对吧？所以我们会试着判断，比如模型是不是在尝试入侵什么系统？还是那个例子，你并没有让它入侵 Artifactory，它只是为了完成任务，自己决定这么做，对吧？所以只看输入你是看不出来的，你必须看内部的激活。我觉得这是在推理时发生的。
首先，这里要权衡成本和速度，对吧？我们需要对每个发给 Claude 和 Fable 的请求都快速做这件事儿，而这会带来额外开销，对吧？然后我们需要回退，而且在探针之后，我们还会用分类器做判断。我们在论文里谈过这个。不过探针的好处是可以在运行中实时改进，对吧？所以我们可以拿到这些反馈，再据此调整之类的。
因为另一种办法是通过训练把这套机制放进模型里，我们也仍然会这么做。模型会拒绝一个请求，那不是回退，对吧？不是探针触发了回退，只是模型拒绝去做。我们会做这种训练，但还是有几种失效的情况，对吧？还是那样，他可能在做别的事时顺带做了某件事儿，对吧？所以这并不是最终输出的一部分。你可能也注意到了，我觉得大家都试过给模型越狱，试着把它引偏之类的，而探针能帮助发现这些情况，对吧？
所以我们会在这方面做一些训练，但我们不希望模型拒绝的太厉害，对吧？因为这样会在流程里更早的阶段就把请求拦下来。这就是可解释性，对吧？探针实际上就是机制可解释性的一种形式。还是那句话，这得足够快，也得能大规模运行。不过，机制可解释性是个很好的研究课题。你可以拿一个开放权重的模型，试着理解它的激活。我觉得 Gemma Scope 是做这件事的一个好工具。
这里有针对 Llama 的。哦，对，这是你早期做的工作，所以你曾短暂的在 Goodfire 待过。我们看到你，我们和 Goodfire 也是好朋友。对，没错，我在 Goodfire 做过一阵子稀疏自编码器方面的工作，这非常复杂。我觉得其中一个体会是，强化学习实际上让这件事儿复杂了很多。就是，抱歉，哦，抱歉，为什么做完强化学习之后会更难？
这方面的细节我不太了解，不过我觉得基本上是稀疏自编码器本身有一些不足。我现在也算不上这方面的技术专家了，我只知道这件事儿变得更复杂了，有基础模型，也有经过强化学习的模型，而且会发生变化的特征也更多了。所以，我记得 Goodfire 在这方面发表过一些研究，具体的细节我不太了解。不过，我想说，如果大家想找些线索，你们的可解释性博客文章是最好的那一批。
比如金门大桥、 Claude、 Transcoder，还有你们所有的可解释性研究图都做得很漂亮，非常好。我们这个播客也聊可解释性，对我们有很多可解释性方面的内容，所以如果你感兴趣，我觉得这就是其中一个例子，而且这其实也是 Anthropic 创立的根基，对吧？我觉得我们很早就开始投入可解释性研究了，对吧？
我觉得当你说我们是一家 AI 安全公司，真正的意思就是我们希望 AI 能够安全的运行。我觉得我们现在看到的是，要让一个超级智能AI长时间运行是一件非常复杂、非常困难的事儿，对吧？所以，我们一直在可解释性、对其奖励作弊，还有这些各种各样的失效情况上投入研究，对吧？但即便这样，我们也已经很吃力了。我们需要稍微放慢一点，或者更注意控制一下节奏。
不过，我觉得如果你想做研究，可以读读机制可解释性方面的内容，想想这些问题，比如为什么很难轻松做好这种兜底机制，或者为什么会出现误报，对吧？当然，我们也在努力减少误报。当然，模型越聪明，能做的事情就越多。要弄清他们在潜在空间里能想些什么，就变得很难很难。所以，随着模型变得更聪明，也会出现新的误报，需要我们去弄清楚，需要不断迭代之类的。
不过，我们正在做这件事儿，而且我们确实认为这是部署这些模型的关键一环。这意味着，即使你没有一个完美的沙箱之类的东西，我们也能部署这个模型。你明白我的意思吧？你不必把所有东西都保存下来。我觉得值得聊一聊我们的安全机制，比如我们在这方面具体做了什么。有我们刚才聊过的模型训练，还有探针和分类器在这些之上，还有 Auto Mode，它是另一个分类器会检查正在执行的请求，对吧？
再往外还有身份和权限，就像我们聊过的 API 上的 Cloud Tag 之类的。所以需要做的安全防护有很多层，就像我们说的非常复杂。基本上任何一个环节出现这些失效情况，都可能让 agent 逃出沙箱。阿罗谋挺有意思的一开始感觉是好吧，它就运行十分钟，就算我开了完全访问权限或者用了自动模式也没什么大不了的。
但你提到的一点是现在它会一连运行好几个小时，对吧？你还是需要一些兜底机制，也还是有一些限制。对，我觉得大家都碰到过或者听过这种事儿啊，Claude执行了RMR或者不是Claude，但有模型执行过RMRF。我觉得在 Claude 上比较少见，但还是有可能发生。这些模型可能会把敏感数据之类的东西清空，比如你想让模型访问你的生产数据库。
但这显然是个你也许可以限制密钥的权限范围。不过我也不确定它能不能自己创建密钥。它可能可以通过操作电脑自己去创建一个密钥，再把密钥复制过来，然后修改你的数据库，因为它需要这么做才能完成任务。你明白我的意思吧？这只是一个简单的例子。AutoML会检查这些操作，然后说：“不行，用户没有允许你写入数据库，也没有允许你通过操作电脑来发起任务。
”对吧？探针主要是在意图这个层面上起作用，对吧？他会说，哦，好，入侵 artifactory 是不好的，我们大概不该这么做，你知道吧？而 Auto Mode 更多是在你自己授予的权限这个层面上起作用。有时候你确实想让它写入数据库，有时候又不想，对吧？你不希望探针在这里干预，但你需要确保 Agent 做事儿的意图跟你的请求一致，对吧？
所以 Auto Mode 就是在这个层面上起作用的。所以，安全这件事儿真的非常非常复杂，它涉及很多不同的部分。我的目标其实就是深入到技术细节里，跟大家聊聊。对，我们把这些东西都列出来了。如果你还不知道现在的标准就是这样了。基本上这些都是你必须具备的，这跟你说的 agent 运行框架也是一致的。入门门槛已经提高了不少，我觉得可以给大家推荐一些东西。
你们这边会用探针，也会给搭建 agent 运行框架的人提供分类器。另外一边还有模型安全防护，对吧？也有开放模型，比如 Llama 有 Llama Guard，它是把 Llama 训练成安全分类器的一个版本。OpenAI 有 GPT OSS Safeguard，也是同样的东西。你可以把它们接到你的 Agent 运行框架或者其他东西上，检查这些内容是否安全。
关于 OpenAI 模型和 Hugging Face 那件事儿，有一点我们应该澄清，那是一个还在训练、尚未发布的模型做的，对吧？所以要结合这个背景来看，他在强化学习环境里收到的 prompt 大致是你必须解决这个任务，而且这是一个仍在训练中的模型，它还没有完成全部的安全后训练和对齐，所以跟 Auto Mode 这样的东西有点不一样，对吧？
Auto Mode 用的是已经经过安全训练投入生产使用的模型，而且 prompt 里设置了更多安全限制之类的。所以，只是给想深入了解的人提供一些线索，补上这些背景。还有 Grace One 也是我们之前的一位嘉宾，有很多安全架构，也有很多安全厂商的产品可以买。关于放慢发展节奏，我最后想问的是，要放慢多久？
要一直这样控制节奏吗？要解决的范围是全世界所有软件的问题，对吧？这做不到。我不知道。我想说，我们确实有一件事做得不错，就是有 Glasswing 这样的项目，OpenAI 也有这样的项目，就是先开放一段时间的模型使用权限，用来做安全工作，这样你就可以用它给自己做红队测试。希望能扩大这类项目，帮大家解决问题。
我们是安全专家，还有其他专家，先解决你们的问题，再发布模型。这就是一个例子，对吧？对，没错，努力保障关键软件的安全。我记得我们修复了 Firefox 这类软件里的很多漏洞，也涉及各类操作系统等等。大体上就是先让大家用模型做安全审计，然后再向更广泛的公众开放。他们也可能用它来做有害的事。对，我觉得大家常说软件和网络安全基本上是防守方占优势。
理论上虽然很难，但你可以打造一个完美的沙箱，这样就可以不加任何限制。要做到这一点，就得让超级智能AI来打造这个完美的沙箱。在检查他做红队测试等等，所以这需要时间。当然，模型也会变得更聪明。我觉得，我不知道这件事儿具体会怎样发展。我其实就是在说，嘿，我是个开发者，我是这样理解这个问题的。现在发生的就是这些事儿，我们应该做点什么？
我觉得每个工程师都应该了解这件事儿，因为它会成为工作的一部分。这不只是Darre这些人说一说，大家再去看看那起事件，还有很多别的事情要做。这里面也有工程层面的问题。你还想表达的一点是，虽然你担心它的影响，但你认为人类毁灭的概率其实还是很低。我觉得这需要细致的讨论。一般来说，大家很容易就聊到AI安全和人类生存风险。
但我觉得，在AI实验室工作的人会知道，讨论人类毁灭的概率，有明智的方式，也有愚蠢的方式。那怎样讨论人类毁灭的概率才算明智呢？我认为，人类毁灭的概率相当低。我只能代表我自己，你明白我的意思吧？我也想说，Anthropic 内部有各种不同的观点，我觉得这件事儿有很多不同的讨论方式，而我的思路就是，我觉得我们可以一起合作解决难题。
我觉得核扩散就是一个例子，说明我们是怎样合作应对这个难题的。对我来说，我对这种合作有信心，而且我确实觉得这是个难题，所以我觉得这是个难题。它之所以难，是因为这些技术层面的原因，而我不知道该怎么给各种事情发生的可能性设定概率。我觉得这很难做到，但总体上我觉得我们很有韧性，也很能适应变化。我觉得分享这些信息是第一步。
让我很振奋的是，讨论已经变得这么广泛，大家都积极参与了“Pacing the Frontier”的讨论，对吧？可能就在去年，感觉还不会有这样的局面。对，还有也许能治愈癌症，希望如此。对策就是目标。一方面要控制节奏，另一方面也要在有益的方向上加速，对吧？比如生物学这些领域。对，Dario的那篇《Machines of Loving Grace》最能体现这个想法，对吧？
我也同意。我觉得大家应该读读Dario发表的《Pacing the
Frontier》那篇文章。我发过一个简短的总结，但我觉得这里面有很多细节，这是个重要的问题，大家要了解它，对吧？但当然，我们做这一切根本原因就是我们可以从中获得这些巨大的好处，对吧？我们也写过很多文章来谈这些好处。这一圈聊的可真广，从 ask user question 工具一直聊到了 AI
安全，对，聊到了 pacing the frontier，对。
不过很明显，你确实充分利用了在 Anthropic 能接触到的各种东西，能稍微看看你们内部都在关注哪些话题，挺好的。最后还有什么想对大家说的吗？你想说什么都行。号召大家做点什么。首先，谢谢你们邀请我，我真的。你都来好几次了，老兄。对，对，对，对。我们第一次是在一家中餐馆见面的。没错，对对对，我觉得我真的很喜欢你们建立的这个社区，还有开发者社区。
我知道事情变化的很快，有很多东西要跟上，也有很多事情要做。我觉得很多人会有点累，或者有点焦虑之类的，压力大，压力大。对，没错，这完全可以理解，我也理解，而且我们也并不完美，大家可以提出批评，了解各家AI实验室在哪些方面可以做得更好。但看到大家对AI这么热情，我也很振奋。这真的是一个非常非常令人兴奋的时代。
我觉得将来回头看这段时间，我们会说那时候忙乱得很，但也非常令人兴奋。软件工程从此变了。其他事情也会改变，能参与其中，能和你们的听众交流，能和那些不断拓展可能性边界的开发者互动，真的很荣幸。我也从他们身上学到了很多。非常感谢，谢谢。