Wiki Notes

Appearance

Prompt工程案例专题 ​

版本：v1.2

最后更新：2026-07-09

适用对象：正在做结构化抽取、知识库问答、客服分诊、工具调用、审批助手、多轮对话和 Agent 工作流的产品、应用研发与平台同学

很多人学 Prompt 工程时，最容易停留在：

  • 会写 few-shot
  • 知道 constraints
  • 看过一些“高质量提示词模板”

但一进真实项目，马上又会碰到更实际的问题：

  • 为什么线下样例很好，上线后还是不稳
  • 为什么 Prompt 越写越长，团队却越来越难维护
  • 为什么明明改的只是一小句，工具调用率、JSON 成功率和延迟却一起变了
  • 为什么换了模型之后，旧 Prompt 反而开始过度约束、变机械或提前停

这说明 Prompt 工程在生产里不是“写得更像模板”，而是：

  • 把任务边界、上下文装配、输出协议、工具策略、评测与版本治理整成一条可迭代链路。

按 2026-07-09 复核可访问的 OpenAI Prompt engineering、Prompt guidance、Reasoning best practices、Structured outputs、Prompt caching、Prompt optimizer、Evaluation best practices 和 Conversation state 等当前官方资料来看，Prompt 工程至少要同时回答六个问题：

  1. 任务 contract 到底是什么。
  2. 这次要靠 Prompt 解决什么，什么不该继续靠 Prompt 硬控。
  3. 当前模型家族更适合哪种写法。
  4. Prompt、schema、工具定义、上下文预算是否被当作同一组资产治理。
  5. 发布前后怎么验证 Prompt 变化没有带来隐藏回归。
  6. 高流量系统如何兼顾稳定前缀、缓存命中和会话状态。

1. 先把 Prompt 工程从“写提示词”升级成“设计控制面” ​

OpenAI 当前 Prompt engineering 文档强调的核心，不是堆技巧，而是：

  • instructions 要清晰
  • 上下文要明确
  • 复杂任务要拆开
  • 结果要能被约束和验证

这意味着 Prompt 从来不是孤立存在的。

它总是和下面这些东西一起工作：

  • 任务目标
  • 输入质量
  • 检索上下文
  • 输出 schema
  • 工具调用
  • 评测标准
  • 运行时状态

所以一个 Prompt 是否“好”，不能只看句子优不优雅，而要看：

  • 是否稳定
  • 是否可评测
  • 是否可维护
  • 是否能和系统其他层配合
  • 是否适配当前模型家族

1.1 一个更像生产系统的 Prompt 资产包 ​

在平台工程里，更推荐把下面这些东西视为同一组发布对象：

  • prompt_text
  • model_family
  • reasoning_effort
  • schema_version
  • tool_definition_version
  • retrieval_budget
  • validation_rules
  • eval_dataset_version

如果只版本化 Prompt 文本，而不版本化这些对象，后面很容易出现：

  • 回放时根本还原不出当时环境
  • 同一 Prompt 在不同服务上表现不一致
  • 团队误以为“Prompt 回归”，其实是 schema 或工具变了

2. 现代 Prompt 栈更像五层结构，而不是一大段自然语言 ​

很多历史 Prompt 堆成一整块，读起来像说明书，但在系统里不好治理。

更稳的拆法通常是五层。

2.1 任务层 ​

只回答：

  • 这次到底要完成什么
  • 什么叫成功
  • 什么叫失败

2.2 边界层 ​

只回答：

  • 不能做什么
  • 信息不足时怎么处理
  • 高风险动作是否必须转人工或走审批

2.3 上下文层 ​

只回答：

  • 可以使用哪些资料
  • 哪些资料优先
  • 上下文预算如何控制

2.4 协议层 ​

只回答：

  • 输出结构是什么
  • tool args 要符合什么 contract
  • 引用和 refusal 格式怎么写

2.5 运行层 ​

只回答：

  • 用什么模型家族
  • reasoning effort 取多少
  • 是否需要 tool preamble
  • 是否需要会话状态保留

