别再写提示词小作文了：GPT-5.6 Chat、Work、Codex 应该这样用

最近大家是不是每天都在等着 Tibo 刷新 Codex 额度？

额度到账，打开 GPT-5.6，手放到键盘上，另一个问题又来了：现在到底该怎么写提示词？Chat、Work、Codex 都能接任务，三种模式是不是还要准备三套“咒语”？

OpenAI 最近更新了官方 Prompting 指南^[1]，明确了再最新的 GPT-5.6 中提示词的写作原则，而且还贴心的给出了 Chat、Work 和 Codex 不同模式下提示词的实用示例。

小编提示：这套提示词规则不止限于 GPT，国内 GLM、KIMI、QWEN、DS 等最新大模型都适用~

不用写提示词小作文了

官方给出的基础框架只有四项：

• 目标（Goal）：你要它完成什么；
• 上下文（Context）：哪些信息和资料会影响结果；
• 输出（Output）：你要什么格式、篇幅和详细程度；
• 边界条件（Boundaries）：什么不能改、不能猜，采取什么动作前必须确认。

而且这四项并不要求每次填满。任务简单，一句话就够；任务复杂，再补上真正会改变结果的信息。

这和过去流行的提示词写法差别很大。我们曾经习惯先给 AI 安排角色，再列背景、步骤、语气、原则、注意事项，恨不得把一条提示词写成岗位说明书。到了 GPT-5.6 这一代，更实用的写法反而是：把结果说清楚，把材料给够，把风险圈出来，然后给模型留出完成任务的空间。

Chat：先说你要什么答案

Chat 适合提问、解释概念、头脑风暴、短文起草和日常决策。它处理的是一次对话里能快速完成、方便继续追问的任务。

Chat 的提示词不需要写成长表格。先告诉它你想得到什么，再补充那些确实会改变答案的细节。

比如你想比较两款 AI 产品，可以直接写：

比较产品 A 和产品 B，面向没有编程经验的一人公司创业者。
用表格列出价格、上手难度、自动化能力和数据隐私差异，最后推荐一个，并说明代价。

这里有目标、受众、输出和判断维度，已经足够。没有必要再加“你是一位拥有 20 年经验的世界级产品经理”，也不用命令模型“深呼吸、一步一步思考”。

官方指南还强调，第一条提示词不必完美。先看结果，再用后续消息指出具体修改：

开头再直接一点，保留现有证据，把推荐结论移到背景介绍之前。

这比删掉整条提示词、重新复制一份“终极模板”更有效。Chat 本来就是对话，不是一次性交卷。

Chat 提示词模板

帮我完成：[你要的结果]

使用场景或受众：[谁会看、你准备怎么用]
需要包含：[真正影响答案的内容]
输出形式：[表格、清单、短文、字数等]
注意：[最多一两条关键限制]

其中不需要的部分，直接删掉。

Work：结果导向，要它交付成品

当任务需要读取多份资料、调用不同工具、执行一连串步骤，或者最后要生成一个可以继续使用的文件时，适合切到 Work 模式。

Chat 里的典型要求是“帮我想想”；Work 里的要求应该更接近一份交付说明：基于哪些材料，为谁制作什么成品，你准备如何验收，哪些动作需要先批准。

比如要把季度资料做成管理层简报，可以这样写：

使用附件中的季度报告，制作一份管理层简报和一份六页演示文稿。

受众是公司高管团队。开头先列出需要作出的三项决定。
区分报告中明确陈述的事实和你的分析，为每个数字标注来源文件。
完成前检查简报和幻灯片中的数字是否一致。

先生成文件供我审阅，不要发送或发布。

这条提示词没有规定它先读哪一页、再调用哪个工具、最后按什么顺序写文件。过程由 Work 自己安排，用户只控制结果和风险。

这是官方指南里一个很容易被忽略的变化：除非执行过程本身很重要，否则不要把每一步都预先写死。模型可以搜索、比较、创建文件和自检，过细的步骤反而可能限制它处理意外情况。

Work 模式还要比 Chat 多想一层：这个结果如何验收？

• 行动项是否都有负责人和截止日期；
• 文档中的数字是否能追溯到来源；
• 不确定的信息是否被明确标出；
• 多个交付文件之间是否一致；
• 发送、发布或修改共享资料前，是否需要你的批准。

这些检查要求最好直接写进提示词。模型完成了任务，并不等于结果已经可以使用。

Work 提示词模板

请基于：[文件、网页、已连接的数据源]
完成：[最终交付物]

