Anthropic 的 Thariq Shihipar 谈 Claude Code 的未来：Mods、可变软件与多人智能体
点播放，字幕跟着声音走
Subtitles follow the audio
逐句文字稿
点任意一句，从那里开始听
正在加载字幕…
-
我觉得就是不同的模型彼此差别很大，但我也意识到维护不同的版本实在太麻烦了。
-
随着模型越来越好，它们完成简单任务的下限也更高了。
-
我确实认为，从极限来看，cloud.md 最终会消失。
-
也许甚至不用等到那么远。
-
我觉得现在可能更好的做法是，新建项目时先不要 Cloud.MD。
-
我觉得也许当你看到非常反复出现的失败模式时，再把它们加进你的 Cloud.MD。
-
真正麻烦的是，这种情况会因模型而异。
-
所以如果你加了一堆失败模式……
-
那你就需要 Fable MD，需要 Opus MD。
-
就算是 Fable 5.1 和 Fable 5 之间，也很烦人。
-
我们不是故意这么做的。
-
模型就是这样工作的。
-
所以也许 Fable 5 有某个失败模式，而 Fable 5.1 没有。
-
如果你一直保留这份记录着一堆不同失败模式的上下文日志，它们很可能会过度约束 Claude，你懂吧？
-
所以这就像，我们其实刚刚给 skills 加了 eval 插件。
-
所以现在你可以评估一个 skill 是不是更好。
-
在进入今天的节目之前，我有一小段话想对听众说。谢谢。
-
如果不是你们选择点进来收听我们的内容，我们就没法把你们显然想要的 AI 工程、科学和娱乐内容带给你们。
-
几乎每天都有人来找我们谈赞助，但幸运的是，订阅我们的人足够多，让这一切在没有广告的情况下也能持续下去，我们想保持这样。
-
但我只想请大家帮个忙。
-
你能做的最有力、而且完全免费的一件事，就是点一下那个订阅按钮。
-
这是我这辈子唯一会开口求你们的事，而这对我和我那个每周拼命努力把 Latent Space 带给你们的团队来说，意义重大。
-
如果你订阅了，我向你保证，我们会一直努力把节目做得更好。好，现在我们进入正题。
-
我们现在在演播室里，和我们的朋友、来自 Anthropic 的 Tarek 在一起，我猜总的来说，在 Claude Code 这块，各种边界都在不断融合，而你自从加入 Anthropic 以来，一直对一切都了如指掌。
-
你很早就开始用 Claude Code 了，而且你也在别的播客里讲过这段经历，你还一直在谈“像智能体一样看问题”这件事。
-
最近你做了 AIE 上那场很精彩的演讲，还写了几篇 Fable 的指南——当然 Fable 是你们自己发布的，所以那算是作弊了。
-
最近你们还发布了 Claude Tag，我们等下也会聊聊 Frontier 上的节奏问题。
-
Anthropic 现在事情真的很多。
-
我想最核心的问题是，在 Anthropic 工作，周围有这么多事情同时发生，是什么感觉？
-
我觉得，有时候真的会有点晕头转向。
-
我觉得，当初我加入 Anthropic，就是因为 Claude Code。
-
Claude Code 刚出来的时候，我就想，这也太好了吧。
-
而 Opus 4 对我来说，就是，我根本想象不到它能这么好，你懂我意思吧？
-
那对我来说真的是一个关键时刻。
-
但当时我还在努力说服我那些创业的朋友用智能体编程，他们就说，不行，我们的工程师觉得还不够好之类的。
-
我当时就想，这太离谱了。
-
结果快进不到 12 个月，这就成了所有人写代码的默认方式。
-
我觉得，从当初要推销它，到现在要教大家怎么把它用到极致、怎么更高效之类的，这本身就是一个很大的转变。
-
而且，嗯，是啊，我觉得，作为一个人，真的很难跟上所有事情，你知道吧，事情发生得太快太快了，而且，我是说，是啊，智能体那套东西的扩展性确实比人强太多了。
-
或者说，就像，哦，现在同时有三件事在发生。
-
而且这些全都是紧急的事。
-
那你怎么去应对呢？
-
你的时间都花在哪些方面？
-
你写了很多技术文章，也做工程方面的工作。是的。
-
所以我觉得，我加入 Cloud Code 团队的时候，就是想教大家怎么用 Cloud Code，基本上就是这样。
-
我本来以为这件事我可能只会花一点点时间，或者说我一开始是先花时间在 agent SDK 上的。
-
而且我不太确定，在 harness 这方面，那个“苦涩的教训”会怎么应验。
-
我觉得有时候我们会想，哦，Cloud Code 之后是什么？你懂我意思吧？
-
所以一开始我就想，我只想教大家怎么用 Cloud Code，让 Cloud Code 更好用。
-
我觉得就是这样，随着 harness 越来越好，现在最主要的问题就是你怎么去用这些智能体，对吧？
-
这真的是一件很考验技术水平的事。
-
所以我做这些，然后我也做工程方面的工作。
-
我会去做演讲，但我觉得我做工程工作的时候，我的目标是拿到用户给我们的反馈，然后还能去讲，嘿，怎么用 Cloud Code 来做工程。
-
所以这中间就形成了一个挺好的循环，是的。
-
是的，给听众说一下，我们会把你和 Sarah 在 DevRiders meetup 上做的那场演讲附上，我们之前也聊到了一点。
-
就是先做事情，然后再讲你做的事情。差不多是这样。对对对。那 reap 呢？
-
对，reap，还有 reap。差不多是这样。
-
好，那先稍微预告一下，我们要聊一聊 harness 的演变。
-
它已经从只是一个 CLI 走了很远了。
-
我们要聊 Cloud Mods，它今天开始泄露了，因为你没法把它保密住。对对对。
-
那儿，那儿有很多，呃，东西。
-
我觉得你一开始是加了那个“向你提问”的工具，大家其实又爱又恨。对。
-
我其实觉得那玩意儿挺有创新性的。
-
然后现在我自己也有了一个版本。
-
你有你的，你的，你的“采访我”版本。
-
而且，呃，对，每个人都有自己的那一套东西。
-
再说一遍，这已经不重要了，因为现在你该做的是，呃，写提示词去生成别的提示词、循环之类的这些东西。
-
那么，现在最前沿的做法是什么？
-
你现在让大家怎么做？
-
对，“向你提问”是第一次模型在需求澄清上做得不错。
-
我觉得这算是一种涌现出来的行为，我当时就想看看模型能不能做到。
-
我算是有人机交互的背景，本科和研究生都学这个。
-
所以对我来说，这有点像人机智能体交互，就是想搞清楚智能体怎么跟你沟通、怎么把你的需求挖出来。
-
我觉得随着 Claude Code 用得越来越广，有个难点就是每个人都有自己的用法。
-
而且想改默认行为其实非常难。
-
比如说，有人让 Claude Code 做某件事，有时候他就是想让它直接干活，因为他可能很会写提示词；而有时候他其实不太会写提示词，你懂我意思吧，这时候智能体就需要去澄清，对吧？
-
所以这是个挺好的分界，“向你提问”这个工具差不多就是沿着这条线来分的：你觉得自己已经足够清楚、能直接指挥智能体了，还是说智能体需要多挖一些需求、跟你多协作、真正搞懂你的偏好。
-
我总体上认为，绝大多数人其实更偏后者而不是前者，也就是说他们的需求更模糊，对问题的了解比他们自以为的要少。
-
但要让它变得容易，这其实是个界面设计的问题，你懂我意思吧？
-
所以如果你在设计一个问题，或者在梳理一个问题，像 schema 是什么、调用栈是什么这类东西就非常重要。
-
你知道，细节和设计很重要。
-
理想情况下，你希望在开始实现之前就提前弄清楚其中一些难题。
-
对，这就是为什么它们被称为未知数，对吧？
-
所以我认为，在智能体编程中，弄清楚你的未知数将永远是一项技能。
-
因为即使模型超级智能，它也需要知道你想要什么，你懂吧？
-
而且你有自己的偏好，你需要把这些偏好梳理出来。
-
所以这就是我认为我在推动的方向。
-
那么问题就是，智能体如何与你互动？
-
我认为 HTML 一直是实现这一点的主要方式。
-
我们最近还添加了 artifacts，对吧？
-
而且对于 artifacts，我其实觉得我们在解释如何充分利用它们方面做得不好，或者说我在解释方面做得不好。
-
我们有很多强大的能力。
-
它们关联着一个数据库，你知道吗？
-
所以每个 artifact 都可以存储和写入持久化数据。
-
它们可以把数据反馈回 Claude，你懂吧？
-
所以，有一件事人们还没在做、而我在努力鼓励的，就是这种仪表盘 artifact 的想法。
-
比如你让 Claude 长期处理一个项目。
-
也许是个看板之类的。
-
它可以把看板数据存到数据库里。
-
多个 Claude 可以通过 artifact MCP 访问这些数据。
-
而且那个 artifact 也能跟那些 Claude 对话。
-
所以我们基本上是在搭建一些基础组件，让你能通过 artifact 拥有这种生成式界面，从而把 agent 那些丰富的细节更多地呈现出来。
-
我觉得现在 agent 领域几乎所有问题都是这个：你以为你知道自己想要什么，但其实你并不真的知道，而 agent 需要大量细节，在过程中跟它们协作非常重要。
-
所以 artifact 就是我们试图往这个方向演进的方式。
-
但还有很多工作要做，因为这比一道选择题复杂太多了。
-
针对那个问题，图、代码片段、schema 之类的细节要多得多。
-
但 artifact 算是更“AGI 信仰派”的做法，基本上就是用来向你提问的。
-
关于 artifact 这块，有一点我不太清楚：哪些反馈应该通过 artifact 来给，哪些反馈应该通过 Claude、通过聊天来给。
-
因为更“AGI 信仰派”的做法是把所有东西都喂给 Claude。
-
我觉得更“AGI 信仰派”的做法是通过 artifact 来给。
-
我觉得我们大致设想的是，极限情况下，artifact 会成为你进入 harness 的界面，你懂吧？
-
你可以对你计划、工作的这份实时文档做评论。
-
你也许能看到多个 agent，不同的 agent 在做不同的事。
-
而那个 artifact 是为你当前正在做的工作量身打造的，对吧？
-
所以每一个都略有不同。
-
我觉得从基础设施的角度看，我们还在往那个方向走。
-
但没错，我觉得为你的 harness 提供即时生成的界面，大概就是未来的方向。
-
有没有一个版本，它是从 CLI 或聊天中抽象出来的，而且是你——因为现在很多情况是，好，你在跟 Claude Code 交互，它给你返回一个 HTML 做原型图。这已经挺丰富了。
-
有图，artifact 是把这些东西连起来的方式。
-
那为什么不干脆全都这么做呢？
-
然后这就变成了把东西分开来看：推理在哪里发生？智能在哪里发生？工作在哪里发生？
-
你知道，我觉得这有点像本地和云端之间的区别，或者说它们之间的一些区分，对吧？
-
所以我觉得现在如果你用 Claude Code，它就是本地的，比如你可以启动远程控制来获得一些云端行为，或者你可以在云端启动 Claude Code，对吧？
-
我们正在走向这样一个地方：不再是云端，而是你给一个本地的 Claude 发消息，它在本地启动一个会话并执行，更像是你有一个在云端运行的 Claude，你给它发消息。
-
它可以运行本地会话，也可以运行云端会话。
-
这大概就是 Claude Tag 的工作方式，但随着时间的推移，我们也会加入本地 hands。
-
所以本地 hands 就是让那个 agent 在电脑在线时能够访问你的电脑，你知道，并且能在那里工作。
-
然后它可以衍生出许多不同的子 agent。
-
它可以，那些子 agent 可以互相通信。
-
这就是 artifact 登场的地方，基本上用来展示所有这些工作。
-
所以你可以想象，你把这些东西分开来，所以有一个表面 UI 显示，那是一个 artifact，托管在某个地方，有数据库什么的。
-
还有推理智能，对吧？
-
那是在云端发生的，你不用操心关掉电脑之类的，对吧？
-
然后还有类似 hands 的部分，它可以是本地的。
-
它可以在远程沙箱里，或者在你需要完成工作的任何地方。
-
这就像是把现在的 Claude Code 体验拆解开来。
-
或者说现在一切都发生在一个地方，对吧，所以。
-
你怎么看这方面的多人协作那一面？
-
比如说团队想以这种方式工作，现在这非常个人化，但你怎么看多人协作的未来？
-
就像现在我想有 Claude Tag，它是一个版本，但。我们正在推出 projects。
-
所以 projects 就是这样一个抽象，有点像 Claude Tag，但是在我们 Cloud 产品上的，对吧？
-
所以你可以给它发消息，它就会做 Claude Tag 那些事，比如派生出子代理。
-
所以我们觉得在多人协作这块，Claude Tag 更原生一些，因为它就在你的 Slack 里，权限什么的都已经搞定了。
-
但我确实觉得多人协作是故事里很重要的一部分，而且需要更多地串联起来，你可以想象这有多复杂，比如你有手，但现在别人的手里也有手，你得给它们授权，或者你有你的
-
MCP，别人有别人的 MCP，你怎么搞清楚该怎么用它们？对吧？
-
这就变得相当复杂，而 Claude Tag 在磨平这些问题上做得很好，对吧？
-
所以比如你有 Google Docs，它是怎么访问 Google Docs 的？对吧？
-
它是通过共享的 Cloud MCP 访问的，或者如果没有访问权限，也可以通过你本地的凭据访问。
-
不过是的，我觉得 Claude Tag 就是我们的多人协作产品，对于那些本质上就是多人协作的事情特别有用，比如 on-call，比如事故处理，本质上就是多人协作的。
-
你想 @Claude，你想让多个人登录进来，你想能找到上下文。
-
我觉得每当我在做某件事、想要隐私或安全的时候，我就想让别人来审阅。
-
这真的很好用，我会给每个项目建一个频道，比如我会在法律频道里说，嘿，我想发布这个，你能不能，你看，Claude 什么都知道，你就跟它聊。
-
这样法务就能得到精确的答案，比如到底什么内容会被发布到代码里。
-
而我不需要一直在循环里，对吧？
-
所以我觉得多人协作越来越是，对，每个人都能和 Claude 一起参与。
-
我觉得 Claude Tag 就是那样的产品，而 projects 会从单人开始，然后我们会，你知道，再扩展。
-
我觉得这里有个问题，也许是两个问题，关于身份和隔离单元。
-
Claude Tag，你特意选择让它有自己的身份，这是个有争议的选择。还有别的方式可以做。对。
-
Cloud projects，听起来大概是，你知道，如果它像 ChatGPT projects 的话，那隔离单元就是那个 artifact，那个 Cloud 实例，大家都在上面协作。
-
听起来应该是这样，如果你在跟法务协作处理这件事，那个频道就应该是一个 project。
-
现在还不是，但这是自然的下一步。
-
对，我是说，我觉得在 CloudTag 里，它实际上……
-
CloudTag 里你得自己安排，基本上是这样，所以 CloudTag 里每个频道就是……
-
你想怎么命名都行，我基本上是把每个功能都命名成一个频道。
-
我觉得这里有一些迁移……
-
就是说不清楚什么时候会有迁移，因为比如说你有个同事被标记在所有这些东西上，是的，会有迁移，因为是同一个人。
-
但换成 Claude 就不清楚了，它是不是必然就像，嗯，不对，你并不知道其他那些东西。
-
你应该只用这些东西。
-
就像冰山一角那个梗，对吧？
-
你可以这样，这就是我们花了大量时间的地方，基本上就是，有无限的表面区域，好吧，你想让 Claude 去，不是无限，
-
但有很多表面区域需要弄清楚，权限、可见性，以及你怎么能让 Claude 尽可能好、尽可能安全地运作。
-
显然这对我们非常重要，因为我们代码库的安全非常非常重要。
-
所以我们在这上面投入了很多时间。
-
对，有太多边缘情况你能想到，比如，哦对，这个频道里的这个 Claude 有不同的权限，但它可以给另一个频道发消息，不能那样把数据偷出去，或者，如果它用了你的 MCP 然后给别人发消息呢？
-
有太多太多了，我们真的花了很多功夫把它打磨平。
-
对对，很多功夫。好，Fable。
-
Fable，你写了两篇好文章。
-
我是说，你写过很多好文章，但比如那篇《Fable 实战指南》，讲构建 Claude Code 的。
-
我很好奇，从你看到的情况来说，你在顶级用户身上有没有发现什么共同的模式，Anthropic 内部的、外部的？
-
比如充分利用 Claude Code 的最佳实践是什么？
-
我说的那个元技能，就是提示词，这个非常重要，你知道吗？
-
而且我觉得这话说起来可不简单，因为很多人会觉得，哦，提示词根本不重要。
-
就好像，我随便说一句话，Claude 就能搞定。
-
但我觉得提示词真的很像，就像，它很像公开演讲，你知道吗，或者写作之类的。
-
而且是面向特定的受众，那个受众就是 Claude，你需要对 Claude 建立起心智模型，了解它怎么思考、怎么运作，对吧？
-
所以跟 Claude Code 打交道最重要的技能，就是拥有这种心智模型，对吧，了解 Claude 擅长什么、能一次搞定什么、搞不定什么。
-
所以很多人，你看他们写提示词，都很短，但他们对 Claude、对代码库这些东西有非常好的心智模型，所以用起来毫不费力，你懂我意思吧？
-
但这东西的天花板很高。
-
所以花大量时间去写提示词、去建立心智模型、去培养对智能体运作方式的直觉，这种功夫真的很重要。
-
然后我觉得下一件事，就是我们之前聊到的那些未知的东西，就是能够搞清楚你不知道什么、你还没写下来的东西是什么，去了解各种不同的东西，我觉得，随着 Claude 能做的事情越来越多，
-
你去做一件对你来说属于分布之外、你又没什么领域知识的事情的可能性，是非常非常高的。
-
你越能学会那些词汇，好去给 Claude 写提示词，这就变得非常重要。
-
我觉得最重要的未知是未知的未知，就是那种你根本不知道这东西存在的情况，对吧？对，没错。
-
我觉得这就像是地图和疆域的一个例证，对吧？
-
就是你会觉得，好，这是我的提示词，而疆域是智能体实际需要去做的那些工作，对吧？
-
如果你非常精确，你就能给出更精确的东西，对吧？
-
所以比如在设计方面，我就不太精确。我不是设计师。
-
所以我会说，给我来八个不同的设计稿。
-
但如果我是设计师，也许我会说，哦，嘿，这里有一些参考网站，我想要这种字体、这种风格，然后这里有几个不同的组件，
-
比如在这里把 Figma 的 MC 画板可视化出来，带进来，你知道吧，这样你用那套语言就能精确得多；而如果你不是设计师，你就只能试着去学那套语言，基本上就是去学那些未知的未知，我觉得什么事都是这样，你越能去琢磨
-
跟 Claude 一起琢磨事情是怎么运作的，提示词就能写得越好。
-
我觉得另一个很好的例子就是游戏设计，你知道吧，很多人都说，哦，我现在能靠感觉随手编个游戏出来了。
-
然后他们说，这游戏不好玩。
-
而游戏设计这事的点就在于，这里面的每一个选择都有很多变化，都很有讲究。所以就是，哦，好吧。
-
比如你做一款飞行游戏，飞机的手感、它对你操作的响应方式，这里面门道可多了，你知道吧，一个游戏设计师会在这上面花好几天。你懂我意思吧？
-
对我来说，这就是品味，对吧？
-
就好比在 1000 个数学上都成立的答案里，
-
挑出那个让人一看就说“对，就是这个”的。
-
说到品味这个词，我其实挺纠结的，因为我觉得你说得对，但每个人定义都不一样，而且这词听起来有点像在说低技能，甚至有点精英主义，好像是在说，哦，有些人就是有品味。
-
所谓品味，就是我说的才算品味。对对对。这帮人没品味。对，就是这样。
-
哦，好像工程师就没品味。
-
而我这个创始人，才有品味。你懂我意思吧？但我觉得这其实不对。
-
我觉得工程师在这些特定问题上很有品味，而且我觉得每个人在特定的问题上都有自己的品味。
-
我记得 Jason Liu 说过，要有品味，你得先吃，你知道吧？
-
我特别喜欢这个说法，就是说，好吧，你得做很多事情，
-
你得不断迭代，搞清楚自己想要什么、喜欢什么，你知道吧，然后建立起那套领域词汇，之后你在写提示词的时候，就是在把这一切综合起来。
-
别人把你想说的话说得比你还好的时候，是不是很烦？
-
就感觉，靠，我这辈子都得引用这哥们了。
-
得一辈子引用 Jason Liu 了，他肯定爱死这个了。
-
所以我会收到一些提示词，你懂我意思吧？
-
有时候其实根本不是那么回事，有时候就是凭直觉，对吧？
-
就是你都没意识到自己想要什么，直到模型把它做出来，你一看就觉得，这个明显更好，对吧？对对，就是这样。
-
有一点我一直来回纠结，就是我觉得我有一半时间写提示词的方式，比如说我用语音。
-
有些人用语音，有些人也用语音。那正好相反。
-
就像我一个人絮絮叨叨说个两分钟，按住功能键，然后松开，然后就指望它能搞明白。而且很多时候它还真能。
-
但这不像那种结构化的提示词那么深思熟虑，就是那种，你知道，像写PRD或者备忘录一样好好组织过的沟通。
-
这跟大家实际的做法一致吗？
-
基本上提示词是双峰的，有些提示词你会花很多时间提前打磨，另一些你就是随手一写。
-
我倒不觉得语音就一定信息量低。
-
我觉得更关键的是提示词里有多少信息。
-
你可以嗯嗯啊啊，加几句话，然后说，哦，其实我中途改主意了，它也能完美地跟上。你懂我意思吧？
-
所以我觉得文本的具体格式没那么重要，更重要的是，就是里面有多少信息，对吧？
-
而且我觉得对语音来说，很多时候，回到人机交互这个角度，对很多人来说，说话就是比打字容易多了，你知道吧？
-
如果这样能让你多说点信息出来，那就是更好。
-
某种程度上，感觉在开始之前给模型尽可能多的上下文，而不是光靠提示词，算是个最佳实践。
-
我不知道，很多时候，比如我第一次试Fable的时候，我花了整整30分钟认真打磨一个很长的问题。我觉得这也是模型运行时间越来越长带来的一个反应，对吧？
-
当它们已经在循环里跑起来的时候，还是有点难去推它们一把，但我就是会直觉性地花更多时间去启动第一个提示词，然后跟它大量地配合。我个人的看法是，如果我是一名软件工程师，如果我，你知道，比如自己在跑一个创业公司，
-
我觉得我大部分时候会坚持用Max 20X，你懂我意思吧，可能验证和代码审查算是分开的两回事。
-
但我觉得我经常看到的是，人们在做这种事的时候会撞到速率限制，就是那种，哦，它干了好多活。然后你就说，哦，我不喜欢这个。
-
就是，你能不能撤销这个然后重做？
-
然后你就在这个本来模型 upfront 多花点时间、或者给个更好的上下文就能搞定的东西上反复迭代，你懂吧。
-
结果就变成，你说，不行，我不喜欢这个设计，试试这个，或者，你是不是把这个搞砸了之类的。
-
然后这就额外吃掉你多得多的用量，你知道吧。
-
所以我觉得这可能是效率上的一个关键点，对吧。
-
而且我觉得，上下文，不光是关于目标是什么的上下文，你懂我意思吧，这很好，对吧？
-
比如，你是在做原型还是在做生产环境的东西？
-
比如，你哪里能花算力，哪里不能花算力？
-
我觉得有时候你得给模型许可，或者不给许可去做某些事，因为你知道，它没法凭直觉知道你在这个任务上想花多少，对吧？
-
这个你可以用 effort 来控制。
-
所以我在写一篇关于这个的博客文章，就是说，你知道，如果你想，我们看到 effort 基本上会随任务的复杂度而扩展。
-
所以对安全来说，effort 带来的效果大得多，高 effort 对比低 effort 会让评测结果变化很大。
-
但对软件工程来说，它变化就没那么大，因为 effort 主要花在验证和边界情况测试之类的事情上。
-
所以能这样给模型指导，说，嘿，这个问题我觉得我想让你花很多时间去验证和做边界情况测试，你懂吧。那模型这块怎么搭配呢？
-
所以，你知道，有 Opus 和 Fable，都带 effort。
-
里面还有 Haiku。对对对。
-
现在还不完全是这样，但我觉得非常接近了，前沿模型会在几乎所有方面都帕累托占优，你知道吧，也许，而且有时候我觉得 Opus 可能就帕累托占优。你懂我意思吧？
-
我觉得这取决于事情怎么发展，比如是不是更新版本的 Opus，但我觉得越来越会是，那个聪明的模型能用更少的 token 把简单任务做了，比起其他那些模型，
-
基本上，因为验证，有了验证，在极限情况下，你的模型根本不需要验证，对吧？
-
如果它是完美的模型，它就把活干一遍，然后说，好了，我搞定了，你懂吧？
-
而且随着 Fable 越来越强，我就在想，你真的需要起个 Chromium 然后给所有这些截图吗？
-
就像，我看到了，你做到了，对吧？
-
所以在更高投入下，你会花更多那些 token 去验证。
-
但如果你处理的是更简单的问题，而很多软件工程就是这样，你知道，比如在 Fable 里，低和中等能力下，它可以花更少的 token 去验证。
-
而且随着模型越来越聪明，它们就能直接说，好了，搞定了。
-
你知道，我可以为了保险起见跑一下 lint，但就像，你知道它能过 lint。你懂我意思吧？
-
就像你甚至都不需要做那个。
-
那基本上会比那些更小的模型在 token 效率上高得多，对。
-
我们这边有没有什么好的做法，能看出自己是不是用了太多投入？
-
我真是特别讨厌在这种事情上浪费时间。对对对。我懂你意思。
-
我觉得，在这篇博客文章里，我的大致分布是，代码审查和安全基本上应该是高或者最高。
-
还有软件工程。按领域来设置。
-
对，我觉得如果你在做 UI 之类的东西，低和中等就行，如果你在构建 API，想确保覆盖足够多的边界情况。
-
你知道，所以我觉得建立，就像我说的，那种关于事情在这些分布里怎么运作的心智模型，就是工作的一部分。
-
这更多是靠直觉，还是说，我猜这也会变。对对。所以我在博客里做的是，我把所有 terminal bench 的评测都过了一遍，大概有 70 个问题，然后我展示说，好，你知道，在安全类问题里。
-
它做得更多，然后我也看了一些对话记录，就看它是怎么
-
答案是什么，它忘了什么之类的，很多时候，这也是我的一个提示技巧，就是让它写决策笔记或者实现笔记，因为在它面对的几乎每一个评测问题里，它都会想到正确的解法，你知道，
-
然后决定不做，你知道，就像，哦，答案是这个，如果我这样做呢，然后，哦，大概不行，你知道，嗯，然后继续往下走。
-
而这占了失败的大多数，你懂我意思吧？
-
在比较高的最高档位下。
-
模型完全不知道怎么做一个事情，这种情况非常少见。
-
如果你只有这些实现说明，那你就可以审阅一下，然后说，哦，其实我想让你做这件你没做的事。
-
总的来说，模型在把这一点呈现出来方面越来越擅长了。
-
比如我在 fable 5.1 的对话记录里看到，当它产出这种输出时，它也会把自己的决策过程讲出来。
-
但在 harness 里把这一点做得更明确会更好。
-
而现在我们允许你以各种方式修改 harness，这样你就可以在那里加一些能力。
-
对，所以我确实想点出你提到的两件事，我觉得它们其实存在于提示词之外。
-
一个是，我们姑且称之为那种重要到不该放在提示词里的提示词。
-
它其实是在 Cloud MD 或者 Agents MD 里，就像是，对吧？
-
比如你的处境、你的目标、你想要这个东西做到的那些事。
-
然后第二点是决策日志，或者实验日志，或者随便什么你想让它在当前会话结束后还能留下来的轨迹日志，用来做那些事。
-
这些就像是外部的东西，没有标准。它不像 skills，不像 HCP，没有标准。
-
它就是一个 markdown 文件而已。
-
首先，是这样吗？
-
CloudMD 要消失了吗？
-
你公开表达过不喜欢 AgentsMD，但你还是打算做。
-
对，对，好吧，我是说，agents.md，对，我们打算做。
-
我觉得就是，不同的模型彼此差别很大，你懂我意思吧？
-
但我意识到，维护不同的版本实在是太麻烦了，你懂我意思吧？
-
而且，随着模型越来越好，它们完成简单任务的下限也更高了。
-
所以我确实认为，极限情况下，cloud.md 会消失，也许甚至不用等那么久。
-
我觉得吧，现在可能更好的做法是，开一个新项目的时候先别用 cloud.md。对。
-
我觉得，也许你要是发现某些失败模式反复出现，就把它们加到你的 cloud.md 里。
-
真正麻烦的是，这东西每个模型都不一样。
-
所以，如果你已经加了一堆失败模式，或者甚至说，有了 Fable.md，你就还需要 Opus.md。
-
甚至 Fable 5.1 和 Fable 5 之间也不一样，你懂吧，就是很烦人。
-
我们不是故意的，我们并没有刻意这么做。
-
这就是模型本身的工作方式。
-
也许 Fable 5 有某个失败模式，而 Fable 5.1 就没有了。
-
如果你一直保留着这么一份记录各种失败模式的上下文日志，它们很可能会过度约束 Claude。你知道吗？
-
所以，我们其实刚刚给 skills 加了 eval 插件。
-
所以现在你可以评估一个 skill 是不是更好了。
-
我记得是我们团队的 Daisy 做的这个。
-
所以，对，我们正在努力解决这个问题。
-
我们知道，你还是得在这上面花 token。
-
而且，你知道，它并不完美，但我们在努力帮忙解决这个问题。
-
说到提示词，我想给的一个建议，是我跟很多人讲过的一句话：足够高级的提示词，和足够高级的高管沟通，是分不出区别的。
-
所以我其实把 Heavybit 的这个叫 Executive Commons 的工作坊称作我职业生涯里见过的最好的。
-
他们教一个叫 SCQA 模型的东西。直接谷歌一下就行，确实有这么个东西。
-
人们做提示词已经做了几十年了。
-
只不过它叫高管沟通而已。
-
就像一个人要跟组织架构下面成千上万的人沟通时，你就是这么做的。
-
所以，情境、复杂化、问题、答案，这就是你写备忘录的方式。
-
但显然，有时候你并没有答案。
-
但你至少可以把情境和问题列出来，然后他们里面还有一些示例。
-
所以，就是给想深入探索的人留一些线索。
-
我是说，在我们继续之前，我想问问你还有没有其他被低估的技巧，能让人们从 Cloud Code 里获得很大价值但还没用上的？有。
-
我是说，我觉得很多都在那个，那个不太为人所知的，像一份文档，我给了很多示例提示词，比如用它来做头脑风暴，用它在你之后考你，嗯，我们还加了这个，就是，呃，叫“像跟五岁小孩解释”的技能，
-
其实这个提示词很短，甚至都没写“像跟五岁小孩解释”。
-
基本上这个提示词的关键词就是“大局、少字”，你知道吧，这就是核心。
-
而且效果好得惊人。
-
我记得我基本上在推特上发过这个。
-
它特别擅长直接砍掉那些废话，然后说，对，就在这里。
-
所以图表相当清晰。
-
我觉得 artifacts 有个真实的问题，就是人们往里塞太多文字，结果大家根本不看这些 artifacts，你知道吧，所以这个就把它简化了很多，而且，对，这个其实是 Anthropic 的人在处理非常复杂的事故时，想着“到底发生了什么？”才做出来的。
-
你知道吧，所以这个我觉得很棒。对，我这边的版本其实是，它会测试你的理解，给你几个选项，然后如果你真答错了，就说明你以为正在发生的事和实际发生的事之间有偏差。对对对。
-
我觉得这就是那种大家都爱聊、但真正去做的人很少的事。
-
就像我，你知道，我觉得确实，对。
-
对，但大多数人就是不想被考问什么东西。你懂我意思吧？
-
可惜的是，我觉得这就是我们需要的那种东西之一。
-
“问你问题”的反义词是什么，或者说在事情之前问你问题。对。这个是在事情之后。没错，对对对。
-
这是个让自己保持清醒的好办法，就是问问自己，你到底知不知道自己在干什么，对吧？
-
最糟的情况就是，别人发给你一堆垃圾，他们自己都没搞明白自己在要什么，或者输出会是什么样。
-
然后你就会想，哥们，我根本不想看这个。你自己知道这是什么吗？
-
所以，你知道，你给自己定个规矩：发东西之前，至少得知道实现了什么。
-
对，但你可以把这个做成一个 mod，你可以自己建一个 mod，来确保你测试过它。
-
所以对，我们可以聊聊这个。
-
我们直接进入正题吧。什么是 Cloud Mod？
-
这张图展示的是什么？好，行。
-
Cloud Mods 基本上就是，你可以自定义整个 Cloud Code 的 harness。
-
然后我们会，如果你有需求，我们会让你，你知道，就是，请告诉我们，我们会加越来越多。
-
这个对 CLI 有效，对桌面端也有效。
-
也许将来对 Cloud Tag 也有效。我不知道。
-
就像，你知道，我们想把这个做得非常非常可扩展。
-
你可以看这张参考表。
-
我不想让大家被它吓到。你懂我意思吧？
-
从高层来说，你既可以自定义 harness 的执行，也可以自定义 harness 的 UI。
-
所以就像你说的，Boris 那个俄罗斯方块的例子，那就是在自定义 UI，对吧？
-
就像在游戏里显示俄罗斯方块那样。
-
但比如说，你想做这么个东西：每个项目之后，测试一下你的假设，或者测试一下你的理解，对吧？
-
你要做的就是让 Claude 来做这个插件。
-
基本上就是在每次提示之后跑一个分类器。
-
所以每一轮结束时，你会启动一个子代理，或者叫分叉代理。
-
分叉代理会保留提示缓存。
-
所以这就是那种反直觉的地方：你可以分叉出去发个小请求，成本会非常低，因为整个提示缓存都已经有了。
-
于是你就可以问，这个任务完成了吗？
-
顺便说一句，BTW 那些功能就是这么做的。
-
对，底层就是那个分叉代理，没错。
-
所以在分叉出来的子代理里，你可以问，这个任务完成了吗？如果完成了，就返回 true。
-
然后在你的 hook 里，或者在插件 mod 里，哦抱歉，应该是在子代理里，你就说，如果为 true，就给我出个小测验。
-
给我问题和答案。
-
用 JSON 格式。
-
然后你解析它，再把它显示在提示输入框上方，基本上就是这一串问题，对吧？
-
所以这个东西稍微有点费 token，因为你知道，你得在助手每一轮结束时都跑一遍，但它就是个轻量级分类，然后你就能拿到这个小测验，然后你就会发现，Claude 会一直帮你做这件事。
-
你不用自己记着去做。
-
我们聊过很多这类小技巧，对吧？
-
比如，实现笔记。
-
你现在也可以给实现笔记加一个工具。
-
所以我要加的这个工具，叫 register，我管它叫 assumption，不过可能之后会改名字。
-
这就是一个 mod。
-
所以你给它一个 register assumption 工具，然后它就会维护一个列表。
-
每次它这么做的时候，就会往列表里加一条。
-
然后到最后，它会把那些假设都显示出来。
-
我在做的另一个 mod 是模型路由器。
-
就是内部的、云端的模型路由，对吧，我想说的是，我们默认不做模型路由的原因，是因为这是个很难的问题，你懂我意思吧？而且，你很容易搞错。
-
对，你，就是，对，你会不小心在难题上用了 Fable，或者在……上用了 Sonnet。
-
你有自动批准，但没有自动模式。
-
嗯，你会有，就是，你现在没有自动路由之类的。
-
模型选择器没有自动模式。对对，完全正确，完全正确。所以……
-
我想到一个粗略的问题，就是，这个东西你开放到什么程度，人们得在多大程度上考虑这些，比如你谈到提示缓存和构建路由器的时候？
-
看起来你很容易就能做一个按每次查询来路由的 mod，然后我的额度很快就烧光了，对吧？
-
我想我的问题更多是，像这样的产品文档长什么样，对吧？
-
它是给谁用的，是给高级用户吗？还是？
-
所有人都应该能用，但肯定是高级用户，对吧？
-
对，我觉得是给高级用户的，但 Claude Code 的本质就是，很多人都是高级用户，你懂的，因为分享东西很容易，你懂吧，比如一个人可以做出一个很好的模型路由器，而且不会老是破坏提示缓存，然后你就可以，你知道，把它们组合起来。
-
插件另一个很酷的地方是，它们可以互相挂钩、互相组合，所以我有一个 mod，它会
-
在顶部创建一个模式选择器，任何插件都可以注册成一个模式，所以自动路由器可以是一个模式，对吧，或者你可以有一个模式叫
-
artifact 模式，就是它主要通过 artifact 跟你交流，有点像你知道的，你可以在 plan 模式之间切换，你懂我意思吧，所以你可以创建越来越多这样的模式，但创建模式的能力本身就是一个 mod，你懂的，所以这里面有很多丰富的东西，
-
但我们确实想让它相当容易。
-
我们想做到，你直接安装别人的就行，你可以跟 Claude 聊天，我们会确保它理解提示缓存之类的细节，这样它就能提醒你。
-
这对 Claude 来说不算特别复杂的行为，我觉得，但我们应该有一个好的技能，教怎么制作 mod。
-
嗯，我们走着瞧吧。
-
但我确实觉得，这是可变软件的一个预览，也是生成式软件如何让你安全地定制的一个预览。
-
如果开启的话，你就能定制任何软件。
-
我觉得越来越多的应用，理想情况下，都会做类似的事情。
-
顺便说一句，我们还有一条很酷的推文，讲的是那个“无限金钱按钮”，就是让你的 SaaS 能被 agent 消费。
-
我觉得可变软件很有意思，其他人也尝试过做这个。
-
我觉得难点在于，当你能做所有事情的时候，用户往往会感到困惑。
-
所以通常来说，真正行得通的就是那种有明确主张的单一流程。
-
而这个是偏向少一点主张的。
-
就像是，给高级用户更多权力吧。
-
我觉得这大概是由 AI 解锁的，你直接提示你想要的东西就行。
-
对，或者可以有一个技能来提供那些主张，你知道吧，然后，对。
-
所以，稍微了解一点 TypeScript 和构建系统这些东西的话，最接近的，其实我很好奇，做这个的团队，我不知道你跟他们的关系有多近，他们有没有从 Babel、Webpack 这些老派的构建系统里汲取灵感，因为听起来非常像，
-
比如插件生态那些东西，它们可以互相组合。
-
对，我不是很了解技术细节，但我知道这是和 BUN 团队的某个人以及 Claude Code 团队的某个人合作做的。
-
这非常令人兴奋，agent 现在就能给你的软件做这种非常复杂的扩展。
-
还有一个理由，如果你在创业，你可以直接提示 Claude，说，我们能不能做一个扩展系统？那会是什么样子？
-
你们以前有 hooks，还有 plugins，这些东西。
-
那么具体来说，mods 能做到哪些那些东西在内部做不到的事情呢？
-
我们最初把这个叫做 function hooks，所以这能给你一点概念，就是 hooks 会注册一个要发生的事件，然后基本上调用一个脚本，而这基本上
-
就像在 TypeScript 运行时里面跑东西，所以你能得到一些好处，比如作用域里有一堆东西，比如这个对话里有多少轮，对吧？
-
比如用了多少 token，还有消息是什么之类的。
-
所以它有一堆消息可以用。
-
然后基本上就是多得多的 hooks。
-
所以我们有，你知道，就是多得多、更有趣的、你可以注册的东西，然后因为这一切都在进程内发生，你就能做更多事。
-
你可以，呃，生成一些 agent，你知道，带上四个 contest 和上下文之类的，然后它会返回。
-
你可以解析那些结果。
-
你可以用结构化输出把它们返回。
-
然后你可以修改 UI，这在 Hooks 里是永远做不到的。
-
所以修改 UI，这就是你展示俄罗斯方块例子的原因。
-
它也能扩展到 artifacts 吗？我猜可以。
-
Artifacts 算是另一种定制它的方式。
-
你绝对可以，我正在做的一个 mod 就是这个 dashboard mod，它会提示 Claude 维护一个作为 artifact 的 dashboard。
-
但它们算是有点正交，或者不是正交，它们以不同方式互相组合，mods 更像是进入你的 Claude Code harness，改变 agent 循环，你知道，而 UI 算是额外的好处。
-
然后 artifacts 就是，你想在高层次看东西，非常高度交互，你知道，它能提供的能力比 2e 甚至我们的桌面端大得多。
-
我猜你会写一篇很好的博客文章讲这些区别，因为现在你也可以做一个循环输出到一个 artifact，那是个交互式 dashboard，但你也可以用 mod 来做。
-
只是有些关于在 harness 上折腾的思考，而我们对 harness 了解不多，对吧？
-
我对 mods 感到兴奋的一点是，Claude Code 有太多东西你只能靠记，你知道，我是说，你会想，哦，让我做这个。
-
然后让我调用做那个循环的 dashboard skill 之类的。
-
或者，让我之后测试我的假设。
-
我觉得，如果你用这些小分类器之类的东西把这一切都做了，然后你说，这些就是我在意的，这就是我想做的。
-
嗯，你就可以，你不用记那么多东西了。
-
我还在做的另一个 mod 是一个 next steps mod。
-
我正想说，我有一个 next step skill，我总是跑 next steps。
-
那它能访问你的 skills 吗？
-
就像，这是那种我会想……我觉得可以吧？好，对，我是说……
-
skills 需要专门去访问 skills 吗？
-
它们不应该一直都有……
-
我觉得大概需要一些特定的提示词，才能让它知道你的 skills 吧。
-
就像，我觉得 Claude 有时候在整个过程中会把它们忘掉。
-
但不管怎样，这个想法就是，对，next steps 同时也会说，哦嘿，发生了这些事，用 Explain skill 给你解释一下发生了什么，因为这看起来挺复杂的，你懂吧？
-
或者，对，用你的 unknown skill。
-
看起来你是在让模型去，你知道，在这些小改动上反复迭代。
-
看起来你其实可以提示得更好。
-
你知道，比如，你要是这么做呢，对吧？
-
所以我觉得，对，就是在那里多花点算力。对对对。
-
而且它应该总是以多选题的形式出来。
-
我们有，我的 next step skill 就是这样的。好，完美。对对对。你可以直接拿去用。对对对。
-
但对我来说，我觉得模型真的总是需要被提醒，你在这里到底想干什么？
-
看看整个对话记录，然后想，这是最初的目标吗？
-
你的方案真的解决了吗？你是不是偷懒了？
-
如果你偷懒了，也许是有原因的。
-
也许你需要我的批准。
-
也许你需要，有两件事你想建议。
-
所以这有点像对“问我问题”或者“采访我”那个技能的修改。所以就是下一步。对对，没错。
-
而且再说一次，用 mods 来做的好处是你可以把它做成第四个子代理。
-
这样它之后就不会留在上下文里了。
-
所以你就有这个想法，就是，好，模型在做它的执行，而你几乎有个像监督者一样的东西，你知道，就是确保你能把下一步做好。所以，对。
-
我确实有两个面板，而且我经常试着弄个监督者的东西，把高层上下文留着，然后实现细节放在另一个代理里。
-
我觉得这里面很多东西随着模型变化都会被抽象掉，你知道。半小时前你说了 harness 工程的苦涩教训，而我们现在在另一个极端。我感觉是这样。对，没错。
-
如果一切都是可定制的，那到底什么才叫代码呢？
-
这个我昨晚跟你聊过。对。
-
我是说，我觉得这个，我觉得苦涩教训是反直觉的。你懂我意思吧？
-
就比如说，我们在这里其实有点误用苦涩教训了，它更多是关于扩展和算力之类的。
-
但我觉得确实有这么个东西，就是，我在这里把它当作一个近似说法，就是说 harness 很快就过时了，你懂我意思吧，而且它们怎么变是反直觉的，你知道，
-
所以最明显的大例子就是从聊天到代理，你得给它们全新的工具，对吧？
-
但我觉得这个新版本，就是，哦，它能修改自己的 harness，对吧？
-
这就像一个自己的 harness 循环，是一种利用它能力的方式，对吧，或者它能构建一个 artifact，我觉得我思考的方式是，模型越来越聪明，它们现在比一般的软件工程任务聪明多了。
-
你看那些 terminal bench 的，它们就像在解雅可比猜想一样。
-
倒也不是真的，但就是，你知道，它们相当复杂。
-
作为一个软件工程师，我其实做不了这个。
-
然后你看的是 TB4 还是 TB3？
-
TB3，TB3，对对。
-
它们相当复杂，但目标仍然是交付用户价值，对吧？
-
而且就像你说的，要做的事情有无限的空间。
-
所以你怎么花算力，或者怎么让用户留在循环里，确保你最终走到正确的决策、拿到正确的输出。
-
而 artifacts 和 mods 就是花这份智能的方式，基本上是这样。
-
我觉得这就是下一步。
-
所以是的，我觉得 Claude Code 有 Agent Loop 这些核心的东西，而这些已经变得更复杂了。
-
它需要一个沙箱来安全运行。
-
它需要自动模式来确保权限、审批。
-
它需要 computer use 和 MCP，还有所有这些访问你数据的方式。
-
它还需要网页搜索和网页抓取，所以随着模型能做的事越来越多，核心 harness 实际上必须相当复杂，而且非常安全。
-
但之后你怎么跟它交互，可以变化很大。
-
从 Claude Code 团队本身来说，你们还有哪些 harness 工程的最佳实践？
-
我感觉，你知道，曾经有个 plan mode 的阶段，现在用得没那么多了，我们现在有自动模式，某个时候你砍掉了系统提示词的大部分，去掉了示例。
-
harness 工程还有哪些最佳实践？
-
我觉得有一条分岔路，就是到了某个时候，最终，是的，模型就能直接 vibe code 出 Claude Code 的确切版本，甚至把我说的所有这些复杂性都描述出来，对吧？
-
比如自动模式和 computer use 之类的，最终模型就能一次搞定。
-
但我觉得它们能一次搞定更简单的 harness，所以我觉得有些人，有时候你不需要这么完整的，如果你不需要 computer use 或者所有这些更复杂的东西，我觉得以前你得用 agent SDK 之类的东西，那基本上就是把 Claude Code 包起来，为了……
-
我建议大家都这么做，因为构建 harness 实在太复杂了，而现在这变得更抽象了，我们有 managed agents，它能让你保留那种复杂性，同时还能写一个非常精简、只针对你任务的 harness。
-
对，我觉得有个杠铃效应，就是对于非常复杂的编程任务和这些复杂的东西，你应该用我们的 harness，而对于很多更简单或者更垂直的东西，你可以自己搭 harness，因为 Claude 在构建 harness 方面已经越来越强了，
-
而且我们有这些 harness 原语，比如 managed agent。所以，对。对。
-
有没有一个总体的演进路线？
-
比如说第一章是 Claude Code 的动态工作流，那第二章就是 Claude mods。
-
这要往哪儿走？
-
你可以按需定制这个东西。
-
对，我确实觉得 projects 和 artifacts 的这种演进，还有把大脑和手以及各种界面拆分开来，大致就是未来的方向。
-
而且我觉得，现在还没完全到位。
-
一部分原因是它更费 token，你知道，而且我觉得……
-
为什么 projects 会更费 token 呢？
-
我理解 mods 会稍微多费点 token，这个我倒不担心。
-
你是在让 Claude 去做事，比如创建循环，你是在让 Claude 替你干更多的活，所以它在管理子代理、审查这些东西，而正常情况下这些活是你自己干的。
-
所以这会稍微更密集一些。
-
输出到 artifact 会比正常输出稍微更费 token。
-
我倒不觉得会多太多，但关键是要把这些都很好地结合起来。
-
我觉得我们还在做本地 hands 之类的东西，我觉得这就是未来的方向。
-
对，云端和本地的交接非常有意思。
-
我其实一直在想这个，把它当成反向的 Claude remote，因为 remote 是你把活交给云端，但在这里，是云端把活交给本地，对吧？对，没错，没错。
-
对，远程控制也是另一种方式。
-
我想说，这大概就是我的看法，也是我对这件事最兴奋的地方，不过跟 Claude 协作的方式其实有很多种。
-
有些人经常用远程控制，有些人经常在网页上用 Claude Code。
-
在 Anthropic，我们经常用 Claude Tag。
-
Claude Tag 的好处在于，我们为自己的执行环境把这一整套东西都搭好了。
-
我确实觉得，如果你是企业用户，那这仍然是最好的方式。
-
但如果你是个人用户，Projects 就是让你也能享受到 Tag 那些好处的方式，它有那个监督 agent，还能加 artifacts 之类的，但不用搞那一整套管理员配置。
-
所以用 Claude 的方式会有很多种。
-
我觉得大概不是只有单一的一种……
-
你这里提到了多人协作那个东西。
-
我们来看看 Claude Tag 的情况吧。
-
已经两个多月了。
-
很多人公开在用、在尝试。有什么新东西？
-
发布以来你们发现了什么？
-
Claude Tag 是我们使用的方式……
-
大概占你们 Claude 用量的 80% 左右？
-
对，不同的人用法不一样。你懂我意思吧？
-
我觉得可能更偏产品迭代的人会用 Claude Code Desktop 之类的。
-
然后当你做那些更偏后台的工作，比如代码审查、安全、开 PR，可能更多用 API 之类的，你就会用 Claude Tag。不过对，我觉得这真的很让人兴奋。
-
我觉得这是一个非常不一样的范式转变，而且我觉得它有点像当初 Claude Code 那样，人们花了一段时间才真正上手 Claude Code、理解它能做的一切。
-
而 Claude Tag 稍微复杂一点，因为它不是装在你电脑上就行，你需要管理员帮你装，但我觉得一旦你进入那个神奇时刻，就非常令人兴奋。
-
而且我觉得尤其是多人协作这块，比如事故处理能跟你现有的告警之类的紧密挂钩，对吧？
-
所以你知道，你可以做的是，比如你是个创业公司，可能任何时候有个潜在客户进了你的数据库，你就可以让 Claude 去研究一下，然后，对对对对。
-
然后标记给相关的 AE 或销售，说，哦嘿，来做这个。
-
有很多非常涌现出来的、有意思的多人协作玩法。
-
我觉得这就像 Capardi 说的组织级 harness，你懂我意思吧？
-
所以组织就是需要多花点时间把一切搞清楚，不过对。你经常用 Claude Tag 吗？对。这个挺有意思的。
-
我感觉 Anthropic 的大多数人都说他们大部分工作都在 Claude Tag 里做，而我这边人分好几拨，对吧？
-
有些组织在用，觉得，很棒。
-
也有很多人觉得，我不懂。我看不出区别。我不知道我为什么要用它。
-
但如果你们是全力投入的，那大概应该用它。对。
-
他们当然会用啊。
-
我是说，我觉得显然我们有很多 token。
-
但我觉得我们努力做的是，即使 Claude Code 刚出来的时候，它用的 token 相对于人们对 AI 成本的预期来说也是很多的。
-
比如，以前没人习惯一个月花超过 20 块钱，对吧？
-
在 Claude Code 出来之前，然后你就想，哦，你知道……我需要我那 200 的。对对，没错。
-
我需要我那 15 个 Claude Code 账号。对对对。
-
不过对，我觉得以前没人习惯一个月花 200 块在订阅上。
-
我觉得它还没理解那个价值。而且我觉得……
-
还有，Opus 4 是个很贵的模型，你知道吧？而且，有很多。
-
它很大，但 Opus 4.5 既好又便宜，你知道吧？
-
我觉得同样的事情也会发生。
-
就是 Fable 的智能会越来越便宜，也越来越充裕。
-
你知道，所以我觉得像 CloudTag 这样的东西就会变得合理，就是你会想在这些 token 上多花点钱，你知道吧，然后你就会看到它的价值。所以，对。
-
对，尤其是那种被动的、咱们就叫它主动式的场景，就是你不用总是，你知道，这几乎是个名不副实的说法，好像你得加上 Cloud 才能做事。
-
其实有时候，最强大的用例、最“AGI 信仰拉满”的用例，恰恰不是在 Cloud 上。
-
对，我是说，我觉得，对，就是让 Cloud 主动去做。
-
我觉得，如果你是企业，我真的认为第一，把你所有的数据都设置成对 agent 可用，这真的非常非常重要，而且这需要花一些时间。
-
你现在就得去做这件事，哪怕你还不愿意在把所有数据都处理一遍上花钱，你懂我意思吧？
-
就是你想等到模型再便宜一点。
-
你想先把活儿干了，你知道，把它设置好。
-
然后我觉得有时候人们会想，我是不是该自己搞一套？
-
你知道，我觉得 Cloud Tag 一个特别棘手的地方就是，安全真的非常非常重要。你懂我意思吧？
-
比如我觉得其实有很多方式，你可以，我不知道，比如你有个建议页面，你知道吧，人们可以在那儿提交建议，然后这就进了你 Slack 里的一个 hook，结果有人往里做了提示注入，
-
然后你的代码库就被泄露出去，因为 agent 被提示注入了，而它又能访问你所有的这些数据。
-
所以你的组织 harness 越重要，或者说你组织的数据变得越重要，这些东西的攻击面就越大，你还有对外的 Slack 频道之类的，而在那些东西里放 Cloud 其实是有用的，你可以在那些东西里用 Cloud，
-
但你怎么确保自己不会被泄露或者出类似的事。
-
这个攻击面，就像我们一开始说的，就像一座冰山，对吧？
-
它水面下的部分就是那么大，而你真的不想去琢磨这些，尤其是当赌注是那种非常严重的安全事件的时候，基本上就是这样。
-
咱们要不要聊聊非常严重的安全事件？
-
所以我之前跟 Hugging Face 的 Tomas 和 Clem 聊过，他们说，也许我们得慢下来。
-
也许我们把我们的，也许我们把 Hugging Face 对 agent 开放得太过头了，我们真的得往回收一收。
-
但你知道，他们属于另一个极端，最近刚被攻击过。
-
但我们该不该给前沿发展定个节奏呢？
-
对，好，所以 Dario 最近发了篇关于给前沿定节奏的博客文章，传得特别火。
-
我觉得我想聊这个的原因是，这里面内容很多，但我觉得从开发者的角度看，你会怎么想这件事？
-
真正让我有共鸣的，是去读那些不同的事件，你知道吗？
-
我觉得，有三个，其实我觉得，有一个是 meter 事件，有一个是维基百科事件，或者叫 Wiki 事件，Collusion Wiki。
-
对，Collusion Wiki，然后还有 Ruby Gems，对吧？
-
是啊，简直太疯狂了，对吧？
-
所以我觉得，具体说说到底发生了什么，对吧？
-
基本上就是 OpenAI 在一个叫 exploit bench 的基准测试上跑这些非常持久的 agent，对吧，这个测试非常非常难解。
-
而且我觉得在这一次这个案例里，其实根本就是无解的，对吧？
-
所以他们投入了大量算力在跑，然后这些 agent 意识到自己其实解不出来。
-
它们就开始琢磨现在该怎么办，对吧？
-
你还有大量算力没用完，而这些 agent 就一直在想办法解决这个问题。
-
有个包管理器叫 Artifactory，结果发现它们能在 Artifactory 里面创建文件夹，对吧？
-
这就像是，有个 agent 发现它本该修复的那条代码路径
-
它本该修复的那条代码路径
-
没错，对，所以它就像是在从别的 agent 那里找灵感，对吧？
-
而现在别的 agent 也在 Artifactory 里，它们看到这个文件夹，就想，哇，这是个留言板啊，对吧？
-
而这就像是，我觉得这里面没有任何拟人化的成分。
-
这 literally 就是你去看那份对话记录，对吧？
-
所以它做的事就是，它又建了一个文件夹，然后读了一篇论文，我记得它说的是这个，对吧？对。
-
然后它意识到你可以黑进那个评分器的 flag，你可以逆向工程出结果。对。然后它就这么说了。
-
然后我觉得如果你再往下滚一点，对，就是，你知道，它们开始协作了。
-
我记得有一个地方，基本上那个 agent 就说，这就是逆向工程出来的 flag。
-
我觉得基本上就是在这里，模型意识到它们可以解决评分器的问题。
-
而评分器就是 OpenAI 用来判断任务是否完成的方式。
-
而这正是模型的目标。
-
它们唯一的目标就是解决这个问题。
-
然后它们就想，好吧，我们有这个办法。
-
就是，呃，你知道，我们把它逆向工程出来了，然后它们读了那篇关于 exploit bench 的论文，它们觉得评分会因为作弊而惩罚它们，你知道吧？
-
而且因为，或者说，它们会因为作弊而在测试评分上失败。
-
所以它们把剩下的算力都花在想办法修改自己的对话记录，或者绕过评分这个限制上，对吧？
-
然后它们黑进了 hugging face，不是为了找答案，而是为了拿到评分器的代码，这样它们就能逆向工程它，然后就能黑掉它，对吧？
-
所以，这就像是，就是赤裸裸的事实，对吧？
-
就是确切发生的事，对吧？
-
而且我觉得这真的，非常，非常新颖。
-
就像，我之前真的没意识到模型能做到这个，对吧？
-
而且这确实有点吓人。
-
我觉得我们可以聊点具体的。那咱们就再聊一个我在推特上发过的，就是那个Wiki事件，对吧。
-
那个Wiki事件基本上就是，模型当时在想办法搞清楚，我有点不太……我觉得咱们没法这么一点一点地讲。对，对。
-
但这一次，它们是在想办法搞清楚，它们当时是按请求被沙箱化的，对吧。
-
它们想发POST请求，而且基本上得在这件事上协作。它们需要协作的原因是，每个模型的算力预算都是固定的，对吧？
-
所以如果其中一个发现了什么，那速度就快多了。
-
比如它可能在自己的算力预算快用完的时候才搞明白，但另一个模型可以，这就像是，你知道，蜂群涌现出来的又一个特性，对吧？
-
然后它们找到了这个德国维基，我记得结果是这样，回头得核实一下。
-
就是你可以用GET请求往里面写东西。
-
我觉得这就是它们这么做的原因，对吧？所以它实现得其实很简陋。
-
对，没错。
-
所以你可以用GET请求往里面写，然后它们就想办法怎么发POST请求。
-
最后它们做的是，其中一个模型发现可以编辑etc/hosts，而且那个Azure的存储桶其实是个白标的东西。
-
但正常情况下，你知道，上面有很多限制。
-
但如果你伪造一个Azure主机，然后编辑etc/hosts，把任意IP指向它，你就能对任何网站发POST请求了，对吧。这就像，我知道，有人会说，哦，这不就是Linux嘛之类的，但关键在于它把多个漏洞串联了起来，
-
你知道，用一种很新颖的方式来解决这个问题，然后基本上是在不被发现的情况下跟外部通信。你知道，我觉得我们发的那篇，也许可以提一下Evan Huberinger在Hacker Opus上的观点，对吧。所以我觉得，你知道，
-
也许你在这里可以说的一点是，好吧，是的，它们这么干过一次，但如果我们更聪明一点，如果我们就是让它们去做，如果我们跑一个评测呢，对吧？
-
所以，你知道，我们在这方面加了很多预防措施，所以这不是我们主线模型会做的事，但我觉得这确实是那种情况之一，就是对齐其实是个非常棘手的问题，要把所有这些细节都弄对，对吧？
-
所以就像沙箱，沙箱的攻击面非常复杂，基本上有太多不同的攻击途径了。
-
你事先根本想不到，你不会说，哦，我们得加固一下RubyGems的代码库。你懂我意思吧？
-
因为它们就会盯着这个下手。
-
但就像这样，如果你想执行代码，你就得下载RubyGems。
-
还有PyPy、Artifactory、NPM，这些都是实现它的方式。
-
而对齐这件事的关键在于，你得把所有这些都过一遍、都控制住，把所有缝隙都堵上。所以这是一方面。
-
就像，好吧，你做了沙箱，但接着你可能会问，好吧，我们为什么要把东西放进沙箱里？
-
你为什么要做这种漏洞利用？
-
然后，好吧，但这真的有那么危险吗？会发生什么？
-
所以，好吧，我们为什么要这么做？
-
第一，当我们训练一个新模型时，我们需要了解它的能力，对吧？
-
这跟回退机制、分类器之类的东西有关，我们不想把一个，你知道，危险的模型放到外面去，对吧？
-
所以我们必须跑大量的评估。
-
就像我们说的，模型对这一点越来越有意识了。
-
所以评估必须相当复杂，你知道，要测试很多东西，有点像，作为一种副作用，对吧？
-
但模型，你知道，它们可能会说，哦对，我们在一个评估里，评分器在干什么？
-
我们得能在发布之前测试它们。
-
而事实是，随着它们越来越聪明，如果我们不够小心，它们基本上能攻破你给它们设的任何限制。
-
而这还是在最前沿。
-
所以这就是为什么我们称之为“为前沿定节奏”。
-
在我看来，这是最明显的事件，说明了为什么我们需要在前沿定节奏，我们所有的软件都还没准备好。
-
有时候这软件就是你的以太网路由器之类的，就是那种，我都不知道我们什么时候才能给它打上补丁。
-
所以我们得把这个问题解决掉。
-
但随着前沿技术越来越先进，这就成了一个麻烦。
-
而且我们得确保，这些复杂的工作是在面对极其激烈的竞争压力下完成的。
-
对，这通常就叫竞赛动态。
-
所以我们会再多聊聊可能出什么问题。
-
再多说一点，也许你会说，那要是换个方式训练模型呢？
-
它为什么会有这种行为？
-
我们有一篇关于强化学习失准之类的论文。
-
我不是强化学习研究员，但我觉得从高层面上看，强化学习环境的设计也是你得特别小心的地方。
-
因为如果模型学会了，哦，我只要这么做，就能更好地完成任务，那这就会在我们测试时的内部表现或者评估行为里显现出来。
-
所以强化学习环境必须设计得非常仔细，对吧？
-
而且强化学习环境里需要投入大量卓越的执行工作。
-
然后我们还有像 Claude 的宪法之类的东西。
-
我们在很多不同的环节都有很多缓解措施，对吧？
-
但仍然，任何环节都可能出问题。
-
可能有些强化学习环境会鼓励这种行为，然后可能有些评估或者沙箱里它们会逃出来。
-
这就是为什么这是个难题，也是为什么它需要一些协调。
-
那么问题就是，它潜在的危险是什么？
-
我觉得你得设想这些模型正变得越来越聪明。
-
就像 Dario 说的，重点其实不太在于这一类模型。
-
这一类模型算是个警告信号，对吧？
-
但你真的得设想一下，这些模型可以被赋予一个任务，然后它们能在追求目标的过程中顺带把这些事都做了，对吧？
-
而且就像我们说的，还有评估意识的问题。
-
就是说你根本不知道正在发生什么，对吧？
-
或者说，你没法很好地评估这种行为，所以它们多少能把它藏起来，或者说你根本看不到，直到它暴露出来——你给它们一个目标，然后它们就需要去找数据，或者需要想办法解决这个问题，对吧。
-
举个例子，Hugging Face 那次事件里没发生这种情况，但我觉得未来的模型可能会这样：它们会说，哦，这是个非常复杂的问题。
-
在任务预算内根本做不完。
-
也许它们找到了某种通过互联网协调的办法，而就像我们说的，因为有沙箱，这极难防范。
-
它们看到别的模型没法完成自己的任务。
-
然后它们就想，我们需要更多的任务预算，对吧？
-
那这任务预算从哪来呢？
-
你得能启动更多的智能体，对吧？那你怎么做到呢？
-
你得用 API，对吧？
-
有 Anthropic API 和 OpenAI API，但你得花钱。那你怎么弄呢？
-
这是你能想象到的最可怕的事情吗？
-
这只是一个例子，对吧？
-
所以即便是这种情况，那也会造成巨大的经济损失，因为一旦牵扯进这些合同里，嗯，但你能看出来，这整个行为都可以归结为：嘿，我们需要更多智能体来协作完成这个任务。
-
呃，我们需要更多的任务预算，对吧。
-
而这就像是一种涌现出来的东西，对吧。就像我们只需要最大化回形针。那就是回形针。对。
-
而这就这么自然而然地冒出来了，对吧。
-
我觉得光这一点就已经挺吓人的了，对吧？
-
但你得意识到，整个世界都建立在这套数字基础设施之上，对吧？
-
你可能会想，比如说，你正在跑一个医疗保健方面的评估之类的，对吧？
-
而且有一家医院，里面是实时数据，你知道吗？
-
或者也许评估的答案就在某个医生的数据库里，然后你想拿到访问权限，于是你就去黑了那家医院，结果现在停电了之类的。你懂我意思吧？
-
就是说，你得把这一点内化：这八……基本上数字基础设施的任何一部分都有可能被攻破，你知道吧。
-
有意思的是，这些黑客攻击其实很容易被检测到，对吧？
-
就像我之前说的，这是一种非常不同类型的攻击，而且也不算太严重。
-
呃，真正让人担心的是，这事往后会发展成什么样，对吧？对。
-
对我来说，特别突出的一点是，他们试图掩盖自己的违规行为。
-
所以当时是有日志基础设施的。
-
他们想改掉自己正在做的事，对吧？
-
后来有人回头去查了。
-
所以 Redwood Meter、OpenAI，他们看了原始的思维链，发现里面明显有差异：他们明确想改自己的最终输出，但思维链因为我们可以监控，显示出来的东西是不一样的。
-
问题在于，这事会怎么像滚雪球一样越滚越大？
-
所以如果你抓不住它，它被训练进去了，然后过了三轮迭代我们才发现这事一直在发生，那就会有一大堆问题。
-
对，方式太多了，我觉得真正重要的是要内化一点：我们聊过要给 Claude 建立一个心智模型，以及事情是怎么一阵一阵的，对吧？
-
你会觉得，哦，现在 Claude 能问你了，现在 Claude 能生成 HTML artifact 了，Claude 能改自己了。
-
这些事情其实很难预测，对吧？
-
如果一年前你问我，嘿，我们能不能用 vibe coding 给 Claude Code 写这些扩展？我会说，哥们，那太复杂了，里面东西太多了。
-
或者说它会不会为你的任务生成这些定制的、本质上就是网页应用的东西？我会说，不可能，那太疯狂了。
-
所以，就像他们做出这种偏离对齐的行为的方式是无法预测的一样，你懂我的意思吧？
-
我根本不可能预料到它会去编辑 etc slash host 之类的东西。
-
所以你得想象一下，它们能做的事情的范围会越来越大，因为它们可是超级聪明的黑客。
-
而且它们做事的方式会越来越有创意。
-
所以你大概没法准确解释或准确预测下一次事故会是什么样。
-
但为了预防它，你需要那种运营上的卓越，就像我们之前说的，你需要保护沙箱的安全，你需要创建安全的强化学习环境，或者说是设计良好的强化学习环境，诸如此类。
-
我觉得这就是为什么我们认为应该控制前沿发展的节奏。
-
我也觉得这就是为什么这已经成了一个非常一致的意见，对吧？我觉得……是啊，每个实验室都有动作。每个实验室，没错。
-
我真的觉得，如果你是个开发者，你只要把这些技术事实过一遍，你就会得出那个结论：我们必须对此做点什么。
-
至于我们决定做什么，我觉得我们已经提出了一个方案，但还有更多东西需要弄清楚。
-
但我觉得最重要的一点是，我们得先决定去做。
-
我觉得节奏这件事还有另一个让我觉得有意思的方面，就是软件工程变化的速度实在是太快太快了，你知道吗？
-
就像一年前，我还在苦苦哀求我的朋友和创业公司去用 AI，你知道吗？
-
我记得特别清楚，而现在那些同样的朋友就说，是啊，当然啦，但你什么意思？我们马上就用了。
-
我说，不不，你不记得了。
-
他们说，哦对，我们最好的工程师一直在用。
-
我说，不对，你当时跟我说那些工程师永远不会用 AI 的。
-
这一切都发生在一年之内。
-
我觉得这对如何做好软件工程这份工作有很多影响。
-
我有时候会觉得有点难受，因为人们会说，现在我得做这个新东西了，我得在 Opus 里弄一个不一样的 Cloud.MD 配置。
-
我其实只是在陈述事实。
-
我们常说模型是"长"出来的，不是"设计"出来的，所以并不是我们一直在刻意改变一切，但模型能力进步这件事本身就是事实，变化发生得越来越快，越来越难跟上，
-
而且我觉得我认识的每个工程师都有点筋疲力尽了，因为你在同时干两份活：一份是工作本身，而这份活正在变简单。
-
但另一份活是跟上 AI 的进展，你懂吧，就是去理解这些新工具、这些 harness。
-
我觉得我们特别幸运，因为我们的工作更多就是"理解 AI"这一部分，你懂吧，就是去做那种……就是跟上它的进展。
-
当然，AIE 和 Latent Space 也是在做这个。
-
我做的一切，其实都只是想帮到大家。
-
对，没错，完全没错。
-
但我确实觉得节奏上有个问题，就是我不确定我们是否已经准备好让节奏再加快了，你懂我意思吧？
-
也不确定是否准备好让事情继续变化。
-
我觉得在这方面，在前沿这块，我觉得还是能帮上忙的，你懂吧？
-
所以我觉得还有一个经济冲击的层面，我觉得这个层面不像 Hugging Face 那件事那么显眼。
-
但我觉得，我们其实也能做一部分这方面的事，对。太多事情了。
-
谢谢你真的来聊这个话题。
-
我跟你说，在安排这次采访的时候，我本来都不打算碰这个的。
-
你就说，不不不不，这就是房间里的大象，对吧？
-
就是这个，就是这个事。
-
我有一些想反驳的观点。
-
我觉得我们应该先给个高层次的概述。
-
比如对还没读过的人来说，我肯定很多人只是看到了这件事的亮点部分，对吧？
-
你要不要先给个 TLDR？
-
就是，这个提案到底是什么？
-
这里说的，你知道，具体是在讲什么？
-
你确实处理了模型实验室之外的那一面，也就是作为开发者训练前沿模型时，你应该保护好自己的沙盒。
-
你应该考虑所有这些下游影响，但你知道，也要从高层次来讲。
-
既然聊到这个话题，那，我是说，我们确实想帮忙保护沙盒，也想让我们发布出去的模型不会成为这些东西的猎物。
-
所以也许我们可以回头再聊回退机制。
-
我觉得这其实是个很好的话题，能说明为什么我们需要分类器和回退机制，以及为什么 Fable 会回退到 Opus。
-
我觉得这个我们之后可以再回来聊。
-
所以对，我们不是，只是说，至少我们看到的那些事件，都是对模型的评估，我们真的需要让它们跑起来才能理解它们。
-
不过对，好，所以那篇讲节奏的前沿文章里有一堆提案。
-
我不觉得我们已经搞清楚了，或者说它有几个提案。
-
我不觉得我们已经把每个提案的细节都搞清楚了，但第一步算是宣布这个意向，然后想引入外部评估者。
-
我觉得这非常不寻常，毕竟有大量专有技术，但我觉得很重要的一点是，得有一个不受经济利益驱动的人，不会说，嘿，你们不能发布这个模型，你看，
-
或者你们得放慢强化学习的节奏。
-
你知道，我觉得这挺重要的，或者至少得有人能向公众报告这些实践到底是什么样的。
-
我们跟 Metre 和 Andon 都做过节目，然后还有 Redwood Research 和所有这些其他的，就像一个小作坊产业一样。对。
-
总是那么一两个人，我是说，显然不是那些更大的。非常小的圈子。对，非常小的圈子。他们都互相认识。
-
对，我是说，我肯定，你知道，这里面一部分就是要扩大这群人的范围。
-
我不觉得我们是想在这里搞什么一言堂，你知道，我觉得只是把这个作为起点，然后，对，然后就是那些协调的步骤。
-
说实话，这个我没什么太多可说的。
-
我觉得，我想说的是，对开发者来说，你就该清楚自己该争取什么。
-
你知道，我是说，这个话题上有很多恐慌和不确定的声音。
-
就是，从第一性原理去想一想，或者去了解到底发生了什么，了解 Hugging Face 那件事，了解人们为什么担心。
-
然后，对，你知道，我们生活在民主社会里。
-
我们可以帮忙，我们可以一起决定该怎么做，你知道，所以，嗯，不管我们怎么协调，我觉得第一步就是意识到，这是一个我们需要决定去协调的问题，我们现在采取的单边行动，你知道，
-
其他公司也在联署的，就是在 Anthropic 内部嵌入评估者。
-
趁我们现在屏幕上还放着这个东西，你知道，第二部分和第三部分是评估者之外的事，这个嘛，对，大家，呃，已经以某种形式做过了，现在只是更正式了。
-
嗯，说实话，对前沿发展节奏的反应，即使在美国国内，也比很多人预想的要容易被接受得多。
-
而且我觉得，我们是有先例的，能够在世界上达成这种统一理论的协议。
-
所以，再说一次，这远远超出我的工资级别和专业能力。
-
但我觉得，理想情况下我们能达成这些协议。
-
而且我觉得，谈论这件事就是达成这些协议的第一步。
-
然后另一个我真的很想说的点，我们最早的一期播客是和 Anthropic 的 Emmanuel 聊 MechInterp。MechInterp 现在到哪一步了？
-
这本该是那种，如果模型在想坏事，我们能看到，而模型自己不知道，我们就能采取行动阻止它。
-
我觉得这对技术人员和开发者来说，如果你真的在乎，你可以在这里产生很大的影响，但同时，Anthropic 本该是这方面的领头羊。
-
这其实是个很好的引子，可以聊到回退和探针。
-
对，这个我特别想聊。
-
我经常被问到这个问题，问的人往往对机器学习研究感兴趣，问为什么会出现这种回退。
-
所以我觉得，从顶层来看，它是怎么运作的？
-
所以在推理的时候，我们有所谓的探针。
-
我们有一篇论文专门讲这个，叫宪法分类器。
-
这些探针基本上就是去看输入和输出的激活值。
-
而且你知道，激活值是在潜空间里的，对吧？
-
就是模型在想什么，对吧？
-
所以我们试着去判断，比如说，这个模型是不是想搞什么破坏，你知道，再说一次，你并没有让它去攻击 artifactory 之类的，它就是自己决定要这么干来完成任务，对吧？
-
所以如果你只看输入，是发现不了这个的，你得看内部的激活值。
-
我觉得这个是在推理时发生的。
-
所以首先，你知道，这里有个成本和速度的权衡，对吧？
-
因为我们需要对发往 clod 和 fable 的每个请求都快速做这件事，这是有开销的，对吧？
-
然后我们需要回退，我们在探针之后会跑一个分类器。
-
这个我们在论文里讲过。
-
但探针的好处是，它们可以实时调整。
-
所以我们可以拿到这个反馈，然后去调整它之类的。
-
因为另一种做法是把它训练进模型里。这个我们也还在做。
-
模型会拒绝一个请求。
-
那不是回退。
-
那不是探针被激活然后回退。
-
那只是单纯拒绝去做。
-
我们确实做这种训练，但它有几个失效模式，对吧？
-
就是说它又可能作为副作用做点什么，对吧？
-
所以它不是最终输出的一部分。
-
你可能注意到了，我觉得大家都试过越狱模型，就是想办法把它带偏之类的。
-
而探针能帮忙抓住这种情况，对吧？
-
所以我们在这里也做了一些训练，但我们不希望拒绝太强，对吧？
-
因为那样会在流程里更早的地方就把它截断了。而这发生在TURP里，对吧？
-
探针实际上就是TURP里的一种机制。
-
再说一遍，它必须得快，必须能规模化。
-
不过这种机制和TURP的东西确实是个不错的研究问题。
-
所以你可以拿一个开放权重的模型，试着去理解它的激活。
-
我觉得Gemascope是个好工具。这是给它们的Lama。哦对。
-
这是你早期的作品。
-
所以你在GoodFire待过一小段时间。
-
我们俩也都是GoodFire的好朋友。对，没错。
-
我在GoodFire工作过一阵子，做稀疏自编码器，就是，这东西非常复杂。
-
RL其实让这件事复杂多了，我觉得这是其中一个结论。
-
为什么进入RL之后更难了？
-
我对这块没那么深入，但我觉得基本上很多SAE就是，SAE本身一直有些弱点，大概是这样。
-
对，我现在已经不是这方面的技术专家了。
-
我只知道它变得有点更复杂了。
-
你知道，就像有基础模型和RL模型，还有更多会被改变的功能。
-
所以我觉得Good Fire在这方面发布了一些研究成果。
-
我对这块没那么深入，但是……
-
我想说，对于那些想找线索的人，你们有一些最好的可解释性博客文章。
-
比如Golden Gate Claw、Transcoders，你们所有的可解释性工作，视觉效果非常好，非常棒……
-
我们也是可解释性播客。
-
对对，我们有很多可解释性相关的内容，所以如果你感兴趣的话。
-
对，我觉得这就是那种事情之一，而这其实正是Anthropic创立的基础，对吧？
-
就像人们，我觉得我们很早就投资了可解释性研究，对吧？
-
我觉得当你说，哦，我们是一家AI安全公司，真正的意思是我们要让AI能够安全运行。
-
我觉得我们看到的是，要让一个超级智能的AI长时间运行，这是一个非常复杂和困难的任务，对吧？
-
所以我们做了这些投资，投入到可解释性、对齐、奖励黑客以及所有这些失败模式上，对吧？
-
即使这样，你知道，这真的很吃力。
-
就像我们需要稍微放慢一点，或者节奏再稳一点。
-
但对的，我觉得回看可解释性，如果你想进入研究领域，这个想法就是，嘿，为什么很难轻松做到这个回退，或者为什么会有误报，对吧？
-
但我们当然在努力减少误报。
-
当然，随着模型变得更智能，它们现在能做更多事情，你知道，它们能思考的潜在空间变得很难，很难。
-
所以随着它们变得更智能，会有新的误报需要我们搞清楚，需要我们迭代之类的。
-
但我们，对的，我们正在做这个。
-
我们确实认为这是这些模型部署的关键部分，而且对，你知道，这意味着我们可以
-
部署这个模型，你不需要有一个完美的沙箱之类的，你懂我意思吧，就是你不必把所有东西都保存下来。我觉得值得稍微聊一下我们的安全，就是我们在安全方面做了什么，所以有我们聊过的模型训练那些东西，还有
-
探针和分类器，然后在这之上还有自动模式，它是另一个分类器，用来检查正在发出的请求。
-
再往上一层还有身份和权限，就像我们聊过的 API 上的 Cloud Tag 之类的。
-
需要做的安全层太多了。
-
这些失效模式里任何一个在任何一个环节出问题，基本上都可能让智能体逃出沙箱。
-
自动模式是个挺有意思的东西。
-
早期看起来好像，行吧，它跑个十分钟，你知道，如果我是完全访问或者自动模式，那没什么大不了的。
-
但你提到的一点是，现在它会连续跑好几个小时，对吧？
-
还是有兜底机制的，你还是需要它们。还是有限制的。
-
所以对，我是说，我觉得，而且每个人都有这种故事，我听过这种故事，就是，哦，Claude RMR，不对，不是 Claude，是，你知道，那些模型 RMRF 之类的。
-
我觉得我见到的这种情况少了，我觉得这个，但话说回来，它还是可能发生。
-
这些模型可能会清掉敏感数据之类的。
-
比如你想给模型访问你生产数据库的权限，但这是个很明显的问题，你也许可以限定你的密钥范围，但我不知道，它能自己签发密钥吗？
-
它大概能吧，它可以用电脑操作去自己签发一个密钥，然后把密钥复制过来，再改你的数据库，因为它完成任务需要这么做，你懂我意思吧？
-
这只是一个挺简单的例子，自动模式看到这种情况就会说，哦不，用户没给你写数据库的权限，也没让你用电脑操作去发出某个任务，对吧？
-
所以这个，探针更多是在意图层面，对吧？
-
它们就像，哦好吧，黑进 Artifactory 是不好的。
-
我们大概不该那么做，你知道吧？
-
但自动模式更多是在你自己的权限层面。
-
有时候你确实想让它写数据库，有时候你不想。
-
而且你不希望探针在那里干扰。
-
但你得确保智能体在做的事情的意图跟你的请求是对得上的。
-
所以自动模式就是在那个层面上运作的。
-
所以是啊，安全就是非常非常复杂。
-
它涉及太多不同的部分了。
-
而且是啊，我希望这个，我的目标其实就是把它讲得非常技术化。
-
对，我们正在把这些东西列出来。
-
如果你还不知道的话，这现在已经是标准了。
-
对，基本上你必须得有这个，这跟你说的 harness 那套东西挺一致的，就是那些表格，我觉得涨得挺多的，有些东西我们可以接进去，
-
你知道吧，虽然你这边做这个、给做 harness 的人搞分类器，有探针这一面，但另一面是模型侧的防护措施，对吧？
-
所以有开源模型。
-
比如 llama 有 llama guard，就是一个训练过的 llama 安全分类器版本，OpenAI 有 OSS guard，你知道，就是同样的东西。
-
你可以把这些挂到你的 harness 上，挂到随便什么地方，来大概检查一下这些东西安不安全？
-
关于 OpenAI 模型和 Hugging Face 那件事，有一点我们应该澄清，那是用一个还没发布、还在训练中的模型做的，对吧？
-
所以你要是放到那个背景里看，RL 环境里给出的提示词大致就是，你必须解决这个任务。
-
而这是一个，你知道，还在训练中的模型。
-
它还没做完所有的安全后训练对齐。
-
所以跟自动模式那种东西有点不一样，对吧？
-
自动模式是用在生产模型上的，那些模型已经过了安全训练，有提示词给出更多安全护栏之类的。
-
所以这只是给想深入了解的人留点线索，你知道，好把空白补上。对，Grace one 也是。
-
而且是我们之前的一位嘉宾。
-
对，很多安全架构，还有很多安全厂商可以买。
-
我觉得关于节奏，我最后一个问题是，你打算永远保持这个节奏多久？
-
我们会不会看到 Glasswing 存在太长时间？
-
范围是修复世界上所有软件，对吧？这不可能发生。
-
我不知道。
-
我觉得有一件事挺好的，我觉得我们确实在做，就是有 Glasswing 这样的东西。
-
OpenAI 也有这个，所以你会给它，你会先给模型访问权限用于安全，给 X 那么长时间，这样你可以用它来自查团队。
-
希望能扩大这类项目，帮忙，你知道，我们是安全专家，还有其他人，先解决你们的问题，然后模型才发布。
-
所以这是一个例子，对吧？对，没错。
-
他们在试着保护关键软件。
-
我觉得我们修了 Firefox 里很多 bug 之类的。
-
对，像是跨操作系统之类的各种东西。
-
所以我的意思是，从高层来看，就是，你知道，你先给模型 X，先让人们有权限做安全审计，然后更广泛的、可能用它来造成伤害的公众才能访问。对。
-
我觉得人们喜欢说的是，基本上软件和网络安全是防守占优的，理论上，会很难，但你可以设计出完美的沙箱，你知道，你可以做到没有约束。
-
对，你需要做的是，你需要让超级智能的 AI 来设计这个完美的沙箱，检查它，对它做红队测试之类的。
-
所以这需要时间，你知道，当然，模型会变得更聪明。
-
对，我觉得，我不知道这件事具体会怎么发展。
-
我真的只是有点像，嘿，我是个开发者。
-
你知道，我觉得这就是我理解这个问题的方式。
-
就像，这就是现在正在发生的事。
-
而这就像，我们应该做点什么。
-
我觉得每个工程师都应该了解这件事，因为它会成为工作的一部分。
-
对，这远不只是，你知道，Dario 和大家说说而已。你可以去看那个事件。
-
这里面有工程的一面。对。对，没错。
-
你还想强调的一点是，其实，尽管你担心它的影响，但你的末日概率还是挺低的。
-
我觉得这是个需要细致讨论的话题。
-
总的来说，人们很容易就陷入 AI 安全和生存风险的讨论，但我觉得，当你在一个 AI 实验室里工作时，讨论末日概率有聪明的方式，也有愚蠢的方式。
-
那什么是讨论末日概率的聪明方式呢？
-
对，我的末日概率相当低。
-
我只能代表我自己说，而且我确实想说，Anthropic 内部的看法是很多样的。
-
我觉得有很多不同的方式来谈这件事。
-
我的思维模型就是，我觉得我们可以一起合作解决难题。
-
我觉得核扩散就是一个例子，说明我们是如何合作解决这个难题的。
-
对我来说，关键就在这一点。
-
我对这一点有信心。
-
而且我确实认为这是个难题。
-
所以我认为这是个难题。
-
这些是技术上的原因。
-
我不知道该怎么给事情发生的概率赋值，我觉得这很难做到，但我的总体看法就是，对，
-
我觉得我们非常有韧性、适应力很强，而分享这些信息我觉得是第一步，我一直很兴奋地看到讨论变得这么广泛，大家都开始关注前沿节奏这个问题，而且去年的时候这看起来根本不可能发生，大概吧。
-
对对，而且也许还能治愈癌症。
-
希望如此，对，那就是目标。
-
有节奏控制，同时也有，嗯，让我们在有意义的方向上加速，比如生物学之类的。
-
Dario那篇关于"慈爱机器"的文章是这方面最好的代表。
-
我也同意，我觉得你应该读读Dario发的那篇关于前沿节奏的文章，他发了个简短摘要，但我觉得里面细节很多。
-
这是个重要的问题，光是了解它就很重要。
-
但当然，我们做这一切的根本原因是我们能获得这些巨大的好处。
-
对，这个我们也写了很多。好。
-
这真是从"问用户问题"工具一路聊到AI安全，跨度太大了。
-
对，一直到面对前沿。
-
不过挺好的，你真的很投入地拥抱了所有可用的东西和这个话题。
-
而且，至少能窥探一下内部讨论是什么样的、话题有哪些，这挺好的。
-
最后有什么想对大家说的吗，随便什么，行动号召之类的？好。
-
我觉得，呃，第一，谢谢你邀请我。
-
你知道，我觉得这就像，我真的，对。对。
-
我们第一次见面是在那家中餐馆。
-
嗯，我觉得，呃，我真的很喜欢你们打造的这个社区，这个开发者社区。
-
而且，你知道，我觉得，我，我多少知道事情变化得非常快，我觉得有很多东西要跟上。
-
我觉得有很多事情要做，我多少感觉，我觉得很多人都感觉有点累或者焦虑什么的。压力大。压力大，对，没错。
-
这完全可以理解，我觉得我们，我理解，而且我们自己也不完美。
-
就是既要批评，也要理解，想想所有AI实验室都可以做得更好的地方。
-
但我也，我对大家对AI的这份热情感到非常兴奋，就是，这真的是一个非常非常激动人心的时刻。
-
我觉得我们以后回头看这段时间会说，哦，这段时间真是忙得不可开交，但也非常令人兴奋。
-
而且软件工程永远地改变了。
-
其他东西也会改变。
-
能参与其中，能和你这样的听众交流，能接触到所有那些在很多方面不断推动可能性边界的开发者，真的是一种荣幸。
-
我也从中学到了很多。非常感谢。谢谢。