ChatGPT 提示词实战手册：把需求说清楚，AI 才能把事情做好

这不是一篇“提示词咒语大全”，而是一套可以直接用于 Chat、ChatGPT Work 和 Codex 的任务沟通方法。

ReelOS.AI 禅定｜一句话看懂本文

提示词不是写得越复杂越好，而是要让 AI 明白：做什么、根据什么做、交付成什么样、哪些事情不能做、怎样算完成。

需求模糊 → AI 只能猜 → 猜错以后继续返工 → 补充目标、背景和交付要求 → 再加上限制和检查标准 → AI 才能稳定完成任务 → 有效提示词继续沉淀为模板 → 最终变成可以重复运行的工作流

不要研究怎么“控制 AI”，先学会怎么“交代工作”。

一、提示词不是咒语，而是工作说明

很多人写提示词时，会先写一大段：

你是一位世界顶级产品经理、战略专家、投资人和写作大师……

然后希望 AI 一次给出完美答案。

但真正影响结果的，通常不是角色有多厉害，而是下面几个问题有没有说清楚：

你到底要什么；
结果给谁看；
AI 应该参考哪些资料；
最终要交付什么；
哪些事情不能做；
怎样判断结果合格。

比如下面这句话：

帮我分析一下这份会议记录。

AI 不知道你到底想要什么。

你是想要：

一份会议摘要；
一份发给老板的汇报；
一份任务清单；
一份风险分析；
还是一封会后邮件？

换成下面这样，结果通常会稳定很多：

把这份会议记录整理成一份发给项目团队的会议纪要。

先列出已经确定的决定，再列出下一步任务。
每项任务写清楚负责人和截止日期。

提示词的核心，不是写得专业，而是把工作交代清楚。

二、一个好提示词，只需要说清五件事

OpenAI 官方将核心部分归纳为 Goal、Context、Output 和 Boundaries。为了让结果真正可验收，这份手册再加上一项 Verification，形成五件事：

目标、背景、交付、边界、检查

英文可以记成：

Goal
Context
Output
Boundaries
Verification

不需要每次都写满。

简单任务，只写目标就够了。

复杂任务，再逐项补充。

1. 目标：你最终想得到什么

先告诉 AI 最终结果，不要一上来就安排几十个步骤。

不清楚的写法：

研究一下客户支持平台。

更清楚的写法：

比较三款适合 50 人团队使用的客户支持平台，并给出采购建议。

再进一步：

比较三款适合 50 人团队使用的客户支持平台。

最终输出一份给管理层看的采购建议，重点比较价格、安全性、接入难度和迁移成本。

这里已经说清楚了：

做什么：比较产品；
为谁做：管理层；
用来干什么：采购决策；
重点看什么：价格、安全性、接入和迁移。

一个简单判断方法

写完目标后，问自己：

AI 做完以后，我手里会多出一个什么东西？

如果这个问题回答不出来，说明目标还不够清楚。

2. 背景：AI 需要知道哪些信息

AI 不知道你脑子里的背景。

你需要补充那些会影响结果的信息。

例如：

谁会看这份内容；
当前项目处于什么阶段；
已经做出了哪些决定；
哪些数据是最新的；
应该参考哪些文件；
时间范围是什么；
哪些情况已经试过了。

例如：

我们是一家 30 人的软件公司，目前使用邮箱处理客户问题。

团队希望引入客户支持平台，但没有专门的实施团队，预算也比较有限。

这两句话会直接影响 AI 的推荐。

如果没有这段背景，AI 可能推荐一套功能很强，但部署复杂、价格很高的系统。

背景不是越多越好

只提供会改变答案的信息。

无关信息太多，反而会让重点变模糊。

可以用这个标准判断：

删除这条信息后，AI 的答案会不会改变？

会改变，就保留。

不会改变，就可以删除。

3. 交付：最后要以什么形式给你

“详细一点”“专业一点”“高级一点”都太模糊。

最好直接说明：

输出给谁看；
用在什么地方；
需要多长；
用文章、表格还是演示文稿；
先写什么，后写什么；
是否需要引用来源；
是否区分事实和判断。

例如：

请输出一份不超过 1,500 字的中文分析。

读者是没有技术背景的创业者。

先给出结论，再解释原因，最后给出三个可以立即执行的建议。

再比如：

请整理成一张对比表。

