跳转至

附录 F:提示词技术决策树

在实际应用中,当你面对一个新任务时,可能会困惑:“我应该用什么技术?是零样本还是少样本?需要思维链吗?”

本附录提供了一个实用的决策树,帮你快速选择合适的提示词工程技术。

快速参考决策树

graph TD
    A["🎯 任务开始"] --> B{"是否有明确的<br/>正确答案?"}

    B -->|是| C{"需要复杂<br/>推理吗?"}
    B -->|否| D{"需要生成<br/>结构化内容?"}

    C -->|是| E{"是否涉及<br/>多步骤?"}
    C -->|否| F{"输出格式<br/>要求高?"}

    E -->|是| G["✅ 思维链<br/>+ 提示词链"]
    E -->|否| H["✅ 零样本<br/>思维链"]

    F -->|是| I{"有参考<br/>示例?"}
    F -->|否| J["✅ 零样本<br/>提示词"]

    I -->|是| K["✅ 少样本<br/>学习"]
    I -->|否| L["✅ 少样本<br/>+ 格式模板"]

    D -->|是| M{"需要<br/>外部知识?"}
    D -->|否| N["✅ 自由生成<br/>+ 角色设定"]

    M -->|是| O{"是否需要<br/>执行动作?"}
    M -->|否| P["✅ RAG"]

    O -->|是| Q["✅ ReAct<br/>+ 工具调用"]
    O -->|否| R["✅ RAG<br/>+ 验证"]

    style G fill:#c8e6c9
    style H fill:#c8e6c9
    style J fill:#c8e6c9
    style K fill:#c8e6c9
    style L fill:#c8e6c9
    style N fill:#c8e6c9
    style P fill:#c8e6c9
    style Q fill:#c8e6c9
    style R fill:#c8e6c9

详细决策指南

层次 1:区分任务类型

问题:这是什么类型的任务?

有明确答案的任务

包括分类、信息提取、事实问答、代码生成等:

示例:
- "这条评论的情感是正面还是负面?"
- "从文本中提取人名"
- "根据这份合同找出关键条款"
- "将这个函数从 JavaScript 改为 Python"

特点:

  • 有标准答案或可验证的结果
  • 可以通过自动化指标评估
  • 容易定义测试用例

开放式生成任务

包括创意写作、头脑风暴、内容创作、对话等:

示例:
- "为这个产品写营销文案"
- "进行头脑风暴,想出 10 个新产品概念"
- "写一个关于 AI 的故事"
- "和我讨论如何学习编程"

特点:

  • 没有唯一的“正确”答案
  • 质量评估更主观
  • 强调创意和多样性

层次 2:复杂性评估

问题:任务需要多复杂的推理?

简单任务 → 零样本

特征:
- 单步完成
- 不需要逻辑推理
- 模型能够直接理解

用零样本当:
- 任务清晰明确
- 模型在预训练中已充分学习
- 格式要求简单

示例提示词:
---
将以下句子翻译为英文:
"我喜欢这部电影"
---

经验估计:简单翻译通常较稳定,但仍需按目标语言和质量标准抽检

中等复杂度 → 少样本 + 思维链

特征:
- 需要理解输入与输出的模式
- 涉及格式转换或简单推理

用少样本当:
- 输出格式不标准
- 需要示范模型的行为
- 模型需要"看到例子"才能理解

示例提示词:
---
从文本中提取实体。使用 JSON 格式。

示例:
输入:张三是一个医生,住在北京
输出:{"人名": "张三", "职业": "医生", "地点": "北京"}

输入:李四在上海工作,是一名律师
输出:{"人名": "李四", "职业": "律师", "地点": "上海"}

输入:王五是程序员,在杭州的阿里巴巴工作
输出:
---

经验估计:示例质量越高越稳定;上线前应使用代表性样本集评估

复杂任务 → 思维链

特征:
- 需要多步推理
- 中间步骤对理解关键
- 答案不能直接推导

用思维链当:
- 任务涉及逻辑推理
- 需要打破问题为子步骤
- 准确性要求高

示例提示词:
---
一个火车以 60 km/h 的速度运行。另一个火车以 40 km/h 的速度
从相反方向运行。两列火车之间的距离是 100 km。一只鸟以
120 km/h 的速度在两列火车之间飞行,直到它们碰撞。
鸟飞行了多远?

请逐步思考:
1. 首先,计算两列火车相对速度
2. 然后,计算碰撞所需的时间
3. 最后,根据时间和鸟的速度计算距离

答案:
---

经验估计:多步推理任务通常受益于结构化过程;实际提升需用同一测试集对比

层次 3:外部知识需求

问题:任务是否需要超出模型训练数据的信息?

不需要外部知识 → 纯提示词