把这五层分开之后，很多问题会突然清楚：

  • 任务没定义清楚，不该继续调 wording
  • schema 不稳定，不该继续靠自然语言补丁
  • 检索上下文太乱，不该继续加“请谨慎回答”

3. 2026 年的 Prompt 官方口径，和很多老经验已经不完全一样 ​

这部分是当前资料里最值得补进团队共识的地方。

3.1 GPT-5.5 路线更强调 outcome-first，而不是 process-heavy ​

OpenAI 当前 Prompt guidance 明确提示：

  • 更新后的模型更适合短一些、结果导向更强的 Prompt
  • 过多沿袭老 Prompt 栈，反而可能增加噪声

这对很多团队是个提醒：

  • 不是每次迁移新模型，都应该把旧 Prompt 原封不动搬过去

3.2 reasoning 模型和 GPT 模型不该共用同一套写法 ​

OpenAI 当前 Reasoning best practices 明确说得很清楚：

  • reasoning 模型更适合简单直接的指令
  • 不要默认再写“think step by step”
  • 先 zero-shot，不够再 few-shot
  • 用分隔符、标题和清晰结构帮助模型理解输入

这意味着如果你一边用 reasoning 模型，一边保留大量链路型“请先这样、再那样、再解释每一步”的旧 Prompt，结果可能不但不稳，还会更慢、更绕。

3.3 tool-heavy Responses 工作流里，Prompt 不再只是文本 ​

OpenAI 当前 Prompt guidance、Reasoning models 和 Conversation state 资料共同强调：

  • preambles
  • phase
  • assistant-item replay
  • previous response chaining

这些都已经进入 Prompt 行为边界。

也就是说，生产里的 Prompt 已经不是“只改一段字符串”，而是和：

  • 会话状态
  • tool preamble
  • assistant phase
  • replay 方式

强绑定。

4. 先把 Prompt 问题分成六类，别把所有锅都甩给 wording ​

4.1 任务定义问题 ​

症状：

  • 模型理解偏了
  • 同样输入输出风格飘

本质：

  • 要做什么没有说清楚

4.2 上下文装配问题 ​

症状：

  • 有资料却答不准
  • 检索上下文一长就乱

本质：

  • 不是 Prompt 不行，而是上下文没组织好

4.3 输出协议问题 ​

症状：

  • JSON 漏字段
  • tool args 错
  • refusal 格式不一致

本质：

  • 应该用 schema 或工具约束的地方，仍然在靠自然语言硬控

4.4 工具策略问题 ​

症状：

  • 模型过度调工具
  • 该调时不调
  • 参数像对的，但业务语义不对

本质：

  • tool contract、校验和审批层不完整

4.5 模型家族错配问题 ​

症状：

  • 换了模型后 Prompt 变机械
  • reasoning 变慢但收益不大
  • 长链指令突然提前停或过度解释

本质：

  • Prompt 还在沿用旧模型行为假设

4.6 版本治理问题 ​

症状：

  • 改一句话，线上行为全变
  • 团队不知道哪个版本更好

本质：

  • Prompt 没有 eval 驱动的迭代流程

5. 案例一：结构化信息抽取 ​

典型目标：

  • 从邮件、表单、工单、合同、聊天记录里抽字段

5.1 这类任务里 Prompt 真正关键的不是文风 ​

更关键的是：

  • 字段定义清楚
  • 边界条件清楚
  • 缺失值规则清楚
  • 输出 schema 清楚

5.2 更实用的 Prompt 结构 ​

建议至少包含：

  1. 任务目标
  2. 字段定义
  3. 缺失值处理规则
  4. 输出格式
  5. 1 到 2 个边界样例

5.3 一个更稳的生产拆法 ​

更推荐把任务拆成：

  • Prompt 定义字段语义
  • schema 约束字段结构
  • 校验器拦非法值
  • grader 看业务正确率

5.4 常见失败模式 ​

  • 把“未知”写成猜测值
  • 字段名看懂了，字段语义没对齐
  • 一个输入里多条记录时只抽第一条
  • schema 对了，但业务值错了

5.5 这类任务的关键经验 ​

如果字段必须稳定，优先级通常是：

  1. schema
  2. 字段定义
  3. 样例
  4. Prompt wording

