第二章:提示词模式

学习目标:掌握经典的提示词模式,理解不同模式的适用场景和实现方法
预计时间:90-120 分钟
难度:⭐⭐⭐

2.1 什么是提示词模式?

**提示词模式(Prompt Patterns)**是经过验证的、可复用的提示词设计模板,用于解决特定类型的问题。就像编程中的设计模式一样,提示词模式能帮助我们更高效地设计有效的提示词[^1]。

为什么要学习模式?

避免重复造轮子: 站在前人经验的基础上
提高成功率: 经过验证的模式更可靠
节省时间: 直接应用成熟的模板
提升质量: 学习最佳实践

2.2 Zero-shot Prompting (零样本提示)

定义

Zero-shot是指不给模型提供任何示例,直接通过描述任务让模型完成。

适用场景

简单明确的任务:分类、翻译、格式转换
模型熟悉的任务:训练数据中大量存在的任务
快速原型验证:不希望花费太多 token 在示例上

基本结构

markdown

[任务描述]

输入:[待处理内容]

输出:

实例对比

任务: 情感分析

❌ 模糊的 Zero-shot:

markdown

这段话是什么情感?
"这个产品太棒了,强烈推荐!"

✅ 良好的 Zero-shot:

markdown

请分析以下评论的情感倾向,并输出JSON格式:
{"sentiment": "positive/negative/neutral", "confidence": 0-1}

评论:"这个产品太棒了,强烈推荐!"

输出:

优缺点

优点	缺点
节省 token 成本	对复杂任务效果有限
快速实现	缺乏具体指导
适合简单任务	输出格式可能不稳定

最佳实践

明确任务类型: "分类"、"提取"、"生成"
指定输出格式: JSON、表格、列表
使用领域关键词: 帮助模型激活相关知识

markdown

请将以下文本分类为:技术/商业/教育/娱乐
文本:"AI正在改变软件开发的方式"
分类:

2.3 Few-shot Prompting (少样本提示)

定义

Few-shot是指在提示词中提供几个示例,帮助模型理解任务要求和期望的输出格式。

为什么有效?

演示任务: 通过示例展示"什么是好的输出"
建立模式: 让模型识别输入-输出的映射关系
稳定格式: 示例统一了输出风格

适用场景

复杂的分类任务: 细粒度的情感分析、主题分类
特定格式输出: JSON、代码、特定文档格式
领域专业任务: 需要特定领域知识的任务

基本结构

markdown

[任务描述]

示例1:
输入:[输入1]
输出:[输出1]

示例2:
输入:[输入2]
输出:[输出2]

示例3:
输入:[输入3]
输出:[输出3]

现在请处理:
输入:[新输入]
输出:

实例对比

任务: 产品评论的情感分类(细粒度)

❌ Zero-shot(可能不稳定):

markdown

将以下评论分类为正面/负面/中性:
"电池续航不错,但屏幕质量一般"

✅ Few-shot(更稳定准确):

markdown

请将产品评论分类为:正面/负面/中性

示例:
输入:"太棒了,超出预期!"
输出:{"sentiment": "positive", "aspects": ["整体"]}

输入:"完全没用,浪费钱"
输出:{"sentiment": "negative", "aspects": ["整体"]}

输入:"功能还行,就是有点贵"
输出:{"sentiment": "neutral", "aspects": ["功能", "价格"]}

输入:"电池续航不错,但屏幕质量一般"
输出:

示例设计的关键原则

多样性: 覆盖不同情况
代表性: 反映真实数据的分布
一致性: 格式和风格统一
数量: 通常 3-5 个示例最佳

高级技巧: 动态示例选择

对于复杂的任务,可以根据输入选择最相关的示例:

markdown

根据以下输入的特点,选择最相似的示例作为参考:

[维护一个示例库]
输入类型A → 示例组1
输入类型B → 示例组2
输入类型C → 示例组3

当前输入:[新输入]
最相似的示例类型:[识别类型]

2.4 Chain-of-Thought Prompting (思维链提示)

定义

**Chain-of-Thought (CoT)**是指引导模型逐步推理,展示中间思考过程的提示方法[^2]。

