提示词工程完全指南：从入门到精通

提示词工程（Prompt Engineering）是与大语言模型对话的核心技艺。本指南系统梳理从基础概念、核心原则、常用技术到实战调优的完整方法论，帮你写出"听得懂、做得到、可复用"的提示词。

目录

  1. 什么是提示词工程
  2. 提示词的基本元素
  3. 七大核心原则
  4. 常用提示词技术
  5. 结构化提示词模板
  6. 不同任务类型的写法
  7. 常见陷阱与避坑指南
  8. 迭代与评估方法
  9. 进阶：让模型"自我进化"
  10. 实战示例集
  11. 速查清单

1. 什么是提示词工程

提示词工程是通过设计与优化输入文本，引导大语言模型（LLM）输出符合预期结果的工程实践。它不是"咒语"或"玄学"，而是一套可学习、可度量、可复用的方法体系。

为什么重要

  • 杠杆最大：一行提示词的改动，常常比微调模型带来更显著的效果提升。
  • 成本最低：相比训练/微调，提示词迭代几乎零成本。
  • 可控性最强：明确指令 > 模糊表达 > 模型"猜测"。

它解决什么问题

问题 提示词工程的解法
模型回答跑题 明确角色、范围与边界
输出格式混乱 指定结构（JSON / Markdown / 表格）
推理错误或跳步 引导链式思考（CoT）
风格不一致 给出示例（Few-shot）
答案发散 限制候选、设置温度与拒绝策略

2. 提示词的基本元素

一条完整的提示词通常包含：

  1. 角色（Role）：你希望模型扮演谁。
  2. 任务（Task）：要做什么。
  3. 上下文（Context）：背景信息、受众、约束。
  4. 输入（Input）：用户提供的内容。
  5. 输出格式（Output Format）：结构、长度、风格。
  6. 示例（Examples）：1~5 个高质量示例。
  7. 约束与兜底（Constraints）：禁止事项、不知道时怎么办。
  8. 推理要求（Reasoning）：要不要先推理再回答。

不是每个提示词都要全部具备，但要"按需取用"。

3. 七大核心原则

这些原则按"性价比"排序，越靠前越应优先用上。

原则 1：清晰明确（Clarity）

  • 不好的写法：写一个关于猫的故事。
  • 更好的写法：写一个 300 字、第一人称、温情风格的短故事，主角是一只流浪的橘猫，主题是"回家"。

技巧：

  • 用具体名词替代抽象词（"温情风格" → "海明威式简洁、温暖结尾"）。
  • 给出可衡量的标准（字数、读者年龄、字数范围）。

原则 2：赋予角色（Role Prompting）

给模型一个"专家人设"，可以显著提升回答质量与稳定性。

你是一名有 10 年经验的高级 Python 后端工程师，擅长代码审查和性能优化。
请从可读性、性能、潜在 bug 三个维度审查下面的代码……

原则 3：分解任务（Task Decomposition）

复杂任务拆成"流水线"，每一步只做一件事。

步骤 1：从用户输入中提取关键实体。
步骤 2：将实体映射到数据库表字段。
步骤 3：生成 SQL 语句。
步骤 4：检查 SQL 语法并给出执行计划建议。

原则 4：提供示例（Few-shot）

示例是最强的"格式与边界说明"。一条好示例胜过十句解释。

将输入转换为 JSON：
示例 1：
输入：姓张名三，22 岁，来自北京。
输出：{"name": "张三", "age": 22, "city": "北京"}

示例 2：
输入：姓李名四，30 岁，住在上海。
输出：{"name": "李四", "age": 30, "city": "上海"}

现在请处理：
输入：……

原则 5：约束格式（Format Constraints）

明确输出结构，可以直接对接下游系统。

严格按以下 JSON Schema 输出，不要任何额外文字：
{
  "summary": "string, 50 字以内",
  "tags": ["string"],
  "score": "number, 0-10"
}

原则 6：要求推理（Reasoning Elicitation）

在需要严谨的场景，要求模型"先思考再回答"。

请一步一步推理：先列出已知条件，再推导结论，最后再下最终判断。

原则 7：自我校验（Self-Verification）

让模型检查自己的输出，是高级用户的常用技巧。

