4、提示工程（Prompt Engineering）：提示词设计原则、Few-shot、CoT、角色扮演、结构化输出等技巧，以及常见陷阱与优化方法

提示工程（Prompt Engineering）是大模型应用开发中最基础也最关键的技能之一。在面试中，面试官通常不会直接考察“你是否了解提示词”，而是通过具体场景考察你能否设计出稳定、可控、可复用的提示词方案，并规避常见的失效陷阱。本章将从设计原则、核心技巧、结构化输出、常见陷阱与优化方法五个维度展开，帮助你建立系统化的提示工程知识体系。

提示工程核心框架 提示词设计 原则：明确·具体·可验证 核心技巧：Few-shot · CoT · 角色扮演 · 结构化输出 Few-shot 示例驱动 提供输入-输出对 CoT 思维链引导 分步推理·中间过程 角色扮演+结构化 身份约束·JSON输出 常见陷阱：过拟合·幻觉·格式漂移·上下文污染 优化闭环：评估→迭代→回归

4.1 提示词设计核心原则

核心原理：提示词的本质是“与模型进行条件概率对齐”。大模型在给定上下文后，会基于训练分布生成最可能的后续内容。因此，提示词设计的核心目标不是“让模型听懂”，而是“让模型在概率空间中锁定到我们期望的答案区域”。这意味着提示词需要具备四个基本属性：明确性（Unambiguous）、具体性（Specific）、可验证性（Verifiable）和上下文充分性（Context-sufficient）。

操作流程：设计一个高质量提示词，建议遵循以下五步流程：

  1. 任务定义：明确你要模型完成什么任务，是分类、生成、抽取、改写还是推理？任务类型决定了提示词的结构。
  2. 约束声明：列出所有硬性约束，如输出格式、长度限制、禁止内容、语言风格等。
  3. 示例准备：准备1-5个高质量示例（Few-shot），示例要覆盖典型场景和边界情况。
  4. 推理路径设计：对于复杂任务，设计思维链（CoT）引导模型分步推理。
  5. 输出校验：在提示词中要求模型输出可解析的结构化格式（如JSON），并预留校验逻辑。

实战案例：假设我们需要开发一个“客户评论情感分析”功能。初始提示词为：

请分析以下评论的情感：

这种提示词过于模糊，模型可能输出“正面”“负面”“中性”等不同格式，且无法处理复杂评论。优化后的提示词为：

你是一个情感分析专家。请分析以下客户评论的情感倾向，输出JSON格式，包含字段：sentiment（positive/negative/neutral）、confidence（0-1之间的小数）、reason（一句话解释）。
  
  示例1：
  评论："这家餐厅的菜味道不错，但服务态度很差。"
  输出：{"sentiment": "neutral", "confidence": 0.75, "reason": "正面与负面评价并存"}
  
  示例2：
  评论："物流太慢了，等了一个星期才到！"
  输出：{"sentiment": "negative", "confidence": 0.95, "reason": "明确表达不满"}
  
  现在请分析：
  评论："手机屏幕很清晰，电池续航也超出预期，就是价格稍微贵了点。"

优化后的提示词通过角色设定、格式约束、示例引导三个维度，显著提升了输出的稳定性和可解析性。

4.2 Few-shot 与 CoT 技巧深度解析

Few-shot（少样本学习）的核心原理是：通过提供少量输入-输出对，让模型在推理时“模仿”示例的模式。Few-shot 的关键不在于示例的数量，而在于示例的质量与覆盖度。一个优秀的 Few-shot 示例集应满足：

  • 代表性：覆盖最常见的输入模式。
  • 边界性：包含至少一个容易混淆的边界案例。
  • 格式一致性：所有示例的输出格式必须完全一致。
  • 难度递进：从简单到复杂排列，帮助模型建立信心。

CoT（Chain-of-Thought，思维链）的核心原理是：通过引导模型展示中间推理步骤，将复杂问题分解为多个简单子问题，从而降低每一步的推理难度。CoT 特别适用于数学推理、逻辑判断、多条件决策等场景。CoT 的两种主要实现方式：

