Unity-MCP：把 Unity 專案變成 AI 可操作的開發環境
AI Skills, MCP Tools, and CLI for Unity Engine. Full AI develop and test loop. Use cli for quick setup. Efficient token usage, advanced tools. Any C# method may be turned into a tool by a single line. Works with Claude Code, Gemini, Copilot, Cursor and any other absolutely for free.
秒懂
- 它是什麼？
- Unity-MCP 是一套把 Unity Editor 與 Runtime 接上 MCP 的工具組，讓 Claude、Cursor 等 AI 用戶端直接操作編輯器，甚至讓 AI 在遊戲執行時與玩家互動。本文檢視它的架構、安裝流程、自訂工具方式，以及它真正適用的場景。
- 適合誰用？
- Unity-MCP 適合想讓 AI 直接操作 Unity Editor 的開發者，尤其是需要快速把 C# 方法變成工具、並在遊戲執行時測試 AI 行為的團隊。不適合只想要靜態程式碼生成、不願意讓 AI 進入 Runtime 或需要完整官方支援的專案。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 2 天前。
- 用什麼語言寫的？
- 主要是 C#（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的不是程式碼生成，而是編輯器操作權
多數 AI 輔助 Unity 開發的工具只會吐出 C# 腳本，剩下的貼上、掛載、調整參數仍要人手處理。Unity-MCP 的定位不同，它透過 Model Context Protocol 讓 AI 用戶端直接操作 Unity Editor，包括建立物件、修改場景、執行測試。README 強調它同時支援 Editor 與 Runtime，後者代表 AI 能在編譯後的遊戲內運作，用於動態 NPC 行為或即時除錯。這對做遊戲原型或需要頻繁迭代的開發者來說，等於把 AI 從建議者變成操作者。但這也意味著你必須信任 AI 對專案的修改，因為它不再只是建議，而是直接執行。
架構拆解：MCP 伺服器、CLI 與 Unity 套件
專案由幾個層次組成。Unity 端有一個套件，負責在 Editor 內提供工具清單與執行環境。MCP 伺服器則作為橋樑，把 AI 用戶端的請求轉成 Unity 可執行的指令。傳輸方式支援 stdio 與 http，前者適合本機單一用戶端，後者允許遠端連線。CLI 名為 unity-mcp-cli，負責安裝套件到指定 Unity 專案，並處理登入流程。README 顯示安裝指令是 npm install -g unity-mcp-cli，接著用 unity-mcp-cli install-plugin ./MyUnityProject 把外掛裝進專案，最後用 unity-mcp-cli login 透過 OAuth device flow 登入 ai-game.dev。這表示除了本機工具，還有一個雲端帳號系統，登入後才能取得某些服務。
安裝流程：從 npm 到 Unity 專案
安裝路徑有兩種。一是直接下載 unitypackage 安裝檔，從 GitHub Releases 取得 AI-Game-Dev-Installer.unitypackage，手動匯入 Unity。二是用 CLI，步驟是全域安裝 unity-mcp-cli，然後在專案目錄執行 install-plugin。後者對自動化或團隊標準化較友善，因為指令可以寫進 CI 或交接文件。登入採用 OAuth device flow，會開啟瀏覽器驗證，這代表部分功能依賴遠端服務，不是完全離線。README 也提到 OpenUPM 套件 com.ivanmurzak.unity.mcp，表示可以透過 OpenUPM 管理版本更新。如果你偏好套件管理器，這條路比 CLI 更貼近 Unity 慣例。
把任何 C# 方法變成工具，一行搞定
專案最吸引人的設計是自訂工具機制。README 聲稱任何 C# 方法都能透過一行標記變成 MCP 工具。這代表你不必為每個功能寫 JSON schema 或手動註冊，只要在方法加上屬性，AI 就能呼叫它。這大幅降低擴充門檻，尤其當你的專案有獨特 API 或內部邏輯時，與其教 AI 讀懂整個程式碼庫，不如直接暴露方法當成工具。但這也帶來風險，方法一旦變成工具，AI 就有權執行它，沒有權限控管或沙箱隔離的設計，誤用可能造成場景損毀或資料遺失。文件沒有提到任何審核機制，這點需要你自己把關。
Runtime 模式是賣點，也是最大的包袱
多數 Unity AI 工具只在 Editor 內運作，Unity-MCP 卻宣稱支援 Runtime，也就是把 LLM 帶進編譯後的遊戲。這讓玩家能與 AI 驅動的 NPC 對話，或讓開發者在實際遊戲環境中除錯。但這代表遊戲執行時要連到 LLM 服務，延遲與成本都變成遊戲效能的一部分。README 沒有提供 token 用量或延遲數據，只說「efficient token usage」。另外，Runtime 模式需要處理網路連線、API key 管理與錯誤恢復，這些在 Editor 開發時不會出現。如果你的遊戲是單機離線發行，這個模式可能根本不適用。
語音與技能系統：讓 AI 更懂你的專案
專案提供 Skills 機制，能根據作業系統、Unity 版本與專案內的外掛生成技能描述。這相當於給 AI 一份專案環境的說明書，減少它猜測 API 或目錄結構的錯誤。另一個功能是自然對話，README 列出「Chat with AI like you would with a human」，暗示除了指令式工具呼叫，也支援多輪對話來完成複雜任務。這些設計都指向同一個目標：降低 AI 在陌生 Unity 專案中的試錯成本。但技能生成依賴專案當下的狀態，如果外掛或 Unity 版本更新，技能可能需要重新生成，文件沒有說明自動更新機制。
限制與錯誤使用情境
最大的限制是它綁定 Unity 生態，不適用其他遊戲引擎。其次是它需要網路與雲端帳號，即使本機 stdio 模式，登入流程仍要求連到 ai-game.dev，這對注重隱私或離線開發的團隊是障礙。另外，它把 AI 的權限擴大到 Editor 與 Runtime，若你的專案有大量自動化測試或嚴格的版本控制，AI 直接修改場景可能造成難以追蹤的變更。最後，Apache-2.0 授權允許商業使用，但你仍需注意 Unity 本身的授權條款，以及使用第三方 LLM API 時的資料傳輸合規性。
替代方案與實際差異
另一條路是使用 Unity 官方或社群開發的 AI 輔助工具，例如 GitHub Copilot 搭配 Unity 的 IntelliSense，但它們只做程式碼補全，不會操作 Editor。更接近的替代方案是 C# 腳本自動化工具，如 Unity Test Framework 搭配自訂編輯器腳本，讓 AI 透過執行測試來驗證變更，但這需要你手動寫測試，且 AI 無法直接操作場景。Unity-MCP 的差異在於它把 MCP 協定變成 Unity 的原生介面，讓任何支援 MCP 的用戶端都能用，而不是綁定特定 AI 廠商。如果你已經用 Claude Code 或 Cursor，這套工具能讓它們直接控制 Unity，省去中間的檔案交換與手動操作。
編輯結論
Unity-MCP 適合想讓 AI 直接操作 Unity Editor 的開發者，尤其是需要快速把 C# 方法變成工具、並在遊戲執行時測試 AI 行為的團隊。不適合只想要靜態程式碼生成、不願意讓 AI 進入 Runtime 或需要完整官方支援的專案。採用前應先確認你的 MCP 用戶端是否支援 stdio 或 http 傳輸，並檢查 Unity 版本相容性。最重要的是，Runtime 模式會把 LLM 呼叫帶入正式遊戲，這會影響效能與成本，務必先在小規模場景驗證延遲與 token 消耗。
社群筆記