Prompt Engineering 知识梳理
一、Prompt Engineering 介绍
Prompt 是送入模型的输入，可以是文本、图片、音频，也可以包含系统规则、用户任务、示例、上下文资料与工具说明。
使用 ChatGPT、GPT 等工具时，模型每次生成的内容都具有概率性。若用户只给出模糊任务，模型不知道任务对象、事实范围、输出格式和完成标准，结果就容易出现表述泛化、重点不同、格式变化，甚至补充未提供事实的问题。
Prompt Engineering（提示词工程）是为了达成具体目标，对这些输入进行设计、测试和迭代的过程。
Prompt Engineering 的目的，是把这些隐含要求写清楚，让输出更稳定、准确且可复用。
案例：Prompt 提升输出准确性
假设用户要根据三条工作记录生成周报：
text
1. 完成登录接口改造，单元测试通过。
2. 支付模块联调发现超时问题，正在排查。
3. 下周计划完成支付超时修复并进行回归测试。直接输入 ChatGPT：
text
帮我写一份周报。模型可能输出一段通用周报，既可能遗漏"支付超时"的风险，也可能自行补充"性能得到显著提升"等输入中没有的结论；不同轮次的段落结构和长度也可能不同。
改写为 Prompt：
text
你是一个java后端工程师。仅根据以下工作记录生成面向研发负责人的周报。
要求：
1. 分为"本周进展""风险与阻塞""下周计划"三个部分；
2. 每部分不超过 3 条，每条不超过 30 字；
3. 不得补充记录中未出现的事实；
4. 支付模块超时问题必须出现在"风险与阻塞"；
5. 使用 Markdown 二级标题和无序列表输出。
工作记录：
{{工作记录}}这个 Prompt 明确了角色、依据、结构、长度、禁止项和必须呈现的信息。模型仍可能出错，但输出范围和检查标准已清晰，使用者可以直接检查：是否只有三个部分、是否出现支付超时风险、是否补充了无依据事实。Prompt Engineering 的价值，不是保证模型永远正确，而是把"什么是正确结果"变得可表达、可检查。
Prompt 的常用方式
| 常用方式 | 写法要点 | 适用场景 |
|---|---|---|
| 直接指令（Zero-shot，零样本） | 明确任务、输入、输出与限制 | 总结、改写、分类等简单任务 |
| 角色与背景 | 指明处理视角、受众和业务上下文 | 客服回复、报告撰写、专业解释 |
| 少量示例（Few-shot，少样本） | 给出 1～3 个高质量输入输出示例 | 固定风格、分类口径、复杂格式 |
| 约束与输出格式 | 规定字段、长度、禁止项、Markdown 或 JSON（JavaScript Object Notation，一种结构化数据格式）格式 | 需要稳定复用或程序处理的结果 |
| 分步任务 | 将复杂工作拆为读取、分析、生成、校验等步骤 | 分析报告、资料比对、多条件判断 |
| 迭代与评测 | 根据真实失败案例补充规则，验证修改效果 | 业务场景上线和 Agent 配置优化 |
在 ChatGPT 应用中，最常用的基础组合是：任务目标 + 必要背景 + 约束条件 + 输出格式；只有当模型在特定口径或格式上仍不稳定时，再补充少量示例。不要一开始堆叠过长的规则，因为重复、冲突或无关的信息会降低模型对重点的关注。
二、Prompt 的使用
在 Agent 中，Prompt 通常不是一段孤立的文字，而是由不同来源、不同优先级的指令共同组成。常见组成如下：
| 组成部分 | 主要作用 | 一般由谁提供 |
|---|---|---|
| 系统提示词（System Prompt） | 定义 Agent 的角色、长期目标、安全边界和不可违背的行为规则 | Agent / 平台开发者 |
| 开发者提示词（Developer Prompt） | 定义具体产品的业务流程、工具使用规则和输出规范 | 应用开发团队 |
| 用户提示词（User Prompt） | 表达当前用户的问题、需求和提供的材料 | 最终用户 |
| 限定词与约束条件 | 限定范围、受众、语气、长度、步骤、禁止项和输出格式 | 可放在任一层，通常由系统或开发者固化 |
| 示例与上下文资料 | 给出期望模式、任务数据和必要事实 | 开发者、检索系统或用户 |
其中，系统、开发者和用户提示词有优先级：系统规则优先于开发者规则，开发者规则优先于用户请求。所谓"限定词"并不是独立的消息角色，而是 Prompt 中用于收紧行为范围的内容，例如"仅根据题目已知条件""不要直接给出答案""每次只问一个问题""使用三年级学生能理解的语言"。
案例：小学生教学 Agent
目标是让 Agent 辅导小学生学习数学。若只把用户问题直接交给 GPT，用户问"24 ÷ 6 等于多少？"时，模型通常会直接回答"4"。这对获取答案很有效，却不能帮助学生形成解题思路。
可以把 Prompt 设计为以下几层：
| 层级 | Prompt 内容示例 |
|---|---|
| 系统提示词 | 你是一名耐心的小学数学老师。你的目标是帮助学生理解解题过程，而不是替学生完成题目。除非学生已完成至少一次尝试，或明确表示已多次尝试仍无法继续，否则不要直接给出最终答案。优先使用提问、提示和正向反馈。 |
| 开发者提示词 | 面向三年级学生。每次回复只推进一个小步骤；先让学生说出已知条件或相关乘法口诀；语言不超过 80 字；不评价学生"笨"或"粗心"。 |
| 用户提示词 | 我不会算 24 ÷ 6，告诉我答案。 |
| 限定词与上下文 | 本轮只辅导这道除法题；不要直接给出商；使用学生已学过的 6 的乘法口诀；先提出一个可以回答的问题。 |
在这套 Prompt 下，Agent 的合适输出不是"答案是 4"，而是：
text
我们先不急着写答案。想一想：6 乘几会等于 24？
你可以从 6×1 开始试，找到后告诉我。如果学生回答"6×4=24"，Agent 再引导他把乘法关系转换成除法结论；只有学生已经理解步骤或多次受阻时，才给出答案并解释原因。这样，系统提示词保证"引导而非代答"的长期教学策略，用户提示词提供当前问题，限定词控制本轮的范围和输出方式。
三、Prompt Engineering 的作用
在 ChatGPT 等对话应用的早期阶段，提示词工程的作用，是把通用模型导向可交付的具体任务。
| 直接使用 ChatGPT 时的问题 | Prompt Engineering 的做法 | 带来的作用 |
|---|---|---|
| "帮我分析一下"这类需求缺少目标和对象 | 写清任务、受众、输入资料与完成标准 | 降低意图歧义，提高结果相关性 |
| 模型输出长度、语气、格式不稳定 | 规定字段、格式、长度并给出示例 | 输出更容易复用，也更易接入后续流程 |
| 没有资源为每个场景训练专用模型 | 使用 Zero-shot（零样本：只给指令）或 Few-shot（少样本：给少量示例） | 以较低成本验证新场景和业务假设 |
| 模型会补全未知事实或越过业务边界 | 明确允许资料、禁止动作、资料不足时的处理方式 | 让模型行为更接近业务规则 |
| 改完提示词只凭感觉判断好坏 | 根据真实失败案例补充规则，并做评测 | 将一次性技巧变成可迭代的配置 |
Prompt Engineering 解决的是"怎样把当前一轮任务说清楚"的问题。它不是知识库：最新或私有资料仍要依赖检索增强生成；不是执行器：真实操作需要工具调用；不是权限系统：高风险操作必须由权限、审批和审计控制；也不能单独证明一个多步骤任务已经完成。
四、从独立岗位到 Agent 内置能力
ChatGPT 刚普及时，很多团队把"会写提示词"视为一种独立且稀缺的能力，因此市场上出现过 Prompt Engineer（提示词工程师）岗位。那一阶段的任务，往往是为客服、写作、搜索和内部问答场景反复调整一段 Prompt。
这一独立岗位的高热期已经过去。原因不是 Prompt 不再需要，而是单独优化一段文字不足以交付生产应用：业务目标需要产品定义，资料需要检索和权限控制，模型需要工具，结果需要测试，写操作需要治理。因此，Prompt 能力已经被纳入 AI 产品、算法、应用开发、测试和 Agent 工程等更综合的岗位中。
今天，Prompt 已经作为 Agent 的内置配置和运行逻辑被实现。OpenAI 当前文档仍建议用明确、具体的指令和迭代方式改善输出；其最新模型指南也强调为长任务、工具密集型流程写清成功标准与停止条件，并用评测验证精简后的提示词是否更好。
不过，它的重心已经变化：
| 早期常见理解 | 当前生产实践 |
|---|---|
| 反复寻找"万能提示词"或特殊措辞 | 用清晰、短而完整的规则说明真实需求，再用评测迭代 |
| 主要优化用户输入的一段文字 | 同时设计系统指令、任务模板、工具描述、输出 Schema、示例与失败处理 |
| 认为提示词越详细越可靠 | 追求"最小但信息密度高"的上下文，删除重复、冲突和无关内容 |
| 只看一次回答是否看起来不错 | 用代表性案例、自动检查、人工抽检和线上指标判断是否可用 |
| 让模型自行输出自由文本 | 对可被程序消费的结果优先使用结构化输出和确定性校验 |
一个很重要的变化是：模型的指令遵循能力增强后，旧式的"复杂话术"价值下降了；但业务要求、工具契约和边界条件并不会自动出现在模型上下文中，仍然需要被清楚表达。更强的模型通常需要更少的微操 ，却仍需要更明确的目标和约束。
这也是为什么今天的提示词常常不像一句自然语言问题，而更像一份小型接口规范：
text
目标：根据已提供的订单记录，生成退款风险结论。
范围：只使用本次检索到的订单和政策资料；资料不足时明确说明。
工具：只允许查询订单与政策；不得执行退款。
输出：返回 JSON，包含 risk_level、evidence、missing_information。
完成条件：每条 evidence 必须能对应输入资料中的订单号或政策条款。五、Prompt 在 Agent 中如何实现
传统 ChatGPT 应用中，Prompt 往往是一段用户输入或系统提示；在 Agent 中，它被拆开并落实在多处：系统规则定义总体行为，工具描述定义行动接口，上下文选择提供事实依据，输出 Schema 约束数据格式，评测用例验证改动。也就是说，Prompt 已从"人工在聊天框里调一句话"，变成 Agent 运行过程中的一组可维护配置。
下面展示它在 Agent 工程中的位置：
| Agent 组件 | 核心问题 | Prompt 在其中的实现方式 |
|---|---|---|
| 系统指令 | 定义角色、目标、优先级和边界 | 将原先的核心 Prompt 固化为 Agent 的行为规则 |
| Context Engineering（上下文工程） | 这一轮应该给模型哪些资料、工具结果、记忆和历史 | 动态组织系统指令、检索资料、任务状态和历史信息 |
| RAG（Retrieval-Augmented Generation，检索增强生成） | 如何找到可靠、相关的外部知识 | 将检索到的事实按规则提供给模型，而不是要求模型凭空回答 |
| 工具与 Skill（技能） | Agent 能做哪些动作，何时使用 | 使用清晰的工具描述、参数约束和错误信息指导模型调用 |
| 输出 Schema 与验证 | 结果能否被程序安全消费 | 用字段、类型和自动检查替代"请务必按格式输出"的单纯文字要求 |
| Harness Engineering | 如何让任务安全、可验证、可恢复地运行 | 用权限、状态、审计与人工接管补足 Prompt 无法保证的部分 |
| Evals（Evaluations，评测） | 配置改动后是否真的更好 | 用代表性任务验证系统指令、上下文和工具设计 |
Anthropic 将 Context Engineering 明确描述为 Prompt Engineering 的自然演进：前者管理系统指令、工具、外部数据、消息历史等完整上下文，并在每次模型推理时持续筛选；后者仍负责写好和组织模型指令。Anthropic：Effective Context Engineering for AI Agents
六、未来：从人工写模板到系统化配置
Prompt Engineering 不会消失，但它的边界会变得更清楚：它负责写清模型在当前一轮"应该怎么做"；Context Engineering（上下文工程）负责决定模型在当前一轮"应该看到什么"，并随着 Agent 的执行持续更新这些信息。因此，上下文工程可以理解为提示词工程在 Agent 场景中的扩展和延伸。
| 对比维度 | Prompt Engineering | Context Engineering |
|---|---|---|
| 核心问题 | 怎样表达目标、规则、步骤和输出要求 | 当前一轮应给模型哪些有效信息 |
| 管理对象 | 系统提示词、用户提示词、限定词、示例与输出规范 | Prompt + 检索资料 + 工具说明和结果 + 对话历史 + 记忆 + 任务状态 |
| 典型场景 | 单次问答、固定任务模板 | 多步骤、长时程、会调用工具的 Agent |
| 主要动作 | 编写、组织和迭代指令 | 检索、筛选、压缩、更新和组合上下文 |
以"小学生教学 Agent"为例，提示词工程规定"不要直接给答案，优先用提问引导"；上下文工程则在每一轮决定是否加入学生年级、当前题目、已掌握的知识点、刚才的回答和连续受阻次数。前者定义教学方式，后者为当前教学步骤提供恰当的信息。两者共同保证 Agent 既遵守教学策略，又能根据学生状态调整引导。
未来应减少的做法，是把所有问题都寄希望于一段静态、冗长的 Prompt：
- 不再反复寻找"万能提示词"或特殊话术；
- 不再把完整业务资料、所有历史记录和全部规则一次性塞给模型；
- 不再只用文字要求模型"务必按格式输出"或"务必小心"；
- 不再凭一次回答"看起来不错"就认定配置可上线。
未来主导的能力，则是把 Prompt 放入一个可动态运行、可验证的 Agent 系统：
| 未来主导能力 | 减少的旧做法 | Prompt 与上下文工程的落点 |
|---|---|---|
| 更强的指令微调与推理模型 | 用花哨话术让模型理解简单要求 | Prompt 聚焦业务目标、优先级和边界，而非特殊措辞 |
| Context Engineering | 只维护一段静态 Prompt | 每一轮按需装配系统规则、检索资料、工具结果和记忆，并删除无关信息 |
| 检索增强生成与动态记忆 | 把全部资料提前塞进 Prompt | 仅在需要时检索与加载可靠资料，降低上下文噪声 |
| 结构化输出、类型约束与程序校验 | 靠文字要求模型"务必按格式输出" | Prompt 说明字段语义；Schema 和自动检查保证接口稳定 |
| 工具与 Skill（技能）规范 | 在 Prompt 中描述大量手工操作步骤 | 用清晰的工具描述、参数约束和错误反馈指导 Agent 行动 |
| 自动 Prompt Optimization（提示词自动优化） | 人工凭直觉反复改词 | 用成功标准、真实案例和评测集辅助优化系统指令与任务模板 |
| Evals（Evaluations，评测）与 Harness Engineering | 用一次"看起来不错"的回答决定上线 | 对 Prompt、上下文选择、工具调用和最终结果做持续验证与治理 |
因此，未来减少的是"专门调一句 Prompt"的孤立工作；主导的是"设计可版本管理、可测试、可回滚的 Agent 行为配置"。Prompt 定义行为方向，上下文工程提供每一轮所需信息，工具、结构化约束和评测共同把这种设计落到可靠执行上。
七、面向 Agent 实战，应该怎么使用它
不要先问"有没有一个更强的提示词模板"，而应先判断问题位于哪一层：
| 场景 | 提示词工程要做的事 | 还必须补上的能力 |
|---|---|---|
| 简单问答、写作、分类 | 说清目标、受众、输入、格式与少量示例 | 基础质量抽检 |
| 企业知识问答 | 规定回答范围、引用要求与资料不足时的行为 | RAG、权限过滤、来源质量与事实校验 |
| 数据分析助手 | 定义指标口径、输出 Schema 与异常说明 | 只读数据工具、查询限制、结果复核 |
| 编码 Agent | 明确仓库约束、验收标准、测试要求与停止条件 | 文件/终端工具、沙箱、版本控制、自动测试 |
| 可写业务系统的 Agent | 明确何时允许建议、何时必须确认、何时停止 | 最小权限、审批、幂等操作、审计、回滚与人工接管 |
一个可复用的最小提示词骨架是：
text
角色与范围：你负责什么，不负责什么。
目标：要交付什么结果；什么算完成。
事实来源：允许使用哪些资料和工具；资料不足时如何处理。
约束：禁止动作、优先级、安全要求与升级条件。
输出契约：字段、格式、长度、引用或证据要求。
验证：交付前应执行哪些检查；失败时应报告什么。先用这个骨架构建最小版本，再根据评测中的真实失败补充规则。不要预先堆叠几十条猜测的限制，也不要把业务安全寄托在"请务必小心"这类文字上。
八、总结
Prompt Engineering 源于一个简单需求：在 ChatGPT 等应用中，把用户模糊的自然语言要求转化为模型可稳定执行的任务说明。它曾推动独立 Prompt Engineer 岗位出现；现在，这项能力已经在 Agent 的系统指令、上下文、工具、输出约束和评测中被具体实现。
可以用一句话记住：
ChatGPT 阶段，Prompt 是改善一次回答的方法；Agent 阶段，Prompt 是实现任务行为的一组系统配置。