# Maguyva 對 Rust 的支援：為 AI 協助的變更提供安全的情境

Canonical source: https://maguyva.ai/zh-hant/languages/rust

License: text under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/); code samples under [MIT-0](https://opensource.org/license/mit-0); the Maguyva name, logos, brand assets and other code are not covered. Details: [maguyva.ai/license](https://maguyva.ai/license).

Maguyva 透過 AST 剖析與符號擷取支援 Rust，讓 AI 代理在變更講求嚴謹、以安全為導向的程式碼之前，能穿梭於模組、impl 區塊、建構函式與依賴路徑之間。

## 支援概況

- 等級: AST 與符號支援
- 程式語言
- 副檔名: .rs
- 真正的 AST 剖析，支援語法感知搜尋與結構化情境。
- 具名符號支援語意查詢與交叉參照。啟用關係擷取後，即可使用圖譜導覽。
- 這個語言會為圖譜感知搜尋提供符號與關係；支援的邊類型會隨其原生構造而異。
- 同時支援 AST 剖析與符號擷取。

## 最適合的情境

- 因為正確性與變更安全性確實重要，而選用 Rust 的系統、平台或 CLI 儲存庫。
- 在編輯與所有權相關或低階邏輯之前，希望借助 AI 探索 Rust 程式碼庫的團隊。
- 模組、自動生成型別、巨集與周邊工具鏈交織，使得僅憑單一檔案推理變得不可靠的儲存庫。

## 代理工作流程

- 在變更其行為之前，先追蹤某個 struct 或元件於何處被建構。
- 比較模組模式與實作形式，而不是自創新的一套。
- 在要求代理重構某個型別或輔助函式之前，先找出依賴於它的路徑。

## 為什麼 Rust 的變更需要的不只是自動完成

Rust 正是最能清楚說明「AI 應該先導覽、再編輯」的案例之一。選用這門語言，通常是因為正確性真正重要，而不是因為團隊想要更多推測性的變更生成。因此「支援 Rust」的標準理應更高：代理能不能在提出重構之前，先理解模組邊界、impl 區塊、具體型別的建構方式，以及周邊情境？

這才是真正有價值的門檻，語法生成本身並不是重點。

## Maguyva 在 Rust 中實際擷取了什麼

Maguyva 會將 Rust 的函式與實作區塊，擷取為各自獨立的結構化概念，並將 struct 運算式視為真正的實例化。這讓圖譜能有效呈現具體型別在何處被建構，而不只是在何處被命名。

這份設定同時也過濾掉大量的巨集與標準函式庫雜訊，這在 Rust 中格外重要，因為巨集密集的程式碼，否則很容易讓圖譜淹沒在一堆技術上有效、卻無助於你理解儲存庫實際行為的呼叫之中。

## 對 Rust 儲存庫有用的 MCP 工作流程

最有效的起始模式是：

- 針對你即將變更的 struct、enum 或模組所屬函式，使用 `find_symbol`。
- 在重構一個核心型別之前，使用 `dependency_search`，先了解有哪些程式碼路徑依賴於它。
- 對於像「追蹤 HTTP client 周邊的重試邏輯」這類、路徑橫跨多個模組的概念性提示，使用 `get_task_context`。

## 這個頁面最適合的情境

如果你想在 Rust 中獲得 AI 協助、又不想放棄讓 Rust 值得使用的那套審慎工作流程，這個頁面適合你。如果儲存庫更偏向服務導向、而非系統程式設計導向，[Go](/zh-hant/languages/go) 會是更接近的比較對象。如果 Rust 只是更大型系統資產中的一部分，[技術堆疊頁面](/zh-hant/stack) 上的多語言全貌，會比單純的剖析器檢查清單更重要。

## 引擎細節

- `impl_item` 與 `function_item` 會被分別擷取，這有助於區分具體函式與實作區塊。
- 結構體運算式會被視為實例化，因此圖譜可以追蹤型別實際在哪裡被建構。
- 巨集與常見的標準函式庫建構子會被積極過濾，讓關係圖譜聚焦在儲存庫本身的程式碼上。

## 實用的 MCP 進入點

- `find_symbol`: 從你關心的結構體、列舉，或模組擁有的函式開始，再從那裡擴展。
- `dependency_search`: 在動核心型別或模組之前使用它，查看傳入的使用情況，而不只是本地參照。
- `get_task_context`: 當任務是概念性的，例如追蹤跨模組的重試邏輯或資源生命週期時很有用。