版本更新說明怎麼寫：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 條評論
還沒有評論，來搶沙發～