结构化 Prompt：把任务说明完整
为什么要使用结构？
写邮件、填表和做交接时，我们经常使用固定格式。它不能保证内容一定正确，但可以减少遗漏。
Prompt 也是如此。当任务变复杂以后，目标、输入、限制和输出要求混在一个长段落里，模型和人都更难发现冲突。结构的价值是把这些部分分开，让编写、检查和修改更容易。
结构化 Prompt 不是一套适用于所有模型的标准语法，也不是越长越好。简单任务可以只写一两句话；只有与任务有关的部分才需要保留。
一套实用的结构
1. 目标（Goal）
说明最终要完成什么，以及结果将用于哪里。
根据客户反馈生成一封可直接发送的回复邮件，帮助客服确认问题并说明下一步。2. 上下文（Context）
提供完成任务所需的背景，例如读者、业务规则、时间范围和术语含义。不要加入与任务无关的个人信息。
读者是已经提交售后申请的客户。公司会在收到完整照片后一个工作日内审核。3. 输入（Input）
清楚标记需要模型处理的材料。输入较长时，可以使用 Markdown 标题、代码块或成对标签划定边界。
4. 约束（Constraints）
说明不能做什么、信息不足时如何处理，以及必须遵守的边界。
- 不要承诺具体赔付结果；
- 不要推测客户没有提供的信息；
- 缺少必要信息时，明确列出需要客户补充的内容。5. 输出（Output）
定义语言、格式、字段或篇幅。严格机器处理的输出还需要程序校验，不能只依赖文字要求。
使用中文，输出主题和正文。正文不超过三个短段落。6. 示例（Examples，可选）
当风格、分类边界或输出格式很难只用文字描述时，给出一两个高质量示例。示例本身必须正确，否则模型可能复制其中的错误。
7. 验收标准（Success Criteria）
说明怎样判断结果完成。它让人和模型都更容易在交付前检查。
- 回复必须复述客户遇到的问题；
- 必须列出当前缺少的材料；
- 不得出现原始反馈中没有的订单、金额或时间。角色设定是可选项
“你是一位客服主管”有时可以帮助模型理解语气和任务背景，但它不会屏蔽模型的其他知识，也不会让模型自动获得真实的专业资格。
相比堆叠“资深、顶级、世界一流”等身份，更重要的是直接提供适用规则、输入材料和验收标准。
如果角色对结果没有帮助，可以不写。
完整示例
# Goal
根据客户反馈，生成一封可直接发送的售后回复邮件。
# Context
客户已经创建售后申请。收到商品破损照片后，客服会在一个工作日内审核，但审核结果尚未确定。
# Input
<feedback>
包裹今天送到，外箱破了，里面的杯子也裂了。我已经在订单里申请换货，但还没有上传照片。
</feedback>
# Constraints
- 只使用输入和上下文中已经提供的事实；
- 不要承诺一定换货或赔付；
- 不要虚构订单号、金额和审核时间；
- 使用尊重、清晰的语气。
# Output
使用中文输出：
1. 邮件主题；
2. 邮件正文，最多三个短段落。
# Success Criteria
- 确认商品与外箱破损；
- 提醒客户补充破损照片；
- 说明收到完整材料后的审核时限；
- 不包含输入中没有的事实。这个结构的重点不在英文标题。你完全可以使用“目标、背景、输入、限制、输出、验收标准”。标题只是帮助我们检查信息是否完整。
常见问题
Prompt 是否越详细越好？
不是。无关信息会增加成本，也可能造成干扰。删除重复内容，保留做出正确判断所需的信息。
是否必须同时写所有部分？
不是。翻译一句话可能只需要目标、输入和输出语言；涉及真实业务的任务，通常还需要约束和验收标准。
模型生成的 Prompt 可以直接使用吗？
不建议直接使用。模型可以帮助补全模板，但你仍需检查业务规则、隐私、冲突要求和验收标准，并在真实样本上测试。
本章检查清单
- 目标是否具体；
- 输入边界是否清楚；
- 是否提供了完成任务必需的背景；
- 是否说明信息不足时不能猜测；
- 输出格式是否便于使用；
- 是否有可以客观检查的验收标准；
- 是否删除了无关信息和互相冲突的要求。
结构帮助我们减少遗漏，但不能替代事实核验、程序校验和人工判断。下一章会继续讨论需要机器处理时，怎样要求模型输出 JSON。
