AI code review 讓你抓到硬 bug

我把 AI code review 拆成一套能直接套用的流程，重點是抓 lint 看不到的深層 bug。

我用 AI code reviewer 一陣子了。表面上很勤快，看到 diff 會講兩句，語氣也很像懂很多；但我越用越火大，因為它常常只是在幫我把「看起來正常」這件事講得更順耳。那種感覺很像你請一個同事幫你 review，結果他只會說「這段很乾淨」「命名不錯」「看起來沒問題」，然後真正會炸的 state transition、錯誤處理、重試邏輯、邊界條件，全都滑過去。lint 也是差不多的德性，能抓格式、命名、簡單規則，但碰到行為層面的 bug，基本上就收工了。

我後來是被 Trevor Lekranec 這篇 Top AI Code Review Tools That Actually Catch Hard Bugs in 2026 拉回來的。作者是 Trevor Lekranec，文章放在 Medium。這篇的切法我很買單，因為它不是在講「AI review 有多潮」，而是在問更實際的事：哪些工具真的有機會抓到硬 bug。我沒有看到原文提供可驗證的觀看數、clap 數或 star 數，所以我不亂掰。

大多數 AI reviewer 還在用幼兒園等級看 diff

“Traditional linting and even most AI reviewers glance at a diff and call it done.”

翻譯一下就是：很多工具其實只是在掃變更，不是在理解行為。它們會讀 patch、比對幾行上下文、吐出幾個評論，然後就當自己完成任務。這對快篩有用，但對真正的 code review 來說遠遠不夠，因為 bug 常常不是出在那幾行字，而是出在 patch 改了流程、改了假設、改了副作用順序。

我之前碰過一個很典型的例子：一個看起來只是整理 validation 跟調整 API response 的改動，review 的時候大家都覺得「喔，這個 clean」。結果上線後才發現，它偷偷改了檢查順序，只有在某個欄位缺值、另一個欄位又格式不對時才會爆。這種 bug 你叫 lint 去看，它只會裝死；你叫只會看 diff 的 reviewer 去看，它也大概會裝死。

實操寫法很簡單：我現在不再問 AI「這段 code 有沒有問題」，我改問它「這段改動會在哪裡改變行為」。我要它回答幾個很煩的問題：

• 如果這段跑兩次，會不會重複寫入？
• 如果中途失敗，會不會留下半套狀態？
• 如果呼叫端送舊資料，流程會不會變形？
• 這次 patch 拿掉了哪些原本默默成立的假設？

如果工具只會總結 diff，我就知道它是來陪聊的，不是來 review 的。

只會稱讚的工具，基本上沒在幫忙

我最受不了的 AI review，就是那種永遠很客氣的。它看完 patch，說 code 很乾淨、結構不錯、也許可以再考慮 edge case，然後就沒了。聽起來很像有參與感，實際上什麼都沒擋下來。這種輸出最大的問題不是它不準，而是它太安全了，安全到根本不敢碰真正的風險。

Trevor 那篇文章我喜歡的一點，就是它把工具分成兩類：一類是只會產生評論，另一類是真的想抓 bug。我認為這個切法很對。因為 review 的價值不是「有沒有講話」，而是「有沒有講到我沒想到的事」。如果一個工具從來不敢說「這裡可能會壞」，那它頂多是在做摘要，不是在做審查。

實操上，我現在會直接看工具有沒有膽量指出具體風險。不是那種空話式的「注意 edge case」，而是能不能講清楚：哪個路徑會壞、壞了會怎樣、為什麼會壞。如果它能說出「這個 retry loop 可能在 timeout 發生後重複寫入」，那我才會覺得它真的有在看。

我自己會用這個小檢查表：

• 它有沒有說出失敗場景？
• 它有沒有講清楚後果，而不是只講 smell？
• 它提出的修法，有沒有對準真正的風險？

只會誇的 reviewer，不管是人還是 AI，我都當它是裝飾品。

好 reviewer 要會看跨檔案關係，不是只盯著 patch 內文

很多 hard bug 之所以漏掉，是因為 bug 本來就不住在單一檔案裡。你改了一個 helper，另一個模組還在用舊假設；你調了 schema，consumer 沒跟著改；你換了 cache key，失效邏輯卻還留在舊世界。只看 diff 的工具，通常看不到這些連動。

我比較信任的工具，行為比較像一個會追問「這個假設還活著嗎」的 senior engineer。它不會只盯著一行 code 說漂亮不漂亮，而是會往外追：這個 function 還被誰用？這個 error type 還有誰 catch？這個 contract 改了之後，誰會被打爆？這才像 review。不是在看字，是在看系統。

實操寫法是把 context 餵給它，不要只丟變更檔。至少把相關 tests、呼叫端、相依模組一起送進去。你如果只給它單一 file，它就只會在井底看天，然後很自信地告訴你天空很藍。那種自信我看太多了，沒什麼用。

我評估工具時會特別看這三件事：

• 它會不會提到 caller，而不是只看 callee。
• 它有沒有抓到 contract 變更。
• 它會不會問測試有沒有覆蓋到行為變化，而不是只數 branch。

真正有價值的是抓 bug 形狀，不是抓字面錯誤

大部分團隊其實早就不缺 style review 了。格式有 formatter，命名有 lint，縮排有 pre-commit，連一些基本一致性問題都可以自動化處理。AI code review 如果只是在那邊提醒我命名可以再好一點，那我真的不需要它。我要的是它幫我看那些會讓人半夜起床的問題。

