Prompt Engineering

Prompt Engineering（提示工程）是与大语言模型高效沟通的核心技能。一个精心设计的 Prompt 可以让模型输出质量产生质的飞跃，而一个模糊的 Prompt 则可能导致无用甚至错误的回答。

掌握 Prompt Engineering 不需要编程背景，但它确实需要系统性的思维方式。OpenAI 官方总结了六大核心策略，每一条都经过大量实践验证。无论你是开发者、产品经理还是内容创作者，这些策略都能帮助你从 GPT 模型中获得更好的结果。

本模块将逐一讲解这六大策略，并通过大量对比示例帮助你建立直觉。

六大核心策略

以下是 OpenAI 官方推荐的 Prompt Engineering 六大策略。建议逐一学习并打勾标记你已经掌握的内容：

0% 完成

编写清晰的指令 — 明确任务、格式、长度要求

提供参考文本 — 减少幻觉，让模型基于事实回答

将复杂任务拆分为子任务 — 降低错误率

给模型时间思考 — 先推理再给结论

使用外部工具 — 搜索、代码执行、函数调用

系统性测试 — 用评估集衡量 Prompt 效果

Prompt 的结构层级

一个优秀的 Prompt 通常由以下四个层级组成。System 和 Task 是最关键的两个部分，它们决定了模型回答的方向和质量：

Prompt 结构层级

System

角色定义与规则

→

Context

背景信息与参考

→

Task

具体任务指令

→

Format

输出格式要求

System 层定义模型的身份、能力边界和行为准则，相当于给模型一个"岗位说明书"。Context 层提供完成任务所需的背景信息和参考资料。Task 层是具体的任务指令，告诉模型"做什么"。Format 层规定输出的格式、长度、语言等约束条件。

并不是每个 Prompt 都需要四层俱全。简单任务可能只需要 Task，复杂任务则建议尽量完善每一层。关键原则是：你给模型的信息越明确，模型给你的回答越精准。

---

策略一：编写清晰的指令

模型无法读心。如果你觉得输出太长，就告诉它字数限制；如果你想要特定格式，就明确描述格式要求；如果你想让模型扮演某个角色，就在 System 层说清楚。

模糊的指令是最常见的 Prompt 问题。很多人觉得模型"不聪明"，其实根本原因是指令不够清晰。一个好的指令应该包含：做什么（任务）、给谁看（受众）、怎么做（格式/语气/长度）。

⚠️差的 Prompt

"帮我写一封邮件"

问题：没有说明收件人、场景、语气、长度。

💡好的 Prompt

"写一封给客户的道歉邮件，因为订单延迟了 3 天。语气专业但诚恳，包含补偿方案（9 折优惠券），控制在 200 字以内。"

优势：明确了对象、原因、语气、内容要求和长度限制。

清晰指令的要素

编写清晰指令时，可以从以下几个维度来完善你的 Prompt：

1. 任务定义：明确告诉模型你要做什么（总结、翻译、写代码、分析……）
2. 受众说明：输出是给谁看的（技术专家、普通用户、儿童……）
3. 格式要求：期望的输出格式（列表、表格、JSON、Markdown……）
4. 长度限制：字数、段落数或句子数
5. 语气风格：正式、轻松、学术、口语化……
6. 示例：给一两个输入-输出示例，比任何描述都有效

---

策略二：提供参考文本

大语言模型有一个已知的弱点——幻觉（Hallucination）。当模型不确定答案时，它可能会"编造"看起来合理但实际错误的信息。提供参考文本是减少幻觉最有效的手段之一。

通过在 Prompt 中附上权威的参考资料，你可以要求模型基于这些资料回答问题，而不是依赖其训练数据中可能过时或不准确的信息。这种方式在知识密集型任务（如法律咨询、医学问答、技术文档）中尤其重要。

⚠️差的 Prompt

"公司的退款政策是什么？"

问题：模型不了解你的公司，只能凭空猜测或给出通用回答。

💡好的 Prompt

"根据以下退款政策文档回答用户问题。如果文档中没有相关信息，回答'该问题不在退款政策覆盖范围内'。

---退款政策---

1. 购买后 30 天内可无理由退款
2. 数字产品激活后不支持退款
3. 退款将在 5-7 个工作日内原路返回

---

用户问题：我买了一个软件激活码，3 天前激活的，能退款吗？"

优势：提供了具体文档，要求基于文档回答，并设置了信息不足时的兜底回复。

参考文本的最佳实践

