抓住程式碼審查漏掉的 Bug — Sonar 的 Killian Carlsen-Phelan 與 Taylor Luttrell-Williams

Sonar 的開發者內容團隊成員 Killian Carlsen-Phelan 與 Taylor Luttrell-Williams 指出，AI 編碼代理（coding agent）產出程式碼的速度，已快到人類審查者來不及檢視，因此團隊需要一層自動化驗證機制，檢查 pull request 的意圖與商業邏輯，而不只是語法是否正確。這場議程是實作工作坊：大部分時間都在實機示範，內容包括安裝 Gitar GitHub app、fork 一個名為 Box Office 的 Python 售票 API 範例，並讓三個預先設計好的 pull request 依序跑過開箱即用的審查、專案專屬規則，以及搭配 CI 失敗診斷的完整自動修復／自動合併流程。

兩位講者任職於 Sonar（SonarQube 的開發商），負責開發者內容，並將 Gitar 定位為靜態分析的補充，而非替代品。讀者讀完後應能掌握 Gitar 的設定機制（.gitar/review 情境目錄、.gitar/rules 觸發規則、分支規則集，以及「Gitar fix」或「Gitar auto-merge on」這類 PR 留言）、它在示範中抓到哪些具體 bug，以及這場議程實際展示了什麼、又有哪些只是被描述為 roadmap 或進階能力而並未實作。

代理產出程式碼的速度，遠超審查者能吸收的量

整場論述的起點是：AI 代理寫程式「既快、量又大」，因而衍生兩個相互疊加的問題。第一是審查瓶頸：團隊人力固定，但代理產生的變更數量持續攀升，導致佇列越排越長、合併請求乏人問津，審查成了「沒人想碰的苦差事」。第二是線上事故增加，因為代理不會遵守專案架構、編碼規範或既有準則——它們「缺乏適當的情境脈絡」。

Luttrell-Williams 的結論是：要跟上代理帶來的變更速度，解法「必須比任何人類能做到的都快，而且品質還要優於人工審查」。Gitar 的設計目標也由此而來：高訊噪比以減少誤報與 Token 消耗、能區分真正故障與不穩定或基礎設施雜訊的 CI 失敗診斷、自主修復、由使用者選擇的自動化與參與程度、反覆迭代直到 CI 通過，以及提供透明度的分析儀錶板。

「每一次誤報，都是一次 Token 的消耗，也是一次可能帶來非預期變更的修復嘗試。」

Gitar 能讀出靜態分析讀不懂的意圖與跨檔案脈絡

Killian Carlsen-Phelan 提出整場最清楚的技術區分：像 SonarQube 這類靜態分析不可或缺，能追蹤 SQL 注入「穿過 28 個不同的檔案與函式」一路到資料庫，但它無法推斷意圖。它讀不懂 PR 標題與描述，無法拿新功能與既有程式碼庫比對，也無法判斷商業邏輯是否說不通。這正是 Gitar 鎖定的缺口，兩層機制被定位為互補。

兩位講者說明，Gitar 取用的情境來源包括 PR diff、詳細資訊與留言、CI 紀錄、專案專屬指示，以及儲存庫規則。審查引擎在 PR 開啟時觸發，產出的發現與修復會直接貼在 pull request 上，並可選擇以可執行的建議呈現，或在啟用後自動修復並合併。

示範中的第一個 pull request 正好說明這點。它新增了轉票功能（買兩張票、送一張給朋友），包含對票券不存在、email 格式錯誤、票券已作廢等情況的驗證，也附上測試——而且 CI 全綠。Gitar 的發現是：「買家在把票送人之後，還能退款並作廢該張票。」取消原始訂單時，朋友的票也一併被取消。這個 bug 存在於既有的 orders.py，不在 diff 裡，所以只掃描變更行的審查者根本看不到。有一個測試差點抓到它——測試擋下了「送出已作廢的票」，卻沒擋下反過來的情況。Carlsen-Phelan 的論點是：這類問題「只會隨著代理編碼越用越多而成倍增加」，因為以目前的寫程式速度，要對每個函式都維持可用的理解已不可能。

三種設定介面決定 Gitar 檢查什麼

工作坊的第二個練習介紹團隊用來教 Gitar 自家慣例的機制。講者說明瞭兩個目錄加上一套規則引擎：

第二個 pull request 為每張票加上 3.50 美元的服務費，因此一張 50 美元的票結帳時要 53.50 美元。這家假想公司的規則是：凡是顯示給客戶的價格，都必須是全包價。Gitar 的審查依此規則檢查定價欄位，抓到了違規。Carlsen-Phelan 強調這「本身不算工程 bug」——單看程式碼是正確的——但它違反了公司明訂的慣例，而這類規則平常正是「藏在資深工程師的腦袋裡，或某個 wiki、某個 Confluence 頁面裡」。

他也介紹了更進階的規則模式：如果工程師在 PR 描述裡貼上 Slack 連結，規則可以指示 Gitar 去讀那個 Slack 討論串，並依討論內容檢查程式碼。他說這項能力是他個人的最愛，並鼓勵與會者「想丟多少情境進去就丟多少」。

