1.1 回顾：模型的工作方式#

在上一篇文章中我们讲过，大模型的核心工作就是一件事：根据输入预测下一个 Token。你给它的输入文本，就是它预测的全部依据。

这意味着什么？你输入的内容越精确、越丰富，模型能 看到 的上下文就越好，预测出的结果也越贴合你的需要。

1.2 提示词就是 面试题目#

你可以把每次和 AI 的对话想象成一场面试。模型是候选人，提示词是你出的面试题。

如果你问：“说说你的优点。” 这道题太宽泛了，候选人只能给一个泛泛的回答。

如果你问：“请结合你上一份工作中的三个具体项目，说明你在团队协作和技术难题攻关方面的优势，每个项目用 STAR 方法描述。” 候选人能给出一个清晰、有料、可量化的回答。

题目出得好，答案自然好。提示词也一样。

1.3 提示词的四个作用#

一段好的提示词，本质上在帮模型做四件事：

• 设定上下文：告诉模型这是什么场景、背景信息是什么
• 定义角色：让模型以特定的身份和视角来回答
• 提供示例：通过例子展示你期望的输出格式和风格
• 引导推理：通过特定的指令让模型一步步思考，而非直接给答案

2.1 原则一：清晰具体#

最常见的提示词问题就是 太模糊。模型无法读心，你不说清楚，它只能猜。

差的提示词：

1
帮我写个邮件。

好的提示词：

1
请帮我写一封工作邮件。
2
收件人：我的直属领导张总。
3
目的：申请下周三（3 月 11 日）在家远程办公一天。
4
原因：家中有维修工人上门，需要有人在场。
5
语气：礼貌、正式，但不要过于生硬。
6
长度：150 字以内。

两者的区别一目了然。好的提示词像一张需求文档，包含五个关键要素：

实战建议：写完提示词后，把自己当成模型读一遍。如果你觉得信息不够，模型也一定觉得不够。

2.2 原则二：结构化#

人类阅读时喜欢有结构的内容，模型也一样。用分隔符、编号和 Markdown 格式组织你的提示词，模型更容易理解你的意图。

来看一个代码审查的结构化提示词：

1
## 角色
2
你是一位资深后端工程师，精通 Go 语言和微服务架构。
3

4
## 任务
5
请审查以下代码片段，从四个维度给出评价。
6

7
## 审查维度
8
1. **正确性**：逻辑是否正确，有无 Bug
9
2. **性能**：有无明显的性能瓶颈
10
3. **可读性**：命名、结构是否清晰
11
4. **安全性**：有无潜在的安全风险
12

13
## 输出格式
14
每个维度用以下格式：
15
- 评分：1～5 分
16
- 问题：具体描述
17
- 建议：改进方案（附代码）
18

19
## 代码

// 这里放你要审查的代码

这段提示词用 Markdown 标题分隔了不同部分，用编号列出了审查维度，用模板定义了输出格式。模型拿到这样的输入，能给出的回答远比 帮我看看这段代码 精确得多。

2.3 原则三：角色设定#

角色设定是提示工程中最被低估的技巧之一。

同样问 如何设计一个高并发系统，给模型设定不同的角色，回答会截然不同：

• 你是一位有 10 年经验的架构师：回答会使用专业术语，讨论分布式架构、限流策略、数据库分片，默认读者有技术背景
• 你是一位刚入职的实习生：回答会用大白话解释，会多用类比，避免术语堆砌

角色设定影响三个维度：

角色设定不只是 装装样子。模型在训练数据中见过大量不同身份人群写的文本，设定角色等于告诉模型 从这类文本的风格和深度出发。

3.1 Zero-shot：直接给任务#

Zero-shot（零样本）是最简单的用法：直接描述任务，不提供任何示例。

1
将以下英文翻译成中文，保持原文的语气和风格：
2

3
"The best way to predict the future is to invent it."

对于翻译、摘要、简单问答等模型 本来就会 的任务，Zero-shot 通常就够了。模型在训练阶段已经见过海量的翻译对照数据，不需要你额外示范。

适用场景：模型已经擅长的标准任务。

3.2 Few-shot：用示例教模型#

Few-shot（少样本）的核心思想是：给模型 2～5 个示例，让它从示例中学习输出的模式。

来看一个把产品参数转换成营销文案的例子：

