Claude Platform 降本增效官方指南全文详解：缓存命中、指令反模式与努力度校准
Claude Platform 降本增效官方指南全文详解：缓存命中、指令反模式与努力度校准
性能和成本通常被视为取舍：想省钱就得接受更差的结果。Anthropic 用三个手段证明这个假设是错的。
本文编译自 Anthropic 官方博客 Reducing cost and improving performance with Claude Platform（作者 Lance Martin，2026 年 9 月 8 日），保留原文全部技术细节与数据。
性能和成本通常被视为一对取舍：想少花钱，就得接受更差的结果。但实践中 Anthropic 发现，很多使用 Claude Platform 的应用可以在不牺牲性能的前提下砍掉成本，靠三个手段：
- 最大化提示词缓存命中率（prompt cache）
- 升级到前沿 Claude 模型时清除提示词里的反模式（instructions）
- 把努力度校准到任务（effort）
这套指导已经沉淀进了 claude-api skill。这篇文章展示了带 claude-api skill 的 Claude Code 如何在保持甚至提升性能的同时找到降本路径——实测在四个公开基准上最高降本 73%，一次模型迁移实验中成本降 14.6% 的同时准确率反升 5.3%。
一、提示词缓存（Prompt Cache）
原理：省掉最贵的 prefill
Claude 生成回复之前，要先把你的提示词处理成内部工作状态，这一步叫 prefill，是处理输入中最昂贵的部分。提示词缓存保存的就是这个状态（键值对，即 KV cache）：当一个请求以相同的前缀开头时，Claude 直接读回来而不重新计算。缓存读取的计费只有完整输入价格的一小部分。
三个硬约束
用好提示词缓存，先要理解它的三个限制：
- 绑定特定模型——缓存钉死在某个模型上，换模型缓存即失效
- 字节级精确——缓存读取要求整个提示词范围内逐字节一致
- 有限的生存时间（TTL）——缓存有有效期，过期作废
五个破坏缓存的常见做法
1. 会话中途更改 effort 或 thinking 设置。这些设置会被渲染在内容之前的提示词里，属于缓存前缀的一部分。（例外：Claude Opus 5 和 Fable 5.1 支持会话中途更新 effort 而不破坏缓存。）
2. 把易变值放进前缀。系统提示词里的动态时间戳或 ID 会在每次模型调用间变化，直接打断缓存。
3. 工具定义自我重排。Claude Messages API 按固定顺序组装提示词，工具定义渲染在最顶部。工具定义的任何变动都会破坏缓存。
4. 分叉会话时要小心。子代理和分支只有在前缀逐字节一致、同一模型、同一 effort 时才共享父级的缓存。
5. 同步工具调用和子代理超出缓存 TTL。如果 Agent 阻塞在一个长时间运行的工具调用或子代理上，缓存可能在结果返回前过期。下一轮就得重写缓存，价格是正常输入的 1.25 倍（1 小时缓存则是 2 倍），而不是便宜的读取价。
八个修复方法
Anthropic 从构建 Claude Code 中积累了这些经验：
1. 仔细监控缓存命中率。Claude Console 提供缓存诊断，包括缓存未命中的原因分析——它能对比连续两个请求，精确指出提示词前缀在哪里分叉（原文 Figure 1）。
2. 延迟加载不常用工具。把所有工具预先声明，但把少用的标记为 defer_loading：它们不进缓存前缀，只在 Claude 通过工具搜索查找时才追加进会话，缓存得以保留。
3. 系统提示词更新用消息形式下发。Claude Platform 允许把系统指令作为会话中的消息添加，而不是编辑系统提示词本身，缓存不破。
4. 布局请求时让稳定的部分保持稳定。静态上下文（工具定义和系统提示词）放前面，不断增长的会话放在后面（原文 Figure 2）。
5. 在缓存反正要破的时候换模型或 effort。某些操作（如压缩 compaction）本来就会重写大部分缓存（会话部分）。这是切换模型或 effort 的好时机——反正都得付一次未命中的钱。
6. 随会话增长移动缓存断点。Claude Platform 支持设置自动缓存，自动把缓存断点应用到最后一个可缓存块。
7. 预热缓存。为了降延迟，发一个 max_tokens: 0 带显式缓存断点的请求——它只处理提示词并写入缓存，不生成任何内容。在会话开始时跑（比如用户还在打字的时候），第一个真实请求就能命中热缓存。
8. 别超出缓存 TTL。5 分钟缓存 TTL 从请求开始时计算。如果 Agent 阻塞在超过 5 分钟的工具调用或子代理请求上，父级缓存会在结果返回前过期。这种情况考虑在前缀上设置 1 小时 TTL。
二、指令（Instructions）：六个提示词反模式
提示词会积累一些"给模型打补丁"的指令。这些指令相对最新 Claude 模型的能力已经过时。以下是常见的提示词"反模式"——它们拖累前沿 Claude 模型，还会不知不觉推高成本：
1. 验证仪式。"仔细检查你的工作"、"回复前验证两遍"这类指令会被前沿模型字面化执行，浪费 token。
2. 彻底性和强调强化剂。"做到最大程度的彻底"、"关键：你必须永远……"会导致前沿模型啰嗦冗长、发起多余的额外工具调用。
3. 强制流程和草稿纸脚手架。固定的分步流程（如"在草稿纸里一步步思考"）或推理模板是前沿模型不需要的仪式。这些脚手架会叠加在原生推理之上，消耗不必要的 token。
4. 过时的示例。针对旧模型失败模式调优的 few-shot 示例，会教前沿模型在不需要的请求上模仿冗长的推理链。
5. 矛盾的规则。前沿模型更擅长遵循指令。矛盾的指令（"始终在政策内退款" vs "未经升级审批绝不退款"）会被前沿模型更字面化地执行，导致性能下降。
6. 过时的配置。为旧一代 Claude 写的设置（如手动 thinking 预算）在升级到前沿模型时会被 Claude Platform 拒绝。
修复：prompt-audit 命令 + 迁移实验
claude-api skill 新增了一个盯防这些反模式的命令。在 Claude Code 里对你的提示词、skills 或工具描述运行 /claude-api prompt-audit。审计覆盖工作目录里的一切，包括调用 Claude API 的应用代码和 Claude Code 自身的配置（CLAUDE.md、skills）。
实验设计：Anthropic 在一个客服支持基准上测试了从 Opus 4.8 到 Opus 5 的模型迁移。从干净的提示词出发，一次植入一个反模式（一个已废弃的 thinking 设置、一对矛盾的退款规则、一个手动草稿纸、"verify twice"、"be maximally thorough"、一个强制的六步流程），得到六个"遗留"提示词。每个分别在 Opus 4.8 上、只改模型 ID 的 Opus 5 上、以及跑过一次 /claude-api prompt-audit 的 Opus 5 上运行（原文 Figure 3 为六者平均）。
反模式的具体危害：在 Opus 5 上，验证仪式（"verify twice"）让每次退款都重复查询订单，浪费 token；强调强化剂（"be maximally thorough"）变成了几十次不必要的知识库搜索。
结果：运行 /claude-api prompt-audit 移除反模式后，成本下降 14.6%，准确率平均上升 5.3%。成本下降是因为多余的工具调用和重复推理被消除。准确率上升有三个具体原因：
- 已废弃的 thinking 设置让 API 直接拒绝了每一个路由请求
- 矛盾的退款规则导致 Opus 5 在要求客户确认的同时，扣住了四笔本该退的款
- 手动草稿纸与 Opus 5 的内置思考冲突：在三个工单上它把工具调用写进了推理里却从未执行
三、努力度（Effort）
原理
Effort 告诉 Claude"工作要多用力"。低努力度下 Claude 通常更快得出结论；高努力度下 Claude 会在回答前斟酌、验证、探索备选方案。
数据：收益递减的真实形状
单一模型上不同努力度的成本-性能曲线差异很大：
Claude Fable 5 在 FrontierCode Diamond（最难的 50 个任务）：低努力度 11.5%、每任务 $5.35；最大努力度 30.9%、每任务 $19.00。改努力度让分数涨约 2.7 倍（+19 个百分点），成本约 3.5 倍（原文 Figure 4）。
Claude Fable 5.1 在 Humanity's Last Exam（无工具）：低努力度约 53%、每题约 $0.30；最大努力度约 61%、每题约 $2.23。最后一步升到最大努力度只加约半个百分点，成本却多 46%——这半分在基准的运行间噪声之内，等于多花钱买了个测不出来的提升。
两个方向的错配
方向一：假设越高越好。高努力度可能导致过度思考。Claude 花在斟酌上的时间超过任务应得的限度，增加成本和延迟，还可能降低答案质量。斟酌只在还有证据可找的时候有用。
方向二：偏向低努力度。设得太低，Claude 在证据不足时就停了。它做更少的工具调用，可能从第一个搜索结果而不是第三个作答。它在困难的步骤上想得更少，跳过它通常会自己做的检查。答案看起来完成了，但建立在残缺信息上。
修复方法
1. 用更强的模型测低努力度。强模型低努力度可能比弱模型高努力度更便宜。例如在 CursorBench 3.2 上，Claude Fable 5.1 低努力度以三分之一的价格匹配 Fable 5 高努力度的性能（原文 Figure 5）。两个因素让新模型更便宜：低努力度下每任务工作量更少；Fable 5.1 的缓存读取定价是每百万 token $0.25，Fable 5 是 $1.00。即使按 Fable 5 的价格算，Fable 5.1 低努力度也能省约 40%。
2. 理解你的任务形状。跨一系列努力度测量应用性能，是理解特定任务成本-性能取舍的有用方法。在未饱和的评测上，跨努力度的平坦性能-成本曲线说明任务不受思考算力约束——提高努力度无益。
hillclimb 命令：自动爬山搜索
这种校准通常需要跨模型和努力度跑评测。在 Claude Code 里，/claude-api hillclimb 替你执行这个搜索：把评测分成训练集和测试集，提议配置变更，读取失败的训练样本修复发现的问题。
实验：在客服支持基准上，从 Opus 4.8 默认（高）努力度出发：
- 爬山器先尝试 Opus 5 低努力度，配合 prompt-audit 移除强制工具调用仪式、草稿纸步骤和矛盾规则——以 98.9% 训练准确率越过 Opus 4.8 基线，成本降到每工单 2.6 美分
- 接着降到 Sonnet 5 低努力度，更便宜（每工单 1 美分），但准确率掉到 88.9%
- 读取失败的训练工单后，Claude 给提示词加了路由规则和退款上限交叉引用，把 Sonnet 5 拉回 98.9%，成本不变
最终成绩：在搜索从未见过的 14 个保留测试工单上，最终配置得 90.5%，原始配置 78.6%，成本约为原来的五分之一（原文 Figure 6）。
四、自动化成本优化：cost-optimize 命令
提示词缓存、指令、努力度是降本的常见杠杆，官方文档覆盖更多。要对使用 Claude API 的应用代码做整体成本审计，Anthropic 加了 /claude-api cost-optimize：它分析你的钱花在哪，应用降本措施，如果你提供评测，还能展示省下来的钱和性能如何取舍。
工作流程：
- 先找到 token 去向：如果你有 Claude Admin API key，从组织的用量和成本报告读取；否则从每个 API 响应的 usage 对象读取（前提是应用有日志）；两者都不行就读取构建请求的代码来估算
- 给可省项目排序：从提示词缓存开始，裁剪每个请求携带的内容（包括跑一次 prompt-audit），限制输出长度，把无人值守的工作批处理
- 有评测则更进一步：跨努力度和模型选择计算成本和性能
四个公开基准实测（以 Sonnet 5 为基线）
1. LegalBench（降本约 58%）：cost-optimize 建议跨任务缓存共享前缀、设低努力度、用 Batch API 处理任务。思考 token 从 102,779 降到 8,284，通过率保持在噪声范围内，成本降约 58%。
2. tau2-bench retail（降本约 73%）：通过实现带显式断点放置的提示词缓存，cost-optimize 把开销降了 73%，通过率持平。
3. OfficeQA Pro（降本约 52%）：cost-optimize 加了批处理和文档缓存，成本从 $136.20 降到 $64.87。
4. SWE-bench Verified（降本约 55%）：cost-optimize 发现默认配置已经正确缓存了。节省来自把努力度设为中等、把 Agent 输出限制为几句简洁的话。每任务中位步骤从 29 降到 17，提示词 token 从 75.2M 降到 33.7M。
（原文 Figure 7 展示四个基准上成本与性能的变化全景。）
五、上手指南：三个命令怎么选
/claude-api prompt-audit——当你迁移到前沿 Claude 模型、想检查现有提示词时用。它扫描工作目录里的提示词、skills 和工具描述，可以是调用 Claude API 的应用代码，也可以是 Claude Code 的配置（CLAUDE.md、skills）。它移除拖累前沿模型的常见反模式。
/claude-api cost-optimize——当你的应用使用 Claude API、想做成本审计时用。它分析 token 花费，然后测试不同杠杆：应用 prompt-audit 之外，还检查通过提示词缓存、批处理无人值守工作、限制输出降本的路径。如果你提供评测，它还会测量努力度和模型选择的取舍。
/claude-api hillclimb——用于成本和性能的迭代搜索。给定一个评测，Claude 把它分成训练集和测试集，然后提议对应用的更新，目标是降本同时保持基线性能。Claude 读取失败的训练案例引导搜索，最终配置在保留测试集上评分。
放回大图
这篇文章的三个杠杆和我们之前拆解过的案例严丝合缝：
- Spotify Portal 做的是模型路由（贵模型只干推理活），本文的 effort 校准是它的官方版——"强模型低努力度"就是"好钢用在刀刃上"
- Anthropic commerce-agents 里提到的
cache_read_input_tokens缓存命中验证，正是本文第一大杠杆的工程化落地 - Opik Agent Optimizer 用六种算法搜最优 Prompt，本文的
prompt-audit是更轻量的"反模式清除"路线——先移除负优化，再谈正优化
值得注意的趋势：Anthropic 把这些经验做成了 skill 里的命令而不是文档里的建议——prompt-audit、hillclimb、cost-optimize 三个命令分别对应"清反模式"、"搜配置"、"整体审计"三个层次，AI 自己读失败的训练样本自己改提示词。降本这件事，正在从"人读文档手动调"变成"Agent 跑命令自动查"。
作者: itech001 来源: 公众号：AI人工智能时代(the-ai-era) 网站: https://www.theaiera.top/ 关注每日最新AI新闻和技术博客，主页有更多的文章的AI 技术参考：https://www.theaiera.top
本文首发于 AI人工智能时代，转载请注明出处。原文版权归原作者所有。
