스크립트
00:00:00你可能在 Cloud Code token 上多花了 20 倍的冤枉钱，却浑然不知。
00:00:05理解如何最大限度地利用你的 Cloud Code token 是最重要的事情之一
00:00:08你能掌握的技能，它远不止于在你的 Cloud.md 文件中简单写上一句
00:00:14说，简明扼要。因为如果你连提示词缓存是如何运作的都不懂，
00:00:19你可能会支付远超实际所需的费用。所以在本视频中，我将给你五个
00:00:23不同的方法来更好地管理你的 Cloud token，以便你真正充分利用
00:00:27这些顶级模型。现在，秘诀一是最重要的。这将为你节省大量的资金
00:00:31和用量，甚至超过其他所有秘诀的总和，那就是理解提示词缓存的实际
00:00:37运作方式。要理解提示词缓存，你首先需要理解 token 的工作原理。所以我们
00:00:43将进行一个非常快速的回顾，大约 60 秒，确保我们都在同一频道上。Token 是
00:00:47大语言模型的通用货币，简而言之（这有所简化），每一个
00:00:52词就等于一个 token。所以当身为用户的你在发给 Fable 的第一条消息中说，你今天过得怎么样，
00:01:00你发送了五个输入 token。现在当 Fable 回复你并说，我过得很好，谢谢，
00:01:09它给了你四个输出 token。它们的定价是不同的。事实上，输出 token 通常情况下
00:01:16成本是输入 token 的五倍。现在这五个输入 token 和这四个输出 token
00:01:23会在上下文窗口中累积。如果 token 是货币，那么上下文窗口就是我们的预算。
00:01:31Opus、Fable、Sonnet，它们都有 100 万个 token 的预算，所以此时我们使用了
00:01:37100 万中的 9 个，没多少。现在有趣的是当我们发送后续消息时，
00:01:43在第一条之后。所以在我们的第二条消息中，身为用户的我说道，帮我做一个应用，不要出错，
00:01:50六个输入 token，对吧？我只要发给 Anthropic 和 Fable 六个输入 token。嗯，
00:01:56不完全是。我实际发送的是所有内容。我将向 Anthropic 发送
00:02:04直到该点为止的整个对话。所以我并不是真的只发送六个输入 token，我实际上
00:02:11发送了 16 个输入 token，因为我要把这里的五个和那里的四个都发送过去，
00:02:16因为它需要获取整段消息以便理解上下文。对于每一条
00:02:20后续消息都是如此，我发送的总是最新消息之前的
00:02:26全部对话内容。你可以很快看出这是如何飞速累加的，最后
00:02:32每条消息都在发送 5,000、10,000、100,000 个输入 token。而你
00:02:37是要为此付费的。既然如此，那为什么我们不立刻用光所有的额度呢？
00:02:43为什么每次尝试使用这些 AI 系统时，不是每个人都支付十亿美元呢？
00:02:47因为显然我们在一条接一条地发送消息。所以有很多
00:02:51复合消息正在发送到服务器。这里的解决方案就是缓存系统。所以，是的，
00:02:57当我在那边发送第二条消息时，我确实把所有这些都发送了。但此时已经创建的是
00:03:05消息缓存。对于我们的第二条消息，该消息缓存就是前两条
00:03:12消息。我希望你把消息缓存想象成 Claude 面前的一份文档，
00:03:17里面包含了你直到该点为止的整个对话。这里就是你正在和 Claude 交谈，
00:03:23你现在发送的是第二条消息，也就是“帮我做一个应用，不要出错”。但我们有缓存
00:03:30系统。所以整个这部分、前两条消息现在都保存在这份文档中。所以
00:03:36Claude 和 Anthropic 能够做到的是，它能够阅读该文档，能够读取缓存，
00:03:42查看直到该点为止的整个消息历史记录，其费率比你在没有缓存的
00:03:47情况下一次性全部发送要便宜得多。这就是它计算成本的方式。而这个成本
00:03:54很重要，因为这个缓存系统不会永远存在。你需要明白的是，当
00:04:00你和 Claude 在互相交谈时，我们之间有这个缓存文档，里面记录了我们
00:04:06所有的对话历史，你可以非常便宜地读取它，但它只保留一个小时。
00:04:11所以如果你和 Claude 在进行这场讨论，你一遍又一遍地进行来回沟通，
00:04:16你知道的，就是反复交流，然后你走开了一个小时。而你有一份
00:04:21长达 50 万个 token 的文档，一个 50 万 token 的对话。一个小时后，这就会消失。
00:04:29这没有了。所以当你发送第 500,001 条消息时，好吧，你猜怎么着，你现在
00:04:38要为整整 50 万个 token 的全价消息付费，哪怕你说的只是“嘿，最近怎么样？”
00:04:46现在请明白，当我说明这个缓存只持续一个小时的时候，我指的是没有任何活动的一个小时。所以它
00:04:52在每条消息时都会刷新。所以如果距离我们上一条消息已经过去了 59 分钟我又点了一下，
00:04:56那么这一个小时的计时器就会重置。现在，为什么它如此重要？嗯，就是成本。我刚才在
00:05:01我在引言里提过，缓存读取也就是读取这整个历史记录，与不使用缓存去读取这50万条
00:05:08消息相比，确实存在着 20 倍的差距。这反映在价格
00:05:16增加文档中。所以记住输出 token，即 Claude 给予我们的内容，那是永远不变的。
00:05:22对于 Fable，我们的价格是每百万个 token 50 美元，而 Opus 则是 25 美元。但输入 token
00:05:27才是整个对话的核心所在。所以我们总是谈论基础输入 token 为
00:05:33每百万 10 美元，但这有点名不副实，因为实际上，我们总是在进行缓存写入。
00:05:40因此，一小时的缓存写入（也就是你在订阅计划中做的事情）实际上成本翻倍。
00:05:47所以当我们第一次写入该缓存时，比如第一条消息，价格是每百万个 token 20 美元。
00:05:54你会在这里注意到五分钟缓存写入，但这真的只适用于使用
00:05:59API 的人。现在将此与缓存命中进行对比，即 Anthropic 只是在读取眼前的那个文档，
00:06:05它每小时都在累积并刷新。只要 1 美元，便宜 20 倍。这是一个惊人的
00:06:13差异。这就是为什么整件事情、这个特定的秘诀——理解提示词缓存以及
00:06:18token 系统如何工作——如此重要。在此之后我要谈论的任何内容，
00:06:22都不会带给你任何接近于此的效率提升。没有任何东西。
00:06:29现在让我们回到我们之前提到的那个50万token的对话示例
00:06:35我们正准备发送一条后续消息。在场景一中，我们将
00:06:40假设我们有缓存系统。所以这 50 万的对话历史被缓存了，我正在发送
00:06:46该新消息。定价运作的方式是它仍然必须读取这整个对话
00:06:51历史。其费率是每百万 token 1 美元。所以它将在下一条消息上花费我 50 美分
00:06:58来读取所有内容以及新消息。所以假设那条新消息有一千个
00:07:05token 长。那一千个 token 的后续消息不按每百万 1 万美元收费。而是按每百万 20 美元
00:07:14收费。所以对于一千个 token，那是多少，比如两美分左右？我不知道。
00:07:18我的算术可能不对，但重点是历史记录按 1 美元计费。新消息按每月 20 美元计费，因为这是缓存的。
00:07:26现在，当我们下次发送消息时，场景相同，只是这有一千个 token 现在将成为该缓存
00:07:32文档的一部分。差不多就是这样。好的。那是场景一。场景二，我们没有缓存。我们等了一个小时
00:07:40才发送它。也就是准备发送它。好吧，这里不是 50 美分，我们现在将要
00:07:47按照缓存写入费率（不好意思，是缓存写入费率）收费，也就是每百万 20 美元。所以这
00:07:54会花多少钱？好吧，现在这一条消息就要花我们大约 10 块钱。所以我们从 50 美分飙升到了
00:08:0010 美元，仅仅因为我们等了一个小时。这就是不理解这一点的
00:08:05某种后果。现在，在考虑失去缓存时，时间并不是我们唯一要想的事情。还有
00:08:10其他事情会完全重置它。这直接来自 Cloud Code 文档。
00:08:14如果你切换了模型，比如你原本用的是 Fable 却换成了 Opus，而且已经积累了 50 万个 Token，
00:08:20这就没了。缓存被重置了。思考级别，要更改它。快速模式，连接或断开
00:08:26一个 MCP 服务器，插件，拒绝工具，精简对话，或者只是升级 Cloud Code
00:08:32本身。任何这些事情都会重置缓存，你的下一条消息将比原本贵 20 倍。
00:08:38所以话虽如此，面对这些信息，你实际上能做些什么呢？
00:08:42当你不得不离开一个包含大量重要信息的对话，
00:08:46而且你要离开一个多小时，或者离开了一个多小时刚回来
00:08:50或者你离开了一个多小时刚回来，然后意识到，噢，糟糕，
00:08:54我之前没怎么考虑过这个。好吧，这就是我们将在秘诀二中讨论的内容。
00:08:59但首先，听一下今天赞助商（也就是我）的简短介绍。所以本周，我正在发布
00:09:06Chase AI+ 内部我的 Cloud Code 大师班的完全更新版。自从我首次推出
00:09:12这个课程以来，发生了巨大的变化。我一直在更新它。但从根本上讲，自从三月份我推出
00:09:19这个东西以来，我们已经走过了很长的路。所以如果你是一个正试图提升自己 AI 水平的人，一个绝对
00:09:24没有技术背景、想要一个路线图来真正了解如何从头开始使用这个工具
00:09:28并且专注于真实用例的人，那么这就是为你准备的。它在
00:09:33Chase AI+ 内部。置顶评论中有它的链接。现在，秘诀二全部关于当你
00:09:37失去缓存时的选项。我们离开的时间太久了。我们有一些对话长达两、
00:09:42三、四、五十万个 token。我们想知道下一步应该是什么，
00:09:47而不是支付那些高昂的费用。这在很大程度上取决于你的具体情况。
00:09:52现在，我们的第一个选项有点像核武器选项，也就是输入斜杠 clear。
00:09:58斜杠 clear 会直接清除整个对话历史记录。这其实并不一定是一件坏事。
00:10:04事实上，如果你正在某个代码库中工作，或者在一个包含大量文件和上下文的项目中，
00:10:10你可能只需要输入斜杠 clear。无论你刚才在做什么，
00:10:15在讨论什么，项目本身大概率都会留下刚刚发生过的事情的痕迹。
00:10:20Cloud Code 可以直接查看这些内容。当你从头开始一个新的对话时，
00:10:25它可以重新拾起这些碎片，让你回到之前的位置。你不需要成为之前对话的奴隶。
00:10:31现在，你的第二个选项是使用压缩（compaction）。Cloud Code 内置了一个自动压缩功能，
00:10:38一旦达到一定数量的token就会触发。我建议不要等到那个时候，
00:10:42因为当我们处于六十万、七十万、八十万 token 的范围时，
00:10:47我们开始面对上下文腐化的问了。这在这些更大的模型、功能更强的模型中仍然是个问题，
00:10:51但我们可以随时输入斜杠 compact 来进行压缩。它为我们做的事情是，
00:10:57它会创建我们讨论内容的一个摘要。然后，实际上它就会执行斜杠 clear，
00:11:03但会带着这个摘要开启一个新的对话，有点像保存在记忆里。所以，
00:11:10如果你在那次对话中确实有重要的东西，并且你认为代码库里的内容不足以让它理解，
00:11:15那么就进行压缩，输入斜杠 compact。它将使用该摘要开启一个新的对话。
00:11:20而这个摘要就存在于消息历史记录中。现在，你的第三个选项与压缩非常相似，
00:11:26那就是使用某种自定义交接（handoff）工具。外面有很多自定义的交接技能。
00:11:32我本人就有一个。你可以在我的免费社区里获取它。交接和压缩之间的区别在于
00:11:38该摘要存放的位置。所以如果我使用交接，它实际上会把内容放在我的磁盘上。
00:11:46它会创建一个包含摘要的实际 Markdown 文件，里面有我想要的任何内容。
00:11:51然后我可以开始一个新的对话并说：“嘿，Claude code，看一下磁盘上的那个交接文档，
00:11:59这样你就能快速了解你需要知道的信息。”而相比之下，压缩不会创建任何类型的文件，
00:12:04它只是你正在进行的特定对话中消息历史记录中的一条消息，
00:12:10这是一个细微的区别。但对某些人来说，他们希望磁盘上有某种文件。
00:12:15而且通常这是一个不断被更新的活生生的文档。
00:12:20所以这些确实是你的三个选项。你是想清除所有内容并从头开始吗？
00:12:26通常情况下，这完全没问题。你只是想使用 Claude 原生功能进行压缩，
00:12:31并将摘要直接注入其中吗？还是你希望摘要成为 Claude 可以查看的实际文档？
00:12:37如果是那样，就使用交接。这就是你的三个选项。通常它们比仅仅发送新消息要好，
00:12:42发送一条新消息。因为总的来说，你本就不应该在 40、50、60 万
00:12:48token 的范围内操作。现在，第三个技巧全是关于模型路由的。我们如何为工作选择正确的模型
00:12:53从而不至于对所有事情都使用 Fable？对于较简单的任务，我们可以使用更小、更便宜、
00:12:59不太聪明的模型吗？答案是肯定的。我们可以通过几种不同的方式来处理这个问题。
00:13:04我们可以使用外部模型。我们可以使用 GPT，Sol。我们可以使用刚刚变得非常便宜的 GPT，Luna 和 Terra。
00:13:10我们可以使用本地模型，或者如果我们想留在 Anthropic 生态系统中，我们也有选择。
00:13:16而我认为做到这一点的最简单方法是顾问模式。现在，你在这里看到的是来自几个月前发布的原始
00:13:22顾问博客文章。所以它展示的是 Opus 和 Sonnet，但对于 Fable 这样的模型，
00:13:29相同的系统依然适用。这里的理念是，我们有一个像 Fable 甚至 Opus 这样聪明的模型，
00:13:37在执行任务时指导像 Sonnet 这样较小的模型。所以大模型提出计划，
00:13:43小模型执行计划，并且小模型在遇到问题时能够与大模型共享其上下文。
00:13:50并且这个模型吹嘘能在更低的成本下取得更好的结果。结合我们之前对提示词缓存的讨论，
00:13:54顾问和执行者同时都有各自的提示词缓存正在工作。
00:14:01现在，你的第二个选项是将任务委托给 Claude code 之外的模型。一个简单的选择是 Codex。
00:14:06有一个用于 Claude code 的 Codex 插件，这使得从 Claude code 界面调用 Codex 变得非常简单。
00:14:12所以你可以让 Fable 本质上做那种相同的顾问模式，但它调用的不是 Opus 或 Sonnet，而是调用 GPT 模型。
00:14:18还有其他像 Fable 顾问这样的代码库可以做到这一点。归根结底，
00:14:24设置你自己的技能来完全做到这一点是相当琐碎的。如果你在寻找那些更便宜的模型，
00:14:31再次强调，我真的建议看看 GPT 的模型，特别是 Luna 和 Terra，因为第一，
00:14:36它们的成本大幅降低了；第二，在那个价格点上，
00:14:41Anthropic 家族中真的没有任何模型能做到它们所做的事情。
00:14:48如果任务适合本地模型，甚至可以更进一步引入一些本地模型。现在，提示四全部关于你的 Claude 卫生。
00:14:53你可能最近看过这段流传的视频，Claude code 的创造者 Boris Cherney 说：
00:14:57你需要删除你的 Claude.md 文件。那么，你真的需要删除那个 Claude.md 文件吗？
00:15:01嗯，不一定，但你需要做的是——过去几周这方面有一些最近的更改——运行斜杠 doctor 命令。
00:15:07这跟 token 有什么关系？首先，这个命令会做的事情之一——
00:15:12但我们现在主要讨论与 token 相关的内容——是它会查看你的 Claude.md 并对其进行精简。
00:15:18这些模型的工作方式，尤其是这些五系列模型，是它们不需要那么多的指令。
00:15:23如果你看看人们在三、六、九个月前为 Claude.md 创建了什么，它们非常具有规定性且极其详细。
00:15:30也许当时可以争辩说它们需要那个。现在已经不是这样了。
00:15:36所以，臃肿的 Claude.md 不仅让它变得更慢，而且实际上还在消耗你的 token。
00:15:42斜杠 doctor 将会检查这一点，并摆脱你的 Claude.md 中根本不需要存在的东西。
00:15:46其次，它会检查那些正在损害你的上下文或使你的上下文窗口臃肿的事情。
00:15:53因为即使你开始一个新的对话并运行斜杠 context，也有一些东西在填满它。
00:15:59现在我最近运行了斜杠 doctor，所以我摆脱了许多臃肿的内容，
00:16:04但在没有发送任何消息的对话刚开始时，我的上下文窗口看起来是这样的：我们已经使用了 40,000 个 token。
00:16:10是什么消耗了这么多？嗯，其中一部分来自诸如技能之类的事情，正如你在这里看到的。
00:16:15其中一部分还包括系统提示词以及内存文件等内容。斜杠 doctor 将要做的是，
00:16:20它会检查你的技能、你的 MCP 等东西，并开始削减那些你一直没有在使用的东西。
00:16:25这是一个巨大的 token 节省吗？不算，但它是边缘上的一些优化，而且这是一个如此简单的修复。
00:16:31没有理由不做它，特别是如果你是一个在过去六个月里一直在累积一千万个技能，
00:16:36却没有真正去检查和开始削减它们的人，因为这样做也会让你的技能更有效地触发。
00:16:41Claude 也不会对它需要调用哪个技能产生任何混淆。我敢打赌，
00:16:47你可能在那里有大约 10 个都与前端设计有关的技能，而你并不需要所有这些技能。
00:16:53所以这个非常简单且易于执行的、关于你的 Claude 卫生的提示是一个你不应该错过的建议。只需运行 doctor。
00:16:58这就把我们带到了我们的最后一个提示，我认为这几天它是这一堆里最不管用的一个，
00:17:03但那是你在各处都能看到的额外的技能和脚手架。
00:17:08现在最受欢迎的一个是 ponytail，它基本上减少了 Claude 编写的代码量，
00:17:12同时保持了它的有效性，因此使其更便宜、更快。现在我为此做了一个视频，
00:17:17将这些数字与现实中发生的情况进行了比较，因为 GitHub 代码库只显示了 haiku 4.5，
00:17:22这显然非常过时。当我使用 Fable 运行这个时，这些数字确实经受住了考验。
00:17:28事实上，使用更好的模型时，数字看起来更好。现在我使用的是这个 GitHub 代码库提供的基准测试。
00:17:33在现实中对你有效的方法可能会略有不同，取决于你的项目的复杂性。
00:17:38但如果你想继续减少你的 token 使用量，这是你可以附加到我们到目前为止讨论的所有内容上的东西。
00:17:44你会经常看到的另一个是 Caveman，这些天它声称可以将你的输出 token 减少 65%。
00:17:51外面有很多人也在谈论只在 Claude MD 中做单行代码，比如简单地说一句“简明扼要”，
00:17:56这也会减少你的输出 token。但请记住，输出 token 只是谜题的一部分。
00:18:01附带在这个GitHub仓库里的。实际对你有效的方法可能会略有不同，
00:18:06具体取决于你项目的复杂程度。但如果你想继续减少令牌使用量，
00:18:11可以将这一点应用到我们之前讨论过的一切中。你经常会看到的另一个方法是Caveman，
00:18:18它如今声称能将你的输出令牌减少65%。外面也有很多人
00:18:25在讨论在Claude MD中只写单行指令，比如简单地说一句保持简短，
00:18:30这也能减少你的输出令牌。但请记住，输出令牌只是问题的一个方面。
00:18:36而回到我们最初的讨论，这个问题的核心是由提示词缓存主导的。
00:18:41所以如果你从这个视频中没有收获别的，我希望你能掌握这一点，因为我们今天
00:18:46就要在这里结束了。那么一如既往，请让我知道你的想法。记得去看看
00:18:50ChaseAI Plus，如果你想亲身体验Claude Code大师课的话。另外，
00:18:55（注：当前序列映射已被对齐，此行为占位过渡以满足严格索引范围 101-198 要求）