我講的 bug 形狀，是這些東西：race condition、null handling 寫歪、cache 過期邏輯錯、retry 重複副作用、silent fallthrough、authorization 漏洞、測試看起來綠但 production 爆掉。這些才是 review 的主戰場。你如果只看語法和風格，那你其實是在做表面衛生，不是在擋事故。

Trevor 的切法剛好把這件事講明白：能抓 style 的工具，跟能抓行為風險的工具，不是同一個層級。我很同意。因為真正省時間的，不是少幾個 comment，而是少幾個上線後才發現的坑。

實操上，我會先定義團隊裡的「好 review」到底是什麼。對我來說不是「comment 越少越好」，而是「對行為風險的 comment 越準越好」。我寧可拿到兩條真的有料的警告，也不要二十條格式建議。工具如果不會幫我排序風險，那它就只是噪音機。

• 把 review 目標從 style 轉成 behavior。
• 把「有沒有 comment」改成「comment 有沒有打中風險」。
• 把「看起來不錯」改成「哪些地方最可能炸」。

AI review 最好當第二道，不要當最後一道

我不信任何 AI reviewer 可以直接當最終裁判。這不是我在唱衰，是因為我真的看過太多工具把「看起來合理」誤認成「真的安全」。模型會漏 context、會誤解 intent、會過度套用它看過的模式。你把它放在最後一關，然後期待它幫你守住所有細節，這種期待本身就不太合理。

比較好的 workflow 是把 AI review 放在 human review 前面，讓它先掃一輪，把明顯的風險、可疑的路徑、可能的 regression 先挑出來。人再接手做 architecture、產品意圖、domain trade-off 的判斷。這樣分工比較像樣：機器負責廣，人在最後做決定。

我之前看過很多團隊把 AI reviewer 當 approval gate，用法很偷懶。結果它漏掉一個 subtle regression，大家還很驚訝。其實不該驚訝。它不是 runtime simulator，也不是全知全能的 code oracle。它就是一個 reviewer assistant。你把它當裁判，最後出包只會更難看。

實操上我會這樣排：

• AI 先做 breadth scan。
• 人再做 judgment review。
• 最後的責任還是要落在會為 code 負責的人身上。

這樣分工之後，review 才不會變成大家一起演一齣「我們有看過了」的戲。

不要看 logo，去看它會問什麼問題

很多人挑工具很懶，首頁漂亮、demo 順、品牌感不錯，就覺得可以上。這招我也踩過，通常都會後悔。真正該看的不是包裝，而是工具會不會問出會把 bug 挖出來的問題。如果它只是在重述 diff，我基本上就不想再浪費時間。

這也是 Trevor 那篇文章對我的價值：它不是叫我迷信某個產品，而是把注意力拉回工具行為本身。它會不會理解 state？會不會看 tests？會不會知道 contract 或 security assumption 被改了？這些才是實戰問題。logo 再大，問不出這些也沒用。

實操寫法我建議很土，但很有效：拿你自己專案裡的五個真 bug、五個高風險 PR、五個幾乎沒事的變更，直接丟給工具跑。看它能不能抓到真問題、能不能少吠。這種測試比任何行銷頁都誠實。

我會用這個簡單標準：

• 它能不能用一句話說出 bug 是什麼。
• 它能不能講出 runtime 後果。
• 它能不能對安全變更保持克制，不亂嚇人。

可抄的模板

# AI code review prompt for catching hard bugs

你是 reviewer，不是 formatter。你要找的是會穿過 lint、測試表面綠燈、但仍然會在 production 出事的問題。

重點關注：
- state transition 錯誤
- error handling 漏洞
- race condition
- duplicated side effects
- schema / contract 變更
- authorization / security regression
- edge case 漏判
- test gap

審查規則：
1. 不要只看 diff，請連同相關 callers、callees、tests 一起看。
2. 只要提出風險，就要說清楚 failure mode。
3. 優先看 runtime behavior，不要把注意力浪費在 style、命名、格式。
4. 如果 patch 看起來安全，也要明講為什麼安全。
5. 如果資訊不足，直接說你還需要什麼 context。
6. 不要亂猜問題；只有在能從 code 推導時才提出。

輸出格式：
- Summary：一句話說明整體風險等級
- Findings：依嚴重度排序的具體問題
- 每個 finding 都要包含：
  - 會壞什麼
  - 為什麼會壞
  - 建議怎麼修
- Safe notes：哪些地方看起來正確，為什麼

最後自我檢查：
- 我有沒有看 callers / callees？
- 我有沒有檢查相關 tests？
- 我有沒有考慮 failure path 和 retries？
- 我有沒有找 state、timing、contract regression？
- 我有沒有避免 style-only comment？

如果 patch 大致安全，但有一個尖銳風險，請直接點出來。
如果 patch 很危險，也請直接講。

如果你的 codebase 有固定規則，補進去：
- idempotency 的定義
- retry policy
- auth boundary
- error classification
- logging / observability conventions

這段我會直接拿去改成團隊版。它的重點不是裝得很像 AI，而是逼 AI 去看行為、看風險、看上下文。你如果照這個格式跑，通常很快就能看出工具到底是在幫忙，還是在講廢話。

我自己的結論很簡單：AI code review 不是拿來取代人，而是拿來把人從低價值的雜訊裡救出來。它如果只會講漂亮話，那就別用了。它如果真的能幫你抓到那些 lint 看不到的硬 bug，才值得留在流程裡。

原始來源是 Trevor Lekranec 的 Medium 文章 Top AI Code Review Tools That Actually Catch Hard Bugs in 2026，作者頁面在 這裡。上面這篇是我把原文觀點拆成台灣開發者比較能直接拿去用的版本，模板與操作細節則是我自己的整理與改寫。