核心建議：先顧架構角色，再談排序

這份設計的出發點，是讓程式碼分析服務在有限輸出預算內，優先保留入口、初始化、狀態編排與持久化等架構線索，再以有限度的語法證據補足上下文，最後整理成可重用的知識包。

不過，調查結果修正了一個重要前提：目前程式碼並非已證實採用全域入度或中心度排序。場景 A 會先預留呼叫者指定的必需靜態證據，再將定義候選交給模型導航；場景 B 的本地分數來自問題文字與路徑、限定名稱的匹配，不是圖度數。提取器記錄呼叫表達式，但呼叫目標仍可能是未知，因此即使「7000 多次呼叫」的計數成立，也不能直接視為同等數量的已解析呼叫邊。

這是一份只讀技術設計：沒有修改服務、參考專案或閘道，也沒有執行測試、驗收或模型請求。文中將已核對的現況、建議做法與仍待實測的目標分開處理。

先釐清目前流程的限制

已核對的結構性缺口包括：

• 候選集合包含類別與函式定義，但不包含模組頂層執行語句；頂層裝配、註冊或主程式保護區塊可能因此不會進入正文候選池。
• 必需證據的預留限於明確指定的靜態選擇器。語意推斷維度仍仰賴模型導航，缺少本地的生命周期覆蓋約束。
• 正文讀取會檢查完整定義與預算，卻沒有角色配額、元件公平性或一跳（1-Hop）證據展開機制。
• 現有壓縮已使用共享來源清單，因此不能簡單說每項結論都重複嵌入完整路徑。來源中繼資料、關係記錄和診斷資訊是否才是主要成本，仍須分項量測。

另有一項版本差異尚待追查：目前場景 A 的程式碼會在讀取前將候選聯集限制在 32 個，並以新建讀取器執行一次讀取。僅憑這段現況，無法解釋舊回執所述的「讀滿 32 塊後又有 7 塊遭預算拒絕」；需要把歷史回執、候選清單與程式版本逐一對上。

三層分工：DAG、RAG 與 CAG 各做各的事

建議流程是：授權範圍內的快照 → AST 與繫結索引 → 角色候選及靜態關係 → 強連通分量凝聚成 DAG → 骨架選取 → 一跳證據 → 本地事實校核 → 可選文字壓縮 → 共享引用表 → 完整封包檢查。

• DAG 層整理已消歧的靜態關係、依賴骨架與循環區域。呼叫拓撲不等於程式實際的執行時間順序。
• RAG 層依照請求義務、骨架與合法語法單元選取證據，受區塊數及正文位元組上限約束。相鄰程式碼不會自動證明任意語意結論。
• CAG 層把已校核的事實、來源與未知項整理成穩定、緊湊、可重用的知識前綴。服務能產生穩定前綴，不代表它能控制供應商的 KV 快取，也不代表快取必定命中。

分類、選塊、來源校核與序列化應由本地程式確定性處理。若保留既有模型壓縮，模型只能改寫已選證據，不能增選路徑、增加證據、改動必需義務或提高證據等級。

以角色隔離骨架，避免輔助程式碼搶位

角色辨識應依據語法結構與可確認的繫結，而非特定專案檔名或全域度數。可辨識的角色包括：

• 觸發入口：主程式保護區塊、獲授權的宣告式入口或可辨識的處理器註冊。註冊語句本身不證明宿主已啟用該處理器。
• 裝配初始化：建構器、工廠、元件建立及儲存到實例欄位等訊號。建構器名稱只是候選線索，不足以證明其重要性。
• 狀態編排：呼叫多個已解析元件、跨呼叫傳遞值，或持有與修改狀態、控制處理階段的程式碼。只有迴圈或字典賦值，不足以判定為核心編排。
• 持久化邊界：可繫結到讀寫介面的呼叫、資源取得與釋放、序列化及提交位置。辨識出 I/O 語法，也不代表能證明執行時成功寫入資料。
• 異常邊界：與主流程相關的例外處理、清理、輸入拒絕及限額處理；優先附在已選主幹旁，不泛選整個程式庫。
• 輔助程式碼：其餘候選或證據不足者，不應只因度數高就取得受保護的骨架名額。

繫結解析也要保守：只有在作用域、導入別名與重新繫結狀況足以支持時，才把呼叫列為已解析關係。動態匯入、反射、複雜別名或不明確的繼承分派應保留為未知；名稱剛好相同，並不足以證明是同一個目標。

呼叫圖本身可能有循環，不能直接稱為 DAG。建議先將強連通分量凝聚成元件，再對凝聚後的無環圖穩定排序，並保留分量內的循環資訊。這表示的是靜態依賴偏序，不是「先載入、再執行、最後提交」的執行時保證。