为什么有效?

分解复杂问题: 将大问题拆解为小步骤
提高推理准确性: 逐步思考减少错误
可解释性: 可以看到模型的推理过程
减少幻觉: 有依据的推理更可靠

适用场景

数学问题: 计算题、应用题
逻辑推理: 因果关系、条件判断
复杂决策: 需要多步分析的任务

基本结构

Zero-shot CoT

markdown

[问题]

让我们一步步思考:

示例:

markdown

问题:一个班级有30名学生,其中60%是女生。如果新转学来5名女生,
现在女生占百分之几?

让我们一步步思考:
1. 原有女生数量 = 30 × 60% = 18名
2. 新增女生后总数 = 18 + 5 = 23名
3. 班级总人数 = 30 + 5 = 35名
4. 女生占比 = 23 / 35 ≈ 0.657 = 65.7%

答案:65.7%

Few-shot CoT

markdown

[包含推理过程的示例]

问题:[新问题]
让我们一步步思考:

示例:

markdown

Q:罗杰有5个网球。他又买了2罐网球,每罐3个。罗杰现在有几个网球?
A:罗杰起初有5个球。2罐网球每罐3个,就是6个。5 + 6 = 11。答案是11。

Q:食堂有23个苹果。如果他们用了20个做午餐,又买了6个,食堂现在有几个苹果?
A:食堂原本有23个苹果。用了20个后剩3个。又买了6个,所以现在有3 + 6 = 9个。
答案是9。

Q:停车场有10辆车。如果3辆车离开,又新来5辆车,现在有多少辆?
让我们一步步思考:

CoT 的关键技巧

明确要求展示过程: "请一步步思考"、"展示你的推理"
使用结构化输出: 列表、编号步骤
鼓励中间检查: "验证每一步"、"检查是否合理"

适用性判断

任务类型	CoT 效果	原因
算术问题	⭐⭐⭐⭐⭐	需要逐步计算
逻辑推理	⭐⭐⭐⭐⭐	需要推导过程
常识问答	⭐⭐⭐	简单问题可能过度复杂
创意生成	⭐⭐	过于理性化
翻译任务	⭐	不需要推理

2.5 ReAct Pattern (推理-行动模式)

定义

**ReAct (Reasoning + Acting)**是一种结合推理和行动的模式,让模型在执行任务时思考、行动、观察,循环迭代[^3]。

核心循环

Thought (思考) → Action (行动) → Observation (观察) → Thought (思考) → ...

适用场景

多步骤任务: 需要多次推理和行动
工具使用: Agent 调用外部工具/API
信息检索: 需要查询外部知识
复杂问题求解: 需要分解和试探

基本结构

markdown

你是一个能够使用工具的AI助手。

可用工具:
- [工具1]: [描述]
- [工具2]: [描述]

处理问题时请遵循以下格式:

Thought: [你的思考]
Action: [使用的工具]
Action Input: [工具的输入]
Observation: [工具返回的结果]
... (可重复多次)

Thought: 我现在知道最终答案了
Final Answer: [最终答案]

问题:[待解决的问题]

实例

任务: 查找特定信息

markdown

Thought: 用户想知道Python最新版本是什么。我应该搜索这个信息。
Action: Search
Action Input: "Python latest version 2025"

Observation: 搜索结果显示Python 3.13.0于2024年10月发布,
是目前最新的稳定版本。Python 3.14.0正在开发中。

Thought: 我得到了答案。Python 3.13.0是最新稳定版本。
Final Answer: 截至2025年1月,Python的最新稳定版本是3.13.0,
于2024年10月发布。

ReAct vs CoT

特征	CoT	ReAct
核心	线性推理链	推理+行动循环
工具使用	❌	✅
适用场景	纯推理任务	需要外部信息的任务
复杂度	较低	较高

实现 ReAct 的关键

明确的工具描述: 详细说明每个工具的功能和输入输出
结构化格式: 严格遵守 Thought/Action/Observation 格式
错误处理: 失败时重新思考并调整策略
终止条件: 明确何时给出最终答案

