2026-10-18 · 跨 repo 實測 · TS backend ↔ Go 服務

四個工具，跨 repo 自動連上的都是 0 條

codebase-memory、codegraph、GitNexus、graphify 四個工具，放在一組真實的 TS ↔ Go 服務上測（兩邊都用量測當時工作分支的 HEAD，完整範圍）。兩邊之間有 75 個 HTTP 端點、1 條 gRPC。沒有任何工具自動接上任何一條。5 題跨 repo 實戰題，四個工具組和只用 grep 的基線幾乎都答對，跨 repo 的銜接全靠 grep。工具真正有差的地方在 repo 內：那裡 codegraph 1.6.2 明顯領先。

真值：兩個 repo 之間到底有哪些串接

HTTP
75
個端點（其中 2 個是 SSE），呼叫點分布在 12 個 client 檔。Go 服務的 v1 路由共 130 條，backend 用了其中 75 條。
gRPC
1
條 server-stream。backend 在執行期用 protoLoader 載入一份手抄的 proto，沒有 TS stub。
反向呼叫／共用基礎設施
0
Go 服務不會回呼 backend，也沒有共用 DB、Redis、queue。
順便查到的合約漂移
2 類
SSE 事件：Go 端會送、TS 端沒處理的有 7 種。DTO：某個回應的型別有 4 處不一致。細節不公開。

跨 repo 自動連結

工具跨 repo 連結HTTP /75gRPC /1Go 服務 route → handler /130為什麼
codebase-memory（只建索引）0000一般索引不會產生跨 repo 連結。
codebase-memory（加跑 cross-repo pass）136000136 條全錯：來源全是 Go 服務的測試、scripts、web，目標是 backend 的 benchmark 假 handler（91 條）、泛用路由（44 條）或 middleware（1 條）。Go 1.22 的 mux.Handle("POST /path") 被丟棄（解析器要求路徑以 / 開頭），router 產生 0 個 Route。backend 只認得樣板字串 URL（50/75），純字串的一律漏掉；邊上沒有 README 說的 confidence。
codegraph 1.4.1—0053沒有跨 repo 功能。route → handler 有 77 條連到同名方法，包括測試替身。
GitNexus group20002 條都錯（一條其實在 backend 內部，一條方向相反）。Go 服務的 HTTP provider 數是 0，推測是因為認不得 Go 1.22 的寫法（沒有讀它的原始碼確認）。手寫 manifest 宣告了 75 條，但兩端都對不到程式碼符號；gRPC 解到產生出來的 stub。
graphify merge0000兩張圖之間 0 條直接邊，只有 10 個同時連到兩邊的外部節點（標準函式庫和幾個未解析的參照）。
文件寫「支援跨服務連結」不等於支援你的寫法codebase-memory 和 GitNexus 都宣稱能配對 HTTP 路由和呼叫點，但兩者在 Go 服務端都抽不出路由。codebase-memory 已從原始碼確認是認不得 Go 1.22 把 HTTP 方法寫在路徑字串裡的寫法，GitNexus 推測是同一個原因；codebase-memory 也認不得 this.client.post("/path") 這種純字串加父類別 baseURL 的寫法。導入前要拿自己的 code 跑一次。

5 題跨 repo 實戰題 · 5 個分組

題目：proto 欄位改名的兩邊影響、worker → Go 服務應用層的正向追蹤、回傳格式改變的反向影響、列出全部 75 個端點、找出 SSE 事件和 DTO 的合約漂移。每組 1 個 agent，依真值表評分。

分組Q1（6）Q2（7）Q3（10）Q4（75）Q5a（7）Q5b（4）錯token工具呼叫
只用 grep671075741162,41449
codegraph671075741155,35153
GitNexus671075741177,57666
graphify671075740154,96659
codebase-memory671075541200,62871

repo 內呼叫圖 · TS type checker 當真值

新 HEAD 的 backend service 層，4,495 個呼叫與 new 運算式（召回分母 4,126），跨檔 1,395 個。嚴格判定：目標必須是 type checker 解析到的那個宣告。

工具跨檔召回default singleton（894）具名 const 實例（68）跨檔精確度主要錯誤
codegraph 1.4.191%96%0%64%同名退化、只連到接收者常數
codegraph 1.6.297%95%100%81%範圍外 repository／第三方函式庫的同名猜測
codebase-memory25%4%0%83%漏抓：匯入的 singleton 幾乎沒有 CALLS 邊
GitNexus34%0%100%97%漏 default singleton；介面 dispatch 會連到所有實作
graphify22%0%0%98%漏所有成員呼叫；少數同名錯連

團隊導入前要知道的事（codebase-memory 補充）

  • 受測的是 7 月 5 日從 main 自己編譯的 dev build（v0.8.1 之後的開發版），之後已發布 14 個 release（含 2 個 pre-release），而且沒有官方簽章。
  • 「不傳遙測、不連外」不實：這個 build 每次 MCP 初始化都會連 GitHub 檢查最新版本，沒辦法關（上游已移除）。
  • UI 在 127.0.0.1:9749 監聽，沒有驗證，也沒有檢查 Host header（上游已補上）。它開放 RPC、刪除專案等操作，理論上有 DNS rebinding 風險（讀碼推論）。
  • 跨 repo 要另外手動跑 cross-repo pass，只在同一個 cache 有效，重新索引就會被清掉。
  • 其他三個工具的導入事項（授權、會寫進開發機的東西、遙測、共享方式）見 10-17 的四方報告與工具卡。

怎麼選

repo 內導航
codegraph 1.6.2：召回率和精確度都最好。常見方法名的 caller 只當候選，要用 grep 篩。Go 的 route → handler 不要信它，直接讀 router。
跨 repo
不靠工具。用腳本從兩邊程式碼產生一份「呼叫點 → 路由 → handler」的合約表，在 CI 雙向檢查，SSE 事件名稱也一起比對；再讓 agent 先查表。
codebase-memory
等它支援 Go 1.22 路由和純字串 URL，再用簽章過的 release 重評。
GitNexus／graphify
GitNexus 授權非商用，TS 召回率低；graphify 只有文件也要進圖時才考慮。

條件與限制

  • 只測一組 repo：命名規律、URL 多寫成字面值，對 grep 有利。換成動態組 URL 或端點更多的系統，結論可能不同。
  • N=1：5 題每組只答一次，由主線依真值自評。真值在實驗中修正過兩次。
  • 版本：
    • codebase-memory：7 月 5 日的 dev build，最新 release 沒測。
    • codegraph：1.4.1；1.6.2 只測過 repo 內的 TS 和小型重現。
    • GitNexus：1.6.12，--index-only，沒有 embedding 和 MCP 工具。
    • graphify：0.9.92，--code-only。
  • codebase-memory 組作答時，同一個 store 正在跑 cross-repo pass：那組回報「沒有 CROSS 邊」，應該是在 pass 之前查的。pass 產生的連結全錯，不影響結論。
  • 這份取代 10-17 的跨 repo 報告（受測工具不同、用舊 commit，已下架）。最後由獨立的對抗式驗證逐條核對。