度數只適合作為同角色、同訊號等級內的輔助排序。重複呼叫同一目標不應增加不同鄰居數，中心度也應飽和，避免高度連結節點無限制拉高分數。候選排序應先看必需證據、未覆蓋角色與元件，再看結構訊號、跨元件關係、輔助中心度及穩定的路徑順序。

配額與證據展開：上限固定，缺口如實回報

建議把總量限制為最多 32 個程式碼區塊、正文合計最多 96 KiB，並分成三條互不搶位的選取管道：骨架最多 16 塊、上下文最多 12 塊、異常與資源邊界最多 4 塊。上下文或輔助程式碼不能挪用骨架保留名額；同一候選只占一個名額。

骨架選取先放入必需證據組，再輪流補齊尚未涵蓋的角色與元件。必需證據若超過配額，應回報阻塞或未讀，不能暗中降低要求、借用其他管道或把缺口改成「不適用」。有界的貪心調度也不是完備的可行性求解器：它找不到方案時，只能說本次選取未完成，不能逕自證明在預算內不存在任何可行方案。

上下文展開只從固定的骨架出發做一跳，不因新讀到的程式碼繼續遞迴擴張成第二跳。每個檔案最多增加兩個可選上下文區塊；必要骨架或必需證據不受此可選擴展限制。未解析呼叫可以列出其語法表達式，但不得沿著猜測的目標擴展。

可選取的證據單元應保留完整語法範圍，例如函式或方法及其裝飾器、模組頂層完整語句，以及必要時的完整複合語句。類別標頭不等於完整類別，不能拿來證明尚未讀取的方法內容。父類別與子方法範圍重疊時，必須先計算替代後的總成本，不能重複計算或用整個模組包裝成單一區塊來規避限制。

輸出預算要以完整封包計算

24 KiB 等於 24,576 位元組，22 KiB 等於 22,528 位元組，兩者相差 2,048 位元組，不是 2.5 KiB。若希望保留至少 2.5 KiB 餘裕，常態完整封包就應控制在 **22,016 位元組（21.5 KiB）**以內。建議採用這個較嚴格的目標，同時確保最終輸出不超過呼叫者預算或 24,576 位元組硬上限。

計算對象必須是完整 JSON-RPC 封包，包含外層文字欄位的二次跳脫與結尾換行，不能只量內層摘要。每次加入事實時，也須一起加入它所需的引用資料；所有引用都要指向本地已讀取、且身分經過核對的來源。若最小必要封包超出預算，應明確回報「知識包未交付」，不能回傳看似完整、實際缺項的結果。

知識包可以把檔案表、來源表與事實／關係表分開，讓多個事實共用同一來源，減少重複路徑與範圍資料。不過，共享表本身也有固定成本，實際能否縮小封包仍須量測，不能預先承諾特定壓縮比例。

穩定前綴不等於 KV 快取已命中

快取友善的設計，是讓同一份快照產生穩定、可重用的知識前綴，再於其後附加本輪問題。前綴不應混入隨機請求 ID、時間戳或每輪診斷資訊。快取鍵則應涵蓋專案授權、快照、範圍、解析器與演算法版本、策略版本及影響輸出的請求契約；來源、授權或策略改變時必須失效，不能跨租戶或權限邊界共用。

研究文獻所描述的 CAG 概念包括預先載入外部知識，以供後續重用 KV 快取；這只能支持「預載與重用」這個概念，不能證明本服務的提示一定命中快取，或一定降低延遲與費用。1 供應商的快取路由、保留時間、命中窗口及實際快取 Token 指標，仍須由消費端與供應商回執驗證。

另有兩篇相關研究可作為背景：Codebase-Memory 探討透過 Tree-sitter 建立程式碼知識圖譜供 LLM 探索；Reliable Graph-RAG for Codebases 比較 AST 衍生圖與由 LLM 擷取的知識圖譜。1011 但就目前提供的資料，無法核實「30 至 60 倍、45 倍、95.5%、零遺漏或 Token 減少 10 至 20 倍」等數字所對應的實驗設計、資料集及衡量方式，因此不應把它們當成本服務的效能承諾。

13 項全數涵蓋，仍須通過條件檢查

若 13 項驗收錨點各自都有合法、完整的證據組，證據都在授權快照內，選取配額與 96 KiB 正文預算足以容納，必需來源能放進完整封包，且來源未變、沒有超時或跳過必要項，才有條件讓正文覆蓋達到 13/13。假設每項錨點剛好需要一個不同的骨架區塊，13 個區塊確實低於建議的 16 塊上限；但這個算術不證明實際每個錨點都只需要一塊，也不證明分類器一定會選到它們。