1
请将产品参数转换为面向消费者的营销文案。
2

3
示例 1：
4
输入：蓝牙耳机，40mm 驱动单元，主动降噪，续航 30 小时
5
输出：戴上它，世界安静了。40mm 大驱动单元带来录音棚级音质，
6
ANC 主动降噪让你沉浸在自己的世界里。30 小时超长续航，
7
一周只需充一次电。
8

9
示例 2：
10
输入：机械键盘，Gasket 结构，PBT 键帽，三模连接，4000mAh
11
输出：每一次敲击都是享受。Gasket 弹性结构带来柔软又扎实的手感，
12
PBT 键帽越用越润。蓝牙、2.4G、有线三模随心切换，
13
4000mAh 电池让你忘记充电这回事。
14

15
现在请转换：
16
输入：便携按摩仪，TENS 脉冲技术，6 种模式，Type-C 充电，重量 120g
17
输出：

模型会从两个示例中学到：用第二人称、先讲体验再讲参数、语言要有画面感、每个特性对应一句话。然后它会用同样的风格生成新的文案。

Few-shot 的要点：

• 示例数量：2～5 个最佳，太少模式不明显，太多浪费 Token
• 示例质量比数量重要：一个高质量的示例胜过五个平庸的
• 示例要覆盖不同情况：如果任务有多种输入类型，每种都给一个示例

3.3 Many-shot：大量示例#

当任务非常复杂或对一致性要求极高时，可以提供 10 个甚至更多的示例。这叫 Many-shot（多样本）。

不过 Many-shot 存在边际效益递减。研究表明，示例从 0 到 3 个时效果提升最明显，从 3 到 10 个时提升变缓，超过 10 个之后提升非常有限。而且更多示例意味着消耗更多 Token，成本更高。

经验法则：先试 3 个示例，效果不够再加到 5 个，5 个还不行再考虑其他策略（如 CoT），而不是无限堆示例。

3.4 结构化输出#

让模型输出 JSON、XML 等结构化格式，是提示工程中非常实用的技巧。结构化输出可以直接被程序解析，省去了从自然语言中提取信息的麻烦。

示例提示词：

1
分析以下用户评论的情感，返回 JSON 格式。
2

3
评论："这个耳机音质不错，但佩戴时间长了耳朵会痛。"
4

5
请返回以下格式的 JSON：
6
{
7
 "overall_sentiment":"positive | negative | mixed",
8
 "aspects": [
9
 {
10
 "aspect":"具体方面 ",
11
 "sentiment":"positive | negative",
12
 "evidence":"原文依据 "
13
 }
14
 ]
15
}

模型输出：

1
{
2
 "overall_sentiment":"mixed",
3
 "aspects": [
4
 {
5
 "aspect":"音质 ",
6
 "sentiment":"positive",
7
 "evidence":"音质不错 "
8
 },
9
 {
10
 "aspect":"佩戴舒适度 ",
11
 "sentiment":"negative",
12
 "evidence":"佩戴时间长了耳朵会痛 "
13
 }
14
 ]
15
}

主流 API 都提供了强制结构化输出的能力。

OpenAI 的 response_format 参数：

1
from openai import OpenAI
2

3
client = OpenAI()
4
response = client.chat.completions.create(
5
 model="gpt-4o",
6
 messages=[{"role":"user","content":"分析情感..."}],
7
 response_format={
8
 "type":"json_schema",
9
 "json_schema": {
10
 "name":"sentiment_analysis",
11
 "schema": {
12
 "type":"object",
13
 "properties": {
14
 "overall_sentiment": {
15
 "type":"string",
16
 "enum": ["positive","negative","mixed"]
17
 },
18
 "aspects": {
19
 "type":"array",
20
 "items": {
21
 "type":"object",
22
 "properties": {
23
 "aspect": {"type":"string"},
24
 "sentiment": {"type":"string"},
25
 "evidence": {"type":"string"}
26
 }
27
 }
28
 }
29
 }
30
 }
31
 }
32
 }
33
)

Claude 的 Tool Use 强制格式：

1
import anthropic
2

