[控场AI]
· 7 分钟阅读· 3,505 字

Claude Opus 5.5 正确用法:官方给出的9条提示词新规

Claude Opus 5.5 正确用法:官方给出的9条提示词新规

Anthropic发布Opus 5.5使用指引:用effort参数替代提示词技巧,给完整任务而非碎片指令。

Anthropic为Claude Opus 5.5发布了一套新的交互指引,核心逻辑是:与其用越来越复杂的提示词技巧操控模型行为,不如顺应模型本身的设计机制来工作。具体变化包括:移除「仔细思考」等冗余指令,改用内置的effort参数控制推理深度;一次性提交完整任务并明确定义交付物形态,而非分步喂给模型;在长任务中用CLAUDE.md定义工作规则、tasks.md外化进度跟踪,以应对上下文窗口限制;直接提供截图、图表等原始素材,并要求模型标注无法确认的内容;设计任务中点名不想要的具体风格,长对话中可声明早先答案已定稿以保持聚焦。整体方向是减少提示复杂度,让模型能力得到更直接的发挥。

Anthropic 为 Claude Opus 5.5 发布了一套新的使用指引,核心观点很明确:你不再需要掌握复杂的提示词技巧,而是要改变与模型交互的方式。这些更新涉及努力程度控制、任务分配方式、截图与研究材料处理,以及长对话管理。下面梳理其中最实用的几点变化,以及它们如何改进日常工作流、研究、写作和项目开发。

别再让 Claude「想得更深」,改用努力控制

Anthropic 建议移除诸如「think carefully(仔细思考)」「think step-by-step(逐步思考)」这类要求模型更努力推理的指令。原因在于 Opus 5.5 在每次回复前已经会进行思考,这些指令变得多余。测试中去掉「仔细思考」这类提示后,回复开始得更快,而质量没有明显下降。

如果只是简单问题想要快速答案,直接说「answer directly(直接回答)」即可。

直接回答简单问题

真正控制思考深度的,是 Opus 5.5 自带的 effort(努力程度)设置。默认是中等(Medium)。与其堆砌更多指令逼它多想,不如用这个开关来调节:简单任务用较低的努力程度就够了,困难任务则相应提高。这是官方推荐的替代方案,比在提示词里反复强调「想清楚」要干净利落得多。

Effort(努力程度)控制是 Claude Opus 5.5 API 层面提供的一个参数,允许开发者或用户在调用时指定模型投入多少计算资源进行思考推理。这与早期模型中用户只能通过提示词「说服」模型多思考的方式有本质区别——后者属于自然语言层面的间接引导,效果不稳定且难以量化;而 effort 参数则是对模型行为的直接调节。低 effort 适合信息检索、格式转换等确定性任务,高 effort 则适合需要多步推理、权衡多种方案的复杂分析。理解这一机制有助于在成本、速度与质量之间做出合理取舍,而不是默认所有任务都用最高推理强度。

给 Claude 完整任务,并定义「完成」的标准

另一个关键转变是:把完整的工作一次性交给 Claude,而不是一步步喂给它一个个小片段。告诉它你想要什么、最终成果应该长什么样。对于较长的任务,还可以告诉它什么时候该停下来向你确认。

官方给出一个对比例子。与其只说「总结这些文章」,不如这样写:「审阅这五篇文章,总结它们的主要差异,把结果整理成对比表格,并标出你不确定的地方。」后者明确定义了交付物的形态,效果远好于模糊的指令。

这背后的逻辑是,Opus 5.5 有能力处理更复杂、更清晰的完整任务,拆得太碎反而限制了它的发挥。

用两个文件让 Claude 在长任务中保持轨道

对于较长的 Claude Code 任务,有两个简单文件能帮模型不跑偏。

项目指令文件

第一个是 CLAUDE.md 文件。这里存放你希望 Claude 在整个项目中遵循的指令,比如任务说明、项目结构、工作流程,或某些任务的具体处理方式。

第二个是针对耗时较长的运行:让 Claude 把它的任务清单保存到一个文件里,比如 tasks.md,并在推进过程中实时更新。例如告诉它「把清单保存在 tasks.md,每完成一项就勾选,发现新内容就补充进去」。

这一点之所以重要,是因为长时间运行会填满上下文窗口,Claude Code 可能会对较早的对话内容做摘要压缩。一个保存在文件里的任务清单比翻聊天记录更容易核对,清楚显示哪些已完成、哪些还没做。

