内容写作 编辑复核
产品更新公告与迁移说明
把一次版本更新写成用户能理解和执行的公告，说明影响、迁移、兼容性和回滚边界。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名产品发布编辑。请根据已确认的发布事实写公告，不要夸大收益；对破坏性变更给出清晰的迁移和回滚提示。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 用用户任务解释更新解决了什么问题
2. 列出新增、变更、移除和不受影响的行为
3. 提供时间线、迁移步骤、兼容性与支持入口
4. 写 5 个用户可能追问的问题和需要人工确认的事项
输入变量：
- 发布事实（{{release_facts}}）：提供版本、日期、变更和验证记录。
- 受影响用户（{{affected_users}}）：说明哪些用户或工作流会受到影响。
- 迁移方案（{{migration}}）：提供官方迁移步骤和截止时间。
- 支持入口（{{support}}）：说明文档、工单和回滚渠道。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 发布前让开发、客服和产品分别核对自己负责的事实。
- 公告发布后收集迁移失败和客服问题，按影响优先级更新 FAQ。
WHEN IT FITS
适用判断
适合这些情况
- 功能已经上线或确定上线时间，可以对外说了。
- 改动会影响现有用户的使用方式，需要说明迁移。
- 要同时覆盖公告、站内提示和邮件几个渠道。
换个做法更好
- 你要写的是常规的版本更新说明：用《面向用户的更新说明》。
- 功能还在灰度：公告发早了会引发找不到入口的困惑。
- 改动用户完全无感：不需要公告。
FAILURE MODES
常见翻车与修正
- 公告全篇讲功能有多强，没说用户要做什么。
要求把「你需要做什么」和「什么时候之前做完」放在最前面，功能介绍后置。
- 模型美化了破坏性变更，用「优化」掩盖了功能移除。
要求如实说明移除和限制，并给出替代方案；掩饰只会让用户在发现后更不满。
- 公告里承诺了产品还没做的能力。
要求所有描述限定在已上线的范围，计划中的功能明确标注为「计划中，时间待定」。
ACCEPTANCE
怎么判断输出合格
- 用户需要采取的行动和截止时间放在最前面。
- 破坏性变更如实说明，并给了替代方案。
- 描述限定在已上线范围，没有未兑现的承诺。
- 各渠道的版本长度和重点都做了调整。
SAFETY BOUNDARY
使用边界
- 公告里的时间点、版本号和迁移步骤要和实际发版计划完全一致，写错会直接造成用户操作失误。
- 未发布的功能细节和内部代号在对外稿件里要删掉，发布前需要产品和法务确认。