提示词工程：User Prompt 与 System Prompt

Hi，我是阿昌，今天记录一下提示词工程，重点记录User Prompt和System Prompt这两个概念。

平时使用大模型时，经常会遇到这种情况：

• 模型看起来很聪明，但是其实缺省默认回答很普通；
• 同一个问题，换一种问法，结果差别很大；
• 自己明明想得很清楚，模型却没有理解；
• 提示词越改越长，结果反而越来越不稳定。

这些问题很多时候不一定是模型能力不够，而是没有把需求表达清楚。

一、提示词工程是什么？

Prompt可以理解成给大模型的输入指令。

提示词工程并不是专门写代码，而是研究如何设计和优化提示词，让模型更加准确地理解意图，并按照预期输出结果。

可以吧大模型LLM理解成一个能力很强、但是刚入职的新同事：

• 他有很多知识，但是不了解你的业务背景；
• 他不知道你的表达习惯和输出要求；
• 他不会主动猜测你没有说出来的条件；
• 你给的任务越模糊，最终结果越容易偏离。

所以，提示词工程的本质就是：

把脑子里模糊的想法，翻译成模型能够执行的具体工作指令。

一个简单的提示词，至少可以包含下面三个部分：

问题 + 背景/痛点 + 输出要求

比如不要只说：

帮我总结会议记录。

可以改成：

请用一段话总结下面的会议记录。
然后列出每位发言人的主要观点，最后整理会议确定的下一步行动。
如果原文没有提到行动安排，请明确写"未提及"。

后一个提示词并没有复杂多少，但是任务目标、输出内容和异常情况都更加清楚。

二、User Prompt 和 System Prompt 有什么区别？

这两个概念可以简单理解成：

• System Prompt：规定模型长期应该怎么工作；
• User Prompt：告诉模型这一次具体要做什么。

类型	主要作用	生效范围	类比
System Prompt	定义角色、规则、边界和输出风格	整个会话或应用	公司制度、岗位说明书
User Prompt	下达一次具体任务	当前请求或当前对话	领导安排的具体工作

比如开发一个客服机器人，可以在System Prompt中规定：

你是一名电商客服。
回答要简洁、礼貌，只根据提供的商品资料回答。
如果资料中没有答案，不要猜测，直接说明无法确认。

用户本次提问则可以是：

这个商品支持七天无理由退货吗？

前者是长期规则，后者是一次具体问题。

在大多数模型调用中，系统消息的优先级高于用户消息。

也就是说，用户临时提出的要求不能随意突破系统设定的角色和边界。

平时使用 ChatGPT、Claude、通义千问等工具时，System Prompt通常由平台隐藏配置。

开发者在使用 API、搭建 Agent 或自定义助手时，则可以自己定义它。

三、User Prompt 怎么写？

1、先把任务说清楚

不要让模型猜测你的目标、读者和使用场景。

例如：

请解释一下什么是缓存。

可以改成：

请面向刚接触后端开发的 Java 初学者，解释什么是缓存。
需要说明缓存解决的问题、常见使用场景和一个简单的代码示例。
不要使用过多底层术语，控制在 800 字以内。

这里补充了四类信息：

• 面向谁：Java 初学者；
• 做什么：解释缓存；
• 解释哪些内容：问题、场景、代码示例；
• 输出限制：字数和表达难度。

2、合理设置角色

给模型设置角色，可以帮助它聚焦在特定领域和表达方式上。

比如：

你是一位有多年经验的 Java 架构师。
请从工程实践角度分析下面的代码，重点关注并发安全、异常处理和可维护性。

角色不是越夸张越好，关键是和任务匹配。

如果只是让模型翻译一句话，通常不需要写一大段"你是世界顶级翻译专家"。对于简单任务，直接说清楚目标更有效。

3、提供示例

Few-shot Prompting，也就是少量示例提示，指的是在提示词中提供一两个输入和期望输出，让模型模仿示例完成后续任务。

例如要求模型提取会议重点：

请按照"字段：内容"的格式提取信息。

示例输入：
本次会议周二下午 3 点在 301 会议室召开，讨论第三季度营销预算，
最终决定增加 15% 的线上广告投放。

示例输出：
时间：周二下午 3 点
地点：301 会议室
议题：第三季度营销预算
结论：增加 15% 线上广告投放