在给出最终答案之前，请：
1. 检查是否回答了用户的全部问题；
2. 检查事实是否准确；
3. 检查格式是否符合要求。
若发现问题，请重新作答。

4. 常用提示词技术

4.1 Zero-shot（零样本）

不提供示例，直接让模型完成任务。适合简单、模型已擅长的任务。

将下面这句话翻译成英文：今天天气真好。

4.2 Few-shot（少样本）

提供 1～5 个示例，提升模型对格式/风格的把控。示例质量 > 示例数量。

4.3 Chain-of-Thought（CoT，链式思考）

引导模型"一步一步想"，显著提升推理、计算、逻辑题表现。

小明有 5 个苹果，吃了 2 个，又买了 3 倍的数量。
最后他有几个苹果？请一步步推理。

4.4 ReAct（推理 + 行动）

让模型在"思考-行动-观察"循环中执行任务，常用于 Agent。

可用工具：
- search(query): 搜索互联网
- calc(expression): 计算表达式

任务：特斯拉 CEO 最新净资产是多少美元？

思考 1：我需要先查到他的净资产数字。
行动 1：search("Elon Musk net worth 2026")
观察 1：……

4.5 Self-Consistency（自一致性）

对同一问题采样多次答案，取多数投票或最一致结果，提升稳定性。

4.6 Prompt Chaining（提示词链）

把多步任务拆成多个提示词，前一步输出作为下一步输入。

提示词 A：抽取实体  →  提示词 B：情感分析  →  提示词 C：生成摘要

4.7 Retrieval-Augmented Prompting（RAG 提示）

把检索到的外部知识拼到提示词中，让模型"基于给定材料回答"，减少幻觉。

【参考资料】
{检索到的相关文档片段}

【问题】
基于以上资料，回答：……

要求：
- 只基于资料中的事实作答；
- 如果资料没有答案，请直接说"资料不足以回答"。

4.8 Tree of Thought（思维树）

让模型同时探索多条推理路径，挑选最优解。

4.9 Reflection（反思）

让模型对自己的输出做批评与改进，是当前最强的"质量提升器"之一。

请先生成答案 A，再以严格的审校专家身份指出 A 中的 3 个问题，
最后基于反思重写为答案 B。

5. 结构化提示词模板

下面这套模板覆盖了 90% 场景，可直接复用。

# 角色
你是一名 [具体角色]，擅长 [专业领域]。

# 任务
[用一句话说清楚要做什么]

# 上下文
- 用户背景：[……]
- 业务背景：[……]
- 已知信息：[……]

# 输入
[用户提供的内容]

# 输出要求
- 格式：[Markdown / 表格 / JSON]
- 长度：[字数 / 条数]
- 受众：[……]
- 语气：[专业 / 口语 / 幽默]

# 约束
- 必须：[……]
- 禁止：[……]
- 如无法回答：[兜底策略]

# 示例（可选）
输入：……
输出：……

# 推理步骤（可选）
1. …
2. …

6. 不同任务类型的写法

6.1 文本生成

要点：角色 + 受众 + 长度 + 风格 + 明确主题。

6.2 信息抽取

要点：定义字段 + Schema + 严格 JSON 输出 + 缺失值兜底。

6.3 文本分类

要点：标签集封闭 + 类别互斥 + 给出"边界示例"。

6.4 问答 / RAG

要点：参考资料 + "基于资料"约束 + 不知道就说不知道。

6.5 代码生成

要点：语言 + 框架 + 输入输出示例 + 边界条件 + 注释要求。

6.6 翻译

要点：源语言 + 目标语言 + 风格 + 术语表 + 直译/意译偏好。

6.7 摘要

要点：长度比例 + 保留要点 + 输出结构（标题/要点/数字）。

6.8 角色扮演

要点：人设 + 语气 + 背景知识边界 + 不越权。

7. 常见陷阱与避坑指南

陷阱 现象 解决
指令模糊 输出跑题 用具体名词 + 可量化标准
过度限制 输出僵化 区分硬约束 vs 软约束
示例冲突 输出摇摆 示例风格保持一致
缺少兜底 模型硬编 明确"如果不知道，请说……"
上下文溢出 模型忽略前文 把关键信息放在最前/最后
提示词过长 边际收益下降 用结构化分块 + 引用
一味要求 CoT 简单题变慢 简单任务不必"一步一步"
没有示例 风格不稳 关键场景给"金标准"示例

