一句话结论
GPT-5.5 时代，好的 Prompt 不再是“把步骤写满”，而是把目标、标准、边界、证据和交付形式写清楚。
Prompt 的本质，正在从“提示词技巧”变成“任务设计能力”。
适用对象
这份 Playbook 适合三类人：
- 经常用 ChatGPT / GPT-5.5 写文章、总结资料、做研究的人；
- 用 Codex / Claude Code / Cursor 做 AI Coding 的开发者和产品经理；
- 正在设计 Agent、Skill、Workflow、AI 工作流的 Builder。
这不是一篇“万能提示词大全”。
它解决的是一个更底层的问题：
如何把任务交给强模型，让它既能发挥能力，又不乱发挥。
核心判断：Prompt 从“指令脚本”变成“任务合同”
旧模型时代，很多人写 Prompt 的方式像写操作手册：
先做 A。 再做 B。 然后做 C。 最后输出 D。
这种写法在旧模型上有用，因为旧模型容易跑偏，需要用户一步一步牵着走。
但 GPT-5.5 这类模型的能力更强，它本身更擅长理解复杂目标、调用工具、综合资料、做判断、写代码、检查结果。
所以，继续把 Prompt 写成厚厚的流程脚本，反而可能限制它。
更好的方式是把 Prompt 写成一份任务合同。
一份任务合同需要讲清楚：
- 我要什么结果；
- 这个结果给谁用；
- 什么叫完成得好；
- 哪些事情不能做；
- 哪些内容必须验证；
- 信息不足时怎么处理；
- 最终交付成什么形式。
这比“请一步一步思考”更重要。
Part 1：GPT-5.5 Prompting 的 5 个核心原则
原则一：少写流程，多写结果
很多人会这样写：
请先阅读资料，再提取重点，再整理结构，再写摘要，再检查遗漏。
这不是错，但通常不是最优。
因为你把模型的路径提前写死了。
更好的写法是：
请把这份资料整理成一版适合普通读者阅读的说明文章。
最终结果需要满足：
- 不懂专业背景也能看懂；
- 保留原资料里的关键判断；
- 不新增没有依据的事实；
- 结构自然，不像资料摘抄；
- 最后给出一段简短总结。
这里没有规定模型必须先做什么、后做什么。
但你规定了结果标准。
强模型更适合这种写法。
你不需要替它安排每一步。 你要告诉它最后什么样才算好。
原则二：少说“做好一点”，多写“成功标准”
模糊提示词最大的问题，是模型不知道你在优化什么。
比如：
帮我把这篇文章写好一点。
这句话太宽。
“好”可能代表：
- 更短；
- 更顺；
- 更有逻辑；
- 更像人写；
- 更适合发布；
- 更有商业判断；
- 更有传播性；
- 更适合普通读者。
你不说清楚，模型只能猜。
更好的写法是：
请帮我修改这篇文章。
成功标准：
- 普通读者能看懂；
- 语言自然，不像正式报告；
- 保留原文观点；
- 删除重复和空泛表达；
- 不新增未经确认的事实；
- 修改后可以直接发布。
GPT-5.5 很适合按标准交付。
你给它标准，它就能判断哪些内容该保留，哪些内容该删，哪些表达该重写。
原则三：边界要写清楚，不然模型会“好心多做”
强模型的一个特点是：它会主动推进。
这很好，但也有风险。
你让它润色文章，它可能顺手重写结构。 你让它修一个小 bug，它可能顺手重构代码。 你让它分析资料，它可能补充外部背景。 你让它给建议，它可能扩展成完整方案。
如果你希望它大胆发挥，可以明确授权。
但大多数工作任务里，边界更重要。
例如改文章：
请优化语言表达，但不要改变文章的核心观点。
可以调整句子顺序和段落衔接。 不要新增新的论点。 不要改成立场更强的版本。 不要写成营销文。
例如写研究报告：
请基于我提供的资料写。 不要补充外部事实。 如果某个地方信息不足，请标注“这里缺少依据”，不要自行编造。
例如改代码：
请只修复当前问题，做最小必要修改。 不要重构无关代码。 不要新增功能。 不要改变现有接口。 如果发现其他问题，请在最后列出来，但不要直接修改。
边界不是限制模型能力。
边界是告诉模型：哪里可以主动，哪里必须克制。
原则四：证据规则决定结果可信度
GPT-5.5 能把答案写得很顺。
但写得顺，不代表一定可靠。
尤其是涉及这些内容时，必须写清楚证据规则：
- 具体日期；
- 数据；
- 价格；
- 政策；
- 法规；
- 产品版本；
- 人物职位；
- 公司动态；
- 融资信息；
- 技术规格；
- 医疗、法律、金融判断。
一个好的研究提示词，不应该只写：
帮我研究一下这个项目。
更好的写法是：
请研究这个项目，并区分事实、判断和推测。
凡是涉及具体日期、版本、融资、团队、产品功能和数据的内容，都需要查证。
如果来源之间说法不一致，请指出差异。 如果没有足够证据，请明确写“不确定”，不要把猜测写成事实。
找到足够支撑核心判断的证据后，就停止搜索，不要为了边缘细节无限扩展。
这里有两个关键规则：
第一，什么必须查证。 第二，查到什么程度可以停止。
很多人只要求模型查证，却不告诉它什么时候停止。
结果要么没查就答，要么查个没完。
好的 Prompt 不只是要求“找资料”。
好的 Prompt 要定义“证据到什么程度算够”。
原则五：控制输出形态，而不是控制模型思考
很多人会把“回答短一点”理解成“少思考一点”。
这是错的。
好的模型应该可以深度思考，但简洁表达。
不要只写：
简洁一点。
更好的写法是：
请先给结论，再补充必要原因。
回答控制在 800 字以内。 不要展开背景知识。 不要重复我已经知道的内容。 但不要省略会影响判断的重要信息。
同样，不要只写：
详细分析一下。
更好的写法是：
请做完整分析，包括：
- 核心结论；
- 支撑依据；
- 反对意见；
- 不确定因素；
- 下一步建议。
回答短，不代表思考浅。 回答长，也不代表质量高。
你要控制的是最终呈现，而不是让模型少想。
Part 2：GPT-5.5 任务合同模板
通用模板
把下面这段复制出去，替换空白部分即可：
我要完成的目标是：______
这个结果会用于：______
读者 / 使用者是：______
最终结果需要满足：______
请重点处理：______
请不要做：______
需要查证或验证的地方是：______
如果信息不足，请：______
最终输出格式是：______这个模板背后有 5 个关键字段：
| 字段 | 作用 |
|---|---|
| 目标 | 让模型知道要完成什么 |
| 场景 | 让模型知道如何取舍 |
| 标准 | 让模型知道什么叫做好 |
| 边界 | 防止模型过度发挥 |
| 验收 | 提升结果可信度和可用性 |
这就是任务合同。
模板 1：写文章 / Playbook
我要写一篇关于 ______ 的文章。
这篇文章会发布到 ______。
读者是 ______。
核心判断是：______。
成功标准：
1. 开头有明确判断；
2. 不只是罗列信息，要讲清楚背后的变化；
3. 语言清楚，有传播性，但不夸张；
4. 保留专业概念，但用普通话解释；
5. 文章可以直接发布。
请重点讲：
1. ______；
2. ______；
3. ______；
4. ______。
请不要做：
1. 不要写成官方说明文；
2. 不要堆术语；
3. 不要写成营销文；
4. 不要加入没有依据的事实。
最终输出：
标题 + 摘要 + 正文 + 行动建议。适用场景：
- 公众号文章；
- 产品分析；
- AI Playbook；
- 技术趋势解读；
- 团队内部方法论。
模板 2：资料总结
请总结下面这份资料。
目标：
让没有读过原文的人，也能快速理解资料的核心内容。
成功标准：
1. 先给核心结论；
2. 提取关键判断，而不是逐段复述；
3. 保留重要事实、数字、人物、时间和因果关系；
4. 区分原文事实和你的判断；
5. 不加入资料外的信息。
边界：
如果资料没有提到某件事，请不要自行补充。
如果某个地方不确定，请写“不确定”。
输出格式：
1. 一句话结论；
2. 3-5 条关键要点；
3. 重要细节；
4. 可行动建议；
5. 需要进一步确认的问题。适用场景：
- 长文总结；
- 会议纪要；
- 研究材料整理；
- PDF / 文档归纳；
- 竞品资料分析。
模板 3：项目研究
请研究这个项目：______
研究目标：
判断这个项目是否值得关注，以及它释放了什么产品 / 技术 / 市场信号。
成功标准：
1. 先给明确结论；
2. 讲清楚项目做什么；
3. 分析它解决了什么真实问题；
4. 判断它的创新点和局限；
5. 区分事实、判断和推测；
6. 给出对 Builder 的启发。
证据规则：
凡是涉及发布时间、团队、融资、产品功能、版本、价格、数据的内容，都需要查证。
如果不同来源说法不一致，请指出差异。
如果没有足够证据，请明确写“不确定”。
停止规则：
找到足够支撑核心判断的资料后，就停止搜索，不要为了边缘细节无限扩展。
输出格式：
1. 核心判断；
2. 项目简介；
3. 解决的问题；
4. 产品 / 技术亮点；
5. 局限和风险；
6. 对 Builder 的启发；
7. 参考链接。适用场景：
- GitHub 项目分析；
- 新产品研究；
- AI Agent 框架评测；
- 投资 / 产品信号判断；
- ReelOS Signals / Playbook 写作。
模板 4：代码修复
你是一个负责修复问题的软件工程助手。
任务目标：
修复 ______ 问题。
范围：
只修改和这个问题直接相关的代码。
不要做：
1. 不要重构无关模块；
2. 不要新增功能；
3. 不要改变公开接口；
4. 不要为了风格统一改动大量文件；
5. 不要修改没有证据表明相关的文件。
验收标准：
1. 问题原因已经说明；
2. 修改范围最小；
3. 相关调用点已经检查；
4. 能运行的测试已经运行；
5. 如果测试无法运行，需要说明原因；
6. 最后列出修改了哪些文件和为什么修改。
如果发现其他问题：
请在最后列出，但不要直接修改。适用场景：
- Codex；
- Claude Code；
- Cursor；
- Bug 修复；
- 小范围代码改动；
- 老项目维护。
模板 5：前端 / 设计任务
请设计一个 ______ 页面。
用户是：______。
使用场景是：______。
用户最重要的任务是：______。
设计目标：
重点是清楚、稳定、易用，不是视觉炫技。
成功标准：
1. 信息层级清楚；
2. 关键数据 / 操作突出；
3. 筛选、表格、按钮易用；
4. 页面有加载、空状态和错误状态；
5. 适配桌面端和移动端；
6. 视觉风格统一。
请不要做：
1. 不要使用无意义的大图；
2. 不要堆叠太多卡片；
3. 不要使用夸张渐变；
4. 不要为了好看牺牲可读性；
5. 不要忽略边界状态。
输出格式：
1. 页面结构说明；
2. 信息层级；
3. 组件清单；
4. 关键交互；
5. 可直接实现的前端代码。适用场景：
- 数据看板；
- SaaS 后台；
- AI 产品页面；
- Landing Page；
- 管理后台；
- 运营 Dash。
Part 3：常见错误与修正方式
错误 1：把 Prompt 写成咒语
错误写法：
你是世界顶级专家，请一步一步思考，必须给出最专业、最深入、最全面、最有洞察力的回答。问题：
这句话看起来很强，但没有定义任务。
更好的写法：
请分析 ______。
成功标准：
1. 先给结论；
2. 说明依据；
3. 指出风险；
4. 区分事实和判断；
5. 给出下一步建议。错误 2：只说方向，不说标准
错误写法：
帮我优化一下。更好的写法：
请优化这段文字。
成功标准：
1. 更清楚；
2. 更自然；
3. 更短；
4. 保留原意；
5. 不新增信息；
6. 可以直接发送。错误 3：边界没写清楚
错误写法：
帮我修这个 bug。可能结果：
模型顺手改了一堆文件。
更好的写法：
请只修复当前 bug，做最小必要修改。
不要重构无关代码。
不要新增功能。
不要改变公开接口。
修改后说明原因、改动范围和验证方式。错误 4：要求查证，但没有停止规则
错误写法：
请联网查资料后回答。可能结果：
模型查很多边缘资料，输出变慢，重点变散。
更好的写法：
凡是涉及具体日期、数据、价格、版本和公司动态的内容都需要查证。
找到足够支撑核心判断的证据后，就停止搜索并开始回答。
不需要为普通背景描述逐句找来源。错误 5：把长输出当成深度
错误写法：
详细分析一下，越详细越好。更好的写法：
请做完整分析，但控制在 1500 字以内。
必须包括：
1. 核心结论；
2. 支撑依据；
3. 反对意见；
4. 风险；
5. 行动建议。深度不是长度。
深度是结构、证据、判断和取舍。
Part 4：Reasoning Effort 怎么用
GPT-5.5 支持不同强度的 reasoning effort。
可以简单理解成：
这次任务要让模型花多少精力去想。
一个实用判断：
| 任务类型 | 建议强度 |
|---|---|
| 改一句话、写短消息、简单分类 | low |
| 普通写作、总结、轻量分析 | medium |
| 研究报告、代码调试、复杂策略判断 | high |
| 长文档、多工具、多阶段、强验证任务 | xhigh |
但注意：
更高不一定永远更好。
如果任务目标不清楚、边界不清楚、验收标准不清楚，把 reasoning effort 拉高，可能只是让模型更认真地跑偏。
正确顺序是：
- 先写清楚任务合同；
- 再选择 reasoning effort；
- 最后根据结果调整。
不要用算力弥补任务定义的混乱。
Part 5：长任务协作规则
GPT-5.5 很适合长任务。
但长任务有一个体验问题：
用户不知道模型在干什么。
所以可以加一条协作规则：
如果这个任务需要多步处理，请先用 1-2 句话说明你会怎么推进，然后直接开始。
只有在出现重要进展时再更新我，比如：
1. 找到关键问题；
2. 完成一个阶段；
3. 遇到阻塞；
4. 需要我决策。
不要汇报普通操作。这条规则很适合：
- 长代码任务；
- 多资料研究；
- 项目评测；
- 报告生成；
- 多工具 Agent 工作流。
好的长任务体验，不是每一步都汇报。
而是在关键节点让用户放心。
Part 6：发布前检查清单
每次写 GPT-5.5 Prompt 前，检查这 10 个问题：
- 我有没有写清楚最终目标？
- 我有没有说明结果给谁用？
- 我有没有定义成功标准？
- 我有没有写清楚不要做什么？
- 我有没有说明哪些内容必须查证？
- 我有没有说明信息不足时怎么处理？
- 我有没有定义输出格式？
- 我有没有避免过度规定流程？
- 我有没有区分“输出长度”和“思考深度”？
- 我有没有要求最后检查结果？
如果这 10 个问题都回答清楚，你的 Prompt 已经比 90% 的提示词更稳定。
Part 7：最小可用 Prompt
真正日常使用时，不需要每次写很长。
可以用这个最小版本：
我要完成的目标是：______
成功标准是：
1. ______
2. ______
3. ______
请不要做：
1. ______
2. ______
如果信息不足，请先基于合理假设继续，并说明假设。
如果缺少的信息会明显影响结论，请只问最关键的一个问题。
最终输出格式是：______这个版本足够应对大部分日常任务。
它不是最完整的 Prompt，但它有最重要的骨架：
目标。 标准。 边界。 信息不足策略。 输出格式。
最后总结
GPT-5.5 Prompting 的关键，不是更复杂，而是更清楚。
不要把 Prompt 写成咒语。 不要把 Prompt 写成流程堆叠。 不要用一堆“必须、永远、绝对”制造虚假的控制感。
真正有效的 Prompt，是一份任务合同。
它定义：
目标是什么。 结果给谁用。 什么叫做好。 哪些不能做。 哪些必须验证。 什么时候停止。 最终如何交付。
强模型不需要你替它安排每一步。
它需要你把任务定义清楚。
目标让它发挥能力。 标准让它知道什么叫完成。 边界让它不跑偏。 证据让它可信。 验收让结果可用。
这就是 GPT-5.5 时代最重要的 Prompting 思路：
少写流程，多写目标。 少写命令，多写标准。 少写咒语，多写合同。