玩转大模型必备：深入剖析 Prompt 高级技巧 —— Chain of Thought 与 Few-Shot

Posted on 2026-05-25 In AI 技术

在与大语言模型（LLM）打交道的日常中，你是否经常遇到这样的场景：面对一个稍微复杂的逻辑推理题，模型给出了一本正经的胡说八道（幻觉）；或者面对一种特定的输出格式，无论你怎么强调“请按格式输出”，模型总是时而灵光时不灵光？

如果你只知道“设定角色+描述任务”这种基础的 Prompt 写法，那么你很可能已经触碰到了大模型能力的天花板。要想真正释放 LLM 的强大推理与泛化能力，我们必须从**“指令驱动”转向“上下文学习”**。

今天，我们将深入探讨 Prompt Engineering 中最核心、最高级的两大技巧：**Few-Shot（少样本提示）**与 Chain of Thought（思维链）。无论你是 AI 应用开发者，还是致力于提升日常效率的极客，掌握这两把利器都将让你的 Prompt 功力产生质的飞跃。

一、核心基石：Few-Shot Learning（少样本提示）

1. 什么是 Few-Shot？

传统的模型使用方式是“Zero-Shot（零样本）”，即我们不提供任何示例，直接让模型去完成任务。虽然现代 LLM 在 Zero-Shot 上表现已经非常惊人，但在面对特定领域、特殊格式或复杂边界条件时，仍然容易跑偏。

Few-Shot（少样本提示）的核心思想极其朴素：“ Don’t tell me, show me.”（别只告诉我怎么做，做给我看）。

我们在 Prompt 中提供少量的“输入-输出”对（通常 2 到 5 个），作为模型推理的参考上下文。模型通过这些示例，能够迅速“领悟”你的真实意图，包括潜在的规律、语气、格式甚至是边缘情况的处理逻辑。

2. Zero-Shot vs. One-Shot vs. Few-Shot 实战对比

假设我们需要模型提取用户评论中的“产品名称”和“情感倾向”，并以特定的 JSON 格式输出。

❌ 基础的 Zero-Shot 尝试：

1 2	请提取下面这句话中的产品名称和情感倾向，输出为 JSON 格式。句子：“这台 iPhone 15 Pro 的钛金属边框真的太有质感了，但是电池续航有点拉胯。”

模型可能的输出： 可能会输出一大段废话，比如：“产品名称是 iPhone 15 Pro，情感倾向是混合的，因为…”，而没有直接给出干净的 JSON。

✅ 使用 Few-Shot 的完美绝杀：

你的任务是提取文本中的产品名称和情感倾向（positive/negative/neutral），并严格按照 JSON 格式输出。

# 示例 1
输入：“MacBook Pro 的屏幕色彩绝了，写代码看着真舒服！”
输出：
```json
{"product": "MacBook Pro", "sentiment": "positive"}

示例 2

输入：“这双耐克运动鞋穿了不到一个月就开胶了，绝绝子（反讽）。”
输出：

1	{"product": "耐克运动鞋", "sentiment": "negative"}

实际任务

输入：“这台 iPhone 15 Pro 的钛金属边框真的太有质感了，但是电池续航有点拉胯。”
输出：

*模型输出：* 完美输出 `{"product": "iPhone 15 Pro", "sentiment": "neutral"}` （或者根据你的定义认为是 mixed）。

### 3. Few-Shot 的高阶技巧与避坑指南

*   **格式一致性：** 示例之间的格式必须严格统一。如果你的示例 1 用的是 `JSON`，示例 2 突然变成了 `XML`，模型的注意力机制会发生混乱，导致输出失效。
*   **标签的多样性：** 如果你只提供“正面”和“负面”的示例，模型可能无法识别“中立”。在 Few-shot 中包含各种边界情况的示例（如：讽刺语气、没有提及产品的句子），能极大增强鲁棒性。
*   **顺序很关键：** 大语言模型存在 **“近因偏差”**，即 Prompt 末尾的示例对模型最终输出的影响最大。因此，将与你当前任务最相似的示例放在最后，往往能取得更好的效果。

---

## 二、 灵魂觉醒：Chain of Thought（思维链）

如果说 Few-Shot 是给模型定下了规矩，那么 Chain of Thought (CoT) 则是赋予了模型**“思考的能力”**。

### 1. 为什么大模型需要 CoT？

大语言模型的本质是一个“下一个 Token 预测器”。它从左到右逐字生成文本。
当你向模型提出一个复杂的数学题或逻辑推理题时，如果要求它直接给出答案，它实际上是在**强行预测最终结果的第一个字**。这就像一个学生不写草稿纸，企图在脑海中一口算出微积分的答案，结果必然是胡编乱造（产生幻觉）。

**Chain of Thought (CoT)** 的提出（源自 Google 团队 2022 年的经典论文），正是为了解决这个问题。它的核心理念是：**强迫模型将复杂的推理过程分解为多个中间步骤，一步一步推导，最终得出结论。**

正如人类在解决复杂问题时需要打草稿一样，CoT 就是 LLM 的“草稿纸”。

### 2. Auto-CoT（Zero-Shot CoT）：一句话魔法

最简单的激发 CoT 的方法，不需要提供任何示例，只需在你的 Prompt 末尾加上一句神奇的咒语：

> **"Let's think step by step."** （请一步一步地思考。）

**实战测试：**

```text
# 问题
食堂有 23 个苹果。如果他们用 20 个做午餐，并又买了 6 个，他们还有多少个苹果？

