一個小 Change 合併前，團隊請 AI 幫忙產生變更摘要。

Diff 很短。

大概只有幾行：

- old routing condition
+ new routing condition
+ additional fallback branch

AI 很快整理成：

本次變更提升跨平台相容性，強化失敗時的可靠性，並統一新舊流程的 Routing 行為，以支援後續擴充。

看起來非常像一份專業 Change Summary。

甚至比工程師自己寫得完整。

Review 的人停了一下。

「跨平台相容性是從哪裡來的？」

沒有人知道。

Diff 沒寫。

Issue 裡也沒有這個 Claim。

再往下看：

「支援後續擴充」也沒有任何 Evidence。

真正能從 Diff 直接證明的只有：

Routing condition 改了，並增加一條 Fallback path。

AI 沒有描述錯程式碼。

它只是替一個很小的 Change 補出了一個完整的設計故事。

Evidence 不只決定答案對不對，也決定答案可以說多遠

大家談 AI Hallucination 時，很容易想到完全不存在的內容。

但工作文件裡更常見的是另一種狀況：

基礎事實是真的，往外多延伸了幾步。

例如 Diff 顯示：

routing rule changed

模型很自然會補：

為了提高 routing consistency。

又看到 Fallback：

為了提升 reliability。

這些 Motivation 可能很合理。

甚至真的可能是作者心裡的原因。

但如果 Source 沒有留下來，它們就不是這份 Change Evidence 可以支持的 Claim。

Package 的 Changelog Rule 因此限制得很清楚：

Change Summary 只能描述 Diff 支持的 routing / operational consequence；不得替 Diff 發明 motivation、compatibility claim 或 supported behavior。

一份漂亮的摘要，可能讓未驗證的推論變成正式紀錄

Change Summary 和一般聊天不一樣。

它常常會一路被帶進：

• Release Note
• Review Record
• 後續 Debug
• 交接文件

所以一旦寫成：

這次修改提升 Platform Compatibility。

下一位讀者通常不會重新翻 Diff 驗證這句話。

他會把它當成已經確認過的 Change Intent。

久了之後，文件甚至可能反過來成為後續 AI 的 Evidence。

一開始只是模型補的一句合理推論。

幾輪之後，看起來就像專案一直都知道的事。

這也是為什麼 Claim Boundary 很重要。

不是要求摘要只能機械式重述 Diff。

而是：

你可以整理 Evidence，但不能把 Claim 的範圍擴到 Evidence 之外。

他們沒有要求 AI 只列行號

最後團隊沒有把 Change Summary 改成：

Line 12 changed.
Line 18 added.

那樣雖然安全，卻失去摘要價值。

AI 仍然可以把 Diff 翻成工作語言。

例如：

- Routing condition now selects the new path under condition X.
- A fallback branch was added when the primary path is unavailable.

這兩句已經不是原始 Code。

但仍能被 Diff 直接支持。

如果真的需要說 Motivation，則必須再找 Issue、Design Note 或明確的 Change Request。

沒有，就不補。

下一次，摘要反而短了一半

又一個 Change 合併。

AI 產出的初稿只有三行。

工程師看完說：

「是不是太短？」

另一個人問：

「還有什麼是 Diff 真正能證明、但現在沒寫到的？」

大家看了一遍。

沒有。

所以三行就留下來了。

Release 時，那份 Change Summary 沒有「提升整體穩定性」、沒有「強化未來擴充性」，也沒有「改善跨平台體驗」。

它只是很精確地說明：這次到底改了什麼。

字比較少。

但每一句都有地方可以回去對。