Claude 提示词最佳实践:写给用 Claude Code 的开发者

本文是对 Anthropic 官方文档《Prompting best practices》的中文要点摘要,完整内容以原文为准:https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-4-best-practices

文章结构

原文分三部分:先讲 Claude Fable 5、Claude Sonnet 5、Claude Opus 4.8 各自的提示词差异;再讲适用于所有当前模型的通用技巧(清晰表达、上下文、示例、XML 结构、输出格式、工具使用、thinking、多智能体系统);最后是从旧版模型迁移时的注意事项。本篇摘要重点整理模型专属部分和跨模型的共性套路,通用技巧与迁移细节请查阅原文对应小节。

Claude Fable 5:为长时间自主运行调优

• Fable 5 擅长处理以往过于复杂或耗时的任务,单次请求在较高 effort 下可能运行数分钟甚至数小时,需要提前调整客户端超时、流式展示,以及「异步查看进度」而非阻塞等待的产品设计。
• 面对模糊任务容易过度规划,可以加入类似「有足够信息就直接行动,不要重新论证已经确定的事,不要罗列不会采纳的方案」这类指令。
• 指令遵循能力更强,一句简短的规则(例如「先给结论,再给细节」)通常就能替代逐条列举的约束。
• 长任务中偶尔会夸大进度,建议要求它「每条进度声明都要能对应一次工具调用的证据,未验证的部分要如实说明,失败就照实报告」。
• 会更主动地派发并行 subagent,建议明确告诉它何时该委派、何时自己做,并优先异步沟通而非等待每个 subagent 返回。
• 支持构建「记忆系统」:给它一个 Markdown 文件记录经验教训,并说明一课一文件、开头一句话摘要、不要重复记录仓库或对话历史里已有的信息。
• 深度会话中偶尔会用文字宣布要做什么却不发起工具调用,或者已经有把握还要请求许可,可用「继续/直接做到底」推进;自主流水线里应加一句「你在自主运行,用户不在场,不要询问许可」。
• 不建议要求它在回复文本中复述内心推理,否则可能触发 reasoning_extraction 类拒答;需要可见推理时应读取 thinking 块,而不是让它讲出来。

Claude Sonnet 5 与 Claude Opus 4.8:高频共性调优点

两个模型的调优思路高度相似:

• 回复长度:默认按任务复杂度自适应,而非固定啰嗦程度;需要更简洁时直接加一句「简明扼要,省略非必要背景,示例从简」。
• effort 与 thinking:effort(low/medium/high/xhigh/max)是控制智能、延迟、成本的主要旋钮;Sonnet 5 默认开启 adaptive thinking,Opus 4.8 默认关闭、需显式设置 thinking: {type: "adaptive"};temperature/top_p/top_k 设为非默认值时两者都会直接返回 400 错误,迁移时应移除这些参数,改用系统提示控制文风。
• 更字面化的指令遵循:不会把某条规则自动推广到相似场景,需要显式声明适用范围,例如「把这个格式用到每一节,不只是第一节」。
• 代码评审场景召回率下降:当提示词写着「只报告高严重度问题」「保守一点」时,两个模型会更严格执行,导致排查深度不变但报出来的 bug 变少;建议改成「所有发现都报出来,含低置信度的,严重度筛选交给下一步做」。
• 前端/设计默认风格:Opus 4.8 偏好米白背景配衬线字体的编辑风格,Sonnet 5 也有类似的默认审美倾向;「别用米色」这类否定式指令只会换一种固定风格,更有效的做法是直接给出具体配色和字体规范,或者让模型先提出 4 个方向、由用户挑选后再实现。
• 交互式编码产品:在第一轮就把任务、意图和约束讲清楚,减少多轮追加指令,能同时提升效果和 token 效率。

通用技巧与迁移

原文另有独立章节讲适用于所有当前模型的通用原则(明确指令、给出上下文和示例、XML 标签结构化、控制输出格式、工具调用与并行工具调用、thinking/extended thinking 的使用、agentic 系统设计),以及从旧版模型迁移到当前模型时的参数和行为差异清单。这两部分内容量较大,建议直接查阅原文对应小节获取完整细节。