表格至少包含：
- 产品名称
- 价格
- 核心能力
- 适合团队
- 主要缺点
- 推荐程度

把抽象要求改成具体要求

不要写：

写得有深度一点。

可以改成：

除了支持这个观点的理由，还要写出反方观点、失败条件和主要风险。

不要写：

写得简洁一点。

可以改成：

控制在 800 字以内，每段不超过 4 行，删除重复背景。

不要写：

写得专业一点。

可以改成：

使用准确术语，但每个专业概念都要用一句通俗语言解释。

不要只给形容词，要给可以执行的标准。

4. 边界：哪些事情不能做

边界用来避免 AI 做错事，或者做出你没有授权的动作。

例如：

只根据我提供的资料分析，不要补充未经验证的数据。

不要修改已经确定的预算和日期。

信息不足时直接标记“待确认”，不要猜测。

只生成邮件草稿，不要发送。

不要修改线上代码，先给出方案。

边界不需要很多。

通常聚焦最重要的一两条；高风险任务再补充必要的审批与核验条件。

哪些情况一定要写边界

当任务涉及下面这些事情时，最好明确说明：

发送邮件；
发布内容；
修改代码；
修改数据库；
删除文件；
使用公司内部数据；
对外报价；
涉及预算、法律或合规判断。

草拟内容与写入、发送、发布、执行属于不同风险等级，应分别授权。

5. 检查：怎样算真正完成

很多人最后会写：

请确保准确。

这句话作用有限，因为“准确”没有具体标准。

最好告诉 AI 在完成前检查什么。

例如：

完成前检查：
1. 每项任务是否都有负责人；
2. 每项任务是否都有截止日期；
3. 是否存在前后矛盾；
4. 是否列出了仍待确认的信息。

再比如代码任务：

修改完成后：
1. 重新执行复现步骤；
2. 运行 lint；
3. 运行相关测试；
4. 列出修改过的文件；
5. 说明是否还有未解决的问题。

再比如研究任务：

完成前检查：
- 所有价格是否注明查询日期；
- 所有关键事实是否有来源；
- 是否区分事实、分析和假设；
- 是否列出无法验证的信息。

不要只让 AI“认真一点”，要告诉它检查什么。

三、直接可用的通用提示词模板

下面这份模板，可以用于大多数复杂任务。

任务目标：
请帮我完成【具体任务】。

使用场景：
这份结果会用于【使用场景】。
主要读者是【目标读者】。

背景信息：
- 当前情况：【背景】
- 已知条件：【条件】
- 参考资料：【文件、网页、数据或来源】
- 时间范围：【时间范围】

输出要求：
- 输出形式：【文章、表格、报告、演示文稿、代码等】
- 长度：【长度要求】
- 结构：【先写什么，再写什么】
- 重点：【最重要的信息】
- 表达方式：【通俗、专业、简洁等具体要求】

边界：
- 不要【不能做的事】
- 必须保留【不能改变的内容】
- 信息不足时【如何处理】

完成前检查：
1. 【检查项一】
2. 【检查项二】
3. 【检查项三】

最后请列出：
- 仍待确认的信息
- 主要风险
- 下一步建议

这份模板不用每次全部填写。

可以根据任务大小删减。

四、最实用的方法：先出第一版，再继续修改

不要期待第一次提示就得到完美结果。

更高效的方法是：

先生成
→ 看差距
→ 指出问题
→ 局部修改
→ 再检查

比如第一版太长，可以直接说：

保留当前核心观点，把全文压缩到 1,000 字以内。
删除重复解释，每一部分只保留一个例子。

如果结论不够突出，可以说：

保留现有证据，但把核心判断放到开头。
每一节先写结论，再写原因。

如果文章太专业，可以说：

内容不要减少，但换成普通创业者也能理解的语言。
每个专业术语后面增加一句通俗解释。

如果只想改其中一部分，可以说：

保留其他内容不变，只重写第三部分。
第三部分需要更具体，并增加可执行步骤。

修改提示词的简单公式

后续修改时，说清楚三件事：

保留什么
修改什么
不要影响什么

例如：

保留现有结构和数据。

把表达改得更通俗，每段不超过四行。

不要修改结论和引用来源。

不要每次从头重写提示词，直接在当前结果上继续收敛。

五、Chat、ChatGPT Work 和 Codex 应该怎么写提示词

不同工作入口，适合不同类型的任务。

