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；三十秒能攔下的大部分事故，不需要你發明任何新的流程。