提示词工程(Prompt Engineering)是与大语言模型(LLM)高效交互的核心技能。随着ChatGPT、Claude、GPT-4等AI模型的普及,掌握提示词设计已成为开发者、产品经理和内容创作者的必备能力。本文将系统讲解提示词工程的核心原理、主流技术和实战最佳实践。
📋 目录
- 核心要点
- 什么是提示词工程
- 主流提示词技术详解
- 提示词结构化设计
- 角色
- 背景
- 任务
- 要求
- 代码
- 输出格式
- 场景优化策略
- 任务
- 技术要求
- 测试用例
- 输出
- 角色
- 数据
- 任务
- 输出格式
- 产品
- 目标受众
- 任务
- 要求
- 禁止
- 实战代码示例
- 任务
- 背景信息
- 输出格式
- 常见问题解答
- 总结与资源
核心要点
- 提示词工程:通过设计优化的输入文本,引导LLM生成高质量、准确的输出
- Zero-shot:无需示例,直接描述任务让模型完成
- Few-shot:提供少量示例,帮助模型理解任务模式
- Chain-of-Thought:引导模型逐步推理,提升复杂问题解决能力
- ReAct:结合推理与行动,实现工具调用和多步骤任务
- 结构化提示词:使用角色、任务、格式、约束等元素构建高效提示词
什么是提示词工程
提示词工程是设计和优化输入文本(Prompt)的过程,目的是引导大语言模型生成期望的输出。它不仅仅是"问问题",而是一门结合语言学、认知科学和AI技术的实践艺术。
为什么提示词工程重要
| 维度 | 差的提示词 | 好的提示词 |
|---|---|---|
| 准确性 | 模糊、偏离主题 | 精准、切中要点 |
| 效率 | 需要多次迭代 | 一次获得满意结果 |
| 成本 | Token消耗高 | 优化Token使用 |
| 可控性 | 输出格式不稳定 | 格式一致可预测 |
提示词的基本组成
┌─────────────────────────────────────┐
│ 角色设定 (Role) │
│ "你是一位资深的Python开发专家..." │
├─────────────────────────────────────┤
│ 任务描述 (Task) │
│ "请帮我优化以下代码的性能..." │
├─────────────────────────────────────┤
│ 上下文信息 (Context) │
│ "这是一个处理百万级数据的ETL脚本..." │
├─────────────────────────────────────┤
│ 输出格式 (Format) │
│ "请以Markdown格式输出,包含..." │
├─────────────────────────────────────┤
│ 约束条件 (Constraints) │
│ "代码需要兼容Python 3.8+..." │
└─────────────────────────────────────┘
主流提示词技术详解
Zero-shot Prompting
Zero-shot是最基础的提示词技术,直接描述任务,不提供任何示例。适用于简单、明确的任务。
示例:
将以下英文翻译成中文:
"The quick brown fox jumps over the lazy dog."
适用场景:
- 简单的分类任务
- 直接的翻译需求
- 基础的文本生成
优点: 简洁高效,Token消耗低 缺点: 复杂任务效果不稳定
Few-shot Prompting
Few-shot通过提供少量示例(通常2-5个),帮助模型理解任务模式和期望的输出格式。
示例:
请根据示例进行情感分类:
示例1:
文本:"这家餐厅的服务太棒了!"
情感:正面
示例2:
文本:"等了一个小时才上菜,体验很差。"
情感:负面
示例3:
文本:"价格还行,味道一般。"
情感:中性
现在请分类:
文本:"虽然有点贵,但食材新鲜,值得推荐!"
情感:
Few-shot最佳实践:
| 实践 | 说明 |
|---|---|
| 示例数量 | 从少量示例开始,再评测更多示例的收益是否值得 Token 成本 |
| 示例多样性 | 覆盖不同类型的输入情况 |
| 格式一致性 | 所有示例保持相同的格式 |
| 示例顺序 | 将最相关的示例放在最后 |
Chain-of-Thought (CoT)
思维链提示词引导模型在最终答案前生成自然语言中间步骤。它可能改善部分多步任务,但效果取决于模型、任务、示例与解码配置;可见步骤也不保证忠实呈现模型的内部计算。
基础CoT示例:
问题:一个书店有3个书架,每个书架有4层,每层可以放25本书。
书店目前已经放了210本书,还能再放多少本?
让我们一步步思考:
1. 首先计算总容量:3个书架 × 4层 × 25本 = 300本
2. 然后计算剩余空间:300本 - 210本 = 90本
答案:还能再放90本书。
Zero-shot CoT 指令:
在问题后加入「让我们一步步思考」(Let's think step by step),会要求模型在没有示例时生成中间步骤。应与直接回答基线对比,而不是假设它会激活可靠的推理模式:
问题:如果一辆车以60km/h的速度行驶,需要多长时间才能行驶150公里?
让我们一步步思考:
ReAct 模式
ReAct(Reasoning + Acting)结合推理和行动,让模型能够使用工具、搜索信息并执行多步骤任务。
ReAct模式:
问题:北京今天的天气如何?适合户外运动吗?
思考:我需要查询北京今天的天气信息。
行动:[搜索] 北京今天天气
观察:北京今天晴,气温15-25°C,空气质量良好,PM2.5指数45。
思考:根据天气信息,我需要判断是否适合户外运动。
行动:[分析] 评估户外运动适宜度
观察:晴天、温度适中、空气质量良好都是有利条件。
思考:我现在可以给出完整的回答了。
最终答案:北京今天天气晴朗,气温15-25°C,空气质量良好。
非常适合户外运动,建议选择上午或傍晚时段,避开中午阳光直射。
Self-Consistency
自洽性方法通过多次采样并选择最一致的答案,提高输出的可靠性。
responses = []
for i in range(5):
response = llm.generate(prompt, temperature=0.7)
responses.append(response)
final_answer = majority_vote(responses)
提示词结构化设计
CRISPE框架
| 元素 | 说明 | 示例 |
|---|---|---|
| Capacity | 角色能力 | "你是一位有10年经验的全栈工程师" |
| Role | 具体角色 | "担任代码审查专家" |
| Insight | 背景信息 | "项目使用React+Node.js技术栈" |
| Statement | 任务陈述 | "审查以下Pull Request代码" |
| Personality | 风格要求 | "以专业但友好的语气" |
| Experiment | 输出格式 | "按严重程度分类列出问题" |
完整示例:
## 角色
你是一位有10年经验的全栈工程师,担任代码审查专家。
## 背景
我们的项目使用React 18 + Node.js 20技术栈,遵循Airbnb代码规范。
## 任务
请审查以下Pull Request代码,识别潜在问题。
## 要求
- 以专业但友好的语气
- 按严重程度(高/中/低)分类问题
- 提供具体的修改建议
## 代码
```javascript
// 待审查的代码
输出格式
🔴 高优先级问题
🟡 中优先级问题
🟢 低优先级建议
### 负面提示词技巧
明确告诉模型"不要做什么",可以有效避免常见错误:
请撰写一篇关于机器学习的技术博客。
要求:
- 面向初学者
- 包含实际代码示例
- 长度约1000字
请不要:
- 使用过于专业的术语而不解释
- 只讲理论不给实例
- 使用过时的库版本
## 场景优化策略
### 代码生成场景
任务
实现一个Python函数,用于验证邮箱地址格式。
技术要求
- Python 3.10+
- 使用正则表达式
- 包含类型注解
- 添加docstring
测试用例
- 有效: "[email protected]", "[email protected]"
- 无效: "invalid", "@nodomain.com", "spaces [email protected]"
输出
只输出代码,不需要解释。
### 数据分析场景
角色
你是一位数据分析师。
数据
| 月份 | 销售额 | 用户数 |
|---|---|---|
| 1月 | 50000 | 1200 |
| 2月 | 48000 | 1150 |
| 3月 | 62000 | 1400 |
任务
- 分析销售趋势
- 计算用户平均贡献值
- 预测下月销售额
输出格式
使用Markdown表格和要点列表。
### 文案创作场景
产品
智能手表 - FitPro X1
目标受众
25-35岁,注重健康的都市白领
任务
撰写一条朋友圈推广文案
要求
- 突出健康监测功能
- 语气轻松活泼
- 包含行动号召
- 长度:50-80字
- 可以使用emoji
禁止
- 夸大宣传
- 使用"最好"、"第一"等绝对词汇
## 实战代码示例
### Python调用OpenAI API
```python
from openai import OpenAI
client = OpenAI()
def structured_prompt(role, task, context, format_spec):
"""构建结构化提示词"""
prompt = f"""## 角色
{role}
## 任务
{task}
## 背景信息
{context}
## 输出格式
{format_spec}
"""
return prompt
def generate_with_cot(question):
"""使用思维链生成回答"""
prompt = f"""{question}
让我们一步步思考这个问题:"""
response = client.chat.completions.create(
model="gpt-4",
messages=[
{"role": "system", "content": "你是一个善于逻辑推理的助手。"},
{"role": "user", "content": prompt}
],
temperature=0.7
)
return response.choices[0].message.content
prompt = structured_prompt(
role="资深Python开发者",
task="优化以下代码的性能",
context="这是一个处理CSV文件的脚本,文件大小约500MB",
format_spec="提供优化后的代码和性能对比说明"
)
print(prompt)
Few-shot模板生成器
def create_few_shot_prompt(task_description, examples, query):
"""创建Few-shot提示词"""
prompt = f"{task_description}\n\n"
for i, (input_text, output_text) in enumerate(examples, 1):
prompt += f"示例{i}:\n输入:{input_text}\n输出:{output_text}\n\n"
prompt += f"现在请处理:\n输入:{query}\n输出:"
return prompt
examples = [
("苹果", "水果"),
("西红柿", "蔬菜"),
("三文鱼", "海鲜"),
]
prompt = create_few_shot_prompt(
task_description="请将食材分类到对应的类别(水果/蔬菜/海鲜/肉类)",
examples=examples,
query="牛排"
)
上线前评测提示词
提示词是可版本化的行为规格,而不是一次性的措辞。判断某种技巧是否更好前,应在冻结基线和具有代表性的输入上比较,包括普通请求、模糊输入、长上下文、对抗指令和预期拒答。
| 检查项 | 应记录什么 | 为什么重要 |
|---|---|---|
| 任务质量 | 正确性或任务评分量表 | 表达流畅不等于答案正确 |
| 格式遵循 | JSON/Schema 有效性和必填字段 | 下游系统需要可预测输出 |
| 事实依据 | 引用准确性或证据支持 | 提示词不能让无依据的内容变成事实 |
| 安全性 | 注入、隐私和策略测试用例 | 系统提示词不是安全边界 |
| 运行指标 | 延迟、Token、成本和失败率 | 更复杂的模式未必值得其成本 |
每次结果都应保存模型修订、系统提示词、示例、解码参数、工具、检索语料版本和评测器版本。一次只改变一个有意义的变量,否则无法将表面改进归因于提示词本身。
对于 Agent 工作流,要明确区分可信指令与不可信的检索文本、工具输出;工具参数应结构化,并在执行前校验。授权、允许列表和预算控制必须由运行时负责。威胁模型可参考提示注入攻击与防御指南,提示词作为生产资产时可使用提示词 CI/CD 与回归测试建立持续评测。
常见问题解答
1. 提示词越长越好吗?
不一定。提示词应该足够详细以明确任务,但过长会增加Token成本和处理时间。关键是精准而非冗长。建议先用简洁提示词测试,根据输出质量逐步优化。
2. 如何处理模型"幻觉"问题?
几种有效策略:
- 要求模型引用来源
- 使用"如果不确定,请说明"的约束
- 提供参考资料作为上下文
- 使用Self-Consistency多次验证
3. Few-shot示例应该放在提示词的什么位置?
研究表明,将最相关的示例放在最后(靠近实际问题)效果最好。这是因为LLM对最近的上下文有更强的注意力。
4. 不同模型需要不同的提示词吗?
是的,不同模型有不同的特性:
- GPT-4:理解能力强,可使用复杂提示词
- Claude:擅长长文本,适合详细指令
- 开源模型:可能需要更明确、简单的指令
5. 如何评估提示词的效果?
建立评估体系:
- 准确性:输出是否正确
- 相关性:是否切题
- 格式:是否符合要求
- 一致性:多次运行结果是否稳定
总结与资源
提示词工程是一门需要不断实践和迭代的技能。掌握核心技术后,关键是在实际场景中持续优化。
关键技术回顾
| 技术 | 适用场景 | 复杂度 |
|---|---|---|
| Zero-shot | 简单任务 | ⭐ |
| Few-shot | 模式学习 | ⭐⭐ |
| Chain-of-Thought | 推理问题 | ⭐⭐⭐ |
| ReAct | 工具调用 | ⭐⭐⭐⭐ |
| Self-Consistency | 高可靠性需求 | ⭐⭐⭐ |
最佳实践清单
✅ 明确定义角色和任务
✅ 提供足够的上下文信息
✅ 指定期望的输出格式
✅ 使用负面提示词避免常见错误
✅ 在多步任务上评测 CoT 或问题分解,并独立核验结果
✅ 持续测试和迭代优化
本文介绍的这些技术——从 Zero-shot、Few-shot 到思维链和 ReAct——并非一成不变的固定套路,而是一套可供取用的工具箱。想要真正提升效果,最可靠的方式是为你自己的任务搭建一个小型评估集,试用某项技术、量化前后差异,然后保留真正奏效的做法。相比一次性的巧妙措辞,提示词工程更奖励有纪律的持续迭代。