企业官网建设流程全解析

Unity-Skills是一个基于 REST API 的 AI 驱动型 Unity 编辑器自动化引擎：它在 Unity 内启动本地 REST 服务，通过 805 个 Skills 让 AI 直接创建、修改场景对象、脚本与资源。很多人想"让 AI 操作 Unity"时的第一反应是 MCP（Model Context Protocol），但它真的是更稳的选择吗？本文带你从权限、审计、回滚、预演四个维度看清楚差别。

先说结论：MCP不是不好，是"太信任AI了"

MCP 的思路是给 AI 客户端挂一个"工具桥"：连上之后，工具面整体可调用。它的优点确实存在——生态活跃、接入简单、适合快速验证。

但 AI 驱动编辑器时，写的不是临时文件，而是真实的场景、Prefab 和.meta文件。真正的问题从来不是"它能不能做到"，而是：

它做错时，会发生什么？

典型 MCP 桥接方案在这一问面前，往往只能给出"依赖 Unity 原生 Undo 栈"这个答案——而 Undo 栈在 Domain Reload 之后并不保证还能回退。这就是 Unity-Skills 选择REST + Skills + 治理层架构的根本原因：把"拦得住、查得到、回得去"做成服务端机制，而不是依赖 AI 的自觉。

方案对比：一张清单看懂可靠性差距

下面这张表基于仓库 README 中的横向调研（另一列描述的是 2026-07 公开资料中"典型 MCP 桥接方案"的普遍形态，非特指某个项目）：

治理层四道防线：Unity-Skills 的关键设计

完整的机制说明见 docs/OPERATING_MODES_CN.md，这里用大白话讲一遍：

1️⃣ 执行前：dryRun 预演，"先演一遍再真做"

任何高风险操作都可以加?mode=dryRun预演：服务只做参数校验和影响预估（会不会改场景？会不会触发重编译？风险等级多高？），不落地任何改动。AI 相当于先"报菜名"，你确认后再执行。

2️⃣ 执行时：风险拦截由服务端判定，不靠 AI 自觉

每个 skill 都在元数据里声明了风险级别、操作类型、是否可能进入播放模式或触发域重载。服务端据此自动拦截高危操作——拦不拦，从来取决于元数据，而不是 AI 有没有"提醒"用户。Allowlist 可以为单条 skill 持久放行，灵活度和安全性可以按需调节。

3️⃣ 执行后：JSONL 审计日志，删日志这个动作也被记录

每次调用、授权、撤销、被拦截，都追加到项目内的Library/UnitySkillsAudit.jsonl（1MB 自动滚动），可在面板里直接浏览过滤。有意思的是：删除审计条目本身也会以audit_deleted入账——日志本身也是可审计的。

4️⃣ 出错后：任务级快照回滚，而不是"整个项目倒带"

Workflow 快照分Modified / Created / Deleted / Moved / Setting五类，主文件与.meta各自内容寻址，跨 Domain Reload 和编辑器重启依然存活。workflow_undo_task只回退一个任务，不会把整个项目卷回历史时点；批量操作失败时自动回滚，场景永不残留半成品。

这套"执行前预演 → 执行时拦截 → 执行后审计 → 出错后回滚"的闭环，就是 REST + Skills 架构最核心的红利：治理逻辑全部跑在服务端，AI 客户端换谁都一样受约束。

三步上手：从 0 到 AI 可控 Unity

安装过程非常直接，官方中文版指南见 docs/SETUP_GUIDE_CN.md：

1. 装 Unity 包：在 Unity 的 Package Manager 中通过 Git URL 添加（稳定版 / beta / 指定版本三档可选），环境要求 Unity 2022.3+。
2. 开面板启动服务：菜单Window → UnitySkills（快捷键 Alt+Shift+U），点顶栏开关，Console 出现REST Server started at http://localhost:8090/即成功，可用/health接口验证。
3. 一键安装 AI Skills：在 AI Config 标签页选择你的 AI 工具点 Install，安装器会把unity-skills~/模板自动复制到正确位置，无需手工拷贝。

💡 小贴士：脚本编译、Domain Reload 期间服务会短暂不可达，这是 Unity 编辑器的正常行为，等几秒重试即可。

六大 IDE 原生支持：一键安装即用

Unity-Skills 深度优化了 Claude Code / Antigravity / Codex / Cursor / OpenCode / Kimi Code 六大 AI 工具的技能目录发现机制，安装后升级包版本时已安装工具还会自动同步到新技能版本（不会替你装新工具）。

AI 侧的技能定义入口是 SKILL.md，协议细节（如何发现 805 个 skill、如何省 token）写在 references/protocol-discovery.md：一次recommend调用即可拿到 top 3 候选 skill 及其精确参数模式，典型响应只有 1~4KB，token 消耗比全量 schema 低一个数量级。

常见问题 FAQ

Q：我只做简单的 AI 问答，需要装 Unity-Skills 吗？不需要。纯概念问答不碰编辑器状态，普通 LLM 或 Unity 官方 AI Assistant 就够了。

Q：MCP 生态更热，什么时候它更合适？快速原型、团队已深度使用 MCP 工具链、且操作以只读查询为主时，MCP 桥接是合理选择。一旦 AI 开始写场景和资源，权限与回滚缺口就会显现。

Q：批量操作安全吗？失败会留下脏数据吗？POST /skills/batch以事务方式执行：支持失败即停（fail-fast）或continueOnError、跨步$ref引用前序步骤输出，失败自动回滚，还可以用?diff=1查看聚合净变化。

Q：服务端核心代码在哪里可以看？HTTP 服务核心在 SkillsHttpServer.cs（默认端口 8090，自动扫描 8090–8100 多实例），请求路由与 skill 反射发现在 SkillRouter.cs，工作流快照与回滚在 WorkflowManager.cs。

总结

回到标题的问题：

• 要快：MCP 桥接上手更快，适合探索期；
• 要稳：当 AI 开始真实写入你的 Unity 工程，REST + Skills + 治理层提供了权限到操作级、审计逐次留痕、回滚到任务级的完整保障——而且这些保障都在服务端，与 AI 客户端无关。

这正是 Unity-Skills 的设计哲学：AI 负责"想"，治理层负责"守"。想要亲手验证，按上文三步装好即可——/health接口返回的那一刻，你的 Unity 编辑器就已经对 AI 打开了，并且是可控地打开。