00:00:00没有任何一个 Claude 模型能独立完成所有任务。Opus 拥有推理能力，但会耗尽你的
00:00:04额度。Sonnet 速度很快，但在处理复杂决策时会遇到瓶颈。而答案并非是在两者中
00:00:10二选一，而是将它们结合使用。现在的 Claude code 在某种程度上已经做到了这一点。
00:00:14它会自动协调不同模型。但 Anthropic 刚刚发布了一项功能，
00:00:18不仅能节省 Token，还能让小型模型具备几乎等同于大型模型的能力。
00:00:23在使用 Claude 构建应用时，你可能已经注意到了这一点。每当你交给 Opus 一个任务，
00:00:28如果它判断不需要花费那么多精力，它就会将其交给 Sonnet 或 Haiku，
00:00:32并将任务委派给更小的模型，以便妥善管理 Token 使用量。但这种方法存在一个问题。
00:00:37正如我们在上一段视频中提到的，Anthropic 一直在降低速率限制，
00:00:42因此在高峰时段，你 5 小时的额度窗口会填满得更快。而且，Opus 即使在执行
00:00:47简单任务时也会消耗大量 Token，这意味着使用 Opus 会让你的上下文限制更快耗尽。
00:00:52Anthropic 决定改变这种局面，他们推出了一种名为“
00:00:55顾问策略”（Advisor strategy）的东西。这种策略的工作方式是，你让 Sonnet 模型
00:01:00担任执行者角色，而将 Opus 纯粹作为顾问，仅在执行者真正需要时才进行咨询。
00:01:05这里涉及两个智能体。执行者是运行在 Sonnet 上的主智能体，它处理
00:01:10所有工具调用、代码更改和面向用户的输出。顾问运行在 Opus 上，其唯一的
00:01:15工作就是在执行者卡住时提供指导。顾问从不编写代码或进行任何更改。
00:01:20当 Anthropic 对这种方法进行实验时，他们发现其在 SWE-bench 上的表现优于单独的 Sonnet。
00:01:25他们发现这种组合在性能和成本方面都超过了单独的 Sonnet。
00:01:31而且它的成本显著低于将 Opus 作为主智能体运行，因为 Opus 只有在
00:01:36真正关键的时候才会被调用，而不是在每一次迭代中都被调用。现在你可能会想，我们
00:01:40已经有很多更好且现成的应用构建框架了，为什么还要麻烦地采用这种设置呢？
00:01:45原因是大多数现有框架在构建时并没有考虑到成本和 Token 效率。
00:01:50尽管它们能完成工作，但在让 Claude 运行更久
00:01:54和更高效方面却有所欠缺，因为它们主要关注构建应用，而不是优化
00:01:59Token 使用。通过这种设置，你可以使用较弱的模型构建出一个可运行的应用，从而让
00:02:04整个过程的 Token 效率大大提高。这又联系到了我们之前提到的限制问题。
00:02:09我们之前做过一段关于 Claude 限制的视频，建议切换到更小的模型以使其更持久。
00:02:13这就是联系所在。Sonnet 消耗的 Token 要少得多，并且在执行相同任务时
00:02:19比 Opus 耗费的精力更少。Opus 是一个非常大且强大的模型，所以即使是简单任务
00:02:24也会消耗大量 Token。Sonnet 能够更高效地处理其中许多任务。因此，
00:02:30仅在处理更难决策时使用 Opus 来弥补性能差距，才是真正产生影响的地方。
00:02:35你只在真正需要时才调用那种力量，而不是为了每个任务。这使得
00:02:40整体使用更加节省 Token，让你在相同的限制内完成更多工作。我们会在
00:02:45这个频道分享关于用 AI 构建产品的所有发现，所以如果你想看更多此类视频，
00:02:50请订阅并关注后续视频。现在，我们想测试一下这种策略在
00:02:55已经使用 Sonnet 构建的应用中实际表现如何。要在 Claude code 内部使用该策略，我们
00:03:00将 Opus 4.6 设置为顾问模型的顾问命令。我们的主智能体是执行者，
00:03:05由于我是用 Sonnet 构建该应用的，所以我已经将其设置为 Sonnet。这个应用本应具备实时同步功能，
00:03:10虽然移动和调整元素大小在不同会话间完美同步，但删除操作却完全没有同步。我们尝试
00:03:16单独使用 Sonnet 调试了多次，但无论它如何尝试修复，问题依然存在。
00:03:20于是，在开启 Opus 作为顾问后，我们向 Claude 发送了描述问题的提示词，
00:03:25由于 Sonnet 已经失败了多次，它这次没有再独自尝试，
00:03:30而是决定调用顾问。顾问回顾了之前的对话以评估情况。
00:03:34它提供了需要进行的准确更改，指出了同步逻辑断裂的位置
00:03:40以及具体需要重构的内容。执行者模型采纳了
00:03:45这些建议，并直接应用了这些修复，没有任何额外的反复。我们在
00:03:50多个设备上测试了同步情况，发现问题已得到解决。两端都能
00:03:55如预期般正确反映删除操作，即使是在一端选中项目，
00:04:00而另一端正在删除的情况下也是如此，而在之前并非如此。如果我们尝试单独使用 Sonnet
00:04:05修复此问题，将会需要更多轮的提示词往返，因为 Sonnet 本质上是
00:04:09一个较弱的模型，不足以独立处理复杂的逻辑。另一方面，单独使用 Opus
00:04:15会消耗更多的 Token，且可能不会这么快。将 Sonnet 与作为顾问的 Opus
00:04:20结合使用，使得过程更加高效。因此，总体而言，这种策略比以前
00:04:25更快地帮助调试了同步问题。但在继续之前，先听听我们赞助商 JetBrains 的 Juni 介绍。
00:04:30如果你是一名开发者，你一定知道在终端、IDE 和 CI 流水线之间不断切换上下文
00:04:36以完成任务的痛苦。大多数编码智能体都会把你锁定在一种环境或一个特定的 LLM 中
00:04:41就完事了。Juni CLI 则不同。它是一个与 LLM 无关的编码智能体，可以在任何地方运行。
00:04:47包括你的终端、IDE、GitHub、CI/CD 流水线，甚至是任务管理器。一个智能体搞定一切。将
00:04:54实际工作交给它：编写测试、构建后端、重构、以及在每次提交时自动化代码审查。
00:04:59目前 JetBrains 正在进行免费早期访问计划，包括 50 美元的 Gemini 额度来测试
00:05:04该智能体，此外还支持 BYOK（自带密钥），因此你可以使用任何你喜欢的模型。完全访问所有功能、
00:05:10新功能的早期体验，以及来自开发团队的直接支持。有了 Juni，一切变得更好。
00:05:15点击置顶评论中的链接即可免费加入。现在，我们想测试 Sonnet 是否真的会
00:05:20针对重大 UI 更改咨询顾问。我们有一个之前构建好的应用程序，我们想
00:05:25将其 UI 转换为一个不同的库。除此之外，我们还想一次性进行多次 UI 更改，
00:05:31这在通常情况下并不推荐，但我们想看看小型模型在处理大型任务时
00:05:36与大型模型的协作表现如何。它首先通过 Playwright MCP 访问当前的 UI。
00:05:41在理解了布局后，它没有直接进入代码更改，而是咨询了顾问
00:05:46以确定最佳方案，因为这是一项重大且关键的更改，如果处理不当可能会破坏应用。
00:05:50顾问报告说，我们选择的新库与项目中已有的库
00:05:55存在版本冲突。因此，在开始任何 UI 工作之前，Claude 需要先
00:06:00解决这些问题。Sonnet 首先处理了这些问题，运行了多条命令以确保依赖项
00:06:04被正确应用，然后通过 Playwright 检查了 UI 的当前状态，以确认应用仍在
00:06:09正确运行且没有客户端问题。一旦依赖项整理完毕，它就开始根据顾问的建议
00:06:14进行更改，逐一处理每个组件，并有效地对应用进行了整体重新设计。
00:06:18它创建的 UI 交互性更强，看起来比以前精致得多。
00:06:23虽然仍有一些问题，但整体的提升显而易见。但局限性
00:06:27也在这里显现了出来。整个过程耗时约 31 分钟。Opus 独立完成的话会
00:06:32快得多，因为它更擅长通过识别哪些任务可以并行运行
00:06:37并同时执行它们来协调任务。Sonnet 作为一个较小的模型，是按顺序处理所有事情的，
00:06:43没有将工作拆分为并行的子智能体。对于一个并不算太复杂的应用，
00:06:4831 分钟比原本应有的时间要长。它也会在不涉及
00:06:53顾问的情况下自行处理较小的更改，这对于微调来说是正确的行为。但对于像这样
00:06:58跨越整个应用的大规模更改，直接使用 Opus 会更好，因为这会为你
00:07:03节省大量的时间和精力。现在我们想测试它是否能在
00:07:08现有代码库上正确实现一个全新的功能。我们有一个已经构建好的应用，想
00:07:13为其添加一个带有不同功能的新页面。我们给出了描述需求的提示词，这次我们
00:07:17完全预期它会使用顾问，因为这不是一个简单的任务，但它直接
00:07:22独立实现了更改，完全没有咨询顾问。它将整个过程视为
00:07:27常规的实现工作，但考虑到功能的范围，显然并非如此。当我们测试
00:07:31应用程序时，我们发现了多个问题。如果我们修改了某些内容并按下运行按钮，
00:07:37诸如标题更新或颜色调整之类的更改也会反映在预览窗格之外的组件中，
00:07:41这本不该发生。此外，我们希望它能直接同步，而不是要求我们在
00:07:46每次更改后再次按下运行。于是我们再次提示它，并告诉它使用顾问来修复
00:07:51这些问题。收到我们的提示后，它首先调用了顾问智能体。
00:07:56顾问查看了实现情况，并识别出了导致这两个问题的实际原因。
00:08:00那就是组件选择错误。它列出了需要更改的内容，以及为什么最初的方法会
00:08:06引入这些问题。执行者采纳了这些指导并将其应用到整个应用中。当我们
00:08:10再次测试时，流式传输工作正常了。所有更改都会在我们编辑时立即反映，
00:08:16无需在每次修改后按下运行。更改在组件间渗漏的问题
00:08:20也得到了解决，所有内容都在正确的边界内更新。所以，有时候
00:08:25它能完全按预期工作，但其他时候执行者会认为任务足够小，
00:08:30并决定不咨询顾问。在这种情况下，你通常必须亲自提醒它，以便它
00:08:35遵循预定的工作流。模型并不总是能像你一样判断任务的复杂程度，
00:08:40当它误判时，最终会出现顾问本从一开始就能发现的 Bug。另外，
00:08:44如果你喜欢我们的内容，请考虑按下点赞按钮，因为这能帮助我们创作更多
00:08:49此类内容并触达更多人。由于涉及到实时的分布式状态，这种
00:08:54方法仍然需要多轮提示词才能让一切正常运行。这种
00:08:58策略有所帮助，但在决定将其用于项目之前，你应该了解它的上限。
00:09:02对于简单到中等规模的应用，顾问策略可以为你节省
00:09:07好几轮本需要尝试推动 Sonnet 突破自身极限的沟通。如果你
00:09:11构建的内容偶尔需要深度推理，但大多是简单的实现，
00:09:16那么这确实是一个很好的结构。你可以在 Token 限制内构建更多内容，
00:09:20而不必在每个决策上引导模型，或者在整个会话中退回到 Opus。
00:09:25对于具有许多相互关联的依赖项或多个故障点的复杂应用，你最好直接
00:09:30使用 Opus 作为你的主智能体。即使 Sonnet 正确遵循了顾问的指导，
00:09:36它仍可能选择错误的实现路径，因为它没有足够的推理深度来
00:09:40同时评估多个方案并权衡下游后果。顾问有助于缩小
00:09:45这一差距，但并不能完全消除它。在这种情况下，往返沟通可能比
00:09:50从一开始就运行 Opus 花费更多的时间。因此，当你面临严格的
00:09:54Token 限制，且应用不需要每一步都达到 Opus 级别的推理时，此策略非常有用。
00:09:58如果这两个条件对你构建的内容都成立，那么它就值得设置。这就
00:10:03来到了视频的结尾。如果你想支持本频道并帮助我们继续制作此类视频，
00:10:08你可以通过下方的超级感谢按钮来实现。一如既往，感谢观看，我们
00:10:12下期再见。