Enivia 最近我认真读了 OpenAI 官方发布的 Prompting 官方指南。读完感觉收获颇多，最明显的感受是，写好 Prompt 并没有想象中那么复杂。
Prompt 可以是一个问题、一项指令，也可以只是对最终目标的描述。最重要的是，先用自己的语言表达清楚需求，然后根据 ChatGPT 的回答继续补充和调整。
真正影响结果的，通常只有四个因素：目标、上下文、输出形式、边界。
这四个部分并不需要每次都填写完整。任务越简单，Prompt 就可以越简短；任务越重要、涉及的信息越多，我们才需要把关键条件交代完整。
在规划步骤先确定任务结果
很多开发者写 Prompt 时，可能经常会把重点放在过程上。例如要求 AI 先分析什么、再比较什么、最后执行什么。
而 OpenAI 给出的建议是，应该优先描述自己最终需要的结果，包括结果的格式和受众。至于具体采用什么分析过程，可以给模型留出一定空间。
例如，与其写：
先分析会议记录，然后提取重点，再判断哪些内容适合发送给项目成员，最后整理成一份更新报告。不如直接写成：
将会议记录整理成一份简短更新报告发送给项目团队，将已确定的决策和下一步行动放在最前面。第二种写法更短，信息也更集中。它明确说明了要生成什么、写给谁，以及哪些内容优先。
所以在写 Prompt 时，可以先问自己三个问题：
- 我最终需要什么东西？
- 谁会阅读或使用它？
- 什么内容最重要？
只要这三个问题能够回答清楚，Prompt 就已经完成了一半。
提供真正能影响结果的上下文
上下文并不是越多越好。有效的上下文，应该能够改变 ChatGPT 对任务的理解或输出方式。
如果要让 ChatGPT 总结、对比或改写材料，就应该直接上传相关文档、表格、演示文稿或 PDF。如果任务依赖页面设计、数据图表或视觉细节，就提供截图，并指出需要关注的位置。如果问题涉及新闻、价格、政策、产品信息或其他可能变化的内容，就明确要求使用网络搜索，并附上可核查的信息来源。
对于持续时间较长的工作，还可以把相关对话和文件放在同一个项目中。这样，后续任务就能够沿用相同的背景材料，不必在每次对话中重新解释。
当 ChatGPT 可以访问云盘、邮件、Slack、GitHub 等连接来源时，也不需要替它设计每一次搜索。只要告诉它去哪里查找，以及需要找到什么即可。例如：
使用 Drive 中最新的项目计划，并结合项目 Slack 频道中的相关决策和进展，准备一份项目状态更新报告。这种写法给出了信息来源和任务目标，同时保留了合理的执行空间。
只设置真正重要的边界
一份高质量 Prompt 往往会包含少量明确的边界。
边界的作用，是防止 ChatGPT 修改不该修改的信息、超出任务范围，或者执行用户还没有准备好的操作。OpenAI 给出的典型例子包括：
- 核准日期和预算数字保持不变
- 只使用提供的资料来源，标记缺失信息，不要盲目猜测
- 所有建议必须控制在规定预算内
- 只生成邮件草稿，不要直接发送
这里的关键是控制数量。一般只需要写出一两个会直接影响结果的限制，没有必要规定模型的所有行为。
例如，让 ChatGPT 分析一份销售报告时，真正重要的边界可能只有：
不要修改原始数据。无法从文件中确认的信息请标记为“待核实”。如果我让它帮助准备对外沟通，边界可能是：
生成可供审核的草稿，不要发送或发布。边界的具体和可执行性，也能避免产生额外工作。
告诉 ChatGPT 你将如何使用结果
同一份内容，给管理层阅读、给客户发送、供内部讨论，应该采用不同的内容长度、结构和表达方式。
因此，应该在 Prompt 中说明输出的实际用途，例如：
生成一页以内的管理层摘要报告，供总监在会议前快速阅读。先说明需要作出的决定，再写下一步行动。或者：
将这些记录整理成会后邮件，列出已经确定的事项、负责人和截止日期。当 ChatGPT 知道内容将在哪里使用，就更容易选择适当的信息密度和组织方式。
对于重要工作，还可以增加一个最终检查要求：
任务结束前需确认每项行动都有负责人和截止日期。无法核实的信息需单独列出。这一步很实用，它相当于在生成内容后，再执行一次针对关键风险的质量检查。OpenAI 同样建议，重要结果在实际使用或分享前仍应由使用者完成最终审核。
第一条 Prompt 不需要一次性写到完美
很多人写 Prompt 时会有一种压力，认为第一句话就必须包含所有信息，否则就得重新开始。
实际上，OpenAI 明确建议通过后续消息逐步改善结果。第一版出来以后，我们可以针对具体问题继续调整，例如：
开头再直接一些，保留现有证据，把建议移动到背景介绍之前。也可以补充遗漏的来源、纠正方向、变更方案，或者调整篇幅以及详细程度，不需要重新提交整个任务。
这条建议也让我重新理解了 Prompt 的作用。它更像一次持续的协作，而不是一张必须一次填写正确的表单。
当输出偏离预期时，你不应该简单地说“重新写”或者“写得不好”，而是指出需要发生的具体变化：
保留当前结构，将正文缩短到 800 字以内。删除重复观点，每个部分只保留一个核心结论。语气更加客观，减少宣传性表达。保留分析过程，但把最终建议移到开头。反馈越具体，你得到的结果通常越接近预期。
根据任务规模选择合适的工作方式
官方指南也区分了不同类型的任务。
日常问答、构思、短篇改写和轻量草稿，可以直接使用普通聊天。涉及多个来源、多个步骤、工具调用、文件生成或较大交付物时，则应该把它当成一项完整工作来描述，包括结果、来源、受众、审核方式和操作权限。
例如，准备管理层资料时，可以这样写：
使用附件中的季度报告，制作一份管理层简报和六页演示文稿。受众是公司管理团队。先说明需要管理层决定的三个问题，区分报告中的事实和你的分析，所有数字都要标注来源，并在完成前检查简报与演示文稿中的数据是否一致。这条 Prompt 同时规定了交付物、受众、内容顺序和最终检查，因此很适合需要直接投入工作的复杂任务。
在编程任务中，同样的原则依然适用。与其只告诉 Codex“修复这个错误”，更有效的方式是提供复现步骤、相关文件、不能改变的接口、期望运行的测试，以及修复后的验证方法。
OpenAI 的示例尤其强调，明确的复现步骤和约束通常比笼统的故障描述更有价值。
我在使用的 Prompt 基础模板
结合官方指南，我将自己的常用 Prompt 简化成了如下结构：
<!-- 目标 -->
请完成什么任务，最终需要得到什么结果。
<!-- 上下文 -->
使用哪些资料、文件、数据或信息来源。说明哪些背景会影响结果。
<!-- 输出 -->
内容写给谁看，以什么格式呈现，需要多长，哪些信息放在前面。
<!-- 边界 -->
哪些内容不能修改，哪些事情不能执行，信息不足时应该如何处理。
<!-- 检查 -->
完成前检查哪些关键问题，并报告无法确认的信息。这套结构并不是必须严格遵守的公式。简单任务可能只需要一句话，复杂任务才需要补充更多信息。官方指南反复强调，应当只使用对当前任务有帮助的部分。
最后
读完这份官方指南后，我对写 Prompt 的理解变得更简单了。
有效的 Prompt 通常不依赖复杂术语。它需要明确的结果、必要的上下文、可执行的边界，以及清楚的使用方式。第一版出现问题也很正常，只要根据输出继续提供具体反馈，就能逐步得到更合适的结果。
我现在判断一条 Prompt 是否清楚时，主要检查五件事：
要完成什么、依据什么、交付什么、不能做什么、最后检查什么。
能够回答这五个问题，大多数工作任务就已经拥有了一个好的开始。
