Claude Prompt 套路汇总:10 个可直接复制的工程化模板
写好 Claude 的 prompt 不靠灵感,靠套路 + 排列组合。同一个任务,新手写得啰嗦低效,老手用一个 XML 结构 + 一个 prefill 就把输出稳得死死的。
这些套路不是凭感觉攒出来的,是 Anthropic 官方 prompting 文档与无数生产事故里沉淀出的工程规则。本文整理 10 个最高频、最值钱的 prompt 模板,每个都给完整可复制的示例,配上在 Claude API(claudeapi.com 国内接入点)上的实际调用代码。
一、用 XML 标签把上下文和指令分开
Claude 对 XML 标签的识别度远高于"```“代码块和单纯换行。混在一段长 prompt 里的"参考资料 + 任务 + 输出要求”,用 XML 切分后准确率明显提升。
反面:
你帮我看一下下面这段代码,它做了什么,
然后告诉我有没有性能问题,
还有就是上面那个函数我之前问过你怎么改,
你说改成 async 就行……
你帮我看一下下面这段代码,它做了什么,
然后告诉我有没有性能问题,
还有就是上面那个函数我之前问过你怎么改,
你说改成 async 就行……
正面:
<context>
我们在做一个高并发抓取服务,每秒约 500 请求。
</context>
<code>
def fetch_all(urls):
results = []
for url in urls:
results.append(requests.get(url).text)
return results
</code>
<task>
1. 用一句话说明这段代码做什么
2. 指出最严重的性能问题
3. 给出符合 context 中并发量的改写方案
</task>
<output_format>
按 task 的 1/2/3 编号回答,每点不超过 5 行。
</output_format>
<context>
我们在做一个高并发抓取服务,每秒约 500 请求。
</context>
<code>
def fetch_all(urls):
results = []
for url in urls:
results.append(requests.get(url).text)
return results
</code>
<task>
1. 用一句话说明这段代码做什么
2. 指出最严重的性能问题
3. 给出符合 context 中并发量的改写方案
</task>
<output_format>
按 task 的 1/2/3 编号回答,每点不超过 5 行。
</output_format>
调用代码:
import anthropic
client = anthropic.Anthropic(
api_key="sk-你的ClaudeAPI密钥",
base_url="https://gw.claudeapi.com"
)
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
messages=[{"role": "user", "content": prompt_with_xml}]
)
import anthropic
client = anthropic.Anthropic(
api_key="sk-你的ClaudeAPI密钥",
base_url="https://gw.claudeapi.com"
)
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
messages=[{"role": "user", "content": prompt_with_xml}]
)
经验:XML 标签名用语义化英文(<context>、<task>、<rules>、<examples>),不要用 <a>、<b>。
二、Few-shot:给 3 个例子,效果好过写 300 字规则
让 Claude 学一个有具体格式的小任务(实体抽取、文本分类、JSON 转换),例子的力度远大于描述。
<task>
从用户输入的一段产品评论中,抽取以下字段,返回 JSON:
- sentiment: positive / negative / neutral
- mentioned_features: 数组
- has_complaint: bool
</task>
<examples>
<example>
<input>电池续航不错,但是充电太慢了,要 3 小时</input>
<output>{"sentiment": "neutral", "mentioned_features": ["电池续航", "充电速度"], "has_complaint": true}</output>
</example>
<example>
<input>屏幕显示效果非常好,色彩鲜艳</input>
<output>{"sentiment": "positive", "mentioned_features": ["屏幕"], "has_complaint": false}</output>
</example>
<example>
<input>客服根本不回我消息,差评</input>
<output>{"sentiment": "negative", "mentioned_features": ["客服"], "has_complaint": true}</output>
</example>
</examples>
<user_input>
拍照效果惊艳,但开机慢了点,整体满意
</user_input>
<task>
从用户输入的一段产品评论中,抽取以下字段,返回 JSON:
- sentiment: positive / negative / neutral
- mentioned_features: 数组
- has_complaint: bool
</task>
<examples>
<example>
<input>电池续航不错,但是充电太慢了,要 3 小时</input>
<output>{"sentiment": "neutral", "mentioned_features": ["电池续航", "充电速度"], "has_complaint": true}</output>
</example>
<example>
<input>屏幕显示效果非常好,色彩鲜艳</input>
<output>{"sentiment": "positive", "mentioned_features": ["屏幕"], "has_complaint": false}</output>
</example>
<example>
<input>客服根本不回我消息,差评</input>
<output>{"sentiment": "negative", "mentioned_features": ["客服"], "has_complaint": true}</output>
</example>
</examples>
<user_input>
拍照效果惊艳,但开机慢了点,整体满意
</user_input>
经验:3 个例子是甜点。1 个例子学不到模式,10 个例子浪费 token 还分散注意力。例子要覆盖典型场景的边界——正向、负向、含混。
三、思路链(CoT):让模型先想后答
复杂推理(数学、逻辑、多步分析)直接问答案,错误率明显升高。让 Claude 先列推理步骤再下结论:
初级版:在 prompt 末尾加一句"让我们一步一步思考"。
工程版:用 XML 锁定推理结构。
<question>
一辆车从 A 到 B 走了 4 小时,平均速度 60 km/h。返程走相同路线,因下雨平均速度降为 40 km/h。求往返平均速度。
</question>
<instructions>
请按以下步骤回答:
<thinking>
- 第 1 步:列出已知条件
- 第 2 步:计算单程距离
- 第 3 步:计算返程时间
- 第 4 步:用总距离 / 总时间求平均速度
</thinking>
<answer>
最终答案,单位 km/h,保留 1 位小数
</answer>
</instructions>
<question>
一辆车从 A 到 B 走了 4 小时,平均速度 60 km/h。返程走相同路线,因下雨平均速度降为 40 km/h。求往返平均速度。
</question>
<instructions>
请按以下步骤回答:
<thinking>
- 第 1 步:列出已知条件
- 第 2 步:计算单程距离
- 第 3 步:计算返程时间
- 第 4 步:用总距离 / 总时间求平均速度
</thinking>
<answer>
最终答案,单位 km/h,保留 1 位小数
</answer>
</instructions>
进阶:直接用 Claude 4.7 的 Extended Thinking 模式,让模型在专门的 thinking token 里推理,最终输出更干净:
response = client.messages.create(
model="claude-opus-4-7",
max_tokens=16000,
thinking={"type": "enabled", "budget_tokens": 8000},
messages=[{"role": "user", "content": question}]
)
response = client.messages.create(
model="claude-opus-4-7",
max_tokens=16000,
thinking={"type": "enabled", "budget_tokens": 8000},
messages=[{"role": "user", "content": question}]
)
四、Prefill:用 assistant 开头一句锁住输出格式
Anthropic API 允许在 messages 里塞一条 role: assistant 作为模型的"开头",模型会从这里续写。这个能力被严重低估。
场景 1:强制 JSON 输出
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
messages=[
{"role": "user", "content": "用 JSON 输出 3 个有趣的 Python 库,每个含 name 和 desc"},
{"role": "assistant", "content": "{\n \"libraries\": ["} # 让模型从这里续写
]
)
print("{\n \"libraries\": [" + response.content[0].text)
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
messages=[
{"role": "user", "content": "用 JSON 输出 3 个有趣的 Python 库,每个含 name 和 desc"},
{"role": "assistant", "content": "{\n \"libraries\": ["} # 让模型从这里续写
]
)
print("{\n \"libraries\": [" + response.content[0].text)
这样模型一定从 { "libraries": [ 后开始续,不会有"好的,这是您要的 JSON:"这种废话开头。
场景 2:强制角色一致性
{"role": "assistant", "content": "<法律顾问回答>\n"}
{"role": "assistant", "content": "<法律顾问回答>\n"}
模型会顺着标签里的语气写。
场景 3:避开拒答
模型有时会回"我不能帮你做……"。如果你的请求合理但触发了过度防御,prefill 一句"好的,我可以帮你分析"通常能突破。注意:只对合规请求使用。
五、System Prompt:把角色、约束、风格放上面
system 字段是模型最优先吸收的指令。重要的全局约束放 system,一次性任务放 user。
SYSTEM = """你是一位资深 Python 后端工程师,专攻 FastAPI 与高并发优化。
回答规则:
1. 只给可直接运行的代码,不给伪代码
2. 不要写多行 docstring 和废话注释
3. 涉及版本时只考虑 FastAPI 0.115+ 和 Python 3.12+
4. 如果用户的需求有明显错误,直接指出并给正确做法,不要顺着写
5. 不确定的事情明确说"我不确定",不要编造
"""
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=2048,
system=SYSTEM,
messages=[{"role": "user", "content": user_query}]
)
SYSTEM = """你是一位资深 Python 后端工程师,专攻 FastAPI 与高并发优化。
回答规则:
1. 只给可直接运行的代码,不给伪代码
2. 不要写多行 docstring 和废话注释
3. 涉及版本时只考虑 FastAPI 0.115+ 和 Python 3.12+
4. 如果用户的需求有明显错误,直接指出并给正确做法,不要顺着写
5. 不确定的事情明确说"我不确定",不要编造
"""
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=2048,
system=SYSTEM,
messages=[{"role": "user", "content": user_query}]
)
经验:system 不要超 5000 字。超过这个长度通常意味着你在 system 里塞了应该放 user 的具体任务。
六、输出长度控制
Claude 倾向写得啰嗦。三种约束方法,按效果排序:
A. 明确字数 / 行数:
用不超过 100 字回答。
用不超过 100 字回答。
B. 给出结构:
按以下结构回答,每项 1 句话:
- 结论:
- 主要原因:
- 推荐做法:
按以下结构回答,每项 1 句话:
- 结论:
- 主要原因:
- 推荐做法:
C. Prefill + max_tokens 双卡:
messages=[
{"role": "user", "content": "用一句话总结上面文章"},
{"role": "assistant", "content": "一句话总结:"}
],
max_tokens=80
messages=[
{"role": "user", "content": "用一句话总结上面文章"},
{"role": "assistant", "content": "一句话总结:"}
],
max_tokens=80
七、角色扮演:用具体身份替代抽象指令
"请用通俗易懂的话解释"是抽象指令;"假设你在给一位完全没接触过编程的高中生讲课"是具体角色。后者效果好得多。
| 抽象指令 | 角色化 prompt |
|---|---|
| “用通俗易懂的话解释” | “假设你在给一位完全没接触过编程的高中生讲课” |
| “回答专业一些” | “你是一位有 15 年经验的资深税务顾问,对方是国内中型企业的 CFO” |
| “要严谨” | “你是一位审稿人,给一篇拟投顶会的论文做 review” |
| “回答简短” | “你在 Twitter 上回复,单条不超过 280 字符” |
角色定义放 system 字段最稳定。
八、把模型当工人:明确"拒绝执行"的边界
如果你的任务对正确性敏感(金融计算、法律判断、医疗建议),加上明确的"拒绝条件":
回答以下问题时,如果出现以下任何情况,请直接说"我无法准确回答这个问题"并停止:
- 缺少计算所需的具体数据
- 涉及具体法律条款而你不确定最新版本
- 涉及具体医疗诊断
- 答案依赖你无法验证的事实
回答以下问题时,如果出现以下任何情况,请直接说"我无法准确回答这个问题"并停止:
- 缺少计算所需的具体数据
- 涉及具体法律条款而你不确定最新版本
- 涉及具体医疗诊断
- 答案依赖你无法验证的事实
这是降低模型"硬编"的最有效手段。Anthropic 训练时强化了"承认不知道"的能力,但只在 prompt 明确鼓励时才会触发。
九、长文档处理:把文档放前面,问题放后面
Anthropic 官方测试结论:长上下文场景下,把文档放消息开头、把问题放消息末尾,准确率比反过来高 30%。
prompt = f"""<document>
{long_document}
</document>
请基于上面的文档回答:{question}
如果文档中没有相关信息,明确说"文档中未提到",不要猜测。
"""
response = client.messages.create(
model="claude-opus-4-7",
max_tokens=2048,
messages=[{"role": "user", "content": prompt}]
)
prompt = f"""<document>
{long_document}
</document>
请基于上面的文档回答:{question}
如果文档中没有相关信息,明确说"文档中未提到",不要猜测。
"""
response = client.messages.create(
model="claude-opus-4-7",
max_tokens=2048,
messages=[{"role": "user", "content": prompt}]
)
如果文档非常长(万字以上)+ 多次问问题,用 prompt caching:
messages=[
{"role": "user", "content": [
{"type": "text", "text": f"<document>\n{long_document}\n</document>",
"cache_control": {"type": "ephemeral"}},
{"type": "text", "text": f"问题:{question}"}
]}
]
messages=[
{"role": "user", "content": [
{"type": "text", "text": f"<document>\n{long_document}\n</document>",
"cache_control": {"type": "ephemeral"}},
{"type": "text", "text": f"问题:{question}"}
]}
]
十、Multishot 风格控制:让模型学你团队的语气
写 PR description、commit message、文档时,每个团队风格不一样。最有效的对齐方式是给历史样本:
<task>
根据下面的 git diff 写一条符合团队风格的 PR description。
</task>
<style_examples>
<example>
## What
Add retry logic to the payment webhook handler.
## Why
~3% of webhook calls were failing silently due to upstream timeouts.
## How
Exponential backoff, max 5 retries, with DLQ for permanent failures.
## Test
- Unit: tests/payments/test_webhook_retry.py
- Manual: triggered 50 mock failures locally
</example>
<example>
## What
Switch user search from LIKE to Postgres tsvector.
## Why
P99 latency on /api/users/search was 1.8s; reduces to <100ms.
## How
Added GIN index on `users.search_vector`; migration in 0042.
## Test
- Unit: existing search tests
- Benchmark: scripts/bench/users_search.py before/after
</example>
</style_examples>
<diff>
{git_diff_content}
</diff>
<task>
根据下面的 git diff 写一条符合团队风格的 PR description。
</task>
<style_examples>
<example>
## What
Add retry logic to the payment webhook handler.
## Why
~3% of webhook calls were failing silently due to upstream timeouts.
## How
Exponential backoff, max 5 retries, with DLQ for permanent failures.
## Test
- Unit: tests/payments/test_webhook_retry.py
- Manual: triggered 50 mock failures locally
</example>
<example>
## What
Switch user search from LIKE to Postgres tsvector.
## Why
P99 latency on /api/users/search was 1.8s; reduces to <100ms.
## How
Added GIN index on `users.search_vector`; migration in 0042.
## Test
- Unit: existing search tests
- Benchmark: scripts/bench/users_search.py before/after
</example>
</style_examples>
<diff>
{git_diff_content}
</diff>
输出会自动对齐到 What / Why / How / Test 四段结构。
通用模板:把上面的套路组合起来
实际生产中,一个稳定的 prompt 通常是 3-5 个套路的组合:
SYSTEM = """你是<角色>,<约束>。
回答规则:
1. <规则 1>
2. <规则 2>
3. <规则 3>
"""
USER_PROMPT = f"""
<context>
{背景信息}
</context>
<examples>
<example>
<input>...</input>
<output>...</output>
</example>
</examples>
<task>
{具体任务}
</task>
<output_format>
{格式要求}
</output_format>
"""
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=2048,
system=SYSTEM,
messages=[
{"role": "user", "content": USER_PROMPT},
{"role": "assistant", "content": "<开头 prefill 锁住格式>"}
]
)
SYSTEM = """你是<角色>,<约束>。
回答规则:
1. <规则 1>
2. <规则 2>
3. <规则 3>
"""
USER_PROMPT = f"""
<context>
{背景信息}
</context>
<examples>
<example>
<input>...</input>
<output>...</output>
</example>
</examples>
<task>
{具体任务}
</task>
<output_format>
{格式要求}
</output_format>
"""
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=2048,
system=SYSTEM,
messages=[
{"role": "user", "content": USER_PROMPT},
{"role": "assistant", "content": "<开头 prefill 锁住格式>"}
]
)
这个骨架可以套到 80% 的任务上,剩下 20% 按场景增加 CoT、Caching、Tool Use 等扩展。
在 ClaudeAPI.com 上的实际调用
上面所有代码都可以直接对接 claudeapi.com 接入点,把 base_url 改成 https://gw.claudeapi.com 即可。OpenAI 兼容路径走 https://gw.claudeapi.com/v1。
模型选择建议:
| 套路 | 推荐模型 | 备注 |
|---|---|---|
| Few-shot / 简单分类 | claude-haiku-4-5-20251001 |
价格最低、速度最快 |
| 大部分日常任务 | claude-sonnet-4-6 |
综合最优 |
| CoT / 复杂推理 / Extended Thinking | claude-opus-4-7 |
推理质量最高 |
控制台 console.claudeapi.com 提供按调用维度的用量明细,方便排查"为什么这个 prompt 又长又贵"。
小结
Prompt engineering 不是玄学。10 条套路记下来,配合 XML 结构 + Few-shot + Prefill 这三件套,能解决 80% 的对话质量问题。
最值得记住的三句话:
- 结构胜过描述:XML 标签比段落分隔有效得多
- 例子胜过规则:3 个 example 抵 300 字解释
- Prefill 胜过事后修剪:让模型从指定位置开始写,省去后处理
如需稳定调用 Claude 完整能力(含 Extended Thinking、Prompt Caching、Tool Use),访问 claudeapi.com 注册账号,账单清晰、用量透明,企业结算支持。



