AI 寫的 PR，先看邏輯是否重複、邊界是否漏、測試是否只演戲。
你昨天用 coding-AI 寫的東西，今天才發現結果不對
你才開心兩個月：功能真的變快了，工單(ticket)關得像切菜。結果某天打開程式碼庫，突然覺得它有點像租屋處的雜物間。能用，門也關得起來，但裡面塞滿命名怪怪的函式(function)、三份長得很像的邏輯、看起來有測試(test)，其實只測一切順利的劇本(happy path)。最煩的是 PR 很大，你不知道該從哪裡罵起。對啊，就是這裡開始長出技術債(tech debt)。
為什麼 AI 寫得快，債也長得快？
問題不是 AI 寫程式助手「不會寫程式碼」，而是它很擅長把眼前任務補完，卻不太會替你的程式碼庫(codebase)做長期收納。它看到一個需求，就近找一段相似邏輯，改一改、包一包、命名一下，交差。短期看起來很有效率，長期就像每次都多買一個收納盒，但沒人真的整理櫃子。
人類寫爛程式碼通常也會這樣，只是 AI 的速度更快，讓技術債(tech debt)累積週期被壓縮。以前三個 sprint 才聞到怪味，現在可能三天後就冒出「這個 helper 跟上週那個是不是同一件事」的既視感。
Simon Willison 提過一個很貼切的點：假套件這種凸槌(hallucination,AI 一本正經亂講)反而沒那麼可怕，因為跑起來很快會炸；比較麻煩的是「跑得起來但邏輯不對」。AI 寫出的廢碼(AI slop)最常躲在這裡：不是編譯錯，是設計慢慢歪掉。
它通常長成這 3 種樣子
第一種：同一件事被重寫三次。今天一個 `calculateUserScore`，明天一個 `getScoreForUser`，後天又多一個 `computeFinalScore`。每段都能跑，每段只差一點點，之後需求一改，你就要猜哪個才是正式版本。這不是小潔癖，這是未來 bug 的孵蛋器。
第二種：命名很順，但語意很空。像 `handleData`、`processResult`、`newUserInfo`、`finalList2`，讀起來沒有錯，真的要懂卻很累。AI 很會生出「看似很工程」的名字，但名字沒把商業規則說清楚，下一個人 review 時就只能靠通靈。
第三種：測試(test)像佈景，不像防線。測了有資料、有成功、有 200 回應(response)，然後就收工。可是真正會爆的常常是空資料、重複提交、權限不符、兩個請求同時打架(race condition)、失敗後一直自動重試(retry storm)、資料沒上鎖(缺 row lock)這種極端情境。Stack Overflow 工程部落格也提過，2025 年線上服務(production)出包(outage)變多，跟 AI 寫的程式碼高度相關；這類問題不少都不是語法錯，而是場景沒守住。
Review AI PR，先抓這 3 件事
第一件：抓「重複邏輯」。不要先糾結縮排或語氣，先問一句：這段功能在程式碼庫裡是不是已經有了？Review 時直接搜尋關鍵商業名詞、API 名稱、狀態 enum、計算公式。如果找到相似實作，要求 AI 改成共用 function、共用 service，或至少把差異寫清楚。AI 很會複製眼前這一小段解法，review 要替它拉回全局視角。
第二件：抓「邊界條件」。每看到一段新增流程，就問三個問題：空值怎麼辦？重複操作怎麼辦？失敗後重試怎麼辦？這三問很土，但很有效。尤其是付款、庫存、權限、排程、批次匯入這類功能，別只看一切順利的劇本(happy path)。CodeRabbit 2026 年研究提到，AI PR 比人類 PR 多 75% 邏輯錯誤，每 100 個 PR 多 194 個 bug；這些錯很容易藏在邊界裡。
第三件：抓「test 有沒有真的保護行為」。不是看到 `test` 檔就放行。你要看它測的是實作細節(implementation)，還是真的使用行為。好的 test 會說：「同一個 request 送兩次，不會建立兩筆訂單」；水 test 只會說：「function 回傳不是 null」。如果 PR 改了商業規則，至少要有一個失敗案例、一個邊界案例、一個主流程案例。
最後補一個小防呆：要求 AI 在 PR description 裡列出「重用哪些既有邏輯、刻意沒有處理哪些極端情境、測試覆蓋哪些情境」。這不是文件潔癖，是逼它把隱形假設攤在桌上。你 review 的時候也比較不會被 800 行程式碼差異淹沒，只能留言「看起來 OK」。
拿走的一句話
AI 做 PR review 不用每行都抓，先守住重複邏輯、極端情境、測試品質，技術債(tech debt)才不會跟交付速度一起飆。
