别再用effort参数控制Claude Opus 5的回答长短了，这根本没用！
Anthropic官方文档刚敲了黑板：这个参数管的是脑子转多快，不是嘴巴说多少话。降低effort只会让模型少想一会儿，但你的回答该多长还是多长。想让它说短点？直接在提示词里写清楚！
2026年7月24日，Anthropic发布了新一代旗舰大模型Claude Opus 5。百万Token上下文窗口、128K最大输出、默认开启思考功能。性能直逼顶配Fable 5，价格只有后者一半。开发者们欢呼雀跃，连夜把代码库里的模型名称从Opus 4.8改成了Opus 5。
然后他们发现了一个诡异的问题。
同样的提示词，Opus 4.8给出的回答干净利落，Opus 5吐出来的东西长得像毕业论文。客服场景里，用户问“密码忘了怎么办”，模型先解释密码安全的重要性，再列出三种找回方式，然后补充两个注意事项，最后附上一段免责声明。用户等了五秒钟，看到五百个字，翻了三屏才找到“点这里重置”那个链接。
产品经理抓狂了。工程师把effort从high一路调到low，回答还是那么长。
这就怪了！
大家都以为effort能控制输出长度，但官方文档说：你想多了。
effort参数控制的是模型在响应时花费的令牌数量，在回答的全面性和令牌效率之间做权衡。说人话：effort越高，模型思考得越深入，推理链条越长，回答越周全。但“思考量”和“输出量”是两码事。降低effort可以减少思考的深度，但不能可靠地缩短你看到的那个回答。
Claude Opus 5的默认面向用户响应比之前的Opus模型都要长。这不是Bug，这是模型变聪明之后的副作用。它太想把事情说清楚了，太想面面俱到了，太想让你觉得它靠谱了。结果就是——话多。
Anthropic在迁移指南里写得明明白白：降低effort会减少思考量，但不能可靠地缩短可见响应。想控制回答长度？直接在提示词里明确要求简洁或指定目标长度。
事情没那么简单！
那effort到底用来干嘛的？官方文档给了五个级别：low、medium、high、xhigh、max。默认值是high。max用于对能力要求极高的工作。low和medium在Opus 5上已经能产出强劲的质量，只是花费的令牌和延迟更少。
所以正确的用法是：用effort控制成本和速度，用提示词控制回答长短。前者管“想多久”，后者管“说多少”。
这就好比你去餐厅点菜。effort是厨师的烹饪时间——你让他快点做（low），菜可能没那么精致，但分量不会变。想让菜量少一点？你得直接跟服务员说“来个小份”。
对吗？
Anthropic给了一个示例提示词，效果出奇的好。
官方文档里写着：对于面向用户的多轮对话产品，加一句这样的指令就行——
> Keep responses focused, brief, and concise.
> Keep disclaimers and caveats short, and spend most of the response on the main answer. When asked to explain something, give a high-level summary unless an in-depth explanation is specifically requested.
翻译过来就是：回答要聚焦、简短、精炼；免责和注意事项一带而过，大部分篇幅给核心答案；解释类问题先给高层概述，除非用户明确要求深入。
就这么几句话，能把Opus 5从“话痨模式”切换成“高效模式”。
为什么这么有效？
第一，它直接告诉模型“你要短”。不是暗示，不是拐弯抹角，是命令。
第二，它给了模型一个判断标准——“大部分篇幅给核心答案”。模型知道什么该多说，什么该少说。
第三，它预设了分层响应逻辑——默认简短，用户追问再展开。这是自适应的长度控制，不是一刀切的截断。
有开发者测试过这个提示词的效果。在客服场景里，加了这句话之后，Opus 5的平均响应长度从500多字降到了150字左右，关键信息反而更突出了。用户等待时间从5秒降到了2秒，满意度不降反升。
这又怪了——说少了反而更好？
Claude Opus 5的提示词策略正在发生根本性变化，很多旧习惯反而是累赘。
Anthropic的工程师在X上发帖说，团队为Claude Opus 5和Fable 5这类新模型删掉了Claude Code超过80%的系统提示词。删完之后重新跑内部编码评测，没有测到性能损失。
80%！这不是小修小补，是推倒重来。
为什么敢这么删？因为Opus 5自己就会做很多事情，不需要你告诉它。它会自我验证、会检查算术、会重新跑测试、会寻找你没提到的边缘情况。你以前的提示词里写的那些“请双检查你的回答”、“验证每一步”、“仔细检查推理过程”——Opus 5本来就在做。你再加一遍，它就做两遍。你为每一遍付钱。
在长时间运行的代理任务上，这不是四舍五入的误差，是实打实的账单。
更离谱的是，有些旧指令还会产生冲突。系统提示词说“适当给代码补充注释”，某个省Token的Skill说“不要添加注释”，用户指令又说“照着原有代码风格补充”。模型懵了——到底听谁的？它得花额外的时间做决策，而不是直接干活。
Claude Code团队的做法是把那些强硬规则删掉，换成一句更短的要求：按照周围代码的写法工作，匹配原有的注释密度、命名和习惯。
这个感觉像不像你问老板方案要做成什么样，老板说“跟咱们原来项目调性一样就可以”。不需要事无巨细地交代，因为对方知道该怎么做。
所以提示词工程的思路要翻转了——从“加东西”变成“减东西”。你主要在删除指令，而不是添加指令。你加的应该是约束：说短点、别跑题、别乱开子代理。
Anthropic官方给Opus 5专门出了一份提示指南，里面藏着好几个反常识的要点。
第一，删除验证指令。这是最重要的一个。搜索你的系统提示词，把“双检查你的回答”、“验证每一步”、“仔细检查推理”这类话全部删掉。Opus 5默认就会做，不用你教。如果你确实有个高风险步骤需要明确验证，只针对那一步做限定，不要搞成全局规则。
第二，明确限制任务范围。Opus 5比旧模型更容易主动委派子代理。在多代理框架里，要明确说明什么情况下该委派，或者直接限制子代理的数量。不然它可能为一个小任务开一堆子代理，你付的钱翻好几倍。
第三，重新跑effort扫描。如果你从旧模型直接搬用了effort默认值，要在你自己的评估上重新跑一次。Opus 5上low和medium的表现比旧模型强得多。别惯性思维用high，可能medium就够用了，成本少一大截。
第四，如果禁用了思考功能，注意effort上限。Opus 5上，只有在effort为high或更低时才能禁用思考。在xhigh或max下禁用思考会返回400错误。这是一个破坏性变更。
这些规则看起来琐碎，但每一条都对应着真金白银。一个没删干净的验证指令，在长时间运行的代理任务上可能多烧掉几十美元。一个没限制的子代理数量，可能让单次调用的成本翻三倍。
那到底怎么正确地让Opus 5说短点？官方给的方案简单到让人不敢相信。
就一句话的事。
在系统提示词或用户消息里，直接写上简洁要求。日常对话用那句经典的：Keep responses focused, brief, and concise.。长系统提示可以在末尾加个精简标签：
如果你想更精细地控制，可以加上篇幅分配原则：免责和注意事项简短，大部分篇幅给主要答案；解释类问题先给高层概述，除非用户明确要求深入。
就这么简单。不需要调参数，不需要复杂的提示词工程，不需要各种花哨的技巧。直接说“说短点”，它就懂了。
对比一下两种做法的差异。错误的做法：把effort从high调到low，期待回答变短。结果思考深度降了，回答长度没变，质量还打折了。正确的做法：保持effort在high，提示词里加一句“Keep responses focused, brief, and concise.”。结果思考深度不变，回答长度降了，质量没打折扣。
前者是南辕北辙，后者是药到病除。
对吗？
但这里有个坑——effort和提示词的关系比想象中更微妙。
官方文档说effort控制的是思考量，不是可见响应长度。但思考量和输出量真的完全独立吗？不一定。思考得更深入，有时候确实会说出更多话。但这两者不是线性关系——思考量翻倍，输出量可能只增加20%。反过来，思考量减半，输出量可能一点没变。
所以effort和提示词是两种不同的杠杆，作用于不同的环节。effort管的是模型内部的推理过程，提示词管的是输出端的表达方式。前者影响“怎么想”，后者影响“怎么说”。
正确的组合策略是：用effort控制推理深度和成本，用提示词控制表达长度和风格。两者各司其职，不要混为一谈。
Anthropic在努力程度文档里也说了，effort是一种行为信号，而不是严格的令牌预算。在较低的努力程度下，Claude仍然会对足够困难的问题进行思考，只是思考量比高努力程度少。它不是开关，是旋钮。旋到low不代表不思考，只是少想一点。
而提示词里的简洁指令是直接的、明确的、可执行的。模型不需要猜测“短”是多短，它知道要聚焦、要精炼、要把主要篇幅给核心答案。
官方给出的示例提示词里，还有一层被很多人忽略的设计。
仔细看那句Keep disclaimers and caveats short, and spend most of the response on the main answer.——它不只是说“要短”，它说的是“把大部分篇幅给主要答案”。
这是一个篇幅分配原则。模型在生成回答时，脑子里有一个隐性的“篇幅预算”。如果不加干预，它会按照默认的分配方案：介绍占10%，主要答案占50%，补充说明占20%，免责占10%，结尾占10%。加了这句指令之后，分配方案变成了：主要答案占80%，其他所有加起来占20%。
结构变了，重点突出了，用户体验提升了。
再看最后那句When asked to explain something, give a high-level summary unless an in-depth explanation is specifically requested.——这是一个条件分支逻辑。默认给高层概述，用户追问再深入。这让模型既能保持首轮响应的简洁，又不牺牲深度解答的能力。
两层设计叠加在一起：篇幅分配+条件分支。前者控制“怎么说”，后者控制“什么时候说什么”。这就是为什么短短几句话能有这么强的效果。
Claude Opus 5的发布，标志着一个新的提示词范式正在形成。
旧范式：写尽可能详细的规则，事无巨细地交代，用提示词工程弥补模型能力的不足。新范式：删除冗余指令，信任模型的判断力，用少量高质量的约束引导模型行为。
旧范式的代表是那些几千字的长篇系统提示词，涵盖所有可能场景，预设所有边缘情况。新范式的代表是那句Keep responses focused, brief, and concise.——简短、明确、可执行。
Anthropic的工程师说，很多提示词在旧模型上是必要的，在新模型上反而是累赘。因为模型变聪明了，它自己就知道该做什么。你不需要告诉它“要验证”，它默认就验证。你不需要告诉它“要周全”，它默认就周全。你需要的反而是告诉它“别太周全”、“说短点”。
这就是为什么Opus 5的提示词策略是“减法”而不是“加法”。
一个具体的例子：以前为了让Claude学会使用工具，最常见的做法是提供几个调用示例。但Anthropic在新模型上发现，演示案例反而可能把Claude限定在演示过的操作范围内。现在只要在接口中规定好状态和规则，Claude就能自行判断该怎样调用工具。
同样的逻辑适用于响应长度控制。以前你可能需要写一大段话解释“什么情况下要短、什么情况下要长、短是多短、长是多长”。现在你只需要说“Keep responses focused, brief, and concise.”——它全懂。
这事还没完。
官方文档里还藏着一个细节，可能颠覆你对max_tokens的理解。
max_tokens在Opus 5上仍然是输出总量的硬限制。但如果你启用了思考功能（默认就是开启的），max_tokens限制的是“思考Token+回答Token”的总和。不是只有回答部分！
这意味着什么？意味着如果你把max_tokens设得太低，模型的思考过程可能被截断，回答质量会断崖式下跌。官方建议从64K令牌开始，在此基础上调整。如果你在xhigh或max努力程度下运行，至少要把max_tokens提到64K作为起点。
这是一个容易被忽略的坑。很多开发者习惯把max_tokens设得很低来控制成本，结果在Opus 5上发现回答质量莫名其妙地下降了。原因就是思考被截断了，不是模型变笨了。
所以正确的成本控制策略应该是：用effort控制思考深度（从而控制思考Token的消耗），用提示词控制回答长度（从而控制输出Token的消耗），两者配合，而不是单纯靠max_tokens一刀切。
官方迁移指南里有一整段在说这个事。如果你从Opus 4.8迁移过来，之前没有thinking字段的工作负载，现在默认会带上思考功能。你需要重新审视max_tokens的设置，或者显式传入thinking: {type: "disabled"}来保持旧行为。
这个细节再次印证了核心观点：Opus 5的工作方式和旧模型不一样了。旧的调优经验不一定适用，甚至可能起反作用。
文章开头提到的那个客服场景——用户问“密码忘了怎么办”，Opus 5写了五百字——如果用对了方法，三句话就能搞定。
第一句：在系统提示词里加上Keep responses focused, brief, and concise. Keep disclaimers and caveats short, and spend most of the response on the main answer.
第二句：把effort保持在high，不要动它。
第三句：把max_tokens调到64K以上，给思考留足空间。
然后重新跑一遍那个客服场景。Opus 5的回答会变成：“点击登录页面的‘忘记密码’链接，按提示验证身份后重置。如有问题联系客服。”一百字以内，核心信息突出，用户体验大幅提升。
同样的模型，同样的能力，不同的提示词策略，输出天差地别。
这不是魔法，这是对模型工作机制的精准理解。
但还有一件事让人睡不着——Anthropic说Opus 5在低effort下准确性依然保持。那是不是意味着以后可以用low跑所有任务，既省钱又快？
官方文档的回答是：视任务而定。low适用于需要最佳速度和最低成本的较简单任务，比如子智能体。medium适用于需要在速度、成本和性能之间取得平衡的代理任务。high适用于复杂推理、困难的编码问题。xhigh和max用于长时间运行的智能体和能力要求极高的工作。
没有一刀切的答案。你得在自己的评估上重新跑一次effort扫描。
这就引出了一个更深的问题：我们到底应该花多少精力在调优提示词上？Anthropic的工程师删掉了80%的系统提示词，性能没降。那是不是意味着我们也可以删掉80%的自定义提示词？
不一定。Claude Code的80%删减是在特定场景（编码辅助）下、针对特定模型（Opus 5和Fable 5）做的。你的场景、你的任务、你的评估标准可能不一样。但方向是明确的——少即是多。删掉那些模型已经会做的事情的指令，保留那些真正约束行为的规则。
文章开头说effort控制不了回答长度——现在你知道了，控制长度靠提示词。文章中间说旧指令可能是累赘——现在你知道了，要删掉验证指令、限制任务范围。文章末尾说max_tokens有陷阱——现在你知道了，要给思考留足空间。
但有一个问题还没有答案：effort和提示词之间的最优配比到底是什么？在什么场景下用low+详细提示词？什么场景下用high+简短提示词？什么场景下用medium+条件分支？
官方没有给出明确的对照实验数据。Anthropic只说“在您自己的评估上重新跑一次effort扫描”。每个任务、每个场景、每个预算约束下的最优解都不一样。
这事还没完。等你跑完自己的评估，可能发现结果和官方文档说的不一样。那才是真正属于你的答案。