1. Chat：适合快速回答和轻任务

适合：

解释一个概念；
改写一段文字；
头脑风暴；
比较几个简单方案；
制订轻量计划；
快速总结内容。

示例：

用没有投资经验的人也能理解的方式解释复利。

使用一个 10 万元本金的具体例子。
控制在 500 字以内。

Chat 的重点是：

说明想得到什么，再补充必要背景。

2. ChatGPT Work：适合完成一整项工作

适合：

同时阅读多个文件；
搜索和整理资料；
调用多个工具；
生成报告、表格和演示文稿；
完成多步骤任务；
制订完整项目计划；
在支持 Scheduled tasks 的环境中安排定期工作。

Chat 和 Work 的区别可以简单理解为：

Chat 更适合快速回答与轻量草稿，Work 更适合跨来源、多工具、多步骤或较大的交付物。

具体可用的工具、连接来源和定时能力，会因套餐与工作区设置而异。

示例：做采购研究

研究三款适合 50 人公司的客户支持平台。

重点比较：
- 定价
- 安全性
- 集成能力
- 数据迁移成本
- 实施周期

输出一份给管理层看的采购建议。

先给推荐结论，再写主要原因、风险和签约前需要确认的问题。

所有价格和产品能力都要注明来源和查询日期。

不要联系厂商，不要提交任何表单。

示例：整理季度材料

使用附件中的季度报告，生成：

1. 一份管理层决策简报；
2. 一份 6 页演示文稿。

先列出本季度最需要决定的三个问题。

区分：
- 报告中的事实
- 你的分析
- 仍待确认的假设

所有数字都要注明来自哪个文件。

完成前检查简报和演示文稿中的数据是否一致。

示例：做产品发布计划

根据附件中的产品说明，创建一份完整的产品发布计划。

包括：
- 时间线
- 负责人
- 依赖关系
- 主要风险
- 发布公告草稿
- 客户常见问题
- 上线检查清单

先列出当前尚未确定、但会影响发布的关键问题。

只生成内容和计划，不要发送邮件，不要发布公告，不要修改线上内容。

3. Codex：适合代码和开发任务

Codex 提示词需要说清四件事：

现在出了什么问题；
怎样复现；
哪些东西不能改；
修改后怎样验证。

示例：修复 Bug

问题：
用户在设置页面点击“保存”后，页面显示成功，但刷新后设置恢复原值。

复现步骤：
1. 运行 npm run dev
2. 打开 /settings
3. 修改 Enable alerts
4. 点击 Save
5. 刷新页面

约束：
- 不修改现有 API 结构；
- 尽量使用最小修改；
- 不重构无关代码；
- 可以增加回归测试。

请先复现问题，再定位根因。

修复完成后：
1. 重新执行复现步骤；
2. 运行 lint；
3. 运行相关测试；
4. 列出修改的文件；
5. 说明问题根因和修复方式。

示例：先理解代码，不要直接修改

请先解释这个服务的请求处理流程，不要修改代码。

重点阅读：
- api.ts
- schema.ts
- handler.ts

请说明：
1. 每个文件负责什么；
2. 请求从哪里进入；
3. 数据在哪里校验；
4. 错误在哪里处理；
5. 修改时最容易出现什么问题。

最后用编号列表画出完整请求流程。

示例：大型重构

我们准备重构认证模块。

目标：
- 分离 Token 解析、Session 加载和权限判断；
- 减少循环依赖；
- 提高测试能力。

约束：
- 不改变用户可见行为；
- 保持现有公共 API；
- 每个阶段都能独立回滚；
- 不处理无关问题。

先不要改代码。

先输出：
1. 当前模块结构；
2. 主要依赖；
3. 风险；
4. 分阶段重构计划；
5. 每个阶段涉及的文件；
6. 测试方案；
7. 回滚方案。

明确授权的小改动可以直接执行；多步骤、高风险或影响范围不清的改动，先出计划更稳妥。

六、六个最常见的错误

错误一：角色写了很多，任务没有说清楚

错误示例：

你是一位世界顶级商业专家，请深入分析。

问题在于：

分析什么；
给谁看；
用来做什么；
交付什么；
怎样算深入；

这些都没有说清楚。

可以改成：

分析这家公司的商业模式。

读者是准备投资这家公司的普通投资人。

