Claude Platform 降本增效实操指南摘要

本文是对官方文章「Reducing cost and improving performance with Claude Platform」的中文要点摘要，完整内容以原文为准：https://claude.com/blog/reducing-cost-and-improving-performance-with-claude-platform

这篇文章（作者 Lance Martin,2026年9月发布）围绕一个问题展开：在切换到更强的 Claude 模型或规模化使用 Claude API 时，如何系统性地降低成本、同时保持甚至提升效果。文章给出了四条主线：prompt cache、指令（prompt）审计、effort 校准，以及三个可直接调用的 /claude-api 命令。

Prompt Cache：最大的省钱杠杆

Claude 在生成回复前会先把 prompt 处理成内部工作状态（prefill），这一步是处理输入中最贵的部分。缓存读取的成本只是完整输入价格的一小部分，因此缓存命中率直接决定了成本高低。

缓存生效有几个硬约束：

• 缓存绑定到具体模型，换模型或换 effort/thinking 设置都会使缓存失效；
• 缓存要求整段 prompt 在字节层面完全一致，时间戳、请求 ID 等动态值一旦混入前缀就会破坏缓存；
• 缓存有生存期（TTL），默认约 5 分钟，可配置到 1 小时，同步工具调用耗时过长同样会让缓存过期。

官方给出的实操建议：

• 用 Claude Console 监控 cache hit rate，而不是凭感觉判断；
• 对很少用到的工具使用 defer_loading 延迟加载，避免工具定义顺序被打乱；
• 需要临时补充信息时用「对话中途插入系统消息」，而不是直接编辑系统提示（编辑会破坏缓存前缀）；
• 把稳定内容放在 prompt 前部，动态内容放在末尾追加；
• 利用自动缓存功能让断点自动应用，或在必要处手动设置 cache breakpoint;
• 对低频但关键的请求，可发一个 max_tokens: 0 的请求预热缓存。

清理指令中的反模式

文章指出，很多为旧模型（尤其是推理能力较弱的模型）写的提示词，包含大量「保险性质」的指令，在前沿模型上反而会被字面执行，造成浪费。典型反模式包括：

• 验证仪式：诸如「double-check your work」「verify twice before responding」这类措辞，前沿模型会真的重复核实，多打一次不必要的工具调用；
• 彻底性强调：「Be maximally thorough」「CRITICAL: YOU MUST ALWAYS」等强调语气，导致回复冗长、工具调用过多；
• 强制程序 / 草稿垫脚：规定死板的分步流程或推理模板，给本地推理堆上不必要的 token;
• 过时的 few-shot 示例：是针对旧模型的失败模式专门调整的，放到新模型上反而误导；
• 互相矛盾的规则（例如退款政策里前后打架的条款）；
• 过时配置：比如为旧版 Claude 手写的 thinking 预算参数。

官方建议直接在 Claude Code 里跑 /claude-api prompt-audit，它会扫描工作目录里的 prompt、skills 和工具描述（包括应用代码与 CLAUDE.md、skills 配置），找出上述反模式并给出修改建议。文中一个 Opus 4.8 迁移到 Opus 5 的例子里，跑完 prompt-audit 后成本降低 14.6%，准确度反而提高 5.3%——此前的验证仪式导致了重复的订单查询，彻底性强调则触发了大量不必要的知识库搜索。

Effort 校准：不是越高越好

effort 参数决定 Claude「多努力地」思考：低 effort 更快得出结论，高 effort 会更多地权衡、验证、探索备选方案。文章提醒两种常见的误配置：

• 默认调高 effort：以为更高总是更好，结果过度思考，成本和延迟都上升，质量未必更好；
• 默认调低 effort：模型过早收敛，信息不足，工具调用偏少，导致准确度下降。

校准思路是针对具体任务形态，横向测试不同模型 × 不同 effort 组合。文中举例：Fable 5.1 在低 effort 下的成本，只有 Fable 5 高 effort 的三分之一（缓存读取价格 0.25 美元/百万 token，对比 Fable 5 的 1 美元）。

官方提供 /claude-api hillclimb 命令做自动搜索：把评估集切成训练集/测试集，不断提出配置改动，通过阅读训练集里的失败样本来定位问题并修复，最终配置在留出的测试集上打分。文中的客服场景案例显示：从 Opus 4.8 高 effort 基线出发，先尝试 Sonnet 5 低 effort 虽然把每张工单成本降到 1 美分，但准确度掉到 88.9%；补上路由规则和退款上限的交叉校验后，准确度回升到 98.9%，成本仍保持在 1 美分，测试集整体表现从 78.6% 提升到 90.5%，而成本只有原来的五分之一。

自动化成本审计：/claude-api cost-optimize

这是文章介绍的第三个命令，流程分三步：

1. 定位 token 花在哪：结合组织的用量与成本报表（需要 Claude Admin API key）、每次 API 响应里的 usage 对象，以及对请求构造代码的静态分析；
2. 排出可用的节省手段优先级：prompt caching、按需裁剪每次请求的内容、prompt 审计、限定输出边界、把无需实时响应的工作切到 batch processing;
3. 如果提供了评估集，还会计算不同 effort 水平和模型选择之间的成本-性能权衡。

文章给出了从 Sonnet 5 基线出发、跑完整套优化后的几个基准数据（供参考量级，非普适承诺）：LegalBench 成本降低约 58%（靠共享前缀缓存、低 effort、Batch API）；tau2-bench retail 降低约 73%（靠明确设置缓存断点）；OfficeQA Pro 降低约 52%（批处理+文档缓存）；SWE-bench Verified 降低约 55%（中等 effort+输出约束）。

快速上手

文章最后把三个命令按使用场景归纳成一张清单：

三者可以配合使用：先用 prompt-audit 清掉明显浪费，再用 cost-optimize 摸清花销结构和缓存/批处理空间，最后如果有条件构建评估集，用 hillclimb 做更精细的 effort/模型搜索。