使用纯提示词当:
- 答案在模型的一般知识范围内
- 不需要最新信息
- 不需要特定的专有知识库

例子:
- 解释哲学概念
- 编写代码示例
- 进行语言转换
- 回答通用知识问题

需要外部知识 → RAG(检索增强生成)

使用 RAG 当:
- 需要最新的信息(新闻、股票价格)
- 需要专有知识库(公司文档、产品说明)
- 需要精确的引用来源
- 需要减少幻觉

示例流程:
1. 用户问:"我们最新的产品政策是什么?"
2. 系统从知识库检索相关文档
3. 将文档作为上下文传递给模型
4. 模型在上下文中生成答案

改进:RAG 往往能显著提升事实性任务表现;具体准确率应以业务评测集为准

层次 4:交互与行动

问题:模型是否需要执行实际的操作或调用外部系统?

纯信息生成 → 标准提示词

场景:
- 信息问答
- 内容生成
- 分析与解释

不需要工具调用的提示词:
---
分析这份财务报表,总结关键发现。
---

需要执行操作 → ReAct + 工具调用

场景:
- 调用 API 查询数据
- 执行计算
- 访问系统
- 多步工作流

ReAct 框架提示词:
---
你是一个助手,可以使用以下工具:
- search_api(query): 搜索网络
- calculator(expression): 计算数学表达式
- get_weather(city): 获取天气

任务:告诉我北京明天的天气,并建议我应该穿什么

流程:
思考:我需要获取北京的天气预报
行动:get_weather("北京")
观察:[工具返回的结果]
思考:根据天气条件建议穿着
行动:无需调用工具,直接生成建议
---

关键点:
- 明确列出可用工具
- 使用"思考-行动-观察"循环
- 让模型自己决定何时调用工具

常见场景决策表

分类任务

✓ 情感分析(Sentiment Analysis)
- 零样本:✓ 简单情感(正/负/中立)
- 少样本:✓ 复杂情感(混合、讽刺)
- 思维链:✗ 通常不需要

推荐:零样本起步,如果准确率 < 70% 加少样本

示例:
---
将以下评论分类为:正面、负面、中立

评论:"这部电影很无聊,浪费了我的时间。"
分类:
---

信息抽取

✓ 实体识别(Named Entity Recognition)
- 零样本:△ 只适合明显的实体
- 少样本:✓ 推荐,用示例定义实体类型
- 思维链:△ 当实体间有复杂关系时

推荐:少样本,配合 JSON 格式

示例:
---
从文本中提取人物、地点、组织机构。

示例:
文本:"马斯克是特斯拉的CEO,公司总部在美国加州。"
结果:{"人物": "马斯克", "组织": "特斯拉", "地点": "美国加州"}

文本:"李娜是中国网球运动员,曾效力于国家队。"
结果:
---

问答系统

✓ 事实问答(Factual QA)
- 零样本:△ 常见问题可以
- 少样本:✓ 格式一致性
- RAG:✓✓✓ 强烈推荐,确保准确性

推荐:RAG + 思维链

示例:
---
[检索的上下文文档]

问题:产品保修期是多长?

基于上述文档,回答问题。如果文档中没有相关信息,说明"文档中未提及"。
---

✓ 开放式问答(Open-ended QA)
- 零样本:✓ 通用知识可以
- 少样本:△ 有益但非必需
- 思维链:✓ 建议使用

推荐:思维链

代码生成

✓ 程序补全(Code Completion)
- 零样本:✓ 简单场景
- 少样本:✓✓ 推荐,用示例展示风格
- 特殊:考虑代码特定的微调模型

示例:
---
用 Python 写一个函数。

要求:
- 输入:列表
- 输出:排序后的列表
- 方法:快速排序

示例函数风格:
def bubble_sort(arr):
    for i in range(len(arr)):
        for j in range(len(arr)-1-i):
            if arr[j] > arr[j+1]:
                arr[j], arr[j+1] = arr[j+1], arr[j]
    return arr

请写快速排序函数:
---

推荐:少样本 + 代码格式模板

内容生成

✓ 营销文案(Marketing Copy)
- 零样本:△ 可以,但可能不符合风格
- 少样本:✓✓ 推荐,定义风格和语调
- 角色设定:✓ 非常有用

示例:
---
你是一个经验丰富的市场营销专家,专门写电商产品描述。

语调:热情、专业、简洁
长度:100-150 字

示例:
产品:无线耳机
描述:"解放你的双手!这款无线耳机采用最新的主动降噪技术,
让你在任何环境中享受清晰的音质。续航达 12 小时,快速充电
仅需 15 分钟。适合工作、运动、旅行。"

产品:智能手表
描述:
---