CI 失敗診斷補上了測試紀錄這一環

第三個 pull request 重構了票券掃描的方式，改為指向票券頁面 URL。CI 有一個測試失敗：對已使用過的票券再掃描一次，回傳 200 而非被拒絕——這是重構時漏掉的檢查。Gitar 檢視 CI 紀錄，回報失敗的測試與具體行為，並提出修復方案。

Carlsen-Phelan 把這形容為解脫了工程工作最痛苦的部分之一：讀紀錄、在本機診斷、推送、等漫長的 pipeline、又失敗、再敲另一位審查者。他稱之為「耗時又燒錢」。Gitar 把「診斷—重推—驗證」這個迴圈自動化，反覆迭代直到 pipeline 全綠，「且每個 PR 不額外收費」。

自動化由 PR 留言驅動。「Gitar fix」會把建議的修復套用成新 commit 並重新驗證。「Gitar auto-apply on」讓 Gitar 不需逐次核准就能推送修復。「Gitar auto-merge on」則在沒有殘留問題且 pipeline 通過後自動合併。示範中，Gitar 對這些留言回了個讚並開始迭代；講者繼續往下講時，合併本身還在進行中。Carlsen-Phelan 說明，用留言操作是為了工作坊方便控制——實務上，自動核准與自動合併是在 Gitar 儀錶板中依儲存庫個別開關，團隊可以針對每個 repo 選擇自動化程度。

示範驗證了概念，但合併結果沒能秀出來

坦白說，這場議程的實況是：第一個練習的修復已落地並通過驗證（Gitar 核准了它，並在 orders.py 補上額外檢查），第二個刻意不合併，第三個在講者交棒時仍在迭代。本集最有力的證據，是 Gitar 在 CI 全綠的 pull request 中抓到的兩個邏輯 bug，而不是自動合併的結果——觀眾被告知「幾分鐘內」就會完成，但臺上始終沒看到它跑完。

進階能力只被點名，並未實際示範

Taylor Luttrell-Williams 最後介紹了超出工作坊範圍的功能，並請與會者參考 repo README 底部的「take it further」段落：

• 功能驗證 — 拿每個 PR 去比對它所實作的 Jira 或 Linear 票券，確保變更「正確、完整，而不只是乾淨」。也支援 Slack，可透過 Gitar 儀錶板的 Settings 與 Integrations 連線，並可引用 Slack 訊息或 Jira 票券來組織審查。
• 知識（Knowledge） — 從審查者回饋中學習慣例並記住誤報，依審查者資歷加權，並顯示每次審查背後的規則、規則來源，以及為何適用。
• 跨 repo 分析 — 找出本身能乾淨合併、卻會弄壞另一個儲存庫程式碼的 PR，且未說明可分析多少個 repo 的上限。
• 跨 PR 分析 — 讓進行中的 PR 互相檢查，處理兩個 PR 各自單獨通過、合併後卻一起弄壞線上的情況；講者說這種風險會隨著堆疊中每多一個代理而升高。

關於方案包裝，Luttrell-Williams 說部分能力屬於企業方案，而「這些全都會隨 Pro 方案推出」。開場時透過 QR code 提供 14 天免費 Pro 試用。

這場議程沒能回答的兩個問題

Q&A 很短，留下一些空白。被問到 MCP 連線與匯入架構準則時，Carlsen-Phelan 確認 Gitar 具備 MCP 連線能力，可透過這種方式匯入情境，並把它與 Knowledge 功能區分開來：Knowledge 是引導 Gitar 自身的審查與修復行為（例如「我們這類東西通常這樣修」），而情境匯入則是依架構準則審查程式碼。他表示知識匯入的具體運作方式還得再確認，但強調他知道有辦法把它接起來。

值得持續關注的未解張力是：講者大力推銷自主性（「就讓它們自己去跑」），但示範中最有說服力的時刻，都是 Gitar 抓到商業邏輯違規——而這完全仰賴團隊必須自行提供的情境：.gitar/review 檔案、規則、票券連結。驗證層的好壞，取決於餵給它的慣例，這又把責任丟回同一批資深工程師身上，而這套工具原本正是要捕捉他們的知識。

flowchart TD
    A["代理或人類開啟 PR"] --> B["Gitar 審查引擎觸發"]
    B --> C["情境來源：PR diff、留言、CI 紀錄、.gitar/review、.gitar/rules"]
    C --> D["發現以行內留言與審查摘要形式張貼"]
    D --> E{"團隊選擇自動化程度"}
    E -->|"手動"| F["審查者點選 Apply fix 或留言「Gitar fix」"]
    E -->|"自動套用"| G["Gitar 推送修復 commit"]
    E -->|"自動套用＋自動合併"| H["Gitar 反覆迭代直到 CI 全綠，然後合併"]
    F --> G
    G --> I["重新驗證 CI，迭代直到全綠"]
    I --> H