简单记法:CLAUDE.md 告诉 Claude 怎么干活,tasks.md 告诉 Claude 干完了什么、还剩什么。

上下文窗口(Context Window)是大语言模型一次能处理的最大文本量,以 token 为单位计量。当对话或任务内容超过这一上限时,模型会对较早的内容进行摘要压缩甚至丢弃,导致它「忘记」任务初始的细节和约束条件。Claude Code 在长时间运行的编程任务中尤其容易遇到这个问题——随着文件读写、命令输出不断累积,上下文很快被填满。将任务清单外化到 tasks.md 文件的本质,是把「工作记忆」从容易被截断的对话流中转移到持久化的文件存储中,绕过上下文限制,让模型在任何时间点都能通过读取文件重建当前进度,而无需依赖对早期对话的完整记忆。

不要索要隐藏的推理过程,直接要你想要的东西

Anthropic 指出,要求复现 Claude 内部推理的请求可能会被拒绝。应避免「show your chain of thought(展示思维链)」「think out loud(出声思考)」「show every reasoning step(展示每一步推理)」这类表述。

正确做法是直接要你真正想要的结果——比如「解释一下你为什么这么建议」,而不是去挖它的内部过程。这其实也呼应了第一条:把精力放在输出上,而不是过程控制上。

Claude Opus 5.5 采用了「扩展思考(Extended Thinking)」架构,模型在生成最终回复前会在内部进行一个独立的推理阶段。这个内部思考过程并非对话历史的一部分,也不完全等同于最终回复中可见的逻辑链条。Anthropic 将内部推理视为模型的「私有」计算过程,因此要求模型「展示思维链」或「逐步出声思考」实际上是在要求它重新用自然语言复现一个已经完成的内部过程,这不仅可能触发拒绝响应,也往往会生成冗长且不必要的内容。正确的替代方式是直接描述你需要的输出形式,例如「说明你建议这个方案的原因」——这要求的是一个解释性输出,而非内部推理的镜像。

给 Claude 原始材料,并让它说明无法确认的内容

Anthropic 建议直接附上真实的截图、图表、示意图或幻灯片,而不是把信息重新打字转述。Opus 5.5 在理解「信息出现在图像哪个位置」这类依赖视觉布局的内容上更强。

提供原始文档

官方举的例子包括:某个箭头连接的是哪个方框、两张示意图之间的差异、日历上某件事的开始或结束时间等。你也可以把长文档交给 Claude,让它查找数字、人名或日期中的矛盾。

与此配套的建议是:让 Claude 主动告诉你它无法确认的内容。比如要求它「标出你无法确认的任何内容,并说明你查了哪里」。这对研究、对比、事实核查等依赖信息来源的场景尤其有用。

明确说出你不想要的设计风格

在设计类任务中,Anthropic 指出像「make this less generic(让它别那么普通)」「avoid an AI look(避免 AI 感)」这类模糊指令往往不够具体。

更好的做法是点名你不想要的确切风格。例如:「用占位内容搭一个个人网站,不要用米色或灰白背景、斜体强调词、01/02/03 式的编号标题、等宽字体标签,或药丸形按钮。」如果你已经有一套设计系统,直接把它给 Claude 效果更好。

告诉 Claude 哪些早先答案已经定稿

在长对话中,Opus 5.5 有时会在工作过程中回头重新考虑之前的答案。

在项目指令中加入设定

可以在项目指令中加入这样的设定:「一旦你回答过某件事,就把那个答案当作已定稿。专注于我现在问的问题,除非我主动提及或指出其中有问题,否则不要回头重审早先的答案。」

这能让长对话保持聚焦,但存在一个权衡:Claude 可能更不容易自己主动发现并修正早先的错误。因此 Anthropic 提醒,不要在那种「后续信息可能改变早先结论」的长篇分析中使用这条规则。

总结:改变交互方式,而非增加提示复杂度

这套 Opus 5.5 指引的核心,不是让你去掌握某种复杂的新提示技巧,而是改变你与模型交互的习惯:

  • 不要把任务拆成小碎步,而是给它更复杂、更清晰的完整任务;
  • 用模型已有的控制项(如 effort)来引导行为;
  • 让它在长任务中不被打断地持续工作;
  • 尽可能提供原始素材;
  • 最重要的是,明确说清你想要它产出什么。

如果你此前有一套固定的提示习惯,建议先小范围测试这些新做法——它们能让 Claude 更好用,同时又不会让你的提示词变得更复杂。

分享:

相关推荐