BlueRose/BlueRoseNote
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
b396e6fe75023bdf81d411b343fbdee4e925eae8
BlueRoseNote/07-Other/AI/AI Agent/UnrealEngine/UnrealEngine Hardness Game Development.md

12 KiB
Raw Blame History

目录结构

  • docs
    • Netease_AITA_AssetMaker.md：项目技术、设计细节入口文档，方便Agent来寻找
  • Projects：UE工程目录。

开发计划

  1. 以Lyra为基础进行初始化
    1. 加入GitNexus 引擎代码 以及 项目代码。
    2. CC + Obsidian CLI编写Lyra功能模块、代码逻辑文档、代码规范。
    3. 使用蓝图编译功能生成c++代码，让CC继续理解，并且迭代文档。 该功能已被废弃。
    4. GAS Document加入
    5. 加入Graphify管理文档。
  2. IDE相关MCP加入。
    1. Rider
    2. VSCode 编译与DebugUE工程
    3. 5.8 MCP调研
  3. 好功能移植
    1. GASShooter
    2. Auro
    3. 询问之后还有其他的开发方向。
  4. 其他基建项
    1. 自动测试功能探索。
    2. Puerts。
      1. GitNexus
      2. 改造方案 - 将业务 TS 代码嵌入插件
      3. QuickStart.ts 加入。
      4. 编写相关Skill。
        1. https://github.com/noobGuaTai/ue5-puerts-init-skill
        2. Puerts 编码指南。
    3. Lyra代码插件化与资产插件化。
  5. 编写第三人称RPG的代码。
    1. 找案例移植？

相关技术与容器

需要搬运的：

  1. Myself
    1. RPGGameplayAbility
  2. RiderDebugMcp
  3. VSDebugMCP
  4. UnrealMCP
  5. ue-reference-diagnostic-mcp
  6. AssetMaker
  7. Artlib

测试

UE测试技术

  • 可视化日志
  • 自动测试框架

知识图谱

工具 层级 职责 技术
Graphify 宏观语义层 设计文档、模块架构、策划案、跨文件概念关系 LLM 语义提取 + AST
GitNexus 微观符号层 C++ 类继承、函数调用链、符号精确定位 Tree-sitter AST（无 LLM 成本）
  • Graphify 不适合索引 UE 引擎源码：引擎源码（Engine/Source）数百万行 C++ + 海量宏（UCLASS()、GENERATED_BODY()），Graphify 的 LLM 语义提取会极其昂贵且不精确。引擎源码唯一指定 GitNexus。
  • GitNexus 不适合设计文档：GitNexus 基于 Tree-sitter 解析代码 AST，不处理 Markdown/策划文档的语义关系。设计文档唯一指定 Graphify。

实际配置方案

Step 1：GitNexus 索引 UE 引擎源码（一次性）

cd D:\UnrealEngine\UE_5.7\Engine\Source
npx gitnexus analyze --skip-agents-md --skip-skills --skip-git --embeddings --verbose

npx gitnexus analyze --skip-agents-md -embeddings --skills --verbose

  • --skip-agents-md：避免在引擎目录生成 CLAUDE.md
  • --skip-git：引擎目录可能不是独立 git 仓库
  • 引擎代码是静态的，索引一次即可，无需日常更新
  • GitNexus MCP 会自动发现新索引的仓库（单实例服务所有仓库）

Step 2：Graphify 索引项目业务层

# 1. 创建 .graphifyignore（排除引擎、编译产物、第三方插件）
# 2. 构建知识图谱
/graphify . --directed --no-viz

.graphifyignore 关键排除项：

# UE 编译产物
Binaries/
Intermediate/
Saved/
DerivedDataCache/
Build/

# UE 配置和资产（非代码）
Config/
Content/

# 第三方插件
Plugins/LogicDriver/
Plugins/UnrealImGui/
# ... 等

# AI 工具配置（非项目内容）
.kilocode/
.trae/skills/
.trae/plans/

保留的索引目标：

  • Source/：项目 C++ 业务代码
  • Plugins/CelpecTalent/、Plugins/RPGGameCore/ 等：项目自有插件
  • .trae/documents/、.trae/specs/：设计文档和规范

Step 3：CLAUDE.md 路由规则

## Architecture-Aware Routing

1. 理解业务意图 → Graphify（graphify-out/graph.json）
2. 精确符号查询 → GitNexus AIDM 仓库
3. 引擎底层 API → GitNexus UE Engine 仓库
4. 设计文档/规范 → Graphify 社区标注

MCP 配置说明

不需要修改 MCP 配置。 GitNexus MCP 是单实例多仓库架构：

现有 MCP 实例（gitnexus）
  ├── AIDM（项目代码，59K symbols）
  ├── UE_5.7（引擎源码，索引中）
  └── 其他已索引仓库

通过 repo 参数区分目标：

  • 查项目代码：gitnexus_context({name: “URPGAttributeComponent”, repo: “AIDM”})
  • 查引擎源码：gitnexus_context({name: “AActor”, repo: “UE_5.7”})

实施计划

阶段 1：功能规划期 (Planning)

任务：新增一个技能释放组件，调用 C++ 底层属性系统（AttributeSet）。

