2026-10-17 · 實測評比 · services/ 範圍

Understand-Anything 是給人看的地圖，codegraph 是給 agent 查的索引

同一份 ai_family_backend（commit a6fb1d3e，只取 backend/src/services，232 個 TS 檔）。沿用 8 月報告的 grep 真值，再加上三個 8 月沒測過的維度：LLM 建出來的邊會不會捏造、重跑穩不穩、給新人看懂的效果。

建圖成本

兩邊都對同一份 232 檔建圖；UA 是正確設定那一輪的數字（第一輪設定錯誤作廢，見最後一段）。

CODEGRAPH · 冷啟索引
1.7 秒
0 LLM token · 3,405 節點 · 6,268 邊（calls 1,919 條）· 方法／函式層級
UNDERSTAND-ANYTHING · 建圖
≈156 萬 token
17 批 file-analyzer＋審查、分層、導覽，共 20 個 agent · 5 併發約 10 分鐘（agent 累計 26 分鐘）· 519 節點 · 1,061 邊（calls 208 條）· 以 class 層級為主

差距是 0 對 156 萬 token、1.7 秒對 10 分鐘。UA 的節點數少，是因為 file-analyzer 依「顯著性門檻」只為檔案、匯出的 class／函式建節點，class 方法幾乎不建。

分維度計分

各 0–10，由本次實驗執行者自評。不加總：兩個工具的圖顆粒度不同，總分沒有意義。

① 建圖成本
codegraph10
Understand-Anything3
確定性解析 vs 每 10–25 檔一個 LLM agent。
② 呼叫者完整性（方法層級問題）
codegraph10
Understand-Anything4
codegraph 2/2、5/5；UA 沒有方法節點，只能退到 class 層級回答，漏 1 個、多 2 個假陽性。
③ 邊的精確度（抽樣 30 條 calls）
codegraph10
Understand-Anything10
兩邊都 30/30，沒有捏造的邊。
④ 重現性
codegraph10
Understand-Anything6
UA 同一批重跑，calls 邊 Jaccard 0.79。
⑤ 給新人看懂（同一題流程解說）
codegraph8
Understand-Anything9
事實抽查兩邊都 10/10；UA 的分層＋導覽讓答案涵蓋面較廣。差距小，N=1。

關鍵證據 · 呼叫者完整性

真值在 a6fb1d3e 上用 grep 重建：每個呼叫點都找到外層函式。

外層函式（真值）形式codegraphUA（class 層級）
assertWithinQuota 的 caller · 真值 5
VitalsMeasurementService.uploadAndAnalyzeclass method✅❌ 有 import 邊、沒 calls 邊
VoiceCallWsGateway.handleConnection → onMessage巢狀 arrow fn✅（歸到 handleConnection）✅
VoiceCallService.startclass method✅✅
registerWebrtcConnectionHandler → onUserTurn巢狀 async fn✅（列為 onUserTurn）✅
VoiceCallWebrtcService.initclass method✅✅
CostModeService · CostStreamService呼叫的是 getUsage—（正確未列）⚠ 列為 QuotaService 的 caller（class 層級為真，方法層級是假陽性）
handleUserText 的 caller · 真值 2
onMessage（ws gateway）· onUserTurn（webrtc）兩個都是巢狀函式2/22/2（指向 VoiceCallSession class）
8 月的結論在這裡重現不出來8 月報告寫 codegraph「漏巢狀函式與 singleton 實例方法」（1/2、3/5）。這次用 CLI 1.4.1 查兩份索引：今天在 scratchpad 新建的，以及 7/18 建、原 repo 裡的舊索引副本。兩份都是 2/2、5/5；舊索引的範圍含 tests，連 tests 裡的 caller 都列了出來。8 月的差異從何而來，這次沒查到原因（可能是查詢方式或當時的 server 版本）。8 月那條「影響分析用 codebase-memory」的分工理由，至少對這兩個符號不成立。
介面 dispatch 仍是共同盲點handleUserText 的 5 個 callee 裡，transport.isOpen／sendJson 走介面型別。codegraph 這次範圍沒有 mock 可誤指，所以直接沒列（4 個 callee 裡也沒有它們）；UA 沒有方法節點，VoiceCallSession 也沒有任何指向 transport 的邊。兩邊都沒解出介面多型。

關鍵證據 · LLM 建的圖：不捏造，但會漏、會飄