更一般地說，有限配額下的啟發式不可能保證涵蓋任意隱藏測試：同一角色、同一元件中可能有大量相似候選，而被選漏的任一項都可能是獨立錨點；部分動態行為也無法單靠 AST 證明。因此，能承諾的是避免高入度輔助程式碼跨角色擠占骨架、遵守預算並揭露證據缺口。特定專案是否達到 13/13，仍須由獨立驗收確認。正文覆蓋也不等於語意審查通過，更不等於真實宿主環境驗收成功。

180 秒時限也必須涵蓋交付

180 秒應從入口取得同一個絕對截止時間，套用到掃描、拓撲整理、選塊、可選壓縮、來源複核、儲存、封包及傳送。建議最晚在第 165 秒停止新增分析或等待模型，保留最後 15 秒處理複核與交付。若只量模型階段或部分耗時，不能據此證明整個流程都在時限內。

週期性檢查只能提供協作式中斷，不代表可以強制終止所有阻塞操作。若要求進程層級的硬截止，須在後續實作中另行設計可受控、可終止的子程序及其輸入、輸出與背壓限制；逾時或清理未確認時不得記為成功。對不讀取輸出或無法回應的客戶端，也不能保證成功送達，只能確保不把逾時誤報為通過。

目前狀態與後續驗收

本輪完成的是只讀調查與技術規格，尚未實作或回歸。13 項錨點的來源映射、每項證據的預算成本及選取理由尚未獨立核對；場景 A 也未重新驗收。下一步若獲准實施，至少要測試重複呼叫不搶占骨架、同名遮蔽與別名不誤建關係、頂層語句及完整語法範圍、非 ASCII 與二次跳脫下的封包臨界值、必需證據超限時的失敗處理，以及快照或授權改變後的快取失效。

場景 B 原有的定向查詢、12 KiB 上限、證據等級與取消行為，也須確認沒有因場景 A 改造而退化。凍結答案只能用於生成後的獨立驗收，不應交給選取器作為偷看答案的依據。

因此，這份方案提出的是可檢驗的選取、證據與封包不變條件，不是已完成的修復報告：測試、重新驗收、供應商快取驗證及真實宿主驗收目前都尚未進行。

核心建議：先顧架構角色，再談排序

這份設計的出發點，是讓程式碼分析服務在有限輸出預算內，優先保留入口、初始化、狀態編排與持久化等架構線索，再以有限度的語法證據補足上下文，最後整理成可重用的知識包。

不過，調查結果修正了一個重要前提：目前程式碼並非已證實採用全域入度或中心度排序。場景 A 會先預留呼叫者指定的必需靜態證據，再將定義候選交給模型導航；場景 B 的本地分數來自問題文字與路徑、限定名稱的匹配，不是圖度數。提取器記錄呼叫表達式，但呼叫目標仍可能是未知，因此即使「7000 多次呼叫」的計數成立，也不能直接視為同等數量的已解析呼叫邊。

這是一份只讀技術設計：沒有修改服務、參考專案或閘道，也沒有執行測試、驗收或模型請求。文中將已核對的現況、建議做法與仍待實測的目標分開處理。

先釐清目前流程的限制

已核對的結構性缺口包括：

• 候選集合包含類別與函式定義，但不包含模組頂層執行語句；頂層裝配、註冊或主程式保護區塊可能因此不會進入正文候選池。
• 必需證據的預留限於明確指定的靜態選擇器。語意推斷維度仍仰賴模型導航，缺少本地的生命周期覆蓋約束。
• 正文讀取會檢查完整定義與預算，卻沒有角色配額、元件公平性或一跳（1-Hop）證據展開機制。
• 現有壓縮已使用共享來源清單，因此不能簡單說每項結論都重複嵌入完整路徑。來源中繼資料、關係記錄和診斷資訊是否才是主要成本，仍須分項量測。

另有一項版本差異尚待追查：目前場景 A 的程式碼會在讀取前將候選聯集限制在 32 個，並以新建讀取器執行一次讀取。僅憑這段現況，無法解釋舊回執所述的「讀滿 32 塊後又有 7 塊遭預算拒絕」；需要把歷史回執、候選清單與程式版本逐一對上。

三層分工：DAG、RAG 與 CAG 各做各的事

建議流程是：授權範圍內的快照 → AST 與繫結索引 → 角色候選及靜態關係 → 強連通分量凝聚成 DAG → 骨架選取 → 一跳證據 → 本地事實校核 → 可選文字壓縮 → 共享引用表 → 完整封包檢查。

