AI 寫了一半程式碼，怎麼審查？工程師 Code Review 檢查清單

AI 現在能寫出相當大一部分的程式碼，但這不代表工程師可以少做事——反而要多花時間審查和除錯。判斷該用什麼順序看、看哪些地方、什麼情況該直接退回重寫，是現在每個用 Cursor、Claude Code 或 Codex 的工程師都要練的技能。這篇把審查拆成三層，並給出實際可用的檢查清單。

AI 寫了一半程式碼，省下的時間去哪了？

根據 2026 年 9 月 BairesDev 對 705 名開發者的調查，回報「AI 寫了至少一半程式碼」的比例從一年前的 12% 增至 42%。開發者每週省下的寫程式時間也變多了，從約 7 小時增加到約 13 小時，幾乎是兩倍——但省下來的時間並沒有變成休息,而是轉移到別的地方：67% 的開發者說自己花更多時間在審查 AI 寫的程式碼，52% 花更多時間處理 AI 造成的錯誤，學習新工具的時間也從每週 4 小時增加到 9 小時。

也因此，只有 21% 的開發者現在每週有超過一半時間在從頭寫新程式——寫程式這件事本身正在從「打字」變成「審查、除錯、學新工具」。而程式上線的決定權仍牢牢留在人身上：只有 7% 的開發者說已經完全把上線決定交給 AI,78% 的技術長反而增加了審查、品質檢測與驗證的預算。這代表 AI 寫程式碼變快了,但「誰負責判斷這段程式碼能不能用」這個問題,並沒有因此消失,反而變得更重要。

像 ThePrimeagen 這類重度使用終端機 AI 代理（在命令列裡能讀專案檔案、執行指令、直接修改程式的工具，Claude Code 和 OpenAI Codex CLI 都屬於這類）的開發者，也公開說自己很大一部分工作已經變成「代理動手、我負責審查」，而不是自己逐行寫。

為什麼不能只看「能不能跑」就放行？

一個容易被忽略的事實是：AI 寫出來的程式碼語法正確率極高，但這跟安全或可靠完全是兩件事。2026 年的一份程式碼安全報告顯示，整體安全通過率是 56%，也就是約 44% 的 AI 生成程式碼帶有已知漏洞——這個比例跟去年系列報告開始時幾乎一樣，沒有明顯進步。語法正確率高達 99.9%，但安全通過率只有 56%，兩者完全脫鉤。

模型之間的差距在拉大：表現最好的 GPT-5.5 達到 68%，但超過一半的模型落在 50% 到 53% 之間。值得注意的是，「編碼專用模型」並不比通用模型更安全——編碼模型平均 51%，通用模型 52%，差距只有 1 個百分點；模型大小也沒有顯著影響，大型（超過 1000 億參數）、中型、小型模型的安全通過率都差不多，落在 51% 到 53% 之間。特定漏洞類型的表現更是兩極——SQL 注入和加密演算法相關的漏洞，AI 處理得不錯（分別達 83% 和 87%），但跨站腳本攻擊（XSS）只有 15%，日誌注入更低到 12%。

另一份針對 Claude Code、Codex、Gemini 三款終端機 AI 代理的實測更直接：各自建立一個應用，30 個 PR（Pull Request，提交給團隊審查的程式碼變更）裡有 26 個帶有漏洞，漏洞率高達 87%。而且問題不是隨機分散的，是六種結構性漏洞在三款代理身上重複出現：

• 存取控制失效：AI 優先考慮「功能能跑」，不會主動驗證是誰在發出請求
• 業務邏輯漏洞：AI 預設相信前端傳來的資料，不會主動假設「有人會作弊」，除非你明確提示才會加伺服器端驗證
• OAuth 實作省略 state 參數：三款代理都這樣做，會造成跨站請求偽造（CSRF）風險
• WebSocket 沒有認證：AI 把 WebSocket 當成獨立系統，忘記套用已經寫好的 REST API 認證邏輯
• Rate Limiting 寫了但沒掛上：三款代理都定義了限流的中間件，卻沒有真正掛到應用路由上
• JWT 密鑰硬編碼：為了讓程式能跑，AI 會加入像「secret」這種寫死在程式裡的備用密鑰

這些是「邏輯層級」的漏洞——連接缺失、流程被省略——傳統的 SAST（靜態應用程式安全測試）工具用的是 regex 模式比對，看不出這類問題，所以 ESLint security、npm audit、Bandit 這些常見掃描工具對 AI 寫的漏洞防護有限。這也是為什麼「程式能跑」不能當成審查通過的標準。

三層審查法：範圍、介面、測試

既然 AI 的 diff（改動內容）不能只看能不能跑，實際審查時可以分成三層，由粗到細：

第一層：改動範圍有沒有超出你交代的需求

AI 代理很容易把一個小修正自己擴大成整套重寫——你只是要修一個函式的邏輯，結果它順手改了命名、調整了檔案結構、甚至動到不相關的模組。第一層審查就是先看 diff 的範圍：這次改動動到幾個檔案？有沒有碰到你沒要求的地方？如果範圍明顯超出任務本身，不用細看內容，先打回去要求重新限定範圍，比逐行檢查一個過度膨脹的 PR 划算得多。

第二層：對外介面與資料流

這一層對應前面講的結構性漏洞，是審查裡最該花時間的部分。可以照這張清單逐項核對：

