CHANGELOG 靠自动化，Release Notes 靠人工：聊聊我们团队在发版文档上的落地取舍

大家发版的时候，CHANGELOG 和 Release Notes 是怎么做权衡的？

聊聊我带团队踩过的坑：以前推 Conventional Commits，配合工具自动抓 Git log 吐 CHANGELOG，工程上看流程闭环极爽，CI 一跑全自动。结果发版邮件一抄送，业务方和运营直接找过来：“这里面写的 feat(auth): refactor token refresh logic 到底对用户有什么影响？我们到底要不要通知客户？”

后来我们把这事拆成了两层，算是个权衡：

1. 面向研发与 QA：继续纯自动化。规范卡死 Commit Message，自动生成 CHANGELOG，用来对账、定位 Bug、回溯代码改动。
2. 面向业务、运营和客户：必须人工提炼 Release Notes。重点从“改了哪行代码”转变为“解决了什么业务问题/带来了什么新体验”。

但现实很骨感：只要加了“人工”两个字，就涉及排期成本和流程卡点。 如果让 PM 写，PM 往往看不全技术改动；让研发写，研发觉得发个版还要憋作文。

我们现在的折中方案是在 GitHub PR 模板里加了一栏必填的「一句话业务影响说明」，发版那天负责发版的同学花 10 分钟拼一下，尽量不拖发布节奏。

想问问大家，你们团队这两块是怎么切分的？人工提炼的成本摊给了谁（PM、Tech Lead 还是各模块研发）？有没有更轻量、不卡排期的落地解法？