2.6 其他重要模式

Self-Consistency (自洽性)

核心思想: 让模型生成多个推理路径,选择最一致的答案。

markdown

请用3种不同的方法解决这个问题,然后比较答案:

方法1:
...

方法2:
...

方法3:
...

综合分析,最可靠的答案是:

Tree-of-Thoughts (思维树)

核心思想: 探索多个可能的推理路径,像树一样分支。

markdown

让我们探索几种可能的解决方案:

路径1: [方案A]
- 优点:...
- 缺点:...
- 可行性:...

路径2: [方案B]
- 优点:...
- 缺点:...
- 可行性:...

路径3: [方案C]
- 优点:...
- 缺点:...
- 可行性:...

经过比较,推荐路径X,因为...

Generate Knowledge Prompting

核心思想: 先让模型生成相关知识,再基于这些知识回答问题。

markdown

步骤1:生成相关知识
请先列举与[主题]相关的5个关键概念或事实。

步骤2:基于知识回答
现在基于上面列出的知识,回答以下问题:[问题]

2.7 模式选择指南

决策树

任务是否需要外部信息?
├─ 是 → 使用 ReAct 模式
└─ 否 → 任务是否需要推理?
    ├─ 是 → 使用 CoT 模式
    └─ 否 → 任务是否简单明确?
        ├─ 是 → 使用 Zero-shot
        └─ 否 → 使用 Few-shot

模式组合

在实践中,常常需要组合多种模式:

示例: Few-shot + CoT + ReAct

markdown

任务:基于用户查询提供产品推荐

示例:
输入:"我想买一台办公笔记本"
Thought: 需要了解用户的具体需求和预算
Action: AskQuestions
Action Input: ["预算范围?", "主要用途?", "便携性要求?"]
Observation: 用户回答预算5000-8000,主要用于文档处理,需要轻薄

[继续ReAct循环...]

现在处理你的请求:
输入:[实际输入]

2.8 实战练习

练习1:Zero-shot vs Few-shot

任务: 设计一个提示词,将客户反馈分类为功能请求/问题报告/表扬

点击查看 Few-shot 提示词

markdown

请将客户反馈分类为以下类型:
- 功能请求(FR): 用户希望添加新功能
- 问题报告(BG): 用户遇到bug或问题
- 表扬(P): 用户表达满意

示例:
反馈:"希望能添加夜间模式"
类型:FR

反馈:"应用闪退,无法打开"
类型:BG

反馈:"界面设计很漂亮,很喜欢"
类型:P

反馈:"导出功能不好用,希望能改进"
类型:BG

现在请分类:
反馈:"[用户反馈内容]"
类型:

练习2:使用 CoT 解决问题

任务: 设计一个 CoT 提示词,帮助计算项目预算

点击查看参考答案

markdown

你是一位专业的项目经理。

请帮助计算以下项目的总预算,让我们一步步思考:

项目信息:
- 开发人员:3人,每人月薪15000元,项目周期4个月
- 设计人员:1人,月薪12000元,项目周期2个月
- 服务器费用:每月2000元,项目周期4个月
- 其他费用:测试设备5000元,软件授权3000元

请按以下步骤计算:
步骤1: 计算人力成本(开发人员)
步骤2: 计算人力成本(设计人员)
步骤3: 计算基础设施成本
步骤4: 计算其他成本
步骤5: 汇总总预算
步骤6: 考虑10%的风险储备金,给出最终预算建议

开始计算:

练习3:设计 ReAct Agent

任务: 设计一个能回答技术问题的 ReAct Agent

点击查看参考答案

markdown

你是一个技术支持AI助手,可以使用以下工具:

工具列表:
1. Search: 搜索技术文档和解决方案
2. CodeAnalysis: 分析代码片段
3. ErrorLookup: 查找错误代码的解决方案

处理流程:

Thought: [分析问题,确定需要的行动]
Action: [选择工具]
Action Input: [准备输入]
Observation: [观察结果]
... [根据需要重复]

Thought: 我现在可以给出最终答案
Final Answer: [综合解决方案]