方式 实现方法 适用场景 优缺点
Zero-shot CoT 在提示词末尾添加“Let's think step by step” 通用推理任务 简单易用，但推理过程不可控
Few-shot CoT 在示例中展示完整的推理步骤 数学题、逻辑题、复杂决策 效果更稳定，但需要精心设计示例

经验提醒：CoT 并非万能。对于简单任务（如情感分类、关键词抽取），使用 CoT 反而会增加输出延迟和 消耗，且可能引入不必要的推理错误。建议在任务复杂度达到“需要两步以上推理”时才使用 CoT。

案例拆解：以“商品推荐”场景为例，我们需要根据用户描述推荐合适的商品。使用 Few-shot CoT 的提示词设计如下：

你是一个智能购物助手。请根据用户需求推荐商品，并展示推理过程。

示例1：
用户需求："我想买一款适合跑步时佩戴的无线耳机，预算500元左右。"
推理过程：
1. 关键需求提取：跑步佩戴→需要防汗防水；无线→蓝牙连接；预算500元→中端价位。
2. 筛选条件：防水等级≥IPX4，蓝牙5.0以上，价格300-600元。
3. 推荐结果：XX品牌运动耳机，IPX5防水，蓝牙5.2，价格499元。
输出：{"product": "XX品牌运动耳机", "price": 499, "reason": "IPX5防水适合运动，蓝牙5.2稳定连接，价格在预算范围内"}

示例2：
用户需求："我需要一款办公用的机械键盘，要安静，预算1000元左右。"
推理过程：
1. 关键需求提取：办公→需要数字键区；安静→选择红轴或静音轴；预算1000元→高端机械键盘。
2. 筛选条件：104键或87键，红轴/静音轴，价格800-1200元。
3. 推荐结果：YY品牌静音红轴机械键盘，104键，价格899元。
输出：{"product": "YY品牌静音红轴机械键盘", "price": 899, "reason": "静音红轴适合办公，104键满足办公需求，价格合理"}

现在请分析：
用户需求："我想买一台适合视频剪辑的笔记本电脑，预算8000元左右，需要屏幕色彩准确。"

通过这种设计，模型不仅输出了推荐结果，还展示了推理过程，便于开发者调试和校验。

4.3 角色扮演与结构化输出

角色扮演（Role Prompting）的核心原理是：通过设定角色身份，激活模型在特定领域知识上的先验分布。例如，设定“你是一个资深律师”会激活法律领域的专业术语和逻辑框架。角色扮演的关键在于角色描述的具体性和边界性：

  • 具体性：不要只说“你是专家”，要说明“你是拥有10年经验的Java架构师，擅长高并发系统设计”。
  • 边界性：明确角色的能力边界，如“你只回答与法律相关的问题，其他问题请礼貌拒绝”。

结构化输出（Structured Output）是生产级应用中最关键的技巧。大模型默认输出自由文本，但应用系统通常需要解析特定格式的数据。结构化输出的实现方法包括：

  1. JSON Schema 约束：在提示词中明确指定 JSON 的字段名、类型和必填项。
  2. 枚举值限制：对于分类字段，明确列出所有允许的枚举值。
  3. 正则表达式引导：对于特定格式（如日期、邮箱），给出正则表达式示例。
  4. 后处理兜底：在代码中增加解析失败的重试逻辑或默认值。

风险提示：即使提示词中明确要求输出 JSON，模型仍可能输出 Markdown 代码块、多余解释或格式错误的 JSON。生产环境必须使用 JSON 解析库（如 Python 的 json 模块）并捕获异常，同时设计重试机制。建议在提示词中增加“只输出JSON，不要包含任何其他文字”的强约束。

实战场景：构建一个“简历信息抽取”系统，要求从简历文本中提取候选人信息并输出结构化 JSON。提示词设计如下：

你是一个简历解析专家。请从以下简历文本中提取候选人信息，严格输出JSON格式，不要包含任何其他内容。

