先講結論：程式碼分析唔應只追「最多人用」嘅節點

面對大型程式碼庫，AI 如果只按某個函數有幾多呼叫關係去排序，未必搵到真正重要嘅系統骨架。更穩陣嘅做法係先分清楚入口、裝配初始化、狀態編排、持久化邊界等角色，再喺角色之間安排證據讀取，最後先壓縮成可重用嘅知識包。

不過，呢個係一套建議中嘅設計，唔係已經驗收通過嘅修復。本輪只做咗只讀技術調查，冇改服務或閘道、冇跑測試或模型請求，亦未有重新驗收 13 個錨點。

現況同原先假設有落差

調查指出，現有場景 A 並非本地計算全圖入度、出度或中心度，再用度數貪心揀程式碼。佢會先預留呼叫者明確指定嘅必需靜態證據，再由模型導航候選定義，之後讀取證據並請模型壓縮。場景 B 嘅本地分數，則來自問題詞同路徑、限定名稱嘅匹配，唔係圖度數。

另一個重要限制係，提取器記錄到呼叫表達式，唔代表已經成功解析出呼叫目標。所以即使「7,000 多個 calls」呢個計數成立，都唔可以直接當成 7,000 條已確認嘅呼叫圖邊。

較明確嘅缺口包括：候選池目前以類別同函數定義為主，可能漏咗模組頂層嘅入口保護區塊、裝配或副作用；角色覆蓋亦未有本地選取契約。現有壓縮其實已經有共享來源列表，但重複嘅來源資料、關係資料同描述仍可能佔空間，係咪輸出超限主因就要實際量度。

三層各有工作，唔好混埋一齊

建議流程係：授權快照 → AST 同綁定索引 → 角色候選及靜態關係 → 強連通分量凝聚成 DAG → 揀骨架 → 擴展一跳證據 → 本地校核 → 可選文字壓縮 → 引用表壓縮 → 完整輸出幀檢查。

• DAG 用已確認嘅靜態關係整理依賴骨架同循環區域；佢唔係執行時間表，唔可以單憑呼叫拓撲話程式一定按某個生命周期順序運作。
• RAG 根據請求義務同骨架，揀可定位嘅完整語法證據；唔應由未解析嘅呼叫猜出下一跳。
• CAG 將已核校嘅事實、來源同未知項整理成穩定知識前綴，方便後續重用；但服務本身唔能夠保證供應商 KV 快取真係命中。

本地選取、來源校核同序列化應保持確定性。若保留模型壓縮，模型只可以改寫已選證據，唔應自行加來源、揀路徑或者將未證實內容升格成已知事實。

以角色分流，避免高頻節點霸晒名額

建議將候選分類為觸發入口、裝配初始化、狀態編排、持久化邊界、異常／資源邊界同輔助項目。分類要睇語法同可確認嘅綁定，例如入口保護區塊、構造及實例欄位裝配、已解析嘅跨組件呼叫、可綁定到讀寫介面嘅操作。

函數名或者檔案名可以做輔助訊號，但唔應單靠字眼就判斷重要性。反射、動態匯入、猴子補丁、含糊繼承分派等情況，應標示為未知，而唔係硬砌成確定關係。

呼叫圖本身可能有循環，所以建議先將強連通分量凝聚成 DAG，再做穩定拓撲排序。度數可用作同角色、同訊號級別內嘅輔助排序，但重複呼叫同一鄰居唔應重複加分；高入度輔助節點亦唔可以越過角色分流，搶走入口或持久化證據嘅骨架名額。

建議預算：限制正文，同時保留完整交付空間

設計草案建議最多選 32 個正文單元，正文合計不超過 96 KiB，並將名額分成骨架 16 個、上下文 12 個、邊界 4 個。上下文或輔助程式碼唔可以消耗骨架保留位；同一候選亦唔應重複計數。

語法單元應盡量係完整函數、方法、類或模組頂層語句。只讀到類別標頭，唔等於讀過類別內部方法；為咗湊數而截斷大型定義，再當成完整證據，亦唔可取。父子定義重疊時，要按實際讀取正文去重，唔可以靠增加來源別名假裝讀過更多內容。

輸出預算方面，24 KiB 即 24,576 bytes；22 KiB 即 22,528 bytes，兩者相差 2 KiB，唔係 2.5 KiB。如果目標係保留最少 2.5 KiB 空間，完整幀就應控制喺 22,016 bytes（21.5 KiB） 以內。計算時要包括 JSON-RPC 封裝、文字欄位內再轉義嘅內容，以及結尾換行；唔可以只量內層摘要。