• DAG 層整理已消歧的靜態關係、依賴骨架與循環區域。呼叫拓撲不等於程式實際的執行時間順序。
• RAG 層依照請求義務、骨架與合法語法單元選取證據，受區塊數及正文位元組上限約束。相鄰程式碼不會自動證明任意語意結論。
• CAG 層把已校核的事實、來源與未知項整理成穩定、緊湊、可重用的知識前綴。服務能產生穩定前綴，不代表它能控制供應商的 KV 快取，也不代表快取必定命中。

分類、選塊、來源校核與序列化應由本地程式確定性處理。若保留既有模型壓縮，模型只能改寫已選證據，不能增選路徑、增加證據、改動必需義務或提高證據等級。

以角色隔離骨架，避免輔助程式碼搶位

角色辨識應依據語法結構與可確認的繫結，而非特定專案檔名或全域度數。可辨識的角色包括：

• 觸發入口：主程式保護區塊、獲授權的宣告式入口或可辨識的處理器註冊。註冊語句本身不證明宿主已啟用該處理器。
• 裝配初始化：建構器、工廠、元件建立及儲存到實例欄位等訊號。建構器名稱只是候選線索，不足以證明其重要性。
• 狀態編排：呼叫多個已解析元件、跨呼叫傳遞值，或持有與修改狀態、控制處理階段的程式碼。只有迴圈或字典賦值，不足以判定為核心編排。
• 持久化邊界：可繫結到讀寫介面的呼叫、資源取得與釋放、序列化及提交位置。辨識出 I/O 語法，也不代表能證明執行時成功寫入資料。
• 異常邊界：與主流程相關的例外處理、清理、輸入拒絕及限額處理；優先附在已選主幹旁，不泛選整個程式庫。
• 輔助程式碼：其餘候選或證據不足者，不應只因度數高就取得受保護的骨架名額。

繫結解析也要保守：只有在作用域、導入別名與重新繫結狀況足以支持時，才把呼叫列為已解析關係。動態匯入、反射、複雜別名或不明確的繼承分派應保留為未知；名稱剛好相同，並不足以證明是同一個目標。

呼叫圖本身可能有循環，不能直接稱為 DAG。建議先將強連通分量凝聚成元件，再對凝聚後的無環圖穩定排序，並保留分量內的循環資訊。這表示的是靜態依賴偏序，不是「先載入、再執行、最後提交」的執行時保證。

度數只適合作為同角色、同訊號等級內的輔助排序。重複呼叫同一目標不應增加不同鄰居數，中心度也應飽和，避免高度連結節點無限制拉高分數。候選排序應先看必需證據、未覆蓋角色與元件，再看結構訊號、跨元件關係、輔助中心度及穩定的路徑順序。

配額與證據展開：上限固定，缺口如實回報

建議把總量限制為最多 32 個程式碼區塊、正文合計最多 96 KiB，並分成三條互不搶位的選取管道：骨架最多 16 塊、上下文最多 12 塊、異常與資源邊界最多 4 塊。上下文或輔助程式碼不能挪用骨架保留名額；同一候選只占一個名額。

骨架選取先放入必需證據組，再輪流補齊尚未涵蓋的角色與元件。必需證據若超過配額，應回報阻塞或未讀，不能暗中降低要求、借用其他管道或把缺口改成「不適用」。有界的貪心調度也不是完備的可行性求解器：它找不到方案時，只能說本次選取未完成，不能逕自證明在預算內不存在任何可行方案。

上下文展開只從固定的骨架出發做一跳，不因新讀到的程式碼繼續遞迴擴張成第二跳。每個檔案最多增加兩個可選上下文區塊；必要骨架或必需證據不受此可選擴展限制。未解析呼叫可以列出其語法表達式，但不得沿著猜測的目標擴展。

可選取的證據單元應保留完整語法範圍，例如函式或方法及其裝飾器、模組頂層完整語句，以及必要時的完整複合語句。類別標頭不等於完整類別，不能拿來證明尚未讀取的方法內容。父類別與子方法範圍重疊時，必須先計算替代後的總成本，不能重複計算或用整個模組包裝成單一區塊來規避限制。

輸出預算要以完整封包計算

24 KiB 等於 24,576 位元組，22 KiB 等於 22,528 位元組，兩者相差 2,048 位元組，不是 2.5 KiB。若希望保留至少 2.5 KiB 餘裕，常態完整封包就應控制在 **22,016 位元組（21.5 KiB）**以內。建議採用這個較嚴格的目標，同時確保最終輸出不超過呼叫者預算或 24,576 位元組硬上限。

