混合執行環境程式語言
Maguyva 對 JavaScript 的支援：為混合執行環境儲存庫打造的 AI 搜尋
當儲存庫混雜了 CommonJS、ESM、工作腳本、測試與較舊的應用程式碼時，這特別有用。
完整圖譜支援AST 解析符號擷取
副檔名
.cjs, .js, .mjs, .spec.js, 還有 2 個
開啟指南
為什麼 TypeScript 頁面很重要
TypeScript 正是許多團隊期待 AI 協助重構終於能讓人放心的語言。型別系統確實有幫助，但它並沒有解決真正的問題：共用套件、DTO、自動生成的 client、React 元件、測試與應用程式碼，全都在一個大型儲存庫中拉扯著同樣的名稱。
對 TypeScript 而言，標準要比「它理解語法」高得多。代理人需要在編輯一個共用型別、hook 或 client 之前，一路追蹤合約，從定義到實作，再到影響範圍。
Maguyva 在 TypeScript 中實際擷取了什麼
Maguyva 會橫跨 .ts、.mts、.cts，以及測試與 story 檔案周邊常見的 TypeScript 檔案變體，擷取類別、方法、介面與型別別名。成員前綴會被正規化，但類別限定的識別碼會被保留下來 — 這在一個儲存庫同時存在裸露的輔助函式名稱，以及最終片段相同的類別範圍方法時，特別有幫助。
JSX 會被視為真正的結構訊號，而不是零散的標記，符號預期也會明確跳過大量的測試、story 與設定路徑。這在 Monorepo 中格外重要，否則代理人會把太多時間花在重新發現鷹架程式碼上，而不是真正的實作內容。
對 TypeScript 儲存庫有用的 MCP 工作流程
通常三種起始模式就已足夠：
- 當你已知介面、型別別名、hook 或 service 名稱時，使用
find_symbol。 - 在變更可能橫跨多個套件的共用型別或 client 之前，使用
dependency_search。 - 當你需要的是程式碼形狀、而不是關鍵字比對時 — 例如重複出現的元件或方法模式 — 使用
structural_search。
對於像「追蹤結帳送出流程」這類概念性問題，get_task_context 通常會是比原始搜尋更好的第一步。
這個頁面最適合的情境
這個頁面最適合 TypeScript 作為多個套件協調層的 Web 與平台 Monorepo。如果你的儲存庫仍包含大量較舊的 JS，可以參閱 JavaScript 指南。如果你真正想問的是「代理人能不能同時掌握應用程式碼與基礎架構情境？」，可以將這個頁面與 Terraform 搭配閱讀。
最適合的情境
- >在單一 TypeScript 儲存庫中運行 Next.js、Node 服務、共用套件與工具鏈的產品與平台團隊。
- >介面、DTO、schema 與 React 元件彼此連動、卻分散在不同目錄中的儲存庫。
- >在讓 AI 代理人動手處理共用型別或套件邊界之前，努力為其提供安全情境的團隊。
代理工作流程
- >追蹤一個型別、介面或元件，從其定義一路追到實際使用它的程式碼路徑。
- >在變更一個共用輔助函式或 API 合約之前，先比較各套件間的實作方式。
- >繪製出編輯某個共用型別、工具函式或服務模組時，可能造成的影響範圍。
引擎細節
- >TypeScript 會擷取類別、方法、介面與型別別名，而不是把所有東西都攤平成通用符號。
- >成員前綴會被移除，但類別限定的識別碼會被保留，這有助於區分 `CheckoutService.create` 與單獨的 `create`。
- >JSX 元素會被視為實例化，而測試、story 與設定檔路徑，則會在符號預期中被明確跳過，以減少雜訊。
實用的 MCP 進入點
find_symbol
當你知道要檢查的共用介面、型別別名、hook 或服務時，從這裡開始。
dependency_search
在變更共用的 DTO 或用戶端之前使用，取得跨套件的真實影響範圍。
structural_search
當你需要的是模式，而不是字串比對時，使用 AST 層級的搜尋，例如重複出現的元件或方法結構。