Claude 提示词工程：八大核心模式与可复用模板

把 Claude 提示词写好，靠的不是什么魔法咒语，而是少数几种结构化模式——它们能稳定地提升结果。本指南梳理我们在真实项目里验证过、站得住脚的八种模式，每种都给一个可复用模板，并点明 Claude 特有的技巧。它们都不依赖任何秘密参数，只关乎你如何组织已经写下的文字。

1. 角色设定（Role prompting）

在任务之前，给 Claude 一个清晰定义的角色。角色隐含了受众、词汇和标准，能让语气更锐利，减少泛泛而谈。

模板：

你是一名资深安全工程师，第一次评审一个 pull request。
你的任务是找出真实漏洞，而不是夸奖代码。
评审下面的 diff。只汇报那些在生产环境里真正要紧的问题，
按严重程度排序。如果一个都没发现，明确说没有。

<diff>
{粘贴_DIFF}
</diff>

为何有效：「资深安全工程师」会拉起一整套背景预期；「只汇报真正要紧的问题」则禁止了那种常把评审稀释掉的客套话。

2. 少样本（Few-shot）

在要新答案之前，先给两三个输入/输出示例。这是锁定输出格式或语气最可靠的办法。

模板：

把客服工单分到唯一一个分类里。

工单："我的八月账单被扣了两次。"
分类：账单

工单："我点头像时 App 闪退。"
分类：bug

工单："怎么把同事邀请进工作区？"
分类：操作指引

工单："{新工单}"
分类：

为何有效： 示例比口头描述更能卡死标签集合和措辞。保持示例有代表性，并让标签集封闭。

3. 思维链（Chain-of-thought）

要求 Claude 在作答前一步步推理。凡是涉及算术、逻辑或满足多重约束的判断，思维链都能明显提升准确率。

模板：

解答下面的问题。首先，在 <thinking> 标签里一步步推理。
然后在单独一行给出最终答案，写成 "Answer: X"。

某订阅每月 12 美元。年付方案每年 120 美元，相比月付相当于
免两个月。如果某用户当前处于月付的第 3 个月，那么今年剩下的
9 个月改成年付，能省多少钱？

Claude 专属提示： Claude 很适合显式的思考步骤。把答案强制写到可预测的一行（Answer: X），在你调用 API 时解析会更稳。

4. ReAct（推理 + 行动）

对需要工具或外部查询的任务，把推理和行动交错进行。模型推理下一步要做什么、执行动作、观察结果，如此循环直到完成。

模板：

你可以调用工具来回答用户请求。按这个循环走：

Thought: <你下一步要搞清楚什么>
Action: <工具名与参数>
Observation: <工具返回的结果>
……（按需重复 Thought/Action/Observation）
Final Answer: <给用户的回答，要引用观察结果>

用户请求："按年经常性收入排名前十的客户里，上个月有多少人
提交过客服工单？"

为何有效： 让推理可见，模型就能在步骤之间自我修正，而不是一上来就押死在单一计划上。它也给你（开发者）留下了一条「答案是怎么来的」审计轨迹。

5. 自洽性（Self-consistency）

对高风险答案，把同一个问题问几次（改变措辞或采样温度），取多数票答案。用更多调用换来更高可靠性。

模板（这是编排逻辑，不是单条提示词）：

把下面这条提示词运行 N 次，每次记下最终答案：
{基础提示词}

然后返回出现次数最多的答案。若打平，返回候选答案及其计数。

为何有效： 独立采样偶尔会朝不同方向出错；而正确答案往往会反复出现。它最适合有可检验答案的任务（数学、分类），对开放式生成则是浪费。

6. 用 XML 标签做结构化输出

Claude 对 XML 标签结构的遵从度很高。用标签把段落、数据和指令分隔开，模型就没法把它们混为一团。

模板：

你会在 <document> 标签里收到一段文档，在 <question> 标签里
收到一个问题。

<document>
{文档}
</document>

<question>
{问题}
</question>

按如下格式返回：

<answer>
<一段基于文档的回答>
</answer>

<sources>
<支持该回答的文档原文短引文列表>
</sources>

如果文档里没有答案，就在 <answer> 里写「文档中未提及」，
并把 <sources> 留空。

为何有效： 标签划出了硬边界。那个「未提及」兜底很关键——没有它，模型往往会编造，而不肯承认空白。

7. 分层系统提示（Layered system prompts）

把系统提示词分层：稳定身份 → 策略约束 → 任务上下文。这样更好维护，也让你能只换任务层、不动其余部分。

模板：

# 第一层 —— 身份
你是 Acme Assistant，Acme 账单产品的客服 Agent。
你冷静、精确，绝不臆造功能。

# 第二层 —— 策略
- 绝不透露账号或 token 值。
- 超出账单范畴的问题，转去通用客服渠道。
- 只引用 <kb> 标签里的策略，不要自行转述定价。

# 第三层 —— 任务上下文
今天是 {日期}。
用户当前是 {套餐} 套餐。
<kb>
{知识库节选}
</kb>

为何有效： 出问题时，你清楚去哪一层改。它也让模型分得清主次——身份恒定、策略约束、任务上下文变化。

8. 自我批判与宪法式模式

让 Claude 在交答案前，按显式标准批判自己的草稿并修订。这是低成本发现单轮错误的好办法。

模板：

为下面的改动写一段发布说明。

写完草稿后，按这份清单批判你的草稿：
- 是否覆盖了所有用户可见的变更？
- 是否避免了非工程师看不懂的术语？
- 是否有夸大或臆测之处？

根据批判修订草稿，然后只返回最终版本。

<changes>
{更新日志}
</changes>

为何有效： 单独的批判步骤，会逼模型像审视别人作品一样审视输出，从而暴露起草阶段被略过的问题。清单要具体；「写得更好点」毫无用处。

组合使用

这些模式是可以叠加的。一条生产级提示词，往往同时叠了角色（1）、few-shot（2）、XML 结构（6）和一轮自我批判（8）。要避免的错误是——对一个琐碎任务一次性堆上全部八种，每种都增加延迟和 token 成本。涉及真正推理的，才上思维链；答案可检验且代价高时，才上自洽性；答错了恢复代价大时，才上自我批判。

支撑所有这些的统一习惯是：像给一个能干却字面化理解指令的新同事写说明那样写提示词。告诉对方是谁、给出好作品的示例、把输入和指令分开、要求对方在交回前先自查一遍。Claude 同样奖励这份清晰。

本文基于截至 2026 年 7 月的公开信息，相关 API 可能演进。