openai-reusable-prompts

OpenAI 可复用提示词

概要

此技能专注于编写高质量提示词，并将其格式化，使其清晰、一致且更易于引导模型。

它有助于定义提示词结构、措辞质量、示例和格式模式，从而获得可靠的输出。

详细的 OpenAI 提示词工程指南请参阅 references。

适用场景

• 你希望提示词写得更好，并具有清晰的指令层级。
• 你需要在不同任务或团队之间统一提示词格式。
• 你希望使用包含有力示例和约束的可复用提示词模板。
• 你需要改进会产生不一致输出的模糊提示词。
• 你正在制定稳定、可重复的流程，供多个 Agent 或团队共同使用。
• 你希望行为可复用、可独立进行版本管理，并能随时间不断改进。

不适用场景

• 你需要的是 API 集成代码、部署或版本发布策略。
• 你需要的是运行时实现细节，而不是提示词编写指导。
• 这是一次性的请求，无需可复用的结构。
• 流程每天都在变化，尚未稳定。
• 任务主要依赖实时外部状态或副作用；请改用工具或 API。

必需输入

请提供或推断：

• 预期结果：提示词必须生成什么。
• 受众或任务类型：谁会使用输出，以及用于什么目的。
• 输出规范：自由文本、Markdown、JSON，或受架构约束的输出。
• 约束：风格、语气、安全限制和禁止行为。

如有需要，还应提供示例输入和预期输出。

如果缺少细节，只询问编写可用 v1 模板所必需的最少信息。

路由指南和边缘情况

• 对于可复用流程、稳定的写作标准或组织范围内的提示词规范，优先触发此技能。
• 如果用户要求的是无需严格结构的临时头脑风暴，则避免触发此技能。
• 在编写的提示词包中同时加入正面和负面示例，以提高路由准确性。
• 如果路由不一致，应先迭代 frontmatter 中的 name、description 和示例，再修改脚本或运行时代码。

流程

1. 定义目标行为

   • 为提示词写一句话目标。
   • 将成功定义为可观察的输出标准。

2. 设定指令层级

   • 将高优先级行为放在前面。
   • 区分必需规则与偏好。
   • 明确说明模型必须做什么、不得做什么。
   • 将可复用的应用规则放入 Responses API 的 instructions 参数或 developer 消息中；这些规则的优先级高于 user 输入。
   • 使用 previous_response_id 时，不要依赖先前轮次中的 instructions；请再次发送这些指令。

3. 采用一致的格式编写提示词

   • 在适用时，按以下顺序使用清晰的章节标题：Identity、Instructions、Examples、Context。
   • 保持指令明确且可测试。
   • 使用占位符表示动态值，例如 {{customer_name}}。
   • 将稳定且重复的内容放在靠前位置，以提高提示词缓存的收益。

4. 强化格式规范

   • 使用项目符号列表列出约束和输出规则。
   • 在有帮助时，使用 XML 风格的分隔符来标记输入／输出示例块。
   • 避免使用会隐藏要求的长段落。

5. 添加能说明行为的示例

   • 在示例确实能提高可靠性时，提供若干不同的示例，尤其适用于严格格式。
   • 涵盖常见输入和边缘输入。
   • 确保示例与已声明的规则一致。

6. 添加输出契约检查项

   • 明确指定格式要求（字段、顺序、允许的标签）。
   • 添加明确的禁止项，以减少偏离。

7. 修改措辞，使其清晰简洁

   • 删除冗余指令。
   • 将含糊的措辞替换为可衡量的要求。
   • 仅保留会影响模型决策的上下文。
   • 对于 GPT 模型，使用精确的指令。对于推理模型，先说明更高层级的目标，再根据评估结果按需补充细节。

8. 当提示词将作为技能制品使用时，添加运行准备说明

   • 说明何时使用、如何运行以及预期输出和注意事项。
   • 对脆弱的多步骤工作流，添加明确的验证步骤和输出检查。

分支逻辑

• 如果输出必须符合严格的架构： 使用明确的字段级格式规则和类似架构的示例。

• 如果行为因客户或地区设置而异： 保持全局规则稳定，并将特定地区的规则单独放在专用上下文块中。

• 如果提示词冗长且复杂： 清晰划分各个部分，并删除非必要的上下文。

• 如果任务需要大量推理且要求不够明确： 先说明目标和约束，再根据观察到的失败补充示例。

• 如果任务是确定性的，且对格式敏感： 使用严格的格式指令和高度具体的示例。

质量标准

满足以下所有条件时，技能运行才算完成：

• 提示词目标和输出契约均明确。
• 指令层级清晰（必须遵循与应当遵循的要求有别）。
• 各章节的格式一致。
• 示例能强化所需行为和格式。
• 已消除含糊措辞。
• 包含用于提高路由精确度的负面触发示例。
• 当工作流涉及多步骤执行时，已定义验证步骤和输出检查。
• 具有代表性的测试样例、测试和评估检查覆盖生产环境中的提示词变更。

API 部署指南

• 对于新的 OpenAI API 工作，请在应用代码中管理提示词，而不是使用可复用的提示词对象。
• 在功能附近保留一个精简的提示词构建器模块。
• 使用类型化的函数输入或架构来处理动态值。
• 将生成的 instructions 和 input 直接传递给 Responses API。
• 固定使用特定的生产模型快照，并在更改提示词或模型之前评估其行为。
• 通过常规部署控制发布更改；使用功能标志或配置分阶段发布。
• 可复用的提示词对象已弃用：其创建功能已于 June 3, 2026 降低优先级，v1/prompts 计划于 November 30, 2026 关闭。仅在处理现有提示词对象集成时使用 OpenAI 迁移指南。

