用 Claude Code 與 Cursor 操作 Unity MCP:少手寫引擎裡的重複改動
透過 Model Context Protocol 將 Claude Code、Cursor、Codex 接到 Unity:安裝本地橋接、預覽與除錯場景,說明與僅改磁碟檔案的 AI 輔助有何不同。
- unity-mcp
- mcp-for-unity
- claude-unity-mcp
- unity-claude-code
- unity-ai
- claude-code
- cursor
- vberai
「AI 只往資料夾裡寫 C#」的上限
對話式程式設計很擅長產生腳本。只改磁碟檔案的 AI 輔助,仍然看不到活的編輯器狀態——目前場景、選中物體、預製體變體、Play 模式行為、Console 報錯。
如果模型只能看磁碟上的檔案,它會猜層級,卻點不了 Play、改不了 Hierarchy 裡的節點、也查不到 Missing Reference。團隊真正需要的是助手進入引擎循環,而不只停在倉庫裡。
Model Context Protocol(MCP) 是 AI 客戶端呼叫工具的一種標準方式。Unity MCP 透過本地橋接暴露編輯器能力,讓 Claude Code、Cursor、以及類似 Codex 的工作流程在 Unity 執行階段讀寫專案。
VberAI 提供 Unity MCP 插件作為這類橋接。本文走實用安裝與使用路徑,不做功能清單堆砌。
Unity MCP 改變日常的哪些事
| 沒有 MCP | 有 Unity MCP |
|---|---|
| 貼上產生腳本,再自己修編譯錯誤 | 讓客戶端建立腳本並掛到指定 GameObject |
| 手工複製 UI 面板 | 提示:「在 Canvas 下複製 Panel_Shop 並重新命名子節點」 |
| 在聊天裡口述 Console 報錯 | 在插件支援的範圍內讓客戶端讀取日誌 / 選中上下文 |
| 從 YAML 猜場景結構 | 先查 Hierarchy,再帶著確認去改 |
你仍要審查改動、看 Play 結果。省掉的是那些代理可以安全完成的重複點擊。
前置條件
- 已開啟的 Unity 專案(團隊協作建議 LTS)
- 支援 MCP 的客戶端:Claude Code、Cursor、Windsurf 等
- 本機可存取
127.0.0.1(橋接通常只跑在回環位址) - 對應 Unity 版本的 VberAI Unity MCP 套件(下載 / 文件)
可選:準備一個小場景(空 Canvas + 兩個按鈕),方便驗證首批提示。
安裝清單
1. 安裝 Unity MCP 插件
- 將套件匯入專案(或按團隊套件管理流程安裝)
- 啟用擴充 / 選單項目(不同建置名稱略有差異,常見為 MCP 或 AI Bridge)
- 如 Unity 提示,請重新載入編輯器
2. 啟動本地 MCP 橋接
打開插件面板並啟動服務,確認:
- 狀態為 執行中
- 主機為 localhost(不要把埠號暴露到公網)
- 專案路徑就是你要改的那個 Unity 專案
3. 在 AI 客戶端裡註冊服務
在 Cursor 或 Claude Code 中新增 MCP 服務,指向本地 Unity 橋接(stdio 或 HTTP/SSE,以插件目前文件為準)。
若工具清單未出現,重新啟動客戶端。應能看到與 Unity 相關的工具(讀取場景、節點操作等)。
4. 唯讀冒煙測試
提問:
列出目前活動場景的根層級 GameObject。
回覆若與 Hierarchy 一致,說明橋接正常。再嘗試寫入操作。
5. 小範圍寫入測試
提問:
在場景根下建立一個名為
MCP_SmokeTest的空物體。
在 Hierarchy 裡找到後刪除。大範圍重構前,優先做可逆試驗。
更好用的提示寫法
先結構
列出
Canvas/HUD的子節點,並說明哪些是 LayoutGroup。
寫入要聚焦
在
Canvas/Menu下把Button重新命名為Btn_Start,並把 TMP 文字設為開始。
除錯閉環
我按下 Play 後,彙總與
PlayerController相關的 Console 錯誤,並給最小修復建議。
配合已匯入的 UI
若畫面來自 AI Studio,可用 MCP 接 onClick、統一命名與 C# 慣例——不必手拆預製體重新搭建。
安全習慣
- 橋接僅保留在 localhost
- 習慣「讀取 → 規劃 → 寫入」,避免一條提示「重做整款遊戲」
- 大改前先提交版本
- 不要把金鑰寫進提示;MCP 不能取代權限管理
- 把 Play 模式與資源重新整理當作人工檢查點
MCP 減少手動點引擎,不取消程式碼審查。
和市面上的 Unity AI 能力怎麼比
廠商內建助手與第三方 Unity MCP 插件目標常有重疊。用同一套問題評估:
- 能否看到即時 Hierarchy / 選中物件?
- 改動是否可逆、可稽核?
- 能否接入團隊已在用的客戶端(Claude Code、Cursor 等)?
當團隊已在這些客戶端裡工作時,Unity MCP 的價值最大;同一習慣也能延伸到 Godot / Cocos 的 MCP。
常見問題
還要不要寫 C#?
要。MCP 擅長編輯器操作與腳手架。玩法系統、網路與效能仍需要工程師。
Claude Code 和 Cursor 選哪個?
只要支援 MCP 並指向同一本地 Unity 服務即可。選倉庫已在用的客戶端;橋接是共享部分。
是不是只適合 UI?
不是。層級、元件、場景操作同樣適用於玩法物體。UI 只是最好驗證的第一課。
有沒有影片教學?
可參考 Unity 引擎 MCP 插件影片指南。
下一步
- 在臨時場景安裝 Unity MCP
- 連接 Claude Code 或 Cursor,通過唯讀冒煙測試
- 自動化一件你討厭的雜務(批次重新命名、複製面板、掛腳本)
若瓶頸在設計稿到預製體,而不是編輯器操作,可搭配 Figma → Unity 的 AI Studio 流程。
繼續閱讀
你可能還會喜歡這些文章
Figma 到 Unity UI:用 VberAI AI Studio 從設計稿到預製體
將 Figma 設計導入 Unity UI 層級:在 VberAI AI Studio 中導入、以自然語言微調後導出預製體,並說明與 Figma MCP、Unity MCP 的分工。
- figma-to-unity
- figma-to-code
- figma-ai
- figma-design
Godot MCP vs 手寫腳本:什麼時候該讓 AI 操控編輯器
對照 Godot 場景組織與信號規範,說明 VberAI Godot MCP 適合加速原型與樣板,以及何時應堅持手寫 GDScript。
- godot-mcp
- vberai
- comparison
- GDScript
2026 的 AI 遊戲開發:用 Unity / Godot MCP 留在編輯器閉環裡
梳理 AI 輔助 Unity、Godot 的工作流程:MCP 適合什麼、人要守住什麼,以及多引擎團隊如何共用同一套提示習慣。
- ai-game-development
- unity-game-development
- godot-game-engine
- unity-mcp