13/13 覆蓋，暫時只係有條件嘅推論

要證明 13 個驗收錨點全部有正文覆蓋，至少要確認每個錨點都有合法完整證據組、選取策略真係會揀中佢哋、所需單元符合各條配額同 96 KiB 正文上限，而且完整輸出幀放得落預算。新來源類型亦要有相應校驗器，原有驗收要求唔可以因為改造而放寬。

如果 13 個錨點剛好各需要一個唔同嘅骨架單元，16 個骨架名額喺數目上容得落；但呢個推算唔代表本身每個錨點都只需一塊證據，更唔代表分類器一定會揀中佢哋。通用啟發式亦唔可能保證任何程式庫、任何隱藏測試都覆蓋齊全。

因此，現階段合理嘅承諾係：設計上避免高頻節點跨角色搶位、明確限制讀取量、保留未能確認嘅項目；至於本庫係咪真係 13/13，要靠之後獨立驗收。正文覆蓋亦唔等於語義正確，更唔等於真實宿主環境已通過測試。

快取效益同研究數字都要小心解讀

建議將穩定知識包同每次執行嘅請求 ID、時間、診斷等資訊分開，並以授權範圍、快照、演算法版本同策略版本組成快取鍵。來源或權限一有變，就要重新驗證或失效；亦唔應跨租戶或權限邊界共用。

CAG 研究摘要支持「預先載入外部知識，再重用 KV 快取」呢個概念，但唔足以證明本服務一定零延遲、減少特定比例費用，或者每次都命中快取。1 兩篇程式碼圖譜論文嘅題名及 arXiv 編號已核對：一篇比較 AST 衍生圖同 LLM 抽取知識圖譜，11 另一篇介紹以 Tree-sitter 建立程式碼知識圖譜。10 不過，現有資料未足以核實其他聲稱嘅效能倍數或覆蓋率數字，唔應當成本項目嘅效能承諾。

**總結：**呢份方案重點係將角色覆蓋、完整語法證據、預算門禁同來源可追溯性變成明確契約，而唔係單純換一個排序分數。實作、回歸測試、13/13 重驗、供應商快取驗證同真實宿主驗收，目前全部仍未完成。

先講結論：程式碼分析唔應只追「最多人用」嘅節點

面對大型程式碼庫，AI 如果只按某個函數有幾多呼叫關係去排序，未必搵到真正重要嘅系統骨架。更穩陣嘅做法係先分清楚入口、裝配初始化、狀態編排、持久化邊界等角色，再喺角色之間安排證據讀取，最後先壓縮成可重用嘅知識包。

不過，呢個係一套建議中嘅設計，唔係已經驗收通過嘅修復。本輪只做咗只讀技術調查，冇改服務或閘道、冇跑測試或模型請求，亦未有重新驗收 13 個錨點。

現況同原先假設有落差

調查指出，現有場景 A 並非本地計算全圖入度、出度或中心度，再用度數貪心揀程式碼。佢會先預留呼叫者明確指定嘅必需靜態證據，再由模型導航候選定義，之後讀取證據並請模型壓縮。場景 B 嘅本地分數，則來自問題詞同路徑、限定名稱嘅匹配，唔係圖度數。

另一個重要限制係，提取器記錄到呼叫表達式，唔代表已經成功解析出呼叫目標。所以即使「7,000 多個 calls」呢個計數成立，都唔可以直接當成 7,000 條已確認嘅呼叫圖邊。

較明確嘅缺口包括：候選池目前以類別同函數定義為主，可能漏咗模組頂層嘅入口保護區塊、裝配或副作用；角色覆蓋亦未有本地選取契約。現有壓縮其實已經有共享來源列表，但重複嘅來源資料、關係資料同描述仍可能佔空間，係咪輸出超限主因就要實際量度。

三層各有工作，唔好混埋一齊

建議流程係：授權快照 → AST 同綁定索引 → 角色候選及靜態關係 → 強連通分量凝聚成 DAG → 揀骨架 → 擴展一跳證據 → 本地校核 → 可選文字壓縮 → 引用表壓縮 → 完整輸出幀檢查。

• DAG 用已確認嘅靜態關係整理依賴骨架同循環區域；佢唔係執行時間表，唔可以單憑呼叫拓撲話程式一定按某個生命周期順序運作。
• RAG 根據請求義務同骨架，揀可定位嘅完整語法證據；唔應由未解析嘅呼叫猜出下一跳。
• CAG 將已核校嘅事實、來源同未知項整理成穩定知識前綴，方便後續重用；但服務本身唔能夠保證供應商 KV 快取真係命中。

