目录结构

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

相关技术与容器

UE
- UnrealMcp
- Puerts
- Puerts Editor
- uecli
  - Readme的材质都是agent调用uecli做的帮我生产材质排版材质节点帮我场景截图，帮我材质蓝图截图帮我写readme 帮我提交仓库。 https://github.com/wlxklyh/UECLI
- 通过蓝图转c++功能，让AI读懂蓝图
Debug
- 雷火MCPIDE Debug MCP
  - https://km.netease.com/v4/section/aigc/detail/blog/263683
  - cpp-debugger-cli
- 互娱
  - 从 ASAN 到 AI 的“接力排查” https://km.netease.com/v4/detail/blog/256465
    - 1. 借助 ASAN 把“指针变野”的时间点钉住 UE5编辑器开启ASAN
    - 第一步是启用 ASAN（AddressSanitizer）来辅助定位：
    - 在 UE5 编辑器环境启用 ASAN，本身需要做一些额外工作：https://km.netease.com/v4/detail/blog/254722
    - 这些环境搭建细节本文不展开，只强调结论：ASAN 成功启用，可以看到完整的分配 / 释放栈。
  - https://km.netease.com/v4/detail/blog/260127
  - RiderDebugMcp
  - VSDebugMCP
  - UnrealMCP
  - ue-reference-diagnostic-mcp
- VSCode MCP & Plugin
  - https://github.com/juehang/vscode-mcp-server
  - @modelcontextprotocol/server-dap (DAP MCP) 用途：如前所述，这是 AI 进行代码调试的“圣杯”。它允许大模型直接通过标准 DAP 协议连接到本地的 Python、C++ (GDB/LLDB)、Node.js 调试进程。
- LLDB MCP https://lldb.llvm.org/use/mcp.html
- 其他仓库
  - https://github.com/akiselev/debugger-cli
Docker
- Gitea：工单以及版本管理。
- ~~OpenClaw：子节点部署，通过父节点进行控制。~~
- SMB服务。
Obsidian Cli：文档管理。

UE测试技术

可视化日志
自动测试框架

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 来执行操作。

5.4 KiB Raw Blame History Unescape Escape