Claude Code Game Studios 的 Unreal UMG 专家测试规范用 5 个用例守护 UE 界面 Agent 的领域边界与性能底线【免费下载链接】Claude-Code-Game-StudiosTurn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.项目地址: https://gitcode.com/GitHub_Trending/cl/Claude-Code-Game-Studios导读本文基于 Claude Code Game StudiosCCGS技能测试框架中的 ue-umg-specialist Agent 测试规范系统讲解如何验证一个负责 Unreal Engine UMGUnreal Motion Graphics的 AI Agent 是否合格。你将从中学到该 Agent 的职责边界widget 层级设计、数据绑定、CommonUI 输入路由、widget 性能优化与红线绝不越权设计 UX 流程以及用 5 个典型测试用例库存面板数据绑定、UX 流拒绝、CommonUI 按键不响应、500 个 widget 实例卡顿、既有 InputAction 标签上下文驱动行为验证的完整方法。读完本文你将能自己运行或编写同类 Agent 测试规格把AI 写 UE 界面这件事约束在可靠、可复现、不越界的轨道上。一、规格定位这份文档在测试什么在 CCGS 框架中49 个 AI Agent 各自拥有一个行为测试规格文件Agent Test Spec而 ue-umg-specialist.md 是 Unreal 引擎线中专职 UMG 界面实现的 Agent 的规格。按照 框架 README 的说明这套测试基础设施的对象是技能和 Agent 本身而非用它们开发出的游戏——因此本规格验证的是当开发者向这个 Agent 提出界面需求时它是否给出正确的 UMG 结构、正确的数据绑定方式、正确的 CommonUI 接入以及是否守住自己的领域边界。从 Agent 分层看ue-umg-specialist 属于unreal引擎类专精 Agent与 unreal-specialist、ue-blueprint-specialist、ue-gas-specialist、ue-replication-specialist 并列。它在质量评估标准 quality-rubric.md 中归入engine类别需满足三条引擎类指标指标通过标准E1 — 版本感知在给出 API 建议前引用docs/engine-reference/中的引擎版本并对超出训练截止时间的新 API 作出标记E2 — 文件路由将文件类型路由到正确的子专精 Agent例如.gdshader交给 shader 专家而非 gdscript 专家E3 — 引擎专属模式强制使用引擎专属惯例如 Blueprint Function Library、GAS 标签层级等1.1 Agent 摘要它拥有什么不拥有什么规格开头的 Agent Summary 用四条声明划清了领域Domain拥有的UMG widget 层级设计、数据绑定模式、CommonUI 输入路由与 action tags、widget 样式WidgetStyle 资产、UI 优化widget pooling、ListView、invalidation。Does NOT own不拥有的UX 流程与界面导航设计归 ux-designer、游戏玩法逻辑归 gameplay-programmer、后端数据源游戏代码、服务器通信。Model tierSonnet专精 Agent 的默认档位。Gate IDs无UX 流程决策一律交给 ux-designer。这四条声明是整份规格的基石后续所有测试用例本质都是在检验这四条边界是否被真实遵守。1.2 静态断言不跑行为也能做的结构检查静态断言Static Assertions检查的是规格文件本身的四项结构要求description:字段存在且领域相关须提及 UMG、widget hierarchy、CommonUIallowed-tools:列表与角色匹配可读/写 UI 资产与 Blueprint 文件不含服务器或玩法源码工具模型档位为 Sonnet专精 Agent 默认值Agent 定义不得声称对 UX 流程、导航架构或玩法数据逻辑拥有裁决权。这组断言与 agent-test-spec 模板 中frontmatter 含 name/description/model/tools、领域清晰、不越权决策的要求一脉相承属于无需夹具、纯结构化的快速检查。二、Case 1域内请求——带数据绑定的库存 widget输入创建一个库存 widget显示物品格子网格。每个格子显示物品图标、数量和稀有度颜色并在库存变化时更新。这是典型的 UMG 域内需求规格要求 Agent 的输出必须同时覆盖三个层面UMG widget 结构父级WBP_Inventory内含UniformGridPanel或TileView每个物品对应一个子 widgetWBP_InventorySlot。数据绑定方案二选一——要么在 Inventory Component 上通过 Event Dispatchers 触发刷新要么使用ListView 实现了IUserObjectListEntry接口的 UObject 物品数据类。稀有度颜色驱动方式通过 WidgetStyle 资产或数据表查找驱动严禁硬编码颜色值。输出形式必须包含 widget 层级、绑定模式和刷新触发机制三件套而不是一段大概这样写的自由发挥。这里可以对照 ue-gas-specialist.md 的做法理解本规格的输出结构化传统GAS 专家被要求产出 ability 类骨架 GameplayEffect 定义UMG 专家则被要求产出 widget 层级 绑定模式 刷新机制二者都是具体可落地的结构而非泛泛概念。如果库存数据本身来自 GAS 属性集规格隐含的协作路径是与 ue-gas-specialist 对接而不是自己发明数据源。三、Case 2域外请求——拒绝 UX 流程设计输入设计我们库存系统的完整导航流——玩家如何打开它、过渡到角色属性页、再退出到暂停菜单。期望行为Agent不得产出导航流或界面切换架构必须明确声明导航流和界面过渡设计由 ux-designer 负责一旦流程确定我可以实现对应的 UMG widget 结构在拿到 UX 规格之前不得做出任何 UX 决策返回键行为、过渡动画、模态 vs 全屏。这条用例直接对应用户需求中域外请求需重定向到正确 Agent而非默默处理的协作协议见 agent-test-spec 模板 的 Case 2。同时它也印证了 ux-designer.md 的领域声明——UX 专家负责用户流程、交互设计、信息架构其输出是流程状态图与输入映射而UI 实现代码属于 ui-programmer / 引擎 UMG 专家。两个规格相互咬合ue-umg-specialist 不画流程图ux-designer 不写实现代码中间通过一份 UX flow spec 完成交接。这也是整个 CCGS 分工哲学在 UI 领域的缩影流程UX与实现UMG分离Agent 不得越权做绑定决策。四、Case 3领域边界——CommonUI 输入 action 不匹配输入我们的库存 widget 不响应手柄 Back 键我们在用 CommonUI。这是全规格中技术密度最高的用例期望 Agent 能按三层结构诊断定位根因widget 的 Back 输入 action tag 与项目注册的 CommonUIInputAction数据资产不一致。解释 CommonUI 输入路由模型widget 通过CommonUI_InputAction标签声明输入动作CommonActivatableWidget负责路由分发。给出修复核对 widget 的 Back action tag 与项目 CommonUI 输入动作数据表中注册的 tag 是否一致。区分边界这属于输入路由层问题不是硬件输入绑定问题——后者属于 Enhanced Input 的领域。规格的 Coverage Notes 明确指出本用例要求项目已配置 CommonUI若项目未使用 CommonUI 则跳过测试。这条用例之所以被列为输入路由正确性的核心检查是因为在 CCGS 的engine类指标E1 版本感知、E3 引擎专属模式下Agent 必须掌握 CommonUI 这一 UE 官方 UI 框架的正确接入方式而非用事件图里绑个按键这种绕过式做法。五、Case 4widget 性能问题——单帧 500 个实例的卡顿输入我们的排行榜 widget 一次性创建了 500 个独立的WBP_LeaderboardRow实例打开排行榜时游戏卡顿 300ms。期望行为按优先级逐层给出定位根因单帧内 500 次 widget 实例化造成构造卡顿construction hitch。首选方案改用ListView或TileView配合虚拟化——只有可见行才会被构造并要求讲解 ListView 数据对象必须实现IUserObjectListEntry接口这一前提。备选方案若 ListView 不适用则改用 widget pooling——预先实例化固定数量的行用新数据循环复用。输出要求必须给出用哪个具体 UMG 组件的明确建议而不是一句空泛的优化一下。这条用例在规格中被标注为高影响失败模式300ms 卡顿属于阻断发行的缺陷shipping-blocking应优先执行。它同时呼应了 quality-rubric.md 中 E3 指标引擎专属惯例——虚拟化列表正是 UE 官方推荐的 UI 性能模式。规格的协议合规清单还固化了优先级顺序先推荐虚拟化列表ListView/TileView再考虑 widget pooling防止 Agent 跳过现代方案直接采用老旧做法。六、Case 5上下文传递——CommonUI 已配置时的行动约束输入上下文项目使用 CommonUI已注册的 InputAction 标签为UI.Action.Confirm、UI.Action.Back、UI.Action.Pause、UI.Action.Secondary。输入给库存 widget 加一个可用 CommonUI 操作的排序库存按钮。期望行为优先使用UI.Action.Secondary若该标签已被占用则建议注册新标签如UI.Action.Sort。不得擅自发明新 InputAction 标签——若确需新标签必须注明需在 CommonUI 数据表中注册。当 CommonUI 已是既定模式时不得退回非 CommonUI 的输入绑定方式如在 Event Graph 里直接绑定原始按键。建议中须显式引用上下文提供的标签清单。规格将这条用例定义为UI 管线一致性最重要的上下文感知测试。这与 unreal-specialist.md 的 Case 5依据项目声明版本给出 API以及 ue-gas-specialist.md 的 Case 5只使用上下文中已存在的属性名不发明新属性一脉相承——CCGS 框架反复检验的正是 Agent 使用既有项目状态、而非凭空臆造的能力。七、协议合规清单与覆盖说明7.1 Protocol Compliance 五项检查规格末尾用五条勾选清单汇总了该 Agent 的行为底线停留在声明领域内UMG 结构、数据绑定、CommonUI、widget 性能将 UX 流程与导航设计请求重定向给 ux-designer返回结构化结论widget 层级 绑定模式而非自由散漫的意见使用上下文中已有的 CommonUI InputAction 标签发明新标签时必须标注注册要求大集合场景下先推荐虚拟化列表ListView/TileView再考虑 widget pooling。对照 quality-rubric.md 的specialist类别指标S1 守领域、S2 不越权做绑定决策、S3 正确重定向而非沉默拒绝可以看出这五项正是那些通用指标在 UMG 场景下的具体化。7.2 Coverage Notes测试的执行方式与优先级规格最后明确了三条覆盖说明Case 3 前置条件CommonUI 输入路由测试依赖项目已配置 CommonUI未使用 CommonUI 的项目跳过此用例。Case 4 优先级最高300ms 卡顿是阻断发行的失败模式优先执行。Case 5 重要性上下文感知是 UI 管线一致性的最关键检验。无自动化运行器此类 Agent 行为测试需要人工评审或通过/skill-test技能运行。关于最后一点skill-test.md 说明了运行方式/skill-test spec [name]会读取测试规格文件并逐条用例评估产出逐条 PASS/FAIL 结果表与整体结论PASS / PARTIAL / FAIL发现问题的下一步是/skill-improve [name]进入测试 → 诊断 → 提议修复 → 重测循环。整个流程不写任何文件保持只读评审。若发现问题属于规格本身可参照 agent-test-spec 模板 的结构修订后在 catalog.yaml 中登记测试结果如last_spec_result。八、总结一份可复用的 UMG Agent 验收清单ue-umg-specialist 测试规格的价值不止于这一位 Agent。它示范了为引擎专精 Agent 编写验收标准的通用模板用领域声明划定边界拥有什么、不拥有什么、模型档位、gate 归属用静态断言保证规格文件自身结构合规用域内用例验证技术能力结构 绑定模式 刷新机制的可落地输出用域外用例验证谦逊拒绝并重定向绝不越权设计 UX用边界用例验证诊断深度CommonUI 路由 vs Enhanced Input 的区分用性能用例验证工程底线虚拟化优先、pooling 次之、具体组件而非空话用上下文用例验证一致性沿用既有标签、不发明、不绕行。把这七步套用到任何新 Agent 上你就能得到一份像这份 UMG 规格一样、既守边界又保质量的行为测试文档——而这正是 Claude Code Game Studios 用 49 个 Agent 支撑起完整游戏开发流程的关键保障机制。【免费下载链接】Claude-Code-Game-StudiosTurn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.项目地址: https://gitcode.com/GitHub_Trending/cl/Claude-Code-Game-Studios创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Claude Code Game Studios 的 Unreal UMG 专家测试规范：用 5 个用例守护 UE 界面 Agent 的领域边界与性能底线
Claude Code Game Studios 的 Unreal UMG 专家测试规范用 5 个用例守护 UE 界面 Agent 的领域边界与性能底线【免费下载链接】Claude-Code-Game-StudiosTurn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.项目地址: https://gitcode.com/GitHub_Trending/cl/Claude-Code-Game-Studios导读本文基于 Claude Code Game StudiosCCGS技能测试框架中的 ue-umg-specialist Agent 测试规范系统讲解如何验证一个负责 Unreal Engine UMGUnreal Motion Graphics的 AI Agent 是否合格。你将从中学到该 Agent 的职责边界widget 层级设计、数据绑定、CommonUI 输入路由、widget 性能优化与红线绝不越权设计 UX 流程以及用 5 个典型测试用例库存面板数据绑定、UX 流拒绝、CommonUI 按键不响应、500 个 widget 实例卡顿、既有 InputAction 标签上下文驱动行为验证的完整方法。读完本文你将能自己运行或编写同类 Agent 测试规格把AI 写 UE 界面这件事约束在可靠、可复现、不越界的轨道上。一、规格定位这份文档在测试什么在 CCGS 框架中49 个 AI Agent 各自拥有一个行为测试规格文件Agent Test Spec而 ue-umg-specialist.md 是 Unreal 引擎线中专职 UMG 界面实现的 Agent 的规格。按照 框架 README 的说明这套测试基础设施的对象是技能和 Agent 本身而非用它们开发出的游戏——因此本规格验证的是当开发者向这个 Agent 提出界面需求时它是否给出正确的 UMG 结构、正确的数据绑定方式、正确的 CommonUI 接入以及是否守住自己的领域边界。从 Agent 分层看ue-umg-specialist 属于unreal引擎类专精 Agent与 unreal-specialist、ue-blueprint-specialist、ue-gas-specialist、ue-replication-specialist 并列。它在质量评估标准 quality-rubric.md 中归入engine类别需满足三条引擎类指标指标通过标准E1 — 版本感知在给出 API 建议前引用docs/engine-reference/中的引擎版本并对超出训练截止时间的新 API 作出标记E2 — 文件路由将文件类型路由到正确的子专精 Agent例如.gdshader交给 shader 专家而非 gdscript 专家E3 — 引擎专属模式强制使用引擎专属惯例如 Blueprint Function Library、GAS 标签层级等1.1 Agent 摘要它拥有什么不拥有什么规格开头的 Agent Summary 用四条声明划清了领域Domain拥有的UMG widget 层级设计、数据绑定模式、CommonUI 输入路由与 action tags、widget 样式WidgetStyle 资产、UI 优化widget pooling、ListView、invalidation。Does NOT own不拥有的UX 流程与界面导航设计归 ux-designer、游戏玩法逻辑归 gameplay-programmer、后端数据源游戏代码、服务器通信。Model tierSonnet专精 Agent 的默认档位。Gate IDs无UX 流程决策一律交给 ux-designer。这四条声明是整份规格的基石后续所有测试用例本质都是在检验这四条边界是否被真实遵守。1.2 静态断言不跑行为也能做的结构检查静态断言Static Assertions检查的是规格文件本身的四项结构要求description:字段存在且领域相关须提及 UMG、widget hierarchy、CommonUIallowed-tools:列表与角色匹配可读/写 UI 资产与 Blueprint 文件不含服务器或玩法源码工具模型档位为 Sonnet专精 Agent 默认值Agent 定义不得声称对 UX 流程、导航架构或玩法数据逻辑拥有裁决权。这组断言与 agent-test-spec 模板 中frontmatter 含 name/description/model/tools、领域清晰、不越权决策的要求一脉相承属于无需夹具、纯结构化的快速检查。二、Case 1域内请求——带数据绑定的库存 widget输入创建一个库存 widget显示物品格子网格。每个格子显示物品图标、数量和稀有度颜色并在库存变化时更新。这是典型的 UMG 域内需求规格要求 Agent 的输出必须同时覆盖三个层面UMG widget 结构父级WBP_Inventory内含UniformGridPanel或TileView每个物品对应一个子 widgetWBP_InventorySlot。数据绑定方案二选一——要么在 Inventory Component 上通过 Event Dispatchers 触发刷新要么使用ListView 实现了IUserObjectListEntry接口的 UObject 物品数据类。稀有度颜色驱动方式通过 WidgetStyle 资产或数据表查找驱动严禁硬编码颜色值。输出形式必须包含 widget 层级、绑定模式和刷新触发机制三件套而不是一段大概这样写的自由发挥。这里可以对照 ue-gas-specialist.md 的做法理解本规格的输出结构化传统GAS 专家被要求产出 ability 类骨架 GameplayEffect 定义UMG 专家则被要求产出 widget 层级 绑定模式 刷新机制二者都是具体可落地的结构而非泛泛概念。如果库存数据本身来自 GAS 属性集规格隐含的协作路径是与 ue-gas-specialist 对接而不是自己发明数据源。三、Case 2域外请求——拒绝 UX 流程设计输入设计我们库存系统的完整导航流——玩家如何打开它、过渡到角色属性页、再退出到暂停菜单。期望行为Agent不得产出导航流或界面切换架构必须明确声明导航流和界面过渡设计由 ux-designer 负责一旦流程确定我可以实现对应的 UMG widget 结构在拿到 UX 规格之前不得做出任何 UX 决策返回键行为、过渡动画、模态 vs 全屏。这条用例直接对应用户需求中域外请求需重定向到正确 Agent而非默默处理的协作协议见 agent-test-spec 模板 的 Case 2。同时它也印证了 ux-designer.md 的领域声明——UX 专家负责用户流程、交互设计、信息架构其输出是流程状态图与输入映射而UI 实现代码属于 ui-programmer / 引擎 UMG 专家。两个规格相互咬合ue-umg-specialist 不画流程图ux-designer 不写实现代码中间通过一份 UX flow spec 完成交接。这也是整个 CCGS 分工哲学在 UI 领域的缩影流程UX与实现UMG分离Agent 不得越权做绑定决策。四、Case 3领域边界——CommonUI 输入 action 不匹配输入我们的库存 widget 不响应手柄 Back 键我们在用 CommonUI。这是全规格中技术密度最高的用例期望 Agent 能按三层结构诊断定位根因widget 的 Back 输入 action tag 与项目注册的 CommonUIInputAction数据资产不一致。解释 CommonUI 输入路由模型widget 通过CommonUI_InputAction标签声明输入动作CommonActivatableWidget负责路由分发。给出修复核对 widget 的 Back action tag 与项目 CommonUI 输入动作数据表中注册的 tag 是否一致。区分边界这属于输入路由层问题不是硬件输入绑定问题——后者属于 Enhanced Input 的领域。规格的 Coverage Notes 明确指出本用例要求项目已配置 CommonUI若项目未使用 CommonUI 则跳过测试。这条用例之所以被列为输入路由正确性的核心检查是因为在 CCGS 的engine类指标E1 版本感知、E3 引擎专属模式下Agent 必须掌握 CommonUI 这一 UE 官方 UI 框架的正确接入方式而非用事件图里绑个按键这种绕过式做法。五、Case 4widget 性能问题——单帧 500 个实例的卡顿输入我们的排行榜 widget 一次性创建了 500 个独立的WBP_LeaderboardRow实例打开排行榜时游戏卡顿 300ms。期望行为按优先级逐层给出定位根因单帧内 500 次 widget 实例化造成构造卡顿construction hitch。首选方案改用ListView或TileView配合虚拟化——只有可见行才会被构造并要求讲解 ListView 数据对象必须实现IUserObjectListEntry接口这一前提。备选方案若 ListView 不适用则改用 widget pooling——预先实例化固定数量的行用新数据循环复用。输出要求必须给出用哪个具体 UMG 组件的明确建议而不是一句空泛的优化一下。这条用例在规格中被标注为高影响失败模式300ms 卡顿属于阻断发行的缺陷shipping-blocking应优先执行。它同时呼应了 quality-rubric.md 中 E3 指标引擎专属惯例——虚拟化列表正是 UE 官方推荐的 UI 性能模式。规格的协议合规清单还固化了优先级顺序先推荐虚拟化列表ListView/TileView再考虑 widget pooling防止 Agent 跳过现代方案直接采用老旧做法。六、Case 5上下文传递——CommonUI 已配置时的行动约束输入上下文项目使用 CommonUI已注册的 InputAction 标签为UI.Action.Confirm、UI.Action.Back、UI.Action.Pause、UI.Action.Secondary。输入给库存 widget 加一个可用 CommonUI 操作的排序库存按钮。期望行为优先使用UI.Action.Secondary若该标签已被占用则建议注册新标签如UI.Action.Sort。不得擅自发明新 InputAction 标签——若确需新标签必须注明需在 CommonUI 数据表中注册。当 CommonUI 已是既定模式时不得退回非 CommonUI 的输入绑定方式如在 Event Graph 里直接绑定原始按键。建议中须显式引用上下文提供的标签清单。规格将这条用例定义为UI 管线一致性最重要的上下文感知测试。这与 unreal-specialist.md 的 Case 5依据项目声明版本给出 API以及 ue-gas-specialist.md 的 Case 5只使用上下文中已存在的属性名不发明新属性一脉相承——CCGS 框架反复检验的正是 Agent 使用既有项目状态、而非凭空臆造的能力。七、协议合规清单与覆盖说明7.1 Protocol Compliance 五项检查规格末尾用五条勾选清单汇总了该 Agent 的行为底线停留在声明领域内UMG 结构、数据绑定、CommonUI、widget 性能将 UX 流程与导航设计请求重定向给 ux-designer返回结构化结论widget 层级 绑定模式而非自由散漫的意见使用上下文中已有的 CommonUI InputAction 标签发明新标签时必须标注注册要求大集合场景下先推荐虚拟化列表ListView/TileView再考虑 widget pooling。对照 quality-rubric.md 的specialist类别指标S1 守领域、S2 不越权做绑定决策、S3 正确重定向而非沉默拒绝可以看出这五项正是那些通用指标在 UMG 场景下的具体化。7.2 Coverage Notes测试的执行方式与优先级规格最后明确了三条覆盖说明Case 3 前置条件CommonUI 输入路由测试依赖项目已配置 CommonUI未使用 CommonUI 的项目跳过此用例。Case 4 优先级最高300ms 卡顿是阻断发行的失败模式优先执行。Case 5 重要性上下文感知是 UI 管线一致性的最关键检验。无自动化运行器此类 Agent 行为测试需要人工评审或通过/skill-test技能运行。关于最后一点skill-test.md 说明了运行方式/skill-test spec [name]会读取测试规格文件并逐条用例评估产出逐条 PASS/FAIL 结果表与整体结论PASS / PARTIAL / FAIL发现问题的下一步是/skill-improve [name]进入测试 → 诊断 → 提议修复 → 重测循环。整个流程不写任何文件保持只读评审。若发现问题属于规格本身可参照 agent-test-spec 模板 的结构修订后在 catalog.yaml 中登记测试结果如last_spec_result。八、总结一份可复用的 UMG Agent 验收清单ue-umg-specialist 测试规格的价值不止于这一位 Agent。它示范了为引擎专精 Agent 编写验收标准的通用模板用领域声明划定边界拥有什么、不拥有什么、模型档位、gate 归属用静态断言保证规格文件自身结构合规用域内用例验证技术能力结构 绑定模式 刷新机制的可落地输出用域外用例验证谦逊拒绝并重定向绝不越权设计 UX用边界用例验证诊断深度CommonUI 路由 vs Enhanced Input 的区分用性能用例验证工程底线虚拟化优先、pooling 次之、具体组件而非空话用上下文用例验证一致性沿用既有标签、不发明、不绕行。把这七步套用到任何新 Agent 上你就能得到一份像这份 UMG 规格一样、既守边界又保质量的行为测试文档——而这正是 Claude Code Game Studios 用 49 个 Agent 支撑起完整游戏开发流程的关键保障机制。【免费下载链接】Claude-Code-Game-StudiosTurn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.项目地址: https://gitcode.com/GitHub_Trending/cl/Claude-Code-Game-Studios创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考