在大型軟體工程組織中，系統極少僅依賴單一隔離的儲存庫運作。微服務透過分散式 RPC 介面緊密通訊，前端應用程式依賴跨專案定義的版本化 API 協定，而核心業務流程往往架構在運作多年的遺留單體（Legacy Monolith）之上。當研發團隊試圖運用常見的 AI 程式碼助理來維護、重構或調查這些架構時，經常面臨結構性限制：多數工具僅能讀取本機目前開啟的檔案或單一工作區目錄，對跨儲存庫的共用函式庫、下游依賴服務以及散落在其他專案中的歷史實作邏輯一無所知。
Sourcegraph Cody 透過將 AI 上下文檢索與本機編輯器工作區解耦化，徹底克服了這項瓶頸。奠基於 Sourcegraph 的集中式程式碼智慧平台，Cody 能在 GitHub、GitLab、Bitbucket 或企業內部 Git 伺服器所代管的數百至數千個儲存庫之間，即時檢索關聯上下文。
本文將完整解析工程團隊如何為 Sourcegraph Cody 配置多儲存庫上下文（Multi-Repository Context）、系統管理員如何建置全域程式碼索引與權限防護，以及開發者如何利用這項能力釐清複雜的跨專案遺留邏輯，並在組織級程式碼庫中進行精準的自然語言搜尋。
1. 架構核心：多儲存庫上下文的運作機制
不同於僅仰賴本機客戶端提取或單一專案向量資料庫的輔助工具，Cody 的多儲存庫上下文檢索是建構在集中式基礎架構之上的：
┌─────────────────────────────────────────────────────────────┐
│ 開發者 IDE │
│ (VS Code / JetBrains / Visual Studio / Cody Web) │
│ - 上下文標籤：目前檔案 + 釘選的遠端儲存庫 (最多 10 個) │
│ - 精細化 @ 提及 (@repo, @dir, @file, @symbol) │
└──────────────────────────────┬──────────────────────────────┘
│ HTTPS / 存取權杖 (Access Token)
▼
┌─────────────────────────────────────────────────────────────┐
│ Sourcegraph Enterprise 執行個體 │
│ (雲端代管或企業內部部署) │
│ │
│ ┌─────────────────────────┐ ┌─────────────────────────┐ │
│ │ 搜尋引擎 │ │ 程式碼圖譜 │ │
│ │ (Zoekt Trigram 索引) │ │ (SCIP 語意索引圖譜) │ │
│ └─────────────────────────┘ └─────────────────────────┘ │
│ ┌─────────────────────────┐ ┌─────────────────────────┐ │
│ │ 上下文篩選器 │ │ 權限與身分同步 │ │
│ │ (排除特定敏感儲存庫) │ │ (GitHub/GitLab RBAC) │ │
│ └─────────────────────────┘ └─────────────────────────┘ │
└──────────────────────────────┬──────────────────────────────┘
│ 提示詞 + 精準程式碼片段
▼
┌─────────────────────────────────────────────────────────────┐
│ LLM 模型提供商 (Cody Gateway) │
│ (Claude 3.7 / 3.5 Sonnet, GPT-4o 等模型) │
└─────────────────────────────────────────────────────────────┘
- 集中化程式碼索引：Sourcegraph 透過 Zoekt（高效能三元組文字索引）與 SCIP（Source Code Intelligence Protocol）索引器，針對所有連線的代管平台進行索引，在全組織維度建立涵蓋符號定義、呼叫位置與繼承關係的語意圖譜。
- 權限感知檢索機制：Cody 完全尊重版本控制系統原生的權限邊界。當工程師發出提問時，系統只會檢索該工程師帳號具備合法讀取權限的儲存庫，杜絕資料越權洩漏。
- 精準上下文注入：Cody 不會將龐大的遠端儲存庫原始碼全數塞入大語言模型的 Prompt（這會瞬間耗盡 Token 限制並削弱模型的專注力），而是透過 Sourcegraph Search API 抽取最相關的符號宣告、實作片段與介面定義。
多儲存庫上下文是 Cody Enterprise（企業版，包含雲端代管與內部部署）專屬的核心能力；Cody Free 與 Pro 版本則主要局限於本機單一儲存庫。
2. 基礎設施與系統管理員設定
啟用多儲存庫上下文的第一步是在 Sourcegraph 企業執行個體（Instance）上完成全域設定。站台管理員必須確保程式碼代管服務順暢同步、索引正常建置，並啟用 Cody Enterprise。
步驟 1：連結程式碼代管平台並同步儲存庫
登入 Sourcegraph 管理後台，前往 Site Admin > Code Hosts（/site-admin/external-services），設定與公司版本控制服務（例如 GitHub Enterprise、GitLab Self-Managed 或 Bitbucket Data Center）的連線。
設定規則以確保關鍵微服務、共用套件庫與歷史遺留系統皆納入同步清單：
{
"url": "https://github.com",
"token": "ghp_yourEnterpriseSyncToken",
"orgs": ["engineering-core", "legacy-platforms", "shared-libraries"]
}
檢查後台複製與排程同步作業是否正常運作，確認無連線阻斷或權杖失效錯誤。
步驟 2：設定程式碼圖譜（Code Graph）與自動索引
程式碼複製完成後，Zoekt 文字搜尋便可即時生效。但若要準確解構複雜的跨儲存庫遺留業務邏輯，精準的語意導航（跨專案尋找定義與關聯引用）至關重要：
- 在 Site Admin > Code Navigation 中啟用自動索引（Auto-indexing）。
- 對於核心程式語言（Go、TypeScript/JavaScript、Java、Python、C++ 等），可在 CI/CD 流水線（如 GitHub Actions、GitLab CI）中整合對應的 SCIP 索引工具（如
scip-typescript、scip-java或scip-python），生成索引檔並上傳至 Sourcegraph 執行個體。 - 完整的 SCIP 語意數據可讓 Cody 在解析跨儲存庫架構時，依據精確的抽象介面與呼叫鏈推導，而非模糊猜測。
步驟 3：在站台全域設定中啟用 Cody
前往 Site Admin > Site Configuration（/site-admin/configuration），加入以下設定區塊：
{
"cody.enabled": true,
"completions": {
"provider": "sourcegraph"
}
}
選擇適合長上下文推理的大語言模型（例如透過 Cody Gateway 支援的 Anthropic Claude 3.5 Sonnet、Claude 3.7 Sonnet，或 Azure OpenAI GPT-4o）。確認站台設定中未殘留限制存取的 cody.restrictUsersFeatureFlag。
步驟 4：設定上下文篩選器（Context Filters）隔離敏感資料
許多企業擁有包含金流 PCI 規範資料、憑證金庫或機密演算法的特定儲存庫，這些專案不應被 AI 讀取為上下文。
管理員可透過 Context Filters（cody.contextFilters）在全域排除特定儲存庫：
{
"cody.contextFilters": {
"exclude": [
{ "repo": "github.com/company/pci-vault-service" },
{ "repo": "github.com/company/compliance-secrets-.*" }
]
}
}
3. 開發者用戶端環境配置（VS Code、JetBrains 與 Web）
伺服器端環境就緒後，工程團隊即可在本機整合開發環境中進行簡易連線設定。
步驟 1：安裝並登入 IDE 擴充套件
- 在 VS Code、JetBrains 系列工具（IntelliJ IDEA、PyCharm、GoLand、WebStorm）或 Visual Studio 中搜尋並安裝官方 Cody 套件。
- 點擊側邊欄 Cody 圖示，選擇 Sign In with Sourcegraph Enterprise。
- 輸入企業專屬的 Sourcegraph 伺服器網址：
https://sourcegraph.internal.company.com - 完成企業瀏覽器單一登入（SSO），或貼上從個人帳戶設定產生的存取權杖（Access Token）。
步驟 2：對齊本地儲存庫識別碼（cody.codebase）
通常情況下，Cody 能自動偵測本機 Git 的 remote origin 網址，並與 Sourcegraph 上的儲存庫路徑自動匹配。
若本機目錄名稱有所調整，或使用了特製的 Submodule 結構，可在專案工作區設定（.vscode/settings.json）中明確指定儲存庫名稱：
{
"cody.codebase": "github.com/organization/core-payment-service"
}
步驟 3：在對話視窗中靈活調度多儲存庫上下文
在開啟 Cody Chat 時，輸入視窗上方會顯示預設上下文標籤：
- 目前編輯中的檔案
- 本地開啟的專案儲存庫
開發者可以透過以下方式主動擴充跨專案上下文：
- 上下文管理列（Context Chips）：點擊輸入框上方的標籤列，可搜尋並釘選最多 10 個遠端儲存庫到目前對話中。釘選後，該會話中的每一次提問都會自動跨越這些指定的程式碼庫進行檢索。
- 精確的
@語法標記：@repo/organization/legacy-billing-monolith：導入特定的遺留計費單體儲存庫。@dir/organization/auth-service/pkg/middleware：聚焦於特定相依專案的子目錄或中介軟體模組。@file/organization/proto-contracts/v2/payment.proto：無需在本機 clone 專案，直接讀取外部契約結構。@symbol：引用已在組織全域程式碼中索引的類別、介面或函式名稱。
- Cody Web 介面：如果工程師處於架構調研階段，無需打開肥大的本地開發環境，可直接登入 Sourcegraph Web 平台，點擊導航列上的 Cody 圖示，針對全公司所有已索引的儲存庫進行高層次架構諮詢。
4. 實戰指引：運用跨儲存庫上下文梳理複雜遺留系統
遺留系統通常面臨原開發者離職、文件遺失或嚴重落後現狀、商業邏輯隱含於多個分散式服務中的痛點。以下展示工程團隊如何藉由 Cody 多儲存庫上下文破解遺留程式碼迷宮：
情境 A：追蹤跨服務的分散式呼叫路徑
調查現代前端結帳服務與十年前的舊版計費單體系統之間，偶發性的訂單通知遺失問題：
在本機開啟現代化 checkout-service，在 Cody Chat 中輸入：
提問範例：
@checkout-service @legacy-billing-monolith @event-bus-contracts「請追蹤由結帳服務發出的OrderSubmittedEvent事件是如何在遺留計費單體系統中被接收與處理的？會更新哪些資料庫資料表？在哪些邊界或例外邏輯下會略過帳戶扣款程序？」
Cody 的底層處理邏輯：
- 分析
@event-bus-contracts中宣告的事件欄位與型別。 - 在
@legacy-billing-monolith中搜尋訂閱該主題的佇列監聽器（Queue Consumer）或事件處理函式。 - 追蹤遺留交易管理類別中的 SQL 更新語法與預存程序呼叫。
- 找出導致扣款被略過的隱藏規則（例如遺留系統中針對特定舊版通路商 ID 的硬編碼白名單判斷）。
情境 B：解讀無文件記載的複雜商業演算法
遺留程式碼常包含充滿特殊公式且毫無註解的狀態機與計費邏輯：
提問範例：
@core-monolith/src/main/resources/rules/pricing_engine_v1.rb@pricing-integration-tests「請解析calculate_tiered_rebate函式的狀態機流轉與邊界處理邏輯。比對@pricing-integration-tests儲存庫中的歷史整合測試案例，說明為何跨越季度臨界值時會觸發負向調差邏輯？」
Cody 能將生產原始碼與歷史整合測試的斷言資料相互印證，將晦澀的條件分支轉換為易讀的領域邏輯規格說明書。
情境 C：服務廢棄與介面遷移影響面評估
在準備停用底層舊版 RPC 介面或資料庫結構前：
提問範例：
@user-profile-service @notification-service @reporting-worker「我們預計廢棄@user-profile-service中的GetUserPreferencesV1介面。請分析目前釘選的相依服務中，哪些模組呼叫了此介面、實際讀取了哪些欄位，並列出遷移至GetUserPreferencesV2所需的詳細程式碼修改清單。」
Cody 能跨儲存庫掃描所有呼叫端客戶端，釐清實際消費的欄位，為各個下游服務提供精準的遷移範例程式碼。
5. 組織級程式碼庫的智慧搜尋與典範探索
傳統搜尋方式要求工程師具備對關鍵字、目錄命名或正規表示式（Regex）的先備知識。Cody 將自然語言對話與 Sourcegraph 的全文搜尋引擎相結合，顯著降低了全組織資產探索的門檻。
挖掘內部權威實作典範
團隊擴充迅速時，各小組常無意間重複造輪子，各自撰寫重複的 Redis 快取包裝、HTTP 重試或權杖更新邏輯：
提問範例： 「在我們公司的 Go 語言微服務架構中，大家通常如何使用 Redis 實作分散式限流（Rate Limiting）？請找出全公司內部最通用、經過驗證的標準共用套件或參考實作。」
Cody 自動搜尋跨部門的微服務，比對各模組的引用關係，推薦公認的內部基礎套件（如 pkg/ratelimit），並展示符合公司慣例的呼叫程式碼。
稽核資安模式與過期加密做法
在執行全面性架構治理或安全合規稽核時：
提問範例：
@payment-service @auth-service @mobile-api-gateway「這幾個服務是如何設定 JWT 權杖驗證的？是否存在跳過簽章檢查的漏洞，或仍在使用未經金鑰輪轉保護的過期演算法（例如缺乏校驗機制的 RS256 實作）？」
Cody 快速統整各服務的中介軟體配置，直接指出不同專案之間的安全落差與脆弱點。
6. 最佳實踐、潛在陷阱與維運建議
為了在多儲存庫架構下維持最佳的回應精確度與速度，建議團隊採行以下作業原則：
| 最佳實踐 | 運作考量 |
|---|---|
| 單一對話維持 2–5 個核心關聯儲存庫 | 雖然 Cody 支援釘選最多 10 個儲存庫，但納入過多無關專案會引進雜訊，稀釋大模型的專注度並拉長回應延遲。 |
針對合約檔案善用精確的 @file 或 @dir 標記 | 明確指定規格定義檔案（如 .proto、OpenAPI YAML、GraphQL Schema），能強制模型以最高權威的介面協定作為邏輯推導基準。 |
| 維持 SCIP 語意索引的週期性更新 | 文字搜尋僅能做到字串比對，而 SCIP 語意索引才能確保跨專案定義跳轉的絕對精確。建議將 SCIP 產生作業整合進核心函式庫的 CI 流水線中。 |
| 提問前確認上下文標籤 | 發起重大架構提問前，先檢視並清除對話框上方暫存的無關檔案標籤，避免非預期內容干擾推論。 |
| 將 Cody 架構規劃與 Batch Changes 緊密結合 | 透過 Cody Chat 全盤理解遺留架構並規劃遷移細節，隨後運用 Sourcegraph Batch Changes 自動化產生跨數十個儲存庫的批量修復與拉取請求（PR/MR）。 |
結語
配置 Sourcegraph Cody 的多儲存庫上下文，使 AI 輔助開發從單純的「本機編輯器自動補全」躍升為具備全域視野的「企業級軟體智慧中樞」。透過版本控制平台的集中同步、高精準度的語意程式碼圖譜以及嚴格的身分存取控管，工程團隊得以打破資訊孤島，自信且安全地駕馭錯綜複雜的遺留系統，並推動跨組織的高效軟體演進。