系统提示词设计、常用技巧和最佳实践。
什么是 Prompt 工程?
Prompt 工程是设计和优化输入提示词的技术,目的是引导大模型生成更准确、更符合预期的输出。
好的 Prompt 可以:
- 提高回答的准确性和相关性
- 控制输出的格式和风格
- 减少幻觉和错误信息
- 降低 Token 消耗和成本
Prompt 工程不是玄学,而是有章可循的技术。核心原则是:清晰、具体、有示例。
为什么 Prompt 工程如此重要?
大语言模型本质上是”预测下一个 Token”的系统。它的输出完全取决于输入。同样的问题,不同的问法可能得到截然不同的答案。Prompt 工程就是研究如何”问对问题”的学问。
Prompt 工程的核心原则:
| 原则 | 说明 | 示例 |
|---|---|---|
| 清晰 | 避免歧义,明确表达意图 | “总结这篇文章” → “用 3 个要点总结这篇文章的核心观点” |
| 具体 | 提供足够的细节和约束 | “写一首诗” → “写一首关于春天的五言绝句” |
| 有示例 | 用例子展示期望的输出 | 提供 2-3 个输入输出示例 |
| 结构化 | 使用清晰的格式组织信息 | 使用标题、列表、分隔符 |
Prompt 结构
一个完整的 Prompt 通常包含以下几个部分,不是每个部分都必需,根据任务复杂度选择:
flowchart TB
subgraph Prompt
A[System 系统指令]
B[Context 上下文]
C[Examples 示例]
D[Task 任务]
E[Format 格式要求]
end
A --> B --> C --> D --> E各部分详解:
| 部分 | 作用 | 是否必需 |
|---|---|---|
| System | 定义 AI 的角色、能力、限制 | 推荐 |
| Context | 提供背景信息、相关知识 | 视情况 |
| Examples | 展示期望的输入输出格式 | 推荐 |
| Task | 明确当前要完成的任务 | 必需 |
| Format | 指定输出的格式要求 | 推荐 |
角色设定
角色设定是 System Prompt 的核心。通过明确的角色定义,可以让模型”进入状态”,生成更专业、更一致的回答。
为什么角色设定有效?
模型在训练时接触了大量不同角色的文本(医生、律师、程序员等)。通过角色设定,你实际上是在激活模型中与该角色相关的知识和表达方式。
好的角色设定包含三要素:
- 身份:你是谁(专家、助手、翻译等)
- 任务:你要做什么
- 约束:你的行为边界
基础模板
你是一个 [角色],专长于 [领域]。
你的任务是 [目标]。
回答要求:[约束条件]
示例
你是一个资深 Python 开发者。
你的任务是审查代码并提出改进建议。
回答要求:简洁、给出代码示例、指出潜在问题。
角色设定的常见模式:
| 模式 | 示例 | 适用场景 |
|---|---|---|
| 专家型 | “你是一位有 20 年经验的心脏外科医生” | 专业咨询 |
| 助手型 | “你是一个友好的客服助手” | 日常对话 |
| 角色扮演 | “你是福尔摩斯,用他的方式分析问题” | 创意写作 |
| 工具型 | “你是一个 JSON 格式转换器” | 数据处理 |
常用技巧
以下是经过验证的 Prompt 技巧,可以显著提升模型输出质量。
1. Few-shot(少样本)
通过提供几个示例,让模型理解你期望的输入输出格式。这是最有效的技巧之一,特别适合格式化输出、分类任务。
为什么 Few-shot 有效?
模型会从示例中学习模式,包括:
- 输入输出的对应关系
- 输出的格式和风格
- 任务的边界和约束
示例数量建议:2-5 个,太少可能不够,太多会浪费 Token。
flowchart LR
A[示例1] --> B[示例2] --> C[实际问题]
style A fill:#e1f5fe
style B fill:#e1f5fe
style C fill:#fff3e0将英文翻译成中文:
English: Hello
中文: 你好
English: Thank you
中文: 谢谢
English: Good morning
中文:
Few-shot 最佳实践:
| 建议 | 说明 |
|---|---|
| 示例要有代表性 | 覆盖常见情况和边界情况 |
| 格式要一致 | 所有示例使用相同的格式 |
| 难度要递进 | 从简单到复杂 |
| 避免误导 | 示例必须正确,错误示例会误导模型 |
2. Chain of Thought(思维链)
让模型”展示思考过程”,而不是直接给出答案。这对于数学计算、逻辑推理、复杂分析特别有效。
为什么 CoT 有效?
原理:强制模型分步骤思考,减少跳跃式推理带来的错误。当模型需要”写出”中间步骤时,它实际上在进行更深入的推理。
flowchart LR
A[问题] --> B[步骤1] --> C[步骤2] --> D[步骤3] --> E[答案]触发词:
- “让我们一步步思考”
- “Let’s think step by step”
- “请详细说明你的推理过程”
- “首先…然后…最后…”
CoT 示例对比:
# 不使用 CoT
问:小明有 5 个苹果,给了小红 2 个,又买了 3 个,现在有几个?
答:6 个
# 使用 CoT
问:小明有 5 个苹果,给了小红 2 个,又买了 3 个,现在有几个?请一步步思考。
答:
1. 小明最初有 5 个苹果
2. 给了小红 2 个后:5 - 2 = 3 个
3. 又买了 3 个后:3 + 3 = 6 个
所以小明现在有 6 个苹果。
3. 输出格式控制
明确指定输出格式可以让结果更易于程序解析。模型对格式指令的遵循度很高,但建议配合示例使用。
| 方法 | 示例 |
|---|---|
| JSON | 请以 JSON 格式输出 |
| 列表 | 请用编号列表回答 |
| 表格 | 请用 Markdown 表格展示 |
| 代码 | 只输出代码,不要解释 |
格式控制技巧:
# 强制 JSON 输出
请分析以下文本的情感,以 JSON 格式输出:
{
"sentiment": "positive/negative/neutral",
"confidence": 0.0-1.0,
"keywords": ["关键词1", "关键词2"]
}
文本:这个产品太棒了!
注意事项:
- 使用 JSON Mode(
response_format: {"type": "json_object"})可以保证输出有效 JSON - 复杂格式建议提供完整示例
- 避免过于复杂的嵌套结构
System Prompt 设计
System Prompt 是整个对话的”宪法”,定义了 AI 的行为准则。好的 System Prompt 应该结构清晰、职责明确。
结构化模板
# 角色
你是...
# 能力
- 能力1
- 能力2
# 限制
- 不要...
- 避免...
# 输出格式
使用...格式回复
提示词优化
Prompt 工程是一个迭代过程。很少有人能一次写出完美的 Prompt,通常需要多次测试和调整。
优化流程:
- 写初始 Prompt
- 测试多个输入
- 分析失败案例
- 针对性调整
- 重复测试
flowchart TD
A[初始 Prompt] --> B[测试]
B --> C{效果好?}
C -->|否| D[分析问题]
D --> E[调整 Prompt]
E --> B
C -->|是| F[固化使用]常见问题与解决
| 问题 | 解决方案 |
|---|---|
| 回答太长 | 添加”简洁回答”、限制字数 |
| 格式不对 | 给出格式示例 |
| 理解偏差 | 增加上下文、给示例 |
| 拒绝回答 | 调整措辞、说明用途 |
高级技巧
Self-Consistency(自洽性)
对同一问题多次采样,选择出现最多的答案。适合有明确答案的任务(数学、选择题)。
flowchart TD
A[问题] --> B[采样1]
A --> C[采样2]
A --> D[采样3]
B --> E[答案A]
C --> F[答案A]
D --> G[答案B]
E & F & G --> H[投票: A获胜]Tree of Thoughts(思维树)
让模型探索多条推理路径,评估每条路径的可行性,选择最优解。适合复杂规划、创意任务。
flowchart TD
A[问题] --> B[方案1]
A --> C[方案2]
A --> D[方案3]
B --> E[评估: 7分]
C --> F[评估: 9分]
D --> G[评估: 5分]
F --> H[选择方案2]请用思维树方法解决这个问题:
1. 列出 3 种可能的方案
2. 评估每种方案的优缺点
3. 选择最佳方案并详细说明
问题:如何提高团队的代码质量?
ReAct(推理+行动)
结合推理和行动,让模型在思考和执行之间交替。这是 Agent 的核心模式。
你可以使用以下工具:
- search(query): 搜索信息
- calculate(expression): 计算数学表达式
请按以下格式回答:
Thought: 我需要思考...
Action: search("关键词")
Observation: 搜索结果...
Thought: 根据结果,我认为...
Answer: 最终答案
反面示例(负面提示)
告诉模型”不要做什么”,有时比”要做什么”更有效。人类也是如此——知道什么是错的,往往比知道什么是对的更容易。
你是一个代码审查助手。
不要:
- 不要只说"代码看起来不错"
- 不要忽略潜在的安全问题
- 不要给出模糊的建议
要:
- 指出具体的问题行号
- 给出修改后的代码示例
- 解释为什么这样改更好
分解复杂任务
将复杂任务分解为多个简单步骤,逐步完成。
任务:写一篇关于人工智能的博客文章
请按以下步骤完成:
1. 首先,列出文章大纲(3-5 个主要部分)
2. 然后,为每个部分写 2-3 句话的摘要
3. 接着,扩展第一部分的内容
4. 继续扩展其他部分
5. 最后,写引言和结论
各厂商差异
不同模型对 Prompt 的响应有所不同,了解这些差异可以帮助你写出更好的 Prompt。
| 特性 | OpenAI | Claude | Gemini |
|---|---|---|---|
| System 位置 | messages 中 | 顶层参数 | systemInstruction |
| 最佳长度 | 中等 | 可以很长 | 中等 |
| 格式遵循 | 好 | 很好 | 好 |
| 拒绝倾向 | 中 | 较高 | 低 |
| 长文本处理 | 好 | 很好 | 很好 |
| 代码能力 | 很好 | 很好 | 好 |
针对不同模型的建议:
| 模型 | 建议 |
|---|---|
| GPT-4 | 可以使用复杂指令,理解力强 |
| GPT-3.5 | 指令要更明确,多给示例 |
| Claude | 可以给很长的上下文,擅长分析 |
| Gemini | 多模态任务表现好 |
实用模板
以下是经过验证的实用模板,可以直接使用或根据需要修改。
代码审查
你是一位资深代码审查专家。请审查以下代码:
## 审查维度
1. **正确性**:是否有 bug 或逻辑错误
2. **安全性**:是否有安全漏洞
3. **性能**:是否有性能问题
4. **可读性**:代码是否清晰易懂
5. **最佳实践**:是否遵循语言/框架的最佳实践
## 输出格式
- 问题列表(按严重程度排序)
- 改进建议
- 代码质量评分(1-10分)
## 代码
```{language}
{code}
```
文档生成
为以下函数生成专业的文档注释。
## 要求
- 使用 {docstring_style} 风格(如 Google、NumPy、Sphinx)
- 包含功能描述
- 参数说明(类型、含义、默认值)
- 返回值说明
- 异常说明(如果有)
- 使用示例
## 函数
```{language}
{function}
```
数据提取
从以下文本中提取结构化信息。
## 输出格式
```json
{
"name": "姓名",
"date": "日期(YYYY-MM-DD 格式)",
"amount": "金额(数字)",
"currency": "货币单位"
}
```
## 规则
- 如果信息不存在,使用 null
- 日期统一转换为 YYYY-MM-DD 格式
- 金额只保留数字
## 文本
{text}
翻译
你是一位专业翻译,精通中英双语。
## 任务
将以下{source_lang}文本翻译成{target_lang}。
## 要求
- 保持原文的语气和风格
- 专业术语使用标准译法
- 如有多种译法,选择最自然的表达
- 保留原文的格式(如列表、标题)
## 原文
{text}
摘要生成
请为以下文章生成摘要。
## 要求
- 长度:{length}字以内
- 包含文章的核心观点
- 保持客观,不添加个人观点
- 使用简洁的语言
## 文章
{article}
问答助手
你是一个专业的{domain}领域助手。
## 你的职责
- 回答用户关于{domain}的问题
- 提供准确、有帮助的信息
- 如果不确定,诚实地说"我不确定"
## 回答风格
- 简洁明了
- 使用通俗易懂的语言
- 必要时给出示例
- 复杂问题分步骤解答
## 限制
- 不提供{prohibited_topics}相关建议
- 不编造信息
- 超出能力范围时建议咨询专业人士
Prompt 调试技巧
1. 使用分隔符
清晰分隔不同部分,避免混淆:
### 指令 ###
{instructions}
### 输入 ###
{input}
### 输出 ###
2. 明确输出起始
告诉模型从哪里开始输出:
请分析以下文本的情感。
文本:{text}
分析结果:
3. 使用 XML 标签
Claude 特别擅长处理 XML 标签:
<instructions>
分析以下文档
</instructions>
<document>
{document}
</document>
<output_format>
JSON
</output_format>
4. 迭代优化记录
记录每次修改和效果:
| 版本 | 修改内容 | 效果 |
|---|---|---|
| v1 | 初始版本 | 格式不稳定 |
| v2 | 添加格式示例 | 格式改善 |
| v3 | 添加负面示例 | 避免了常见错误 |
常见错误
| 错误 | 问题 | 改进 |
|---|---|---|
| 指令模糊 | “写得好一点” | “使用专业术语,每段不超过100字” |
| 缺少示例 | 期望特定格式但不给示例 | 提供 2-3 个示例 |
| 过度约束 | 太多限制导致模型困惑 | 保留核心约束,删除次要的 |
| 矛盾指令 | “简洁但详细” | 明确优先级或分场景 |
| 假设太多 | 假设模型知道背景 | 提供必要的上下文 |