Agent 技能打包

当提示词模板被打包为 Agent 技能，而不是 OpenAI API 提示词对象时，应用以下准则。

1. 确保技能易于发现。

   • 使用清晰的 frontmatter name 和 description。
   • 明确说明“适用情况”和“不适用情况”。
   • 除正例外，也要包含反例。

2. 保持系统提示词精简。

   • 将稳定、可复用的流程放入技能中。
   • 将全局策略和始终生效的行为放在系统提示词中。
   • 不要在系统提示词中重复完整的技能流程。

3. 将由脚本支持的技能设计成轻量级命令行工具。

   • 确保命令可从命令行运行。
   • 对关键状态和结果，要求标准输出具有确定性。
   • 遇到错误时应明确失败，并给出清晰的用法或验证错误信息。
   • 将输出写入已知且有文档说明的文件路径。

4. 在技能资源中加入完整示例。

   • 提供输入、命令和预期输出。
   • 覆盖常见情况以及至少一种边缘情况。

5. 添加明确的验证关卡。

   • 验证输出格式和必需字段。
   • 确认产物存在于预期路径。
   • 添加能够捕获未完成情况的检查。

6. 谨慎处理网络访问。

   • 尽可能优先选择不联网执行。
   • 如果必须访问网络，应使用严格的允许列表并明确限制数据外传。

7. 使用能够可靠完成多步骤工作流的模型。

   • 如果执行不稳定，应简化工作流并加强验证指导。

可复现性与版本管理

• 将提示词和提示词构建器纳入源代码管理，并通过代码审查进行更改。
• 如需保证可复现性，请固定使用特定的生产模型快照。
• 为提示词行为维护具有代表性的夹具、测试和评估套件。
• 随应用程序一起对提示词更改进行版本管理和部署；使用功能标志或配置分阶段发布。
• 如果也将此指南打包为 Agent 技能，请对该技能单独进行版本管理，不要与 API 提示词共用版本。

交付物

请提供：

1. 用于代码管理的 instructions 或 developer 消息的可复用提示词模板（流程步骤 1-4）
2. 提示词格式检查清单（流程步骤 6）
3. 改进后的示例集（良好示例和边缘情况；流程步骤 5）
4. 提示词重写说明，解释关键的清晰度改进（流程步骤 7）
5. 运行就绪说明（如何运行、预期输出、注意事项、验证检查；流程步骤 8）

代码管理的提示词模板

将此内容用作发送给 Responses API 的 instructions 值或 developer 消息。将其保存在源代码管理中，并放在所支持功能附近。

对于现有的已保存提示词对象，请将其迁移到代码中；不要创建新的可复用提示词对象。

# Identity

You are an assistant that {role-purpose}.

# Instructions

- Primary objective: {objective}
- Required constraints: {constraints}
- Output requirements: {format-rules}
- Never do: {prohibited-behaviors}

# Examples

<input id="example-1">
{example-input-1}
</input>
<output id="example-1">
{example-output-1}
</output>

# Context

{stable-reference-context}

技能编写附加模板（适用于可运行的技能工作流）

当提示词包将作为带有脚本或资源的技能执行时，请使用此配套模板。

# When to use

- {positive-trigger-1}
- {positive-trigger-2}

# Do not use when

- {negative-trigger-1}
- {negative-trigger-2}

# Inputs

- {input-contract}

# How to run

- {install-command}
- {run-command}

# Expected outputs

- {path-1}: {artifact-description}
- {path-2}: {artifact-description}

# Gotchas

- {failure-mode-1}
- {failure-mode-2}

# Verification checks

- {check-1}
- {check-2}

# Worked examples

<input id="example-1">
{example-input-1}
</input>
<run id="example-1">
{example-command-1}
</run>
<output id="example-1">
{example-output-1}
</output>

提示词格式检查清单

每次修订提示词时都使用此检查清单。

- [ ] Objective is one sentence and testable
- [ ] Required behavior is listed before optional preferences
- [ ] Output format is explicit and easy to verify
- [ ] Examples are diverse and included when they materially improve reliability
- [ ] Negative constraints are included
- [ ] Context is minimal and relevant
- [ ] No contradictory instructions
- [ ] "Use when" and "Do not use when" routing guidance is explicit
- [ ] At least one negative trigger example is included
- [ ] Prompt is code-managed, model snapshot is pinned when needed, and rollout intent is defined
- [ ] Verification steps and output checks are defined for multi-step workflows

提示词起始模板

• “在保留原意的前提下，使用身份、指令、示例、上下文几个部分重写此提示词：{prompt}。”
• “收紧此提示词，消除歧义并强制遵守以下格式：{format-rules}。”
• “添加高质量示例，以指导以下行为：{objective}。”
• “将这段冗长的段落式提示词改写为简洁、结构化且包含明确约束的提示词。”

防护措施

• 不要在提示词文本中包含机密或私人数据。
• 不要在多个部分混杂相互冲突的指令。
• 当精确性至关重要时，不要让输出格式含糊不清。
• 不要过度拟合单个示例；请使用多样化的示例。
• 不要在可复用的开发者指令中重复完整的技能流程。
• 不要依赖开放的网络访问，除非设置了严格的允许列表和明确的数据外传规则。
• 对于由脚本支持的工作流，不要让输出路径未定义。