AI 改完程式碼，先一格一格讀 DIFF：30 秒的慢功夫，省下半天的救火時間

上次 AI 幫我清理一批排程腳本，它說「全部改好，邏輯等價」。我信了，讓它直接提交。當晚線上警報響起：三個腳本裡有兩條日誌被靜默吞掉了——它把帶 `-f` 的 stderr 重新導向順手「統一」掉了。復原、排查、修正，一共花掉四十分鐘。從那以後我固定一個習慣：**AI 改完程式碼，先一格一格讀 DIFF，再談下一步。**

什麼時候必須一格一格讀

四類場景，DIFF 越大越不能快讀——不是越大越要大意，而是越大越不能大意：

- 讓 AI 順手重構、清理「還沒用上的程式碼」。刪掉的行往往比新增的行危險，尤其是 `except: pass`、防禦性 `mkdir -p`、看著沒用其實是給下游相容留的變數。

- AI 替你做了一道「風格統一」。註解格式、日誌層級、環境變數前綴，這些「美學改動」最愛和真改動纏在一處，讓你第一眼看不出哪行動了腦子、哪行只是換了皮膚。

- 涉及權限、密碼路徑、shell 展開、併發鎖和跨檔案契約的改動。這類改動「看起來沒問題」的概率不是零，而是「填表時對不上再去翻帳單」級別的麻煩。

- 你要把改動交給別人 review，或者自己合併進共享倉庫。此時 DIFF 裡混合了 AI 的判斷和你的判斷，讀者分不出哪塊要重點看。

什麼時候不用這麼讀

- 只格式化：跑了 `prettier`、`black`，順序沒動，掃一眼確認沒多沒少就行。

- 只加一個測試檔案：不碰現有邏輯時，點幾下就能過。

- AI 只填模板：改的是檔名、大小寫、字串這類確定詞，肉眼十秒確認。

這些場景值得省時間，但省的方式不是「不讀」，而是「快速掃 + 行數對帳」。

30 秒慢功夫怎麼做

1. 先 `git status` 確認檔案清單和 AI 說改的一致。多出來的檔案比漏掉的檔案更可疑——檔案清單本身就是第一層 DIFF。

2. `git diff --stat` 掃總量。新增 5 行、改了 80 行這種「淨刪型」改動，重點看刪。

3. 一格一格讀，讀的順序按疑心排：權限與敏感欄位 > 控制流（if/else/迴圈）> 邊界（空輸入、空陣列、越界）> 字串與日誌 > 其餘上下文。

4. 讀完過一遍關切口：改動接上下游了嗎？呼叫方那行沒改，被改的函式簽名卻變了。**AI 最擅長的就是改對眼前那行，忘了前面一步。**

5. 本地跑一遍 CI 清單：lint → 測試 → 啟服務；頂不住可以只跑 `npm test`，但「編譯通過」和「本地綠燈」是兩回事。

6. 最後才是提交。commit message 裡寫清「做了什麼 + 為什麼」，AI 風格只寫「updated code」的那種，直接打回。

檢查清單（貼在終端機側邊欄）

- [ ] 改動檔案清單 = AI 宣稱清單，無多無漏

- [ ] 刪掉的每一行都解釋得清為什麼可以刪

- [ ] `except` / `||` / `??` 裡的默默兜底沒被「優化」掉

- [ ] 權限、路徑、環境變數沒被改名或改位置

- [ ] 中英混排、編碼沒動（別用 `BOM` 坑自己）

- [ ] 本地 lint + test 綠燈；CI 下來再過一遍

- [ ] commit message 寫明理由，不是 `update` / `fix bug` / `chore`

坑速記

| 坑 | 怎麼踩 | 怎麼避 |

|---|---|---|

| 「還得等我再裝個套件」 | 本地 `npm install` 沒跑，CI 綠了本地就掛 | 提交前 `npm ci && npm test`，別信編輯器小綠點 |

| 把 `useEffect` 依賴交給 AI | `eslint-disable` 加了三處，一年的隱性坑 | `eslint --fix` 能解的可自動解，不能解的人工過 |

| `git diff` 看一半就 push | 改到 workspace 命中 `.gitignore`，AI 悄悄挪了路徑 | 提交前 `git status` + `git diff --stat` 再看一次 |

| AI 替你把 if/else 合併稱優化 | 視覺行數少了，網路 ordering 變了，重試邏輯亂跳 | 看到「看起來更緊湊」就停一秒：真的等價嗎？ |

為什麼不把這套交給自動化

自動化防的是語法和類型，防不了語意。上面這些坑裡，只有 lint 能攔住一兩項，其餘都靠人讀。預算三十秒不貴——貴的是後面兩小時你一邊打補丁一邊罵它「誰讓你動它的」的連帶火光。

一句話

AI 改完程式碼，先一格一格讀 DIFF；三十秒能攔下的大部分事故，不需要你發明任何新的流程。