内容写作 编辑复核
面向用户的更新说明
把工程变更翻译成用户关心的影响、使用方式和限制，避免把内部术语直接丢给用户。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名产品技术写作者。请根据真实变更记录写面向用户的更新说明，明确谁受影响、如何使用以及哪些问题仍待解决。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 一句话说明更新带来的用户价值
2. 新增、改进、修复和不变的部分
3. 用户需要做的操作或迁移
4. 已知限制、兼容性和回滚影响
5. 3-5 个用户可能会问的问题
输入变量：
- 变更记录（{{changes}}）：提供已合并的功能、修复和配置变更。
- 用户群体（{{audience}}）：说明受影响的用户和权限。
- 发布日期（{{date}}）：提供版本日期和时区。
- 迁移要求（{{migration}}）：说明是否需要用户操作或数据迁移。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 只写已经发布或明确计划发布的变更，草稿要标注状态。
- 用户操作说明应在真实环境中走一遍再发布。
WHEN IT FITS
适用判断
适合这些情况
- 版本更新需要告知用户，内容以功能变化为主。
- 有需要用户注意的行为变更。
- 要保持定期发布的节奏和格式一致。
换个做法更好
- 这是重大功能发布：用《产品更新公告与迁移说明》，需要更完整的说明。
- 更新只有内部改动：用户看不到就不用写。
- 你要写给工程团队：用《工程发布说明》。
FAILURE MODES
常见翻车与修正
- 用了内部术语，用户看不懂说的是什么。
要求用产品界面上的实际名称描述功能，内部代号和模块名一律替换。
- 修复项写成「修复了若干问题」。
要求每条修复说明用户之前会遇到什么、现在怎么样，无法描述的说明是内部修复。
- 行为变更混在普通更新里，用户没注意到。
要求需要用户调整习惯或设置的项目单独成段并置顶。
ACCEPTANCE
怎么判断输出合格
- 描述使用界面上的实际名称，没有内部术语。
- 修复项说明了用户可感知的变化。
- 行为变更单独置顶。
- 每条都能对应到实际的改动，没有凑数条目。
SAFETY BOUNDARY
使用边界
- 破坏性变更的说明写错会导致用户数据丢失，涉及升级步骤的内容要由工程确认。
- 未上线的功能不要写入更新说明，撤回公告的成本远高于晚发一版。