本地選取、來源校核同序列化應保持確定性。若保留模型壓縮，模型只可以改寫已選證據，唔應自行加來源、揀路徑或者將未證實內容升格成已知事實。

以角色分流，避免高頻節點霸晒名額

建議將候選分類為觸發入口、裝配初始化、狀態編排、持久化邊界、異常／資源邊界同輔助項目。分類要睇語法同可確認嘅綁定，例如入口保護區塊、構造及實例欄位裝配、已解析嘅跨組件呼叫、可綁定到讀寫介面嘅操作。

函數名或者檔案名可以做輔助訊號，但唔應單靠字眼就判斷重要性。反射、動態匯入、猴子補丁、含糊繼承分派等情況，應標示為未知，而唔係硬砌成確定關係。

呼叫圖本身可能有循環，所以建議先將強連通分量凝聚成 DAG，再做穩定拓撲排序。度數可用作同角色、同訊號級別內嘅輔助排序，但重複呼叫同一鄰居唔應重複加分；高入度輔助節點亦唔可以越過角色分流，搶走入口或持久化證據嘅骨架名額。

建議預算：限制正文，同時保留完整交付空間

設計草案建議最多選 32 個正文單元，正文合計不超過 96 KiB，並將名額分成骨架 16 個、上下文 12 個、邊界 4 個。上下文或輔助程式碼唔可以消耗骨架保留位；同一候選亦唔應重複計數。

語法單元應盡量係完整函數、方法、類或模組頂層語句。只讀到類別標頭，唔等於讀過類別內部方法；為咗湊數而截斷大型定義，再當成完整證據，亦唔可取。父子定義重疊時，要按實際讀取正文去重，唔可以靠增加來源別名假裝讀過更多內容。

輸出預算方面，24 KiB 即 24,576 bytes；22 KiB 即 22,528 bytes，兩者相差 2 KiB，唔係 2.5 KiB。如果目標係保留最少 2.5 KiB 空間，完整幀就應控制喺 22,016 bytes（21.5 KiB） 以內。計算時要包括 JSON-RPC 封裝、文字欄位內再轉義嘅內容，以及結尾換行；唔可以只量內層摘要。

13/13 覆蓋，暫時只係有條件嘅推論

要證明 13 個驗收錨點全部有正文覆蓋，至少要確認每個錨點都有合法完整證據組、選取策略真係會揀中佢哋、所需單元符合各條配額同 96 KiB 正文上限，而且完整輸出幀放得落預算。新來源類型亦要有相應校驗器，原有驗收要求唔可以因為改造而放寬。

如果 13 個錨點剛好各需要一個唔同嘅骨架單元，16 個骨架名額喺數目上容得落；但呢個推算唔代表本身每個錨點都只需一塊證據，更唔代表分類器一定會揀中佢哋。通用啟發式亦唔可能保證任何程式庫、任何隱藏測試都覆蓋齊全。

因此，現階段合理嘅承諾係：設計上避免高頻節點跨角色搶位、明確限制讀取量、保留未能確認嘅項目；至於本庫係咪真係 13/13，要靠之後獨立驗收。正文覆蓋亦唔等於語義正確，更唔等於真實宿主環境已通過測試。

快取效益同研究數字都要小心解讀

建議將穩定知識包同每次執行嘅請求 ID、時間、診斷等資訊分開，並以授權範圍、快照、演算法版本同策略版本組成快取鍵。來源或權限一有變，就要重新驗證或失效；亦唔應跨租戶或權限邊界共用。

CAG 研究摘要支持「預先載入外部知識，再重用 KV 快取」呢個概念，但唔足以證明本服務一定零延遲、減少特定比例費用，或者每次都命中快取。1 兩篇程式碼圖譜論文嘅題名及 arXiv 編號已核對：一篇比較 AST 衍生圖同 LLM 抽取知識圖譜，11 另一篇介紹以 Tree-sitter 建立程式碼知識圖譜。10 不過，現有資料未足以核實其他聲稱嘅效能倍數或覆蓋率數字，唔應當成本項目嘅效能承諾。

**總結：**呢份方案重點係將角色覆蓋、完整語法證據、預算門禁同來源可追溯性變成明確契約，而唔係單純換一個排序分數。實作、回歸測試、13/13 重驗、供應商快取驗證同真實宿主驗收，目前全部仍未完成。