用户问题: [实际技术问题]

2.9 本章小结

核心要点

提示词模式是经过验证的模板,能提高效率和成功率
Zero-shot: 适合简单明确的任务
Few-shot: 通过示例提高准确性和稳定性
CoT: 引导逐步推理,适合复杂问题
ReAct: 结合推理和行动,适合需要外部信息的任务

模式选择速查表

场景	推荐模式
简单分类/翻译	Zero-shot
需要特定格式	Few-shot
数学/逻辑推理	CoT
信息检索/工具调用	ReAct
探索多种方案	Tree-of-Thoughts

下一步

掌握经典模式后,下一章我们将学习进阶技巧,包括框架化思维(CO-STAR、CRISP)、复杂任务拆解、安全考虑等。

思考题

Zero-shot 和 Few-shot 各有什么优缺点?在什么情况下你会选择其中之一?
为什么 CoT 在数学问题上特别有效?它在哪些任务上可能反而降低效果?
ReAct 模式和传统的 CoT 有什么本质区别?设计 ReAct Agent 时需要注意什么?
尝试组合多种模式来设计一个复杂的提示词(如:研究报告生成)

← 返回模块三 | 继续学习:进阶技巧 →

💡 实践建议: 选择一个你熟悉的任务,尝试用不同的模式设计提示词,对比它们的效果。建议测试:Zero-shot vs Few-shot,有/无 CoT 的差异。

第二章:提示词模式 ​

2.1 什么是提示词模式? ​

为什么要学习模式? ​

2.2 Zero-shot Prompting (零样本提示) ​

定义 ​

适用场景 ​

基本结构 ​

实例对比 ​

优缺点 ​

最佳实践 ​

2.3 Few-shot Prompting (少样本提示) ​

定义 ​

为什么有效? ​

适用场景 ​

基本结构 ​

实例对比 ​

示例设计的关键原则 ​

高级技巧: 动态示例选择 ​

2.4 Chain-of-Thought Prompting (思维链提示) ​

定义 ​

为什么有效? ​

适用场景 ​

基本结构 ​

Zero-shot CoT ​

Few-shot CoT ​

CoT 的关键技巧 ​

适用性判断 ​

2.5 ReAct Pattern (推理-行动模式) ​

定义 ​

核心循环 ​

适用场景 ​

基本结构 ​

实例 ​

ReAct vs CoT ​

实现 ReAct 的关键 ​

2.6 其他重要模式 ​

Self-Consistency (自洽性) ​

Tree-of-Thoughts (思维树) ​

Generate Knowledge Prompting ​

2.7 模式选择指南 ​

决策树 ​

模式组合 ​

2.8 实战练习 ​

练习1:Zero-shot vs Few-shot ​

练习2:使用 CoT 解决问题 ​

练习3:设计 ReAct Agent ​

2.9 本章小结 ​

核心要点 ​

模式选择速查表 ​

下一步 ​

思考题 ​

第二章:提示词模式

2.1 什么是提示词模式?

为什么要学习模式?

2.2 Zero-shot Prompting (零样本提示)

定义

适用场景

基本结构

实例对比

优缺点

最佳实践

2.3 Few-shot Prompting (少样本提示)

定义

为什么有效?

适用场景

基本结构

实例对比

示例设计的关键原则

高级技巧: 动态示例选择

2.4 Chain-of-Thought Prompting (思维链提示)

定义

为什么有效?

适用场景

基本结构

Zero-shot CoT

Few-shot CoT

CoT 的关键技巧

适用性判断

2.5 ReAct Pattern (推理-行动模式)

定义

核心循环

适用场景

基本结构

实例

ReAct vs CoT

实现 ReAct 的关键

2.6 其他重要模式

Self-Consistency (自洽性)

Tree-of-Thoughts (思维树)

Generate Knowledge Prompting

2.7 模式选择指南

决策树

模式组合

2.8 实战练习

练习1:Zero-shot vs Few-shot

练习2:使用 CoT 解决问题

练习3:设计 ReAct Agent

2.9 本章小结

核心要点

模式选择速查表

下一步

思考题