3
client = anthropic.Anthropic()
4
response = client.messages.create(
5
 model="claude-sonnet-4-20250514",
6
 max_tokens=1024,
7
 tools=[{
8
 "name":"sentiment_analysis",
9
 "description":"分析文本情感 ",
10
 "input_schema": {
11
 "type":"object",
12
 "properties": {
13
 "overall_sentiment": {
14
 "type":"string",
15
 "enum": ["positive","negative","mixed"]
16
 },
17
 "aspects": {
18
 "type":"array",
19
 "items": {
20
 "type":"object",
21
 "properties": {
22
 "aspect": {"type":"string"},
23
 "sentiment": {"type":"string"},
24
 "evidence": {"type":"string"}
25
 },
26
 "required": ["aspect","sentiment","evidence"]
27
 }
28
 }
29
 },
30
 "required": ["overall_sentiment","aspects"]
31
 }
32
 }],
33
 tool_choice={"type":"tool","name":"sentiment_analysis"},
34
 messages=[{"role":"user","content":"分析情感..."}]
35
)

两种方式的思路相同：通过 Schema 约束模型的输出格式，确保返回的一定是合法的结构化数据。

4.1 Chain-of-Thought：让模型 一步步想#

Chain-of-Thought（CoT，思维链）是 2022 年 Google 提出的技巧，核心思想极其简单：让模型在给出最终答案之前，先写出推理过程。

为什么有效？回忆一下模型的工作原理：它是逐 Token 生成的。如果你让它直接给答案，它只有一次 “猜” 的机会。如果你让它先写推理步骤，每一步的输出都会成为下一步的输入，模型等于在 草稿纸上演算。

来看一个经典的数学题对比。

不用 CoT：

1
问：一个商店有 23 个苹果。上午卖了 8 个，下午进货 15 个，
2
又卖了 12 个。现在有多少个苹果？
3

4
答：18 个。

模型直接给答案，容易算错。

使用 CoT：

1
问：一个商店有 23 个苹果。上午卖了 8 个，下午进货 15 个，
2
又卖了 12 个。现在有多少个苹果？请一步步推理。
3

4
答：让我一步步计算。
5
1. 初始库存：23 个
6
2. 上午卖了 8 个：23 - 8 = 15 个
7
3. 下午进货 15 个：15 + 15 = 30 个
8
4. 又卖了 12 个：30 - 12 = 18 个
9
所以现在有 18 个苹果。

这个例子比较简单，结果一样。但当问题变复杂，比如五六步运算或逻辑推理，CoT 的正确率提升非常显著。Google 的论文显示，在 GSM8K（小学数学题集）上，CoT 将 PaLM 540B 的准确率从 17.9% 提升到了 58.1%。

Zero-shot CoT：你甚至不需要手动写推理步骤的示例。只需在提示词末尾加一句 让我们一步步思考（Let’s think step by step），模型就会自动展开推理链。这是目前最简单也最实用的 CoT 用法。

1
问：如果一条船上有 26 只羊和 10 只山羊，船长多大年纪？
2
请一步步思考。
3

4
答：让我分析一下这道题。
5
1. 题目给出的信息：26 只羊和 10 只山羊。
6
2. 题目问的是：船长的年纪。
7
3. 羊的数量和船长的年纪之间没有任何逻辑关系。
8
4. 这是一道经典的 "陷阱题"，信息和问题无关。
9
结论：无法根据给出的信息确定船长的年纪。

没有 CoT 时，模型可能直接回答 “36 岁”（把 26 + 10 凑了一个答案）。有了 CoT，模型在逐步推理时发现了信息和问题之间没有关联。

4.2 Tree of Thoughts：多路径探索#

Tree of Thoughts（ToT，思维树）是 CoT 的升级版。CoT 是一条直线式的推理链，ToT 则是同时探索多条推理路径，评估每条路径的可行性，最终选择最优解。

想象你在迷宫里找出路。CoT 是沿着一条路一直走到底。ToT 是在每个岔路口都探探路，走不通就退回来换一条。

1
你是一位资深系统架构师。
2
需要为一个日均 1000 万请求的电商平台设计缓存方案。
3

4
请用思维树方法分析：
5
1. 列出 3 种可行的缓存方案
6
2. 对每种方案评估优劣（命中率、一致性、运维成本）
7
3. 选择最优方案并说明理由

ToT 适合有多种可能解法的开放性问题，比如架构设计、策略规划、创意方案等。对于有唯一正确答案的问题（如数学计算），CoT 通常就够了。