而不是一开始就疯狂改措辞。

6. 案例二：知识库问答 ​

典型目标：

  • 基于企业文档回答问题

6.1 这类 Prompt 的核心不是“更会说话” ​

而是：

  • 如何只基于证据回答
  • 如何在证据不足时拒答
  • 如何保持引用稳定

6.2 更好的约束方式 ​

更适合明确写出：

  • 只允许使用提供的上下文
  • 上下文不足时直接说明
  • 不要编造来源
  • 如果多个证据冲突，优先指出冲突

6.3 citation 不该只靠口头提醒 ​

OpenAI 当前 Citation formatting 文档已经把引用摆位和支持关系讲得更细，这意味着企业 RAG 更稳的做法通常是：

  • Prompt 约束“必须引用”
  • 检索层提供真实 source id
  • 渲染层校验引用位置和引用对象

6.4 最常见的反模式 ​

  • 为了“用户体验”，提示模型尽量回答

这经常会直接把问答系统推向幻觉。

6.5 什么时候不是 Prompt 问题 ​

如果明明给了限制还在乱答，别只盯着 Prompt，也要回头检查：

  • 检索质量
  • 证据排序
  • 上下文长度
  • 引用协议

7. 案例三：客服分诊与路由 ​

典型目标：

  • 判断请求类型
  • 决定优先级
  • 判断是否转人工

7.1 这类任务 Prompt 的重点是“互斥分类” ​

必须讲清楚：

  • 每个类别的定义
  • 容易混淆的边界
  • 高风险类的优先级
  • 不确定时应该怎么处理

7.2 更适合的设计方式 ​

不要只写：

  • “请帮我分类”

更适合写：

  • 分类列表
  • 每类定义
  • 易混淆例外
  • 当无法确定时输出什么

7.3 这类任务最该单独版本化什么 ​

  • category taxonomy
  • escalation policy
  • 置信度阈值
  • human handoff 规则

因为很多路由回归并不是 Prompt 文本变了，而是分类体系或优先级规则改了。

7.4 最实用的经验 ​

路由类任务里，Prompt 的作用经常比模型大小更明显。

因为大部分不稳不是能力不足，而是类别边界含混。

8. 案例四：工具调用决策 ​

典型目标：

  • 决定要不要调工具
  • 决定调哪个工具
  • 生成参数

8.1 这类任务里 Prompt 最该解决什么 ​

不是“让模型更主动”，而是：

  • 什么情况下必须调工具
  • 什么情况下禁止调工具
  • 工具失败怎么办
  • 工具结果不足时怎么回退

8.2 最常见的三个坑 ​

  • 模型过度调用工具
  • 模型该调时不调
  • 参数看起来像对的，但业务语义不对

8.3 什么时候别再靠 Prompt 硬控 ​

如果你已经在 Prompt 里写了很多“必须 / 不得 / 只能”，但参数还是飘，通常说明应该补：

  • schema
  • tool contract
  • 业务校验
  • 审批分级

8.4 一个更稳的提示边界 ​

Prompt 更适合表达：

  • 工具选择策略
  • 缺参时怎么办
  • 哪些动作需要确认

而不适合替代：

  • 参数类型系统
  • 枚举校验
  • 权限系统
  • 幂等和补偿逻辑

9. 案例五：多轮对话、会话状态与 customer-facing UX ​

典型目标：

  • 保持角色稳定
  • 处理用户改口
  • 控制权限和语气
  • 支持工具前导说明和长任务状态反馈

9.1 这类任务最重要的是优先级 ​

建议明确区分：

  • 角色定义
  • 允许做什么
  • 不允许做什么
  • 规则冲突时优先级

9.2 为什么不要把角色写成“人设作文” ​

很多团队会给 system 或 developer prompt 写很长的人设段落，但真正决定多轮稳定性的通常不是这些，而是：

  • 冲突时到底听谁的
  • 何时必须拒答
  • 哪些动作需要确认
  • 状态信息是否被错误当成最终回答

角色感可以加分，边界感决定生死。

9.3 tool-heavy 流程里要小心 phase ​

