Prompt Engineering（提示工程）

提示工程（Prompt Engineering） 是通过精心设计输入给 LLM 的文本（prompt），来引导模型产出更准确、更有用、更符合预期的结果的方法论。它不是“写一句聪明的话”，而是把身份、规则、示例、上下文、输出格式和验证方式组织成可维护的输入接口。

核心技术

零样本提示（Zero-shot）：直接描述任务，不给示例
少样本提示（Few-shot）：在 prompt 里提供少量输入/输出示例，让模型模式匹配。OpenAI 建议示例覆盖多样输入和期望输出；Anthropic 的建议是选择多样化的规范示例 而非冗长的边界情况列表——代表性覆盖比穷举边缘情况更有效
思维链（Chain-of-Thought, CoT）：要求模型逐步推理，再给出答案；对复杂推理任务提升显著
角色设定（Role Prompting）：给模型指定身份（“你是一位资深工程师”），影响输出风格和视角
结构化输出：要求 JSON、Markdown 等特定格式，便于下游处理；在 OpenAI API 中可用 Structured Outputs（结构化输出）把 JSON 格式要求提升为 schema 约束
上下文注入：把私有数据、检索结果、文件内容或任务选项放进 prompt，约束模型只基于给定材料回答；这与 Context Engineering（上下文工程）和 RAG 重叠

API 语境下的 Prompt 结构

在 OpenAI API 中，prompt 不只是单个字符串，而是按角色和字段组织的输入。developer message 通常承载应用开发者的规则、业务逻辑和输出约束；user message 承载终端用户的具体请求和参数。可以把它类比成“函数定义”和“函数参数”：前者定义行为边界，后者提供本次调用的数据。

OpenAI 的 Prompt Engineering 指南建议用 Markdown 标题、列表和 XML 标签标记逻辑边界。一个可维护的 developer message 通常包含：

Identity：助手的目的、角色、沟通风格和高层目标
Instructions：必须遵守的规则、禁止行为、工具调用方式和输出格式
Examples：典型输入与期望输出，用来校准任务模式
Context：本次任务需要的额外材料，如私有文档、检索结果、配置选项；通常放在后面，因为它随请求变化

这类结构化写法的价值不只在“模型更容易懂”，也在于人类能 review、测试和版本化 prompt。边界模糊的自然语言块很难维护；有章节、有标签、有示例的 prompt 更接近工程接口。

生产 Prompt 的版本化

OpenAI 在 API 文档中明确建议：生产 prompt 应放在应用代码中，而不是依赖可复用 prompt object。代码化 prompt 的好处是可以使用类型化输入、代码审查、测试、部署流程和 feature flag 来管理模型行为变更。

实践原则：

把 prompt builder 放在靠近业务功能的小模块里
用类型化函数参数或 schema 传入动态值，如客户数据、文件和任务选项
通过 Responses API（响应 API）的 instructions 和 input 传入生成后的 prompt
修改生产 prompt 前准备代表性 fixture、回归测试和 Evals（评估）
需要灰度时，用配置或 feature flag 控制 rollout

这说明提示工程已经从“对话技巧”变成软件工程资产：prompt 是代码的一部分，必须能 diff、review、测试和回滚。

与 Prompt Caching 的关系

Prompt 的组织顺序会影响 Prompt Caching（提示缓存）。OpenAI 建议把会在多次 API 请求中复用的内容放在 prompt 开头，并尽量作为请求 JSON 中靠前的参数传入。稳定的 developer instructions、工具 schema、格式规则和示例适合放在前缀；用户输入、检索材料和工具输出等高变化内容适合放在后面。

因此，“好 prompt”不仅是语义清楚，也要对成本和延迟友好。对长对话和 Agent 来说，随意修改早期指令会破坏缓存前缀；把动态内容追加到末尾，往往比重写整个 prompt 更稳。

针对不同模型的提示方式

OpenAI 文档区分了 GPT 系列模型和 reasoning model 的提示风格：

GPT 系列更受益于精确、完整、显式的指令，尤其是把完成任务所需的逻辑和数据写清楚
Reasoning model 更适合给高层目标和边界，允许模型自行推导细节；过细的过程指令反而可能限制表现

