AI 產碼的品質把關，答案一直在 git diff 裡

AI 產碼的速度不是問題，問題是你多快能判斷產出的品質。git diff 是 Human-in-the-Loop 最低成本的實踐。

高見龍在 Threads 上分享了一個做法：在 commit 前跑 /simplify，再用 git diff 審查 AI 改了什麼。看起來只是日常操作，但這裡面藏著一個更根本的判斷。

AI 產碼的速度已經不是問題。問題是：你多快能判斷產出的品質？

AI 產碼的品質現實

2024 年 GitClear 分析了超過 1.53 億行程式碼變更，報告指出 AI 輔助編碼導致「搬移碼」和「複製貼上碼」大幅增加，程式碼的 churn rate（寫完不久就被改寫的比例）在 2024 年翻了一倍。這不是在說 AI 寫的程式爛——而是說未經審查的 AI 產碼，品質波動比人類大很多。

SoftwareSeni 統整多份研究也得出相似結論：AI 產碼常引入隱性的重複和微妙錯誤，而且這些錯誤往往不是語法問題，而是邏輯層面的——比如多餘的條件判斷、未處理的邊界情況、不一致的命名慣例。這類問題不看 diff 根本抓不到。

diff 審查本身就是學習

我自己的習慣是 git add 之後，先用 diff 看一遍 AI 的改動。不是因為不信任——而是因為 diff 會逼你理解每一行變化的意圖。

你會看到 AI 怎麼簡化你的邏輯、它選擇什麼寫法、在哪裡犯了你不會犯的錯。舉個實際例子：我曾經讓 Claude 重構一段 Python 的錯誤處理，它把三層巢狀 try-except 壓成一個 context manager，但漏掉了一個 retry 的邏輯。這種錯誤你讀產出程式碼不容易看到，但在 diff 裡面一眼就發現——因為你看得到那段 retry 邏輯被刪掉了。

Donald Knuth 說過："We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." 套用在 AI 產碼的語境，我覺得可以這樣說：我們應該花 97% 的時間在理解 AI 的改動，而不是急著 commit。

安全面向不是可選項

NSF 的研究報告直接點出：AI 產碼容易帶入缺少驗證的 API 呼叫、硬編碼的密碼、以及未經過 sanitization 的使用者輸入。Stanford 大學 2023 年的一份研究更發現，使用 AI 輔助的開發者寫出的程式碼在安全性上顯著低於不使用 AI 的對照組——而且更令人擔憂的是，這些開發者反而更有信心自己的程式碼是安全的。

diff 是 Human-in-the-Loop 最低成本的實踐。你不需要跑完整的 code review 流程，肉眼掃一遍 diff 就能擋掉大部分明顯問題。當 diff 裡出現不熟悉的 library 或奇怪的參數，先跑測試或查文件，確定沒問題才 push。