提示词工程
提示词工程是向模型写清任务、约束、输入和输出要求，并用评测结果持续改进提示的过程。本文先说明提示由哪些部分组成，再介绍示例与思维链的适用条件。最后讲解如何约束输出结构，以及怎样通过评测判断修改是否有效。
1. 面试核心
先记住这几条，再读正文- 提示结构。 生产提示应明确角色与任务范围、可检查的规则、输入数据、示例、输出格式和异常处理。卡 · 综合题
- 效果评测。 提示质量由固定评测集上的任务指标衡量。修改应针对具体失败原因，并检查正常任务是否退化。卡 · 评测驱动的调优
- 示例与推导。 Few-shot 用示例传达格式和判断边界，CoT 用中间推导帮助完成多步任务，但会增加输出与延迟。卡 · Few-shot 与思维链
- 结构化输出。 严格 JSON Schema 约束输出字段和类型，业务程序还需检查订单是否存在、金额是否合规等内容。卡 · 结构化输出
2. 提示的组成
提示要让模型知道该完成什么，也让开发者能检查结果是否合格。编写时，可以按六类信息逐项确认：
- 角色与任务范围：说明模型承担什么职责，以及可以处理哪些请求。
- 规则与约束：把字数、字段来源和转人工条件写清楚。
- 输入数据：提供业务记录或检索文档，并标明来源。
- 输入输出示例：给出输入与期望输出，展示难以仅靠文字说明的判断边界。
- 输出格式：说明回答语言、长度或程序需要的字段。
- 异常处理：说明信息不足、请求越界和工具失败时应怎样处理。
下面用售后任务示范一个提示模板。{{order_json}} 是占位符，由程序填入本次查询到的订单数据：
<task>处理订单、物流和退款咨询。</task>
<rules>
订单号缺失时，询问订单号。
退款金额超过 500 元时，申请人工处理。
订单状态以 order 数据为依据。
信息缺失时，说明尚待确认的字段。
</rules>
<order>{{order_json}}</order>
<output_format>
使用中文，最多 120 字。
工单创建成功后，给出工具返回的工单号。
</output_format>
这里的 500 元是示例业务规则，120 字是可检查的长度限制。订单号缺失时，模型应追问；需要人工处理时，只有工单创建成功后才使用工具返回的编号。申请人工处理可以通过 create_ticket 创建工单，成功后再回复编号。退款获批前应说明正在申请处理，避免提前承诺退款。金额限制还要由执行器校验，避免仅靠模型判断。
执行器怎样检查授权，见工具授权与执行沙箱。
把提示用于实际业务时，还需要关注规则依据、数据分隔和版本管理：
- 规则依据：把“回答要专业”改成能验证的要求，例如“不超过 120 字，必须引用订单状态字段”。必要时说明原因，比如“回复会被语音合成朗读，请使用完整句子，避免省略号”。原因能帮助模型理解约束的用途，并处理相近情况。
- 数据分隔：标签把指令与订单数据分开，也方便程序替换变量。外部输入中的特殊字符需要转义，避免破坏标签结构。异常处理也要写出具体动作，例如缺少信息时追问、工具失败时说明尚未完成。
- 版本管理：提示模板存放在仓库中，由模板引擎填充变量。每次修改记录版本，便于对照评测和回滚。填入的订单或文档长度会变化，因此要检查最终输入的 Token 预算。
3. Few-shot 与思维链
当规则难以用文字说清时，可以用示例展示期望结果。任务需要多步推导时，则要考虑推理方式。这两种手段解决的问题不同。
Few-shot 指在提示中提供少量输入与期望输出的示例。它适合传达难以描述的格式、风格和分类边界。示例应覆盖正例、反例与难例，尤其是容易混淆的边界情况。如果所有示例都属于同一类，模型就容易偏向这一类。示例过多还会占用上下文，并让模型照抄具体内容，所以要通过评测选择数量。
思维链（Chain of Thought，CoT）提示展示或请求中间推导，再给出最终答案。它适合计算、多条件判断和规划等多步任务。显式写出推导会增加输出 Token，因此延迟和费用也会增加。简单分类、抽取和改写可以先测试直接指令。
推理模型已在内部执行推理。使用 OpenAI 推理模型时，可以先直接写清目标、约束和验收条件，再按任务评测显式推导是否有收益。推理预算的含义见大语言模型基础。
Few-shot 与 CoT 也可以结合：在少量示例中展示从输入到结论的推导过程。选择前，可以按下表中的任务要求建立评测方案：
| 任务 | 可先测试的提示方式 |
|---|---|
| 固定格式 | 明确格式加示例 |
| 分类边界 | 含边界正反例的 Few-shot |
| 多步计算 | 明确条件，比较推理模型与工具方案 |
| 简单抽取 | 直接指令加 Schema |
4. 结构化输出
输出要交给程序解析时，需要同时约定格式并检查内容。只在提示里写“输出 JSON”，仍会遇到多出解释文字、缺字段或字段类型错误等问题。
JSON Schema 是描述字段、类型和取值范围的结构规则。应用可以区分以下三种格式控制方式：
- 提示格式：用文字和示例说明期望格式，程序再尝试解析并处理错误。这种方式依赖模型遵循提示。
- JSON 模式：接口约束 JSON 语法，字段是否齐全、类型是否符合预期，仍需另行检查。
- 严格 Schema：提供方在生成时限制可选输出，使正常完成的结果符合支持的 Schema。这种方式称为约束解码，能进一步约束字段与类型。
OpenAI Responses 可通过 text.format 指定 json_schema，并用 strict: true 启用严格模式。工具调用也需要按接口启用严格约束，普通工具定义本身不保证参数满足 Schema。
下面的 JSON Schema 定义了售后请求的意图和订单号：
{
"type": "object",
"properties": {
"intent": {"type": "string", "enum": ["refund", "logistics", "other"]},
"order_id": {"type": ["string", "null"]}
},
"required": ["intent", "order_id"],
"additionalProperties": false
}
required 要求 intent 和 order_id 都出现。order_id 未知时可以填 null，enum 则把意图限定为退款、物流和其他三类。additionalProperties: false 表示结果只能包含声明的字段。
这些规则约束的是结构，实际订单是否存在仍需查询，退款金额是否超限也要由程序判断。各接口只支持 JSON Schema 的一部分能力，所以启用前要核对所用模型与接口支持的结构。
4.1 拒答、截断与流式解析
严格约束格式后，还要确认响应是否正常完成。模型拒答或输出被截断时，应用需要先处理这些状态，再解析结构化结果。比如，Responses 可以返回 refusal 拒答内容项，达到输出上限时可以返回 incomplete 状态。
流式输出是边生成边返回，接收过程中 JSON 的括号或字符串还没有闭合。界面可以用增量解析器展示已经确认的字段，也可以等完整结束后再解析。执行工具和写入数据库则应等待完整结果，再依次检查 Schema、权限和业务规则。
检查失败后，要根据格式错误、信息缺失和授权失败分别处理：
- 格式或可修正的字段错误，可以把具体错误返回模型，要求重新生成。重试次数要有上限，超过上限后进入人工处理或返回明确错误。
- 信息缺失时，应追问所需字段，补齐后再处理。
- 授权失败时，应停止对应动作，避免通过重复生成绕过权限检查。
5. 评测驱动的调优
提示是否有效，要看它能否稳定完成目标任务。先固定评测请求和评分方式，才能判断修改是否改善了结果。
一次调优可以按评测集、任务指标、失败原因、提示修改和回归比较推进：
- 从真实请求中抽样，加入已知难例和失败样例，标注期望结果或评分标准。
- 根据任务定义指标。分类看准确率，抽取看字段正确率，格式要求看合规率。开放式回答可以由人工或模型按统一标准评分，工具任务还要检查参数来源与执行结果。
- 将失败按原因归类，例如指令歧义、缺少信息、示例误导和格式错误。原因不同，需要修改的规则或输入也不同。
- 每次针对一类明确问题修改，并记录提示版本。这样，结果变化后才能判断是哪项修改起了作用。
- 在整组任务上回归比较。既检查目标问题是否改善，也检查正常、边界和拒答任务是否退化。
模型输出有随机性，所以关键结论需要多次运行，比较平均分或通过率。除了正确率，还应记录任务成功率、耗时和费用。上线后持续收集新的失败样例，补充到后续评测中。
完整评审与重复运行方法见 Agent 评估。
5.1 开发集与留出集
反复针对同一批样本改提示，会让结果越来越适合这批样本。因此，需要区分开发集和留出集，检查提示对新请求是否也有效。
开发集用于分析失败和修改提示，Few-shot 示例也从开发数据中选择。留出集单独保留，用于独立验收。如果把测试答案写进提示，模型就提前见过了答案，比较结果会失真。
对比提示版本时，同一任务应使用相同模型版本和参数。更换模型后要重新评测，因为旧模型上有效的措辞和示例，在新模型上也会产生不同效果。
6 · 面试题卡片
本页题目与参考回答
6.1 Agent 的提示词一般包含哪些部分？如何设计？
题型：综合题
考察重点：说明提示各部分的作用，并解释怎样把规则写成可检查的条件、怎样验证和管理修改。
参考回答
Agent 提示应包含角色与任务范围、可检查的规则、输入数据、示例、输出格式和异常处理。
任务范围说明助手能处理什么，规则则明确字段来源、字数和转人工条件。输入数据用标签与指令分开，示例展示关键边界。异常说明要覆盖信息不足、请求越界和工具失败，让模型知道正常流程中断后该怎么做。
提示规则可以说明原因，帮助模型处理相似情况。模板存放在仓库中，由程序填充变量并记录版本。填充后还需检查 Token 预算，因为输入数据长度会变化。权限和金额限制交给执行器校验，提示修改通过评测后再发布。
6.2 系统 Prompt 如何调优？如何判断一个 Prompt 的质量？
考察重点：解释怎样根据失败原因修改提示，并通过独立验收与重复运行判断效果。
相关内容：评测驱动的调优。
参考回答
Prompt 质量应由固定评测集上的任务指标衡量，调优则围绕失败原因逐项修改并回归比较。
从真实请求、已知难例和失败样例建立开发集，另留独立验收集。按任务定义准确率、字段正确率或格式合规率，开放式回答使用统一评分标准。再把失败按歧义、缺失信息、示例误导和格式错误归类，一次修改一类问题并记录版本。
修改后运行整组任务，检查目标问题是否改善，以及其他场景是否退化。固定模型版本和参数，多次运行关键用例，比较平均分或通过率，同时记录成本。上线后继续补充失败样例，更换模型时重新评测。
6.3 CoT 和 Few-shot 分别适合什么场景？
考察重点：说明两种技术分别解决什么问题，以及示例分布和显式推导如何影响效果与成本。
相关内容：Few-shot 与思维链。
参考回答
Few-shot 适合用示例传达格式、风格和分类边界，CoT 适合计算、多条件判断与规划等多步任务。
Few-shot 应覆盖难例和反例。全部示例属于同一类，会让输出偏向该类；数量过多又会占用上下文，甚至让模型照抄内容。因此，要用评测选择有代表性的示例。
CoT 显式展示中间推导，会增加输出 Token、延迟和费用。推理模型可以先使用直接指令，简单抽取或改写也可以先测试清晰要求与输出格式。两者可以结合，在少量示例中展示推导过程，再评测是否提高任务成功率。
6.4 想要模型按照固定结构输出，应该怎么做？
考察重点：区分提示格式、JSON 模式和严格 Schema，并说明业务校验、拒答与流式结果怎样处理。
相关内容：结构化输出。
参考回答
接口支持时，应使用严格 JSON Schema 约束字段与类型，解析后再由程序检查业务内容。
Responses 可用 text.format 的 json_schema 格式，并设置 strict: true。Schema 要符合接口支持的子集。工具调用也应显式启用严格约束；不支持严格结构时，可以使用 JSON 模式，并在程序侧检查字段和类型。
应用先检查是否拒答或未完成，再解析完整结果。Schema 通过后，仍需检查订单是否存在、金额范围和当前权限。流式片段可用于界面增量展示，工具执行或写库则要等结果完整并通过校验。
可修正的错误返回模型重试，次数超限后转人工或返回错误。缺失信息通过追问补齐，授权失败则停止对应动作。