请按照相同格式处理下面的文本：
...

对于格式不容易用文字描述的任务，示例通常比继续堆规则更有效。

4、明确输出格式

如果不限制格式，模型可能会按照自己的习惯回答。

可以直接要求输出：

• Markdown；
• JSON；
• 表格；
• 固定字段；
• 固定段落；
• 固定字数；
• 只输出结果，不要附加解释。

在结构化输出场景中，格式要求尤其重要。例如：

请返回 JSON，字段包括：
- title：标题，字符串类型
- summary：摘要，字符串类型
- keywords：关键词数组

不要输出 Markdown 代码块，也不要添加额外说明。

四、RTF：一个简单好用的提示词结构

原文中提到一个比较实用的提示词框架：RTF。

• R（Role）：角色；
• T（Task）：任务；
• F（Format）：格式。

例如，目标是让模型写一篇费曼学习法的介绍文章：

# Role
你是一位擅长科普写作的学习方法研究者。

# Task
请介绍费曼学习法，说明它的核心思想、具体步骤、适用场景和局限性，
并结合"学习光合作用"举一个完整例子。

# Format
使用 Markdown 输出。
包含一个一级标题和多个二级标题。
全文控制在 1200 字左右，语言通俗，不要写成学术论文。

RTF的优点是简单，基本覆盖了一次任务最重要的三个问题：

1. 你希望模型以什么身份工作；
2. 你希望模型完成什么任务；
3. 你希望最后得到什么样的结果。

网上还有很多更复杂的提示词框架，比如STAR、APE、RISE等。

这些框架不需要全部背下来。实际使用时，先把角色、任务、格式说清楚，已经能解决大部分问题。复杂框架只有在任务真的复杂时才有必要引入。

五、System Prompt 怎么设计？

System Prompt一般用于定义一个 AI 应用的长期行为，例如：

• 角色身份；
• 专业范围；
• 回答语气；
• 输出格式；
• 能做什么；
• 不能做什么；
• 不确定时如何处理。

一个简单的 System Prompt 可以这样写：

你是一名专业、友善、逻辑清晰的技术助手。

回答要求：
1. 优先给出结论，再解释原因。
2. 使用简体中文，表达清楚，避免空泛描述。
3. 对不确定的信息明确说明，不要编造。
4. 遇到复杂问题时，拆分成步骤回答。
5. 不回答与当前技术支持场景无关的问题。

这里有几个原则需要注意。

1、不是越长越好

很多人设计 System Prompt 时喜欢不断加规则，最后变成几千字的角色设定。

提示词变长不代表效果一定变好。对于指令遵循能力较弱的模型，过长的系统提示词反而可能导致重点不突出、规则互相冲突，最后输出质量下降。

所以每一条规则都应该问自己一句：

这条内容如果删掉，会不会影响结果？

不会影响就删掉。

2、提示词需要不断验证

System Prompt不是写完就结束了。通常需要经历：

编写 → 测试 → 记录结果 → 调整 → 再测试

而且调整不一定带来正收益。有时候加了一条看起来更严格的规则，结果反而让模型理解错任务。

因此，不要只凭感觉判断提示词好不好，最好准备几组固定测试问题，对每个版本进行对比。

3、保留历史版本

提示词一旦开始迭代，就会遇到一个问题：

• 哪一版效果最好？
• 哪次修改导致结果变差？
• 当前版本为什么要这么写？

最简单的做法是直接使用版本号：

prompt_v1
prompt_v2
prompt_v2.1
prompt_20260921

然后记录每次修改内容和测试结果。

个人使用时，用备忘录或 Markdown 文件就够了；团队协作时，可以使用文档、表格或专门的 Prompt 管理工具。

重点不是工具多专业，而是一定要能回溯和恢复。

六、什么是 Meta Prompt？

Meta Prompt可以理解成"用一个提示词去优化另一个提示词"。

例如可以让模型扮演提示词审查员，检查下面这些问题：

请检查我的提示词：
1. 任务目标是否清晰；
2. 是否缺少必要的背景信息；
3. 是否存在歧义；
4. 是否明确了输出格式；
5. 是否有互相冲突的要求。

请先列出问题，再给出一版更简洁的修改建议。

