ARTICLE · 1311130
OpenAI 官方提示词指南:不用背模板,说清这四件事就够
ChatGPT 官方文档《Prompting》
最近翻了到一篇OpenAI 挂出来的文档，标题很朴素，就叫《Prompting》。
它不太像我们平时刷到的那些「30 个万能咒语」合集。
没有 role play，没有「你是一位资深专家」，也没有 "let's think step by step" 这种老梗。点开之前我以为又是那种花活合集，读完发现不是。
整篇读下来，主张就一句话：prompt 不是咒语，是把话说清楚。
文档开头写得很直白。
prompt 可以是一个问题、一条指令、一个目标，你不需要懂什么技术语法，也不用套固定公式。
从自己的话开始，看它返回什么，再追问着调。
比较反常识的是它明确说：短 prompt 经常就够了。
这句我看了两遍。
平时我们被教的都是「越长越好，最好写满一屏」，官方反而在往回收。
只有任务变大、变重要的时候，才值得把几个部件写全：目标、背景、输出、边界。而且它反复强调一句 "use only the parts that help"，用得上哪块写哪块，不用每项都填。
一个完整 prompt 的四个部件
一、先说结果，别急着教它怎么做
文档第一条就挺反常。
「Start with the result, not a detailed list of steps.」先说要什么结果，而不是先列一堆步骤。
原因不难理解。
步骤一旦写死，模型就只能在你划的圈里跑，它本来能自己去搜、去比、去换条路走，全被你堵上了。
所以文档说，除非流程本身就是交付物的一部分，否则别描述流程。
它给的例子很短：把这份会议记录改写成一段给项目组看的简短更新，决策和下一步放最前面。
就两句话。但交付物（简短更新）、受众（项目组）、结构偏好（决策打头）都在里面了，信息量刚好够它不跑偏。
所以你写 prompt 的时候可以先问自己一句：我到底要拿到什么东西，谁看。
受众和格式写清楚，往往比写一堆步骤有用得多。
二、信息给够，但只给会改变答案的那部分
第二条是加背景。
注意它的措辞，share the information that could change the result。
能改变结果的信息才给，不是把手上的资料一股脑倒进去。
它列了几种具体场景，我按顺序说。
文档、表格、PPT、PDF 直接传，让它总结、对比、转换、生成新文件。截屏图片也行，但别指望它自己找重点，得指出你看的是哪一块。
答案依赖最新信息，就明确让它联网搜，并且要来源。需要多轮对话共享同一批文件、或者某个本地目录，就开一个 project。
再往上一层是连接的数据源，前提是你装了对应插件。这时候的正确写法是点名去哪找什么，而不是把要执行的搜索一条条列出来。
文档的例子是这样：用 Drive 里最新那版项目计划，加上 Slack 项目频道里相关的决策和更新，做一份状态汇报。
插件有个小细节挺实用：在 ChatGPT 输入框里打 @ 就能指定某个插件。
还有一层是偏好该放哪儿。
跨对话都成立的偏好，比如你习惯什么语气、什么格式，放进设置里的个性化和自定义指令。
只跟这次对话有关的细节，留在 prompt 里。
别每次都把个人偏好重打一遍，那是纯浪费。
三、边界只封真会出事的那几处
边界，boundaries，我觉得翻译成「禁区」更顺。
它的定义很克制：只有当改错一个细节会让整份东西作废，或者你需要赶在别人看到之前过一眼，才值得加一条边界。
文档给了四条示例，基本覆盖了实际会踩的坑。预算和已批准的日期不许动。只用给的资料，缺的地方标出来，别猜。推荐方案不能超预算。消息写成草稿，不要发。
然后它又强调一遍别过度：抓住最关键的一两条就行，不用把每一步都锁住。
这条我觉得最容易被忽略。
很多人写 prompt 喜欢一口气列十几条「你必须」「绝对不要」，结果模型把注意力全耗在守格式上，正事做糙了。
真正该封的，是那些发出去就收不回来的动作：发送、发布、改动别人依赖的数据。
四、告诉它你打算怎么用
这条比想象中重要。
你说清楚拿到东西之后要干什么，它才知道该多长、多细、怎么组织。
文档三个例子正好对应三种用法。
一页纸给总监开会前扫一眼，决策和下一步打头。把笔记变成一封跟进邮件，带决策、负责人、截止日。
做一张预算对比表，超过 10% 的差异高亮出来。
三句话，三种完全不同的产物。
你要是只说「帮我整理一下这些数据」，出来多半是个谁也不满意的中间态。
重要的事情上，它建议再加一道自查：每个待办是不是都有负责人和截止日，有没有哪些信息它其实没能核实。自查完之后你自己还得看一遍再用，这句它也写了。
五、第一版不用完美，追问比重写省事
文档明确说，第一版 prompt 不需要写得完美。
看结果，然后提具体要改哪里。
它给的追问示例我觉得可以直接当模板：开头写得更直接一些，证据保留，把建议挪到背景部分前面。
一句话，三个动作，全是可执行的指令。
对比一下「再优化一下」「感觉不太对」，差别马上就出来了。 补
补一份漏掉的资料、纠正方向、要另一个方案、改详细程度，都不用从头再来。
顺带说一个 Codex 里的机制，很多人不知道。
它在跑的时候你可以直接再发一条。
Steer 是把话插进当前这一轮，用来改方向、补细节、递新信息。
Queue 是存到下一轮，等这轮干完再说的跟进。
桌面 App 里在设置里选默认用哪个，Codex CLI 里跑着的时候按 Enter 是转向，按 Tab 是排队。
六、拼起来长什么样
文档最后把四件套拼成了一个完整例子，场景是给周一领导会准备一页纸的项目状态更新。
用 Drive 里的最新计划和 Slack 频道里的决策做输入，要求先讲需要领导拍板的事和下一步，再讲进展、风险、负责人、截止日。
锁死已批准的日期和预算数字，冲突或缺失的信息要标出来，不要发送或发布任何东西。最后检查每个下一步是不是都有负责人和截止日。
这段把目标、背景、输出、边界全带上了，再补一道自查，全程没有一句「第一步打开、第二步点击」。
四个部件我整理成一张表，方便对照着写：
七、Chat、Work、Codex 是三套不同问法
文档后半段按产品分了场景，这部分信息密度最高，也最容易被略过。
Chat 就是日常问答、改稿、出主意。
四个示例都很短，但每个都挂着硬约束。
讲复利：受众是从来没投过资的人，要一个具体例子，提到的金融术语必须解释。
写拒邀邮件：120 词以内，还得留个以后再约的口子。
比手机套餐：按「一年出国两次」这个具体人来算，表格列差异，然后推荐一个并说清取舍。
排工作日晚餐：每个 30 分钟内，避开花生，食材复用，最后汇总成一张购物清单。
注意最后那个。
「食材复用」「汇总成一张购物清单」，这种要求才是让输出直接能用的关键。不然你还得自己再加工一遍，等于白问。
ChatGPT Work 是给跨多个来源、多步、要产出文件的任务用的。
它的用法要点有五条。只放相关的源，必要时把时间范围也限住。受众、格式、长度先说清。必须做的和可选的修饰分开写。方案本身重要的话，先只要一个计划，凡是涉及发送、发布、改动别人依赖的信息，必须等你批。发现它在做你不需要的活，立刻收窄或者叫停。
三个例子分别对应三种活。
把季度报告变成领导简报加六页 PPT：区分事实和你的分析，每个数字标注来源文件，简报和幻灯片的数字要对得上。
给 50 人公司选客服系统：比价格、安全、集成、迁移成本，只用最新资料，交一份带链接和假设的推荐备忘。
按产品简报做发布计划：时间线、负责人、依赖、风险、公告草稿、客户 FAQ、上线当天清单全要，缺的决策先标出来。
Codex 那块最像工程手册。
它的内核是四件事：说清你要什么行为、指向相关代码或复现步骤、保留重要约束、说明怎么验证。
八个工作流都给了 IDE、CLI、云端的具体走法：读懂一个代码库、修 bug、写测试、照截图做原型、边跑边改 UI、把重构甩到云端、本地代码审查、审 GitHub PR、更新文档。
两个点值得单独记一下。
修 bug 时，它要的不是「帮我修一下」，而是一套复现配方。
怎么启动、进哪个页面、点什么、刷新后看到什么，再附上约束：别改 API 形状、修复尽量小、能加回归测试就加。
文档原话说，这些复现步骤和约束比一句高层描述重要得多。
另一个是它的分工逻辑。本地做规划，云端做执行。
在 IDE 里让它出重构方案，审完、讨价还价完，点输入框下面的云图标，把第一个里程碑丢给云端跑，出来看 diff、开 PR、再推下一个。云端是隔离环境，默认不联网，要你自己开。
两个环境差异也提一下。IDE 扩展会自动把你打开的文件当上下文，CLI 里得手动 @ 路径，或者用 mention 挂文件。Codex 在本机跑命令是在沙箱里，碰边界要按你设的审批策略走。
八、我自己的感受
写这篇的时候我一直在想一件事：这份文档几乎没有「技巧」。
没有角色设定，没有情绪勒索式的「这对我很重要，拜托了」，也没有任何一句需要背下来的话。
它通篇在讲一件很朴素的事：你得像跟一个聪明但完全不了解你处境的同事交代工作那样，说清楚要什么、手里有什么、给谁看、哪里不能碰。
我觉得这恰恰是它值钱的地方。
prompt 的难点从来不在措辞，在于你自己有没有想清楚要什么。
|热门提示词文章推荐：
OpenAI 官方出手：Chat / ChatGPT Work / Codex 实用提示词指南全场景拆解
吴恩达新课《AI Prompting for Everyone》的10个核心要点
Claude Opus 5.5 提示词指南：别再教它"仔细思考"了
如果你觉得今天这篇有收获，欢迎点赞、在看、转发三连 。