流程：

  1. 调用 Graphify 查询 graphify-out/graph.json，了解现有技能系统与属性系统的模块关系
  2. 调用 gitnexus_context({name: “URPGAttributeSet”, repo: “AIDM”}) 获取属性系统的继承拓扑
  3. 调用 gitnexus_impact({target: “URPGAttributeSet”, direction: “upstream”, repo: “AIDM”}) 评估修改影响范围
  4. Graphify 高亮相关设计文档（.trae/specs/ARPGGameDevelopment/）

结果：CC 在未加载具体 C++ 实现代码的前提下完成方案规划，Token 消耗极低。

阶段 2：编写代码期 (Coding)

任务：在 C++ 中实现绑定逻辑，调用引擎定时器 FTimerManager。 流程：

  1. 调用 gitnexus_context({name: “FTimerManager”, repo: “UE_5.7”}) 获取引擎侧精准函数签名
  2. 调用 gitnexus_query({query: “timer set timer”, repo: “UE_5.7”}) 查找引擎中定时器的执行流
  3. Graphify 确认修改不违反项目架构约束（.trae/documents/02_程序架构/开发规范.md）

结果：CC 写出的代码精准匹配引擎 API，避免盲猜宏和重载。

阶段 3：调试 Bug 期 (Debugging)

任务：C++ 接口在 TS 调用时崩溃。 流程：

  1. CC 获取调用栈，将崩溃符号输入 GitNexus
  2. gitnexus_context 逆向追踪调用链（Caller/Callee）
  3. gitnexus_impact 列出所有受影响执行流
  4. Graphify 检查是否有相关设计文档记录了已知限制或迁移计划

结果：通过图谱边（Edges）直接定位 Bug 核心链路，无需人工复制几千行生命周期管理代码。

Debug

LLDB

1. 安装与环境配置

首先，你需要确保本地安装了 LLDB，并为 Claude Code 配置 MCP 服务。

  • 方案 A：使用官方/社区 LLDB-MCP (推荐) 在终端中运行以下命令添加 MCP 调试服务：
# 使用 uvx 或 npx 自动安装并运行 lldb-mcp-server
claude mcp add lldb-debugger -- command "uvx" --args "lldb-mcp-server"

可能是https://github.com/stass/lldb-mcp

  • 方案 B：开启 LLDB 2026 原生 MCP 支持 现代版本的 LLDB（v19+）已内置 MCP 协议支持。你可以在项目目录下启动它：
lldb --protocol-server start --port 59999

2. 安装调试“技能” (Skill)

为了让 Claude 具备系统化的调试思维（而不只是乱试命令），你需要从 Skills.sh 或 GitHub 安装技能包：

# 安装通用的调试技能包
claude skill install AlmogBaku/debug-skill

VSCode

这的确是一个非常典型的架构差异问题。你提到通过 COM (Component Object Model) 接口控制 Visual Studio，这非常精准，因为 VS 的底层重度依赖 Windows 的 COM 组件机制（如 DTE 对象）。 但对于 VS Code 来说，情况完全不同。VS Code 是基于 Electron 和 Node.js/TypeScript 构建的，它根本没有 COM 接口。 要让 MCP (Model Context Protocol) 或者外部 AI Agent 控制 VS Code，特别是进行断点调试，社区目前有几套非常成熟的开源方案和设计思路：

一、 VS Code 的 MCP 控制方案

针对 VS Code 的架构，目前主要有三种主流的控制路径：

1. “由内向外”方案：Agent 直接作为 VS Code 插件 (目前最稳定、最主流)

与其让外部的 MCP 服务去“黑客”般地控制 VS Code，不如让 Agent 直接运行在 VS Code 内部。

  • 原理：像 Cline、Roo Code 这样的插件，它们本身就拥有完整的 VS Code Extension API 权限（可以打开文件、打断点、读取控制台）。
  • MCP 的角色：在这种架构下，VS Code 插件作为 MCP Client，它去连接外部的 MCP Server（比如获取特定的代码分析工具、数据库查询权限等），而不是让 MCP 来控制 VS Code。

2. DAP-MCP 桥接方案 (专门针对断点调试)

VS Code 所有的调试能力都是基于 DAP (Debug Adapter Protocol) 构建的。如果你想让一个外部的 Agent（比如你终端里的 Claude Code）控制 VS Code 的调试器，最好的办法是拦截或桥接 DAP。

  • 原理：启动一个 mcp-server-dap。这个 MCP 服务把 Agent 发出的 MCP 指令（如“继续执行”、“查看变量”）翻译成标准的 DAP 协议，直接发给 VS Code 底层的 Debug Adapter（比如 cppdbg 或 lldb-dap）。
  • 效果：AI 不需要点击 VS Code 的 UI 按钮，它直接和 VS Code 背后那个真正负责调试的引擎对话。

3. “由外向内”方案：WebSocket / RPC 桥接插件

如果你的 Agent 必须在外部运行，且需要控制 VS Code 的 UI（比如让编辑器滚动、高亮某一行代码）。

  • 原理：需要在 VS Code 里安装一个暴露 WebSocket 或 HTTP 接口的桥接插件。外部的 MCP Server 通过向这个本地端口发送 JSON-RPC 指令，插件再调用 VS Code API 来执行操作。
Reference in New Issue View Git Blame Copy Permalink