你的 AI 代理每次上工都像新進員工——專訪 Sonar 的 Killian Carlsen-Phelan

Sonar（程式碼驗證廠商）的 Killian Carlsen-Phelan 主張，AI 編碼代理應該在編碼工作階段內就被強制以確定性的方式檢查自己的工作，而不是等到發出 pull request 時才檢查；否則代理會複製程式庫既有的缺陷，而且每個工作階段都要重新摸索專案脈絡、白白燒掉 Token。這場 17 分鐘的演講大部分是 Sonar Vortex 的產品導覽——這是一款外掛，會在代理動手寫程式之前，把專案規範與程式碼地圖注入代理，並在每次編輯後重新執行 SonarQube 分析；標題裡的「新進員工」比喻只是他的開場類比，並非另一條獨立主線。讀者可以從中看到 Sonar 關於開發者對 AI 程式碼信任度的調查資料、一段代理兩度修不好暫存檔許可權漏洞的實錄示範，以及廠商對節省 Token 與降低事故的說法。

Carlsen-Phelan 是以 Sonar 代表的身分發言，場合顯然是有廠商攤位的研討會，因此他引用的數字與產品主張都是公司說法，而非獨立研究結果。本簡報把他「實際示範了什麼」（代理在真實任務上的自我修正迴圈）與他「只是宣稱什麼」（Token 少 36%、生產事故少 44%、誤報率很低）分開呈現，並標明哪些論點取決於你是否信任 Sonar 自家的規則集。

代理會把你程式庫既有的缺陷原封不動複製一遍

Carlsen-Phelan 的核心論點是：代理工作階段一開始對專案一無所知。它不知道慣例、編碼規範，也不知道預先定義好的架構規則，所以被指派一項功能時，只能搜尋整個儲存庫，反推既有程式碼怎麼運作。他形容這種搜尋「有點像擲骰子」——運氣好很快找到脈絡，運氣不好就在整個 repo 裡亂逛，兩種情況都耗時間也耗 Token。

更麻煩的是缺陷會被繼承。他說，每個程式庫都有問題，所以「你用的那個代理，很可能會把這些問題複製一遍、把這些模式重複一遍」。一旦代理引入了沒被抓到的新問題，要維持程式碼品質就變得「幾乎不可能」。

他用 Sonar 對 1,100 多位開發者的調查來凸顯這件事的嚴重性：

他說這兩個數字之間的落差令人心驚：用他的話說，團隊是「在沒有驗證的情況下，盲目把程式碼送進生產環境」。

等到 PR 才抓缺陷，已經太遲

他的成本論點是：程式碼審查是錯的檢查點。代理寫程式比人審查快得多，所以等到 pull request 才發現缺陷，就會觸發一整套迴圈：退回給開發者或代理、重做、重新推送、重新審查、重新分析。他說這既燒時間也燒錢，還讓所有人挫折。

他的錄影示範把這點講得很具體。他要求代理把一個日誌檔解壓縮成暫存檔、重複使用同一個檔案，並寫一個測試證明它確實被重複使用。代理不到兩分鐘就完成，還自己寫了測試套件——但同時引入了一個安全問題：它建立暫存檔時沒有明確設定許可權。Carlsen-Phelan 主張，這類 bug 很難用測試抓到，「通常是資深審查者只有在特別去找的時候才會發現，甚至根本不會發現」。

他要針對的失敗模式不是寫得慢，而是發現得太晚。「代理寫得很快。重做會拖慢你。而如果你是在 PR 才抓到，你早就落後於該有的進度了。」

Vortex 先把脈絡餵進去，之後每次編輯都重新驗證

這款產品分兩階段運作，他稱為「引導」與「驗證」。在代理動手寫之前，Vortex 先提供專案的編碼規範、核准使用的函式庫、架構規則，以及一張程式碼彼此如何連結的地圖——讓代理「直接找到正確的檔案」，而不是一個檔案一個檔案地掃。工作過程中，每次編輯或新增檔案都會自動觸發 SonarQube 分析；在代理結束這一輪之前，還會被要求做一次更深入的檢查，涵蓋跨檔案的資料流與更深層的安全問題。被標記的問題會送回代理修正，Vortex 再重新檢查。

flowchart TD
    A["代理收到任務"] --> B["Vortex 引導階段：專案規範、核准函式庫、程式碼地圖"]
    B --> C["代理撰寫或編輯程式碼"]
    C --> D["每次編輯自動執行 SonarQube 檢查"]
    D --> E{"發現新問題？"}
    E -->|是| F["問題送回代理"]
    F --> C
    E -->|否| G["回合結束前的深入檢查：資料流、安全"]
    G --> H{"發現問題？"}
    H -->|是| F
    H -->|否| I["代理交回已驗證的變更"]

