Hades 实战：用 Unity 知识图谱让 Claude Code 真正理解你的游戏项目
用 AI 写 Unity 游戏代码时，最令人沮丧的事不是代码写不对——而是 AI 根本不理解你的项目结构。
你问 Claude Code「删除 OldNetworkManager 会影响哪些文件」，它去 grep 了一通 YAML 文件，读了 20 万 token，找到 1 个 prefab，漏掉 3 个变体，还建议了一个会破坏继承关系的修改。这不是模型能力的问题——是工具层面缺少对 Unity 项目的结构理解。
Hades 就是为了解决这个问题的。它是一个 Unity 原生 AI 基础设施层，在 Unity Editor 中构建可查询的知识图谱，然后通过 88 个 MCP 工具暴露给 Claude Code。从此你的 AI agent 能看到项目的结构关系——scene、prefab、script、asset 之间的引用和依赖——而不是在文件堆里瞎猜。
问题：为什么 AI 在 Unity 项目中经常”失明”
Unity 项目的特殊性在于其资产结构的复杂性：prefab 嵌套、scene 层级、serialized reference、GUID 跨文件引用——这些关系完全不在 AI 工具的理解范围内。
| 任务 | 无 Hades 的 AI | 有 Hades 的 AI |
|---|---|---|
| 查找「谁引用了 PlayerController」 | grep YAML，猜 | 读取知识图谱的结构化事实 |
| 修改 EnemyAI 后的影响范围 | 找到 1/4 的 prefab | 返回完整的 4 个 prefab + 3 个 scene |
| 删除废弃组件 | 无法确定是否安全 | 给出依赖图和信任度信号 |
| 理解项目概览 | 泛泛而谈 | 基于真实结构的项目描述 |
关键差距在于：现有 AI 工具（包括 Claude Code 默认搜索）本质上是文本匹配 + 概率推测，而不是结构理解 + 确定性查询。
Hades 的四层架构
Hades 由四个核心层组成，运行在 Unity Editor 内部：
Claude Code ←→ 88 个 MCP 工具 ←→ Hades Hub
├── Graph（项目知识图谱）
├── Asphodel（持久记忆）
└── Charon（完整追踪）
1. Graph（知识图谱层）
自动索引整个 Unity 项目的 scene、prefab、script、asset 及其依赖关系。这是一个语义化的结构化图数据库，每次查询返回的是确定性事实，而非概率预测。
当 agent 问「哪个 scene 用到了 PlayerController」，Graph 层直接返回精确的引用链——3 个 scene、4 个 prefab 变体，每一条都是可验证的。
2. Asphodel（持久记忆层）
将项目的架构决策、编码约定和工作模式持久化为版本控制的 Markdown 文件（.arcforge/memory/）。你只需记录一次「我们项目用 MVVM + ScriptableObject 事件总线」，后续每个 AI 会话都会自动读取。
3. Charon（可观测性层）
追踪每一次工具调用、图查询和记忆操作。通过 Unity Editor 中的 Hades > Open Charon Dashboard 可查看完整调用链路，方便调试和审计。
4. 工具和命令
- 88 个 MCP 工具：21 个图/记忆/追踪工具 + 67 个编辑器操作工具（scene、component、prefab、material、animation、asset）
- 22 个 AI Skills：架构决策、工作流指引、领域专业知识（网络、音频、UI、Shader、ECS、测试等）
- 6 个斜杠命令：
/hades:status、/hades:rebuild-graph、/hades:show-traces等
安装步骤
Hades 需要 Unity 6000.0+、macOS 和 Node.js 20+（Windows/Linux 未经测试）。
第一步：Unity 包安装
在 Unity Package Manager 中点击 Add package from git URL，输入：
https://github.com/TheArcForge/Hades.git
首次安装后 Hades 会自动构建项目知识图谱——一个几秒到几分钟的一次性过程（取决于项目大小），后续更新为增量且近乎瞬时。
第二步：Claude Code 插件安装
推荐持久安装：
/plugin marketplace add TheArcForge/hades-plugin /plugin install hades
之后在 Unity 项目目录中启动 Claude Code，所有工具立即可用。
五种实战场景
场景 1：「告诉我这个项目的情况」
Tell me about this project
无 Hades：AI 泛泛介绍 Unity 通用概念。有 Hades：AI 给出你项目的具体结构——有几个 scene、核心 prefab 是什么、脚本组织结构、资产依赖关系。它真的看了你的项目，而不是猜的。
场景 2：「在哪里用到了 PlayerController？」
Where do we use PlayerController?
无 Hades：在 YAML 文件里 grep 匹配 playercontroller 大小写变体，返回一堆文本片段，AI 再从中推测。有 Hades：直接查询知识图谱的引用边，返回结构化的使用位置列表——精确、可验证、零幻觉风险。
场景 3：「删除 OldNetworkManager 会破坏什么？」
I want to remove OldNetworkManager. What would break?
这是 Hades 最擅长的场景——影响范围分析。依赖图追踪通过整个项目结构（prefab → 脚本 → scene → 材质 → 资源），返回一份完整的”影响清单”，每一条都标注置信度信号。
场景 4：项目迁移或重构
大规模重构中，Hades 的 Asphodel 层可以把架构决策持久化。记录一次「新系统用 ECS 架构」，后续每个 AI 会话都会基于这个约定生成代码，不会出现新旧混用。
场景 5：新成员加入项目
新人用 Claude Code + Hades 打开项目，直接问「理解这个项目的架构」，AI 会根据知识图谱和持久记忆给出结构化的项目说明——比你手写 Onboarding 文档更精确，而且自动更新。
信任度信号系统
Hades 对自己的不确定性是诚实的——每项结果都带有信任度标记：
| 信任等级 | 覆盖范围 | 使用建议 |
|---|---|---|
| Trust（直接信任） | 类型 → 文件映射、prefab/scene/material 内容、资产 GUID 和类型、直接依赖 | 直接使用——这些是从项目文件直接读取的序列化数据 |
| Verify（需要验证） | 脚本和 prefab 的「谁引用了 X」查询 | 作为强线索使用，标注检查 nested_by 字段和置信度块 |
| Confirm（需要确认） | 继承/接口边、C# 依赖追踪、「哪些 prefab 用了这个组件」 | 在涉及预编译包/DLL、泛型、反射/DI 注入时需独立确认 |
注意事项
- 目前仅 macOS 测试通过，Windows 和 Linux 是未测试状态
- 需要 Unity 6000.0+，较旧版本不兼容
- 需要 Node.js 20+ 作为 MCP 桥接运行环境
- 静态分析有已知边界：泛型、反射、动态加载的依赖无法完美追踪
- 如果工具在 Unity 重编译后消失，等待 10 秒让 Hub 恢复后再试
总结
Hades 解决了一个非常具体但重要的问题：AI 编码工具缺乏对 Unity 项目结构的真正理解。它不是一个”也能用到 Unity 项目”的通用工具——它是为了 Unity 而设计的，从知识图谱到持久记忆到置信度信号，每层设计都对应 Unity 项目特有的复杂性。
对于认真使用 Claude Code 开发 Unity 游戏的团队来说，Hades 提供的 7 次工具调用替代 20 万 token 的 grep、27% 的成本降低、100% 的召回率——这些数字比任何通用 RAG 工具都更有说服力。作为 MIT 开源的 v1 项目，社区反馈是其成长的关键。如果你在 Unity 项目上重度使用 AI 编码工具，值得一试。
GitHub: TheArcForge/Hades · OpenUPM 包 · MIT 许可证