Anthropic 发布 Claude Platform 降本指南：自称 prompt-audit 平均降本 14.6%、准确率提升 5.3%

Anthropic 官方开发者账号 @ClaudeDevs 于 9 月 8 日在，推介 Anthropic 同日发布的工程指南《》（降低 Claude Platform 成本并提升性能）。指南给出的核心判断是：多数基于 Claude Platform 的应用可以在不牺牲性能的前提下降低成本，做法有三：最大化 prompt cache（提示词缓存）命中率、在升级前沿 Claude 模型前清理提示词里的“反模式”、按任务校准 effort（投入程度）。

Anthropic 同时把这份指南做进了工具：相关做法被收入 claude-api skill，并在 Claude Code 中新增 /claude-api prompt-audit、/claude-api hillclimb、/claude-api cost-optimize 三个命令。文章自称，在把客户支持基准从 Opus 4.8 迁移到 Opus 5 的测试中，对六个“遗留”提示词各跑一次 prompt-audit，平均降本 14.6%、准确率提升 5.3%；hillclimb 搜出的最终配置在 14 张模型未见过的工单上拿到 90.5% 的准确率，高于原配置的 78.6%，成本约为原来的五分之一。这些数字全部出自 Anthropic 自家基准与内部工具，属于官方自述口径，指南由 Lance Martin 署名。

三个杠杆的机制：缓存计费、指令漂移与 effort 档位

指南先把成本高的原因拆开：在 Claude 生成回答之前，模型要把整段提示词处理成内部工作状态，这一步叫 prefill（预填充），输入处理成本的大头发生在这里。prompt cache 把这一状态（键值缓存）保存下来，后续请求只要以相同前缀开头，就直接读回缓存而不是重算；缓存读取只按全价输入的一小部分计费。提示词怎么组织、怎么升级，以及让模型“多用力”，因此成了省钱的主要杠杆。

文章认为，提示词里会积累一层层为修补旧模型弱点而写的指令，这些指令相对最新 Claude 模型的能力已经“漂移”，甚至反过来抬高成本；effort 档位设高设低也各有代价，并非越高越好。三个新命令分别对应这三处：prompt-audit 清提示词、hillclimb 搜模型与 effort 组合、cost-optimize 做整体降本审计。

prompt-audit：先清掉六类“反模式”再迁移模型

文章列举了六类会拖累前沿模型的提示词反模式：验证仪式（如“double-check your work”“verify twice”，前沿模型会照字面执行，浪费 token）；thoroughness 强化词（“Be maximally thorough”“CRITICAL: YOU MUST ALWAYS…”，带来冗长输出和多余的工具调用）；强制步骤与 scratchpad 脚手架（固定流程或思考模板叠在模型原生推理之上，烧掉不必要的 token）；陈旧示例（按旧模型失败模式调教的 few-shot（少样本）示例，会教新模型在不必要的地方模仿长推理链）；矛盾规则（前沿模型更听话，自相矛盾的指令被执行得更字面，性能反而退化）；过时配置（为老一代模型写的设置，如手动 thinking budget，会被 Claude Platform 直接拒绝）。

测试是这样设计的：从一个干净的提示词出发，一次只埋入一个反模式，六次分别埋入已退役的 thinking 设置、一对矛盾的退款规则、一个手动 scratchpad、“verify twice”、“be maximally thorough”和一段强制六步流程，得到六个 legacy 提示词，各自跑在 Opus 4.8、只改模型 ID 的 Opus 5、以及 Opus 5 加一次 prompt-audit 上。文章 Figure 3 展示的就是六个提示词的平均结果（下图）：只把模型换成 Opus 5 时，每张工单成本从 2.52 美分抬到 3.43 美分，准确率从 89.4% 升到 91.7%；再跑一次 prompt-audit，成本降到 2.93 美分、准确率升到 97.0%，即平均降本 14.6%、准确率提升 5.3 个百分点。

钱省在哪里，文章给了具体例子：在 Opus 5 上，“verify twice”会让模型在每笔退款里重复查一次订单；“be maximally thorough”带来几十次用不上的知识库检索。准确率的提升则另有三个来源：退役的 thinking 设置让 API 直接拒绝每一个路由请求；矛盾的退款规则让 Opus 5 扣下四笔本该退的钱，转而要求客户确认；手动 scratchpad 与 Opus 5 的内置思考相撞，三张工单上模型把工具调用写进了推理文本，从未真正执行。prompt-audit 会扫描工作目录里调用 Claude API 的应用代码，以及 Claude Code 自身配置（CLAUDE.md、skills），把这类反模式从提示词里移除。

effort：在成本-性能曲线上找档位

同一模型上，effort 档位换来的是成本与分数的不同组合。按文章数据，Claude Fable 5 在 FrontierCode Diamond（最难的 50 道题）上，低档 effort 得分 11.5%、每任务 5.35 美元，最高档得分 30.9%、每任务 19.00 美元，分数约为低档的 2.7 倍、成本约为 3.5 倍。

另一个模型的曲线则提醒“最后一档”未必值钱。Fable 5.1 在 Humanity's Last Exam（无工具）上，低档约 53%、每题约 0.30 美元，最高档约 61%、每题约 2.23 美元；从高档再升到最高档只多约半分，却要多付 46% 的成本，而这增益落在基准自身运行噪声之内，按文章的说法，多花钱买不到可测的提升。

