OpenAI 官方 Prompt 指南

先说说 Prompting 的核心概念——你不需要背什么公式，也不用学技术语法。Prompt 就是一句话，可以是问题、指令，或者一个目标。用自己的话开头，看看 ChatGPT 的回复，然后再用后续消息把它修成你要的样子。一句短 prompt 往往就够了，任务更大或更重要时，带上关键的几块信息：

• 目标（Goal）
  ：ChatGPT 该做什么？

• 上下文（Context）
  ：哪些信息或来源能帮上忙？

• 输出（Output）
  ：你需要什么格式、多长、多细？

• 边界（Boundaries）
  ：哪些东西不能动？哪些事 ChatGPT 该避开，或者动手前先来问你？

只用对你有帮助的部分就行，不需要每一项都填，也没有什么必须遵守的格式。

描述你要的结果

从结果说起，不要从一长串步骤说起。当受众或格式会影响产出时，把它们写进去。

例如：

把这些会议记录整理成一份给项目组的简短进展通报。决策和下一步行动放在最前面。

这条 prompt 说清了要产出什么、给谁看。只有当过程本身重要时，才去描述过程。其他时候，给 ChatGPT 留出空间，让它自己去搜索、比对信息、调整做法。

补充有用的上下文

把可能改变结果的信息给它。只加真正相关的来源，并且说明每个来源里 ChatGPT 该取什么。

想让 ChatGPT 总结、比对、转换内容，或者生成待审阅的文件时，附上文档、电子表格、演示文稿或 PDF。

任务依赖视觉信息时，加一张截图、示意图或其他图片输入。指出图里关键的区域，不要只把图丢过去。

答案依赖最新信息时，让 ChatGPT 用网页搜索。需要核对结果时，让它给出来源。

相关的对话或任务需要共享文件、来源或本地文件夹时，用 project 来组织。

使用已连接的数据源

当 ChatGPT 能访问已连接的数据源时，点名它该去哪找、找什么。不需要把每一次检索都描述出来。

例如：

用 Drive 里最新的项目计划，加上项目 Slack 频道里相关的决策和进展，准备一份状态通报。

已连接的数据源需要对应的插件，能不能用还取决于你的订阅方案和工作区设置。

使用插件

插件给 ChatGPT 提供可复用的指令，以及到 Google Drive、Gmail、Slack、GitHub 这类工具的连接。直接说你要的结果，让 ChatGPT 从可用的工具里自己挑。想指定某个插件，在输入框里输入 @。

个性化 ChatGPT

需要在所有对话和任务里生效的偏好，放进「设置 > 个性化」的自定义指令。只对当前任务有用的细节，写在 prompt 里。

设定能防住真麻烦的边界

边界是那么几条指令，用来防止 ChatGPT 制造额外的工作，或者做出你没打算让它做的动作。什么时候加？改错一个细节结果就没法用的时候，或者某件事影响到别人之前你想先过目的时候。

例如：

• 已批准的日期和预算数字保持不动。
• 只用我提供的来源。信息缺了就标出来，不要猜。
• 建议控制在说好的预算之内。
• 把消息准备成草稿，不要发出去。

盯住最要紧的一两条边界就好，不需要控制 ChatGPT 走的每一步。

让结果拿来就能用

告诉 ChatGPT 你打算怎么用这个结果，它就能选对长度、详细程度和组织方式。

例如：

• 做成一页纸的摘要，让总监开会前扫一眼就行。决策和下一步放最前面。
• 把这些笔记整理成一封跟进邮件，写清决策、负责人和截止日期。
• 做一张计划支出和实际支出的对照表，差异超过 10% 的都标出来。

重要的工作，让 ChatGPT 收尾时做一次终检，比如确认每个行动项都有负责人和截止日期，或者把它没法核实的信息标出来。然后你自己再过一遍，再去用、再去分享。

用追问改进结果

第一条 prompt 不需要完美。看完结果，把你想要的具体改动说出来。

例如：

开头写得更直接一点，证据保留，把建议挪到背景部分的前面。

你可以补一个漏掉的来源、纠正方向、再要一个方案，或者调整详细程度，不用从头再来。

Steer 与 Queue

Codex 干活的时候，你不用等当前这轮跑完，就能发下一条消息：