JSON Schema:
{
  "name": "string（必填）",
  "age": "integer（可选，无法识别时填null）",
  "phone": "string（必填，格式为11位手机号）",
  "email": "string（可选）",
  "skills": ["string"]（必填，至少1个技能）,
  "years_of_experience": "integer（必填，按整数年计算）",
  "education": {"degree": "string", "school": "string"}（必填）
}

简历文本：
"张伟，男，28岁，电话13812345678，邮箱zhangwei@email.com。毕业于北京大学计算机系，本科学历。拥有5年Java开发经验，精通Spring Boot、MySQL、Redis，熟悉分布式系统设计。曾在某互联网公司担任高级开发工程师。"

请输出JSON：

这种设计确保了输出格式的稳定性和可解析性，同时通过字段约束避免了模型自由发挥。

4.4 常见陷阱与优化方法

陷阱一：过拟合示例（Few-shot Overfitting）。当示例过于具体或数量过多时，模型可能“死记硬背”示例的模式，而忽略用户的实际输入。例如，示例中所有输入都是“手机评论”，当用户输入“电脑评论”时，模型可能仍然按照手机评论的模式输出。

优化方法：控制示例数量在3-5个，并确保示例覆盖不同的输入类型。同时，在提示词中明确“请根据实际输入内容进行分析，不要受示例限制”。

陷阱二：幻觉（Hallucination）。模型可能生成看似合理但实际错误的信息，尤其在知识密集型任务中。例如，在“产品规格查询”场景中，模型可能编造不存在的产品参数。

优化方法：在提示词中增加“如果你不确定答案，请回答‘未知’”，同时结合 RAG（检索增强生成）技术，将外部知识库内容注入上下文，减少模型“凭空想象”的概率。

陷阱三：格式漂移（Format Drift）。模型在长对话或多轮交互中，可能逐渐偏离初始设定的输出格式。例如，第一轮输出 JSON，第二轮却输出 Markdown 表格。

优化方法：在多轮对话中，每一轮都重复格式约束；或者在系统层面增加“格式校验器”，一旦检测到格式偏离，自动重试或修正。

陷阱四：上下文污染（Context Pollution）。在多轮对话中，历史消息中的无关信息可能干扰当前任务的推理。例如，用户先聊了天气，再问“帮我写一段 Python 代码”，模型可能将天气信息错误地融入代码中。

优化方法：使用滑动窗口管理上下文，只保留与当前任务相关的历史消息；或者在提示词中明确“忽略之前所有与当前任务无关的对话内容”。

陷阱类型 典型表现 检测方法 优化策略
过拟合示例 输出与示例高度相似，忽略实际输入 对比不同输入的输出差异度 减少示例数量，增加输入多样性
幻觉 输出看似合理但事实错误 人工抽检或与知识库比对 增加“不确定就回答未知”约束，引入RAG
格式漂移 输出格式逐渐偏离设定 自动化格式校验 每轮重复格式约束，增加后处理校验
上下文污染 无关历史信息干扰当前输出 检查输出中是否包含无关内容 上下文窗口裁剪，任务隔离

优化闭环案例：某金融问答系统上线后，发现模型在回答“基金收益率计算”问题时，经常输出错误的计算公式。排查过程如下：

  1. 现象收集：收集100条错误回答，发现80%的错误集中在“复利计算”场景。
  2. 原因分析：提示词中未包含复利计算公式，模型依赖训练数据中的不完整记忆。
  3. 优化方案：在提示词中增加复利计算公式的明确说明，并添加一个 Few-shot 示例。
  4. 效果验证：优化后，复利计算场景的错误率从80%降至5%。
  5. 回归测试：确保其他场景（如单利计算）的准确率未受影响。

这个案例说明，提示词优化是一个“观察→假设→实验→验证”的迭代过程，而非一次性设计。

总结复盘：提示工程的核心能力不是“背模板”，而是诊断能力——能够快速定位输出异常的原因，并针对性地调整提示词。面试中，建议准备1-2个自己实际优化过的提示词案例，展示你的分析思路和优化过程。同时，要理解提示词只是应用系统的一部分，需要与模型选型、RAG、后处理等模块协同工作，才能构建稳定可靠的大模型应用。

← 上一章 📖 返回目录 下一章 →