OpenAI 官方提示词指南：从控制过程转向描述结果

OpenAI 官方最新提示词指南，覆盖 Chat、ChatGPT Work 和 Codex 三个场景 https://t.co/WAieuClbqu 作者是创建 @RepoPrompt 的 @pvncher，现在也在 OpenAI Codex DX 团队了！ 开篇就纠正了一个观点：提示词需要"公式"吗？不需要！ 给出可选的四要素框架，但反复强调"只用有帮助的部分"： · 目标（Goal）：要 ChatGPT 做什么 · 上下文（Context）：哪些信息或来源有帮助 · 输出（Output）：需要什么格式、长度、详细程度 · 边界（Boundaries）：什么必须保持不变、什么需要先征求确认 这背后的方法论转变值得注意：从"控制过程"转向"描述结果"。文档明确建议先说你要的结果，而不是罗列步骤——只有当过程本身重要时才描述过程，其余留给模型自己搜索、比较、调整。 几个容易被忽视的关键原则 1. 边界要"少而准"。 文档对边界的定义很克制：只写那一两条能防止真实问题的指令，比如"保持已批准的日期和预算数字不变""只用提供的来源，缺信息就标注而不是猜""写成草稿，不要发送"。不需要控制每一步——过多约束反而降低效果。 2. 上下文是"筛选"而不是"堆料"。 只附加真正影响结果的来源，并说明每个来源该取什么。用连接的数据源（Drive、Slack 等）时，指明去哪找、找什么即可，不必描述每一次搜索。 3. 说明用途，而不只是格式。 "让主管会前一页扫完""转成带负责人和截止日期的跟进邮件"——告诉模型结果将如何被使用，它才能选对长度和组织方式。 4. 首个提示不必完美。 用追问来修正方向、补充来源、调整详略，不用推倒重来。配套机制是 Steering（插入当前运行，即时改方向）和 Queuing（排队到下一轮），Codex CLI 中分别对应 Enter 和 Tab。 5. 对重要工作，要求"自检 + 人工复核"。 让模型收尾前确认"每个行动项都有负责人和日期"、标注无法核实的信息，然后自己再审一遍。 三个场景的分工 Chat：快速问答、改写、头脑风暴、轻量草稿。例子都很短——解释复合利息、写婉拒邮件、对比手机套餐、规划一周晚餐。 Work：跨来源、多步骤、产出文件的任务（如从季报生成简报和幻灯片、调研采购决策、协调产品发布）。因为消耗额度，文档强调效率策略：一次只要一个可审阅的结果、区分必需与可选、方法重要时先要计划、发布前需你批准、跑偏了及时收窄。跑通后可以把工作流沉淀为定时任务复用。 Codex：代码类任务。好的 Codex 提示要包含四件事——想要的行为、相关代码或复现步骤、必须保留的约束、如何验证。 Codex 部分的实践要点 这是文档篇幅最大、最工程化的部分，给出了多个工作流模板，共同模式是"上下文 + 约束 + 验证"三段式： · 上下文来源不同：IDE 扩展自动包含打开的文件；CLI 需要显式用 @路径 或 /mention 附加。这是选择工作面的重要依据。 · 修 Bug 的最佳实践是给出可执行的复现步骤（比高层描述有用得多）+ 约束（"不改 API 形状，改动最小化"）+ 要求先复现再修、修完重跑复现和最小测试集。 · 从截图做原型：图片提供视觉要求，但技术栈、路由、图上看不到的行为（hover、校验、键盘交互）仍需文字说明。 · 云端委托重构：本地（有完整代码上下文）先用 /plan 出计划并协商修改，然后分里程碑委托到云端并行执行，逐个审 diff。注意云端 agent 阶段默认无网络。 · UI 迭代：另开终端跑 dev server，用小而具体的提示逐步改；如果你手动回退了某个改动，要告诉 Codex，避免下一轮被覆盖。 · 代码审查：本地用 /review（可加聚焦指令），GitHub PR 上用 @ codex review 评论触发。  > **引用原帖 eric provencher (@pvncher):** > With 5.6 Sol, a lot of people are still prompting the model exactly as they did 5.5 > It's important to note that 5.6 Sol is a lot more tenacious and thorough than previously models. > Check out the guide I wrote here to get better outcomes > https://t.co/nk1rHm0sWY > https://x.com/pvncher/status/2075663535544135935