企業級深度 程式語言
Maguyva 對 Java 的支援：企業級儲存庫的程式碼智慧
當儲存庫充滿 Spring 服務、內部框架，以及歷經數個組織世代仍存活下來的程式碼時，這特別有用。
AST 與符號支援 AST 解析 符號擷取 圖譜關係
副檔名
.java
開啟指南
Groovy 讓淺層 AI 工具栽跟頭的地方
Groovy 讀起來常常像設定檔。在 Gradle 建置裡，dependencies { implementation ... } 是一串帶閉包的方法呼叫，宣告式 Jenkinsfile 也是如此。建構器把任意名字變成呼叫，GDK 又給每個物件加上 each、collect 這樣的方法。記錄每一個呼叫的工具會被這些雜訊淹沒。
Maguyva 過濾掉 DSL 和 GDK 這一層，讓你自己的方法和類別凸顯出來。
Maguyva 在 Groovy 中擷取什麼
Maguyva 支援 .groovy 和 .gradle 檔案以及 Jenkinsfile。類別、函式和方法都會被擷取，匯入會正規化 import static 和 as 別名。呼叫名會去掉末尾的閉包塊和 ?. 安全導航運算子，因此 repo?.save(order) { ... } 會記錄為對 save 的呼叫。類別內部不帶接收者的呼叫會解析到該類別自己的方法。
雜訊會分層過濾：
- 約 140 個標準函式庫、Gradle 和 Spock 名稱，如
dependencies、implementation、task、given、when、then和Mock。 - 約 260 個 GDK 方法，如
each、collect、inject和eachLine。 - 建構器 DSL 名稱，包括
pipeline、stage、steps和sh等 Jenkins 步驟，在以建構器風格使用、而不是帶括號呼叫時會被過濾。 @CompileStatic、@Immutable和@Autowired等 AST 轉換註解和框架註解，它們永遠不會被記錄為呼叫。
圖譜還會記錄繼承、實例化和讀寫。
代理提示範例
- 「誰呼叫了
deployToStaging，來自哪些管線？」（先用find_symbol，再用dependency_search的 incoming 方向） - 「哪些類別繼承了
BaseIntegrationSpec？」（dependency_search） - 「解釋發布任務如何建置並發布成品。」（
get_task_context）
已知限制
- Groovy 的方法和自由函式共用同一種語法節點，因此
structural_search中的methods預設集什麼也選不到。請改用functions預設集或find_symbol。 - 與 GDK 或 DSL 方法同名的使用者方法（如
collect或stage）可能會被一併過濾。如果某個呼叫端似乎缺失，請使用text_pattern_search。
下一步
透過快速入門連接儲存庫，然後在相容性頁面檢視支援矩陣。建置所編譯的 JVM 程式碼請閱讀 Java 指南和 Kotlin 指南。
最適合的情境
- > 用 Groovy 編寫、共享建置邏輯分散在大量 `.gradle` 檔案中的 Gradle 建置。
- > 代理在修改 CI 之前需要讀懂的 Jenkins 管線和共享函式庫。
- > 執行在 JVM 上的 Groovy 應用和 Spock 測試套件。
代理工作流程
- > 在修改共享函式庫步驟的參數之前，找到它的所有呼叫端。
- > 追蹤哪些建置腳本呼叫了公共 `.gradle` 檔案中定義的輔助函式。
- > 在重構之前，梳理哪些類別繼承了某個基底類別。
引擎細節
- > Groovy 支援涵蓋 `.groovy`、`.gradle` 和 `Jenkinsfile`。呼叫名會去掉閉包塊和 `?.` 安全導航。
- > 約 140 個標準函式庫、Gradle 和 Spock 名稱，以及約 260 個 GDK 方法，會從關係中過濾掉。
- > 建構器 DSL 名稱（包括 `stage` 和 `sh` 等 Jenkins 步驟）在建構器風格下會被過濾，註解永遠不會被記錄為呼叫。
實用的 MCP 進入點
- find_symbol
需要共享函式庫步驟、建置輔助函式或類別的定義和呼叫端時使用它。
- dependency_search
對建置輔助函式使用 incoming 方向走訪，檢視哪些腳本和管線呼叫了它。
- text_pattern_search
用於查詢 DSL 呼叫和 GDK 方法，這些呼叫已從圖譜中過濾掉。