如何写出更好的 Prompt：初学者的检查与修订方法

假设你把会议记录交给 AI，只写了一句：

根据这些会议记录写一封跟进邮件。

AI 很快给出了一封措辞流畅的邮件：感谢所有参会者，列出三项决定，还为后续工作分配了负责人。问题是，记录里有两项内容只是讨论中的建议，其中一项工作也没有确定由谁负责。

这封邮件读起来很好，却不能直接发送。

很多初学者遇到这种情况，会认为自己需要更长的 Prompt、某个固定公式，或者“请扮演世界顶级沟通专家”之类听起来很厉害的角色设定。更有用的诊断其实很简单：AI 不知道怎样区分“语言流畅”和“结果可用”。

更好的 Prompt 像一份可以检查的任务说明。它交代 AI 要完成什么工作，提供完成工作所需的信息，标出不能越过的边界，并让人容易核对结果。不是每个请求都需要包含所有部分，第一条消息也不必一次写到完美。

什么才算“更好的 Prompt”？

处理日常任务时，可以用三个标准判断：

• 实用：结果能否支持你接下来的行动？
• 忠实：结果是否保留了材料中的重要事实、区别和不确定信息？
• 可检查：采用结果前，你是否知道应该拿什么进行核对？

“请写得专业一些”也许会改变语气，却不能回答这三个问题。“把已确认决定与待确认问题分开，不要虚构负责人”则可以。

下面会用一份虚构的会议记录，逐步组成完整 Prompt。会议、人物和项目都不是现实案例。

第一步：交给 AI 一项明确的工作

先说需要什么结果，不必从 AI 应该扮演什么角色开始。

模糊的要求：

帮我处理这些会议记录。

更清楚的要求：

根据下面的会议记录，为项目组起草一封会后跟进邮件。

第二条要求说明了动作、来源材料、最终产物和读者。你可以想象把这句话交给一位没有参加会议、但有能力完成工作的同事：对方知道应该交付什么吗？

继续补充 Prompt 前，还要先想清楚“完成”意味着什么。在这个例子里，邮件需要让项目组看出哪些事项已经决定、哪些工作已经有人认领、哪些问题仍然没有答案。如果把这些类别混在一起，即使文字写得再好，任务也没有完成。

Anthropic 的 Prompt 开发指南也把定义成功标准和检验方法放在优化措辞之前。普通聊天不需要专门建立一套评测系统，一份简短的心中清单就足够了。

第二步：补充真正会改变结果的上下文

只写“起草跟进邮件”，AI 不可能知道你没有提供的会议内容。你需要加入来源材料，以及会改变材料使用方式的背景。

这次练习需要的会议记录是：

会议记录

- 团队确认在 9 月 18 日试运行新的帮助页面。
- Mei 将在 9 月 8 日前准备第一版草稿。
- 团队讨论过增加视频，但没有作出决定。
- 需要有人确认字幕制作成本，尚未分配负责人或截止日期。
- 客户仍需确认其支持团队能否审核草稿。

读者和用途也会影响结果：这是一封内部跟进邮件，目的是让承诺和待确认事项清楚可见。此前每次项目会议的完整历史大概不会改变这封邮件。

Prompt 可以组合任务、必要材料、边界和期望结果；只保留真正会改变工作的部分。

“提供相关上下文”并不等于“提供尽可能多的上下文”。一项关于长上下文语言模型的研究发现，在其测试的检索和问答任务中，模型并不能同样可靠地使用输入中各个位置的信息。模型能力仍在变化，所以这不是适用于所有当前模型的固定限制，但它足以提醒我们：应当整理重要材料，而不是把关键要求埋在无关文字里。

可以逐条问自己：

如果删除这条信息，正确答案会不会改变？

如果会，它可能是必要上下文；如果不会，就可以考虑省略。发送前还要删除任务不需要的姓名、联系方式、账号信息、内部记录或其他敏感材料。涉及保密内容时，应另行查看当前工具的数据使用政策。

第三步：保护事实、约束和未知信息

上下文告诉 AI 可以参考什么，边界则告诉它哪些内容不能被悄悄改变。

会议记录中的三类信息并不相同：

• 事实是材料里已经明确的信息，例如 9 月 18 日的试运行日期；
• 约束是结果必须遵守的要求，例如不能改变已确认日期；
• 未知信息是 AI 不能自行填补的空缺，例如由谁确认字幕制作成本。

把这些区别写进请求：

请把已确认决定、已分配行动、讨论中的建议和待确认问题分开。
不要虚构负责人、截止日期、决定或客户回复。
材料里缺少的必要信息请标为“待确认”。

这比要求 AI “写得更权威”更有价值。语气再笃定，也不能把建议变成决定，更不能让缺失的负责人凭空出现。

比起连续列出很多“不要做什么”，说明结果应该怎样组织通常更容易执行。因此，我们先给出四个明确类别，再为会让邮件失真的情况保留必要的禁止边界。

第四步：要求一个便于使用和检查的输出

输出格式不是装饰。它应该让结果更容易继续使用，也更容易发现问题。

为邮件加入下面的要求：

请按以下结构撰写：

1. 不超过两句话的会议概述；
2. 已确认决定；
3. 已分配行动，只写记录中明确给出的负责人和日期；
4. 待确认问题和未分配行动；
5. 请收件人纠正不准确信息的结尾。

邮件不超过 250 字，使用直接、中性的语言。

