版本更新说明怎么写：Changelog / Release Notes 生成提示词（commit 列表 → 用户看得懂的更新日志）
发版时要写更新日志，但手里只有一堆 commit 记录或合并请求标题时用：让 AI 筛掉内部改动、合并同类项，按「新增 / 改进 / 修复 / 破坏性变更」分类，同时输出给开发者看的 CHANGELOG 和给普通用户看的更新说明两个版本。
通用大模型 对话模型通用
请根据下面的提交记录，整理本次版本的更新说明。 - 产品名与版本号：[如 v2.4.0] - 上一个版本号：[如 v2.3.2] - 发布日期：[日期] - 读者：[开发者/普通用户/两者都要] - 提交记录或合并请求标题列表（可以直接粘贴 git log 输出）： [粘贴提交记录] - 需要特别强调的内容：[如重点新功能、需要用户操作的升级步骤] 处理规则： 1. 去掉对用户没有影响的条目：代码格式调整、测试、CI 配置、依赖小版本升级、内部重构、合并提交。去掉了哪些，在最后单独列一个简短清单，方便我确认没有误删。 2. 把描述同一件事的多个提交合并成一条。 3. 分类： - 破坏性变更（放在最前面，并写明用户需要做什么来升级）； - 新增； - 改进； - 修复； - 安全（如有）。 4. 每一条从用户角度描述「现在能做什么 / 解决了什么问题」，而不是复述代码改动。例如把「fix: handle null in parseDate」写成「修复了日期为空时导入失败的问题」。 5. 有对应的问题编号或合并请求编号的，保留在条目末尾。 6. 拿不准是否影响用户、或者看不懂提交信息含义的条目，标「待确认」，不要猜测。 输出： - 开发者版：Markdown 格式，遵循 Keep a Changelog 的分类习惯，可以直接加到 CHANGELOG.md 顶部； - 用户版（如果需要）：不超过 8 条，用口语化的短句，适合放在 App 更新说明或公告里； - 被过滤掉的提交清单。
高亮处换成你自己的内容：[如 v2.4.0]、[如 v2.3.2]、[日期]、[开发者/普通用户/两者都要]、[粘贴提交记录]、[如重点新功能、需要用户操作的升级步骤]
ChatGPT Plus 充值
已被复制 0 次
使用说明
怎么填变量：[粘贴提交记录] 可以用 git log v2.3.2..HEAD --oneline --no-merges 导出，合并请求的标题通常比单个提交信息更适合做更新说明。[读者] 决定措辞：开发者关心接口和配置变化，普通用户只关心「多了什么、哪里变好了」。
常见坑：
- 提交信息写得太随意（「fix bug」「update」），AI 无法判断改了什么，会被标为待确认。这时候需要补充上下文，或者干脆去看对应的代码改动。
- 破坏性变更埋在一堆修复里，用户升级后才发现配置项改名了。模板要求它放在最前面并写清迁移步骤。
- 用户版写成开发者术语（「重构了缓存层」），普通用户看不懂也不关心。
追问技巧：追问「把用户版改写成一条 100 字以内的公告」，或「根据这些变更判断版本号应该升主版本、次版本还是修订号（语义化版本规则）」。
示例输出
示例，仅供参考（开发者版节选）
markdown
## [2.4.0] - 2026-10-07
### 破坏性变更
- 配置项 `upload.maxSize` 改为 `upload.maxSizeMb`，单位由字节改为 MB。升级前请修改配置文件，旧配置项将被忽略。(#512)
### 新增
- 订单列表支持按支付方式筛选。(#498)
### 修复
- 修复了日期为空时 Excel 导入失败的问题。(#507)用户版：订单列表可以按支付方式筛选了；修复了部分表格导入失败的问题。
已过滤：chore: bump eslint、test: add cases for parser、ci: cache node_modules
同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～