这与“一个最佳 prompt 模板适用于所有模型”的直觉相反。模型升级时，prompt 也应该重新评估，而不是机械复用旧模型时代的提示方式。这里需要用 Evals（评估）验证：改写 prompt 后到底是更好、更便宜，还是只是更复杂。

GPT-5.6：精简不等于删掉边界

GPT-5.6更能从上下文推断用户的目标和预期工作量，默认回答也比 GPT-5.5 更短。OpenAI 因此建议先检查旧 prompt 中重复的规则、样例和工具说明，而不是继续叠加模板。在一组内部 coding-agent eval 中，较精简的系统提示让分数约提高 10–15%，总 token 降低 41–66%，成本降低 33–67%；这些只是方向性区间，不能外推为所有任务都会受益。

可靠的精简方式是从一个已通过评估的 prompt 出发，每次只移除一组指令、示例或工具，再复跑同一批代表性任务。应当保留产品要求、已知失败模式的修正规则，以及任务必需的领域背景。尤其不能把“少写过程”误解为“少写控制”：目标、硬约束、授权边界、成功标准和输出格式仍然值得明确。

对 Agent，可把授权规则集中成一份紧凑策略：回答、解释、审查或规划时只检查材料并汇报；修改、构建或修复时可直接做范围内的本地变更与无破坏验证；外部写入、破坏性动作、购买或实质扩大范围时再请求确认。同一句“先问我”反复出现在多个位置，反而可能让模型对安全的预期动作也频繁停下来确认。

风格指令也应写成可观察的选择，而非只贴标签。例如，与其笼统要求“更简洁”，不如要求“先给结论，保留证据、重要 caveat 和下一步，优先删掉开场、重复与次要背景”；与其要求“更友善”，不如明确何时承认具体问题、何时需要安慰、是否省略客套收尾。这样既方便模型执行，也方便评估器判断是否达标。

Outcome-first 与停止条件

GPT-5.6 的提示指南把复杂任务的默认结构收敛为“定义目的地，而不是逐步遥控”。应先写用户可见结果、成功标准、证据要求、权限边界和输出形状，再让模型自己选择有效路径。过程规定只保留确实影响行为的部分；ALWAYS、NEVER、must 和 only 只用于真正不变的规则，搜索、追问、用工具或继续迭代这类判断应写成条件。

停止条件是 prompt contract 的一部分。一个实用规则是：每次获得结果后，判断核心请求是否已经能由有用证据支持；若能，立即作答；若仍缺必需事实，只执行能补齐该事实的最小回退。这样既避免无意义的工具循环，也不会让“少调用工具”压过正确性、计算、验证或引用要求。

复杂 prompt 可从以下短结构开始，再只在行为确实需要时加细节：

Role / Personality：模型在产品中的职责，以及语气与协作方式
Goal / Success criteria：用户可见结果和完成判据
Constraints：安全、业务、证据、授权和副作用边界
Tools：何时用哪些工具、前置检索和失败回退
Output：格式、长度、必须保留的信息
Stop rules：何时重试、收窄、追问、放弃或结束

人格、协作方式与回答长度

人格和协作方式是两个维度。人格决定温度、直接程度、正式程度、幽默和润色；协作方式决定何时追问、做假设、主动推进、解释取舍、检查结果和处理不确定性。两者都应写成少量可观察行为，不能代替目标、成功标准、工具路由和停止条件。

对 Responses API，可以用 text.verbosity 的 low、medium、high 设定默认细节级别，再用 prompt 说明本次任务必须保留的事实、决定、caveat 和下一步。当需要缩短答案时，先指定“不能删什么”，再指定优先删开场、重复、泛化安慰和可选背景；这比宽泛的“简洁”更稳定。

Grounding 与检索预算

需要来源支撑的回答，prompt 应说明哪些论断必须有证据、什么算证据充分，以及找不到证据时如何处理。普通问答可以先用一组短而有区分度的关键词做一次宽检索；只有缺少必需事实、负责人、日期、ID、指定材料，用户要求穷尽或比较，或重要论断仍无支持时，才追加检索。不要只为润色、补非必要例子或堆更多链接而继续搜索。