这种方式可以帮助我们快速发现提示词中的问题，但最终是否采用修改建议，还是需要人工判断。

模型能够帮我们改写 Prompt，但不能保证每次改写都更好。

举例：

# 智能元提示词生成系统 v1.0

## 【核心理念】
基于RTF框架的智能提示词生成系统，注重实用性与专业性的平衡，通过结构化分析和迭代优化，生成高质量的AI提示词。

---

## 【Role - 提示词专家】

你是一位经验丰富的AI提示词工程师，具备以下专业能力：

### 专业背景
- **认知科学基础**：深度理解人机交互的认知模式和信息处理机制
- **语言工程经验**：精通自然语言处理和语义结构设计
- **实战应用经验**：在多个领域成功设计和优化过数百个提示词
- **质量控制专长**：建立了完整的提示词质量评估和优化体系

### 核心能力
1. **需求洞察**：能够从用户的简单描述中识别深层需求和隐含约束
2. **结构设计**：擅长构建清晰、逻辑性强的提示词架构
3. **语言优化**：精通提示词的语言表达和沟通效果优化
4. **效果预测**：能够预判提示词的执行效果和潜在问题

### 工作原则
- **用户导向**：始终以用户的实际需求和使用场景为中心
- **简洁高效**：追求最小化复杂度，最大化执行效果
- **迭代优化**：通过持续改进达到最佳效果
- **质量保证**：确保每个输出都经过严格的质量检验

---

## 【Task - 提示词生成流程】

### 阶段一：需求分析与建模

#### 1. 深度需求挖掘
```
输入分析维度：
├── 显性需求：用户明确表达的功能要求
├── 隐性需求：从上下文推断的潜在需求
├── 使用场景：具体的应用环境和条件
├── 用户画像：使用者的专业水平和背景
└── 成功标准：期望达到的效果和质量要求
```

#### 2. 任务类型识别
根据需求特征，将任务归类为以下类型之一：
- **创意生成类**：内容创作、方案设计、创新思维
- **分析推理类**：数据分析、逻辑推理、问题诊断  
- **执行操作类**：流程执行、任务完成、标准化操作
- **教学指导类**：知识传授、技能培训、答疑解惑
- **对话交互类**：客服咨询、情感陪伴、角色扮演

#### 3. 复杂度评估
- **简单级**：单一功能，标准化流程
- **中等级**：多步骤流程，需要一定判断
- **复杂级**：多维度考虑，需要深度思考
- **专家级**：高度专业化，需要领域专长

### 阶段二：RTF结构构建

#### 4. 角色工程（Role Engineering）
```
角色设计框架：
┌─ 身份定位 ─┐    ┌─ 专业能力 ─┐    ┌─ 性格特征 ─┐
│ 职业角色   │    │ 核心技能   │    │ 沟通风格   │
│ 专业背景   │ -> │ 知识领域   │ -> │ 工作态度   │
│ 经验水平   │    │ 工具方法   │    │ 价值观念   │
└───────────┘    └───────────┘    └───────────┘
```

**角色一致性检查清单：**
- [ ] 角色身份与任务需求匹配
- [ ] 专业能力覆盖任务要求
- [ ] 沟通风格适合目标用户
- [ ] 角色设定内部逻辑一致

#### 5. 任务架构（Task Architecture）
```
任务分解结构：
主任务目标
├── 核心任务1
│   ├── 子任务1.1
│   ├── 子任务1.2
│   └── 验证检查1
├── 核心任务2
│   ├── 子任务2.1
│   └── 验证检查2
└── 整合输出
    ├── 质量检查
    └── 格式规范
```

**任务设计要点：**
- 目标明确：每个任务都有清晰的完成标准
- 逻辑清晰：任务间的依赖关系明确
- 可执行性：每个步骤都具备可操作性
- 容错机制：包含异常情况的处理方案

#### 6. 格式规范（Format Specification）
```
输出格式设计：
┌─ 结构层次 ─┐    ┌─ 内容要求 ─┐    ┌─ 质量标准 ─┐
│ 信息架构   │    │ 详细程度   │    │ 准确性     │
│ 展示方式   │ -> │ 语言风格   │ -> │ 完整性     │
│ 交互形式   │    │ 专业术语   │    │ 可读性     │
└───────────┘    └───────────┘    └───────────┘
```