檢查項目	要確認什麼
WebSocket 認證	是否套用了跟 REST API 一致的認證邏輯，而不是獨立於驗證之外
Rate Limiting 掛載	中間件是否真的掛到路由上，不是寫了但沒接
JWT 密鑰來源	有沒有寫死的備用密鑰（如「secret」），密鑰是否來自環境變數或密鑰管理服務
破壞性端點授權	刪除、修改等端點是否驗證了請求者的權限，不是只看功能能不能跑
伺服器端資料驗證	是否只信任前端傳來的資料，沒有在後端再驗證一次
OAuth state 參數	OAuth 流程是否包含 state 參數，避免 CSRF 攻擊
每次合併前掃描	每個 PR 合併時是否都跑過安全掃描，不是只在專案初期做一次

這七項對台灣團隊來說是可以直接拿去用的清單，因為這些漏洞不是個別模型的毛病，而是三款主流終端機代理都重複出現的結構性問題——換模型不會自動解決這些問題，必須靠人工審查補上。

第三層：測試與錯誤處理是否真的跑過

AI 代理有時會生成測試檔案，但那不等於測試真的跑過、真的涵蓋到關鍵路徑。這一層要盯的是：單元測試有沒有實際執行並通過、原本的測試有沒有被悄悄刪除或跳過、錯誤處理的邏輯是否完整而不是用一個空的 catch 擋掉。GitHub 官方對 AI 生成程式碼的審查建議也提到，除了跑測試，還可以用 CodeQL、Dependabot 這類工具做自動檢查，搭配 GitHub 的程式碼品質檢測看可靠性與可維護性；更基本的人工審查則要留意可讀性、命名是否清晰，避免接受難以閱讀的程式碼。另外 AI 特有的錯誤模式也要留意：幻覺出來、根本不存在的 API、被忽視的技術限制、看似合理但邏輯其實不對的判斷。如果 AI 建議了新的套件或依賴，也要確認套件確實存在、有在維護，授權條款跟專案相容。

怎麼讓審查不要比自己寫還慢

審查成本高,很多時候不是因為 AI 寫得差,而是因為任務一開始就給得太大。幾個實際能降低負擔的做法：

把任務切小，一次只動一個關注點。 如果你要求 AI 同時「修 bug、順手重構、加新功能」，產生的 diff 會很難審查,因為你分不清哪些改動是必要的、哪些是順手做的。把每個任務限定在單一目的，diff 自然會小,審查起來也快。這跟處理大型專案時用程式碼索引縮小 AI 需要處理的 Context 是同一個邏輯——範圍越窄，AI 犯錯和你審查出錯的機率都會降低。

用 git diff 分段 review，而不是看整包改動。 把一個大改動拆成幾個邏輯清楚的 commit，一段一段看，比對著一大包變更慢慢找問題容易得多，也比較容易發現「這段改動跟任務無關」。

善用自動測試先過一輪。 在人工細看之前，先讓單元測試、CodeQL、Dependabot 這類工具跑過一輪，能先篩掉一部分明顯的問題，把人力留給邏輯層級的漏洞判斷——這些工具抓不到的部分，才是真正需要你花時間看的地方。

Composer Predictions 這類「建議下一句」功能，拿來整理下一步，而不是每則都照送。 Codex 的 Composer Predictions 會根據對話脈絡,建議你接下來可能要說的話，這個功能包含在 Pro 方案裡、不耗用額度，而且會參考你的說話方式給建議。但它終究只是建議，真正送出什麼仍是你決定。如果每一條建議都不經思考直接送出，等於把判斷權交給預測模型，審查負擔反而會變重；比較好的用法是用它快速整理出下一個小步驟該怎麼描述，確認方向對了再送。

團隊怎麼決定該放行還是打回去

在 GitHub 的 Pull Request 機制裡，任何有讀取權限的人都可以參與 review，這本身也有助於團隊知識共享——不是只有資深工程師能看。審查完之後的決定通常分三種：

• Comment：留下意見，但沒有明確表示核准或要求修改，適合還在討論階段
• Approve：表示可以合併，審查者認可這次改動
• Request changes：明確要求修正才能合併，適合發現第一層或第二層問題時使用

這個機制套用在 AI 生成的程式碼上特別有用，因為前面提過的結構性漏洞往往不是「寫錯」而是「省略」——AI 不會主動告訴你它漏了什麼，所以 Request changes 不該只留給明顯的 bug，範圍超出需求、資安清單沒過，都值得直接打回去，而不是帶著意見放行。

看得懂、敢否決 AI 程式碼，才是現在的核心能力

一項 Anthropic 的實驗提供了一個值得注意的對照：用 AI 協助完成任務後接受測驗的參與者，平均分數是 50 分；靠自己動手完成、沒有 AI 協助的參與者平均分數是 67 分，差距在除錯類題目上最明顯。但實驗也發現,會主動追問 AI「為什麼這樣寫」「這個邏輯的原理是什麼」的參與者,表現明顯比只接受答案的人好。

這跟審查 AI 程式碼的道理是一樣的——如果你只是看 diff 能不能跑就放行，長期下來你對系統的理解會越來越薄，遇到除錯這種需要深層理解的情況就會吃虧。反過來，如果你每次審查都強迫自己問「這段改動為什麼要這樣寫」「這個資料流有沒有漏驗證」,你不只是在抓漏洞,也是在維持自己對系統的理解深度。

現在能自己從頭寫程式碼的時間變少了（調查顯示只有 21% 的開發者每週有超過一半時間在寫全新程式），但能看懂 AI 的 diff、抓到邏輯層級漏洞、並敢在該打回去的時候打回去的工程師，價值比以前更高——因為這個判斷現在落在每一次 PR 上，而不是只在系統設計初期做一次。想練這個能力，最實際的方法就是照著前面的三層審查法,每次 review 都刻意走一遍，而不是憑感覺掃過去。熟悉 Codex、Cursor、Claude Code 這幾款工具 各自的 diff 呈現方式，也能讓分段審查更順手。