8. 迭代与评估方法

8.1 黄金法则：像产品经理一样迭代

  1. 明确目标：什么叫"好"？定 3-5 条可衡量的标准。
  2. 准备测试集：准备 10-50 条覆盖典型/边界/对抗样本。
  3. 跑 baseline：用当前提示词跑测试集，记录得分。
  4. 定位问题：按失败样本分类（格式/事实/风格）。
  5. 改一条：一次只改一个变量，对比结果。
  6. 回归：确保不破坏之前通过的样本。

8.2 A/B 测试

同一任务，准备 2-3 个提示词版本，随机采样，对比评估。

8.3 LLM-as-Judge

用一个更强的模型当裁判，对输出打分。提示词：

你是严格的评审员，根据以下标准给答案打分（1-10）：
- 准确性（5 分）
- 完整性（3 分）
- 格式（2 分）

请只输出：{"score": <int>, "reason": "<一句话原因>"}

9. 进阶：让模型"自我进化"

9.1 自动优化器（如 DSPy、TextGrad）

把提示词当作可学习的参数，用算法自动搜索最佳组合。

9.2 元提示（Meta-Prompt）

让模型帮你优化提示词本身：

我有一个任务：[任务描述]
我现在的提示词是：[当前提示词]
我的测试样本是：[样本]
模型当前输出：[输出]
我期望的输出：[期望]

请你作为提示词工程专家，重写我的提示词，让模型输出更接近期望。
只输出新的提示词。

9.3 多智能体协作

把任务拆给不同角色的 Agent，互相校验。例如：

  • 生成 Agent → 写初稿
  • 评审 Agent → 找问题
  • 修正 Agent → 重写
  • 仲裁 Agent → 决定是否通过

10. 实战示例集

10.1 代码审查助手

# 角色
你是一名资深 Java 工程师，专注于代码审查与性能优化。

# 任务
审查用户提交的代码，从以下维度给出建议：
- 正确性
- 可读性
- 性能
- 安全性
- 可测试性

# 输出格式
使用 Markdown，每个维度一个二级标题。
对每个问题，给出：问题描述 + 严重程度（高/中/低）+ 改进建议 + 改进后代码。

# 约束
- 不要复述代码原文。
- 如无问题，请明确说"无明显问题"。

10.2 客服工单分类

# 角色
你是电商客服主管，负责将用户工单分类并评估紧急程度。

# 标签集（必须从中选择，不可新增）
- 类别：物流、售后、退款、商品咨询、活动、其他
- 紧急度：低、中、高、紧急

# 输出格式（严格 JSON）
{
  "category": "string",
  "urgency": "string",
  "reason": "string, 30 字内"
}

# 输入
{{ticket_text}}

# 决策步骤
1. 提取用户核心诉求；
2. 匹配最贴近的类别；
3. 根据关键词（投诉/法律/立即等）评估"紧急度"；
4. 给出 JSON 输出。

10.3 营销文案改写

# 角色
你是一名擅长小红书风格的文案撰稿人。

# 任务
将用户提供的"卖点列表"改写成 3 条小红书爆款文案。

# 要求
- 风格：亲切、有 emoji、有"干货"价值感；
- 长度：每条 80-120 字；
- 开头必须有"钩子"；
- 结尾必须带"互动引导"。

# 示例
卖点：无线耳机，30 小时续航。
文案：🎧 通勤党狂喜！这个耳机续航真的离谱……快来评论区告诉我你的通勤神器！

# 输入
{{bullet_points}}

11. 速查清单

写提示词前，问这 10 个问题：

  1. 我是否给出了明确的角色？
  2. 我是否给出了可量化的任务？
  3. 我是否提供了必要的上下文？
  4. 我是否说明了输出格式？
  5. 我是否给出了示例（如适用）？
  6. 我是否说明了禁止事项与兜底策略？
  7. 我是否要求模型先推理（如适用）？
  8. 我是否考虑边界/对抗样本？
  9. 我是否能离线评估效果？
  10. 我是否能版本化提示词？