受众和用途：[谁会使用、用于什么场景]
必须包含：[核心内容]
输出要求：[文件类型、篇幅、结构]
边界条件：[不能修改、不能猜测、哪些动作需先批准]

完成前请检查：[你的验收标准]
先交付给我审阅，不要发送或发布。

如果任务会反复执行，先在普通对话里把这套提示词跑顺。结果稳定后，再考虑把它做成定时任务或Skill。不要一上来就把一个未经验证的流程自动化，否则你得到的只是定时发生的错误。

Codex：写清行为、代码位置、限制和验证

Codex 直接面对代码库、开发环境和可以实际执行的命令。

因此，给 Codex 的提示词需要回答四个更具体的问题：

1. 你希望软件表现出什么行为；
2. 相关代码在哪里，或者问题如何复现；
3. 哪些接口和行为必须保持不变；
4. 修改后用什么方式证明它真的修好了。

官方示例中的 Bug 提示词很典型：

Bug：点击设置页的“保存”后，有时显示“已保存”，但修改并未持久化。

复现步骤：
1. 运行 npm run dev
2. 打开 /settings
3. 切换“启用提醒”
4. 点击“保存”
5. 刷新页面，开关恢复原状

限制条件：
- 不要改变 API 结构；
- 尽量采用最小修改；
- 如果可行，添加回归测试。

先在本地复现问题，再提出补丁并运行检查。
修复后，重新执行复现步骤，并运行 lint 和最相关的最小测试集。
报告执行过的命令和结果。

这条提示词的价值与长度无关，每一段都在直接减少 Codex 的猜测。

“帮我修一下保存功能”只给了目标，没有现场信息。Codex 可能找到相似代码，也可能修错位置。复现步骤、文件路径、接口限制和验证命令，才是代码任务里真正值钱的上下文。

IDE、CLI 和云端，提示词也有一点差别

在 IDE 扩展里，Codex 会自动看到当前打开的文件，也可以把选中的代码加入对话。所以你可以直接说：

解释请求如何经过选中的代码完成处理。
列出相关模块的职责、数据验证位置，以及修改这里最容易踩的两个坑。

在 CLI 里，最好明确写出路径，或者用 @ 与 /mention 附加文件：

阅读 @foo.ts 和 @schema.ts，解释协议的数据结构和请求响应流程。
重点说明必填字段、可选字段和向后兼容规则。

多步骤重构可以先用 /plan，让 Codex 调查代码库并提出方案，确认后再动手。耗时任务可以委托到云端，但云端运行在隔离环境中，默认可能没有互联网访问。涉及依赖下载或外部服务时，要把环境和权限条件说清楚。

Codex 提示词模板

任务：[要实现或修复的行为]

相关位置：[文件、函数、模块，或用 @ 附加路径]
复现方法：[命令和操作步骤]

限制条件：
- [必须保持不变的 API、数据结构或用户行为]
- [修改范围、兼容性或安全要求]

开始时：[先复现 / 先调查 / 先给计划]
完成后：[运行哪些测试、lint、构建或界面检查]
请报告修改的文件、执行的命令和验证结果。

工作中途跑偏，直接引导，不用等它结束

官方指南还有一个很实用的细节：正在执行时，可以继续发消息，有两种模式：

• Steer（引导）：把新消息加入当前运行，用来纠正方向、补充遗漏信息；
• Queue（排队）：把消息留到下一轮，适合当前任务完成后再做的事情。

比如 Codex 正在改整个页面，而你发现自己只想调整页头，不必眼睁睁看它把额度烧完。直接 Steer：

缩小范围：只修改页头。保留正文布局和现有组件，不要继续调整其他区域。

如果你想让它完成当前修复后再补文档，就 Queue：

当前修复和测试完成后，更新 README 中对应的配置说明。

提示词因此不再是一张发出后就不能修改的订单。你可以在执行过程中持续校正，这也是 Agent 工作方式和传统聊天最明显的差别之一。

GPT-5.6 之后，提示词更像验收单

现在的提示词不再强调过程，而是先描述结果，再提供会改变结果的上下文，最后写清边界和验收方式。

Chat、Work、Codex 的区别，可以放进这张表里：

所以，GPT-5.6 之后该怎么写提示词？

简单任务，少写一点。复杂任务，重点是补齐材料、边界和验收标准，不再需要操作手册式的提示词。Chat 用来把问题聊清楚，Work 用来交付成品，Codex 用来修改并验证代码。

下次 Tibo 刷新额度之后，也别急着把珍贵的 Codex 额度花在“你是一位世界级工程师”上。

把结果、目标给它。剩下的，让它干活。