请说明：
- 公司如何赚钱；
- 成本主要在哪里；
- 为什么持续亏损；
- 资本为什么仍然愿意投资；
- 最主要的三项风险。

错误二：要求“详细”，但没有重点

错误示例：

请详细介绍这个产品。

AI 很可能什么都写，结果却很难读。

可以改成：

请介绍这个产品。

重点回答：
1. 它解决什么问题；
2. 谁会付钱；
3. 为什么用户不用现有工具；
4. 它靠什么赚钱；
5. 最难建立的壁垒是什么。

控制在 1,200 字以内。

错误三：一次塞入太多无关背景

不是资料越多，结果越好。

正确做法是告诉 AI：

哪些文件最重要；
每份资料用来解决什么问题；
只看哪个时间范围；
哪些旧资料可以忽略。

例如：

以 2026 年 6 月之后的材料为准。

优先使用“产品方案 V3”和“最新会议纪要”。

旧版 V1 和 V2 只作为背景，不要引用其中已经废弃的数据。

错误四：只说“写得高级”

“高级”无法执行。

可以改成：

使用专业但通俗的语言。

每一部分先给一句明确判断，再解释原因。

不要使用空泛口号。

每个建议都要说明具体行动和适用条件。

错误五：没有区分草稿和执行

例如：

帮我给客户写封邮件。

这句话没有说明是草稿，还是直接发送。

更安全的写法是：

先生成邮件草稿，不要发送。

邮件需要解释延期原因，并给出新的交付日期。
语气诚恳，但不要过度道歉。

错误六：第一次结果不好，就重新开始

没有必要重新开一个对话。

直接告诉 AI 差在哪里：

当前版本信息完整，但太松散。

请保留事实和结论，删除重复背景。

按照“结论—原因—行动”的结构重新整理。

会修改，比会写第一条提示词更重要。

七、把好提示词变成可重复使用的工作流

当一个提示词经过多次使用，已经能够稳定产生好结果，就不要每次重新写。

在 ReelOS 的实践框架中，可以逐步升级成：

一次性提示词
→ 固定模板
→ 团队标准流程
→ 可复用 Skill
→ 定时任务
→ 自动执行的 Agent Loop

例如，每周都要做一次项目周报。

一开始可以手动输入：

整理本周进展、风险和下周计划。

之后逐步固定为：

读取本周会议记录、项目任务和团队更新。

输出：
1. 本周关键进展
2. 本周最大风险
3. 下周关键里程碑
4. 需要管理层决定的问题

每项进展必须说明结果，不只描述过程。
每项风险必须说明影响和负责人。

再稳定之后，可以变成每周自动执行的任务。

不要先自动化一个还没有跑顺的流程。

八、提交提示词前，快速检查这五个问题

目标

我到底想得到什么？
AI 做完以后，会交付一个什么结果？

背景

AI 缺少哪些关键背景？
哪些信息会直接改变答案？

交付

结果给谁看？
用在什么场景？
需要什么格式、长度和结构？

边界

哪些事情不能做？
哪些信息不能猜？
是否涉及发送、发布或修改数据？

检查

怎样算完成？
哪些事实需要来源？
哪些内容必须人工确认？

只要这五个问题清楚，提示词通常就不会太差。

结语：真正重要的不是提示词，而是任务设计

过去，我们把 AI 当成一个聊天机器人。

所以，我们关心的是：

怎样问出一个好答案？

现在，AI 正在进入真实工作。

更重要的问题变成了：

怎样把一项工作完整地交给 AI？

一份可靠的任务说明，需要包含：

清楚的目标；
必要的背景；
明确的交付物；
关键的边界；
可执行的检查标准。

不要把提示词写成咒语，要把它写成一份可以执行、可以检查、可以继续改进的工作说明。

进阶阅读

如果你已经掌握这套五项清单，希望进一步为强模型设计复杂任务，可以继续阅读《GPT-5.5 Prompting Playbook：把 Prompt 写成任务合同，而不是咒语》。

原始资料

OpenAI，《Prompting：Write useful prompts for Chat, ChatGPT Work, and Codex》

来源：

https://learn.chatgpt.com/docs/prompting

本文基于 OpenAI 官方内容进行中文整理、案例补充和实践化改写。Goal / Context / Output / Boundaries 与 final check 来自官方框架；Skill、定时任务和 Agent Loop 为 ReelOS 的实践延伸。官方页面核验于 2026 年 7 月 14 日。