OpenAI 当前 Reasoning models 与 Conversation state 明确提醒：

  • tool-heavy、长运行流程里，要正确保留 assistant 的 phase
  • 中间 commentary 如果被当成 final answer，行为会明显退化

这对 Prompt 工程的启发是：

  • “我先去查一下”“我先调用工具”这类前导说明，已经不是单纯文案问题
  • 它和会话状态 round-trip 正确性绑定

9.4 一个更像生产系统的会话对象 ​

  • conversation_id
  • response_id
  • phase
  • tool_preamble_enabled
  • assistant_item_replayed
  • final_render_policy

10. 案例六：审批助手和高风险动作确认 ​

典型目标：

  • 总结审批材料
  • 判断是否满足规则
  • 生成待审批建议

10.1 这里 Prompt 的重点不是替人拍板 ​

更合适的方向是：

  • 总结证据
  • 提示风险点
  • 给出建议动作
  • 明确不直接做最终裁决

10.2 这类任务的危险写法 ​

  • “如果信息足够就直接批准”

很多企业场景不应该把最终动作委托给自然语言 Prompt 决策，而应该：

  • 用规则
  • 用权限
  • 用审批流

Prompt 更适合做证据整理和辅助判断。

10.3 高风险场景里 Prompt 最该明确什么 ​

  • 哪些情况必须拒绝自动执行
  • 哪些动作必须先确认
  • 哪些证据缺失就不能进入建议环节
  • 哪些字段应该强制回显给人审

11. Prompt 不只是质量对象，还是成本对象 ​

这是很多团队后面才意识到的一件事。

11.1 Prompt 太长会带来什么 ​

  • 成本更高
  • 延迟更高
  • 规则冲突更多
  • 调试更难

11.2 当前官方资料给出的一个非常现实的方向 ​

OpenAI 当前 Prompt caching 和 API deployment checklist 都强调：

  • 稳定前缀能明显改善缓存命中
  • 动态用户内容更适合放后面
  • 高流量流程应稳定使用 prompt_cache_key

11.3 这对 Prompt 工程的启发很直接 ​

更稳的提示组织通常是：

  1. 静态 instructions 放前面
  2. 少变化的 examples 放前面
  3. tools / schema / policy 放前面
  4. 用户动态上下文放后面

如果你把动态字段、时间戳、用户画像、随机排序案例穿插在前半段，就会直接打碎缓存收益。

11.4 一个更像平台工程的缓存观察字段 ​

  • prompt_cache_key
  • cached_tokens
  • prompt_version
  • schema_version
  • toolset_hash

这样后面才能知道：

  • 分数变差是 Prompt 本身问题
  • 还是缓存 miss 导致延迟和截断一起变了

12. Prompt 不是越长越稳 ​

这是生产里最常见的误区之一。

Prompt 变长的常见原因包括：

  • 旧规则不敢删
  • 出过一个问题就补一条
  • 不同人追加不同要求
  • 迁移新模型时不敢删旧约束

结果往往是：

  • 自己都读不清
  • 冲突规则越来越多
  • 上下文成本越来越高
  • 模型行为越来越机械

12.1 更推荐的做法 ​

  • 少而清晰的规则
  • outcome-first 的目标表达
  • 明确分层
  • 把该由 schema、工具、权限做的事移出去

Prompt 最适合承载的是：

  • 任务意图
  • 边界
  • 输出要求
  • 风格和体验目标

不是把所有系统逻辑都塞进来。

12.2 reasoning 模型尤其要小心“过程过载” ​

OpenAI 当前 Reasoning best practices 明确提醒：

  • reasoning 模型不需要默认“think step by step”
  • 简单直接通常更好

所以碰到 reasoning 场景时，更值得先删掉无效流程性话术，而不是继续加。

13. 一个更实用的 Prompt 迭代流程 ​

OpenAI 当前 Evaluation best practices、Prompt optimizer 和 Model optimization 一起看，最值得保留的不是某个工具，而是这个飞轮：

text
Define Task Contract
 -> Write Prompt V1
 -> Add Schema / Tool Constraints
 -> Build Eval Cases
 -> Run Baseline
 -> Inspect Failure Buckets
 -> Adjust Prompt / Context / Schema / Tool Policy
 -> Re-evaluate
 -> Ship with version

