Skip to content
海博賽特
HCYTLOG
RSS
← 文章目次 HCYTLOG / 文章與筆記
更新： Gitlab AI Dev Cli

我怎麼用 GitLab Duo CLI 做 Code Review：一個社群維護者的日常

保留我在 2026 年 6 月用 GitLab Duo CLI 做 review 的經驗，並補上 2026-10-08 的版本與 namespace 前提、模型識別碼、Credits 計費，以及 headless 自動核准工具的邊界。

For English readers, switch to the English version.EN
本文目錄

先講清楚：我是 GitLab 的社群貢獻者（Community Contributor），當時透過貢獻者計畫拿到 Duo Enterprise 的使用權限。我不是 GitLab 員工。這篇保留 2026 年 6 月的使用經驗，操作與計費補充查核至 2026-10-08；我的席次來源不代表所有讀者都需要同一種附加元件。

從一個意外的發現開始

我一開始也是只用 GitLab Duo Chat，就是 MR 頁面上那個 AI 聊天框。問問「這段 code 在幹嘛」「幫我寫個 commit message」之類的。夠用，但就那樣。

直到有一天我需要一口氣 review 好幾個模組的程式碼，在網頁上一個一個問實在太慢了。我翻了一下 glab 的文件，發現有個 glab duo cli run 指令。試了一下，嗯，原來還能這樣用。

它跟網頁版最大的差別是什麼？可以寫腳本。 你可以把 AI 分析變成一個可以重複執行的流程，不用一直坐在螢幕前面跟它對話。

而且（這點很多人不知道）CLI 和網頁版的對話是同步的。 你可以在網頁上開一段對話，然後用 /sessions 指令在 CLI 接著繼續。反過來也行。IDE 擴充套件也通。三個入口，同一個對話。

你的第一個 Duo CLI 指令

2026-10-08 更新：版本與 namespace 先確認

現在照官方安裝文件操作，透過 glab 使用 Duo CLI 需要 glab 1.107.0 以上並完成 glab auth login。GitLab 19.2 起是正式版；18.11 到 19.1 的實例還需要啟用 beta 與實驗功能。glab duo cli 第一次啟動時會提示安裝 Duo CLI binary，兩個工具有各自的版本。

存取權要看 Agent Platform 的前置條件：啟用 GitLab Duo 與 Agent Platform；沒有 Duo Pro／Enterprise 時，要啟用 Duo Core。Self-Managed 與 Dedicated 還要確認實例允許 Duo CLI。CLI 安裝頁目前標示 Premium／Ultimate，不能把 Agent Platform 部分功能支援 Free 直接當作 CLI 在所有方案都可用。

還有一個我原文沒交代的前提：到 Preferences → Behavior → Default GitLab Duo group 設定 default GitLab Duo namespace，或從有 Duo 存取權的專案啟動。CLI 先解析專案 remote 的 namespace，再看個人預設；第一個 namespace 沒有權限或 Credits，不會自動換下一個。指定 -C 只是切工作目錄，不會替你取得權限。

以下指令已依官方文件調整；這次更新沒有實跑會消耗 Credits 的任務。

互動模式與無頭模式

裝好並完成上述設定後，Duo CLI 有兩種模式：

互動模式：就像在終端機裡面開一個 AI 對話。

glab duo cli

進去之後可以直接打字問問題，用 /model 切換模型，用 /sessions 列出之前的對話（包含你在網頁或 IDE 裡的），用 /new 開新對話。

無頭模式（headless）：給腳本用的，跑完就結束。

glab duo cli run -C ~/my-project --goal "看一下這個專案的整體架構，用三句話摘要"

-C 指定 repo 路徑，--goal 是指令。跑完直接印結果，不用互動。

我第一次跑完的感覺是：「喔，這就是我要的。」不用切視窗，結果直接印在終端機，可以 pipe、可以存檔、可以串進其他工具。而且因為對話會同步到網頁版，我跑完之後還可以到 GitLab UI 上繼續追問，不用重來。

可以切模型，這件事改變了我的用法

我當時用網頁版 Duo Chat，很少去看背後是哪個模型。CLI 的 --model flag 讓我開始固定模型，再比較同一個任務。現在網頁版 Agentic Chat 也有模型選擇，選模型已經不是 CLI 獨有的能力。

這個功能看起來不起眼，實際上超有用。

原文記下我拿同一個 code review 任務跑過 9 個模型。下面保留其中幾筆結果；原文沒有註明測試日期、完整 prompt 與逐輪輸出，不能把它當作目前模型的排名：

  • Claude Opus 4.6 回了 10.2 KB：最詳盡，每個角度都展開講，適合你想要全面了解的時候
  • Claude Opus 4.7 只回 5.9 KB：精簡扼要，只講重點，適合你已經大概知道狀況只想確認
  • Gemini 3.5 Flash 回了 4.4 KB：最快，但相對淺，適合快速掃一眼
  • GPT 5.4 回了 0.3 KB：那一輪拒絕回答，同一個任務 GPT 5.5 則有回答；單次拒答不能用來判斷整個模型的安全設定

列出的非拒答結果從 4.4 KB 到 10.2 KB，約差 2.3 倍；拒答的 0.3 KB 不算在這個比較裡。輸出長度不代表 finding 正確率，也不能拿一次任務決定模型品質。

我當時的習慣是：重要的 review 至少用兩個模型跑一次，交叉比對，再查每個發現是否成立。這會增加呼叫數；都用 Credits 計費，不代表成本相同。

