OpenAI更新了自己的Prompt编写指南，这是 ChatGPT / ChatGPT Work / Codex 三个产品线的统一 prompt 指南。
编写者eric provencher：“
使用5.6 Sol时，很多人仍在沿用5.5版本的提示方式。
需要特别注意的是，5.6 Sol比之前的模型更加坚韧且细致。
请查看我编写的指南以获得更优结果。”
以下是文章翻译：
# 提示词
## 提示词概述
提示词是你用来告诉 ChatGPT 你想了解、创建或修改什么的方式。提示词可以是一个问题、一条指令，也可以是一个目标。你不需要使用技术化的语法或严格固定的公式。直接用自己的话开始，查看回复，然后通过后续消息逐步调整结果。
简短的提示词通常就足够了。对于规模更大或更重要的任务，可以加入真正关键的部分：
- **目标：** ChatGPT 应该做什么？
- **上下文：** 哪些信息或来源会有所帮助？
- **输出：** 你需要什么格式、篇幅或详细程度？
- **边界：** 哪些内容必须保持不变？ChatGPT 应避免什么，或在采取行动前先向你确认什么？
只使用对任务有帮助的部分即可。你不需要填写每一项，也不必遵循规定格式。
## 描述你需要的结果
先说明你想要的结果，而不是详细列出执行步骤。当受众或格式会影响 ChatGPT 的产出时，也请一并说明。
```text
把这些会议记录整理成一份给项目团队看的简短更新。
把决策和后续步骤放在最前面。
```
这条提示词说明了要创建什么，以及谁会阅读它。当过程本身很重要时，再描述过程。否则，应给 ChatGPT 留出空间，让它自行搜索、比较信息并调整处理方式。
## 添加有用的上下文
提供那些可能改变结果的信息。只加入真正相关的来源，并说明 ChatGPT 应从每个来源中提取什么。
- 当你希望 ChatGPT 总结、比较、转换文档，或创建可供审阅的文件时，可以附加文档、电子表格、演示文稿或 PDF 文件。
- 当任务依赖视觉信息时，可以添加截图、图表或其他图像输入。请指出需要关注的区域，而不要只让 ChatGPT 自行判断图像中的重点。
- 当答案依赖当前信息时，要求 ChatGPT 使用网页搜索；如果你需要核查结果，也应要求它提供来源。
- 当相关对话或任务需要共享文件、来源或本地文件夹时，可以使用项目。
### 使用已连接的来源
当 ChatGPT 可以访问已连接的来源时，请说明它应到哪里查找，以及需要查找什么。你不必逐一描述它应执行的每次搜索。
```text
使用云端硬盘中最新的项目计划，以及项目 Slack 频道中的相关决策和更新，准备一份状态更新。
```
使用已连接的来源需要相应的插件，其可用性可能取决于你的套餐和工作区设置。
### 使用插件
插件为 ChatGPT 提供可复用的指令，并让它连接 Google Drive、Gmail、Slack 和 GitHub 等工具。只需说明你需要的结果，让 ChatGPT 从可用工具中进行选择。若要指定某个插件，请在输入框中键入 `@`。
在 ChatGPT 中查找、安装和使用插件。
### 个性化 ChatGPT
对于希望在不同对话和任务中持续生效的偏好，请在 **设置 > 个性化** 中将其添加为自定义指令。只与当前任务有关的细节，则应保留在本次提示词中。
设置默认个性、个性化指令和其他应用偏好。
## 设置边界，避免实际问题
边界是少数几条必要指令，用于避免 ChatGPT 制造额外工作，或执行你本不打算进行的操作。当错误修改某项内容会导致结果无法使用，或者你希望在内容影响其他人之前先审阅时，应添加相应边界。
- 保持已批准的日期和预算数字不变。
- 只使用提供的来源。对于缺失信息应明确标注，不要猜测。
- 建议不得超出规定预算。
- 将消息准备为草稿，不要发送。
重点说明最重要的一两条边界即可。你不需要控制 ChatGPT 执行的每一个步骤。
## 让结果可以直接使用
告诉 ChatGPT 你打算如何使用结果。这有助于它选择合适的篇幅、详细程度和组织方式。
- 将内容整理成一页摘要，方便主管在会议前快速浏览。把决策和后续步骤放在最前面。
- 把这些笔记整理成一封跟进邮件，其中包含决策、负责人和截止日期。
- 创建一张清晰的计划支出与实际支出对比表，并突出显示超过 10% 的差异。
对于重要工作，可以要求 ChatGPT 在最后进行检查，例如确认每个行动项都有负责人和截止日期，或标记它无法核实的信息。随后，在使用或分享结果之前，请自行复核。
## 通过后续消息改进结果
你的第一条提示词不必完美。先查看结果，然后明确说明你想要的具体修改。
```text
让开头更直接，保留证据，并把建议移到背景信息之前。
```
你可以补充缺失的来源、纠正方向、要求另一种方案，或调整详细程度，而不必从头开始。
### 引导与排队
当 Codex 已在工作时，你可以不等当前任务完成就发送另一条消息：
- **引导（Steer）** 会把这条消息加入当前运行。可用于改变方向、补充遗漏的细节或提供新信息。
- **排队（Queue）** 会把这条消息保存到下一次运行。适合那些应等当前工作结束后再处理的后续请求。
在 ChatGPT 桌面应用中，可前往 **设置 > 通用 > 后续行为** 选择默认方式。排队的消息会显示在输入框上方，你可以编辑、重新排序、发送或删除。该设置页面还会显示相应快捷键，方便你针对单条消息临时使用另一种行为，而不更改默认设置。
在 Codex CLI 中，当 Codex 正在工作时，按 Enter 可引导当前轮次，按 Tab 可将消息排入下一轮。详细信息请参阅交互式快捷键。
## 组合这些要素
对于需要使用已连接来源的项目更新，一条完整的提示词可以写成：
```text
为周一的管理层会议准备一份一页式项目状态更新。使用云端硬盘中最新的项目计划，以及项目 Slack 频道中的相关决策和更新。
首先列出管理层需要作出的决策和后续步骤。总结进展、风险、负责人和截止日期。保持已批准的日期和预算数字不变。标记任何相互冲突或缺失的信息，不要发送或发布任何内容。
完成前，请检查每个后续步骤是否都有负责人和截止日期。
```
这条提示词涵盖了**目标**、**上下文**、**输出**和**边界**，并要求进行最终检查，而没有逐项规定每个执行步骤。
## 使用语音听写
在 ChatGPT 桌面应用中，当输入框可见时，按住 Ctrl+M，然后开始讲话。ChatGPT 会将语音转写到输入框中，方便你在发送前检查和编辑。
lightSrc="/images/codex/app/voice-dictation-light.webp"
darkSrc="/images/codex/app/voice-dictation-dark.webp"
maxHeight="400px"
class="my-8"
/>
## Chat 提示词示例
使用 Chat 处理问题、创意、草稿和日常决策。先说明你想要的结果，只在细节会改变答案时再补充说明。
### 理解一个主题
```text
向一个从未投资过的人解释复利是如何运作的。
使用一个具体示例，并解释你引入的所有金融术语。
```
### 起草并润色文字
```text
起草一封语气友好的邮件，说明我因出行无法参加这次邀请。
控制在 120 个英文单词以内，并为今后的活动保留可能性。
```
### 比较不同选项
```text
比较这两种手机套餐，使用者为每年出国旅行两次的个人用户。用表格展示重要差异，然后推荐其中一种并说明取舍。
```
### 制定实用计划
```text
规划五顿工作日晚餐，每顿准备时间不超过 30 分钟。避免使用花生，在多顿饭之间复用食材，最后提供一份合并后的购物清单。
```
## Work 提示词
使用 Chat 处理快速提问、简短改写、头脑风暴和轻量级草稿。对于需要综合不同来源或工具、包含一系列步骤、执行修改或生成较大交付成果的任务，则使用 Work。
对于 Work 任务，请描述你需要的结果，提供源材料，说明受众，并解释你将如何审阅成果。要求 ChatGPT 制定计划、收集所需信息、创建文件，并在完成前进行检查。
### 高效使用 Work
Work 适合耗时或重复性任务，也适合创建可重复使用的成品文件。即使某项任务消耗较多额度，只要它能节省时间、提高质量，或帮助你作出重要决策，通常仍然值得。
先从一个可供你审阅的结果开始：
- 只包含相关来源，并在适当时限制日期范围。
- 明确受众、输出格式和目标篇幅。
- 将必需工作与可选改进或润色分开。
- 当处理方法本身很重要时，要求 ChatGPT 先制定计划。在它发送、发布或修改其他人所依赖的信息之前，要求先获得你的批准。
- 如果任务开始处理你已经不再需要的工作，应缩小范围或停止任务。
审阅第一个结果，完善指令，并在流程有效时重复使用。
### 将源材料转化为成品文件
```text
使用附带的季度报告，创建一份管理层简报和一份六页演示文稿。
受众是高管团队。首先列出他们需要作出的三项决策，明确区分报告中的事实与分析判断，为每个数字引用其源文件，并在完成前检查简报和演示文稿是否一致。
```
### 研究一项决策
```text
为一家拥有 50 名员工的公司研究三种客户支持平台。使用当前来源比较价格、安全性、集成能力和迁移工作量。
交付一份建议备忘录，其中包含链接、假设，以及我们在签订合同前应回答的问题。
```
### 协调产品发布
```text
根据附带的产品简报创建一份发布计划。包括时间表、负责人、依赖关系、风险、公告草稿、客户常见问题，以及发布当天的检查清单。在生成最终文件前，标记所有尚未作出的决策。
```
对于重复性工作，应先在普通任务中完善提示词。输出稳定可靠后，再根据该任务安排定期工作。如果每次定时运行都应从一个新任务开始，则应创建独立的计划任务。
## 为 Codex 编写提示词
当你希望 ChatGPT 处理代码、代码库或开发者工具时，请使用 Codex。一条有效的 Codex 提示词应说明你希望实现的行为，指向相关代码或复现步骤，保留重要约束，并说明如何验证修改。
对于多步骤任务，如果希望 Codex 在编辑前先调查并提出方案，可在应用输入框中输入 `/plan`。当目标模式可用时，可在计划之后使用 `/goal` 设置一个持续有效的目标。当前命令列表请参阅应用斜杠命令。
### 如何阅读这些示例
每个工作流包括：
- **适用场景**，以及最合适的 Codex 使用界面（IDE、CLI 或云端）。
- 带有示例用户提示词的**步骤**。
- **上下文说明**：Codex 会自动看到哪些内容，以及你应附加哪些内容。
- **验证方法**：如何检查输出。
> **注意：** IDE 扩展会自动将你打开的文件作为上下文。在 CLI 中，请明确提及路径，或使用 `/mention` 和 `@` 路径自动补全来附加文件。
Codex 会在一个限制文件和网络访问权限的沙盒中运行本地命令。如果任务需要跨越该边界，Codex 会根据你的审批策略继续操作。
### 解释代码库
适用于入职新项目、接手某项服务，或需要理解协议、数据模型或请求流程的场景。
#### IDE 扩展工作流（本地探索的最快方式）
1. 打开最相关的文件。
2. 选择你关心的代码（可选，但建议这样做）。
3. 向 Codex 输入：
```text
解释请求是如何流经所选代码的。
包括：
- 对所涉及各模块职责的简短总结
- 哪些数据在何处得到验证
- 修改这些代码时需要注意的一两个“陷阱”
```
验证：
- 要求 Codex 提供可供核对的图示或检查清单：
```text
将请求流程概括为一个编号步骤列表，然后列出涉及的文件。
```
#### CLI 工作流（适合需要操作记录和 Shell 命令的情况）
1. 启动交互式会话：
```bash
codex
```
2. 附加文件（可选），然后输入提示词：
```text
我需要理解这项服务使用的协议。读取 @foo.ts 和 @schema.ts，解释其架构以及请求/响应流程。重点说明必填字段与可选字段，以及向后兼容规则。
```
上下文说明：
- 你可以在输入框中使用 `@` 插入工作区中的文件路径，也可以使用 `/mention` 附加特定文件。
### 修复错误
适用于存在可在本地复现的故障行为时。
#### CLI 工作流（紧凑的复现与验证循环）
1. 在代码仓库根目录启动 Codex：
```bash
codex
```
2. 向 Codex 提供复现步骤，以及你怀疑有问题的文件：
```text
错误：点击设置页面上的“保存”后，有时会显示“已保存”，但修改实际上没有持久化。
复现步骤：
1) 启动应用：npm run dev
2) 前往 /settings
3) 切换“启用提醒”
4) 点击“保存”
5) 刷新页面：开关恢复原状
约束：
- 不要更改 API 结构。
- 尽量保持修复范围最小；如可行，添加回归测试。
先在本地复现该错误，然后提出补丁并运行检查。
```
上下文说明：
- 由你提供：复现步骤和约束（它们比高层次描述更重要）。
- 由 Codex 提供：命令输出、发现的调用位置，以及它触发的任何堆栈跟踪。
验证：
- 修复后，Codex 应重新执行复现步骤。
- 如果你有标准检查流程，应要求它运行：
```text
修复后，运行 lint 和最小范围的相关测试套件。报告所执行的命令和结果。
```
#### IDE 扩展工作流
1. 打开你认为错误所在的文件，以及离它最近的调用方文件。
2. 向 Codex 输入：
```text
找出导致界面显示“已保存”但实际没有持久化修改的错误。提出修复方案后，告诉我如何在界面中验证它。
```
### 编写测试
当你希望明确界定测试范围时，可使用此工作流。
#### IDE 扩展工作流（基于所选代码）
1. 打开包含该函数的文件。
2. 选择定义该函数的代码行。在命令面板中选择“Add to Codex Thread”，将这些代码行加入上下文。
3. 向 Codex 输入：
```text
为这个函数编写单元测试。遵循其他测试中使用的惯例。
```
上下文说明：
- 由“Add to Codex Thread”命令提供：所选代码行（即“行号”范围），以及当前打开的文件。
#### CLI 工作流（在提示词中说明路径和行范围）
1. 启动 Codex：
```bash
codex
```
2. 在提示词中提供函数名称：
```text
为 @transform.ts 中的 invert_list 函数添加测试。覆盖正常路径和边界情况。
```
### 根据截图制作原型
适用于将设计稿、截图或界面参考图转化为可运行原型的场景。
#### CLI 工作流（图像 + 提示词）
1. 将截图保存到本地，例如 `./specs/ui.png`。
2. 运行 Codex：
```bash
codex
```
3. 将图像文件拖入终端，附加到提示词中。
4. 继续补充约束和结构要求：
```text
根据这张图片创建一个新的仪表板。
约束：
- 使用 React、Vite 和 Tailwind。代码使用 TypeScript 编写。
- 尽可能准确地匹配间距、排版和布局。
输出：
- 一个用于渲染该界面的新路由/页面
- 所需的少量组件
- 包含本地运行说明的 README.md
```
上下文说明：
- 图像提供视觉要求，但你仍需明确实现约束，例如框架、路由和组件风格。
- 对于图像无法展示的行为，应通过文字补充，例如悬停状态、验证规则或键盘交互。
验证：
- 要求 Codex 运行开发服务器（如允许），并明确告诉你应查看哪个位置：
```text
启动开发服务器，并告诉我用于查看该原型的本地 URL/路由。
```
#### IDE 扩展工作流（图像 + 现有文件）
1. 在 Codex 任务中附加图像（拖放或粘贴）。
2. 向 Codex 输入：
```text
创建一个新的设置页面。使用附带的截图作为目标界面。
遵循该项目其他文件中的设计和视觉模式。
```
### 通过实时更新迭代界面
适用于希望在 Codex 修改代码时形成紧凑的“设计 → 调整 → 刷新 → 再调整”循环的场景。
#### CLI 工作流（运行 Vite，然后用简短提示词反复迭代）
1. 启动 Codex：
```bash
codex
```
2. 在另一个终端窗口中启动开发服务器：
```bash
npm run dev
```
3. 要求 Codex 进行修改：
```text
为落地页提出 2～3 项样式改进建议。
```
4. 选择一个方向，并通过简短、具体的提示词进行迭代：
```text
采用方案 2。
只修改页眉：
- 让字体排版更具编辑设计感
- 增加留白
- 确保在移动端仍有良好效果
```
5. 继续用聚焦的请求反复调整：
```text
下一轮：减少视觉噪声。
保留布局，但简化颜色并移除所有多余边框。
```
验证：
- 在 Codex 更新代码时，通过浏览器查看修改效果。
- 提交你满意的修改，并还原你不满意的修改。
- 如果你还原或改动了某项编辑，请告诉 Codex，以免它在下一次处理提示词时覆盖你的修改。
### 将重构工作委托给云端
适用于先结合本地上下文设计方案，再将耗时实现工作委托给可并行运行的云端任务的场景。
#### 本地规划（IDE）
1. 确保当前工作已经提交，或至少已暂存，以便清晰比较修改。
2. 要求 Codex 制定重构计划。如果你可以使用 `$plan` 技能，请明确调用它：
```text
$plan
我们需要重构身份验证子系统，以实现：
- 拆分职责（令牌解析、会话加载和权限处理）
- 减少循环导入
- 提高可测试性
约束：
- 不改变任何用户可见行为
- 保持公共 API 稳定
- 包含分步骤迁移计划
```
3. 审阅计划并协商修改：
```text
修改计划，要求：
- 明确说明每个里程碑中要移动哪些文件
- 包含回滚策略
```
上下文说明：
- 当 Codex 能在本地扫描当前代码，包括入口点、模块边界和依赖关系图线索时，规划效果最好。
#### 云端委托（IDE → 云端）
1. 如果尚未完成设置，请先配置 Codex 云端环境。
2. 点击提示词输入框下方的云朵图标，然后选择你的云端环境。
3. 输入下一条提示词时，Codex 会在云端创建一个新任务，并继承现有任务上下文，包括计划和本地源代码修改。
```text
实施计划中的里程碑 1。
```
4. 审阅云端差异，并在需要时继续迭代。
5. 直接从云端创建 PR，或将修改拉取到本地进行测试和收尾。
6. 继续处理计划中的其他里程碑。
委托给云端的任务会在隔离环境中运行。除非你为该环境启用互联网访问，否则代理阶段的网络访问默认关闭。详情请参阅云端互联网访问。
### 进行本地代码审查
适用于在提交代码或创建 PR 前，希望获得第二方审查意见的场景。
#### CLI 工作流（审查工作区中的修改）
1. 启动 Codex：
```bash
codex
```
2. 运行审查命令：
```text
/review
```
3. 可选：提供自定义关注重点：
```text
/review 重点关注边界情况和安全问题
```
验证：
- 根据审查反馈应用修复，然后重新运行 `/review`，确认相关问题已经解决。
### 审查 GitHub 拉取请求
适用于希望在不将分支拉取到本地的情况下获得审查反馈的场景。
使用此功能前，需要在代码仓库中启用 Codex **代码审查**。请参阅代码审查。
#### GitHub 工作流（通过评论触发）
1. 在 GitHub 上打开拉取请求。
2. 发表评论，标记 Codex 并明确说明审查重点：
```text
@codex review
```
3. 可选：提供更明确的指令。
```text
@codex review for security vulnerabilities and security concerns
```
### 更新文档
适用于需要进行准确、清晰的文档修改时。
#### IDE 或 CLI 工作流（本地编辑 + 本地验证）
1. 找出需要修改的文档文件，并在 IDE 中打开，或在 IDE/CLI 中使用 `@` 提及它们。
2. 向 Codex 提供范围和验证要求：
```text
更新“高级功能”文档，加入身份验证故障排除指南。验证所有链接均有效。
```
3. Codex 起草修改后，审阅文档并根据需要继续迭代。
验证：
- 阅读渲染后的页面。
发布于 山东