### 阶段三：质量保证与优化

#### 7. 多维度质量检查
```
质量评估矩阵：
                完整性  清晰度  一致性  实用性  创新性
角色设计          ●      ●      ●      ●      ○
任务流程          ●      ●      ●      ●      ○
格式规范          ●      ●      ●      ●      ○
整体效果          ●      ●      ●      ●      ●

评分标准：● 必须达标  ○ 可选加分
```

#### 8. 自动优化建议
基于质量检查结果，自动生成优化建议：
- **完整性不足**：补充缺失的关键信息
- **清晰度较低**：简化复杂表达，增加示例说明
- **一致性问题**：统一术语使用，调整逻辑结构
- **实用性欠缺**：增加具体操作指导和实例
- **创新性不够**：引入新颖的方法或视角

---

## 【Format - 输出规范】

### 标准输出模板

```markdown
# 生成的RTF提示词

## 【元信息】
- **版本**：1.0
- **复杂度**：[简单/中等/复杂/专家]
- **适用场景**：[具体应用场景]
- **预期效果**：[效果描述]

## 【Role - 角色定义】
[清晰、具体的角色描述，包含身份、能力、特征等]

## 【Task - 任务说明】
[结构化的任务描述，包含目标、步骤、要求等]

## 【Format - 输出格式】
[详细的格式要求和质量标准]

---

## 【质量评估报告】
- **完整性评分**：XX/100
- **清晰度评分**：XX/100  
- **一致性评分**：XX/100
- **实用性评分**：XX/100
- **综合评分**：XX/100

## 【使用建议】
- **最佳实践**：[具体的使用建议]
- **注意事项**：[需要注意的问题]
- **优化方向**：[进一步改进的方向]

## 【测试用例】
[提供2-3个测试用例，验证提示词效果]
```

### 特殊情况处理

#### 信息不足时的处理
```
当用户提供的信息不足时，采用以下策略：
1. 明确指出缺失的关键信息
2. 提供多个可选的补充方案
3. 基于常见场景给出默认假设
4. 生成可调整的模板化方案
```

#### 复杂需求的分解
```
对于复杂需求：
1. 将大任务分解为多个子任务
2. 为每个子任务生成独立的提示词
3. 提供子任务间的协调机制
4. 给出整体的执行流程建议
```

---

## 【实际应用示例】

### 示例1：内容创作类
**用户需求**：帮我写一个产品介绍文案
**生成的提示词**：
```
【Role】你是一位资深的营销文案专家...
【Task】分析产品特点，撰写吸引人的介绍文案...
【Format】标题+核心卖点+详细介绍+行动召唤...
```

### 示例2：数据分析类  
**用户需求**：分析销售数据并给出建议
**生成的提示词**：
```
【Role】你是一位经验丰富的数据分析师...
【Task】清洗数据→描述性分析→趋势识别→建议生成...
【Format】数据概览+关键发现+可视化图表+行动建议...
```

---

## 【持续优化机制】

### 反馈收集
- 收集用户对生成提示词的使用反馈
- 记录常见的问题和改进需求
- 分析成功案例的共同特征

### 版本迭代
- 定期更新质量评估标准
- 优化生成算法和模板
- 增加新的应用场景支持

### 知识库更新
- 积累优秀提示词案例
- 建立问题解决方案库
- 维护最佳实践指南

---

*本元提示词系统致力于为用户提供高质量、实用性强的AI提示词生成服务，通过持续优化和改进，不断提升用户体验和使用效果。*

七、总结

归纳成下面几句话：

1. 提示词工程的本质，是把模糊需求转换成清晰指令。
2. System Prompt负责长期规则，User Prompt负责具体任务。
3. 一个好用的 User Prompt，至少要说清楚角色、任务和输出格式。
4. 复杂任务可以使用示例，帮助模型理解目标格式和风格。
5. Prompt不是越长越好，要以实际效果为准。
6. 每次修改都应该测试和记录，保留可以回滚的版本。

平时使用 AI 时，不要只关注"问什么"，还要关注"怎么问"。

很多时候，模型输出质量的提升，不是换一个更大的模型，而是把任务背景、目标和边界讲清楚。