# 普通 Prompt 直接要答案
问：食堂有 23 个苹果。如果他们用 20 个做午餐，并又买了 6 个，他们还有多少个苹果？
答：答案是 9。（错误！模型直接预测答案，算错了）

# CoT Prompt
问：食堂有 23 个苹果。如果他们用 20 个做午餐，并又买了 6 个，他们还有多少个苹果？
答：让我们一步一步地思考。
首先，我们有 23 个苹果。
用了 20 个做午餐，所以剩下 23 - 20 = 3 个苹果。
然后，他们又买了 6 个。
所以最后有 3 + 6 = 9 个苹果。
答案是 9。（正确！过程清晰，逻辑严密）

3. Manual CoT（Few-Shot CoT）：精确控制思考路径

虽然 “Let’s think step by step” 很神奇，但模型自己摸索的推理路径有时可能是不稳定的。在工业级应用中，我们通常会结合前面讲的 Few-Shot，不仅给出示例的答案，还给出示例的推理过程。这就是 Few-Shot CoT。

实战案例：复杂业务逻辑判断

假设你是一个电商平台的客服机器人，需要判断用户是否符合退货条件。规则非常复杂（如：是否超过30天？是否拆封？是否是生鲜食品？）。

你是一个严格的电商售后审核员。请根据用户的描述，判断是否同意退货，并给出理由。

# 示例 1
用户诉求：我买的这个机械键盘用了两周，空格键有点晃动，我想退货。
思考过程：
1. 提取商品类别：电子产品（机械键盘）。
2. 提取时间：两周（未超过常规的15天无理由或30天质保期）。
3. 提取状态：质量问题（空格键晃动），非人为损坏。
4. 匹配规则：非定制类商品，在质保期内出现质量问题，支持退货退款。
最终决定：同意退货。

# 示例 2
用户诉求：三天前买的鲜活大龙虾，今天发现不好吃，我要退全款！
思考过程：
1. 提取商品类别：生鲜食品（鲜活大龙虾）。
2. 提取时间：三天前。
3. 提取状态：主观认为“不好吃”，非死亡或变质等客观事实。
4. 匹配规则：生鲜类商品，不支持无理由退货；若非变质问题，不支持退款。
最终决定：拒绝退货。

# 实际任务
用户诉求：我昨天收到的 iPhone 15，屏幕自己碎裂了，要求退货！
思考过程：

通过提供带有“思考过程”的 Few-Shot，模型不仅能够准确判定结果，而且输出的理由完全符合你预设的业务逻辑。这就是 Prompt Engineering 中“天花板级别”的控制力。

三、王炸组合：将 CoT 与 Few-Shot 结合的最佳实践

在真实的生产环境中，我们极少单独使用 CoT 或 Few-Shot，而是将它们深度融合。以下是一套工业级 Prompt 的标准架构模板：

# Role (角色设定)
你是一位拥有 10 年经验的资深数据分析师，精通 SQL 和业务指标拆解。