計算對象必須是完整 JSON-RPC 封包，包含外層文字欄位的二次跳脫與結尾換行，不能只量內層摘要。每次加入事實時，也須一起加入它所需的引用資料；所有引用都要指向本地已讀取、且身分經過核對的來源。若最小必要封包超出預算，應明確回報「知識包未交付」，不能回傳看似完整、實際缺項的結果。

知識包可以把檔案表、來源表與事實／關係表分開，讓多個事實共用同一來源，減少重複路徑與範圍資料。不過，共享表本身也有固定成本，實際能否縮小封包仍須量測，不能預先承諾特定壓縮比例。

穩定前綴不等於 KV 快取已命中

快取友善的設計，是讓同一份快照產生穩定、可重用的知識前綴，再於其後附加本輪問題。前綴不應混入隨機請求 ID、時間戳或每輪診斷資訊。快取鍵則應涵蓋專案授權、快照、範圍、解析器與演算法版本、策略版本及影響輸出的請求契約；來源、授權或策略改變時必須失效，不能跨租戶或權限邊界共用。

研究文獻所描述的 CAG 概念包括預先載入外部知識，以供後續重用 KV 快取；這只能支持「預載與重用」這個概念，不能證明本服務的提示一定命中快取，或一定降低延遲與費用。1 供應商的快取路由、保留時間、命中窗口及實際快取 Token 指標，仍須由消費端與供應商回執驗證。

另有兩篇相關研究可作為背景：Codebase-Memory 探討透過 Tree-sitter 建立程式碼知識圖譜供 LLM 探索；Reliable Graph-RAG for Codebases 比較 AST 衍生圖與由 LLM 擷取的知識圖譜。1011 但就目前提供的資料，無法核實「30 至 60 倍、45 倍、95.5%、零遺漏或 Token 減少 10 至 20 倍」等數字所對應的實驗設計、資料集及衡量方式，因此不應把它們當成本服務的效能承諾。

13 項全數涵蓋，仍須通過條件檢查

若 13 項驗收錨點各自都有合法、完整的證據組，證據都在授權快照內，選取配額與 96 KiB 正文預算足以容納，必需來源能放進完整封包，且來源未變、沒有超時或跳過必要項，才有條件讓正文覆蓋達到 13/13。假設每項錨點剛好需要一個不同的骨架區塊，13 個區塊確實低於建議的 16 塊上限；但這個算術不證明實際每個錨點都只需要一塊，也不證明分類器一定會選到它們。

更一般地說，有限配額下的啟發式不可能保證涵蓋任意隱藏測試：同一角色、同一元件中可能有大量相似候選，而被選漏的任一項都可能是獨立錨點；部分動態行為也無法單靠 AST 證明。因此，能承諾的是避免高入度輔助程式碼跨角色擠占骨架、遵守預算並揭露證據缺口。特定專案是否達到 13/13，仍須由獨立驗收確認。正文覆蓋也不等於語意審查通過，更不等於真實宿主環境驗收成功。

180 秒時限也必須涵蓋交付

180 秒應從入口取得同一個絕對截止時間，套用到掃描、拓撲整理、選塊、可選壓縮、來源複核、儲存、封包及傳送。建議最晚在第 165 秒停止新增分析或等待模型，保留最後 15 秒處理複核與交付。若只量模型階段或部分耗時，不能據此證明整個流程都在時限內。

週期性檢查只能提供協作式中斷，不代表可以強制終止所有阻塞操作。若要求進程層級的硬截止，須在後續實作中另行設計可受控、可終止的子程序及其輸入、輸出與背壓限制；逾時或清理未確認時不得記為成功。對不讀取輸出或無法回應的客戶端，也不能保證成功送達，只能確保不把逾時誤報為通過。

目前狀態與後續驗收

本輪完成的是只讀調查與技術規格，尚未實作或回歸。13 項錨點的來源映射、每項證據的預算成本及選取理由尚未獨立核對；場景 A 也未重新驗收。下一步若獲准實施，至少要測試重複呼叫不搶占骨架、同名遮蔽與別名不誤建關係、頂層語句及完整語法範圍、非 ASCII 與二次跳脫下的封包臨界值、必需證據超限時的失敗處理，以及快照或授權改變後的快取失效。

場景 B 原有的定向查詢、12 KiB 上限、證據等級與取消行為，也須確認沒有因場景 A 改造而退化。凍結答案只能用於生成後的獨立驗收，不應交給選取器作為偷看答案的依據。

因此，這份方案提出的是可檢驗的選取、證據與封包不變條件，不是已完成的修復報告：測試、重新驗收、供應商快取驗證及真實宿主驗收目前都尚未進行。