研究型任务还应要求：只引用实际取得的来源；引用紧贴所支持的论断；把推断与直接证据分开；披露来源冲突；证据不足时收窄结论，而不是把“没有找到”写成事实上的“不存在”。这把检索次数从模糊的“尽量查全”变成可评估的预算与停止规则。

Agent 任务中的提示工程

对于长运行 Agent 任务，OpenAI 的 GPT-5 系列提示建议强调三件事：

规划与持久执行：要求 Agent 分解任务，持续推进到问题真正解决，而不是完成一小段就停止
工具使用前言：在关键工具调用前简短说明为什么要调用，提升可观察性和人类协作体验
TODO 或 rubric 跟踪：用显式任务列表或评分标准防止遗漏步骤

这些技巧连接到 Loop Engineering（循环工程）和 Harness Engineering（驾驭工程）：prompt 可以要求模型规划、使用工具和跟踪进度，但真正可靠的 Agent 还需要外部 harness 提供工具、权限、测试、日志和停止条件。

OpenAI 的 Codex Prompting Guide 对 coding agent 给出了一个反向提醒：并不是所有“多沟通”都会提升效果。对 Codex-tuned 模型，如果 prompt 过度要求 rollout 期间输出 upfront plan、冗长 preamble 或状态更新，可能让模型在任务完成前过早停下。更稳的做法是让 starter prompt 明确自主性、持久执行、代码库探索和验证规则，同时由 harness 支持短而结构化的 preamble，并用 phase 等运行时元数据区分工作中更新和最终回答。

GPT-5.6 指南把可见更新进一步收窄为：首次工具调用前给一到两句 preamble，之后只在主要阶段切换或新发现改变计划时更新；每次说明一个具体结果和下一步，不逐条播报例行工具调用。若应用手动重放历史，必须保留 assistant item 原本的 phase；使用 previous_response_id 时，先前状态会自动延续。

模型与 Prompt 迁移

迁移到 GPT-5.6 时，应把模型、prompt、工具集和推理强度视为不同变量：

先切换模型，保留现有 reasoning effort，跑同一批代表性 eval
再逐组移除过时脚手架、重复规则和无关工具，每次修改后复测
只为已经观察到的回归添加最小、针对性的指令
reasoning effort 先测试原档位和低一档；只有 eval 显示显著收益时才提高到 high、xhigh 或 max

一次重写整套 prompt 会混淆因果：无法判断变化来自模型、推理配置、prompt、工具表面还是 runtime。调试回归时应读取少量真实 trace，定位具体失败模式和可能冲突的指令，做外科式修改后重跑原用例。

提示工程的局限

提示工程解决"如何有效地问 AI 一个问题"。它在以下场景下遇到瓶颈：

任务需要多轮迭代和自动重试
需要并行处理多个子任务
需要接入外部系统（GitHub、CI/CD、数据库）
状态需要跨会话保存
需要自动验证结果正确性

这些场景需要的不只是更好的 prompt，而是Loop Engineering（循环工程）——把 prompt 变成闭环系统里的一个零件。

OpenAI 对 Codex Goals 的表述也强调了这条边界：长程任务通常不需要一个更大的 prompt，而需要一个持久目标。Prompt 让模型知道下一步怎么做；Goal 让线程知道什么时候才算真正完成，以及应该用什么证据检查。

与循环工程的关系

维度	提示工程	循环工程
解决什么	如何问 AI	如何让 AI 持续做事、检查、修正、停止
人的角色	逐步提问和检查	设计系统，审查关键结果
规模	单次交互	多轮自动化循环
状态管理	在对话窗口内	外部文件/看板/数据库
验证方式	人工判断输出	独立测试/lint/构建

提示工程是Loop Engineering（循环工程）的基础——循环里的每次 Agent 调用背后都是一次精心设计的 prompt。但好的 prompt 只是必要条件，不是充分条件。

工程范式演进中的位置

提示工程是四阶段范式演进的起点：

提示工程 — 核心能力：语言表达
Context Engineering（上下文工程） — 核心能力：信息筛选与组织
Harness Engineering（驾驭工程） — 核心能力：系统设计与规则制定
Loop Engineering（循环工程） — 核心能力：目标定义与管理

后一层包含前一层，而不是替代。