方向拧反同样有问题。文章提醒两种误校准：一律开高 effort，模型会在任务不值得的地方过度斟酌，加钱加延迟，甚至损害回答质量，而斟酌只在还有证据可找时才有帮助；一律开低 effort，模型会在证据不足时就停：工具调用变少，可能拿第一个搜索结果而不是第三个就作答，答案看似完整，实则建立在部分信息上。

把更强的模型调低 effort，有时比弱模型开高 effort 更便宜。在 CursorBench 3.2 上，Fable 5.1 低档 effort 的表现追平 Fable 5 高档，成本只有后者的三分之一：一是低档下每任务干得少，二是 Fable 5.1 的 prompt-cache 读取价是每百万 token 0.25 美元，Fable 5 为 1.00 美元，即使按 Fable 5 的缓存价格计算，Fable 5.1 低档仍便宜约 40%。

由于“哪一档划算”取决于具体任务，Anthropic 把搜索过程做成了命令：/claude-api hillclimb 会把评估集切成训练集和测试集，提出配置修改，并阅读失败的训练样本找问题。文章展示了它在客户支持基准上的一轮结果：从 Opus 4.8 默认（高档）effort 出发，hillclimber 先试 Opus 5 低档并跑 prompt-audit，清掉强制工具调用仪式、scratchpad 步骤和矛盾规则后，以 98.9% 的训练集准确率通过基线，成本降到每张工单 2.6 美分；接着降到 Sonnet 5 低档，每张只要 1 美分，但准确率跌到 88.9%；读完失败的工单后，Claude 往提示词里加了路由规则和退款上限交叉引用，把 Sonnet 5 拉回 98.9%，成本不变。在搜索从未见过的 14 张留出工单上，最终配置拿到 90.5% 的准确率，成本约为原配置的五分之一。

prompt cache 实战：断点、TTL、预热

缓存生效有三个前提，文章逐个点破：缓存绑定具体模型；读取要求前缀逐字节一致；TTL（存活时间）有限。实际操作里的坑，多数来自无意间改动前缀：动态时间戳或 ID 放进系统提示词、工具定义顺序发生变化、会话中途改 effort 设置，这类设置会渲染进提示词、成为缓存前缀的一部分，一动就 miss。fork 出的子代理和分支也只在前缀逐字节一致、模型相同、effort 相同的条件下才能共享父会话的缓存。唯一的例外是 Opus 5、Fable 5.1 这类可以在会话中途更新 effort 而不破坏缓存的模型。

TTL 是另一个隐藏约束：5 分钟的缓存 TTL 从请求开始计时。如果代理卡在超过 5 分钟的工具调用或子代理请求上，父会话的缓存先过期，下一轮只能重写缓存，按正常输入价 1.25 倍计费（1 小时缓存为 2 倍），而不是便宜的读取价；这种场景文章建议给前缀改设 1 小时 TTL。

Anthropic 给出的修法可以归成几类。一是监控：Claude Console 和 cache diagnostics API 会给出 miss 原因，并指出两次请求到底在哪里分叉（上图即控制台诊断界面）。二是让“会变的部分”远离“不该变的部分”：静态上下文（工具定义、系统提示）放在前面，不断增长的对话放在后面；不常用的工具声明时标上 defer_loading，平时不进缓存前缀，Claude 需要时再通过工具搜索追加进对话；会话中段要加系统指令时，以 message 形式追加，而不是改写系统提示词。三是利用“反正要 miss”的时刻：compaction（压缩）本来就会重写大部分缓存，既然 miss 的费用反正要付，此刻正是换模型或换 effort 的好时机；也可以开启 automatic caching，让缓存断点自动落在最后一个可缓存块上。四是预热：在会话开始时（例如用户还在打字时）发一个 max_tokens: 0、带显式断点的请求，只把提示词处理进缓存、不生成任何内容，第一个真实请求就能命中暖缓存。

cost-optimize：把花销账单跑成降本清单

第三个命令 /claude-api cost-optimize 做整体审计。它先弄清 token 花在哪里：有 Claude Admin API key 就看组织的用量与成本报告；应用记录了每次 API 响应的 usage 对象就用它；两者都没有，就阅读请求构建代码来估算。然后按序排列降本手段：prompt caching、精简每个请求携带的内容（含一次 prompt-audit）、限制输出、批量处理无人值守的工作；如果提供评估，还会跨模型与 effort 档位算一遍成本与性能的权衡。

文章在四个公开基准上跑了 cost-optimize，基线都是 Sonnet 5：LegalBench 降本约 58%（共享前缀缓存、低档 effort、经 Batch API 批量处理，思考 token 从 102,779 降到 8,284，通过率仍在噪声内）；tau2-bench retail 降本约 73%（带显式断点的 prompt caching，通过率持平）；OfficeQA Pro 降本约 52%，成本从 136.20 美元降到 64.87 美元；SWE-bench Verified 降本约 55%，省在把 effort 设成中档、约束代理只输出几句简洁结论，每任务中位步骤从 29 降到 17，prompt token 从 75.2M 降到 33.7M。其中 SWE-bench 还提醒了一点：它的默认配置本来就缓存正确，省钱靠的是别处，并非所有降本都来自缓存。

三个命令的适用时机，文章给出了分工：从旧模型迁到前沿模型、想检查存量提示词，先跑 prompt-audit；用 Claude API 的应用要做成本体检，跑 cost-optimize；手上有评估、想做跨模型跨 effort 的迭代搜索，用 hillclimb，最终配置都在模型没见过的留出集上打分。至于一套应用能从哪一档 effort 里省出钱来，文章给出的判据是任务形状：在非饱和评估上，如果成本-性能曲线是平的，说明任务不受思考算力约束，提高 effort 没有好处。