Prompt 工程不是”写提示词”，而是与模型有效沟通的艺术。好的 Prompt 能让模型输出质量提升 10 倍，差的 Prompt 让再强的模型也束手无策。
本文将通过大量实战案例，带你掌握 Prompt 工程的核心技巧。
一、Prompt 基础结构
一个高质量的 Prompt 通常包含以下要素：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| ┌─────────────────────────────────────────┐
│ 1. 角色设定 (Role) │
│ "你是一位资深 Python 开发者..." │
├─────────────────────────────────────────┤
│ 2. 任务描述 (Task) │
│ "请帮我优化这段代码..." │
├─────────────────────────────────────────┤
│ 3. 上下文/输入 (Context/Input) │
│ "以下是需要优化的代码：..." │
├─────────────────────────────────────────┤
│ 4. 约束条件 (Constraints) │
│ "保持原有功能，时间复杂度 O(n)..." │
├─────────────────────────────────────────┤
│ 5. 输出格式 (Output Format) │
│ "请用 Markdown 格式输出，包含..." │
└─────────────────────────────────────────┘
|
二、核心技巧
2.1 角色设定（Role Prompting）
原理：给模型一个明确的角色，激活相关知识和表达方式。
| 角色 |
适用场景 |
| 资深开发者 |
代码审查、架构设计 |
| 产品经理 |
需求分析、用户故事 |
| 数据分析师 |
数据解读、可视化建议 |
| 教师 |
知识讲解、概念类比 |
示例：
1
2
3
4
5
6
7
8
9
10
| # ❌ 差的 Prompt
帮我解释一下 Transformer 架构。
# ✅ 好的 Prompt
你是一位 AI 领域的资深教师，擅长用通俗易懂的类比解释复杂概念。
请向一名有编程基础但没学过深度学习的学生解释 Transformer 架构。
要求：
1. 用生活中的类比说明核心概念
2. 避免过多数学公式
3. 重点说明为什么 Transformer 比 RNN 更适合处理长文本
|
2.2 思维链（Chain of Thought）
原理：让模型展示推理过程，而不是直接给答案。
示例：
1
2
3
4
5
6
7
8
9
10
11
12
13
| # ❌ 差的 Prompt
计算：(15 + 27) × 3 - 89 ÷ 7 = ?
# ✅ 好的 Prompt
请逐步计算以下表达式，展示每一步的中间结果：
(15 + 27) × 3 - 89 ÷ 7
思考步骤：
1. 先计算括号内的加法
2. 再计算乘法
3. 然后计算除法
4. 最后计算减法
5. 给出最终答案
|
效果：复杂推理任务准确率提升 30-50%。
2.3 少样本提示（Few-Shot Prompting）
原理：提供几个示例，让模型学习输出格式和风格。
示例：
1
2
3
4
5
6
7
8
9
10
11
12
13
| 将以下中文句子翻译成英文，保持专业语气：
示例 1：
输入：这个系统的延迟太高了，需要优化。
输出：The system's latency is too high and needs optimization.
示例 2：
输入：数据库查询超时，请检查索引配置。
输出：Database query timed out, please check the index configuration.
现在请翻译：
输入：API 响应时间超过 2 秒，影响用户体验。
输出：
|
2.4 约束条件（Constraints）
原理：明确限制输出范围，避免无关内容。
示例：
1
2
3
4
5
6
7
8
9
| 请总结以下文章的核心观点（不超过 200 字）：
[文章内容...]
约束条件：
- 只总结核心观点，不要添加个人观点
- 使用中文输出
- 不超过 200 字
- 使用项目符号列出要点
|
2.5 输出格式控制
原理：明确指定输出格式，便于后续处理。
| 格式 |
适用场景 |
| JSON |
程序化处理、API 集成 |
| Markdown 表格 |
对比分析、数据展示 |
| 项目符号列表 |
要点总结、清单 |
| 代码块 |
代码生成、配置示例 |
示例：
1
2
3
4
5
6
7
8
9
10
11
| 请分析以下用户评论的情感倾向，以 JSON 格式输出：
用户评论：这个产品真的很好用，推荐给大家！
输出格式：
{
"sentiment": "positive|negative|neutral",
"confidence": 0.0-1.0,
"key_phrases": ["短语 1", "短语 2"],
"reasoning": "简短分析"
}
|
三、实战案例
3.1 代码生成
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| 你是一位资深 Python 开发者，擅长编写简洁、高效、可维护的代码。
任务：实现一个带缓存的 API 客户端
要求：
1. 使用 functools.lru_cache 实现缓存
2. 支持超时和重试机制
3. 添加类型注解
4. 包含单元测试示例
5. 代码风格遵循 PEP 8
输出格式：
- 主代码放在代码块中
- 单元测试单独放在另一个代码块中
- 在代码前简要说明设计思路
|
3.2 数据分析
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| 你是一位数据分析师，擅长从数据中提取洞察。
任务：分析以下销售数据，找出关键趋势
数据：
| 月份 | 销售额 | 新客户 | 复购率 |
|------|--------|--------|--------|
| 1 月 | 120 万 | 500 | 35% |
| 2 月 | 135 万 | 480 | 38% |
| 3 月 | 142 万 | 520 | 40% |
分析要求：
1. 计算环比增长率
2. 识别关键趋势
3. 给出 3 条可执行建议
4. 用 Markdown 表格展示计算结果
|
3.3 内容创作
1
2
3
4
5
6
7
8
9
10
11
12
13
| 你是一位科技博主，擅长写深度但不晦涩的技术文章。
任务：写一篇关于"为什么大模型需要更多上下文"的短文
要求：
1. 目标读者：有编程基础的非 AI 专家
2. 字数：800-1000 字
3. 结构：
- 引言：用一个日常类比引入主题
- 正文：解释上下文的重要性（2-3 个要点）
- 结尾：总结 + 展望
4. 风格：亲切、专业、不堆砌术语
5. 包含 1-2 个具体例子
|
四、常见陷阱
| 陷阱 |
表现 |
修复方法 |
| 太模糊 |
“帮我写点什么” |
明确任务、格式、约束 |
| 太冗长 |
无关信息太多 |
精简上下文，突出关键信息 |
| 矛盾指令 |
“简洁但详细” |
明确优先级，分层次说明 |
| 假设模型知道 |
不提背景信息 |
补充必要上下文 |
| 格式混乱 |
没有指定输出格式 |
明确指定格式要求 |
五、Prompt 优化工作流
1
2
3
4
5
| 1. 初稿 → 写出基础 Prompt
2. 测试 → 用模型跑一遍
3. 诊断 → 分析输出问题（太短？太泛？格式不对？）
4. 迭代 → 针对性优化（加约束？改格式？加示例？）
5. 固化 → 保存为模板，复用
|
六、总结
| 技巧 |
核心 |
适用场景 |
| 角色设定 |
激活相关知识和风格 |
所有场景 |
| 思维链 |
展示推理过程 |
复杂推理、数学 |
| 少样本 |
学习输出格式 |
格式化输出、翻译 |
| 约束条件 |
限制输出范围 |
摘要、总结 |
| 格式控制 |
便于后续处理 |
程序化任务 |
核心原则：Prompt 工程是迭代过程，没有一蹴而就的完美 Prompt。先写出能用的，再逐步优化。
本文基于实际使用经验整理，Prompt 效果因模型而异，建议根据具体模型调整。