• Steer（转向）
  ：把消息加进当前这一轮。用来改方向、补细节、给新信息。

• Queue（排队）
  ：把消息留到下一轮。适合那些该等当前工作干完再说的追问。

在 ChatGPT 桌面应用里，默认行为在「设置 > 通用 > 追问行为」里选。排队中的消息显示在输入框上方，可以编辑、调整顺序、发送或删除。这个设置页还会显示一个快捷键，让你在不改默认的前提下，单条消息临时用另一种行为。

在 Codex CLI 里，Codex 工作时按 Enter 是 steer 当前这一轮，按 Tab 是把消息 queue 到下一轮。细节见交互快捷键文档。

把这些拼在一起

一份用到已连接数据源的项目通报，完整的 prompt 大概长这样：

为周一的管理层会议准备一份一页纸的项目状态通报。用 Drive 里最新的项目计划，加上项目 Slack 频道里相关的决策和进展。管理层需要拍板的决策和下一步行动放在最前面。总结进度、风险、负责人和截止日期。已批准的日期和预算数字保持不动。有冲突或缺失的信息就标出来，任何东西都不要发送或发布。收尾前，检查每个下一步都有负责人和截止日期。

这条 prompt 覆盖了

、、和，最后要了一次终检，但没有把每一步都写死。

使用语音听写

在 ChatGPT 桌面应用里，输入框可见时按住 Ctrl+M，然后开口说话。ChatGPT 会把你说的话转写进输入框，发送前可以检查和修改。

输入框里的语音听写指示条，转写好的 prompt 就在里面。

Chat 的 prompt 示例

Chat 适合提问、找点子、打草稿和日常决策。从你想要的结果说起，细节只在它会改变答案的时候再加。

理解一个话题

给一个从没投资过的人解释复利是怎么回事。用一个具体的例子，你引入的金融术语都要给出定义。

起草和打磨文字

起草一封友好的邮件，婉拒这个邀请，理由是我届时在外出差。控制在 120 词以内，给以后的活动留个口子。

比较选项

帮一个每年出国两次的人比较这两个手机套餐。重要差异用表格列出来，然后推荐一个，说清代价在哪。

做一个实用的计划

规划五顿工作日晚餐，每顿 30 分钟以内做完。不要花生，食材尽量跨餐复用，最后汇总成一张购物清单。

Work 的 prompt 写法

快问快答、小段改写、头脑风暴、轻量草稿，用 Chat。需要调多个来源或工具、包含一串步骤、要做修改、或者要产出较大交付物的任务，用 Work。

Work 任务里，描述你要的结果，给出源材料，点名受众，说明你会怎么审这份活。让 ChatGPT 先规划、再收集所需信息、生成文件，收尾前自查一遍。

高效使用 Work

Work 适合耗时的活、重复出现的活，以及能复用的成品文件。一个任务多花些 credits 也可能划算，只要它省了时间、提了质量，或者帮你做成了一个重要决定。

从一个你审得过来的结果开始：

• 只带相关的来源，合适的话限定日期范围。
• 定好受众、输出格式和期望长度。
• 把必须做的活，和可选的优化、润色分开。
• 做法本身重要时，先要一份计划。ChatGPT 发送、发布或修改别人依赖的信息之前，必须经你批准。
• 它开始干你不再需要的活时，收窄任务，或者直接叫停。
• 审第一版结果，打磨指令，跑通了就复用这套流程。

把源材料变成成品文件

用附件里的季度报告，做一份管理层简报和一份六页的演示文稿。受众是高管团队。开头先给他们需要拍板的三个决策，报告里的事实和你的分析要区分开，每个数字都注明来源文件，收尾前检查简报和幻灯片口径一致。

为一个决策做调研

为一家 50 人的公司调研三个客服平台。用最新的资料比较定价、安全性、集成能力和迁移成本。产出一份推荐备忘录，附上链接、假设，以及签合同前我们该回答的问题。

协调一次发布

根据附件里的产品简报做一份发布计划。包含时间线、负责人、依赖项、风险、公告草稿、客户 FAQ 和发布日检查清单。产出最终文件之前，把还没定的决策标出来。

重复性的工作，先在普通任务里把 prompt 打磨好。输出稳定之后，从那个任务里设置定时执行。如果每次定时运行都该新开一个任务，就单独建一个定时任务。