精確度 · 抽 30 條 calls（seed 42）
30/30 · 30/30
UA 自動判定有 2 條要人工確認：一條經 barrel 匯入，一條放進陣列後經由介面呼叫。人工確認後兩條都是真的。
重現性 · voice-call 那批（17 檔）重跑
0.79
節點、imports、contains 完全相同（這部分由腳本產生）。calls 邊 33 vs 35 條，聯集 38 條裡有 8 條只出現在其中一次，例如 VoiceCallWsGateway → VoiceCallDurationService 只有第二次有。
漏邊型態
「少說」
漏掉的都是「有 import、有呼叫，LLM 沒寫成 calls 邊」，例如 Vitals → Quota。抽樣裡沒看到「憑空多出一條」。

關鍵證據 · 給新人看懂

題目：「解說一通語音通話從接通到結束的流程、使用者講話怎麼變成語音回覆、額度在哪裡檢查和扣」。兩個 subagent 各答一次：一個以 UA 的 knowledge-graph.json 當地圖，一個以 codegraph CLI 當地圖，兩邊都可以回頭讀原始碼。

以 UA 圖為主以 codegraph 為主
token／工具呼叫7.8 萬 · 10 次（圖查詢 3、讀原始碼 5）8.5 萬 · 7 次（codegraph 6、讀檔 1）
事實抽查（grep 驗證 10 條）10/10（含 3 條只靠節點摘要、沒回原始碼確認的）10/10（「sweepStale 在索引內無 caller」正確，真正的 caller 在範圍外的 worker/，它有註明）
選的路徑較新的 WebRTC 路徑，從導覽第 13–14 步切入舊的 WebSocket 路徑，從 explore 結果切入
強項涵蓋面廣：Call Center、KVS 通道池、STT 簡轉繁、兩種計量分開單一路徑更深：路由、狀態碼、token 格式、1006 斷線的結束時間判定
風險答案裡有 7 處標明「只來自圖摘要」，摘要錯了會直接寫進答案範圍外的呼叫者看不到，要靠答題者自己註明
答題成本相同，差別在建圖那筆錢兩邊答一題都花約 8 萬 token、品質相當。UA 的優勢（分層、導覽、每個檔案都有摘要）是用 156 萬 token 預先買來的。同一個 repo 會被很多人反覆問「這專案在幹嘛」時才划算；agent 自己改 code 時，codegraph 每次查詢的成本低得多，結果還是確定的。

踩到的坑 · 範圍設成子目錄會悄悄漏掉別名 import

第一輪我直接對 backend/src/services 跑，tsconfig.json 不在範圍內，@/ 路徑別名就解析不了。services 裡 997 個 import 用別名、只有 250 個是相對路徑，結果 import 邊只建出 128 條。file-analyzer 又被規定「只能依 import 資料建 calls 邊」，quotaService 這類跨檔呼叫就這樣被丟掉了。工具沒報錯，只有一個 agent 在回報裡提到。

改成專案根設為 backend/，用 exclude 只留 src/services/** 和 tsconfig 之後，import 邊回到 278 條。第一輪跑了 11 批、約 89 萬 token，全部作廢。

用法：UA 的範圍要包含 tsconfig（或其他路徑別名設定），縮小範圍用 --exclude，不要直接把子目錄當專案根。

怎麼選

AGENT 改 CODE · 影響分析
codegraph
方法層級、確定性、1.7 秒建完、每次查詢便宜。這次 caller 全中。
新人 ONBOARDING · 給人看全貌
Understand-Anything
分層、導覽、每檔摘要，適合反覆被問「這專案在幹嘛」的 repo。先算建圖成本：這次 232 檔約 156 萬 token。
不要
拿 UA 的圖回答「誰呼叫這個方法」。它是 class 層級的圖，LLM 推的邊會漏、重跑會變。

條件與限制

  • N=1：只有 voice-call 那一批重跑過一次（N=2），其他都只跑一次，不做統計顯著性宣稱。
  • 範圍只有 services/（232 個 TS 檔）。controllers、worker、tests 都不在範圍內，任何「範圍外的 caller」兩邊都看不到。
  • 顆粒度不同：codegraph 是方法層級，UA 是 class 層級，第 ② 維本質上是在拿 UA 回答它設計上不擅長的問題。
  • UA 管線是我手動編排的：照 /understand 2.9.7 的 SKILL.md 逐階段派 agent，但有三處偏離。
    • 批次參數放在檔案裡傳，沒有直接寫進 prompt。
    • 第二輪的 scan 步驟用它附的腳本直接組出來，沒有派 project-scanner agent。
    • 跳過 Phase 7 的 fingerprint。
    跟一鍵跑 /understand 的結果可能有差。
  • 版本：Understand-Anything 2.9.7；codegraph CLI 1.4.1（已有 1.6.2，未升級）。
  • 評分由本次實驗執行者自評；第 ⑤ 維只抽查 10 條事實，不是全文查證，兩份答案的品質差距在雜訊內。
  • 8 月結果重現不出來的原因未查證。