這兩年做游戲開發(fā)工具鏈有個(gè)詞繞不過去MCP。Model Context Protocol模型上下文協(xié)議簡單說就是給大模型裝了一雙能“操作編輯器”的手。過去我們讓AI寫代碼是讓它把文本吐到文件里再手動(dòng)粘貼回引擎現(xiàn)在有了MCPAI可以直接在Unity里新建場景、拖組件、調(diào)材質(zhì)球參數(shù)甚至驅(qū)動(dòng)Unreal的藍(lán)圖系統(tǒng)整個(gè)過程只需要你在對話框里說一句人話。這篇文章不聊概念炒作的廢話直接分享我在實(shí)際項(xiàng)目中把MCP接入U(xiǎn)nity和Unreal的完整過程。包括怎么裝、怎么用、踩了哪些坑、哪些環(huán)節(jié)必須手工兜底。適合已經(jīng)用過AI寫代碼、但對編輯器自動(dòng)化還不熟悉的開發(fā)者以及想給策劃團(tuán)隊(duì)配一套“自然語言驅(qū)動(dòng)引擎”工作流的技術(shù)負(fù)責(zé)人。1. MCP為什么會(huì)在游戲引擎開發(fā)里火起來1.1 從“寫代碼”到“下指令”MCP解決的核心痛點(diǎn)游戲引擎這種重型工具最大的特點(diǎn)是狀態(tài)極度復(fù)雜。一個(gè)Unity場景里有幾十個(gè)GameObject、上百個(gè)組件、無數(shù)資源引用傳統(tǒng)AI生成的代碼根本不知道你的場景里到底有什么。你讓AI寫一個(gè)“讓角色血量減少時(shí)屏幕閃紅”的腳本它連“角色”這個(gè)對象在場景里叫什么名字都不知道只能靠猜。于是我們過去的工作流非常別扭先自己整理一份場景信息、變量名單、資源路徑塞進(jìn)提示詞再讓AI生成代碼再手動(dòng)去編輯器里掛載、調(diào)參。效率提升有但有限而且提示詞越來越長維護(hù)成本越來越高。MCP的思路很直接把編輯器本身變成一個(gè)“工具接口”。AI通過MCP可以實(shí)時(shí)查詢當(dāng)前場景里有哪些物體、某個(gè)組件掛在哪里、某個(gè)資產(chǎn)的GUID是什么。它不再閉著眼睛寫代碼而是像一個(gè)坐在編輯器前面的人一樣先看場景、再操作、再看結(jié)果。這一下就把AI從“文本生成器”升級(jí)成了“編輯器操作員”。1.2 一套協(xié)議打通策劃、程序、工具鏈的協(xié)作邊界MCP的第二個(gè)價(jià)值是讓非程序人員終于有了操作引擎的合法入口。策劃過去想調(diào)一個(gè)光照參數(shù)得麻煩程序改代碼或者教他點(diǎn)點(diǎn)點(diǎn)現(xiàn)在策劃在Claude Code或者自研工具里輸入一句“把主光源的色溫調(diào)到偏暖強(qiáng)度降到0.8”MCP就把這條自然語言翻譯成具體引擎操作完成。這個(gè)能力在中小型團(tuán)隊(duì)尤其實(shí)用。我做過一個(gè)快速原型項(xiàng)目三天里用MCP處理了大約70%的場景搭建工作。策劃直接說“在客廳茶幾上放一個(gè)杯子材質(zhì)換成陶瓷”AI就能根據(jù)場景圖層的命名規(guī)則定位茶幾的位置實(shí)例化杯子Prefab并修改材質(zhì)。程序省下來的時(shí)間全花在真正需要判斷力的系統(tǒng)邏輯上。當(dāng)然協(xié)議本身不只是連接Claude到Unity。MCP是開放的理論上任何支持MCP客戶端的大模型服務(wù)都能接入包括Cursor、Trae這類IDE也包括現(xiàn)在不少團(tuán)隊(duì)自建的Agent網(wǎng)關(guān)。2026年再回頭看MCP已經(jīng)成了游戲開發(fā)工具鏈里繞不開的連接層。2. 開工前準(zhǔn)備Unity MCP的安裝與工程配置2.1 先看清楚自己的編輯器版本和運(yùn)行環(huán)境我在接入U(xiǎn)nity MCP之前建議你先確認(rèn)三件事Unity版本、Node.js版本、以及你習(xí)慣用的MCP客戶端。最常見的組合是Unity 2021.3 LTS或Unity 2022.3 LTS加上Node 18配上Claude Desktop或者Claude Code。Unity MCP目前社區(qū)實(shí)現(xiàn)比較多最主流的方案是給Unity編輯器裝一個(gè)MCP Server插件編輯器啟動(dòng)時(shí)監(jiān)聽本地端口然后通過統(tǒng)一接口暴露編輯器功能。MCP客戶端那邊則是在配置文件里把server地址指向這個(gè)本地端口即可。這里我必須提醒一句不同Unity版本對MCP插件的兼容性有差異。如果你用的是Unity 62023 LTS以后需要確認(rèn)插件是否支持新版本的Editor API有些老插件的場景查詢接口在Unity 6下會(huì)失效。我的建議是最早在干凈工程里跑通一個(gè)最小示例再考慮遷到正式項(xiàng)目。2.2 Windows、macOS下安裝MCP Server的完整步驟我在Windows環(huán)境下的操作流程如下僅供參考。首先確認(rèn)Node可用node -v npm -v然后把Unity MCP插件以UnityPackage形式導(dǎo)入工程這一步和普通插件導(dǎo)入沒有區(qū)別。打開Window菜單下的MCP Server面板點(diǎn)擊啟動(dòng)正常情況下會(huì)看到本地端口地址一般是localhost:8080或9000不同實(shí)現(xiàn)端口不同。接著配置MCP客戶端。以Claude Desktop為例在配置文件claude_desktop_config.json里添加一個(gè)MCP Server條目{ mcpServers: { unity: { command: npx, args: [ -y, some/unity-mcp ], env: { UNITY_MCP_URL: http://127.0.0.1:8080 } } } }配置完重啟Claude就可以在對話里通過MCP工具列表看到Unity相關(guān)的操作接口。能不能連上用一句話就能測試“查詢當(dāng)前場景的所有物體名稱”。MCP客戶端會(huì)調(diào)用場景查詢工具Unity編輯器收到請求返回物體列表AI再整理成自然語言告訴你。macOS下的流程基本一致只是配置文件的路徑不同。唯一需要注意的是macOS對本地網(wǎng)絡(luò)權(quán)限更嚴(yán)格首次啟動(dòng)Node服務(wù)可能會(huì)彈網(wǎng)絡(luò)授權(quán)窗口必須點(diǎn)允許否則MCP Server監(jiān)聽了端口也收不到請求。2.3 Unity編輯器端插件的接入細(xì)節(jié)與權(quán)限設(shè)置MCP插件進(jìn)入工程后通常會(huì)要求你在Project Settings里開啟一些權(quán)限核心是把Allow unsafe code打開。很多MCP插件需要訪問UnityEditor內(nèi)部接口不開unsafe code就會(huì)在首次調(diào)用某個(gè)功能時(shí)出現(xiàn)MethodAccessException看起來很嚇人其實(shí)就是權(quán)限沒開。另外如果工程里用了代碼混淆或IL2CPP打包編輯器狀態(tài)下一般不觸發(fā)問題但某些MCP插件會(huì)掃描程序集混淆過的程序集路徑會(huì)對不上。我的建議是MCP只用于編輯器工具鏈不要試圖讓它參與打包流程至少在前期不要。3. 用自然語言指揮Unity的三個(gè)實(shí)戰(zhàn)場景3.1 場景一自然語言創(chuàng)建物體并掛載剛體組件這個(gè)場景適合拿來驗(yàn)證MCP鏈路通不通也適合給策劃培訓(xùn)“AI能做什么”的直觀認(rèn)知。我在演示時(shí)最喜歡用這句話“在當(dāng)前位置創(chuàng)建一個(gè)立方體添加剛體質(zhì)量為2讓它從十米高空掉下來”。這句話拆解下來有三個(gè)核心操作創(chuàng)建GameObject、添加Rigidbody組件、修改mass屬性。如果換成傳統(tǒng)方式你得手動(dòng)菜單創(chuàng)建、添加組件、在Inspector里輸入數(shù)字。MCP鏈路下AI通過工具調(diào)用把這些步驟一次做完然后返回“已創(chuàng)建CubeRigidbody已掛載mass2”。這種操作的背后是對Unity編輯器API的封裝MCP Server提供了一個(gè)create_primitive工具接收類型、位置、名稱等參數(shù)又提供了一個(gè)add_component工具接收目標(biāo)物體和組件類型。AI做的只是把自然語言映射到工具調(diào)用上。但這里有個(gè)值得注意的細(xì)節(jié)AI并不總能準(zhǔn)確判斷“當(dāng)前位置”是什么意思。Unity編輯器里的“當(dāng)前位置”對AI來說是模糊的它可能用的是場景原點(diǎn)(0,0,0)也可能用了相機(jī)當(dāng)前位置。我建議在提示詞里寫清楚坐標(biāo)基準(zhǔn)或者提前在場景里放一個(gè)名為“SpawnAnchor”的空物體讓AI以這個(gè)錨點(diǎn)作為位置基準(zhǔn)。3.2 場景二動(dòng)態(tài)修改材質(zhì)與光照參數(shù)第二個(gè)我常用的場景是調(diào)參。比如“把主光源改成偏暖的日落色強(qiáng)度降到0.8并讓場景里的所有金屬表面反射更明顯一些”。這句話涉及的操作是獲取主光源的Light組件修改color和intensity然后查找所有材質(zhì)球修改金屬度或Smoothness。實(shí)際操作中AI會(huì)先調(diào)用find_objects_by_tag或get_all_renderers列出場景里的相關(guān)物體再逐一檢查材質(zhì)屬性名。這一步最關(guān)鍵的不是AI的能力而是你的素材規(guī)范性。如果材質(zhì)球的金屬度參數(shù)叫_Metallic另一個(gè)叫Metallic同一個(gè)工程里命名不統(tǒng)一AI處理起來就會(huì)漏掉一部分物體。所以我的建議是在項(xiàng)目資源規(guī)范里提前統(tǒng)一Shader屬性的命名至少讓所有標(biāo)準(zhǔn)PBR材質(zhì)的屬性保持默認(rèn)命名。和MCP無關(guān)但這決定了自然語言驅(qū)動(dòng)能否一步到位。AI工具鏈放大了不規(guī)范資源的維護(hù)成本以前是人眼湊合能看現(xiàn)在是直接報(bào)錯(cuò)或漏操作。3.3 場景三批量創(chuàng)建UI與布局刷新問題第三個(gè)場景帶點(diǎn)硬核味批量創(chuàng)建UI并處理布局刷新。我在熱搜詞里看到“Unity vertical layout group沒刷新”這確實(shí)是UI自動(dòng)化的老坑。通過自然語言告訴AI“在Canvas下創(chuàng)建一行三個(gè)按鈕均勻分布文字分別是開始、設(shè)置、退出”MCP能夠依次執(zhí)行創(chuàng)建UI元素的工具調(diào)用。但做完之后你會(huì)發(fā)現(xiàn)按鈕常常擠在一起因?yàn)閁nity的VerticalLayoutGroup或HorizontalLayoutGroup需要一次布局重建。MCP創(chuàng)建的物體雖然掛好了組件但布局系統(tǒng)可能在同幀內(nèi)沒有感知到新物體。這時(shí)候有兩個(gè)兜底方案一是在提示詞里要求額外執(zhí)行一次布局刷新操作比如調(diào)用LayoutRebuilder.ForceRebuildLayoutImmediate二是在MCP工具層面封裝一個(gè)“創(chuàng)建完UI后自動(dòng)刷新布局”的工具把這兩個(gè)動(dòng)作合并。我自己更推薦第二個(gè)方案。因?yàn)锳I并不知道Unity布局組件的刷新時(shí)機(jī)與其每次都靠提示詞提醒不如在MCP工具層就把“創(chuàng)建按鈕并刷新父節(jié)點(diǎn)布局”作為一個(gè)原子操作。這也是MCP工具鏈設(shè)計(jì)里的一個(gè)重要思路把重復(fù)性操作封裝成粗粒度工具讓大模型只做意圖判斷別讓它糾結(jié)技術(shù)細(xì)節(jié)。4. 意圖識(shí)別與槽位提取自然語言驅(qū)動(dòng)的幕后機(jī)制4.1 意圖識(shí)別和槽位提取怎么參與游戲指令“自然語言驅(qū)動(dòng)游戲引擎”看起來很玄幻但落到工程上底層保底方案還是經(jīng)典的意圖識(shí)別加槽位提取。MCP提供的是執(zhí)行通道而怎么理解人話靠的還是這套NLP機(jī)制。舉個(gè)例子。設(shè)計(jì)師說“把客廳的光調(diào)暗一點(diǎn)”這句話里的意圖是“調(diào)整光照”槽位是“位置客廳”、“操作調(diào)暗”、“屬性亮度”。有了這三個(gè)槽位MCP端才能決定調(diào)用哪個(gè)工具、傳哪些參數(shù)?，F(xiàn)在很多MCP方案直接用大模型做意圖識(shí)別確實(shí)很靈活但代價(jià)是延遲高和輸出不穩(wěn)定。我在生產(chǎn)環(huán)境里更喜歡混合方案固定指令走本地的意圖識(shí)別模型復(fù)雜開放指令才走大模型。比如“把{物體}的{屬性}改成{數(shù)值}”這種模板化指令完全可以用傳統(tǒng)意圖識(shí)別來搞定毫秒級(jí)響應(yīng)不占token。只有當(dāng)句子不在模板庫里時(shí)才讓大模型兜底理解并生成工具調(diào)用序列。4.2 基于Python的本地意圖識(shí)別服務(wù)如何接入如果你打算自建一條更可控的自然語言到Unity的鏈路可以參考我常用的方案用Python寫一個(gè)輕量意圖識(shí)別服務(wù)外部請求先打到這個(gè)服務(wù)解析出意圖和槽位再轉(zhuǎn)換成MCP工具調(diào)用。核心代碼很簡潔用Rasa太重的話直接用規(guī)則加正則也能跑得很穩(wěn)import re from dataclasses import dataclass dataclass class IntentData: intent: str slots: dict def parse_command(text: str) - IntentData: # 識(shí)別“把XX的XX改成XX”這個(gè)模板 m re.search(r把(.?)的(.?)改成(.), text) if m: return IntentData( intentmodify_property, slots{target: m.group(1).strip(), property: m.group(2).strip(), value: m.group(3).strip()} ) # 識(shí)別“創(chuàng)建XX”這個(gè)模板 m re.search(r創(chuàng)建(.), text) if m: return IntentData( intentcreate_object, slots{type: m.group(1).strip()} ) # 兜底走大模型 return IntentData(intentfallback_to_llm, slots{})服務(wù)跑起來之后準(zhǔn)備一個(gè)schema定義好當(dāng)前項(xiàng)目有哪些可操作對象、哪些屬性是白名單。比如只允許修改Transform.position、Light.intensity、Material.color這些關(guān)鍵屬性其他屬性一律拒絕。這個(gè)白名單非常重要它防的不是壞人而是大模型的幻覺——讓它別在離譜的屬性名上浪費(fèi)時(shí)間。4.3 為什么“最小指令集”比“萬能問答”更實(shí)用很多團(tuán)隊(duì)接入MCP后第一反應(yīng)是希望AI什么都會(huì)。我能理解這種期待但我強(qiáng)烈建議反過來設(shè)計(jì)先定義最小指令集。所謂最小指令集就是當(dāng)前能做到穩(wěn)定可靠的操作集合。比如第一周只支持“創(chuàng)建物體、修改組件屬性、移動(dòng)位置、添加預(yù)設(shè)體”第二周再加上“創(chuàng)建UI、批量修改材質(zhì)”第三周再嘗試“生成動(dòng)畫狀態(tài)機(jī)連線”。原因很簡單MCP工具一旦多了大模型的工具選擇準(zhǔn)確率就會(huì)下降。如果你給AI暴露了五十個(gè)工具它在一個(gè)模糊指令下可能選錯(cuò)工具比如把“改顏色”調(diào)成了“創(chuàng)建材質(zhì)”。不如小步迭代每周只暴露幾個(gè)新增工具讓AI有足夠多的示例數(shù)據(jù)去學(xué)習(xí)。自然語言驅(qū)動(dòng)引擎這條鏈路穩(wěn)定比豐富重要得多。5. 轉(zhuǎn)戰(zhàn)UnrealUnrealClaude的工作原理與配置5.1 UnrealClaude和Unity MCP的本質(zhì)差異Unreal這邊的工具鏈我最早接觸的是社區(qū)里的一套叫UnrealClaude的插件方案思路和Unity MCP類似在Unreal編輯器里起一個(gè)本地服務(wù)暴露場景查詢和操作接口給大模型。但Unreal和Unity的架構(gòu)差異導(dǎo)致同樣的事做起來麻煩不少。最核心的差異是組件模型。Unity萬物皆GameObject加Component操作模型高度統(tǒng)一MCP封裝起來非常順手。Unreal則混用了Actor、Component、藍(lán)圖、C、Subsystem等多套機(jī)制同一個(gè)“移動(dòng)物體”的操作在藍(lán)圖里是一個(gè)節(jié)點(diǎn)圖在C里是SetActorLocation函數(shù)在編輯器里可能是手動(dòng)拖拽。因此UnrealClaude的做法通常不是簡單暴露藍(lán)圖節(jié)點(diǎn)而是定義一套高層操作抽象層。AI想“讓門打開”不是直接生成一串藍(lán)圖節(jié)點(diǎn)而是調(diào)用一個(gè)已經(jīng)封裝好的OpenDoor(actor, angle, duration)接口。這套接口由開發(fā)者預(yù)先寫好可以是藍(lán)圖函數(shù)也可以是C函數(shù)。5.2 在Unreal中用自然語言驅(qū)動(dòng)藍(lán)圖與C函數(shù)實(shí)際接入時(shí)我推薦的做法是把Unreal工程里暴露給AI的函數(shù)當(dāng)成“技能庫”每個(gè)函數(shù)都要有清晰的描述和參數(shù)說明。例如給一個(gè)函數(shù)取名叫RotateActorSmoothly描述寫清楚“對目標(biāo)Actor執(zhí)行平滑旋轉(zhuǎn)deltaAngle為旋轉(zhuǎn)角度增量duration為完成時(shí)間”。這樣大模型在看到“讓風(fēng)扇慢慢轉(zhuǎn)起來”時(shí)才能自然匹配到這個(gè)函數(shù)。這里有個(gè)比較實(shí)用的技巧函數(shù)名和參數(shù)名必須符合大模型的常識(shí)。別用項(xiàng)目內(nèi)部的黑話縮寫在暴露給MCP的接口上。我見過一個(gè)項(xiàng)目接口叫RAT_OP_01(float a, bool b)AI根本理解不了這是“旋轉(zhuǎn)門操作”自然無法調(diào)用。給AI看的接口命名要像給新同事看的接口文檔一樣直白。C函數(shù)暴露給AI后編譯問題就成了新的痛點(diǎn)。你改了C接口必須重新編譯并讓Unreal編輯器完成熱重載UnrealClaude才能識(shí)別到新函數(shù)。每次編譯失敗MCP鏈路就斷在中間。所以我把調(diào)試C接口的時(shí)間估算成普通MCP工具的三倍。5.3 常見Unreal MCP坑權(quán)限、編譯和熱重載Unreal MCP最常見的坑有三個(gè)。第一個(gè)是編輯器模式下無法調(diào)用某些僅在游戲運(yùn)行時(shí)才可用的函數(shù)。MCP跑在編輯器進(jìn)程里它沒有正在運(yùn)行的GameInstance凡是依賴WorldContext里GetWorld()-IsGameWorld()之類的代碼都會(huì)返回錯(cuò)誤。這種情況下要么在工具層做特殊處理模擬一個(gè)PIE階段的WorldContext要么干脆限制AI只能操作編輯器靜態(tài)對象。第二個(gè)坑是熱重載后的函數(shù)指針失效。C改動(dòng)后如果編譯不徹底Unreal編輯器界面看著沒問題但MCP Server調(diào)舊接口時(shí)可能直接崩Editor。我的建議是每次改C后重啟編輯器再測試MCP工具不要依賴Live Coding熱重載去驗(yàn)證MCP接口。第三個(gè)坑是藍(lán)圖節(jié)點(diǎn)圖和MCP工具序列的等效性問題。Unreal的藍(lán)圖擅長表達(dá)“事件驅(qū)動(dòng)”的復(fù)雜邏輯而MCP工具調(diào)用天然是“命令序列”。你說“每當(dāng)角色靠近門時(shí)自動(dòng)打開”這句話對于藍(lán)圖的Event BeginOverlap是天然契合的但對于MCP工具序列它需要落成一個(gè)事件綁定器加一個(gè)回調(diào)處理函數(shù)復(fù)雜度直接上一個(gè)臺(tái)階。所以我通常建議Unreal MCP先別碰事件邏輯只做一次性命令式操作。6. 踩坑記錄與排查速查表6.1 連接失敗的通用檢查清單MCP鏈路踩坑是最耽誤時(shí)間的我把常用排查思路整理成了清單每次連不上按順序查基本十分鐘內(nèi)定位。第一查端口。MCP Server是否真的在監(jiān)聽用netstat -ano | findstr 8080確認(rèn)。第二查防火墻。Windows偶爾會(huì)攔截Node進(jìn)程的本地監(jiān)聽尤其是換了網(wǎng)絡(luò)環(huán)境之后。第三查配置文件的JSON格式。我見過太多次多了一個(gè)逗號(hào)導(dǎo)致MCP客戶端直接拒絕加載配置的情況。第四查Unity側(cè)。MCP面板顯示“Running”才代表編輯器端就緒。如果面板顯示但客戶端連不上大概率是地址寫成了localhost而Unity那邊綁定的是127.0.0.1在特殊代理環(huán)境下這倆不完全等價(jià)。第五查編輯器模式的自動(dòng)運(yùn)行選項(xiàng)有些MCP插件要求開啟“EditorApplication.update”輪詢?nèi)绻还催xIED的ExecuteInEditMode場景操作接口不會(huì)刷新狀態(tài)。6.2 提示詞設(shè)計(jì)讓自然語言到引擎操作的翻譯更穩(wěn)定同樣一套MCP工具不同人寫提示詞穩(wěn)定度差很多。我的經(jīng)驗(yàn)是給AI限定操作范圍明確返回格式。反面例子是“幫我在場景里加一些好看的光照和物體”這種話AI會(huì)自由發(fā)揮結(jié)果不可控。正面例子是“在坐標(biāo)(0,0,0)創(chuàng)建一個(gè)Sphere半徑1材質(zhì)使用Assets/Materials/Demo_Red.mat如果該材質(zhì)不存在則創(chuàng)建它并賦給Sphere”。這樣每一步都是可驗(yàn)證的。另外建議在系統(tǒng)提示詞里寫清楚“當(dāng)前項(xiàng)目背景”包括場景坐標(biāo)系、單位制、資源命名規(guī)范。比如告訴AI“所有角色角色模型在Characters文件夾下所有材質(zhì)球統(tǒng)一用URP管線”它就能少犯低級(jí)錯(cuò)誤。自然語言驅(qū)動(dòng)引擎的本質(zhì)是讓AI在一個(gè)有約束的環(huán)境里完成翻譯你給的上下文越準(zhǔn)確它翻譯得越靠譜。6.3 團(tuán)隊(duì)協(xié)作中的MCP權(quán)限管理與回滾方案給策劃團(tuán)隊(duì)開放MCP之后權(quán)限管理會(huì)成為一個(gè)真問題。你不能讓每個(gè)人都能通過AI刪場景、改全局光照。我們團(tuán)隊(duì)的做法是分三層權(quán)限只讀層、對象操作層、高風(fēng)險(xiǎn)操作層。只讀層允許查場景和資源信息所有人都可以訪問。對象操作層允許創(chuàng)建和修改當(dāng)前場景內(nèi)的非關(guān)鍵對象需要項(xiàng)目負(fù)責(zé)人審批開啟。高風(fēng)險(xiǎn)操作層包括批量替換材質(zhì)、修改光照設(shè)置、刪除資產(chǎn)等僅限程序主程使用。MCP Server里可以做一個(gè)簡單的白名單機(jī)制每次工具調(diào)用前檢查當(dāng)前用戶的操作權(quán)限?；貪L方案更不能省。AI一句話可能把場景改得面目全非手動(dòng)CtrlZ不一定救得回來。我們的做法是每天定時(shí)給場景文件做快照備份同時(shí)在MCP工具層封裝一個(gè)“記錄操作記錄”的功能每次AI執(zhí)行工具都會(huì)寫入操作日志。一旦場景被改壞了先看日志、再定位操作、最后用快照恢復(fù)。寫在最后的經(jīng)驗(yàn)分享這套工具鏈用到現(xiàn)在我最深的一點(diǎn)體會(huì)是MCP并不會(huì)替你做游戲它只是把“操作引擎”這個(gè)門檻大幅降低了。AI依然需要你給它正確的工具接口和業(yè)務(wù)上下文才能輸出可靠的結(jié)果。但反過來過去一個(gè)策劃提需求、程序改代碼、美術(shù)調(diào)資源要花一下午的小改動(dòng)現(xiàn)在可能十分鐘就完成了。如果你正準(zhǔn)備在自己的項(xiàng)目里引入這條鏈路我的建議是先從一個(gè)Unity的只讀查詢場景開始讓AI能看出場景里有哪些東西再逐步開放寫操作。別一上來就追求全自動(dòng)穩(wěn)扎穩(wěn)打把自然語言驅(qū)動(dòng)引擎用成日常開發(fā)的標(biāo)準(zhǔn)配置。