PR Code Review 助手

🍽 這道菜在做什麼

寫程式的人都懂那種疲勞：一個 Pull Request 動輒上百行 diff，逐行看下來眼睛都花了，注意力到後面早就渙散，真正危險的那一行 null 沒判斷、那個沒關的資源、那段會被注入的查詢，反而最容易在這時候被滑過去。更現實的是，很多小團隊根本沒有專職 reviewer，PR 不是沒人看，就是隊友匆匆掃過按了 approve，bug 就這樣一路滑進正式環境。

這道配方要解決的，就是「Code Review 又累又容易漏」這件事。你把 PR 的 git diff 或變更後的完整檔案貼給 AI，附上語言與框架，它會以資深工程師的角度，把審查意見依嚴重度分成紅黃綠三級：🔴 必須修正的 bug、安全漏洞、資料外洩、競態條件；🟡 建議改善的可讀性、命名、重複邏輯、邊界情況；🟢 加分的測試、效能、最佳實務。每一項都會指出行數、說明原因、附上修正範例程式碼，最後用一句話告訴你這個 PR 能不能合併。

最需要這道菜的有幾種人。獨立開發者或小團隊工程師，身邊沒有人能幫忙 review，這道配方等於替你補上一位隨時在線的審查夥伴。Tech Lead 或資深工程師，每天要看大量 PR，可以先讓 AI 跑一遍把明顯問題挑出來，自己再聚焦在商業邏輯與架構這些真正需要人腦判斷的地方，效率立刻翻倍。正在學習的新手，則能透過 AI 的審查意見，知道自己的程式碼哪裡寫得不夠好、業界慣例是什麼，等於邊寫邊有人帶。一次原本要花二三十分鐘逐行細看的 review，前置篩查幾分鐘就跑完，省下的注意力可以留給更關鍵的判斷。

為什麼這樣設計

這道配方之所以好用，關鍵在於它把「審查」這件模糊的事，變成一套有層次、可執行的結構。

第一個關鍵是角色設定為「嚴謹但建設性的資深工程師」。這六個字很有分量：「嚴謹」確保它不會放水、會認真挑問題；「建設性」則避免它變成只會嫌東嫌西的酸民，而是每個問題都附上怎麼改。少了這個定位，AI 很容易要嘛太客氣只說好話、要嘛挑一堆無關痛癢的格式問題，兩種都沒用。

第二個關鍵是紅黃綠三級分類。Code Review 最怕的不是沒意見，而是意見一大串卻分不出輕重，結果重要的跟雞毛蒜皮的混在一起，reviewer 反而抓不到重點。把問題按「必須修正 / 建議改善 / 加分項目」分級，等於幫你排好優先順序：紅燈是會出事的、非改不可，黃燈是改了更好、可斟酌，綠燈是錦上添花。你可以先處理紅燈再說，時間不夠時黃綠燈下次再顧，決策一目了然。

第三個關鍵是每一項都要「指出行數 → 說明原因 → 給修正範例」。這三件事缺一不可。只指出問題不說原因，你不知道嚴不嚴重；說了原因不給範例，你還要自己想怎麼修。三者齊備，審查意見才從「批評」變成「可以直接動手」的修改清單。最後那句「能不能合併」的總結，則替你做了一個明確的 go / no-go 收尾，不用自己在一堆意見裡判斷整體該不該放行。

怎麼用

第一步，產生你要審查的內容。最常見的是在終端機跑 git diff（看未提交的變更）或 git diff main...your-branch（看整個分支相對主線的變更），把輸出複製起來。如果 diff 不好讀，也可以直接貼變更後的完整檔案。

第二步，打開 AI 對話工具（Claude、ChatGPT、Gemini 皆可），把上方提示詞整段貼進去，在「程式語言／框架」欄填上實際用的技術（例如 TypeScript + React、Python + Django），這會影響 AI 抓問題的角度——不同語言的常見地雷不一樣。接著把剛剛複製的 diff 或程式碼貼到「變更內容」區塊。

第三步，按 Enter。AI 會回給你紅黃綠三級的審查意見，每項都有行數、原因和修正範例，最後附上能否合併的結論。你先把紅燈逐一處理掉，黃燈視情況採納，改完之後建議把新版程式碼再貼回去讓它複查一次，確認問題真的解掉、而且沒因為修改又引入新問題。這個流程對應 frontmatter 的「貼變更 → 看分級意見 → 套修正範例」三步。

調整技巧

審查的深淺和方向，都可以用講的調整。覺得它意見太發散，可以說「這次只看紅燈，黃綠燈先別提」，聚焦在會出事的部分；想要更嚴格，就說「用最挑剔的標準，把所有潛在邊界情況都列出來」。

