AI-Codereview-Gitlab：把 GitLab webhook 接到大模型的自架審查服務
基于大模型(DeepSeek,OpenAI等)的 GitLab 自动代码审查工具；支持钉钉/企业微信/飞书推送消息和生成日报；支持Docker部署；可视化 Dashboard。
秒懂
- 它是什麼？
- 它用一個 webhook 端點把 Merge Request 與 Push 事件轉給大模型，再把結果寫回 Note。本文拆解它的資料流、部署指令、agentic 模式的實際開銷，以及什麼情況下你該選別的方案。
- 適合誰用？
- 這個專案適合已經自架 GitLab、想把審查結果直接落在 Merge Request Note 裡、並且願意自己保管 API Key 的團隊。不適合沒有自架 GitLab 的團隊，也不適合期待零維運成本的人：它需要一個對 GitLab 可見的常駐服務，agentic 模式還需要 ≥ 50GB 磁碟與 10MB 到 2GB 的每專案快取。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 4 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是審查結果落地的問題，不是審查品質的問題
多數團隊的痛點不在於「沒有人會看 diff」，而在於審查意見散落在聊天軟體、臨時文件或某個人的腦子裡。AI-Codereview-Gitlab 選擇把輸出寫回 GitLab 本身的 Note，讓討論留在程式碼旁邊。README 對流程的描述很直白：使用者在 GitLab 提交程式碼（Merge Request 或 Push）時觸發 webhook，系統呼叫第三方大模型審查，再把結果回饋到對應的 Merge Request 或 Commit 的 Note。
目標使用者是已經自架 GitLab 的開發團隊。如果你用的是 GitLab.com 的 SaaS 版本，這個工具仍可用，但 README 明確提醒要確保 GitLab 能存取本系統，內網受限時建議把系統部署在外網伺服器。這代表它預設的部署拓撲是「一個能被 GitLab 打到的常駐服務」，而不是純粹的 CI Job。
值得注意的是它同時做了推送與日報。審查結果可以一鍵送到釘釘、企業微信或飛書，日報則基於 GitLab、GitHub、Gitea 的 Commit 記錄自動整理。這兩個功能把工具從「審查機器」推向「團隊可見度工具」，但也意味著你得多設定一組 webhook 與對應的環境變數。
資料流：webhook 進、模型審、Note 出
整個系統的骨架由兩個服務組成。api.py 是接收 webhook 的 API 服務，預設在 5001 埠；ui.py 是 Streamlit 寫的 Dashboard，預設在 5002 埠。兩者共用同一份 conf/.env 設定。
一次審查的資料流大致是：GitLab 發出 webhook 到 /review/webhook，系統讀取 diff，依 SUPPORTED_EXTENSIONS 過濾檔案類型，把內容送給 .env 中 LLM_PROVIDER 指定的模型，最後把回覆寫成 Note。SUPPORTED_EXTENSIONS 的預設值是一長串網頁與後端語言副檔名，README 的註解寫得很清楚：未配置的檔案類型不會被審查。這是一道省 token 的閘門，也是實務上最常需要調整的設定。
模型供應商的切換靠單一變數 LLM_PROVIDER，README 列出 zhipuai、openai、deepseek、ollama 四個值，功能列表另外提到 Anthropic 與通義千問。這種設計讓換模型不需要改程式碼，代價是不同供應商的 prompt 行為差異會直接反映在輸出風格上，而專案並沒有提供跨供應商的輸出一致性保證。
Token 的取用優先序也寫在 README：系統優先使用 .env 中的 GITLAB_ACCESS_TOKEN，沒配置時才用 webhook 傳遞的 Secret Token。這順序值得留意，因為它意味著 .env 一旦設了 token，webhook 那邊帶什麼都不會生效。
部署路徑：Docker Compose 與本機 Python 兩條路
Docker 路線的指令是三步。先 git clone 專案並進入目錄，接著 cp conf/.env.dist conf/.env，然後編輯 conf/.env 填入關鍵參數，最後 docker-compose up -d。驗證方式是訪問 http://your-server-ip:5001，看到 The code review server is running. 表示主服務啟動；訪問 5002 看到審查日誌頁面表示 Dashboard 正常。
本機路線需要 Python 3.10+ 與虛擬環境，pip install -r requirements.txt 之後，分別用 python api.py 啟動 API、用 streamlit run ui.py --server.port=5002 --server.address=0.0.0.0 啟動 Dashboard。README 建議使用 venv。
GitLab 端的設定有三個要點。webhook URL 指向 http://{your-server-ip}:5001/review/webhook；Trigger Events 只勾選 Push Events 與 Merge Request Events，README 特別註明不要勾選其它 Event；Secret Token 填上面配置的 Access Token，且標為可選。Access Token 可以來自個人設定或專案設定兩種來源。
推送設定的模式是開關加 webhook URL 兩件套。以釘釘為例，DINGTALK_ENABLED 為 0 表示不發送、1 表示發送，DINGTALK_WEBHOOK_URL 填自訂機器人的位址。企業微信與飛書的配置方式類似，README 把細節指向 doc/faq.md。
Agentic 模式：能力換來的是磁碟、Token 與時延
REVIEW_STRATEGY 這個環境變數切換兩種策略。diff_only 是預設值，README 說它的行為與原版完全一致，只對 diff 做審查。agentic 則讓 LLM 具備工具呼叫能力，可以在本地克隆的程式碼庫內自主探索，README 聲稱能產出更全面的結果。
機制上，agentic 模式會按需在 REPO_CACHE_DIR 下克隆或更新目標專案，README 給的單專案體積區間是約 10MB 到 2GB。另外兩個可調參數是 REPO_CACHE_DIR（預設 data/repo_cache/）與 AGENT_MAX_ITERATIONS（預設 20）。
代價寫得很具體，值得逐項看。磁碟建議預留 ≥ 50GB；單次 session 記憶體峰值約 500MB；單次 review 平均 5k 到 50k tokens，是 diff_only 的 3 到 10 倍；時延 30 秒到 5 分鐘。這組數字決定了它不適合當成同步阻塞的關卡，而更像背景的非阻斷審查。
安全邊界方面，shell 工具有沙箱，包含命令白名單、黑名單、路徑越界檢查與 30 秒超時，預設僅允許讀類命令如 ls、cat、grep、find、git log。要放開得透過 AGENT_SHELL_ALLOWLIST 與 AGENT_SHELL_BLOCKLIST 調整。
降級行為是這個模式最務實的設計：clone、fetch、LLM 或工具呼叫任一階段失敗，都會自動降級回 diff_only，保證至少回傳與原版一致的 review。換句話說，agentic 是加成而非替代，失敗時你失去的是深度，不是審查本身。
Review Style 與日報：討喜的功能，也是團隊文化的變數
專案提供四種 Review Style：專業型、諷刺型、紳士型、幽默型。README 對諷刺型的示範是「這代碼是用腳寫的嗎？」，幽默型則是拿 if-else 跟相親經歷相比。這種設計在個人專案或小團隊裡能降低摩擦，但在跨部門、有外部承包商或需要留存紀錄的場景裡，把帶有嘲諷語氣的評語自動寫進 Merge Request Note，是會被追責的。這不是程式的問題，是流程的問題，而專案並沒有提供語氣審核或人工覆核的環節。
日報功能基於 GitLab、GitHub 與 Gitea 的 Commit 記錄整理每日進展。README 的文案帶著「誰在摸魚、誰在卷」的調性，Dashboard 也以「甩鍋無門」自況。這些話在 README 裡是行銷語氣，實際導入時要當成一個提醒：這個工具會把個人產出變成可比較的數字，而數字一旦進到 Dashboard，就會被拿來做績效討論。
Dashboard 集中展示所有 Code Review 記錄，含專案統計與開發者統計。README 沒有說明資料存放位置、保留策略或清理方式，這對有資料落地要求的團隊是一個需要自行確認的空白。
替代方案與取捨：GitLab CI 內自建，或改用託管服務
最直接的替代做法是把審查寫成 GitLab CI Job，在 pipeline 裡呼叫模型 API。差異在於觸發點與狀態：CI Job 隨 pipeline 生命週期結束，審查結果要嘛寫進 job log，要嘛自己再呼叫 GitLab API 留言；AI-Codereview-Gitlab 則是常駐服務，靠 webhook 觸發，狀態與記錄留在自己的資料庫與 Dashboard 裡。前者不需要額外主機，但每次審查都要重跑環境；後者需要一台對 GitLab 可見的機器，換來的是集中記錄、日報與推送。
另一個方向是改用託管型的程式碼審查服務。差別在於程式碼與 diff 的流向：自架版本讓你控制模型供應商，甚至能用 Ollama 跑本地模型，資料不出內網；託管服務則把 diff 送到第三方。如果你的合規要求不允許程式碼離開內網，Ollama 這條路是這個專案相對少見的價值點。
還有一個容易被忽略的替代選項：什麼都不接。如果團隊的 Merge Request 量很小，或審查意見本來就會在當天被處理，自動化帶來的邊際效益可能低於維運成本。這個工具真正的價值在於量大、且審查意見容易在討論中被淹沒的團隊。
維護成本、授權與導入前該驗證的事
授權是 Apache-2.0，預設分支為 main，最近的版本標記是 v1.5.1（2026-06-29），前兩個版本是 v1.4.3 與 v1.4.2。從版本節奏看，這是一個仍在更新的專案。Apache-2.0 允許商業使用與修改，但這不是法律意見，實際條款與專利授權細節請自行閱讀 LICENSE 全文。
維護成本主要落在三處。第一是模型 API 費用，agentic 模式的 token 區間是 diff_only 的 3 到 10 倍，這是持續性的支出而非一次性設定。第二是磁碟與快取，agentic 模式建議 ≥ 50GB，且每個專案的快取從 10MB 到 2GB 不等，專案數量一多就要重新估算。第三是 webhook 的可達性，README 要求 GitLab 能存取本系統，內網受限時得部署在外網伺服器，這會牽涉到憑證與網路暴露面的管理。
README 另外提到一個 Pro 版，安裝方式是透過 install.sh 腳本，並連到 doc/pro.md 說明。同一作者還有 Entire Dashboard 與 Site Guard 兩個專案。這代表開源版與 Pro 版之間存在功能分界，導入前值得先確認你要的功能是否落在開源版這一側，因為 README 只給了 Pro 版的入口，沒有列出兩者的完整差異表。
導入前最該先驗證的，是 SUPPORTED_EXTENSIONS 是否涵蓋你的主要語言。預設清單偏向 Java、Python、PHP、Vue、Go、C 系列、JS、CSS、SQL 等，如果你的專案以清單外的語言為主，這個工具預設會直接跳過那些檔案，而你不會收到任何審查結果。
編輯結論
這個專案適合已經自架 GitLab、想把審查結果直接落在 Merge Request Note 裡、並且願意自己保管 API Key 的團隊。不適合沒有自架 GitLab 的團隊，也不適合期待零維運成本的人：它需要一個對 GitLab 可見的常駐服務，agentic 模式還需要 ≥ 50GB 磁碟與 10MB 到 2GB 的每專案快取。導入前先確認三件事：conf/.env 裡的 SUPPORTED_EXTENSIONS 是否涵蓋你的主要語言，GitLab webhook 是否只勾選 Push Events 與 Merge Request Events，以及你的模型供應商單次 review 的 token 成本能否接受 agentic 模式 5k 到 50k tokens 的區間。
社群筆記