这些小节会把遗漏暴露出来。单独列出“待确认问题”，可以避免未解决事项消失在一段听起来很顺畅的文字里。长度限制则防止邮件膨胀成一份会议实录。

当期望的格式、分类或语气很难描述时，一个简短示例也能帮助 AI 理解。OpenAI、Google 和 Anthropic 的官方文档都把示例视为引导输出的方法之一。不过，示例不是每条 Prompt 的必备字段。熟悉而明确的任务可能完全不需要它。

把各部分组合成完整 Prompt

现在，完整请求变成了：

请根据下面的会议记录，为项目组起草一封内部会后跟进邮件。
邮件需要让已确认决定、已分配行动和待解决问题清楚可见。

请把已确认决定、已分配行动、讨论中的建议和待确认问题分开。
不要虚构负责人、截止日期、决定或客户回复。
材料里缺少的必要信息请标为“待确认”。

请按以下结构撰写：
1. 不超过两句话的会议概述；
2. 已确认决定；
3. 已分配行动，只写记录中明确给出的负责人和日期；
4. 待确认问题和未分配行动；
5. 请收件人纠正不准确信息的结尾。

邮件不超过 250 字，使用直接、中性的语言。

会议记录
- 团队确认在 9 月 18 日试运行新的帮助页面。
- Mei 将在 9 月 8 日前准备第一版草稿。
- 团队讨论过增加视频，但没有作出决定。
- 需要有人确认字幕制作成本，尚未分配负责人或截止日期。
- 客户仍需确认其支持团队能否审核草稿。

它比最初的要求更长，是因为任务里有值得保留的区别。如果只是“为这个文件夹提供五个名称”，就不需要相同结构。Prompt 的长度应该由任务决定，不是衡量质量的分数。

第五步：对照来源检查回答

不要只判断邮件读起来是否自然。把它与会议记录以及最开始设定的完成标准逐项比较。

可以按下面的顺序检查：

1. 覆盖情况：重要决定、已分配行动和待确认问题是否都出现了？
2. 忠实程度：日期、负责人、承诺或确定程度是否被改变？
3. 无依据补充：回答是否加入了材料中没有的理由、人名、截止日期、事实或引用？
4. 实际用途：项目组是否可以直接根据这封邮件继续行动，而不必先重新整理它？

涉及价格、法规、日程、产品行为或技术兼容性等时效性事实时，需要核对的可能是当前官方页面，而不是粘贴到对话里的文字。打开对应来源进行检查。追问 AI“你确定吗？”不属于独立核实。

NIST 把生成式 AI 自信地给出错误内容视为已知风险，并建议检查生成结果中的来源和引用。这个问题之所以危险，正是因为不准确的回答仍然可能显得非常完整。

第六步：针对具体缺口进行修订

第一次回答出现问题时，通常不必丢掉整条 Prompt。指出错误，恢复正确边界，再让 AI 修订受影响的部分。

例如：

字幕成本确认工作没有负责人和截止日期。请把它移到“待确认问题和未分配行动”，删除你添加的人名，其余邮件保持不变。然后再次检查所有日期和负责人是否与会议记录一致。

这条追问有效，是因为它指出了可以观察的问题。“再试一次”没有给 AI 同样清楚的信息。

写 Prompt 是一个循环：对照任务检查结果，说明具体缺口，再修订失败的部分。

语气、长度、格式或证据出现问题时，也可以使用相同方式：

• “摘要面向专业人士。只改写开头，让不了解项目的读者也能读懂。”
• “比较时没有为两个选项使用相同标准。请按价格、访问条件和取消规则重新制作表格。”
• “其中两条说法没有来源。请删除它们，或者分别链接能够支持它们的当前一手来源。”

因此，高质量 Prompt 更像一个工作过程，而不是一句必须一次写对的完美句子。Google 把 Prompt 设计描述为需要迭代的过程；OpenAI 当前文档也建议在 Prompt 和模型变化时测试实际表现。对初学者来说，迭代可以很简单：检查一次回答，指出一个缺陷，再试一次修正后的要求。

一份可以按需删减的起步框架

当任务包含一定复杂性或风险时，可以从这份框架开始：

任务：
请根据【材料】完成【具体结果】，供【读者或使用场景】使用。

必要上下文：
【只加入会改变正确结果的信息。】

必须保留：
【事实、区别、要求或不可改变的边界。】

不要假设：
【需要保留为空白或标为待确认的未知信息。】

输出：
【让结果真正可用的小节、格式、长度或检查要求。】

与当前任务无关的字段可以直接删除。收到结果后，再问一次：它是否实用、忠实、可检查？ Prompt 帮你说明工作，人仍然负责核对来源、作出最终判断，并完成现实中的行动。

参考资料

• OpenAI：Prompt engineering：清晰指令、示例、相关上下文，以及在 Prompt 和模型变化时进行评测。
• Google AI for Developers：Prompt design strategies：明确指令、上下文、示例、输出格式和迭代方法。
• Anthropic：Prompt engineering overview：在优化 Prompt 前定义成功标准和检验方法。
• Anthropic：Prompting best practices：清晰度、上下文、示例和结构化 Prompt，也包含模型特定建议。
• NIST AI 600-1：生成式人工智能风险管理框架简介：错误生成、信息完整性、人工监督和数据隐私风险。
• Liu 等：《Lost in the Middle》，TACL 2024：对测试模型如何使用长上下文中不同位置信息的实证研究。
• Schulhoff 等：《The Prompt Report》：对 Prompt 技术的系统综述与分类。