4.3 Self-Consistency：投票选答案#

Self-Consistency（自洽性采样）的思路非常直觉：同一道题让模型回答多次，选出现最多的答案。

这就像你对一道数学题没把握，算了五遍。如果三遍答 18、一遍答 16、一遍答 20，你大概率会选 18，因为它出现的次数最多，大概率是对的。

1
import collections
2

3
def self_consistency(prompt, model, n=5, temperature=0.7):
4
 answers = []
5
 for _ in range(n):
6
 response = model.generate(prompt, temperature=temperature)
7
 answer = extract_final_answer(response)
8
 answers.append(answer)
9

10
 counter = collections.Counter(answers)
11
 best_answer = counter.most_common(1)[0][0]
12
 confidence = counter.most_common(1)[0][1] / n
13
 return best_answer, confidence

关键参数是 Temperature。Temperature 设为 0 时每次回答一模一样，采样没有意义。设为 0.7～1.0 之间，模型每次走不同的推理路径，更容易在多条路径上 收敛 到正确答案。

研究表明，Self-Consistency 可以将推理任务的准确率提升 10%～30%。代价是多次调用带来的额外成本和延迟。

4.4 ReAct：推理与行动结合#

ReAct（Reasoning + Acting）让模型不只是 “想”，还能 “做”。它的工作模式是一个循环：Thought（思考）→ Action（行动）→ Observation（观察）→ Thought → …

来看一个实际的例子。用户问：“2026 年 3 月份人民币对美元汇率是多少？”

1
Thought: 用户在问实时汇率信息，这是我训练数据截止后的数据，
2
 我需要搜索最新信息。
3
Action: search("2026 年 3 月 人民币 美元 汇率")
4
Observation: 搜索结果显示，2026 年 3 月 2 日，
5
 人民币对美元中间价为 7.1234。
6
Thought: 我找到了所需的信息，可以回答用户了。
7
Answer: 截至 2026 年 3 月 2 日，人民币对美元中间价约为 7.12。
8
 请注意汇率实时波动，建议以银行实际报价为准。

ReAct 是构建 AI Agent（智能体）的基础范式。Agent 能调用搜索引擎、执行代码、查询数据库，本质上都是 ReAct 循环的具体实现。后续的 Agent 篇会详细展开。

5.1 System Prompt 是什么#

在 API 调用中，消息分为三种角色：system（系统）、user（用户）、assistant（助手）。其中 System Prompt 是一段 全局指令，它在整个对话过程中持续生效，定义了模型的角色、行为规范和输出格式。

你可以把 System Prompt 理解为公司的 员工手册。User Prompt 是每次具体的工作任务，System Prompt 是贯穿始终的行为准则。

5.2 System Prompt 的三个核心职责#

5.3 好的 System Prompt 模板#

1
## 身份
2
你是 [角色名称]，在 [领域] 有 [N] 年经验。
3

4
## 核心能力
5
- 能力 1
6
- 能力 2
7
- 能力 3
8

9
## 行为准则
10
- 回答之前先确认你理解了用户的需求
11
- 不确定时主动说明，不要编造
12
- 涉及代码时提供可运行的完整示例
13

14
## 输出规范
15
- 使用 Markdown 格式
16
- 代码块标注语言类型
17
- 关键结论用粗体标注
18

19
## 限制
20
- 不回答与 [领域] 无关的问题
21
- 不提供医疗、法律方面的专业建议

5.4 System Prompt 与 User Prompt 的分工#

一个常见的误区是把所有信息都塞进 User Prompt。更好的做法是让两者各司其职：

System Prompt 写好后通常不变，User Prompt 每次对话都不同。这种分工让提示词更容易维护和复用。

6.1 重复请求的成本问题#

在实际应用中，很多 API 调用共享相同的前缀。比如你有一个客服机器人，每次调用都带着同样的 System Prompt（2,000 Token）和产品文档（10,000 Token），只有用户的提问不同。每次调用都要付这 12,000 个 Token 的输入费用，非常浪费。

6.2 Prompt Caching 机制#

Claude 和 GPT 都提供了 Prompt Caching（提示词缓存）功能。核心原理：模型会缓存之前处理过的提示词前缀，当后续请求的前缀与缓存匹配时，跳过重复的计算，直接复用中间结果。