推荐:角色设定 + 少样本示例

数据转换

✓ 格式转换(Format Conversion)
- 零样本:△ 简单格式
- 少样本:✓✓✓ 强烈推荐

示例:
---
将自然语言转换为 SQL 查询。

示例:
输入:"找出 2024 年销售超过 10 万的产品"
输出:SELECT * FROM products WHERE sales > 100000 AND year = 2024;

输入:"统计每个城市的订单数"
输出:SELECT city, COUNT(*) as order_count FROM orders GROUP BY city;

输入:"列出今年评分最高的 5 个产品"
输出:
---

关键:提供 2-3 个高质量示例

性能优化决策

当准确率不达标时

现象:准确率 60-70%,不符合要求

决策流程:
1. 是格式问题?→ 加少样本 + 格式模板
2. 是理解问题?→ 加思维链
3. 是知识不足?→ 加 RAG
4. 是极难的任务?→ 考虑微调或更强的模型

对应改进方案:
┌─────────────┬──────────────┬─────────────────┐
│ 问题类型     │ 具体表现      │ 推荐方案        │
├─────────────┼──────────────┼─────────────────┤
│ 格式错误     │ 格式不规范    │ 少样本 + 模板   │
│ 逻辑错误     │ 推理偏离      │ 思维链 + CoT   │
│ 知识错误     │ 答案错误/幻觉 │ RAG + 验证      │
│ 风格不符     │ 语气不对      │ 角色设定 + 示例 │
└─────────────┴──────────────┴─────────────────┘

当成本过高时

现象:Token 使用过多,成本高

决策流程:
1. 是上下文太长?→ 精简或摘要
2. 是多次调用?→ 合并为一次
3. 是模型太强?→ 尝试更弱的模型
4. 是重复计算?→ 缓存结果

对应优化方案:
- 删除不必要的示例(保留 2-3 个高质量示例)
- 简化提示词措辞
- 减少上下文信息(检索相关信息,舍弃无关部分)
- 使用 prompt caching 缓存系统提示词
- 对小任务考虑使用轻量模型(如 Claude Haiku、GPT-5.6 Luna)而非旗舰模型

当延迟过高时

现象:响应时间 > 2 秒

决策流程:
1. 是模型推理慢?→ 尝试更小的模型或流式输出
2. 是数据检索慢?→ 优化 RAG 的检索性能
3. 是工具调用多?→ 合并或并行调用
4. 是生成内容长?→ 分页或流式返回

对应优化方案:
- 使用 stream API 流式返回
- 优化向量数据库查询(使用索引、缓存)
- 并行调用多个 API 而非串联
- 预计算常见问题的答案

技术组合矩阵

        零样本    少样本    思维链    RAG    ReAct
分类      ✓        ✓✓      △        -      -
抽取      △        ✓✓✓     △        △      -
问答      ✓        ✓        ✓✓      ✓✓✓    -
生成      ✓✓       ✓        -        -      -
推理      △        ✓        ✓✓✓      △      -
决策      -        △        ✓✓       -      ✓✓✓
工作流    -        -        △        △      ✓✓✓

图例:
✓     可用
✓✓    推荐
✓✓✓   强烈推荐
△     在特定情况下有用
-     不适用

实践建议

快速迭代策略

第 1 步:选择基础方案(5 分钟)
- 根据决策树选择初始技术
- 撰写最小化提示词
- 测试能否工作

第 2 步:评估效果(10 分钟)
- 在 5-10 个测试用例上运行
- 计算成功率
- 识别主要失败模式

第 3 步:有针对性改进(20 分钟)
- 根据失败模式选择优化策略
- 添加示例或思维链
- 再次测试

第 4 步:边界测试(10 分钟)
- 测试边界情况
- 检查特殊输入
- 评估稳定性

总时间:45 分钟内从 0 到可用的方案

避免的陷阱

❌ 陷阱 1:一开始就用最复杂的技术
   → 从零样本开始,逐步升级

❌ 陷阱 2:添加过多的示例
   → 2-3 个高质量示例通常足够,更多反而会混淆

❌ 陷阱 3:忽视输入质量
   → 好的 RAG 检索 > 完美的提示词

❌ 陷阱 4:一成不变地使用一种技术
   → 定期重新评估,根据实际结果调整

❌ 陷阱 5:没有建立评估指标
   → 无法判断改进是否有效

总结

  • 简单任务 → 零样本 + 清晰指令
  • 格式问题 → 少样本 + 示例
  • 推理问题 → 思维链
  • 知识问题 → RAG
  • 执行问题 → ReAct
  • 准确率低 → 添加示例或思维链
  • 成本高 → 精简上下文
  • 延迟高 → 流式输出或更小的模型