• 正文
  • 相关推荐
申请入驻 产业图谱

OpenAI 官方 Prompt 指南

07/21 22:33
651
加入交流群
扫码加入
获取工程师必备礼包
参与热点资讯讨论

大家好,我是 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,我们下期再见。

相关推荐

登录即可解锁
  • 海量技术文章
  • 设计资源下载
  • 产业链客户资源
  • 写文章/发需求
立即登录