很多团队接入 Claude 后的第一印象是："同样的提示词，有时效果惊艳，有时却漂移得离谱。"这种不稳定感往往被归结为"模型的随机性"，但 Anthropic 官方的 Prompting Best Practices 文档给出了完全不同的视角——大多数稳定性问题的根因，在于没有把"和 Claude 说话"当作一项工程化任务来做。本文基于官方文档解析核心方法论。
黄金法则：把 Claude 当作"缺上下文的新同事"
判断标准：把你的提示词拿给一位对任务缺乏背景的
同事看，如果他看完感到困惑，那么Claude也会困惑
这条黄金法则的含义是，模型并不是在"猜"用户的意图，而是在"拼接"给出的线索。线索不足，就只能退回到某种通用默认；线索充分，输出质量才会稳定。
模糊版：Create an analytics dashboard
清晰版：Create an analytics dashboard. Include
as many relevant features and interactions as
possible. Go beyond the basics to create a
fully-featured implementation.
第二条提示词并没有多出什么"魔法词"，它只是把"什么叫完成"定义得更具体——这就是把"隐性标准"变成"显性标准"。
为"为什么"提供理由，不只是"做什么"
效果较差：NEVER use ellipses
效果更好：Your response will be read aloud by a
text-to-speech engine, so never use ellipses since
the text-to-speech engine will not know how to
pronounce them.
第二个版本多出来的不是"语气"，而是因果链。模型理解了"为什么不能用省略号"之后，能够把这条规则推广到其他类似场景（避免连续破折号、异常 Unicode 符号等）。说清楚"因为"能显著提升规则的泛化能力。
Few-shot 示例：3-5个，相关、多样、结构化
经验法则：
- 相关：贴近真实输入分布，而非挑选"好看但罕见"
的样本
- 多样：覆盖边缘情况，让模型理解规则的边界在哪里
- 结构化：用XML标签包裹，避免与指令语义混在一起
数量：3-5个示例通常效果最佳，更多示例会拉长上下文、
稀释指令，也会让模型过拟合到具体样本
用 XML 标签结构化提示
<documents>
<document index="1">
<source>annual_report_2023.pdf</source>
<document_content>{{ANNUAL_REPORT}}</document_content>
</document>
<document index="2">
<source>competitor_analysis_q2.xlsx</source>
<document_content>{{COMPETITOR_ANALYSIS}}</document_content>
</document>
</documents>
Analyze the annual report and competitor analysis.
Identify strategic advantages and recommend Q3
focus areas.XML 标签的作用不是"美化"，而是给模型一棵可以解析的文档树——让模型清楚知道哪一段是指令、哪一段是数据、哪一段是输出样例。标签名要一致且有语义，有自然层级时再嵌套，避免不必要的层级增加噪音。
长上下文排版：文档放顶部，问题放末尾
长文档放在提示词顶部，查询和指令放在末尾
这种排版相比"问题在前、文档在后"的写法，报告中
可以带来最多约30%的质量提升
模型是自回归生成的，越靠近生成位置的 token，对输出的影响权重越大。把指令放末尾，相当于在模型即将回答的位置"再提醒一次目标"。配套建议是要求模型先提取相关引用再回答，相当于一个隐式的 chain-of-thought，能显著降低幻觉：
请先用<relevant_quotes>标签列出你引用的原文片段，
再在<answer>标签中给出你的回答。
控制冗长度：正面示例优于负面指令
更有效：Provide concise, focused responses. Skip
non-essential context, and keep examples minimal.
效果较差：Do not be verbose, do not add
unnecessary fluff
正面示例告诉模型"要长成什么样"，负面指令只告诉模型"不要长成什么样"，前者约束更紧。
重要变化：预填充响应已被移除
从Claude 4.6以及Claude Mythos Preview开始，不再
支持在最后一个assistant回合做预填充响应（prefilled
response）
迁移路线：
场景 迁移方式
控制输出格式 改用Structured Outputs或工具调用
消除冗余序言 在system prompt里用直接指令控制
避免误拒绝 直接用清晰的user消息提示
继续之前的响应 把"请继续"放进user消息
这条变化对依赖预填充做格式锁定的系统影响最大，迁移时建议优先考虑 Structured Outputs——它从协议层保证了 JSON Schema 级别的结构稳定性，比传统的 prefill 更可靠。
effort 参数：用"思考档位"代替反复改提示词
Claude Opus 4.7引入effort参数，5个档位：
- max：极限努力，适合智能要求最高的任务，有过度
思考风险
- xhigh（4.7新增）：编码和代理类用例的最佳设置
- high：平衡token使用和智能，多数智能敏感场景的
最低推荐
- medium：成本敏感场景的默认
- low：适合短小任务和延迟敏感的高并发工作负载
需要注意的新陷阱：Opus 4.7 会比 4.6 更严格遵循 effort 档位，特别是在低端。这意味着在4.6 时代用 low 依然能跑得动的推理任务，到 4.7 可能直接"想都不想"。处理方式：把 effort 提到 high 或 xhigh，或在提示词里显式要求推理：
This task involves multi-step reasoning. Think
carefully through the problem before responding.
自适应思考：从预算式迁移到 adaptive
# 旧：固定budget的扩展思考
client.messages.create(
model="claude-sonnet-4-5-20250929",
max_tokens=64000,
thinking={"type": "enabled", "budget_tokens": 32000},
messages=[{"role": "user", "content": "..."}],
)
# 新：自适应思考+effort
client.messages.create(
model="claude-opus-4-7",
max_tokens=64000,
thinking={"type": "adaptive"},
output_config={"effort": "high"},
messages=[{"role": "user", "content": "..."}],
)开启 max 或 xhigh 时，建议把 max_tokens 预算设到 64k，避免长推理被截断在关键一步。
实战建议
1. 提示词效果不稳定时，先用"新同事"标准自查——
是否给出了足够具体的完成标准，而非依赖模型
猜测意图
2. 需要模型严格遵守某条规则时，附上"为什么"的
因果链，而非单纯罗列禁止事项
3. 复杂任务优先用3-5个相关、多样、结构化的
few-shot示例，而非堆砌更多示例
4. 处理长文档任务时，把文档放提示词顶部、问题
放末尾，可获得最多约30%的质量提升
5. 如果之前依赖预填充响应做格式控制，尽快迁移到
Structured Outputs，避免4.6+版本兼容性问题
6. 使用Opus 4.7时如果发现low档位下推理质量下降，
优先尝试提升到high/xhigh档位，而非反复改写
提示词
总结
Anthropic 官方文档把提示词工程从"玄学"还原成"工程学"——通用原则、输出格式、长上下文排版、effort 参数调优，每一条建议背后都有可解释的工程逻辑。掌握这套方法论，能显著减少"同样提示词效果时好时坏"的困惑，把提示词调优变成一项可复用、可迭代的系统性工作。
来源：Claude Prompting Best Practices — Anthropic 官方文档（中文解读参考：爱折腾的工程师博客）