OpenAI 官方 Prompt 指南
先说说 Prompting 的核心概念——你不需要背什么公式，也不用学技术语法。Prompt 就是一句话，可以是问题、指令，或者一个目标。用自己的话开头，看看 ChatGPT 的回复，然后再用后续消息把它修成你要的样子。一句短 prompt 往往就够了，任务更大或更重要时，带上关键的几块信息：
- ：ChatGPT 该做什么？
目标（Goal）
- ：哪些信息或来源能帮上忙？
上下文（Context）
- ：你需要什么格式、多长、多细？
输出（Output）
- ：哪些东西不能动？哪些事 ChatGPT 该避开，或者动手前先来问你？
边界（Boundaries）
只用对你有帮助的部分就行，不需要每一项都填，也没有什么必须遵守的格式。
描述你要的结果
从结果说起，不要从一长串步骤说起。当受众或格式会影响产出时，把它们写进去。
例如：
把这些会议记录整理成一份给项目组的简短进展通报。决策和下一步行动放在最前面。
这条 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 会先按你的审批策略来，再继续。
解释一个代码库
适用场景：刚加入项目、接手一个服务，或者想搞清楚某个协议、数据模型、请求链路。
IDE 插件工作流（本地探索最快）
- 打开最相关的文件。
- 选中你关心的代码（可选，但推荐）。
- 给 Codex 下 prompt：
解释请求是怎么流经这段选中代码的。包含：涉及的每个模块，职责的简短总结。哪些数据在哪里被校验。改这段代码时要留神的一两个「坑」。
验证方式：
把请求链路总结成一个带编号的步骤列表，然后列出涉及的文件。
CLI 工作流（想要完整记录和 shell 命令时好用）
- 启动一个交互会话：
codex - 附上文件（可选），然后下 prompt：
我需要理解这个服务用的协议。读一下 @foo.ts @schema.ts 和解释 schema 和请求/响应链路。重点讲必填字段和可选字段的区别，以及向后兼容的规则。
上下文说明：
@ 插入工作区的文件路径，或者用 /mention 附上指定文件。
修一个 bug
适用场景：你手头有一个能在本地复现的异常行为。
CLI 工作流（复现和验证的闭环最紧）
- 在仓库根目录启动 Codex：
codex - 给 Codex 一份复现配方，加上你怀疑的文件：
Bug：在设置页点「保存」，有时显示「已保存」，但改动没有真正落盘。复现步骤：1）启动应用：npm run dev。2）打开 /settings。3）切换「启用提醒」开关。4）点保存。5）刷新页面：开关弹回去了。约束：不要改 API 的形状。修复保持最小化，可行的话加一个回归测试。先在本地复现这个 bug，然后提出补丁并跑检查。
上下文说明：
- 你来提供：复现步骤和约束（这比一段高层描述有用得多）。
- Codex 来提供：命令输出、找到的调用点，以及它触发的堆栈信息。
验证方式：
修完之后，跑 lint 加上最小相关的测试集。报告用了哪些命令、结果如何。
IDE 插件工作流
- 打开你觉得 bug 所在的文件，加上离它最近的调用方。
- 给 Codex 下 prompt：
找到那个显示「已保存」却没真正保存的 bug。提出修复方案之后，告诉我怎么在界面上验证。
写一个测试
适用场景：你想精确圈定要测的范围。
IDE 插件工作流（基于选中代码）
- 打开包含那个函数的文件。
- 选中定义这个函数的那几行。在命令面板里选「Add to Codex Thread」，把这几行加进上下文。
- 给 Codex 下 prompt：
给这个函数写一个单元测试，遵循其他测试里的惯例。
上下文说明：
CLI 工作流（在 prompt 里写路径和行范围）
- 启动 Codex：
codex - 在 prompt 里点名函数：
给 @transform.ts 里的 invert_list 函数加一个测试。覆盖正常路径，加上边界情况。
从一张截图做原型
适用场景：想把设计稿、截图或界面参考图变成能跑的原型。
CLI 工作流（图 + prompt）
- 把截图存到本地（比如
./specs/ui.png）。 - 运行 Codex：
codex - 把图片文件拖进终端，附到 prompt 上。
- 接着给出约束和结构：
照这张图做一个新的 dashboard。约束：用 react、vite 和 tailwind，代码写 typescript。间距、字体和布局尽量贴近原图。产出：一个渲染这个界面的新路由 /页面。需要用到的小组件。一份 README.md，写明本地怎么跑起来。
上下文说明：
- 图片给的是视觉要求，实现层面的约束（框架、路由、组件风格）还是要你自己写清。
- 图里看不出来的行为要用文字补上，比如悬停状态、校验规则、键盘交互。
验证方式：
启动开发服务器，告诉我在本地哪个 URL/路由能看到原型。
IDE 插件工作流（图 + 已有文件）
- 在 Codex 任务里附上图片（拖拽或粘贴都行）。
- 给 Codex 下 prompt：
做一个新的设置页。以附件截图为目标界面，遵循这个项目里其他文件的设计和视觉模式。
边看边改，迭代 UI
适用场景：想要一个「设计 → 微调 → 刷新 → 再微调」的紧凑循环，Codex 在旁边改代码。
CLI 工作流（先跑 Vite，再用小 prompt 迭代）
- 启动 Codex：
codex - 另开一个终端窗口，启动开发服务器：
npm run dev - 让 Codex 提改动：
给落地页提两三个样式改进方案。
- 挑一个方向，用小而具体的 prompt 迭代：
就按方案二来。只改头部：字体排印做得更有杂志感。留白加大。保证移动端依然好看。
- 用聚焦的请求重复这个过程：
下一轮：降低视觉噪音。布局保持，颜色做减法，多余的边框都去掉。
验证方式：
- Codex 改代码的同时，在浏览器里看效果。
- 喜欢的改动就提交，不喜欢的就回滚。
- 你回滚或者手改了某处，要告诉 Codex，免得它跑下一条 prompt 时把你的修改覆盖掉。
把重构交给云端
适用场景：想借着本地上下文把方案设计好，再把漫长的实现交给一个能并行跑的云端任务。
本地规划（IDE）
- 确保手头的工作已经提交，至少 stash 起来，之后才能干净地比对改动。
- 让 Codex 出一份重构计划。如果有
$plan这个 skill，显式调用它：
$plan 我们要重构鉴权子系统，目标：拆分职责（token 解析、会话加载、权限各归各）。减少循环引用。提升可测试性。约束：用户可见的行为不能变。公开 API 保持稳定。给出分步骤的迁移计划。
- 审这份计划，跟它讨价还价：
修改计划：每个里程碑具体动哪些文件，写明白。再加一份回滚策略。
上下文说明：
云端委派（IDE → 云端）
- 还没配的话，先配一个 Codex 云环境。
- 点输入框下方的云图标，选中你的云环境。
- 你输入下一条 prompt 时，Codex 会在云端新建一个任务，带上现有任务的上下文（包括计划和本地的源码改动）。
实现计划里的里程碑一。
- 审云端的 diff，需要就再迭代。
- 直接从云端建 PR，或者把改动拉到本地测试收尾。
- 按计划推进后续里程碑。
交给云端的任务在隔离环境里跑。agent 执行阶段默认断网，除非你给这个环境开了网络。细节见云端网络访问文档。
做一次本地 code review
适用场景：提交或建 PR 之前，想找双眼睛帮你把把关。
CLI 工作流（审查你的工作区）
- 启动 Codex：
codex - 跑审查命令：
/review - 可选：给出自定义的关注点：
/review 重点看边界情况和安全问题。
验证方式：
/review，确认问题都解决了。
审一个 GitHub PR
适用场景：不想把分支拉到本地，也想拿到审查反馈。
用之前，先在你的仓库上启用 Codex 的 Code review 功能。见 Code review 文档。
GitHub 工作流（靠评论驱动）
- 在 GitHub 上打开那个 PR。
- 留一条评论 @ Codex，写明关注点：
@codex review
- 可选：给更明确的指令。
@codex review 重点审安全漏洞和安全隐患。
更新文档
适用场景：需要一次准确、清晰的文档修改。
IDE 或 CLI 工作流（本地改 + 本地验证）
- 找到要改的文档文件，打开它们（IDE），或者用
@提到它们（IDE 和 CLI 都行）。 - 给 Codex 下 prompt，写明范围和验证要求：
更新「高级功能」文档，补充鉴权排障指引。检查所有链接都有效。
- Codex 起草完改动之后，审一遍文档，需要就继续迭代。