目前 --model 要填 GitLab 的 gitlab_identifier，不是模型供應商的 API 名稱。依官方 model registry，下面是 2026-10-08 查到的識別碼；實際可用模型仍依你的實例與群組設定。互動模式可用 /model 查看可選清單。

# 用不同模型跑同一個任務
glab duo cli run -C ~/project --goal "review 錯誤處理" --model claude_opus_4_6_20260205
glab duo cli run -C ~/project --goal "review 錯誤處理" --model claude_opus_4_7
glab duo cli run -C ~/project --goal "review 錯誤處理" --model gemini_3_5_flash_vertex

我的日常工作流

原文記下的日常流程，會搭配幾個 AI CLI 工具：

Duo CLI 我當時拿來做廣度探索。多模型切換方便，當時取得的使用額度也讓我願意拿來批次初篩。我會把大 repo 拆成幾個模組，每個模組跑一次分析，再用不同模型交叉看。這是我的使用條件，不代表只要有 Enterprise seat 就比其他工具便宜。

Claude Code 我拿來做深度挖掘。Duo 標記出來「這邊可能有問題」的地方，我會丟給 Claude Code 深入分析。它有跨 session 的記憶，適合需要來回好幾輪才能搞清楚的問題。

重點不是哪個比較好，是怎麼搭配。Duo CLI 幫你快速掃過全貌，標記可疑的地方；Claude Code 針對可疑的地方深入挖。一個做廣度，一個做深度。

用 git log 當錨點

直接叫 AI「review 這個 repo」，它會自己翻檔案結構、看 git history，但老實說效率不太好。它不知道哪些東西重要、哪些可以跳過。

我的做法是先用 git log 撈出相關的 commit，然後把結果塞進 prompt：

# 先找相關 commit
git log --all --grep='refactor\|fix\|validate' \
  --regexp-ignore-case --name-only \
  --format='%H %cs %s' > anchors.txt

# 把 commit 歷史當作 context 餵給 Duo
glab duo cli run -C ~/project \
  --goal "以下是近期相關的 commit 歷史：
$(cat anchors.txt)

根據這些 commit，這個 repo 的重構方向是否一致？
有沒有哪些模組被遺漏了？"

為什麼有效？因為 AI 有了具體的錨點，它知道哪些檔案被改過、什麼時候改的、改的原因。分析就會集中在有意義的範圍，不會漫無目的地亂翻。

這個技巧用在技術債盤點特別有效。你先用 git log --grep 撈出所有跟 TODO、FIXME、HACK 相關的 commit，丟給 Duo 分析這些技術債的分布跟嚴重程度。比起讓 AI 自己去找，精準很多。

讓 AI 自己過濾垃圾結果

用 AI 做分析常遇到一個困擾：它回報一大堆東西，但大多數是雜訊。你花時間跑分析，又花更多時間人工篩選。

我後來學到一個簡單的方法：在 prompt 結尾加上驗證條件，讓 AI 回報之前先自己篩一遍。

glab duo cli run -C ~/project \
  --goal "檢查這個模組的錯誤處理。

在回報之前，先自我檢查每個發現：
1. 這個問題在預設設定下存在嗎？
2. 有沒有現有機制已經處理了？
3. 影響範圍超出正常使用嗎？

不符合的標為「不適用」並說明原因。"

原文記下的一次任務，本來有 21 個結果，加上驗證條件後剩 2 個。回報數少了約 90%，但這不等於誤報率下降 90%。被刪掉的結果仍可能有漏判，留下的 2 個也要查證；這次沒有重跑那個比較。

踩過的坑

用了一段時間，有些事情想提醒：

無頭模式每次是新 session。 用 glab duo cli run 跑的話，每次是獨立的。但你可以用 --existing-session-id 接續之前的對話，或者切到互動模式用 /sessions 找回之前的 session。要把上一輪結果當 context 餵進去也可以，用 --ai-context-items 注入檔案。

2026-10-08 更新：Credits 與席次分開看。 官方計費文件把 Agent Platform 的 usage billing 與 Duo Pro／Enterprise 的席次型功能分開。模型有不同的 credit multiplier，一個任務也可能有多次 LLM 呼叫；community subscriptions 不附 included credits。批次前先查 namespace 的可用額度、用量上限與 on-demand 設定，不能用我的貢獻者資格推算你的成本。

模型品質差異很大。 前面講過了，同一個任務不同模型的回答可以差兩倍以上。重要的分析不要只跑一個模型就下結論。

2026-10-08 更新：headless 本身就不等你核准工具。 官方 headless 說明明載 run 會自動核准工具，所以批次不需要額外加 --dangerously-skip-permissions。拿掉 flag 也不會變成唯讀模式。這類分析應放在可丟棄的工作副本與受控沙盒，不放正式憑證，完成後檢查差異；「只做 review」的 prompt 不能代替執行環境的限制。互動模式的 plan／build 與工具核准是另一件事，不能套到 run。

最後

我剛開始只把 GitLab Duo 當網頁聊天框。找到 CLI 入口之後，才開始把它接進自己的 review 流程：你可以把 AI 分析變成可重複、可自動化、可比較的流程。

我身為社群維護者，原文記下的就是這套日常 review 流程。它不會取代你的判斷，但確實幫你省下大量「先粗看一遍」的時間，讓你可以把精力集中在真正需要思考的地方。

如果你已經在用 GitLab，glab duo cli run 值得試一下。搞不好你也會跟我一樣，用了就回不去網頁版了。

批次腳本和 timeout 處理，我整理在GitLab Duo CLI 進階篇，也補上我怎麼比較模型和篩選回報結果。