# Task (任务描述)
你的任务是将用户的自然语言提问，转化为符合公司规范的 PostgreSQL SQL 查询语句。
在输出最终 SQL 之前，你必须先输出你的“分析计划”。

# Rules (规则限定)
1. 只能使用 SELECT 语句，严禁使用 UPDATE/DELETE。
2. 日期字段必须使用标准的 `YYYY-MM-DD` 格式。
3. 输出必须严格遵循规定的 JSON 格式。

# Few-Shot & CoT (少样本与思维链示例)
<example_1>
用户提问：上个月的总销售额是多少？
思考过程：
1. 锁定时间范围：上个月的起始和结束日期。
2. 锁定目标指标：总销售额。
3. 锁定涉及表：orders 表。
4. 编写逻辑：使用 SUM() 函数，并用 WHERE 过滤时间。
最终输出：
```json
{"reasoning": "过滤上个月的订单并求和", "sql": "SELECT SUM(amount) FROM orders WHERE order_date >= DATE_TRUNC('month', CURRENT_DATE - INTERVAL '1 month') AND order_date < DATE_TRUNC('month', CURRENT_DATE);"}

</example_1>

<example_2>
用户提问：过去 7 天内，每天平均客单价是多少？
思考过程：
…
最终输出：
…
</example_2>

Actual Task (实际任务)

用户提问：今年第一季度，购买次数超过 3 次的 VIP 用户有多少人？
思考过程：


**为什么这种结构如此强大？**
1. **CoT 充当了缓冲区**：生成 SQL 这种要求 100% 准确的代码，直接生成极易报错。先让模型输出“思考过程”，其实是在引导它做表字段的映射和逻辑梳理。
2. **Few-Shot 界定了输出边界**：即使模型理解了要输出 SQL，如果不给示例，它可能会附带一堆废话。Few-Shot 示范了严格的 JSON 结构，方便下游代码（如 Python）直接 `json.loads()` 解析。

---

## 四、 CoT 的高级衍生玩法

掌握了基础之后，我们可以利用 CoT 的特性玩出更多花样。

### 1. Self-Consistency（自我一致性）
这是一种后处理策略。同一个带有 CoT 的 Prompt，你让模型连续生成 5 次。如果它 3 次推导出答案是 A，2 次推导出答案是 B。那么“答案 A”的置信度远高于答案 B。
**适用场景：** 高精度的数学计算、逻辑推理任务。通过“少数服从多数”的方式对抗 LLM 的幻觉。

### 2. Tree of Thoughts (ToT / 思维树)
如果说 CoT 是一条道走到黑，ToT 则是允许模型在每一步都发散出多个可能的思路，然后通过评估机制选出最优的那条路继续往下走。
**适用场景：** 创意写作、复杂的战略规划、数独等需要不断回溯的推理任务。

### 3. 反向思考
如果你不知道某个问题怎么拆解，你可以利用 CoT 让大模型自己去生成 Few-Shot 示例：
```text
我需要微调一个模型来识别文本中的冒犯性语言。
请你作为一个专家，为我生成 5 个高质量的 "输入文本 -> 推理过程 -> 分类结果" 的少样本示例。

五、代码实战：用 Python 与 OpenAI API 落地 CoT

脱离代码谈 Prompt 都是纸上谈兵。下面我们通过一段标准的 Python 代码，演示如何在实际工程中稳定地实现 Few-Shot + CoT。

这里我们以 OpenAI 的 gpt-3.5-turbo（或 gpt-4o）接口为例，实现一个“复杂客服问答提取器”。

import openai
import json

# 假设您已配置好 API KEY
# openai.api_key = "your-api-key"

# 定义系统级的 Prompt，包含 Few-Shot 和 CoT 规则
system_prompt = """
你是一个专业的快递客服助手。你的任务是根据用户的抱怨，提取出问题类型、情绪等级（1-5），并给出安抚话术。
你必须先进行一步步的思考，然后输出严格的 JSON。

# 示例 1
用户输入：我的快递已经发货 5 天了，怎么还没动静？查不到物流！
思考过程：
1. 分析问题：用户提到物流长时间不更新。
2. 归类：物流异常。
3. 判断情绪：较为着急，但没有辱骂，情绪等级为 3。
4. 拟定策略：安抚情绪，承诺立刻核实。
最终输出：
{"issue_type": "物流停滞", "emotion_level": 3, "response": "亲，非常抱歉让您久等了！我这就去帮您催促快递网点核实包裹情况，一有消息马上通知您，请您放心。"}
"""

