📊 軟體評測
Cody by Sourcegraph 評測 2026：精準理解全專案 Codebase 的 AI
在人工智慧（AI）輔助程式開發工具百花齊放的 2026 年，市面上有許多具備「程式碼自動補全」（Code Autocomplete）與「聊天式問答」（Chat）能力的工具。然而，多數工具仍停留在「片段級」的理解層次，無法真正掌握大型軟體專案的全貌。今天，雅寶社區・頂客論壇要為各位開發者與技術決策者們，帶來一篇關於 Cody by Sourcegraph 的深度評測。這是一款宣稱能「精準理解你整個 Codebase」的 AI 工具，我們將從架構原理、實測表現、優劣勢分析及價格方案等面向，全面檢視它是否能成為 2026 年開發者工具箱中的殺手級應用。
相信許多人聽過 Sourcegraph，它原本就是以「程式碼搜尋」（Code Search）與「程式碼智慧」（Code Intelligence）聞名的平台。而 Cody，正是 Sourcegraph 團隊基於多年的程式碼圖形（Graph）分析技術及語意索引（Semantic Indexing）所開發的 AI 助理。當大多數 AI 工具僅把程式碼檔案當作純文字餵給 LLM（大型語言模型）時，Cody 卻能透過 Sourcegraph 獨有的引擎，先理解專案中的檔案結構、資料流、函式呼叫鏈、型別定義與相依套件。
這個本質上的差異，讓 Cody 並不是單純的「文字接龍」工具，而是具備了 「專案級語境感知」 的智慧代理。它知道你的 User Struct 在哪裡、知道那段拿來處理登入的 Middleware 相依於哪個 SDK、也知道重構某個核心函式後會影響到哪些底層模組。這正是它在 2026 年眾多 AI 競品中脫穎而出的關鍵。
在我的實際測試中，Cody 的運作邏輯包含三個階段：索引（Indexing）、推理（Reasoning）、驗證（Verification）。首先，它會針對你的 Git Repository 建立完整的程式碼基底索引，此過程並不會將你的私有程式碼上傳至公開的模型訓練集；其次，當你提出問題或要求生成程式碼時，Cody 會在索引中提取所有相關的「定義碎片」與「關聯資訊」，構成一個龐大且精確的 Context Window；最後，它會透過多步驟的驗證機制，將生成的程式碼套用至你當前的編輯器環境中，並提供潛在的衝突提示。
這種方式解決了傳統 AI 助理最頭痛的 「幻覺」（Hallucination） 問題，因為它所有的回答都基於你專案內真實存在的類別、方法與欄位。舉例而言，當我要求它「新增一個取得使用者訂閱狀態的方法」，它不會擅自假設一個不存在的 ORM 欄位名稱，而是會自動尋找專案中的資料庫 Schema 檔案，並比對現有的 Repository Interface 來產生符合你專案慣例的程式碼。
本次評測使用了三個不同的開發環境：一個採用 Python Django 開發的電子商務平台（約 12 萬行程式碼）、一個使用 TypeScript 與 React 建構的中台系統（約 8 萬行），以及一個以 Go 語言撰寫的高效能底層服務（約 5 萬行）。Cody 在 VS Code 與 JetBrains IDE 中都展現了高度的穩定性。以下為幾項核心功能的實測心路歷程。
程式碼重構是最能考驗 AI 是否理解專案的指標。我對 Cody 下達了一個複雜指令：「請將使用者服務中所有直接操作 user_session 的地方，改用新的 CacheManager 抽象層。」這類任務在多數 AI 工具中往往會產生錯誤的匯入路徑，或誤用 API 簽名。
但 Cody 的表現令人驚豔。它首先準確地列出了所有在 service/use_cases/ 底下直接引用 user_session 的檔案，接著生成了符合現有 CacheManager 低階模組介面的呼叫語法。甚至連我們團隊內部自訂的錯誤處理包裝（Error Handler），它都能正確地引入並包裹。整個重構過程不需要我手動修改任何一行 import 陳述。
在文檔評分方面，Cody 生成的重構指令碼自動附帶了簡潔的 Docstring，內文參照了專案 README 中制定的命名規範。對於一個有程式碼審查（Code Review）文化的大型團隊來說，這節省了無數的溝通成本。
傳統的程式碼搜尋是「我知道我要找什麼」，而 AI 問答則是「我連要找什麼都不知道」。我向 Cody 提問：「這個系統的訂單流程中，當庫存不足時會觸發哪些事件？串連的 Event Bus 是否有支援延遲重試？」
Cody 的回覆不僅指出了負責庫存檢查的 inventory/domain/StockService.py，還進一步追蹤到了觸發的 order/events/OutOfStockEvent.py，並繪製出事件的傳遞路徑。有趣的是，它自動發現了該事件在 docker-compose 配置中的 consumer group 設定，判斷其屬於非同步消費且支援 3 次重試。這份回答的深度，已經超越了一位閱歷兩年的後端工程師手動追蹤的效率。
嚴格來說，Cody 在回應中還是保留了謹慎的語氣，它會明確標註「基於你 repository 中搜尋到的 pattern，此處推測為...」，讓開發者能保留最終的判斷權。
測試程式碼往往佔據一個專案 40% 以上的工作量。Cody 的 「學習測試資料庫並生成單元測試」 功能同樣表現出色。我請它為一個負責計算跨國匯率手續費的模組 generated Unit Tests，結果令人欣慰——它準確地從 Test Fixtures 中讀取了多組貨幣代碼（USD, JPY, EUR），並正確地應用了專案中處理浮點數的精確度策略（Decimal vs. Float）。
更難能可貴的是，Cody 生成的測試案例包含了 「邊界值測試」，它甚至發現了原始程式碼中對於匯率為零時可能導致的 ZeroDivisionError 漏洞，進而在測試中標記了這個 Edge Case。一個 AI 工具能主動確認測試的有效性，而不只是貪圖模組覆蓋率，這確實是它「精準理解 Codebase」的最佳注腳。
為何市場上其他工具無法做到同樣程度的精準？這必須從 Sourcegraph 的底層技術談起。絕大多數 AI 工具依賴的 RAG（檢索增強生成）架構，通常是將文件切分成 chunk 後對應到 Vector Database。然而這種方式在原始碼領域有一個致命缺陷：語義的碎片化。一個函式的意義，往往分散於它的型別定義、呼叫者意圖以及全域的相依關係中，單純的以文本分塊會撕裂這種脈絡。
Cody 使用了 Sourcegraph 獨有的 「SCIP 索引」（基於 LSP 的改良版）以及「程式碼導航圖」。這個導航圖包含了精確的符號層級（Symbol Level）關係。在執行 AI 推論前，Cody 會執行一個名為 GraphContext 的策略模式，它能在數百毫秒內，從圖中提取出與當前問題最相關的符號子圖（Subgraph），並將這些符號連同原始碼片段動態組合成一份「客製化的上下文」。
Cody 在 2026 年版的架構已進化為 「多模型路由」 機制。依據任務的類型（例如：意圖辨識、程式碼生成、測試知識、語意總結），它會自動分配給最適合的基礎模型。在某些情境下，它使用的是 Anthropic 最新的 Claude Sonnet 模型來處理複雜推理；在快速的補全場景中，它則會切換至更輕量的專用 Code Model，以保持低延遲。這種架構能同時兼顧 「回應速度」 與 「高品質生成」。
此外，企業版的 Cody 允許將模型部署於私有雲（VPC）中。這對於銀行、醫療等受監管行業無疑是一大誘因，確保所有程式碼索引與推論行為皆不離開企業的資安邊界。
為了客觀評價 Cody 在市場中的真實定位，我毫無保留地將它與當前兩大主流工具 GitHub Copilot 與 Cursor 進行了多維度的比較。以下是一份整理後的比較對照表，與我個人的詳細分析。