先认清你要的是聊天还是交付物
一个判断标准:如果结果需要被别人打开、评审、转发或存档,那它就是交付物,不是一段回答。交付物有格式、有受众、有验收标准,也就有失败的可能——这正是提示词要提前说清的东西。
| 你要的 | 更合适的地方 | 理由 |
|---|---|---|
| 一个解释、一段代码、一个短草稿 | Chat | 快速往返,不需要留档 |
| 带来源的简报、竞品纪要、周期周报 | Work | 要用你的文件与工具,要能复核 |
| 可下载的 docx / pptx / xlsx / PDF | Work | Work 能直接生成文件并在对话旁预览 |
Work 和 Codex 的关系、以及三者怎么分,这里不重复,看下面这条就够。
提示词骨架:六个格子填满再发送
一个能稳定产出合格交付物的提示词,基本都在填这六个格子。缺哪个,模型就会自己编一个,然后你要花两轮纠正。
| 格子 | 写什么 | 不写会怎样 |
|---|---|---|
| 目标 | 最终交付物是什么形式、要解决谁的什么问题 | 它给你一份泛泛的综述 |
| 来源 | 用哪些文件、限定到什么时间范围 | 它用模糊印象凑内容 |
| 受众 | 谁会读、他们关心什么决定 | 深度和取舍全错 |
| 结构 | 页数、章节、必含的几个部分 | 长度随意,重点漂移 |
| 证据要求 | 数字要标到源文件,区分事实与分析 | 结论和数字对不上,无法复核 |
| 停止点 | 哪些步骤要先给你确认、什么情况下停下来问 | 它一路做完,方向偏了才发现 |
目标:产出一份 [交付物形式],用于 [谁的什么决定]。
来源:只用我附上的 [文件/数据],时间范围 [起止]。
受众:[读者],他们在意 [关注点]。
结构:[章节/页数/必含部分]。
证据:每个数字标到源文件,把「资料里的事实」和「你的分析」分开写。
停止点:先给提纲让我确认,再生成文件;发现资料不足就停下来说明缺什么。官方给的建议还有一条很实用:把必需的活和可选的润色分开说。否则它会把一半时间花在调字体上,而你真正要的三个结论还没写。
先把资料喂对,再谈写得好不好
Work 能读你上传的文件、连上已批准的工具,桌面端还能用本地文件、应用和浏览器。但「能读」不等于「读对了」:塞十个文件进去,它会把不该用的那份也当依据。
- 只放这次真正相关的来源,宁可分两轮做,也不要一次全塞。
- 时间敏感的内容明确限定范围,比如「只用 2026 年之后的资料」。
- 需要外部最新信息时,明确要求它用当前来源并给链接,而不是凭记忆答。
- 来源之间冲突时,要求它指出冲突,而不是自己选一个。
生成文件时,把约束写死
只要任务最终会落到一个文件上,就要按官方那句话来写:给源数据、给期望的文件类型、给结构、给复核标准。这四项缺一项,产物就得重做。
产出两个文件:一份 2 页的简报(docx)和一套 6 页的演示(pptx)。
两份必须结论一致:简报里的每个数字,在演示里出现时不能变。
开头先放三个需要决策的事项,再放支撑材料。
最后一页列出资料不足、需要我补充的地方。
做完自己核对一遍:数字对得上源文件、简报复述与演示不矛盾。| 场景 | 怎么验收 |
|---|---|
| 桌面端 | 在对话旁直接预览 docx / pptx / xlsx / PDF,用 annotations 指到某处要求定点修改 |
| 网页版 | 附源文件或直接要求生成文件,在对话里下载并给针对性反馈 |
| CLI | 没有预览界面,要求它逐个报告输出路径和做过的检查 |
跨设备继续做的时候注意两点:本机访问关掉会中断正在跑的回合;本地和云端不能在同一个回合内切换,需要先停再续。具体行为以官方文档为准。
三个可以直接改的模板
下面三个模板都按上面的骨架写好了,把方括号里的内容换成你自己的即可。它们的共同点是把「证据」和「停止点」都写进去了。
用我这周提交的 [记录/工单/会议纪要] 写一份周报,读者是 [直属上级]。
结构:本周完成(含影响范围)、进行中(含卡点)、下周计划、需要决策的两件事。
每条结论后面标出依据来自哪份材料。
只写有记录支撑的内容,没记录的不要补。
先给结构,我确认后再写正文。调研 [三家竞品],面向 [公司规模/场景] 做选型。
对比维度:价格结构、安全与合规、集成方式、迁移成本。
只用当前可查到的官方资料,每条附链接。
输出一份推荐备忘录:推荐结论、关键假设、签约前必须问清的问题。
资料不足的维度明确写「未查到」,不要推断。把附件里的 [材料] 整理成 [8] 页演示大纲。
受众是 [管理层],他们最关心 [三个决策]。
前两页讲结论,中间讲证据,最后一页讲风险与待定事项。
每页给:标题、三个要点、一句口播提示。
先只给大纲和每页要点,我确认后再生成 pptx。迭代、停下与验收
第一版出来之后,最有价值的动作不是「再改改」,而是指出结构性问题:缺哪个部分、哪个结论没有证据、哪段受众不对。改结构一轮,胜过改措辞五轮。
- 发现它在做你不再需要的工作,直接缩小范围或停掉,不要让它在废方向上耗额度。
- 要对外发送、发布或改动别人依赖的信息之前,要求先经你批准。
- 复核第一份结果、把指令改到稳定,再固化成可复用的提示词。
- 长任务和复杂任务更费 credits,判断标准是成品值不值,而不是提示词写了几条。
- 01
选一个有真实交付物的任务
别拿「帮我总结一下」练手,选一份真的要发出去的周报或调研。
- 02
先跑骨架
六个格子填满发一次,看它第一版差在哪里,把差距记下来。
- 03
改提示词而不是改产物
同一个错误出现两次,就把它写进提示词,别每次手动改文件。
- 04
固化成模板
同一类产出做三次以上,就整理成模板存起来,下次只换输入。
什么情况下该换工具
Work 不擅长的事也很明确:需要跑代码、需要反复读写仓库、需要接 CI 的活,交给 Codex 更合适。这不是能力差距,是场景差异。
| 信号 | 换到哪 | 原因 |
|---|---|---|
| 要跑脚本、验证输出、改仓库文件 | Codex | 有终端与仓库上下文 |
| 要长期按周自动跑 | 定时任务 | 不用每次手动发起 |
| 只要一句结论 | Chat | 开 Work 反而更慢 |
如果你还在纠结订阅档位值不值,额度与共用规则单独写了一篇,避免在这里重复。
常见问题
Work 和 Chat 的提示词要写得不一样吗?
区别在详略。Chat 里一句话就够;Work 里要写清交付物形式、来源、受众、结构和验收标准,因为它要产出的是一份能被别人打开和复核的东西。
为什么它生成的演示和我给的资料对不上?
通常是资料没限定范围,或者没要求标注来源。明确「每个数字标到源文件」「简报和演示必须一致」「资料不足就写未查到」,能挡掉大部分偏差。
一次能处理多少资料?
没有固定答案,取决于文件大小与任务复杂度。实践上只给相关来源比堆量更可靠,需要更多资料时分成几轮做,每轮产出一部分。
做出来的文件能直接发出去吗?
能生成,但发之前你要复核。让它在交付时列出「资料不足的地方」和「自己做的假设」,这两栏通常就是需要你补的地方。
官方文档与参考
本文依据上述官方文档整理;价格、额度与功能会随官方更新变化,第三方中转站的行为以其自身说明为准。