改動前後，手動核對一遍 DIFF：小改動的隱性成本

具體場景

你讓 AI 改了設定檔，或者手動動了一個 if 分支，點上「儲存」的那一刻，以下三件事發生了：

1. 那行確實按預期改了
2. 旁邊還有兩行你沒注意，原來格式有誤，現已悄然變化
3. 檔案末尾多了一個空行，下一次 diff 時會誤報新增

程式碼通過了，邏輯正確，但下次程式碼審查時別人問你「這個空行是什麼」，你答不上來。改動前後的 DIFF 核對，就是用來發現這種問題的。

什麼時候用它

• 改動很小（同一檔案或相鄰檔案，幾行到幾十行），但涉及共享資源
• 你不確定你的作業系統 / AI 工具會不會順手修改你沒有預期變更的行（格式整齊器、自動換行、BOM 處理）
• 程式碼即將提交，你想在他人審查之前自己先驗一遍
• 讓 AI 改完程式碼，你說你逐行審查了，但沒有用 diff 工具做過最終確認
• 檔案參與了多輪修改，你終於要合併，但你想確認歷史改動都還在

什麼時候可以略過

• 你很清楚你在改什麼，改動單點明確，不涉及共享狀態
• 自動化 CI 已有 diff 階段且其規則與你的預期完全一致
• 你只改了純文件 / 註解 / 空行，不影響邏輯
• 檔案的修復器 / 格式化器你全程手控，且 CI 沒有 diff 攔截

怎麼操作（3 步走）

步驟 1：改動前，留一份快照

在動手之前，用一條指令把當前檔案的狀態固定下來：

cp path/to/file.yaml /tmp/file-before.yaml

步驟 2：改動後，統一 DIFF

改動完成後，跑一次 diff，肉眼過一遍：

diff --unified=3 /tmp/file-before.yaml path/to/file.yaml

重點回答：

• 新增的行，是我預期要加的嗎？
• 刪除的行，是我預期要刪的嗎？
• 已變更的行，改動內容是否最小？
• 有沒有我完全沒有觸碰的行，卻出現了改動？（格式、空行、BOM）
• 檔案末尾是否正確結束？（無多餘空行 / 需要正確結尾）

步驟 3：按 DIFF 修復，再 DIFF 一次

發生意外改動之後，按預期行的內容修復，儲存後，再跑一次 diff。

這一次的目的是：確認你的最終改動與你的預期改動是一致的，不多不少。

檢查表（提交前過一遍）

• 我列出了這次改動預期觸及的每一行（或每一組行）
• 實際 diff 裡的每一行變化，都在我的預期列表裡
• 沒有我完全沒觸碰的行出現在 diff 裡
• 檔案末尾格式正確（無多餘空行，BOM 狀態與原檔案一致）
• 如果檔案有格式化器（或 lint 規則），我沒有在提交後被動地格式改變內容
• 如果這次改動涉及多個檔案，我對每個檔案都做過同樣的 3 步

常見陷阱

陷阱	表現	修復
空行誤刪	diff 顯示出幾行空白變化，你看不出為什麼	對齊改動前後快照，逐位元組核對
BOM 變化	某些編輯器 / CI 會添加 / 刪除 UTF-8 BOM，hex 才能看出差異	用 xxd path/file | head -1 對比改動前後的前 3 位元組
行尾符變化	LF / CRLF 差異，普通 diff 不會報錯	file path/file 檢查行結尾類型，確保與原檔案一致
格式化器被動觸發	儲存動作觸發了自動格式化，格式變化沒出現在你的預期裡	關閉編輯器自動格式化，或格式化之後再 diff 一次
AI 順手修改	AI 改完程式碼的同時，把註解 / 空行 / 程式碼順序也順了一下	明確要求 AI 只改指定行，然後 diff 核對

一個例子

# 改動前：/tmp/file-before.yaml
server:
  host: 127.0.0.1
  port: 8080
  # 快取設定
  cache_enabled: true

# 預期改動：只改 port 為 8081
# 改動後（AI 做的）：
server:
  host: 127.0.0.1
  port: 8081
  cache_enabled: true
deleted_key: something_unused

# diff 結果：
#   @@ -2,5 +2,5 @@
# -    port: 8080
# -    # 快取設定
# -    cache_enabled: true
# +    port: 8081
# +    cache_enabled: true
# +deleted_key: something_unused

預期改動只有 1 行（port 8080 → 8081），實際 diff 出了 3 處變化：刪了註解，加了 deleted_key。如果這個檔案進入 CI 的審查者手裡，你會被問「這行註解怎麼會沒的」。

手動核對一遍，5 分鐘修好，比事後在審查裡被問強很多。