抓住程式碼審查漏掉的 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