发布说明生成与评审工作流

目标

把 git log 粘贴到发布页回答不了任何人的问题。发布说明的存在意义是告诉用户“对他们变了什么、必须做什么”。自动生成原始清单再按读者视角塑形，速度与清晰兼得；双人评审里，工程保证准确，客服保证可答——后者将亲手处理这份文字制造的工单。

步骤要点

1. 收集上个 tag 到候选 tag 之间全部合入 PR：标题、正文、关联 issue，包括漏打标签的也要完整在列。
2. 按受众影响分类：破坏性变更、需要操作、新特性、修复、仅内部，标签加人工过一遍。
3. 把每条从实现语言翻译成用户语言：他们观察到什么、得到什么、需要做什么。
4. 草稿送双人评审：一位实现变更的工程师加一位客服代表，后者重点确认“需要操作”一节毫无歧义。
5. 说明随 tag 与产物元数据一起发布，用户在下载旁边就能找到，两处文字完全一致。

排错提示

用户来信问已写在说明里的问题，说明该条埋得太深或写得含糊，把对应内容上移并改成祈使句；破坏性变更进了内部段说明分类靠标签太粗，人工过审必须看每个 PR 的实际影响面；说明与产物元数据不一致是发布页被单独手改过，改为以产物附带文档为唯一真源。

适用边界

自动生成只能到原始清单为止，语言塑形与影响判断仍需人工；内部段的取舍要有标准，全删会让排查者失去线索，全留会让用户淹没在噪音里。

代码示例

## 1.8.0 -- 2026-10-22

### Action required
- Config key `cache.ttl` is now seconds (was ms).
  Multiply existing values by 1000 before upgrading.

### Breaking
- Removed `/v1/legacy-search` (deprecated since 1.4).

### Added
- Coupon engine: percentage and fixed codes at checkout.

### Fixed
- Checkout rounding on 3-decimal currencies.

### Internal
- (18 PRs omitted from user notes)