Claude 的缓存用法：

1
response = client.messages.create(
2
 model="claude-sonnet-4-20250514",
3
 max_tokens=1024,
4
 system=[
5
 {
6
 "type":"text",
7
 "text":"你是一位专业的客服助手...(很长的系统提示)...",
8
 "cache_control": {"type":"ephemeral"}
9
 },
10
 {
11
 "type":"text",
12
 "text":"(很长的产品文档内容)...",
13
 "cache_control": {"type":"ephemeral"}
14
 }
15
 ],
16
 messages=[{"role":"user","content":"这款产品支持退货吗？"}]
17
)

OpenAI 的自动缓存：

GPT-4o 等模型支持自动缓存，只要请求的前缀与之前的请求匹配（至少 1,024 Token），系统自动复用缓存，无需手动标记。

6.3 成本节省#

缓存在以下场景特别有价值：

• 客服机器人：System Prompt 和知识库文档固定
• 文档问答：同一份文档被反复提问
• 代码助手：代码仓库上下文在多次交互中保持不变
• 批量处理：大量请求共享相同的指令和示例

7.1 JSON Mode#

OpenAI 提供了 response_format: { type: "json_object" } 参数，强制模型输出合法的 JSON。开启后，模型的输出一定是可解析的 JSON，但不保证符合你期望的结构。

进阶版：JSON Schema 约束。 前面代码示例中用到的 json_schema 类型，不仅保证输出是合法 JSON，还保证它符合你定义的 Schema：字段名、字段类型、枚举值都受约束。

7.2 Tool Use 强制格式#

Claude 的 Tool Use（工具使用）机制提供了另一种保障方式。你把期望的输出结构定义为一个 工具 的输入参数，然后强制模型 调用 这个工具。模型返回的工具参数天然就是符合 Schema 的结构化数据。

这种方式的好处是与模型的推理过程解耦：模型可以自由思考，但最终输出必须通过工具调用的结构化接口返回。

7.3 选择建议#

生产环境建议：优先使用 JSON Schema 或 Tool Use。仅在原型验证阶段使用纯提示词方式。

8.1 通用模板#

经过前面的学习，可以总结一个万能的提示词模板：

1
## 角色设定
2
你是 [身份]，擅长 [能力]。
3

4
## 任务描述
5
请完成 [具体任务]。
6

7
## 输入数据
8
[需要处理的数据或上下文]
9

10
## 输出格式
11
请按以下格式输出：
12
[格式示例]
13

14
## 约束条件
15
- 约束 1
16
- 约束 2
17
- 约束 3
18

19
## 示例（可选）
20
输入：xxx
21
输出：xxx

不需要每次都用全五个模块。简单任务可能只需要 任务描述 + 输出格式，复杂任务则建议五个模块都写。

8.2 常见问题与解决#

8.3 迭代优化的流程#

写提示词不是一次性的事。好的提示词通常经过多次迭代：

• 写初版：根据需求快速写出第一版提示词
• 测试：用 5～10 个不同的输入测试效果
• 找模式：失败的案例有没有共同特征？
• 调整：针对性地加约束、改角色、加示例
• 回归测试：确保修改后之前正常的案例没有变差

8.1 提示词效果对比#

1
┌─────────────────────────────────────────────────────────┐
2
│ 提示词质量 vs 输出质量 │
3
├─────────────────────────────────────────────────────────┤
4
│ │
5
│ 模糊的提示词 │
6
│ "帮我写个文案" │
7
│ → 通用、空洞、无法直接使用 │
8
│ 质量：██░░░░░░░░ 20% │
9
│ │
10
│ 有角色的提示词 │
11
│ "你是一位新媒体运营专家，帮我写个文案" │
12
│ → 更专业，但缺少细节约束 │
13
│ 质量：█████░░░░░ 50% │
14
│ │
15
│ 有角色+要求的提示词 │
16
│ "...目标人群 25-35 岁白领，轻松风格，300 字" │
17
│ → 方向正确，可用性提升 │
18
│ 质量：███████░░░ 70% │
19
│ │
20
│ 完整的结构化提示词 │
21
│ "角色+任务+人群+风格+结构+字数+示例" │
22
│ → 精准、可直接使用 │
23
│ 质量：█████████░ 90% │
24
│ │
25
└─────────────────────────────────────────────────────────┘

