unity mcp 智能体 提示词

很多 Unity 开发者把 MCP 接上之后，发现智能体要么不动手、要么乱动工程文件，改完还得自己回滚。问题通常不在模型，而在提示词没把「谁做什么、允许碰什么、做完怎么验」交代清楚。这篇给一套可套用的写法：怎么分工具权限、怎么描述场景任务、怎么让智能体自己回读结果再决定下一步。不承诺一次成功，只给能照着改的结构和排查顺序。

很多 Unity 开发者把 MCP 接上之后，遇到的情况往往不是模型太笨，而是提示词没交代清楚。智能体要么站在旁边不动手，要么一上来就改工程文件，改完你还得自己去回滚。问题的根子通常在提示词里缺少三件事：谁负责做什么、允许碰哪些东西、做完怎么验证。

这篇给一套能直接套用的写法，重点放在工具权限怎么分、场景任务怎么描述、怎么让智能体回读结果再决定下一步。不承诺一次就成功，只给你能照着改的结构和排查顺序。涉及各家模型与工具的具体参数差异，可以到 /models 看当时的说明。

先把工具权限写死：谁能改工程，谁只能读

提示词的第一段不要写目标，先写权限。把 MCP 里挂的所有工具分成两类摊开：只读类负责读场景、读脚本、读日志、查资源；写入类负责建物体、改组件、跑批处理、写文件。写清楚哪些工具可以直接调用，哪些必须等你点头，这一步能挡掉大半误操作。

• 把「失败就停」写进去：工具报错、返回为空、路径不存在时，让智能体停下来输出原因，而不是换个方式继续改工程
• 写清工程边界：允许动哪些目录、哪几个场景、哪些脚本，超出的部分先报告再等你决定
• 区分探索型和交付型任务：探索型允许自由读，交付型只允许按你给的步骤走，别让它顺手重构
• 多人协作的仓库额外加一句：改动前先确认当前分支和工作区状态，避免覆盖别人的未提交内容

场景任务怎么写：从「我要什么」变成「它在哪、变成什么样」

很多提示词写的是「帮我优化一下这个场景」，这种写法智能体没法执行。换成「对象—状态—验收」三段：对象指场景里的具体节点或资源名，状态指要变成的属性值，验收指改完用什么方式确认。三段缺一段，它就得靠猜。

1. 点明对象用场景里的准确节点名或资源路径，避免「那个灯光」「主摄像机旁边的东西」这类模糊指代；如果名字不确定，先让它只读列出候选再让你确认
2. 描述目标状态写清属性名、目标值、取值范围；涉及坐标、旋转、缩放时注明单位和参考坐标系，别让它用默认值猜
3. 约定验收方式写明改完怎么确认：打开某个场景看、跑一次测试、看控制台是否干净；能落到可重复的检查项就别写「你看着办」
4. 拆成单目标多轮一次只给一个可验证的改动目标；五件事塞一句话，出问题时无法定位是哪一步搞坏的

另外在提示词末尾留一句「不确定的地方先问我」。删除资源、覆盖预制体、改公共脚本这类操作一旦执行就很难退回，让它先问一句的成本远低于事后排查。如果你用的是中转站接入的模型，调用行为可能和官方直连有差异，可到 /sites 核对对应站点的说明。

让智能体自己验收：回读、比对、再决定下一步

写入工具返回「成功」不等于工程真的变了。文件可能写入了但没保存，组件可能加上了但参数没生效，脚本可能编译报错但被日志淹没。提示词里要明确要求每轮改动交付三样东西：做了什么、看到的返回是什么、和预期差在哪。没有回读结果的改动不算完成。

• 要求它改完立刻回读同一对象，把实际值和目标值并排报出来
• 约定重试上限：同一个工具连续失败几次就停手汇报，别在错误路径上反复折腾
• 把常见假成功列进提示词：写入未保存、组件参数未刷新、编译错误被忽略、资源引用丢失
• 验收动作尽量用可重复的命令或检查项，方便下次照同样写法复现

什么情况下别用这套写法

这套写法解决的是「有边界、可验证的执行类任务」，不是所有 Unity 场景都适合。以下三种情况，提示词写得再严谨也挡不住问题，应该换思路。

• 工程没有版本控制、也没有可回滚的快照时，先别让智能体做写入类操作，误操作没有退路
• 任务需要美术判断或策划决策（手感、节奏、配色）时，智能体只能做执行，结论必须由人给
• 跨多个工程或跨仓库的大改动，单条提示词管不住，应拆成按仓库、按模块的多轮任务分别交代边界

如果你的团队还没建立回滚习惯，可以先从中转站可信度检测和工具目录入手，确认接入的站点和工具行为稳定之后，再逐步放开写入权限。到 /tools/speed-test 可以看当前工具链的连通情况，具体数字以页面当时显示为准。