全部笔记All notes

Prompt 工程基础

阅读 9m 15s9m 15s read

系统提示词设计、常用技巧和最佳实践。


什么是 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 的核心。通过明确的角色定义,可以让模型”进入状态”,生成更专业、更一致的回答。

为什么角色设定有效?

模型在训练时接触了大量不同角色的文本(医生、律师、程序员等)。通过角色设定,你实际上是在激活模型中与该角色相关的知识和表达方式。

好的角色设定包含三要素:

  1. 身份:你是谁(专家、助手、翻译等)
  2. 任务:你要做什么
  3. 约束:你的行为边界

基础模板

你是一个 [角色],专长于 [领域]。
你的任务是 [目标]。
回答要求:[约束条件]

示例

你是一个资深 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,通常需要多次测试和调整。

优化流程:

  1. 写初始 Prompt
  2. 测试多个输入
  3. 分析失败案例
  4. 针对性调整
  5. 重复测试
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。

特性OpenAIClaudeGemini
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 个示例
过度约束太多限制导致模型困惑保留核心约束,删除次要的
矛盾指令“简洁但详细”明确优先级或分场景
假设太多假设模型知道背景提供必要的上下文

相关文档