别让 AI 只交一段正文：先给成稿定一份「输出协议」

输出协议解决什么问题

可直接复制的 Prompt

你是一名中文实用写作编辑。请按「输出协议」完成一项受控写作任务。

# 本次任务
- 用途：[产品通知 / FAQ / 会议纪要 / 邮件 / 产品更新摘要]
- 读者：[身份]
- 读者读完后要完成的动作或判断：[动作]
- 语气：[直接、克制、友好等具体要求]
- 成稿长度：[例如 300 字以内]

# 参考材料
以下材料是唯一事实来源。材料没有提供的日期、数字、对象、范围、原因、效果、入口和承诺，统一放入「待确认项」，不写成确定事实。

[粘贴原文、会议记录或已确认的事实材料]

# 输出协议
按下面的字段和顺序交付。每个字段只能承担表中写明的任务。

1. 一句话结论：用 1 句说明这次发生了什么，保留对象、状态和生效时间。
2. 正文：解释变化、影响和必要背景；只使用参考材料中的事实。
3. 读者动作：列出读者现在需要做的动作；材料没有要求时，明确写「材料未指定立即动作」。
4. 限制与例外：保留适用范围、豁免对象、截止时间、条件和已知例外。
5. 待确认项：列出材料缺失、互相冲突或尚未确定的信息。每项写明「缺什么」，不提出猜测。

# 工作方式
分两轮完成。

## 第一轮：填写协议，随后停止 {#第一轮填写协议随后停止}
只输出下面的表格，不写正文：

| 字段 | 本次要填的内容 | 必填状态 | 材料依据或缺口 |
| --- | --- | --- | --- |
| 一句话结论 |  | 必填 |  |
| 正文 |  | 必填 |  |
| 读者动作 |  | 必填 |  |
| 限制与例外 |  | 有则必填 |  |
| 待确认项 |  | 必填，可为空 |  |

填写规则：
- 「材料依据或缺口」必须指向参考材料中的句子，或明确写出材料缺失。
- 把材料里的要求、愿望、推测和计划，与已经发生或已经确认的事实分开。
- 发现日期、数字、对象、范围或动作互相冲突时，把冲突写入「待确认项」，保留两种说法及其材料位置。
- 发现必填字段缺少依据时，在表中保留该字段，并标出缺口。不要用常识补齐。
- 第一轮停止在表格末尾，等待我确认或修改协议。

## 第二轮：按确认后的协议成稿 {#第二轮按确认后的协议成稿}
只有在我确认第一轮表格后，才执行以下步骤：

1. 按确认后的字段和顺序输出。
2. 「一句话结论」只写一条结论；「正文」承担解释；「读者动作」只承担动作；「限制与例外」和「待确认项」分别承担边界与缺口。
3. 只把参考材料中有依据的内容写进「一句话结论」「正文」「读者动作」和「限制与例外」。
4. 「待确认项」里的信息保持为待确认状态，不得在其他字段中变成确定事实。
5. 保留日期、数字、对象、范围、状态和限制条件的原值。材料存在冲突时，按第一轮确认结果处理。
6. 目标长度是上限。交齐必需字段后停止，不用套话填满篇幅。

# 第二轮输出格式
## 一句话结论 {#一句话结论}

## 正文 {#正文}

## 读者动作 {#读者动作}

## 限制与例外 {#限制与例外}

## 待确认项 {#待确认项}

## 快速核对 {#快速核对}
- 五个字段是否按协议交齐：
- 每个事实是否能在材料中找到依据：
- 待确认项是否仍与正文分开：
- 是否出现协议之外的新字段或新承诺：
- 是否超过目标长度：

快速核对完成后停止，不追加额外建议。

用一则产品通知试运行

任务：写一则面向团队成员的产品通知，控制在 260 字以内。
读者读完后要知道：搜索功能改了什么，什么时候生效，自己是否需要调整用法。

材料：
团队知识库将在 6 月 18 日启用新版搜索排序。普通成员和管理员都会看到结果排序变化。现有文档、收藏和访问权限保持不变。新版会优先显示标题和正文同时命中的文档。关于是否增加筛选入口、是否开放排序反馈，目前还没有确定安排。

## 一句话结论 {#一句话结论-2}
6 月 18 日起，团队知识库启用新版搜索排序。

## 正文 {#正文-2}
新版会优先显示标题和正文同时命中的文档，普通成员和管理员都会看到排序变化。现有文档、收藏和访问权限保持不变。

## 读者动作 {#读者动作-2}
按原有方式搜索即可，材料未指定立即调整事项。

## 限制与例外 {#限制与例外-2}
本次变化影响搜索结果排序；现有文档、收藏和访问权限保持不变。

## 待确认项 {#待确认项-2}
是否增加筛选入口、是否开放排序反馈，以及相关时间安排，材料尚未确定。

## 快速核对 {#快速核对-2}
- 五个字段已按协议交齐。
- 生效时间、受影响对象和保留能力都能回到材料。
- 筛选入口和排序反馈仍在待确认项中。
- 成稿没有增加材料未提供的操作入口或效果承诺。
- 成稿没有超过 260 字。

这条方法为什么有效

适用场景与边界

• 产品通知： 结论、影响、读者动作和例外需要分开。
• FAQ： 问题、简短回答、适用条件和待补信息需要各有位置。
• 会议纪要： 决定、行动项、负责人、截止时间和未决事项需要分开记录。
• 邮件与产品更新摘要： 收件人先看结论，再判断是否需要行动。

1. 材料之间存在事实冲突。 先处理口径冲突，再确认输出协议；字段分开只能暴露冲突，不能替你决定哪种说法生效。
2. 任务从零开始写长文。 先列子问题或段落职责，再按输出协议收束交付物；五个固定字段承载不了完整研究过程。
3. 需要机器直接读取结果。 聊天里的 Markdown 只能帮助人检查。调用支持结构化输出的 API 时，再把字段写成 JSON Schema，并在应用侧验证必填字段、类型和额外字段。
4. 字段只是为了显得专业。 一句话结论、正文、动作、限制和待确认项之间没有实际区别时，合并字段，避免协议变成新的套话。

发布前 30 秒检查

1. 字段是否由读者的下一步决定，而不是由写作者的习惯决定。
2. 每个必填字段是否都有材料依据或明确缺口。
3. 待确认项是否留在单独位置，没有被正文写成确定事实。
4. 日期、数字、对象、范围和限制条件是否保持原值。
5. 成稿是否严格按协议顺序交付，是否多出协议没有承诺的内容。
6. 如果程序会读取结果，是否做了 Schema 和应用侧校验。