在錄影的工作階段中，第一次分析回報了六個問題。Claude 判定其中兩個落在它剛寫的行數上，另外四個屬於既有程式碼。Vortex 只強制修正新程式碼，既有問題則僅提示、不強迫修——他說這是刻意的設計，免得工具太吵。

那個安全問題就是暫存檔許可權。代理第一次的修法依賴 Java 的預設行為（在 Mac 與 Linux 上只有擁有者可存取），Vortex 把它退回：「問題仍然存在，因為暫存檔還在共享目錄裡。」Sonar 的規則要求必須明確設定許可權。代理又改了一輪，直到符合為止。Carlsen-Phelan 對這件事的總結是：「它先問了 Sonar。當 Sonar 標記它的修法時，它又繼續往下改，自己把問題修掉。」

他也提到這款外掛會自動載入——偵測到 CLI、偵測到 hook 系統、機密偵測自動開啟——完全不需要把 Sonar 的指示貼進提示詞。他特別點出機密外洩是「最容易防範、但對組織代價最高的事情之一」，並表示這款外掛會擋住機密，不讓它們流向 GitHub，也不讓它們進入代理的脈絡記憶。

確定性檢查，而不是再找一個模型來替模型打分數

Carlsen-Phelan 把 Vortex 與 AI 審查劃出清楚界線。「這不是又一個 AI 在檢查 AI。更不是它在檢查自己。」他說自我審查是最不可靠的抓錯方式之一，因為代理在「創造」與「審查」時的思考方式截然不同，而其他代理在審查既有程式碼時則會產生幻覺。

替代方案是確定性：同一份程式碼、同一套分析，每次結果都一樣。他說這正是讓指引「可靠、可治理……合規且可預測」的關鍵。他把 Vortex 定位成夾在 AI 編碼與另一個獨立 AI 審查工具之間的一層——那個工具是 Sonar 自家的，叫 Guitar，他只順帶一提，並說自己那週稍早主持過一場相關工作坊。

效率方面的說法建立在「重用」上：CI 流程本來就會跑 SonarQube 掃描，Vortex 重複利用那次掃描學到的東西，所以對單一檔案做快速檢查時，也帶著整個程式庫的知識。他說 Sonar 在這個領域做了將近二十年，一直是流程中的分析環節，而這些累積下來的智慧，就是交到代理手上的東西。

廠商的數字：Token 更省、事故更少、雜訊更低

Carlsen-Phelan 提出三項量化效益，全部是 Sonar 自家數字，演講中沒有任何獨立來源：

他也宣稱可跨代理通用——Claude Code、Codex、Antigravity，「你想用什麼都行」——並提供可設定的 MCP 使用者端，支援自製或開源代理。這款外掛建構在 Sonar 的 CLI 與 MCP 工具之上。

他最具策略性的一句話講的是槓桿：「除了模型選擇之外，代理從一開始就收到的引導脈絡，是你能為代理效能操縱的單一最大槓桿。」言下之意是：前期投資越多，後面的重做、修正與人工介入就越少。

「別誤會，我很愛 AI 審查……但 Sonar Vortex 是一層確定性的防線，疊在你的 AI 編碼之上，同時也夾在另一層 AI 審查之間。」

買方實際得到什麼，以及論證最薄弱的地方

Carlsen-Phelan 最後列出效益清單：來回審查變少、問題當場就修好、程式碼更安全、花在補救上的錢與時間更少，而且代理工作流程變得夠可信、可以自動化，開發者的時間也就釋放出來了。他請聽眾到攤位找他，並表示可以在場地後方回答問題。

尚未解決的張力在於：整個價值主張都取決於 Sonar 的規則集本身是對的。示篋中第二次退回——一個功能上安全的 Java 預設值，因為規則要求明確設定許可權而被拒絕——被包裝成嚴謹（「在安全這件事上我們不妥協」），但這同時也是工具以政策為由，否決了一個正確的修法。這究竟是紀律還是雜訊，正是那個「誤報率很低」的說法要回答的問題，而這個比率只是宣稱，並未展示。36% 與 44% 兩個數字同樣沒有方法論、沒有樣本、沒有基準。這段錄影真正獨立於 Sonar 數字之外所確立的東西比較窄，但仍然有用：一個現役代理在自行判斷下，交出了有許可權漏洞的程式碼，而且第一次補救還失敗——這證明自我驗證迴圈確實能抓到測試與隨手審查漏掉的真實缺陷。