ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

MCP协议实战:从Unity到Unreal的AI驱动游戏开发工作流

MCP协议实战:从Unity到Unreal的AI驱动游戏开发工作流 今年做游戏开发如果你还没听过MCP这个缩写多少有点跟不上节奏了。MCP全称Model Context Protocol模型上下文协议。这词2024年底开始在AI圈刷屏到2026年已经不是什么新概念而是游戏开发工具链里实打实的一环。Unity MCP、UnrealClaude、Blender MCP、Cocos Creator MCP——这些名字背后其实是同一件事让AI大模型不再只是隔着网页聊天的顾问而是能直接伸手进编辑器里干活的操作员用自然语言驱动游戏引擎。这篇内容我不打算复述官方文档而是把从2025年到2026年这两年在实际项目里接通、踩坑、调优的经验整理一遍。主要覆盖三块MCP协议和游戏开发结合的底层逻辑、Unity MCP的完整接入与实操、UnrealClaude这套把Claude接进Unreal Editor的玩法再加上Blender、设计稿工具联动组成的完整MCP工具链。适合独立开发者、游戏团队技术负责人以及准备用AI重构内部工作流的TA和程序同学。1. MCP到底解决了游戏开发的什么问题1.1 先从协议本身说起MCP是什么MCP的定位一句话就能说清它是AI应用和外部工具之间的标准化接口协议。类比一下你平时给手机插耳机、接充电器用的是同一个Type-C口不管什么品牌什么型号插上就能用。MCP想干的事也一样——让任何AI助手都能通过同一套协议去调用任何暴露了MCP接口的工具。这套协议里有两个核心角色。一个是MCP Server负责把某个软件的能力封装成标准接口比如创建一个物体修改材质执行脚本另一个是MCP Client就是Claude、Cursor、以及各种AI Agent框架负责理解你的自然语言决定调用哪些工具、传什么参数。早期大家玩MCP讨论最多的是文件操作、数据库查询、网页抓取这类常规任务但游戏引擎这行其实特别适合接入MCP原因后面细说。协议层面MCP支持三种传输方式stdio本地子进程通信、SSE服务端推送事件、以及后来逐步标准化的HTTP流式传输。游戏编辑器这类场景绝大多数用的是本地HTTP服务方式——编辑器里起一个本地端口AI客户端通过HTTP请求把工具调用发过来编辑器执行完再把结果写回去。好处很明显不依赖云服务离线可用编辑器侧的安全策略也能自己控制。1.2 为什么游戏引擎特别需要MCP游戏开发的工作流和别的软件行业很不一样链路极长、工具极多、重复操作极重。一个角色资产要经过建模、UV、贴图、导入、材质、动画、蓝图/脚本、关卡布置每个环节都是独立的工具每个工具里都有一堆机械重复的操作。拿Unity为例你想在场景里摆100棵树用于测试遮挡剔除传统做法是什么右键创建、拖到合适位置、调随机旋转、改缩放、复制粘贴……运气好五分钟搞定运气不好弄到怀疑人生。用MCP之后一句在场景里随机生成100棵树分布在原点周围半径50米的环形区域内朝向随机就能完成。这不是什么魔法而是MCP把自然语言映射到了Editor API调用上。另一个关键点在于游戏引擎的几乎所有操作都有确定性API。Unity有EditorApplication和SceneManagementUnreal有Python API和Editor Utility WidgetBlender有bpy。这些API天生就是给代码调的只是过去只能由人写代码去调。MCP等于给AI开了一扇门让它能以写代码的精度去操作编辑器而不是靠截图识别、鼠标模拟那种脆弱的方式。这里顺便提一句很多人问过MCP和Computer Use到底啥区别。Computer Use是让AI像人一样看屏幕、点鼠标属于模拟人操作MCP是让AI直接走API调用真实功能属于程序化集成。游戏开发这种对精确度要求极高的场景必须走MCP这种路子靠视觉识别去点Unity编辑器里的层级面板稍微有点误差就废了。1.3 2026年游戏AI工具链的真实生态我按照实际观察到的行业情况把2026年的MCP游戏开发生态梳理一下。Unity这边社区里已经有多个开源的Unity MCP插件核心思路都是编辑器内挂一个本地服务暴露工具给AI客户端调用。Unreal这边以UnrealClaude为代表的一类项目把Claude的Agent能力接到了Unreal Editor上走的路径是Python脚本执行和编辑器UI自动化。周边的工具也没闲着Blender MCP让AI能直接建模改网格MasterGo MCP和蓝湖MCP把设计稿数据喂给AICocos Creator MCP照顾到了小游戏和2D方向。这套生态最大的变化是MCP从极客实验变成了生产管线。我认识的小团队里已经有把Unity MCP写进日常开发流程的每天早上让AI自动检查场景里未引用的资源、批量重命名命名不规范的物体、生成测试用的假人。这些活儿以前要么花一两个小时手动干要么专门写编辑器工具现在一句话的事。2. Unity MCP接入实战从安装到跑通第一个自然语言指令2.1 环境准备你需要的东西先说结论环境准备一共四样Unity编辑器、MCP插件、AI客户端、以及一个能正常访问外网资源的包管理环境。Unity版本建议用2022.3 LTS或更新版本2021.3也能跑但部分插件依赖了新版Editor API老版本会报编译错误。AI客户端我试过Claude Desktop、Cursor以及自己用Python写的最小客户端都能连只是配置细节略有差异。如果你不想装桌面端也可以用VS Code配合Claude Code这类终端工具走stdio方式挂载。安装Unity MCP插件这一步不同开源的实现略有差别但大体流程一致。以我常用的方案为例把插件源码clone到项目的Assets目录下注意是Assets根目录下的子文件夹不是Packages回到Unity等一次完整编译编译结束后菜单栏会出现MCP相关的窗口入口打开窗口看到服务地址默认一般是http://localhost:8000或9000这类端口点Start启动在浏览器里访问这个地址能看到健康检查JSON说明服务已经挂起来了。这里有个坑我必须提醒Unity是单线程UI模型MCP服务跑的端口监听不能阻塞主线程否则编辑器会卡死。成熟的插件会用EditorApplication.update或者异步方式处理请求队列但一些早期的社区实现会直接在主线程里做IO表现就是编辑器鼠标转圈。选插件的时候优先挑那些支持异步、有请求队列的。2.2 配置AI客户端把Unity工具挂进对话服务端起来了接下来的问题是让AI客户端知道有哪些工具可用。如果你用的是Claude Desktop或Cursor这类带MCP客户端配置的软件操作方式是修改配置文件把Unity MCP的server信息填进去。以Claude Desktop为例配置文件里的核心片段长这样{ mcpServers: { unity: { command: npx, args: [-y, unity-mcp-bridge], env: { UNITY_MCP_URL: http://localhost:8000, UNITY_MCP_PROJECT: ./ } } } }这段配置的意思是让Claude启动时通过npx拉取一个叫unity-mcp-bridge的包这个包负责和Unity编辑器里的本地服务做通信。注意这里的command和args取决于你用的插件实现——有的插件是纯HTTP模式AI客户端只需要知道工具调用的URL不需要本地起进程有的走stdio模式就需要一个本地适配器。配置完成后重启AI客户端你会发现对话模型里多了一组Unity相关的工具工具名可能是create_object、move_object、execute_csharp这类。到这一步连接工作就算完成了。2.3 第一个指令视觉化验证连接是否真的通了很多教程到配置完就结束了但我强烈建议你做一个带视觉反馈的验证而不是只问AI你连上了吗。我的做法是输入这样一句在场景中创建一个立方体位置(0, 1, 0)缩放(2, 2, 1)命名为Ground然后给它赋一个深灰色材质如果一切正常你会看到AI在思考过程中调用create_objectUnity Scene视图里立刻出现一个扁平立方体Project窗口里可能多出一个材质资产。然后你再让AI执行把Main Camera移动到(0, 3, -6)角度旋转到(30, 0, 0)这时候Game视图里能看到从俯视角度看向立方体的画面。两个指令都成功说明从自然语言 → 工具调用 → Editor API执行 → 场景可视化反馈的完整链路已经打通了。这一步之后你就可以放心往下探索更复杂的操作。3. 自然语言驱动Unity的核心实操场景、脚本、UI、资源3.1 场景操作与物体管理先用表格把高频场景操作列一下都是我实测过能稳定工作的操作类型自然语言示例对应的MCP工具单物体创建在原点创建一个胶囊体命名为Playercreate_object批量生成在半径30米圆环内随机生成50个立方体create_object batch_execute坐标变换把Cube_A移动到(2, 0, 5)Y轴旋转90度set_transform层级调整把Player下的子物体全部取消激活set_active批量重命名把场景里所有叫Cube_N的物体重命名为Block_Nlist_objects rename_object删除物体删除名字包含Temp的物体delete_object比较有用的一个技巧是先用查询再用修改。AI在操作前应该先调用list_objects获取场景里的物体列表确认目标存在再执行修改。我见过很多翻车现场都是因为AI不知道物体叫什么名字就瞎猜然后工具调用直接报错。后来我在给团队的提示词规范里加了一条硬性要求凡是涉及具体物体的操作AI必须先查询后操作效果立竿见影。批量生成物体时还需要注意性能。一次请求让AI生成500个立方体Unity主线程会瞬间卡死几秒。更稳的做法是让AI分段执行比如200个一批中间加延迟或者配合协程让编辑器一帧只创建一部分物体。这个约束不只影响体验也会影响MCP连接的稳定性——请求超时重试很容易把消息队列搞乱。3.2 C#脚本生成与修改最有价值的能力如果说场景操作是开胃菜那C#脚本的生成和落盘就是Unity MCP的主菜。过去用AI写脚本流程是你把代码复制到IDE手动建文件拖到物体上编译报错再复制回去问AI。MCP把这个循环压缩到一句话。实际工作中我的用法是帮我写一个角色移动脚本挂在名为Player的物体上用CharacterController控制WSAD移动、空格跳跃、Shift加速在OnDrawGizmos里画出胶囊体碰撞边界AI会先生成完整的C#代码然后调用create_script工具把文件写到Assets/Scripts目录再调用attach_component把它挂到Player物体上最后触发一次编译并读取编译日志。如果代码里有错误比如方法名拼错、命名空间缺失AI会看到日志后自动修复再重新编译。这个循环非常实用等于把写代码—丢进引擎—看报错—改代码这个迭代闭环自动化了。我统计过以前写一个简单交互脚本加调试大概要20到30分钟现在用MCP驱动AI3分钟内能出一个能跑的初版剩下的时间都花在调参和打磨手感上。这里有一个重要心得让AI直接修改已有脚本的准确性比对整个文件重写要高得多。原因很简单完整重写容易引入无关的改动而定位到方法级别的修改改动面小、不容易破坏原有逻辑。所以在操作规范里我倾向于要求AI优先用read_script读取文件再用modify_script精确定位修改而不是动不动就覆盖整个文件。3.3 UI与资源的批量调整UI这块大家问得最多的是LayoutGroup不刷新。热搜里那句unity vertical layout group没刷新说的就是运行时修改了子物体之后VerticalLayoutGroup没有立即重新布局的老问题。用MCP处理很简单让AI在修改子物体尺寸后自动调用LayoutRebuilder.ForceRebuildLayoutImmediate把目标布局组强制刷新一次。过去你需要在代码里专门写刷新逻辑现在AI执行完操作顺手就把布局修复了。另外一类高频需求是平台设置批量修改比如热搜里的unity 提高 minimum API level target API level到API35。这个在PlayerSettings里的设置项通过MCP暴露的update_player_settings工具可以一次搞定不用再打开Build Settings一页页翻选项。我自己在批量维护多个项目时会让AI先检查每个项目的Target API Level不一致的统一改成目标版本省了大量人工核对时间。资源侧材质替换和贴图应用也是高频操作。一条指令把所有叫做Ground的物体材质换成Assets/Materials/GroundMat.matAI会遍历物体、找到MeshRenderer、替换sharedMaterial。注意这里要用sharedMaterial而不是material后者会生成实例材质导致场景里出现大量重复材质资产这是新手容易踩的坑。3.4 安全边界AI手里有刀你得知道刀往哪砍把编辑器操作权交给AI这句话的分量得掂量清楚。AI一个错误决策可能批量删除物体、覆盖场景文件、改错全局渲染设置。我自己发生过一次事故让AI整理场景中重复的材质结果它的匹配逻辑太激进把好几个美术手调的材质替换成了默认材质场景视觉瞬间崩了最后只能靠版本回滚。基于这些教训我列了三条安全底线团队内部强制执行危险工具白名单机制删除、覆盖保存、AssetDatabase操作这类destructive操作必须在MCP配置里单独标注让AI执行前二次确认隔离场景原则MCP调试阶段只操作测试场景绝不直接开放给正在开发的主场景版本控制兜底任何被AI操作过的场景和资源目录必须纳入版本控制出问题能秒回滚。这三条看起来是废话但真到用的时候能救你一命。我见过不止一个团队AI第一次大规模操作成功后high过头开始让它动核心场景然后就没有然后了。4. UnrealClaude在Unreal Engine里跑AI Agent4.1 UnrealClaude到底是个什么东西UnrealClaude这个名字社区里指代的是一类把Claude接入Unreal Editor的项目和工作流。它和Unity MCP的思路一脉相承但实现路径完全不同。Unity走的是C# Editor脚本而Unreal这边的主角是它的Editor Python API也就是unreal这个Python模块。为什么Unreal更适合走Python这条路因为Unreal从4.26开始内置了Python Editor Script Plugin提供了比C反射更轻量但覆盖度极高的编辑器操作API。创建Actor、设置属性、加载资源、管理关卡这些日常操作Python都能做。Claude这类大模型对Python代码的理解能力极强让它生成一段unreal.EditorLevelLibrary.spawn_actor_from_class的调用比让它理解C编译流程容易得多。但这里有个容易懵的地方Unreal的Python环境是内置的不能用系统Python去跑因为系统Python里根本没有unreal这个模块。所以UnrealClaude这类项目本质上是把MCP server跑在一个能访问Unreal Python API的环境里而不是简单起一个外部Python服务。4.2 安装连接一步步把Claude接进Unreal我以一个典型的UnrealClaude项目接入流程为例实际操作分四步确认项目的Python Editor Script Plugin已启用一般5.0以上版本默认开启把UnrealClaude插件的Python脚本拷贝到项目的Content/Python目录或Plugins目录下在Unreal编辑器里执行挂载脚本通常是Edit → Editor Preferences里跑一次或者用py path/to/bridge.py启动本地MCP服务在AI客户端里配置对应的MCP Server连接信息。关键是第2步和第3步脚本位置放错了或者没有执行挂载服务就起不来。和Unity那边不同Unreal C的编译链路重MCP插件如果走C模块一次编译动辄几分钟走Python轻量许多改完脚本直接重新执行就能生效开发迭代快得多。4.3 从读到写蓝图生成和关卡自动化的实践经验先说结论让AI直接生成复杂蓝图目前还不是一个成熟可靠的操作但让AI读蓝图、检查蓝图逻辑、修改属性已经相当实用了。读蓝图的方向典型场景是审计和审查。让UnrealClaude遍历某个Level里所有Actor列出Mesh引用情况、LOD设置、碰撞类型输出一份报告——这类审计型任务AI做得又快又准。还有一个我经常用的场景美术反馈某个区域的物体光照异常让AI检查区域内每个Mesh的Cast Shadow设置、Lighting Channel、材质是否为半透明很快就能定位问题源头。写Blueprints的方向建议从简单的开始。比如在关卡里创建Actor、放置Static Mesh、设置位置缩放这类操作Python脚本非常稳定import unreal level_library unreal.EditorLevelLibrary mesh_asset unreal.EditorAssetLibrary.load_asset(/Game/Assets/Props/SM_Tree.SM_Tree) for i in range(20): actor level_library.spawn_actor_from_object(mesh_asset, unreal.Vector(0, i * 200, 0)) actor.set_editor_property(tags, [AI_GENERATED, fROW_{i}])这段代码通过MCP工具提交到Unreal执行后关卡里会出现一列树并且带上了对应的Tag方便后续按Tag批量处理。关键点是UnrealClaude的MCP工具里至少要有execute_python和read_log这两个一个是执行入口一个是日志反馈缺了任何一个AI都是盲人摸象。对于更复杂的蓝图逻辑我的建议是让AI先生成Python版的逻辑用Python实现游戏逻辑原型确认无误后再转换成Blueprint或C。直接把一整套AI行为树交给大模型从零生成现在的效果还很不稳定。5. 多工具MCP协同从素材生产到引擎摆场的完整链路5.1 Blender MCP资产生产线的自动化单独一个引擎接入MCP价值有限真正能改变工作流的是多工具协同。Blender这块MCP插件让AI可以直接操作bpy模块建模、改网格拓扑、展UV、烘焙贴图都能做。我实际跑通过一条链路让Blender MCP创建一个low poly的树模型导出FBX然后让Unity MCP在Untitled项目里导入这个FBX生成Prefab最后在场景的道路两侧随机摆放。整个过程只需要一句完整指令先在Blender里创建一棵低模风格的树树干圆柱体、树冠圆锥体删掉底部面导出为FBX放到Assets/Imports然后切到Unity导入这个FBX生成Prefab沿场景主路两侧每5米摆一棵随机旋转和缩放Blender MCP执行建模Unity MCP执行导入和布置AI客户端负责在这两个工具之间切换上下文。实际执行时间取决于模型复杂度简单的树3到5分钟就能从零出现在Unity场景里。对于需要快速搭建测试场景的原型阶段这套流程效率碾压手动操作。5.2 MasterGo MCP和蓝湖MCP设计稿到引擎的桥游戏项目里UI这块以前最烦的就是设计稿标注和引擎尺寸对不上。现在有了MasterGo MCP和蓝湖MCP能让AI读取设计稿上的尺寸、间距、颜色、字号再把这些参数应用到Unity的UGUI或Unreal的UMG上。热搜里那句cursor连接蓝湖mcp说白了就是让编程AI在设计稿数据的指引下写UI代码减少来回切换看标注的时间。我现在的UI开发流是设计在MasterGo里更新 → AI通过MasterGo MCP读取最新的标注变量 → AI生成对应的UGUI布局代码 → 通过Unity MCP直接应用到场景 → 设计改完我再同步一句按最新设计稿刷新UI全部流程不需要手动抄一个色值。这里面有个心得把设计系统的token颜色、间距、字号预先整理成AI能读的JSON比让AI去逐条解析设计稿有效得多。MCP直接读标注当然行但设计稿命名不规范的时候AI会卡在这个颜色到底是主色还是强调色这类问题上。你花半小时把设计系统的变量定义好后面能省几十个小时。5.3 多MCP并行时的上下文管理多个MCP server同时挂在同一个AI客户端里工具数量会膨胀。我有一次挂了Unity、Unreal、Blender、蓝湖四个AI能用的工具超过80个结果它在工具选择上开始犹豫一个简单任务想半天。这个问题的解决方案一是给工具命名加前缀比如unity_create_object、blender_create_mesh让AI能从名字上秒辨归属二是在prompt里显式声明工作流顺序让AI知道先做A再做B而不是让它在庞大的工具列表里自由发挥。另外要注意的是多个编辑器同时打开时不要让两个MCP server监听同一个端口。默认情况下Unity MCP在8000Unreal在9000Blender在7000但如果你手动改过配置容易出现端口占用和连接串线的问题。我踩过一次Unity回话的请求被Unreal的server接收返回了一堆Python报错AI也懵了最后查了半天才发现是两个server的端口配反了。5.4 自建MCP Server当现成工具不够用的时候社区里现成的MCP工具终归覆盖不到你项目的所有需求。像我这边团队有自己的一套资源命名规范和批量处理工具就需要把这些内部工具封装成MCP Server暴露给AI。自己搭一个MCP Server没有想象中那么复杂。Python生态里官方提供了一套mcp库用装饰器就能把普通函数暴露成工具。一个最小demo长这样from mcp.server.fastmcp import FastMCP mcp FastMCP(internal-tools) mcp.tool() def rename_assets_by_rule(folder: str, prefix: str) - str: 批量重命名指定目录下的所有资产加上指定前缀返回文件列表 # 这里调用你们项目自己的命名规范逻辑 return \n.join(renamed_files) mcp.run()把这段本地服务跑起来再配置到AI客户端AI就拥有了调用你们内部工具的能力。我这里特别提醒一个点MCP的工具描述要多写业务上下文。比如你写rename_assets_by_rule按公司标准批量重命名资产AI能理解用途但如果你补充规则角色资产前缀CH_场景资产前缀ENV_材质前缀MAT_资源需同时修改文件名和FBX内部的AssetNameAI的执行准确率会明显提高。工具描述写得好不好直接决定了AI能不能正确调用你封装的这些能力。这也是我反复在团队里强调的给AI写工具说明要像写给新同事看的Wiki一样细。6. 常见问题排查与调优实录6.1 连接故障速查表MCP这类东西配置环节最容易出问题而且报错信息通常很抽象。把这一年多遇到的高频问题整理一张表现象可能原因解决方案AI提示无法连接Unity MCPMCP服务没启动检查编辑器菜单栏的MCP窗口状态确认端口在监听连接成功但工具调用超时编辑器主线程被占用等编辑器空闲再试检查是否有大批量操作阻塞主线程Unity启动后MCP服务自动消失插件加载失败或版本不兼容查看Console日志里的编译报错尝试升级Unity版本或换插件分支Unreal执行Python报module unreal not found用了系统Python环境确认通过Unreal内置Python执行而非外部环境两个MCP server通信串线端口配置重复检查各编辑器端口分别改成不同端口AI生成的脚本无法编译API版本或命名空间差异让AI读取编译日志自修复不要手动覆盖场景文件被意外覆盖操作没走版本控制立即从版本控制恢复后续增加destructive操作二次确认大多数连接类问题80%是端口和路径配置错误20%是版本兼容性。排查思路就一条先看服务端编辑器有没有监听再看客户端AI配置对不对最后看中间层网络/本地代理。6.2 让AI听懂你的项目上下文工程很多人说AI操作不精准其实不完全是模型能力问题更多是上下文不够。你让AI去调整那个车它根本不知道车里有哪些组件、在哪个层级下、用什么名字。解决办法是主动给AI喂项目上下文。我的做法在每个项目根目录维护一个AI_CONTEXT.md里面写清项目结构、关键目录、命名规范、常用资源路径、以及常见任务的标准操作流程。然后在prompt里固定一句开始工作前先阅读AI_CONTEXT.md。AI读完后再接任务成功率提升非常明显。另一个技巧是少样本示例few-shot。与其让AI凭借直觉理解你的意图不如直接给它一个可参考的样例这是之前一次成功操作的完整对话记录。AI会模仿这个模式来处理新任务。我测试过同样的任务给示例和不给示例生成代码的首次通过率从50%出头提升到了80%以上。6.3 性能、数据安全与权限边界性能上最核心的约束是编辑器主线程。Unity和Unreal的编辑器都不是为高并发设计的MCP请求打进来本质是把任务插入到主线程执行队列。大批量操作一定要拆分或者异步化不然编辑器会假死。Unreal那边稍微好一点Python脚本本身就会在单独线程里跑但操作关卡时还是绕不开主线程的同步点。数据安全这块做商业项目的人要提高警惕。MCP是把AI和开发环境打通意味着项目源文件、场景结构、代码内容都可能被送到你接的大模型服务商那里。如果你的项目有保密需求要么用本地部署的模型要么在MCP层做字段脱敏比如只传物体名称不传完整路径只传运行日志不传业务数据。团队内部mcp server的访问权限也要控制不要让MCP随手一调就能读全项目文件。6.4 一句话避坑清单把实操过程中踩过的坑浓缩成几句话给想直接上手的读者MCP服务跑在编辑器里请把编辑器当成服务器而不是客户端不要没事频繁开关项目以为在重启服务让AI操作场景之前先让它列出当前物体清单确认目标存在再动手生成脚本类任务一定要让AI读到编译日志没有日志反馈的AI等于闭眼开车Hello World级别的连接测试别跳直接上复杂任务出错了很难分锅所有关键操作留在版本控制之下MCP再稳也不能替代Git。7. 最后说几句个人体感用了快两年MCP驱动的游戏开发工作流我最大的体感是它不是银弹而是一个编程级助理。它对那些重复性、确定性、可验证的任务收益最大比如批量场景操作、脚本脚手架生成、数据审计、参数批量修改。但对创意决策比如这个关卡怎么设计更有趣这个材质氛围怎么调整它帮不上太多这些还是得靠人。真正让MCP发挥价值的方式是把它当作给AI配了一双能操作引擎的手而不是让AI替你当游戏制作人。工作流重新设计后原来需要一小时起步的杂物现在几分钟清完原来要写编辑器扩展才能做的事现在一句话的临时需求也能立刻执行。这种开发者从执行细节里退出来、把精力放到决策和创意的转变才是AI游戏开发工具链最值得投入的方向。最后分享一个小技巧给AI配置一个项目Wiki文件让它每次接任务前先读一遍项目结构和规范。这看起来不起眼但如果你只能从我这篇内容里拿走一个方法我建议是这一个——它会让你所有的AI工具链使用体验提升一个档次。
返回列表