北京
有這么一排提交記錄你是不是很眼熟：v2.4.0下面跟著“fix stuff”“wip”“處理了PR意見”“合并main到feature/checkout”“更新依賴”“最終修復（這次真的）”。這哪里是更新日志，分明是把git日志拽過來，在頂上硬貼了個版本號。關于這件事，維護“Keep a Changelog”規范的那群人有一句我無法超越的忠告：“別讓你的朋友把git日志倒進更新日志里。”
有趣的是時間線——那句話出自2014年。把原始提交歷史變成人愿意讀的東西，這個問題被提出來、被寫下來、被爭論了超過十年。所以新出現的不是問題本身，而是我們終于有了一件工具（一個大語言模型），它能閱讀一大堆提交記錄，然后自己寫出像樣的敘述。同時它也是這十年間第一件能理直氣壯把你從未做過的改動寫進發布說明里的工具。該怎么看待AI在這里的作用呢？它既讓寫更新日志變得真正省力，又會用一種聽起來完全合理的方式對你的用戶撒謊。
先想清楚你要自動化的是什么。一份更新日志不是數據庫導出，而是一份經過策劃的、按時間排列的、每個版本中值得注意的變更列表。“策劃”“值得注意”，以及那個隱性的“為誰而寫”，這幾個詞才是真正的重點。Keep a Changelog提供的過濾標準尖銳到足以止息大部分爭論：如果某項改動對于使用你軟件的人是不可見的，那它就不該出現在更新日志里。比如修復了一個用戶確實暴露其中的CVE漏洞的依賴升級——寫進去；一個給打包體積減了4KB卻不帶來任何可感知變化的依賴升級——拿掉。至于內部重構、持續集成腳本調整、你和自己的代碼檢查工具搏斗的十七條提交記錄——這些工作都很重要，但沒有一條屬于更新日志的材料。
格式本身被刻意設計得平淡無奇，這反而是一個特性。所有變更被歸入六個類別：新增、變更、棄用、移除、修復、安全。最新版本放在最上面，日期統一用ISO 8601格式（比如2026-06-14，因為地球上其他所有日期寫法都搞不清哪個數字是月份），頂部還有一個“未發布”區塊，用來堆積尚未發版的改動。另外有一條被多數人跳過的、真正扎實的規則：一份只提及部分改動的更新日志，可能比完全沒有更新日志更危險，因為用戶一旦開始把它當做唯一可信任的變更來源，隨后就會被你漏記的不兼容改動狠狠教訓。請記住這一點。“只提及部分改動”——這正是大語言模型最擅長制造的失敗模式。
在AI介入之前，業界的確定性方案是把提交信息結構化，讓一段純腳本就能完成分組。這就是“約定式提交”的思路：在提交標題上套一層極小的語法，比如“feat(checkout):添加Apple Pay作為支付選項”“fix(auth):拒絕已過期的刷新令牌而非直接報500錯”“feat(api)!: 移除……”這樣腳本就能按照類型和作用域自動歸類。這條路要求開發團隊高度自律，但從原理上可以保證最終產出的變更列表絕不憑空捏造。
而現在有了大語言模型，它可以把你一大段凌亂的提交歷史吃進去，直接吐出看起來很通順的更新條目。它能省下的人工時間真實存在，但問題在于，它可能會在不知不覺中“補寫”出一項從沒發生過的功能優化，或者把一個內部試運行的半成品說成已發布的新特性，而且措辭聽起來既自信又專業。當一個AI代理從頭至尾幫你“策劃”一份更新日志時，這種合理的謊言就是你必須直面的風險。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