13.1 Prompt optimizer 适合做什么 ​

OpenAI 当前 Prompt optimizer 更像一个：

  • 发现冲突
  • 收缩噪声
  • 生成更清晰初稿

的工具。

它适合：

  • 迁移旧 Prompt
  • 找 wording 冗余
  • 把含混任务改成更明确结构

但它不等于：

  • 自动替你完成生产级治理

13.2 Prompt generation 更适合什么 ​

OpenAI 当前还有 Prompt generation 指南，说明 Playground 已经支持从任务描述生成 prompt / schema / functions。

这更适合：

  • 冷启动草案
  • 从口头需求快速落雏形

但上线前仍然要回到：

  • contract
  • eval
  • failure buckets

13.3 这里最重要的一点 ​

不要把所有失败都归因到 Prompt。

每轮迭代都要先判断问题到底属于：

  • 任务定义
  • 上下文
  • Prompt
  • schema
  • 工具
  • 模型家族选择

这样改动才会越来越准。

14. Evals 平台会变，但 eval-driven 这件事不会变 ​

这是当前官方资料里一个容易被忽略的现实点。

OpenAI 当前 Working with evals 和 Graders 文档都明确写到：

  • 现有 evals / graders 平台正在走向弃用
  • 按当前文档口径，Evals 会在 2026-10-31 进入只读，并计划于 2026-11-30 关闭

这对 Prompt 工程真正重要的启发不是“以后不做评测了”，而是：

  • 不要把 Prompt 治理绑死在某一个特定评测产品表面

更稳的做法始终是保留这些核心资产：

  • 样本集
  • rubric
  • grader prompt
  • 失败分桶
  • 发布阈值
  • 回放证据

只要这些对象在，你换评测执行框架也不会把 Prompt 体系打散。

15. 什么样的 Prompt 更容易长期维护 ​

更推荐：

  • 任务边界清楚
  • 规则层次清楚
  • 输出要求清楚
  • 样例少而有效
  • 版本有记录
  • 与 schema / tool / eval 一起发布

不太推荐：

  • 所有规则混成一大段
  • 大量模糊描述
  • 同义要求反复出现
  • 没有异常路径说明
  • 把不同模型家族共用一个历史 Prompt 栈

15.1 一个更像发布对象的版本包 ​

你至少应该能回答：

  • 这次上线的是哪份 Prompt
  • 配的是什么模型
  • reasoning effort 是多少
  • 对应哪个 schema
  • 对应哪个工具定义
  • 是在哪个数据集上通过门禁的

如果这些答不上来，这个 Prompt 在工程上就还不是“资产”。

16. 企业里最常见的 Prompt 反模式 ​

  • 只调 wording，不改任务定义。
  • 只追求单样例惊艳效果。
  • 把 Prompt 当成万能胶。
  • 没有 eval 支撑改动。
  • 该用 schema 的地方继续靠自然语言。
  • 该做检索和权限治理的地方继续靠“请谨慎回答”。
  • tool-heavy 流程里不保留 phase 和 replay 语义。
  • 高流量系统里完全不考虑稳定前缀和缓存命中。

17. 这章最值得立刻补上的实践动作 ​

  1. 给每个 Prompt 先补任务 contract，不要再从“润色措辞”开始迭代。
  2. 把 Prompt、schema、tool definitions、reasoning effort 和 eval dataset 绑成同一组版本对象。
  3. 为 RAG、工具调用、审批、高风险路由分别建立 failure buckets，不要只看总体通过率。
  4. 检查高流量请求的前缀是否稳定，把静态 instructions 和 examples 挪到前面，把动态用户内容挪到后面。
  5. 为 reasoning 模型单独做一次 Prompt 减法，删掉不必要的 chain-of-thought 式流程提示。
  6. 为 tool-heavy 会话检查 previous_response_id、assistant replay 和 phase round-trip 是否正确。

18. 推荐搭配阅读 ​

19. 重点官方资源 ​

以下资源在 2026-07-09 复核时可访问：