# 附录 D：提示词技术分类索引
提示词工程经过数年的快速发展，已经演变出多种多样的技术和方法。为了更好地理解和应用这些技术，我们需要建立一个清晰的分类体系。本节基于最新的综述研究 [Mizrahi et al. (2024)](https://arxiv.org/abs/2402.07927)，介绍大语言模型提示词技术的系统化分类。
## D.1 为什么需要分类体系
随着 *CoT*、*ReAct*、*RAG* 等技术层出不穷，初学者容易感到混乱。分类体系可以帮助我们：
1. **建立全局认知**：了解不同技术之间的关系和区别。
2. **指导技术选型**：根据任务需求选择合适的技术类别。
3. **系统化学习**：按图索骥，有条不紊地掌握各项技能。
## D.2 提示词技术分类图谱
我们可以从 **交互范式**和**应用策略** 两个主要维度对提示词技术进行分类：
```mermaid
mindmap
root((提示词技术
分类体系))
交互范式
零样本 Zero-Shot
少样本 Few-Shot
思维链 Chain-of-Thought
应用策略
分解 Decomposition
任务分解
逐步推理
集成 Ensemble
自一致性 Self-Consistency
多路投票
增强 Augmentation
检索增强 RAG
工具使用 Tool Use
执行机制
代码生成 PAL
自我修正 Self-Correction
```
*图 D-1：提示词工程技术分类图谱*
## D.3 核心类别详解
### D.3.1 基础交互范式
这是提示词最基本的形态，决定了模型如何通过示例进行学习。
| 范式 | 定义 | 典型场景 | 优势 | 局限 |
| ---------------------------------------------------------------------------------------------------------------- | --------- | ---------- | -------------- | --------- |
| [**Zero-Shot**](/prompt_engineering_guide/di-er-bu-fen-he-xin-ji-shu-pian/05_few_shot/5.1_zero_shot_few_shot.md) | 不给示例，直接提问 | 通用问答、翻译、摘要 | 简单快捷，Token 成本低 | 复杂任务效果不稳定 |
| **One-Shot** | 提供单个示例 | 格式转换、简单分类 | 平衡效果与成本 | 示例选择影响大 |
| [**Few-Shot**](/prompt_engineering_guide/di-er-bu-fen-he-xin-ji-shu-pian/05_few_shot/5.1_zero_shot_few_shot.md) | 提供2-6个示例 | 复杂分类、信息提取 | 效果可控，格式一致 | 占用上下文空间 |
选择策略：当任务足够标准化时（如翻译），优先尝试零样本；当需要特定输出格式或边界处理时，逐步增加示例数量。详见[第5章](/prompt_engineering_guide/di-er-bu-fen-he-xin-ji-shu-pian/05_few_shot.md)。
### D.3.2 推理增强策略
针对需要逻辑推理的复杂任务，引导模型展示思考过程。
| 策略 | 核心机制 | 最佳场景 | 示例触发语 |
| --------------------------------------------------------------------------------------------------------------------------- | ---------- | ----------- | ----------------- |
| [**Chain-of-Thought**](/prompt_engineering_guide/di-er-bu-fen-he-xin-ji-shu-pian/06_chain_of_thought/6.1_cot_principles.md) | 显式展示中间步骤 | 数学计算、逻辑推理 | “让我们一步步思考” |
| [**Tree-of-Thought**](/prompt_engineering_guide/di-er-bu-fen-he-xin-ji-shu-pian/06_chain_of_thought/6.4_tree_of_thought.md) | 探索多条推理路径 | 创意问题、规划任务 | “列出3种可能的方案” |
| **Decomposition** | 将大问题拆分为子问题 | 复杂工作流、多步骤任务 | “首先...然后...最后...” |
这些策略的共同点是：**将隐式的思考过程显式化**。研究表明，在大模型（>50B 参数）上，思维链可将推理准确率提升 20-50%。详见[第6](/prompt_engineering_guide/di-er-bu-fen-he-xin-ji-shu-pian/06_chain_of_thought.md)、[7章](/prompt_engineering_guide/di-er-bu-fen-he-xin-ji-shu-pian/07_prompt_chaining.md)。
### D.3.3 外部能力增强
弥补模型自身知识和能力的边界，使其能够访问实时信息和执行具体操作。
| 技术 | 解决的问题 | 工作原理 | 典型工具 |
| ----------------------------------------------------------------------------------------------------- | --------- | ----------- | ----------------- |
| [**RAG**](/prompt_engineering_guide/di-san-bu-fen-gao-ji-ying-yong-pian/09_rag/9.1_rag_principles.md) | 知识截止、私有数据 | 检索相关文档注入上下文 | 向量数据库、嵌入模型 |
| [**Tool Use**](/prompt_engineering_guide/di-san-bu-fen-gao-ji-ying-yong-pian/08_react_tools.md) | 无法计算、无法操作 | 调用外部API执行任务 | 搜索引擎、计算器、代码解释器 |
| **Code Execution** | 复杂计算、数据处理 | 生成并执行代码 | Python 沙盒、Jupyter |
选择策略：
* 需要最新信息或私有知识 → RAG（[第9章](/prompt_engineering_guide/di-san-bu-fen-gao-ji-ying-yong-pian/09_rag.md)）
* 需要精确计算或外部操作 → Tool Use（[第8章](/prompt_engineering_guide/di-san-bu-fen-gao-ji-ying-yong-pian/08_react_tools.md)）
* 需要复杂数据处理 → Code Execution（[第8章](/prompt_engineering_guide/di-san-bu-fen-gao-ji-ying-yong-pian/08_react_tools.md)）
### D.3.4 可靠性集成策略
通过多路径验证和自我审视机制，提升输出的稳定性和准确性。
| 策略 | 核心思想 | 适用场景 | 成本考量 |
| ----------------------------------------------------------------------------------------------------------------------------- | ---------- | --------- | -------- |
| [**Self-Consistency**](/prompt_engineering_guide/di-er-bu-fen-he-xin-ji-shu-pian/06_chain_of_thought/6.3_self_consistency.md) | 多次采样+多数投票 | 数学题、逻辑推理 | 需多次API调用 |
| **Self-Correction** | 生成后自我检查和修正 | 代码生成、事实核查 | 增加一轮对话 |
| **Verification Chain** | 独立验证步骤 | 关键业务决策 | 需设计验证逻辑 |
这些策略的共同点是：**不信任单次输出，通过冗余机制提升可靠性**。详见[第6](/prompt_engineering_guide/di-er-bu-fen-he-xin-ji-shu-pian/06_chain_of_thought.md)、[7章](/prompt_engineering_guide/di-er-bu-fen-he-xin-ji-shu-pian/07_prompt_chaining.md)。
## D.4 技术选型决策流程
面对一个具体任务，可以按以下流程选择技术：
```mermaid
flowchart TD
Start["开始任务分析"] --> Q1{"需要最新或私有知识?"}
Q1 -->|是| RAG["使用 RAG"]
Q1 -->|否| Q2{"需要执行具体操作?"}
Q2 -->|是| Tool["使用 Tool Use"]
Q2 -->|否| Q3{"需要多步骤推理?"}
Q3 -->|是| CoT["使用思维链"]
Q3 -->|否| Q4{"对输出格式要求严格?"}
Q4 -->|是| FewShot["使用少样本"]
Q4 -->|否| ZeroShot["使用零样本"]
RAG --> Q5{"需要高可靠性?"}
Tool --> Q5
CoT --> Q5
FewShot --> Q5
ZeroShot --> Q5
Q5 -->|是| Ensemble["添加一致性验证"]
Q5 -->|否| Done["完成设计"]
Ensemble --> Done
```
*图 D-2：提示词技术选型决策流程*
## D.5 本书结构与分类体系的对应
本书的章节编排大体遵循了从基础到高级的进阶路线：
* **基础篇 (第3-4章)**：涵盖基础交互范式和设计原则。
* **技术篇 (第5-7章)**：深入讲解少样本、思维链等推理增强策略。
* **应用篇 (第8-10章)**：探讨工具使用、RAG和多模态等外部增强技术。
* **进阶篇 (第11-14章)**：关注安全性、自动化及未来集成策略。
### 讨论
1. 参考上面的技术分类体系，分析你最近遇到的一个 AI 应用需求——最终应该选择哪条技术路线？
2. 如果预算有限只能深入学习一个技术类别，你会优先选“推理增强”还是“外部能力增强”？为什么？
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://yeasy.gitbook.io/prompt_engineering_guide/fu-lu/d_taxonomy_index.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.