Codex 的 prompt 写法

想让 ChatGPT 处理代码、代码库或者开发者工具，用 Codex。一条有用的 Codex prompt 会写明你要的行为，指向相关代码或复现步骤，保住重要的约束，并说清怎么验证这次改动。

多步骤任务，想让 Codex 先调查、先提方案再动手改，就在应用输入框里输 /plan。Goal 模式可用时，计划定了之后用 /goal 设一个持续目标。当前的命令列表见应用的斜杠命令文档。

怎么读这些示例

每个工作流都包含：

• 什么时候用，
  以及哪个 Codex 载体最合适（IDE、CLI 还是云端）。

• 步骤，
  配上用户 prompt 示例。

• 上下文说明：
  哪些是 Codex 自动能看到的，哪些需要你自己附上。

• 验证方式：
  怎么检查产出。

注意：IDE 插件会自动把你打开的文件带进上下文。CLI 里要显式提到路径，或者用 /mention 和 @ 路径补全来附文件。

Codex 在一个限制文件和网络访问的沙箱（sandbox）里跑本地命令。任务需要越过这条边界时，Codex 会先按你的审批策略来，再继续。

解释一个代码库

适用场景：刚加入项目、接手一个服务，或者想搞清楚某个协议、数据模型、请求链路。

1. 打开最相关的文件。
2. 选中你关心的代码（可选，但推荐）。
3. 给 Codex 下 prompt：

解释请求是怎么流经这段选中代码的。包含：涉及的每个模块，职责的简短总结。哪些数据在哪里被校验。改这段代码时要留神的一两个「坑」。

让它给一份你能核对的图或清单：

把请求链路总结成一个带编号的步骤列表，然后列出涉及的文件。

1. 启动一个交互会话：codex
2. 附上文件（可选），然后下 prompt：

我需要理解这个服务用的协议。读一下 @foo.ts @schema.ts 和解释 schema 和请求/响应链路。重点讲必填字段和可选字段的区别，以及向后兼容的规则。

输入框里可以用 @ 插入工作区的文件路径，或者用 /mention 附上指定文件。

修一个 bug

适用场景：你手头有一个能在本地复现的异常行为。

1. 在仓库根目录启动 Codex：codex
2. 给 Codex 一份复现配方，加上你怀疑的文件：

Bug：在设置页点「保存」，有时显示「已保存」，但改动没有真正落盘。复现步骤：1）启动应用：npm run dev。2）打开 /settings。3）切换「启用提醒」开关。4）点保存。5）刷新页面：开关弹回去了。约束：不要改 API 的形状。修复保持最小化，可行的话加一个回归测试。先在本地复现这个 bug，然后提出补丁并跑检查。

• 你来提供：复现步骤和约束（这比一段高层描述有用得多）。
• Codex 来提供：命令输出、找到的调用点，以及它触发的堆栈信息。

修完之后，Codex 应该重跑一遍复现步骤。如果你有标准的检查流水线，让它跑一下：

修完之后，跑 lint 加上最小相关的测试集。报告用了哪些命令、结果如何。

1. 打开你觉得 bug 所在的文件，加上离它最近的调用方。
2. 给 Codex 下 prompt：

找到那个显示「已保存」却没真正保存的 bug。提出修复方案之后，告诉我怎么在界面上验证。

写一个测试

适用场景：你想精确圈定要测的范围。

1. 打开包含那个函数的文件。
2. 选中定义这个函数的那几行。在命令面板里选「Add to Codex Thread」，把这几行加进上下文。
3. 给 Codex 下 prompt：

给这个函数写一个单元测试，遵循其他测试里的惯例。

「Add to Codex Thread」命令提供：选中的那几行（也就是「行号」级别的范围），加上已打开的文件。

1. 启动 Codex：codex
2. 在 prompt 里点名函数：

给 @transform.ts 里的 invert_list 函数加一个测试。覆盖正常路径，加上边界情况。

从一张截图做原型

适用场景：想把设计稿、截图或界面参考图变成能跑的原型。

1. 把截图存到本地（比如 ./specs/ui.png）。
2. 运行 Codex：codex
3. 把图片文件拖进终端，附到 prompt 上。
4. 接着给出约束和结构：

