大家好,我是 cxuan。
大家应该都知道了,GPT-5.6 全量上线之后,Codex 也迎来了大改版,OpenAI 刚开始是把 Codex 改为了 ChatGPT Codex ,然后网上吐槽的声音太多,OpenAI 不得已又改回了 Codex 。
但大家兴许不知道,Codex 这次改版之后,官方手册上新了一个《Prompt 指南》 :为 Chat、ChatGPT Work 和 Codex 编写有用的提示词。
我也是把 OpenAI 的 Prompting 官方文档 从头到尾读了一遍。
然后就有了这篇文章,废话不多说,直接进入正题!
提示词概述
首先官方直接给出了 Prompt 的定义:
Prompt 是你用来告诉 ChatGPT 你想要了解、制作或者修改什么的方式。Prompt 既可以是一个问题、也可以是一项指令或者一个目标。你无需使用编程领域内偏技术性的语法或死板的公式,只需要用自然的语言进行描述,LLM 会根据你的语言执行相关的操作步骤,执行完成后你可以查看结果,后续可以经过多轮对话来调整和完善结果。
这其实就是官方的定义了,有些教科书式。但其实也比较好理解,之前我们编写各种代码,学的各种语言,其实都是在用程序化的语言来和计算机打交道,现在不必这么复杂了,你只需要用自然语言,就可以跟计算机打交道了。这种方式也正是我们俗称的 vibe coding 。
一般情况下,Prompt 写很短的提示词就够了。
比如
| 请继续执行
启动一下 你怎么又给我搞崩了? 请恢复上一个版本 好的 |
但是对于庞大和更重要的内容,需要包括一些关键的部分,比如下面四个要素
Goal(目标) :ChatGPT 应该做什么?
Context(上下文):哪些信息和资源会有帮助?
Output(输出):你需要什么样格式、长度和详细程度的文件?
Boundaries(边界条件):哪些内容必须保持不变?ChatGPT 应该避免哪些问题,或者执行前需要与你确定那些事情?
这四个要素并不是要你所有的 prompt 都加上,针对不同的场景加上对应的即可。
描述你需要的结果
官方第一条建议是:先从结果开始,不要着急给 AI 安排每一个步骤。
比如你拿到一份会议记录,需要给项目组同步,可以这样写:
| 把这些会议记录整理成一份简短的项目进展通报,供项目团队阅读。把已经确定的决策和下一步计划放在最前面。 |
这句话交代了要做什么、给谁看,以及内容怎么排序。至于先提取决策,还是先整理时间线,可以留给 ChatGPT 自己判断。
比如让 Codex 改 Bug 的时候,可以要求它先复现一下 bug ,再定位原因,修改后重新执行复现步骤并运行测试。
财务分析可以规定数据口径,法律材料可以限定资料来源。
普通改写和总结,只要把结果交代清楚即可。
添加有用的上下文
上下文不是把所有资料一股脑扔给 ChatGPT,你需要提供会改变结果的信息,并说明每份资料拿来做什么。
假设你上传了公司品牌手册、产品功能清单和去年的销售报告,只说一句参考附件重写产品介绍,ChatGPT 很难判断三份文件以哪份资料为准。
但是如果你用下面的 Prompt ,有有效很多
| 根据产品功能清单核对功能事实;按照品牌手册里的语气和用词重写;去年的销售报告只用于理解目标客户,不要引用其中已经过期的数字。 |
同样是三份文件,这个 Prompt 给每份资料都找到了各自的作用,这会让 ChatGPT 知道事实去哪查,风格参考哪个,旧报告又该怎么处理
不同类型的资料,提供方式也不同:文档、表格、PPT 和 PDF 适合总结、比较和改写;
任务依赖界面或布局时,可以上传截图并指出具体区域;
答案依赖最新信息时,明确要求搜索网络并附上来源;
多次对话要共用文件时,可以放进同一个 Project。
使用已连接的数据源
如果 ChatGPT 已经连接了 Drive、Slack、Gmail 或 GitHub,Prompt 里需要说清楚去哪找,找什么,怎么用即可。
| 使用 Drive 中最新的项目计划,以及项目 Slack 频道里过去两周的重要决策、进度变化和风险,准备一份状态报告。 |
具体搜索动作可以留给 ChatGPT。你不用再规定它先打开哪个文件、搜索哪些关键词。
连接源能不能用,取决于对应插件是否安装、账号是否授权,以及当前订阅方案和工作区设置。
使用插件
Plugins 提供两类东西:可重复使用的操作指令,以及 Google Drive、Gmail、Slack、GitHub 之类的工具连接。
使用时先说最终要完成什么任务,让 ChatGPT 从可用工具中进行选择。
如果你明确想用某个插件,可以在输入框里输入 @,然后从列表中选择。
说白了,插件负责提供能力,你负责描述结果就行。
个性化 ChatGPT
长期有效的偏好,可以放进 Settings > Personalization 的 custom instructions。比如默认使用中文、少用套话、专业术语第一次出现时保留英文。
个性化设置不适合单次 prompt 有用的条件,只适合放长期起作用的约定。
设置边界条件
Boundaries 是我觉得整份指南里最实用的一部分,它给了 AI 以限定条件,就跟 Harness 似的。
官方给了四个典型例子:已经批准的日期和预算数字保持不变。只使用提供的资料,信息缺失就标出来,不要猜。所有建议都要控制在规定预算内。把消息写成草稿,不要发送。
这四句话分别在保护已确认的数据、信息真实性、预算和操作权限。
比如让 ChatGPT 润色合同,可以写优化表达,但不要修改金额、生效日期和付款期限;
让 Codex 改代码,可以写不要更改公共 API,不要部署到生产环境。
但是边界条件也别写太多,官方建议使用一两条最容易造成实际损失的地方来作为边界条件。
让结果可以直接使用
两种话术,两种结果:
“帮我总结一下”和“整理成一页、以供主管会前快速浏览的摘要”,结果会差很多。
官方给了几个例子:把会议记录整理成包含决策、负责人和截止日期的邮件;
把计划支出与实际支出做成表格;
所有差异超过 10% 的地方高亮显示。
如果遇到重要任务,还应该加一条最终检查:
| 完成之前,检查每一项后续行动是否都有负责人和截止日期。找不到的信息请标记为“待确认”,不要自行补全。 |
通过后续消息改进结果
第一条 Prompt 一般有可能达不到你想要的。你可以先看输出结果,然后再告诉 ChatGPT 具体改什么:
| 开头再直接一点,证据保留,把建议移到背景介绍前面。 |
这比一句“写得不好,再改改”要有用。
Steering and queuing|插入当前任务与排队
Codex 正在工作时,你可以继续发送消息。Steer 和 Queue 决定这条消息什么时候生效。
Steer 会把新消息送进当前任务,适合补充遗漏信息或及时改变方向。Queue 会把消息留到下一轮,适合等当前工作结束后再处理。
一个插队,一个排队。
Codex 可以在 Settings > General > Follow-up behavior 里设置默认行为。排队中的消息会显示在输入框上方,可以编辑、调整顺序、发送或删除。
Codex CLI 中,任务运行时按 Enter 是 Steer,按 Tab 是 Queue。
把上面的那些部分组合起来
下面这条 Prompt,把前面的四部分串起来了:
为周一的管理层会议准备一份一页纸的项目状态报告。
使用 Drive 中最新的项目计划,以及项目 Slack 频道中与项目有关的决策和进展。先列出需要管理层做出的决定和下一步行动,再总结项目进展、风险、负责人和截止日期。
已经批准的日期和预算数字保持不变。如果资料互相冲突或信息缺失,请明确标注。只生成草稿,不要发送或发布。
完成之前,检查每一项下一步行动是否都有负责人和截止日期。
目标是制作一页项目报告;上下文来自 Drive 和 Slack;输出说明了读者、长度和内容顺序;边界限定保护了日期、预算和发布权限;最后又加了一项检查。
使用语音听写
Codex 支持语音听写。输入框可见时按住 Ctrl + M,然后直接说话。
它会先把语音转成输入框里的文字。你可以检查和修改,确认没有识别错再发送。它更像语音输入,不会跳过你直接执行。
Chat 提示词示例
Chat 适合提问、讨论想法、起草短文和做日常决定。
Chat 的入口直接在 Codex 中,如下图示例
Chat 模式适合快问快答。
理解一个主题
| 给一个从未投资过的人解释复利是什么,使用一个具体的例子,并解释其中出现的金融术语。 |
这个例子给了受众和讲解方式。它没有规定必须分几段,也没有要求先讲公式。
起草并修改文字
| 起草一封语气友好的邮件,因为我要外出旅行,所以需要婉拒这次邀请。字数控制在 120 以内,同时表达以后愿意参加类似活动。 |
邮件的语气、拒绝原因、长度都说清楚了,生成后基本可以直接改名字发送。
比较选项
| 为一个每年出国两次的人比较这两款手机套餐。先用表格列出重要差异,再推荐一个,并说明需要接受的取舍。 |
哪款最好没有统一答案,考虑到使用者和出行频率,这个推荐才有依据。
制定可执行的计划
| 安排五顿工作日晚餐,每顿准备时间少于 30 分钟。避开花生,在不同餐次中复用食材,最后汇总成一份购物清单。 |
这个 Prompt 的实用之处在于,它同时考虑了时间、过敏原、采购和食材复用,你用这个结果能直接拿去买菜了。
Work 模式中的提示词
Chat 模式适合短问题、简单改写、头脑风暴和编写草稿。Work 模式更适合需要多份资料、多种工具、一串操作,或者最终要生成较大交付物的任务。
使用 Work 模式时,说明想要的结果、提供原始资料、明确受众,并告诉它你准备怎么检查结果。可以要求 ChatGPT 先规划,再收集资料、创建文件,完成前进行检查。
高效使用 Work 模式
Work 模式适合耗时任务、重复任务,以及以后的可复用性文件。
把原始资料做成成品文件
| 使用附件中的季度报告,制作一份管理层简报和一套六页演示文稿。读者是公司管理层。先写他们需要做出的三个决定,区分报告事实和你的分析,每个数字注明来源文件,完成前检查简报和演示文稿是否一致。 |
这类任务最容易出现两个文件说法不一致的问题,所以完成前交叉检查很关键。
为决策做研究
| 为一家 50 人的公司研究三款客服平台。使用最新资料比较价格、安全性、集成能力和迁移成本。最终交付一份推荐备忘录,附上来源链接、关键假设,以及签合同前需要确认的问题。 |
研究任务要把评价维度和决策写出来,这样得到的是一份能辅助决策的材料,不是三段产品介绍。
协调一次发布
| 根据附件中的产品说明制作发布计划,包括时间线、负责人、依赖、风险、公告草稿、客户 FAQ 和发布日检查清单。发现缺少决策时先标出来,再制作最终文件。 |
发布计划涉及的人和文件众多,如果缺一个负责人或关键决定,后面就会卡住。让 Work 模式先标注缺口,比生成一份看起来完整但没法执行的计划更实用。
重复性的任务可以先在普通 Chat 中把 Prompt 写好,是你想要的结果之后,在执行定时任务。
Codex 提示词
Codex 的入口就是我们最熟悉的了。
碰到你需要处理代码、代码库或开发工具时,直接上 Codex。
一个优秀的 Codex Prompt 要说清楚目标行为,指出相关代码或复现步骤,保留重要约束,并说明结果怎么验证。
多步骤任务可以先输入 /plan,让 Codex 调查并提出方案,再决定是否编辑。
Goal 模式可用时,在计划确认后使用 /goal 设置持续目标。
如何阅读这些示例
官网后面的每个例子都说明了四件事:什么时候用、适合 IDE/CLI/Cloud 中的哪个界面、用户需要提供什么上下文,以及最后如何验证。
IDE 扩展会自动带上打开的文件。CLI 里最好明确写出路径,或者通过 @ 和 /mention 附上文件。
Codex 在 sandbox 沙箱中运行。本地文件、网络或外部操作超出权限边界时,会按照当前 approval policy 处理。
理解代码库
刚接手的项目、阅读你不熟悉的服务,或者需要理解协议、数据模型和请求流程时,可以让 Codex 先解释一下代码。
IDE 扩展工作流(最快的本地探索方式)
打开相关的文件,必要时选中关心的代码,然后输入:
解释请求在所选代码中的完整流转过程。
请包括:
- 每个相关模块负责什么
- 数据在哪里验证
- 修改这些代码时需要注意的一两个问题
验证:让 Codex 把请求流程整理成编号步骤,并列出涉及的文件。
CLI 工作流(适合保留对话和命令记录)
在项目根目录运行 codex,然后明确告诉它要读哪些文件:
我需要理解这个服务使用的协议。阅读 @foo.ts 和 @schema.ts,解释 schema 以及请求和响应流程。重点区分必填字段、可选字段和向后兼容规则。
CLI 会保留对话和命令输出。路径多时可以用 @ 自动补全,或者通过 /mention 附上文件。
修复 Bug
Bug 能在本地复现时,最有用的信息是复现步骤和约束。
CLI 工作流(复现与验证的闭环)
下面出现了一个 Bug:页面保存按钮刷新后无法使用。
Bug:设置页面点击“保存”后显示成功,但刷新页面后开关恢复原状。
复现:
1. 运行 npm run dev
2. 打开 /settings
3. 修改 Enable alerts
4. 点击 Save
5. 刷新页面,观察开关状态
约束:
- 不要改变 API 结构
- 尽量做最小修改
- 条件允许时补一个回归测试
先复现问题,再定位原因并修改。完成后重新执行复现步骤,运行最小的相关测试集,并报告命令和结果。
用户负责提供复现步骤和限制条件。Codex 会补充命令输出、发现的调用位置和堆栈信息。
验证:修改代码之后,重新操作一次原来的出错流程,确认 Bug 已经消失;再运行代码检查和相关测试;最后把实际运行了哪些命令、每个命令是否成功、通过了多少测试告诉我。
IDE 扩展工作流
打开你怀疑有问题的文件和它最近的调用方,然后输入:
| 找出为什么界面显示已保存,但数据没有持久化。修复后,告诉我如何在 UI 中验证。 |
这类 Prompt 适合问题范围已经比较小,只差定位具体代码的时候。
编写测试
编写测试时,先把测试对象和范围交代清楚。Codex 会参考代码库里已有的测试习惯。
IDE 扩展工作流(基于选中代码)
打开包含目标函数的文件,选中函数代码,通过命令面板选择 “Add to Codex Thread”,然后输入:
| 为这个函数编写单元测试,遵循项目中其他测试使用的约定。 |
选中的代码行和当前打开的文件会作为上下文,不需要再复制一遍。
CLI 工作流(在 Prompt 中说明路径和范围)
CLI 中可以直接写函数名和路径:
为 @transform.ts 中的 invert_list 函数添加测试,覆盖正常路径和边界情况。 |
如果一个文件里有多个同名或相似函数,再补充行号范围或调用位置。
根据截图制作原型
截图能看出来布局、字体和间距,但它不会告诉 Codex 应该使用什么技术栈,也看不出 hover、校验和键盘交互。
图片和文字一起发给 Codex ,它才会拿到完整的输入。
CLI 工作流(图片+Prompt)
把截图保存到项目里,例如 ./specs/ui.png,启动 Codex 后拖入图片,再输入:
根据这张图片创建一个新的仪表盘。
约束:
- 使用 React、Vite 和 Tailwind
- 使用 TypeScript
- 尽量匹配截图中的间距、字体和布局
输出:
- 一个能渲染该 UI 的新路由或页面
- 所需的小型组件
- 一份包含本地运行方法的 README.md
验证:让 Codex 启动开发服务器,并告诉你查看原型的本地 URL 和路由。
IDE 扩展工作流(图片+现有文件)
把图片拖入任务,同时打开项目里风格最接近的页面,然后输入:
| 创建一个新的设置页面,以附件截图为目标界面,并遵循本项目其他文件使用的设计和视觉模式。 |
这样 Codex 既能看到目标图,也能参考现有项目的组件和样式。
通过实时更新迭代 UI
页面已经能运行后,可以让 Codex 每次只改一小块内容,每次刷新浏览器看结果。
CLI 工作流(运行 Vite,再用短 Prompt 迭代)
在单独终端运行 npm run dev,然后先让 Codex 提出两三个样式改进。选中一个方向后,把范围缩小:
采用方案 2。
只修改页头:
- 字体更偏编辑风格
- 增加留白
- 确保移动端仍然正常
下一轮可以继续写:
| 保持布局不变,简化颜色,删除多余边框,减少视觉干扰。 |
验证:每次修改后刷新浏览器。满意的修改及时提交,不满意的撤销。你手动改过或回退过文件,也要告诉 Codex,免得下一轮又被覆盖。
把重构交给云端
复杂的重构可以先在本地理解代码和确定方案,再把耗时的实现交给云端。
这个我之前不知道有云端这个功能,这次我才知道。
连接 GitHub 之后,会把你 GitHub 的项目同步过来,然后根据 GitHub 上的项目创建云端环境。
连接之后,你的本地就会出现可以在云端工作的选项。
本地规划(IDE)
先提交或暂存当前修改,保证后面能看清差异。然后让 Codex 规划:
$plan
重构认证子系统:
- 拆分 token 解析、session 加载和权限判断
- 减少循环依赖
- 提高可测试性
约束:
- 不改变用户可见行为
- 公共 API 保持稳定
- 给出分阶段迁移计划
计划出来后继续追问:每个里程碑具体移动哪些文件?失败时怎么回滚?本地规划阶段最需要的是入口文件、模块边界和依赖关系。
云端委派(IDE → Cloud)
你设置好 Codex cloud environment 后,在输入框下方选择云环境,再发送实现计划中的里程碑 1。新的云端任务会带上当前任务里的计划和上下文。
实现完成后检查 diff,必要时继续修改。你可以从云端创建 PR,也可以把修改拉回本地测试。
云端任务运行在隔离环境里。Agent 阶段默认没有互联网访问,除非你在环境设置中明确开启。
进行本地代码审查
提交代码或创建 PR 前,可以让 Codex 先检查当前工作树。
CLI 工作流(审查工作树)
在项目根目录启动 Codex,运行:
/review
也可以加关注点:
/review 重点关注极端情况和安全问题
根据反馈修复后,再运行一次 /review,确认相关问题已经解决。
审查 GitHub Pull Request
如果不想把分支拉到本地,可以在 GitHub 上直接触发 Codex review。前提是仓库已经启用 Codex Code review。
GitHub 工作流(评论触发)
打开 Pull Request,发表评论:
@codex review
需要关注安全问题时,可以写得更明确:
@codex 审查安全漏洞和安全隐患
更新文档
文档任务也要写清修改范围和验证方法。只说更新文档,Codex 很容易顺手重写一大片。
IDE 或 CLI 工作流(本地编辑与验证)
确定需要修改的文档,在 IDE 中打开,或者在 CLI 里用 @ 指定文件,然后输入:
| 更新高级功能文档,补充身份验证故障排查说明,并验证所有链接都能访问。 |
Codex 完成后,最后一步是阅读渲染出来的页面。
参考资料:
-
- OpenAI:PromptingOpenAI:PluginsOpenAI:Personalization settings
如果这篇文章你觉得还不错,谢谢你的三连,也希望可以转发给同样关注 AI / 科技 / 开发效率的朋友。 我是 cxuan,我们下期再见。
651