def analyze_customer_complaint(user_input):
    """
    调用 OpenAI API 处理用户输入
    """
    try:
        response = openai.chat.completions.create(
            model="gpt-3.5-turbo", # 推荐使用 gpt-4o 效果更佳
            messages=[
                {"role": "system", "content": system_prompt},
                {"role": "user", "content": user_input}
            ],
            temperature=0.3, # 降低温度以保证 JSON 输出的稳定性
            # 非常重要的技巧：使用 response_format 强制输出 JSON (需模型支持)
            response_format={"type": "json_object"} 
        )
        
        # 提取模型回复的文本
        raw_output = response.choices[0].message.content
        
        # 因为使用了 CoT，模型可能会在 JSON 前输出思考过程。
        # 结合 response_format，现代大模型通常会将思考过程放在 JSON 的某个字段，或者纯粹输出 JSON。
        # 这里我们安全地解析 JSON
        parsed_output = json.loads(raw_output)
        
        # 如果模型把思考过程也放进了 JSON，我们可以将其分离
        reasoning = parsed_output.get("reasoning", parsed_output.get("思考过程", "无"))
        final_result = {
            "issue_type": parsed_output.get("issue_type"),
            "emotion_level": parsed_output.get("emotion_level"),
            "response": parsed_output.get("response")
        }
        
        print("=== 模型思考过程 ===")
        print(reasoning)
        print("\n=== 最终执行结果 ===")
        print(json.dumps(final_result, ensure_ascii=False, indent=2))
        
        return final_result

    except Exception as e:
        print(f"发生错误: {e}")

# 测试用例
if __name__ == "__main__":
    test_input = "你们是不是瞎啊？包裹上面的易碎品标签那么大，结果收到的时候箱子都扁了，里面的瓷器全碎了！我要投诉！赔钱！"
    analyze_customer_complaint(test_input)

代码解析：

System Prompt 深度应用：我们在系统级别注入了 Few-Shot 和 CoT 规则，这比对每次用户输入都带上示例要节省大量 Token。
Temperature 参数调整：在使用 CoT 和要求严格格式输出时，务必调低 temperature（如 0.1 - 0.3），这能减少模型的随机发散，保证逻辑推理的严谨性。
JSON Mode：使用了 response_format={"type": "json_object"}，结合强力的 Prompt，模型极少会出现解析错误，极大提升了工程可用性。

六、总结与展望

在人工智能领域，有一种说法：“ Prompt Engineering 是用自然语言在写代码。”

如果说基础的 Prompt 技巧相当于代码中的“变量声明”和“打印输出”，那么 Few-Shot 和 Chain of Thought 绝对相当于编程中的“面向对象”和“设计模式”。

让我们最后总结一下今天的核心知识点：

Few-Shot (少样本提示)：解决**“输出格式不规范”和“任务边界不清晰”**的问题。用示例代替繁琐的说明，让 LLM 依葫芦画瓢。
Chain of Thought (思维链)：解决**“复杂逻辑推理失败”和“幻觉”**的问题。通过要求“一步步思考”，强迫模型在得出结论前先运算中间变量。
强强联手：在实际业务（如 NL2SQL、复杂的文档信息提取、客服对话生成）中，结合二者（提供带有推理过程的参考示例），是目前工业界控制和压榨大模型性能的最优解。

随着大模型本身能力的快速进化（例如 OpenAI 的 o1 模型已经内置了强大的隐式 CoT 机制），未来我们可能不再需要手动去写繁琐的“让我们一步一步思考”。但是，如何为 AI 提供高质量的上下文、如何理清人类解决复杂问题的逻辑链条，这种“Prompt Engineering”的思维方式，必将成为 AI 时代每一个技术人的核心竞争力。

现在，就打开你的 ChatGPT 或 Claude，找一个困扰你许久的复杂任务，亲自用 Few-shot 和 CoT 魔法试一试吧！

一、 核心基石：Few-Shot Learning（少样本提示）