照这张图做一个新的 dashboard。约束：用 react、vite 和 tailwind，代码写 typescript。间距、字体和布局尽量贴近原图。产出：一个渲染这个界面的新路由 /页面。需要用到的小组件。一份 README.md，写明本地怎么跑起来。

• 图片给的是视觉要求，实现层面的约束（框架、路由、组件风格）还是要你自己写清。
• 图里看不出来的行为要用文字补上，比如悬停状态、校验规则、键盘交互。

让 Codex 把开发服务器跑起来（如果允许的话），并告诉你具体看哪里：

启动开发服务器，告诉我在本地哪个 URL/路由能看到原型。

1. 在 Codex 任务里附上图片（拖拽或粘贴都行）。
2. 给 Codex 下 prompt：

做一个新的设置页。以附件截图为目标界面，遵循这个项目里其他文件的设计和视觉模式。

边看边改，迭代 UI

适用场景：想要一个「设计 → 微调 → 刷新 → 再微调」的紧凑循环，Codex 在旁边改代码。

1. 启动 Codex：codex
2. 另开一个终端窗口，启动开发服务器：npm run dev
3. 让 Codex 提改动：

给落地页提两三个样式改进方案。

4. 挑一个方向，用小而具体的 prompt 迭代：

就按方案二来。只改头部：字体排印做得更有杂志感。留白加大。保证移动端依然好看。

5. 用聚焦的请求重复这个过程：

下一轮：降低视觉噪音。布局保持，颜色做减法，多余的边框都去掉。

• Codex 改代码的同时，在浏览器里看效果。
• 喜欢的改动就提交，不喜欢的就回滚。
• 你回滚或者手改了某处，要告诉 Codex，免得它跑下一条 prompt 时把你的修改覆盖掉。

把重构交给云端

适用场景：想借着本地上下文把方案设计好，再把漫长的实现交给一个能并行跑的云端任务。

1. 确保手头的工作已经提交，至少 stash 起来，之后才能干净地比对改动。
2. 让 Codex 出一份重构计划。如果有 $plan 这个 skill，显式调用它：

$plan 我们要重构鉴权子系统，目标：拆分职责（token 解析、会话加载、权限各归各）。减少循环引用。提升可测试性。约束：用户可见的行为不能变。公开 API 保持稳定。给出分步骤的迁移计划。

3. 审这份计划，跟它讨价还价：

修改计划：每个里程碑具体动哪些文件，写明白。再加一份回滚策略。

规划这一步，Codex 能在本地扫当前代码时效果最好（入口、模块边界、依赖图线索）。

1. 还没配的话，先配一个 Codex 云环境。
2. 点输入框下方的云图标，选中你的云环境。
3. 你输入下一条 prompt 时，Codex 会在云端新建一个任务，带上现有任务的上下文（包括计划和本地的源码改动）。

实现计划里的里程碑一。

4. 审云端的 diff，需要就再迭代。
5. 直接从云端建 PR，或者把改动拉到本地测试收尾。
6. 按计划推进后续里程碑。

交给云端的任务在隔离环境里跑。agent 执行阶段默认断网，除非你给这个环境开了网络。细节见云端网络访问文档。

做一次本地 code review

适用场景：提交或建 PR 之前，想找双眼睛帮你把把关。

1. 启动 Codex：codex
2. 跑审查命令：/review
3. 可选：给出自定义的关注点：

/review 重点看边界情况和安全问题。

按审查反馈修完，再跑一遍 /review，确认问题都解决了。

审一个 GitHub PR

适用场景：不想把分支拉到本地，也想拿到审查反馈。

用之前，先在你的仓库上启用 Codex 的 Code review 功能。见 Code review 文档。

1. 在 GitHub 上打开那个 PR。
2. 留一条评论 @ Codex，写明关注点：

@codex review

3. 可选：给更明确的指令。

@codex review 重点审安全漏洞和安全隐患。

更新文档

适用场景：需要一次准确、清晰的文档修改。

1. 找到要改的文档文件，打开它们（IDE），或者用 @ 提到它们（IDE 和 CLI 都行）。
2. 给 Codex 下 prompt，写明范围和验证要求：

更新「高级功能」文档，补充鉴权排障指引。检查所有链接都有效。

3. Codex 起草完改动之后，审一遍文档，需要就继续迭代。

读一遍渲染后的页面。