每次调用Claude API，你都在为两类东西买单：真正干活的推理，以及那些看不见的“认知磨损”。Anthropic的工程师最近在一篇技术分享里直接挑明了这件事——他们给了三把钥匙：prompt cache命中率、提示词反模式清理，还有effort校准。这三件事如果你能做成，大概率可以在不牺牲性能的前提下，把成本砍下三分之一，甚至更多。
一、先把你已经支付的缓存钱捡回来
缓存不是让你省，而是把你的重复劳动变得廉价
Prompt cache在Anthropic的语境里并不复杂。它会把请求中固定的前缀token存下来，后续请求如果命中，这部分token就按一个“缓存价”计算——大致是平时输入价的十分之一。也就是说，你每天跑的大量重复任务，本来只需要付出零头。可现实是，很多人从未刻意设计过自己的请求，让所有token每次都走全价。
更可惜的是，官方团队贴出过一组对比：同样一批任务，在缓存优化之前和之后，输入成本完全不是一个量级。他们做的最粗浅的改动，只是把变化的内容往提示词的尾部移动，命中率就立刻有了可观提升。这说明很多人不是不想省钱，而是不知道钱到底花在了哪里。
命中率上不去的三个坑
第一个坑，是把“每时每刻都在变”的内容放在开头。时间戳、随机数、用户状态，这些字段只要出现在前缀里，缓存就直接失效。第二个坑，是没有给缓存设置任何标记。你想命中，但模型端并不知道这段前缀可以复用，于是它只能当全新内容去处理。第三个坑，是缓存周期设得太短。一个每日任务的前缀刚刚被缓存，还没到下一次调用就被过期清理，等于白白浪费了一次建缓存的机会。
从部署层面做的两个调整
最有效的一个动作，是让稳定部分彻底前置。把system prompt、任务定义、格式示例这些基本不变的内容按固定顺序拼好，再让唯一变化的参数坐在最尾部。另一个动作，是使用cache_control参数并指定一个合理的ttl，让它明确知道要保留这一段前缀。官方实测中，这两个改动可以把命中率从60%出头稳定拉到85%以上。这个数字已经是成本曲线的甜蜜点。
二、升级到前沿模型后，提示词为什么成了累赘？
旧模型的“低语”，新模型不需要
模型之间的提示词习惯并不通用。过去用Claude的旧版本，你需要在提示词里反复输出“请认真思考”“不要遗漏任何细节”这类话，因为那时的模型真的会因为少一句而偷懒。可当你把同样的提示词原封不动地搬到Sonnet或者Opus这类前沿模型上时，这些反复出现的“叮嘱”反而成了噪声。Anthropic团队发现，很多用户升级模型后第一个月性能下降，原因根本不是新模型变蠢了，而是提示词还在用旧时代的方式跟新模型说话。
反模式清单：哪些话正在稀释你的响应质量
官方列举的反模式很有代表性：一是在一句话里同时塞进五条约束，让优先级变得模糊；二是用否定句式写行为规则，比如“不要胡编乱造”连续出现三次；三是在few-shot示例里放了好几个质量不高的示范，反而把模型带偏；四是把边界条件翻来覆去地强调，占用了大量输入token。这些反模式在旧模型上或许是不得已的补丁，在Claude的新模型上，它们只是成本和干扰的双重累赘。
清理后的意外收获：省了token，还保住了分数
在官方公布的一个编码场景case里，工程师把提示词做了“外科手术式”的修剪：删掉所有重复限制，把否定句改成直接、肯定的指令，再对示例做减法，只保留一组正反对照。这段prompt在公开的代码生成基准上跑了一遍，分数并没有下降，反而微涨；输入token却减少了约三成。这相当于你花更少的钱，得到了更干净的输出。用来验证性能是否回退的那套测试，他们放在了自己的CI流程里，每次改prompt都会自动跑，所以这次清理并不是拍脑袋。
三、effort：一直被忽略的成本旋钮
effort控制的是什么？
在Claude的新模型体系里，effort是控制模型“思考投入度”的概念。它决定了模型在给出最终答案之前，愿意花多少隐性推理去展开中间步骤。把effort调高，模型会倾向于自我检查、尝试多条思路；调低，它就直接给出一个最可能的答案。这个参数与最终的输出token无关，但它的消耗一点不小，因为在答案落地之前，那些“思考”同样要算进成本里。
校准不是拍脑袋，而是跑基线
很多人一听到effort就习惯性地全部拉满，害怕效果变差。但如果你对请求做一次类型拆分，会发现大多数简单任务根本够不着那条“满血线”。比如给函数写一个正则、提取一段结构化信息，哪怕让它用最低档的effort，输出也和满载时没有肉眼可见的差别。校准动作其实很简单：为你的任务各准备几组代表性的输入，分别用低、中、高三档跑一遍，记录下质量与消耗，再对照阈值选一个最经济的档位。Anthropic团队内部也是这么做的，而且他们发现，越难的任务越值得手动调，越简单的任务越应该“一刀切”放到最低档。
一条可复用的决策准则
我的建议是：新上线的功能先默认用中低档，再从失败样本里逐级往上加。如果你发现一条请求在低effort下反复出问题，那再上调一档，把每次失败当成一次采购额外思考力的依据。在Anthropic对一批编码任务的实测中，他们将不同档位的effort做了拆分，最终在总基准分数几乎不变的前提下，把推理相关的成本压低了将近一半。这就是校准的回报。
四、三种手段的组合拳，顺序比力度重要
先从cache下手，因为它影响最基础的一层
降本方案里的优先级是真实存在的。缓存降的是每一次请求的固定输入成本，这个数字是整个账单的地基。地基没打好，谈effort都是在半空中调整。所以如果你的服务主要差距是在输入token上，别急着去控制思考深度，先把请求结构改对，让命中的部分自动便宜下来。
清完提示词，再看effort，避免相互干扰
提示词里的冗余和冲突会让模型分心，也让后续的effort校准失准。试想，一条本身就含混的prompt，你把它放到高effort下运行，模型可能会花大量思考去猜测你到底要什么，而不是把能力用在刀刃上。Anthropic团队自己的处理路径也很清晰：先清除反模式，让提示词回归直接、明确的风格；再做effort梯度测试，这样每一份额外的思考都对应着真实的任务复杂度。
最后，用一套可持续的监控机制守住战果
一次优化做完只能算开始。缓存命中率会随着新功能的上线而波动，提示词也随时可能被某个激进的产品经理改坏。我的经验是，把prompt cache命中率和effort档位作为两个长期监控项纳入看板，任何改动都跑一遍轻量回归。技巧能帮你省一部分钱，但唯有机制能让你一直省下去。
