This article is not yet available in English. You are reading the Traditional Chinese original. The English edition will appear here once it is translated.
Browse articles that do have an English edition自動化代碼審查助手：從人工逐行檢查到 AI 輔助的品質守門員
Pull Request 堆在待審清單裡，資深工程師花兩小時逐行看程式碼，結果還是漏掉了某個邊界條件沒處理；新人寫的程式碼風格與團隊不一致，審查意見來回改了五輪才過關。這類「人肉審碼」是工程團隊最常見的瓶頸：慢、主觀、而且品質取決於當天誰有空、心情好不好。這篇是操作配方：用 GitHub Copilot、CodeRabbit、SonarQube 與 LLM 節點串出一條自動化審查流水線，讓機器做初步篩選與風險分級，人只處理真正需要判斷的高風險變更。全文最重要的一節是第五節——哪些環節可以交給靜態分析工具，哪些環節必須由 LLM 做語義理解，這條邊界畫錯了，自動化會比人工更危險。
這個場景解決什麼
適合這個配方的流程有四種特徵：高頻率（每天都有 PR）、跨模組（變更影響多個服務或層級）、規則說得清楚（團隊有 coding guideline）、繁瑣但必須做。四者俱備的人工審查，通常有三種損耗：延遲（PR 等半天沒人看）、漏檢（邊界條件、異常處理被忽略）、不一致（不同審查者標準不同）。
做完這個配方之後的目標狀態：低風險變更自動通過初審並給出建議，高風險變更被標記並推到人面前，附帶結構化的審查要點。人的角色從「每一行都看」變成「只看 flagged 的部分」。
同時畫清邊界：這篇處理的是程式碼品質與安全性的初步篩選，不是要你用 AI 取代架構決策；需要業務邏輯判斷與權衡取捨的環節（例如「這個設計是否符合長期演進方向」）也不在自動化範圍內。判斷一個場景值不值得自動化，先讀什麼時候不該用 AI。
工具組合與前置準備
- GitHub Copilot：GitHub 推出的 AI 編程助手，內建於 VS Code 與 JetBrains IDE，支援程式碼補全、解釋、重構建議。企業版提供自訂提示詞與團隊知識庫整合。定價以官網為準；接通後第一件事是在組織設定中限制可訪問的倉庫範圍。
- CodeRabbit：專為 PR 審查設計的 AI 工具，能讀取 diff、理解上下文、給出具體改進建議，並支援與 GitHub/GitLab 深度整合。優點是專注於審查場景，提示詞已針對此任務優化；缺點是需要額外訂閱。方案與定價以官網為準。
- SonarQube：開源代碼品質平台，支援 30+ 語言的靜態分析，涵蓋 bug、漏洞、代碼異味、重複率等維度。可自架或採用雲端版 SonarCloud。自建與採購的系統性取捨見自建還是採購。
- LLM API（本文以 DeepSeek 為例，任何供應商皆可）：負責流程中「語義理解」與「自然語言生成」的判斷。單價以供應商官網為準；接通後第一件事是在供應商控制台設定花費上限與用量告警。
前置檢查表——每一項都有明確答案才動工：
| 檢查項 | 要確認什麼 | 沒確認就做的後果 |
|---|---|---|
| 倉庫權限 | CI/CD 帳號是否有讀取 PR、寫入評論的權限 | 流程跑完但無法回寫審查意見 |
| 編碼規範 | 團隊是否有書面 coding guideline、lint 規則 | AI 給出的建議與團隊習慣衝突，造成混亂 |
| 資料分級 | 程式碼是否包含敏感資訊（金鑰、內部 API）；能否傳給外部 LLM | 敏感程式碼流經未經評估的工具，合規事故 |
| 維運責任 | 上線後誰看告警、誰調整提示詞與規則 | 誤報太多導致團隊關閉自動化，比沒有更糟 |
資料分級的判斷方法見企業資料安全基本盤。
憑證紀律（先講，因為最常被忽略）：所有 API Key、OAuth Token 放進 CI/CD 平台的 secrets 機制；不要寫死在 workflow 檔案、註解或說明文件裡；不要把含憑證的配置檔提交到公開倉庫。
一、盤點人工審查痛點
花兩週，把所有 PR 審查中的常見問題列成一張表：
| 問題類型 | 發生頻率 | 平均發現時間 | 修復成本 | 現在誰發現 |
|---|---|---|---|---|
| 缺少異常處理 | 每週 3-5 次 | 測試階段或上線後 | 高（需熱修復） | 資深工程師 |
| 變數命名不一致 | 每天 2-3 次 | 審查當下 | 低（立即修改） | 任意審查者 |
| 潛在 SQL Injection | 每月 1-2 次 | 安全掃描或滲透測試 | 極高（資安事故） | 安全團隊 |
| 重複程式碼 | 每週 1-2 次 | 代碼重構會議 | 中（技術債累積） | Tech Lead |
兩個填寫紀律：頻率與成本是從實際 issue tracker 與 git log 統計出來的，不靠印象——口頭回憶幾乎總是低估；修復成本要寫具體事件（哪次 hotfix、花了多少人天），寫不出成本的問題，說明它可能根本不值得優先自動化。
這張表有兩個用途：下一步的選型依據，以及上線後計算效益的基線。「自動化前平均每筆 PR 審查多久、自動化後例外處理要多久」都從這張表與後面的執行紀錄算出來——自己測的數字，比任何文章裡的參考值可靠。
二、選一條最痛的審查流程
四個條件同時成立才動手：頻率高（每天發生）、規則寫得出來（能寫成給新人的說明）、出錯有代價（漏檢會出事）、工具鏈有介面。
兩類流程先避開：業務邏輯極度複雜且無文檔的（AI 無法理解上下文，誤報率過高）；團隊規範尚未統一的（今天說 A 明天說 B，自動化追不上變化）。
第一版切小：只做「PR 開啟 → 靜態分析 → 安全掃描 → LLM 語義審查 → 風險分級 → 評論回寫」這一條主幹。客製化規則、歷史程式碼批量掃描全留到第二版。一條穩定跑通的主幹，勝過一張完整但沒上線的設計圖。
三、自架還是雲端
| 考量點 | 自架 | 官方雲端 |
|---|---|---|
| 資料位置 | 程式碼與分析結果在自己環境，適合分級要求高的專案 | 程式碼經供應商環境，須先過資料分級這一關 |
| 維護責任 | 升級、擴展、停機處置都是你的 | 供應商負責 |
| 起步速度 | 需要伺服器資源與基本 DevOps 能力 | 註冊即用，幾分鐘內完成整合 |
| 預算形態 | 伺服器費用加維運人力 | 訂閱制，金額以官網為準 |
決策方法：資料分級結果說「不能出網」時，自架 SonarQube 幾乎是唯一選項；否則先用 CodeRabbit 或 GitHub Copilot Enterprise 把第一條流程跑通，累積了真實用量與失敗紀錄，再評估要不要遷移。不論哪種，都先用測試分支跑通示範流程，第一天不碰生產倉庫。
四、串出最小可跑版本
節點組裝順序：
- 觸發節點：GitHub Actions 的
pull_request事件觸發。優先事件型觸發，退而求其次才用定時輪詢。 - 靜態分析節點：執行 SonarQube Scanner 或 ESLint/Pylint，輸出結構化的警告清單。
- 安全掃描節點：執行 SAST 工具（如 Semgrep、Bandit、Checkov），檢測常見漏洞模式。
- LLM 語義審查節點：將 diff 內容、相關檔案上下文、團隊規範送入 LLM，要求輸出結構化的審查意見 JSON。
- 風險分級節點：根據靜態分析結果、安全掃描等級、LLM 評分，計算綜合風險分數（低/中/高）。
- 評論回寫節點：將審查意見以 GitHub Comment 或 Review API 回寫到 PR，高風險項目 @ 指定審查者。
試跑期三條紀律：
- 用測試分支：建立
feature/test-pr分支，故意放入已知問題（缺少錯誤處理、硬編碼密碼），驗證工具能否正確檢測。 - 留執行紀錄：除平台內建的執行歷史外，為重要流程加一個「台帳」分支——每次執行把時間、PR 編號、風險等級、檢測到的問題數寫進一張專用表格或資料庫。這是第八節監控的原料。
- 影子模式上線：自動化先與人工並行跑幾天——機器給出建議但不強制阻擋，人照樣審查，逐日比對兩邊結果。連續一致之後才讓自動化接管部分低風險 PR，人轉為抽查。
五、哪些環節交給靜態分析、哪些必須用 LLM
這是全文最重要的一節。原則一句話：確定性的模式匹配給靜態分析工具，LLM 只做「語境理解」這一類規則寫不盡的事。
| 環節 | 用什麼 | 為什麼 |
|---|---|---|
| 語法錯誤、未使用變數、重複程式碼 | SonarQube / ESLint / Pylint | 同樣輸入必須同樣輸出；這些是確定性規則，LLM 做不到這個保證 |
| 常見漏洞模式（SQLi、XSS、硬編碼金鑰） | Semgrep / Bandit / Checkov | 基於 AST 或正則的模式匹配，準確率高且可解釋 |
| 變數命名是否符合團隊習慣 | LLM 節點 | 「習慣」難以用規則窮舉，LLM 能理解語境與意圖 |
| 這段程式碼的可讀性與維護性評估 | LLM 節點 | 主觀但重要的維度，需要語義理解 |
| 變更是否影響上下游模組 | LLM 節點＋依賴圖分析 | 需要理解呼叫關係與數據流，靜態分析只能給出部分答案 |
| 審查意見的自然語言表達 | LLM 節點 | 但意見裡的程式碼片段由靜態分析工具原樣注入，LLM 不得改寫任何程式碼 |
兩條鐵律：
- 程式碼片段永遠不經過 LLM 的嘴。 這些內容由靜態分析工具原樣提取；LLM 只產語言，不產事實。自動化審查裡代價最高的事故，形態幾乎都是「模型改寫了一行程式碼，而且改得很像真的」。
- LLM 輸出永遠當作不可信輸入。 LLM 節點要求輸出固定結構的 JSON（欄位在提示詞裡逐一列舉）；下游第一個節點做格式校驗，校驗不過直接進例外分支，不允許「盡量解析」。
LLM 節點的提示詞寫法：給審查維度枚舉（安全性、可讀性、效能、一致性）、給輸出 JSON 的欄位定義、給邊界規則（「只根據提供的 diff 與上下文判斷，不補充推測」），溫度調低以減少隨機性。提示詞不神奇，神奇的是它後面接了校驗節點。
以下是一個典型的 LLM 審查提示詞範例：
你是一位資深軟體工程師，負責審查以下 Pull Request 的變更。
【上下文】
- 專案語言：TypeScript + React
- 團隊規範：變數使用 camelCase，函式名稱需動詞開頭，禁止使用 any 類型
【Diff 內容】
{{diff_content}}
【相關檔案上下文】
{{related_files_context}}
【審查維度】
請從以下四個維度評估，每個維度給出 1-5 分（5 為最佳）：
1. 安全性：是否有潛在漏洞（XSS、Injection、敏感資料洩露）
2. 可讀性：變數命名、函式長度、註解完整性
3. 一致性：是否符合團隊編碼規範
4. 效能：是否有明顯的效能問題（不必要的迴圈、記憶體洩漏風險）
【輸出格式】
請嚴格按照以下 JSON 格式輸出，不要添加任何其他文字：
{
"scores": {
"security": number,
"readability": number,
"consistency": number,
"performance": number
},
"risk_level": "low" | "medium" | "high",
"comments": [
{
"file": string,
"line": number,
"severity": "info" | "warning" | "error",
"message": string,
"suggestion": string
}
],
"summary": string
}
【邊界規則】
- 只根據提供的 diff 與上下文判斷，不補充推測
- 如果無法確定某些資訊，在 comments 中標記為 "needs_human_review"
- 不要改寫任何程式碼，只提供建議
六、錯誤處理、重試與冪等
先把失敗分成三類，因為三類的處置完全不同：
| 失敗類型 | 例子 | 處置 |
|---|---|---|
| 暫時性 | API 限流、網路逾時 | 節點自動重試（設次數與間隔）；重試耗盡仍失敗進例外分支 |
| 資料性 | Diff 為空、檔案編碼異常、LLM 輸出格式錯誤 | 不重試（重試還是錯）；直接進例外分支，人修資料後重跑 |
| 設定性 | API Key 過期、SonarQube 服務停機、GitHub Token 權限不足 | 立即停止流程並告警，等人介入 |
冪等是重試的前提：流程要保證「同一個 PR 跑兩次不會重複發送評論」。做法是在發送評論前先查詢該 PR 是否已有來自本自動化帳號的評論——存在就更新而非新增，絕不無腦追加。沒有冪等設計就開重試，等於裝了一台評論製造機：重複的審查意見，比人工審查還難收拾。
七、失敗告警
- 告警發到「有人在值班」的渠道：即時通訊群組或 email，且群組裡有明確的值班表。告警沒人看，等於沒有告警。
- 告警內容模板：流程名稱、PR 編號、失敗節點、錯誤摘要、發生時間、重跑方式。讓收到的人在半分鐘內能決定「現在處理還是稍後處理」。
- 分級防洗版：單筆 PR 審查例外進每日匯總；API Key 過期、服務停機這類「流程已停」的事件才即時推送。每筆例外都彈一次通知，值班的人很快會把渠道靜音——告警系統就死在靜音那一刻。
八、上線後的監控
- 前兩週是觀察期：每天看執行歷史與台帳，記錄執行總數、失敗次數、誤報率（人工標記為不相關的建議比例）。兩週之後自己算誤報率與主因分佈——這是你的流程自己的數據，判斷門檻（誤報率高到多少要調整提示詞）由你的團隊容忍度決定，定了就寫進值班說明，不要引用任何文章裡的現成數字。
- 每週抽樣複核：固定抽 5-10 筆已自動通過的 PR，人工複查是否有漏檢問題。抽樣筆數依 PR 量自定，關鍵是固定頻率、留下紀錄、發現漏檢就調整規則或提示詞。抽樣抓的是「流程沒報錯但漏掉了重要問題」這類最安靜的事故。
- 變更紀律：團隊編碼規範更新、LLM 供應商更新模型版本、你改提示詞，都算變更。改動前先用最近的例外樣本與幾筆正常樣本重跑一遍，確認沒有變差再上；改動寫進台帳。
- 成本：LLM 節點的用量乘上供應官網單價，加上 SonarQube 授權費與你的維運時間，就是這條流程的真實成本；估算方法見AI 成本怎麼算。
成果與驗收標準
| 檢查點 | 通過標準 | 沒通過怎麼辦 |
|---|---|---|
| 盤點基線 | 有審查痛點表，頻率與成本是從 issue tracker 統計的紀錄 | 回到第一節；先別急著搭流程 |
| 主幹跑通 | 測試分支端到端跑完，檢測到故意放入的問題 | 檢查工具配置與權限 |
| 確定性邊界 | 程式碼片段沒有任何一個由 LLM 改寫 | 改成靜態分析工具直接提取 |
| LLM 輸出校驗 | LLM 輸出有格式校驗節點，不合法進例外分支 | 在 LLM 節點後補校驗 |
| 冪等 | 手動觸發同一個 PR 兩次，沒有重複評論 | 加評論存在性檢查 |
| 影子期 | 與人工並行連續數日結果一致才交接 | 延長影子期，逐項找不一致的原因 |
| 告警有效 | 故意製造一次失敗（暫撤測試 API Key），告警在承諾時間內到達值班渠道且內容完整 | 修告警路由與值班安排 |
| 監控習慣 | 台帳連續兩週每週有紀錄，抽樣複核有留痕 | 把監控指派到具體的人，放進行事曆 |
常見踩坑
- 讓 LLM 做確定性工作：「讓 AI 順便檢查一下語法」一時方便，代價是同樣輸入可能不同輸出，出了錯無法重現、無從追查。
- 用個人帳號的憑證：當事人離職、改密碼的那天，流程集體猝死。用服務帳號，並納入組織的憑證管理。
- 直接在生產倉庫上實驗：正確順序是測試分支、非敏感專案小範圍、全量。跳級的人通常在第二步就出事。
- 沒做冪等就開重試：重試機制會把偶發錯誤放大成重複評論事故。
- LLM 節點不設花費上限：一個迴圈觸發的臭蟲能讓流程整夜持續呼叫 API。上限與告警在供應商控制台設定，五分鐘的事。
- 告警發到沒人看的渠道：沒有值班表的告警是自我安慰。
- 一次自動化所有審查維度：一週把安全性、可讀性、效能、一致性全部自動化，第二週就沒有人力調整誤報。先讓安全性審查穩定跑滿一個月，把模式沉澱成範本，再複製到其他維度。
- 忽略團隊文化阻力：自動化審查初期誤報率可能高達 30-40%，如果沒有提前溝通與教育，團隊會迅速失去信任。第一個月重點不是降低誤報，而是建立「AI 建議供參考，最終決定權在人」的文化共識。
下一步
- 同一套「自動篩選＋人工閘門」模式用在 API 文檔場景：API 文檔同步更新系統
- 技術債的量化與優先級排序：技術債追蹤與重構優先級排序
- CI/CD 管道的異常檢測：CI/CD 管道異常檢測與修復建議
- 微服務架構的依賴可視化：微服務依賴關係地圖生成
- 資料分級與安全邊界：企業資料安全基本盤
- 上線前的合規檢查表：AI 合規與風險邊界
- 流程越串越多、要不要升級成平台：自建還是採購