# Anthropic 讲解用 Claude Platform 降低成本并提升性能的三个方法 - 来源：ClaudeDevs (@ClaudeDevs) - 发布时间：2026-09-09 01:01 - AIHOT 分数：67 - AIHOT 标记：精选 - AIHOT 链接：https://aihot.news/items/cmtsxacbf04jkrob5fu5sp5ti - 原文链接：https://x.com/ClaudeDevs/status/2097369738968195513 ## 精选理由 官方团队给出提示词缓存、反模式清理和 effort 校准三条降本路径，并用公开基准实测数字支持，方法可迁移到自己的 Claude 应用。 ## AI 摘要 Anthropic 团队文章指出，优化 prompt cache 命中率、清除升级到前沿 Claude 模型后的提示词反模式、校准 effort 三个手段可在不牺牲性能的情况下降低成本。 ## 正文 https://x.com/i/article/2095208140753317888 使用 Claude Platform 降低成本并提升性能 调整提示词缓存、指令和投入程度，可以在不牺牲应用性能的前提下降低 Claude 的成本。 性能与成本常被视为一种权衡：想要花费更少，就得接受更差的结果。但在实践中我们发现，许多使用 Claude Platform 的应用可以通过三项调整在不牺牲性能的情况下削减成本：最大化提示词缓存命中率、在升级到前沿 Claude 模型时移除提示词中的反模式，以及根据任务校准投入程度。我们已将这些指导建议整合到 claude-api 技能中。在本文中，我们将展示带有 claude-api 技能的 Claude Code 如何常常能找到在维持或提升性能的同时降低成本的方法。 提示词缓存 在 Claude 生成回复之前，它首先会将你的提示词处理为一种内部工作状态。这一步称为预填充（prefill），是处理输入中成本最高的部分。提示词缓存会保存该状态（即键值缓存，或称 KV 缓存）：当请求以相同前缀开始时，Claude 会直接读回该状态，而不是重新计算。缓存读取的计费价格仅为完整输入价格的一小部分。 要确保提示词缓存的有效使用，有几个实际注意事项。首先，提示词缓存与特定模型绑定。其次，提示词缓存的读取必须在整个前缀范围内做到逐字节完全一致。最后，提示词缓存有有限的生存时间（TTL）。 考虑到这些要点，这里有一些实用建议： • 在对话中途更改 effort 设置时要小心。这些设置会渲染到提示词中、位于你的内容之前，因此它们是缓存前缀的一部分。只有部分精选的 Claude 模型（包括 Opus 5 和 Fable 5.1）允许你在对话中途更新 effort 而不会破坏缓存。 • 将易变的值排除在前缀之外。系统提示词中的动态时间戳或 ID 可能会在多次模型调用之间发生变化，从而破坏缓存。 • 避免使用会自行重新排序的工具定义。使用 Claude messages API 时，提示词会按固定顺序组装，工具定义渲染在顶部。工具定义的任何更改都会破坏缓存。 • 分叉对话时要小心。只有当分叉后的前缀与父对话逐字节相同、使用相同模型且使用相同 effort 时，子智能体和分支才能共享父对话的缓存。 如何修复 我们积累了一些关于提示词缓存管理的经验： • 仔细监控你的提示词缓存命中率。Claude Console 和缓存诊断 API 提供提示词缓存诊断信息，包括提示词缓存未命中的原因（图 1）以及两个请求在何处发生分歧。 • 延迟加载不常用的工具。预先声明所有工具，但将不常用的工具标记为 defer_loading：它们不会进入缓存前缀，只有在 Claude 通过工具搜索查找它们时才会被追加到对话中，从而保留缓存。 • 将系统提示词更新作为消息应用。某些 Claude 模型允许你在对话中途将系统指令作为消息添加，而不是编辑系统提示词，这样可以保留缓存。 • 组织请求时，让稳定的部分保持稳定。先添加静态上下文（工具定义和系统提示词），再把不断增长的对话内容放在它们后面（图 2）。 • 在提示词缓存本就会被破坏时再更改模型或推理强度。某些操作（如压缩）本身就会重写大部分缓存（即对话内容）。此时正是切换模型或推理强度的好时机，因为无论如何你都要为一次缓存未命中付费。 • 随着对话增长，移动缓存断点位置。借助 Claude Platform，你可以设置自动缓存，让缓存断点自动应用于最后一个可缓存块。 • 预热缓存。为降低延迟，可发送一个 max_tokens： 0 并带有显式缓存断点的请求，使用与真实流量相同的推理强度设置。这样会处理提示词并将其写入缓存，而不生成任何内容。如果你在会话开始时运行它（例如在用户输入期间），第一个真实请求就能命中已预热的缓存。 • 不要超过提示词缓存 TTL。5 分钟缓存 TTL 从请求开始时计算。如果智能体在工具调用或子智能体请求上阻塞，且运行时间超过 5 分钟，父级缓存会在结果返回前过期。在这种情况下，考虑改为在前缀上设置 1 小时 TTL。 说明 提示词可能会积累一些针对模型弱点打补丁的指令。这些指令可能会相对于最新 Claude 模型的能力发生偏移。以下是一些常见的提示词"反模式"，它们会拖累前沿 Claude 模型，并可能无意中增加成本： • 验证仪式。像"仔细检查你的工作"或"回复前验证两次"这类指令，往往会被前沿模型按字面意思执行，从而浪费 token。 • 详尽性与强调性增强词。"做到最大限度的详尽"、"关键：你必须始终……"这类表述在与前沿模型协作时，可能导致冗长输出和额外的工具调用。 • 强制流程与草稿本脚手架。固定步骤的流程（例如"在草稿本中一步步思考"）或推理模板，是前沿模型并不需要的仪式。这种脚手架会叠加在模型原生推理能力之上，消耗不必要的 token。 • 过时的示例。针对较旧模型失败模式调优的少样本示例，可能会教前沿模型在不需要长推理链的请求上模仿冗长的推理过程。 • 相互矛盾的规则。前沿模型更擅长遵循指令。相互矛盾的指令（例如"始终在政策范围内退款"与"未经上报绝不退款"）可能被前沿模型更字面化地执行，从而导致性能下降。 • 过时的配置。为较旧的 Claude 代际编写的设置（例如手动思考预算）可能会被 Claude Platform 在更新模型上拒绝。 如何修复 我们更新了 claude-api 技能，新增了一个命令，用于识别这些反模式。在 Claude Code 中，对你的提示词、技能或工具描述运行 /claude-api prompt-audit。该审计覆盖你工作目录中的任何内容，包括调用 Claude API 的应用程序代码以及 Claude Code 自身的配置（例如 CLAUDE.md 或技能）。 例如，我们在一个客户支持基准测试上测试了从 Opus 4.8 到 Opus 5 的模型迁移。我们从一份干净的提示词出发，每次植入一种反模式（一个已退役的思考设置、一对相互矛盾的退款规则、一个手动草稿区、"验证两次"、"做到极致详尽"，以及一个强制性的六步流程），从而得到六份遗留提示词。 我们在 Opus 4.8 上运行了每一份提示词，在仅更改模型 ID 的 Opus 5 上运行了每一份，以及在每份提示词运行一次 /claude-api prompt-audit 后的 Opus 5 上运行了每一份（图 3 显示了这六份的平均结果）。 在 Opus 5 上，验证仪式（"verify twice"）会在每次退款时重复进行订单查询，从而浪费不必要的 token。强调性增强词（"be maximally thorough"）则导致了数十次不必要的知识库搜索。 运行 /claude-api prompt-audit 消除了这些反模式，平均降低了 14.6% 的成本，并将准确率提升了 5.3%。成本下降是因为多余的函数调用和重复的推理被消除了。准确率提升有三个原因。已停用的思考设置导致 API 直接拒绝了每一个路由请求。相互矛盾的退款规则导致 Opus 5 在要求客户确认的同时，扣留了四笔本应退还的款项。此外，手动草稿纸与 Opus 5 的内置思考功能发生冲突：在三个工单中，它将函数调用写在了推理过程中，但从未执行该调用。 投入程度 Effort（努力程度）告诉 Claude"要用多大力度去工作"。在低 effort 下，Claude 通常能更快得出结论。在高 effort 下，Claude 会在回答前进行深思熟虑、验证并探索其他方案。 在同一个模型上，不同 effort 水平下的成本与性能表现可能有所不同。例如，Claude Fable 5 在 FrontierCode Diamond（最难的 50 个任务）上，低 effort 时得分为 11.5%，每个任务成本为 $5.35。在最高 effort 下，Fable 5 得分为 30.9%，每个任务成本为 $19.00；调整 effort 使得分提升了约 2.7 倍（+19 个百分点），而成本约为原来的 3.5 倍（图 4）。 在 Claude Fable 5.1 上，Humanity's Last Exam（不使用工具）呈现出陡峭的曲线，最后一步的提升逐渐递减。低强度模式下，每题约 0.30 美元，得分约为 53%；最高强度模式下，每题约 2.23 美元，得分约为 61%；从低强度提升到最高强度的最后一步，仅增加约半个百分点的得分，成本却增加了 46%。这一增益落在该基准测试多次运行之间的噪声范围内，因此你多付了钱，却没有获得可衡量的提升。 强度设置可能在两个方向上出现校准偏差： • 认为强度越高一定越好。高强度可能导致过度思考。Claude 花在斟酌上的时间超过了任务本身所需，这增加了成本和延迟，还可能降低回答质量。只有在仍有证据可挖掘时，深入思考才有帮助。 • 偏向低强度。设置过低时，Claude 在获得足够证据之前就停止了。它发起的工具调用更少，因此可能基于第一条搜索结果而非第三条来作答。它在困难步骤上思考更少，并跳过它通常会自行执行的检查。回答看起来是完整的，但建立在部分信息之上。 如何修正 有一些有用的方法来校准强度： • 在较低推理强度下测试更强的模型。低强度下的更强模型可能比高强度下努力工作的较弱模型更便宜。例如，在 CursorBench 3.2 上，Claude Fable 5.1 在低强度下的表现与 Fable 5 在高强度下的表现相当，而成本仅为后者的三分之一（图 5）。两个因素使新模型更便宜：在低强度下，每个任务完成的工作更少，并且 Fable 5.1 的提示缓存读取定价为每百万 token $0.25，而 Fable 5 为 $1.00。即使按 Fable 5 的价格计算，Fable 5.1 在低强度下的成本也会降低约 40%。 • 了解你的任务形态。在一系列推理强度下衡量应用性能，是理解特定任务成本-性能权衡的有效方法。在一个未饱和的评测中，如果跨推理强度的成本-性能曲线是平坦的，则表明该任务不受思考计算量的约束；增加推理强度并无益处。 这种校准通常涉及跨模型和推理强度运行评测。在 Claude Code 中，/claude-api hillclimb 可为你执行此搜索：它将你的评测拆分为训练集和测试集，提出配置更改建议，并读取失败的训练示例以修复其发现的问题。 我们在一个客户支持基准上运行了它，从 Opus 4.8 的默认（高）强度开始。该爬山算法首先尝试了低强度下的 Opus 5，应用提示审计来移除强制性的工具调用仪式、草稿板步骤和相互矛盾的规则。这以 98.9% 的训练准确率通过了 Opus 4.8 的基线，并将成本降至每张工单 2.6 美分（图 6）。 随后，它降级到低强度模式的 Sonnet 5，成本更低，每张票仅 1 美分，但准确率降至 88.9%。Claude 阅读了出错的火车票后，在提示词中添加了路由规则和退款上限交叉引用，使 Sonnet 5 在相同成本下恢复到 98.9% 的准确率。 在搜索从未见过的 14 张保留票上，最终配置的得分为 90.5%，而原始配置为 78.6%，成本约为原来的五分之一。 自动化成本削减 提示词缓存、指令和强度是降低成本的常见手段。我们的文档涵盖了更多方法。为了对使用 Claude API 的应用程序代码进行全面的成本审计，我们新增了 /claude-api cost-optimize：它会分析你的支出去向，应用成本削减措施，并且如果你提供评估，它还会展示节省与性能之间的权衡关系。 cost-optimize 首先找出你的 token 去向：如果你有 Claude Admin API 密钥，则来自你组织的使用量和成本报告；如果你的应用程序记录了每次 API 响应中的 usage 对象，则来自该对象；如果两者都不可用，则通过读取你的请求构建代码并进行估算。 然后，它对可用的节省措施进行排序，从提示词缓存开始，精简每个请求携带的内容（包括提示词审计），限制输出长度，并对无人值守的工作进行批处理。如果你提供评估，它会进一步计算不同强度级别和模型选择下的成本与性能。我们以 Sonnet 5 为基线，在四个公开基准上运行了此功能（图 7）： • LegalBench（成本降低约58%）：cost-optimize 建议跨任务缓存共享前缀、设置较低 effort，并通过 Batch API 处理任务。Thinking tokens 从 102，779 降至 8，284，通过率保持在噪声范围内，成本下降约 58%。 • tau2-bench retail（成本降低约73%）：通过显式断点位置实现提示词缓存，cost-optimize 在保持通过率不变的情况下将支出降低了 72%。 • OfficeQA Pro（成本降低约52%）：cost-optimize 增加了批处理和文档缓存，将成本从 136.20 美元降至 64.87 美元。 • SWE-bench Verified（成本降低约55%）：cost-optimize 发现默认配置已经正确进行了缓存。成本节省来自将 effort 设置为 medium，并将智能体的输出限制为几句简洁的句子。每个任务的中位步骤数从 29 降至 17，提示词 token 从 75.2M 降至 33.7M。 快速上手 当你迁移到前沿 Claude 模型并想检查现有提示词时，从 /claude-api prompt-audit 开始。它会扫描你工作目录中的提示词、技能和工具描述。这可以是调用 Claude API 的应用程序代码，也可以是 Claude Code 的配置（CLAUDE.md、skills）。它会移除那些会削弱前沿模型性能的常见反模式。 当你的应用使用 Claude API 并希望进行成本审计时，可以使用 /claude-api cost-optimize。它会分析 token 花费情况，然后测试不同的优化手段：应用 prompt-audit，同时也会检查通过 prompt caching、批量处理非实时任务或限制输出长度来降低成本的方法。如果你提供了评估集，它还会衡量不同方案在效果与模型选择之间的权衡。 最后，使用 /claude-api hillclimb 可以在成本与性能之间进行搜索。在给定评估集的情况下，Claude 会将其拆分为训练集和测试集，然后对你的应用提出旨在降低成本同时维持基线性能的更新建议。Claude 会阅读训练集中失败的案例来引导搜索，最终配置会在保留的测试集上进行评分。 了解更多： • 在此查看我们的文档 • 在此查看我们的成本降低 cookbook • 在此查看 claude-api 技能；该技能也已内置到 Claude Code 中 • 在此查看 Claude Blog 上的这篇文章 作者：Lance Martin （@RLanceMartin）、Brad Abrams （@brada）、Isabella He （@IsabellaKHe） 和 Ben Lehrburger （@benlehrburger）。