提示词（Prompt） 是交给 AI 的任务说明。它可以只有一句话，也可以包含背景资料、限制条件、示例和输出格式。
提示词工程（Prompt Engineering） 是设计、测试和改进提示词的过程。之所以称为“工程”，是因为结果需要验证：写出第一版只是开始，还要根据回答调整，并检查修改后的提示能否稳定工作。
本文只讲最通用的基础方法。提示链、RAG、工具调用等方法解决的是更复杂的问题，不是写好每条提示都必须掌握的前置知识。
| 阶段 | 要做什么 | 判断标准 |
|---|---|---|
| 写提示 | 说明任务、背景、限制和输出 | AI 是否知道要完成什么 |
| 改提示 | 根据实际回答补充或修改规则 | 问题是否被针对性修复 |
| 做评测 | 换几种情况重复测试 | 提示是否只对一个案例有效 |
整套流程可以压缩成一句话：
先写一个可用版本，再根据输出改进；需要复用时，再用评测验证。
下面始终使用同一个例子：让 AI 为一家三口安排周一到周五的晚餐，并生成购物清单。
一、提示词的设计
先看这一章的完整清单：
| 方法 | 解决的问题 |
|---|---|
| 先说要做什么 | 让 AI 知道应该生成什么 |
| 写清成功标准 | 把“好一点”改成可以检查的要求 |
| 补充必要背景与约束 | 避免结果与实际情况冲突 |
| 信息多时分区 | 防止不同要求混在一起 |
| 用示例展示模式 | 说明难以描述的格式或风格 |
| 规定输出和检查项 | 让结果更容易使用和验收 |
正向指令与负向约束
只写“不要太长、不要太老、不要剧透”，AI 知道要避开什么，却不知道应该推荐什么。先写目标，再写排除条件：
推荐 3 部近十年、时长 120 分钟以内的轻松悬疑片。
每部列出片名、年份、时长和一句推荐理由；避免恐怖元素和明显剧透。“不要”并非不能用。安全边界和硬性限制仍应明确写出；只是负向限制最好配上正向目标。 Prompt Engineering Guide：设计提示的通用技巧
成功标准
“健康一点、丰富一点”有很多解释。把它改成能在结果中检查的条件：
| 模糊要求 | 可检查的写法 |
|---|---|
| 健康一点 | 每餐至少有一种蔬菜；不使用乳制品 |
| 简单一点 | 工作日晚餐在 30 分钟内完成 |
| 适合全家 | 两位成人和一个孩子；孩子不吃辣 |
| 清楚一点 | 每天列菜品、用时、库存食材和需购食材 |
具体不等于事无巨细。只写会改变结果的信息。
上下文与约束
晚餐任务需要知道人数、忌口、可用时间和现有食材。它们属于上下文：AI 完成本次任务可依据的信息。
还要区分优先级：乳糖不耐受是不能违反的硬约束；“主菜尽量不重复”是可以取舍的偏好。重要限制应单独写清，不要混在背景描述中。
信息结构
条件较多时，用标题和列表区分职责：
家庭：两位成人和一个孩子；一位成人乳糖不耐受，孩子不吃辣。
库存：鸡胸肉、鸡蛋、番茄、西兰花；鸡胸肉优先使用。
要求：30 分钟内完成；周三只能提前准备或快速加热。
输出：每天的菜品、用时、库存食材，以及一份合并购物清单。分区不是特殊语法，只是减少混淆。简单任务不必套模板。
少样本提示
“购物清单要清楚”仍然抽象。一个示例可以同时说明字段、顺序和细节程度：
周一：番茄鸡蛋面｜20 分钟｜库存：鸡蛋、番茄｜购买：面条、小葱在提示中放入少量范例，称为少样本提示（Few-shot prompting）。它让模型参考当前任务中的模式，不是在现场重新训练模型。
示例也会传递错误和隐含规律：示例漏项，输出可能继续漏项；所有示例都有肉，模型也可能延续这个模式。因此示例应短、相关且格式一致。 Google Prompt Design Strategies
Anthropic Prompting Best Practices
输出格式与检查
如果结果要继续复制、整理或执行，就直接规定交付形式：
每天按“菜品｜预计用时｜库存食材｜需购食材”输出。
最后合并购物清单，并检查是否覆盖菜单中的全部新增食材。格式要求能提高可用性，不能保证事实正确。整齐的表格仍可能包含过期价格或错误计算。
下面的教学模拟把同一个晚餐任务逐步改写。切换标签即可比较每种方法解决了什么。
PROMPT IMPROVEMENT
提示词的逐步完善
帮我安排一家三口周一到周五的晚餐，再列一份购物清单。 一家三口：一位成人乳糖不耐受，孩子不吃辣。工作日晚餐 30 分钟内完成；周三只安排 10 分钟内可加热的食物。冰箱有鸡胸肉、鸡蛋、番茄和西兰花，鸡胸肉优先使用。 家庭情况：两位成人和一个孩子；一位成人乳糖不耐受，孩子不吃辣。现有食材：鸡胸肉、鸡蛋、番茄、西兰花；鸡胸肉优先使用。安排要求：工作日晚餐 30 分钟内；周三只安排 10 分钟内可加热的食物。希望得到：每天菜品、预计用时、使用的现有食材，以及合并后的购物清单。 输出示例：周一：番茄鸡蛋面｜20 分钟｜使用：鸡蛋、番茄｜购买：面条、小葱请每天按这个粒度写，并在最后合并购物清单。 每天按“菜品｜预计用时｜库存食材｜需购食材”输出。最后合并购物清单，并核对是否覆盖菜单全部新增食材。 怎样读这个实验：不是步骤越多越好。只有当某条信息会改变菜单或让结果更容易使用时，才值得加进提示。
写提示的原则：用最少的必要信息，说明任务、条件和合格结果。
二、提示词的迭代
第一版回答不是最终答案，而是一份测试结果：它告诉我们当前提示还缺什么。
改进循环只有四步：
得到回答 → 找到具体问题 → 修改相关规则 → 再次检查
输出偏差
“重新来”和“再详细一点”没有说明哪里需要改变。有效追问通常包含四项：
- 保留什么；
- 哪里不对；
- 希望怎样修改；
- 还要检查什么。
例如：
保留周一和周二。周三不能现做 50 分钟，请改成可提前准备或
10 分钟内加热的食物。最后检查购物清单是否覆盖全部食材。FOLLOW-UP PROMPT
三种追问方式
周一番茄鸡蛋面、周二鸡胸肉盖饭可以接受；周三是 50 分钟的奶油焗饭，购物清单还漏了豆腐。
不太好，重新来。菜单换了一批菜，但周三仍然需要现做，购物清单仍有漏项。
再详细一点，认真检查，安排得更健康、更丰富。回答变长了，增加了做法说明，却仍然使用了乳制品。
保留周一和周二。请修改三处：所有菜避免牛奶、奶油和普通芝士；周三改成 10 分钟内可加热完成；重新核对购物清单是否覆盖菜单所需食材。周一和周二保留；周三改成提前做好的鸡丝蔬菜粥；购物清单补上大米和小葱。
一个顺手的顺序：保留什么 → 哪里不对 → 怎样改 → 需要检查什么。一次处理一到三类问题，通常比把所有不满混在一起更容易得到可用修改。
最小改动
晚餐任务可以依次修正：
- 出现奶油菜 → 补充乳制品限制；
- 周三耗时过长 → 补充当天的时间限制；
- 购物清单漏项 → 增加菜单与清单的核对要求。
少量修改更容易判断哪条规则有效，也更容易在结果变差时撤回。
通用规则
| 局部补丁 | 可复用规则 |
|---|---|
| 不要再写奶油焗饭 | 所有菜避免牛奶、奶油和普通芝士 |
| 周三不要做红烧鸡翅 | 周三只安排可提前准备或 10 分钟内加热的食物 |
前者只修当前答案，后者描述了以后也适用的条件。提示工程是迭代过程；模板只能作为起点，仍要根据实际回答调整。 Google Prompt Design Strategies
改提示的原则：描述输出哪里不合格，再修改直接相关的规则。
三、提示词的评测
一次性任务和重复任务的完成标准不同：
| 使用方式 | 做到什么就够了 |
|---|---|
| 只安排本周晚餐 | 当前菜单可用 |
| 每周重复生成菜单 | 多种家庭情况都满足关键要求 |
后一种情况需要评测（Evaluation）：用代表性输入和固定标准比较提示的表现。
代表性场景
选择几种典型情况即可：普通一周、周三特别忙、库存很少、新增忌口。个人使用不需要复杂平台，保留 5～10 个真实场景已经很有帮助。
固定检查标准
每次都检查相同项目：是否违反忌口、是否超时、是否利用库存、购物清单是否完整。修改提示后重新跑这些场景，可以发现“修好一个问题，却破坏另一个问题”的情况。
LIGHTWEIGHT EVALUATION
多场景评测
安排一家三口的五天晚餐；列出每天菜品、用时和合并购物清单；优先使用现有食材。三人晚餐；30 分钟内；鸡胸肉需优先使用；无额外忌口。
周三只能花 10 分钟；其余条件不变。
冰箱只剩鸡蛋和半颗西兰花；不希望买一大堆一次性食材。
一位成人乳糖不耐受，孩子不吃辣；周三只能快速加热。
这就是轻量评测：不需要先搭平台。把未来可能遇到的几种情况留下，用同一个提示和一张检查表重复试，就能发现“只对眼前这次有效”的规则。
产品级评测还会记录模型版本、成本、延迟和安全指标，但基本原则不变：先定义什么算成功，再用固定案例比较改动。 OpenAI Model Guidance
评测的原则：一次好回答只能证明这次可用，不能证明提示稳定。
四、提示词的边界
先判断问题缺什么，再决定是否继续改提示：
| 问题 | 应该补什么 |
|---|---|
| 忘记忌口、格式不对 | 提示中的要求、结构或示例 |
| 不知道今天的超市价格 | 当前资料或检索 |
| 需要精确计算营养和份量 | 可靠数据和计算工具 |
| 希望自动购买食材 | 执行工具、权限限制和人工确认 |
提示负责表达任务；资料提供事实；工具负责计算或执行；权限限制风险。它们不能用更长的提示互相替代。
进阶：开发场景中的提示词工程可选阅读
程序需要稳定读取结果时，应优先使用 API 提供的结构化输出能力，而不是只在自然语言中要求“输出合法 JSON”。复杂任务也可以拆成提示链：前一步的输出成为后一步的输入。
开发者还会管理模型版本、生成参数、工具调用、成本、延迟和安全。不同模型对同一提示的反应可能不同，因此可复用任务应在实际使用的模型和产品中评测。
五、检查清单
写提示时不必填满所有栏目，只选当前任务需要的部分：
任务：要 AI 完成什么？
背景：它需要知道哪些事实或材料？
硬约束：哪些条件不能违反？
偏好：哪些要求可以取舍？
输出：结果包含哪些内容，采用什么格式？
示例：是否有难以描述、适合直接展示的模式？
检查：怎样判断结果合格？得到回答后，再问三件事：
- 具体哪里不合格？
- 应修改哪一条规则？
- 换一种情况后，这条规则仍然有效吗？
提示词工程不是一次写出完美提示，而是用清楚的要求和可重复的检查，逐步得到稳定结果。