• 用分隔符（如 ---、"""、<reference> 标签）明确标记参考文本的边界
• 要求模型引用原文，例如"请在回答中用【】标注信息来源"
• 设置兜底策略："如果参考文本中找不到答案，请说明信息不足"
• 结合 RAG（检索增强生成）架构，动态注入相关文档片段

---

策略三：将复杂任务拆分为子任务

就像软件工程中的模块化设计一样，复杂的 Prompt 任务也应该被拆分成更小、更清晰的子任务。一次性让模型完成一个复杂任务的错误率远高于分步完成。

这个策略的核心思想是：降低每一步的认知负担。每个子任务都足够简单，模型犯错的概率就会大大降低。最终将各步结果组合起来，整体质量也会更好。

⚠️差的 Prompt

"分析这篇 5000 字的文章，提取要点，翻译成英文，然后写一篇 300 字的英文摘要。"

问题：一步要求太多，模型可能在中间环节丢失信息或出错。

💡好的 Prompt — 分步执行

第一步："阅读以下文章，提取 5 个核心要点，用中文列出。"

第二步："将以下 5 个要点翻译成英文。"

第三步："基于以下 5 个英文要点，写一篇 300 字的英文摘要。"

优势：每一步任务明确，模型可以专注于单一目标，错误率更低。

任务拆分的常见模式

• 管道式（Pipeline）：上一步的输出是下一步的输入，串行执行
• 分类路由：先让模型判断问题类型，再根据类型调用不同的处理 Prompt
• 并行处理：对于独立的子任务，可以并行调用，最后合并结果
• 递归摘要：对于超长文本，分段摘要后再对摘要做总摘要

---

策略四：给模型时间思考

这个策略的直觉来自人类的思考过程——如果有人问你"17 乘以 28 等于多少"，你需要一些时间心算，而不是脱口而出。同样，让模型在给出最终答案之前先展示推理过程，可以显著提高准确率。

这就是所谓的 Chain of Thought（思维链） 技术。通过要求模型"先推理再回答"或"一步一步思考"，模型会分配更多计算资源用于推理，而不是直接跳到结论。

⚠️差的 Prompt

"这道数学题的答案是什么？一个水箱以 2L/min 的速度注水，同时以 0.5L/min 的速度漏水。水箱容量 100L，多久能装满？"

问题：直接要求答案，模型可能跳过关键计算步骤而给出错误结果。

💡好的 Prompt

"请一步一步思考以下问题，先列出已知条件，再写出计算过程，最后给出答案。

问题：一个水箱以 2L/min 的速度注水，同时以 0.5L/min 的速度漏水。水箱容量 100L，多久能装满？"

优势：要求展示推理过程，模型会更仔细地逐步计算，减少跳步导致的错误。

实用技巧

• 在 Prompt 中加入"Let's think step by step"或"请一步一步思考"
• 要求模型先列出思路大纲，再逐步展开
• 对于判断题，要求"先分析再给结论"，避免模型先入为主
• 如果需要更强的推理能力，可以考虑使用 o3 / o4-mini 等推理模型（详见推理模型章节）

---

策略五：使用外部工具

语言模型的能力有边界——它不擅长精确数学计算，无法访问实时信息，也不知道你的私有数据。但通过 Function Calling（函数调用），你可以让模型调用外部工具来弥补这些不足。

这种方式将模型变成了一个"智能调度器"：它理解用户意图，决定调用哪些工具，拼装参数，然后整合工具返回的结果。模型做它擅长的（理解和生成），工具做它擅长的（精确计算、数据查询、API 调用）。

⚠️差的 Prompt

"现在北京的天气怎么样？"

问题：模型的训练数据有截止日期，无法获取实时天气信息。

💡好的做法 — 结合工具

通过 Function Calling 定义一个 get_weather 函数，模型识别到用户在问天气后自动调用该函数获取实时数据，再用自然语言整合回复。

tools = [{
    "type": "function",
    "function": {
        "name": "get_weather",
        "description": "获取指定城市的实时天气",
        "parameters": {
            "type": "object",
            "properties": {
                "city": {"type": "string", "description": "城市名"}
            },
            "required": ["city"]
        }
    }
}]

优势：模型负责理解意图，工具负责获取数据，各司其职。

常见的外部工具类型

• 代码执行：让模型编写代码并在沙盒中运行，处理精确计算
• 搜索引擎：接入 Web 搜索，获取实时信息
• 数据库查询：将自然语言转换为 SQL 查询你的业务数据
• 文件处理：读取、分析 PDF/Excel/CSV 等文件
• API 调用：对接第三方服务（邮件、日历、CRM 等）

关于 Function Calling 的详细用法，请参考 Function Calling 章节。

---

策略六：系统性测试

Prompt Engineering 不是一次性的工作。就像软件开发需要测试一样，Prompt 也需要系统性的评估来确保质量。一个在少数例子上表现好的 Prompt，不代表在所有场景下都可靠。

系统性测试的核心是建立 评估集（Eval Set）——一组有标准答案的输入输出对。每次修改 Prompt 后，都要在评估集上跑一遍，看看整体表现是提升了还是下降了。这样才能避免"修好了 A 场景，搞坏了 B 场景"的问题。

⚠️差的做法

修改 Prompt 后随便试两个例子，觉得"看起来不错"就上线了。

问题：主观判断不可靠，可能在其他场景下退化。

💡好的做法

1. 准备 50-100 个覆盖各种边界情况的测试用例
2. 定义明确的评分标准（准确率、格式合规率、信息完整度等）
3. 每次修改 Prompt 后运行完整评估
4. 记录每个版本的评估分数，追踪变化趋势

优势：数据驱动的优化方式，确保 Prompt 改进有据可依。

评估的实用建议

• 从小开始：先收集 20-30 个高质量测试用例，覆盖常见场景和边界情况
• 自动化评估：用脚本批量运行 Prompt 并对比输出，而非手动逐个检查
• 模型评模型：可以用 GPT-4o 来评判 GPT-4o-mini 的输出质量，作为自动评分器
• A/B 测试：在生产环境中对比不同版本的 Prompt 表现

---

instructions 参数 vs 内置系统消息

在 OpenAI 的 Responses API 中，有两种方式设置系统级指令：

方式一：instructions 参数

response = client.responses.create(
    model="gpt-4o",
    instructions="你是一个专业的技术翻译，请将用户输入的中文翻译成地道的英文。",
    input="大语言模型正在改变软件开发的方式。"
)

instructions 参数是 Responses API 中设置系统指令的推荐方式。它等价于在对话开头插入一条 developer 角色的消息，但语法更简洁。

方式二：通过 input 数组传入系统消息

response = client.responses.create(
    model="gpt-4o",
    input=[
        {"role": "developer", "content": "你是一个专业的技术翻译。"},
        {"role": "user", "content": "大语言模型正在改变软件开发的方式。"}
    ]
)

这种方式更灵活，适合需要在多轮对话中精确控制消息顺序的场景。

如何选择？

• 简单场景：使用 instructions 参数，简洁直观
• 多轮对话：通过 input 数组精确控制，更灵活
• 两者可以同时使用：instructions 会被插入到 input 数组的最前面

---

Temperature 和 Top_p 调优

ℹ️Temperature 和 Top_p 调优指南

temperature 和 top_p 是控制模型输出随机性的两个关键参数。它们影响模型在生成文本时如何选择下一个 token。

Temperature（温度）：取值范围 0-2，默认 1。

• 低温度（0-0.3）：输出更确定、更一致。适合需要准确性的任务，如代码生成、数据提取、数学计算
• 中温度（0.5-0.7）：平衡创造性和一致性。适合一般的对话、摘要、翻译
• 高温度（0.8-1.5）：输出更多样、更有创造力。适合头脑风暴、创意写作、故事生成

Top_p（核采样）：取值范围 0-1，默认 1。

• Top_p 控制模型从累积概率达到 p 的最小 token 集合中采样
• top_p=0.1 意味着只从概率最高的前 10% token 中选择
• top_p=0.9 则会考虑更多候选 token

使用建议：通常只调整其中一个参数，不建议同时大幅调整两者。对于大多数应用场景，调整 temperature 就足够了。

任务类型	推荐 Temperature	说明
代码生成	0 - 0.2	需要精确、可重复的输出
数据提取	0	需要确定性结果
翻译	0.3 - 0.5	需要准确但允许表达灵活
对话/问答	0.5 - 0.7	自然但不过于发散
创意写作	0.8 - 1.2	鼓励多样性和创造力
头脑风暴	1.0 - 1.5	最大化创意空间

---

总结

Prompt Engineering 的六大策略是相互配合的。在实际项目中，你往往需要同时运用多条策略：

1. 用 清晰的指令 定义任务边界
2. 用 参考文本 提供知识基础
3. 用 任务拆分 降低复杂度
4. 用 思维链 提高推理准确率
5. 用 外部工具 扩展能力边界
6. 用 系统测试 持续优化质量

记住：Prompt Engineering 是一项实践技能，最好的学习方式就是不断尝试、对比、迭代。