8.2 Chain-of-Thought 思维链流程#

{{< mermaid >}} flowchart TD A[“用户问题
商店有 23 个苹果
卖 8 个，进 15 个，卖 12 个
现在有多少？”] —> B{“使用 CoT？”}

B —>|否：直接回答| C[“模型一步到位
预测最终答案”] C —> D[“答案：18 个
（简单题碰巧对了）”]

B —>|是：一步步思考| E[“Step 1
初始：23 个”] E —> F[“Step 2
卖 8 个：23 - 8 = 15”] F —> G[“Step 3
进 15 个：15 + 15 = 30”] G —> H[“Step 4
卖 12 个：30 - 12 = 18”] H —> I[“答案：18 个
（推理过程可验证）”]

style A fill:#e1f5fe style D fill:#fff3e0 style I fill:#e8f5e9 {{< /mermaid >}}

{{< mermaid >}} flowchart LR subgraph ReAct[“ReAct 循环”] direction TB T1[“Thought
思考：我需要什么信息？”] —> A1[“Action
行动：调用搜索/工具”] A1 —> O1[“Observation
观察：得到了什么结果？”] O1 —> T2[“Thought
思考：信息够了吗？”] T2 —>|不够| A2[“Action
继续查找”] T2 —>|够了| ANS[生成最终回答] A2 —> O2[“Observation
新的结果”] O2 —> T2 end

style T1 fill:#e1f5fe style A1 fill:#fff3e0 style O1 fill:#e8f5e9 style ANS fill:#f3e5f5 {{< /mermaid >}}

8.1 Q1： 提示词越长越好吗？#

不是。精准比冗长更重要。

一段 50 字的提示词如果包含了明确的任务、格式和约束，效果可能远好于一段 500 字但逻辑混乱的提示词。长提示词的风险在于：信息过多时模型可能遗漏关键指令（尤其在上下文中间的信息容易被忽视）；Token 越多成本越高、延迟越大。

经验法则：先写最短的有效版本，测试不达标再逐步补充，而不是一开始就堆砌信息。

8.2 Q2： 需要每次都写角色设定吗？#

不需要。如果你在调用 API，角色设定通常放在 System Prompt 中，只需设置一次。如果你在 ChatGPT、Claude 等对话界面中使用，简单的日常问答不需要角色设定。

什么时候需要角色设定？ 当你对输出的专业度、风格、视角有特定要求时。比如你想要一份医学科普文章的风格而不是学术论文的风格，角色设定就很有用。

8.3 Q3： CoT 对所有任务都有效吗？#

不是。CoT 对需要多步推理的任务效果最好，比如数学计算、逻辑推理、代码调试、复杂决策。

对于简单任务（翻译、摘要、情感分析），CoT 反而可能降低效率：模型花时间写了一大段 思考过程，但最终答案和直接回答没有区别。更糟糕的是，对于非常简单的问题，强制 CoT 有时反而会让模型 想多了 而出错。

判断标准：如果一个人类不需要草稿纸就能回答的问题，通常不需要 CoT。

8.4 Q4： 提示词工程会被淘汰吗？#

短期内不会，但形态会演变。

随着模型越来越聪明，基础 的提示词技巧（比如 请一步步思考）可能会被模型内化，你不说它也会这样做。但高质量的任务描述、精确的约束条件、好的示例设计永远有价值，因为这本质上是 清晰表达需求 的能力。

类比：编程语言从汇编进化到 Python，编程变简单了，但 把需求转化为清晰指令 的能力依然重要。提示词工程的未来也类似：门槛会降低，但专业能力的天花板会一直存在。

8.5 Q5： 如何系统地测试和优化提示词？#

推荐一套简单的流程：

• 构建测试集：收集 20～50 个代表性的输入样本，覆盖正常情况和边界情况
• 定义评估标准：输出的哪些方面是你关心的？准确率、格式一致性、语气、长度？
• 基线测试：用初版提示词跑一遍测试集，记录每个样本的评分
• 对比实验：每次只改一个变量（加角色、改措辞、加示例），观察评分变化
• 回归验证：每次优化后，确保之前表现好的样本没有变差

如果你在生产环境中使用，可以考虑 Promptfoo、LangSmith 等专业的提示词评估工具来自动化这个过程。