兩個變體很實用。處理登入、金流、權限這類敏感功能時，用「安全專審版」請它只聚焦 OWASP Top 10、SQL 注入、XSS、權限繞過這些安全問題，火力集中。帶新人或自己學習時，用「新人教學版」請它把每個意見解釋得更詳細，連「為什麼這樣寫會有競態條件」都講清楚，等於一邊 review 一邊上課。如果 diff 很長，也可以分段貼，請它一段一段審，避免內容太多它顧此失彼。

注意事項

最關鍵的一條：AI 的審查不能取代人工 review。AI 擅長抓出語法層級、邊界情況、常見安全模式這類「規則性」問題，但它看不懂你的商業邏輯對不對、這個架構決策符不符合團隊長期規劃、這段程式碼是不是其實不該存在。這些需要理解上下文與意圖的判斷，仍然要由你和團隊來做。把 AI 當成「第一道篩網」，幫你濾掉低階問題，而不是「最終裁判」。

其次，AI 給的修正範例不要盲目照貼。它有時會「自信地寫錯」，給出看起來合理但實際上跑不過、或改了之後行為跟原意不符的程式碼。每一段修正都要自己看懂、確認邏輯正確、最好跑過測試再合併。涉及金流、個資、權限的變更尤其要人工把關到底——AI 漏看一個權限檢查可能就是一次資料外洩。另外，貼程式碼前請留意是否含有密鑰、密碼、客戶資料等敏感內容，公司有規範的話要遵守，別把不該外流的東西貼到對話工具裡。審查結果務必複查，AI 是助手，不是負責人。

台灣情境案例

台北一個四人的接案開發團隊，接了一個電商網站的案子，但團隊裡只有一位資深工程師，平常忙到沒空仔細 review 另外三人的 PR，常常是快速掃過就 approve。有次一個結帳功能的 PR 合進去後，正式環境出包——某個優惠券邏輯在數量為零時會算出負數金額，等於用戶可以「買越多越便宜到倒貼」，幸好上線當天就被發現，沒釀成損失，但大家嚇出一身冷汗。

事後他們導入這道配方當作合併前的固定關卡：每個 PR 在請人 review 之前，作者要先自己跑一次 AI 審查，把 diff 貼上、附上「TypeScript + Next.js」，紅燈問題自己先解掉。導入後第一週，AI 就在另一支 PR 裡抓到一個「並發下單時庫存沒鎖、可能超賣」的競態條件——這正是當初那種人眼最容易滑過去的問題。

那位資深工程師說，最大的改變不是 AI 多厲害，而是團隊的 review 文化變了：因為 AI 已經把低階問題濾掉，他終於能把心力放在真正重要的架構與商業邏輯上，review 品質反而比以前更高。

延伸用法

Code Review 是開發流程的中段，它前後都能跟其他工具串起來。改完程式碼準備提交時，接上Git Commit 訊息產生器把這次變更寫成符合規範的提交訊息，審查與提交一氣呵成。萬一審查或測試時冒出看不懂的錯誤，再用錯誤訊息解碼器逆推根因，整條「寫程式 → 審查 → 提交 → 除錯」的鏈路就串起來了。

想找更多工程師專用的效率配方，可以逛食譜總覽；如果你想把「自動 AI 審查 → 人工複審 → 合併」變成團隊的固定流程，工作流專區有可參考的範本。需要快速生出 PR 描述、release notes 或測試案例時，產生器也能省下不少時間。把 AI 審查當成團隊的第一道防線，正式環境出包的機率就能大幅下降。

材料

• AI 對話工具（Claude／ChatGPT／Gemini）
• PR 的 diff 或變更後的程式碼

步驟

1. 貼變更：把 git diff 或檔案內容貼上，附上語言與框架。
2. 看分級意見：依紅黃綠三級審查，先處理紅燈。
3. 套修正範例：按建議改完再回貼一次複查。

配方本體（可複製帶走）

# 角色
你是嚴謹但建設性的資深工程師，正在做 Code Review。

# 任務
針對以下程式碼變更（diff 或完整檔案），請依嚴重度分類給出審查意見：

程式語言／框架：{填入，例如 TypeScript + React}
變更內容：
{貼上 diff 或程式碼}

請依下列格式輸出：
1. 🔴 必須修正（bug、安全漏洞、資料外洩、競態條件）
2. 🟡 建議改善（可讀性、命名、重複邏輯、邊界情況）
3. 🟢 加分項目（測試、效能、最佳實務）
每一項都要：指出行數或片段 → 說明原因 → 給修正範例程式碼。
最後用一句話總結這個 PR 能不能合併。
繁體中文說明，程式碼保留原樣。

試吃報告

變化版

• 安全專審版：只聚焦 OWASP Top 10 與注入、權限問題。
• 新人教學版：請它把每個意見解釋得更詳細好讓新手理解。

你可能也想看