CCGS UI Programmer Agent 测试规范全解读领域边界、跨角色协作与引擎 UI 工具链的验收基线【免费下载链接】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中 UI Programmer 专项 Agent 的行为测试规范CCGS Skill Testing Framework/agents/specialists/ui-programmer.md展开完整解析其职责域划分、5 条测试用例的判定逻辑与协议合规清单并结合仓库中的质量标尺、Agent 编目与 Godot 4.6 引擎参考文档说明这套规范如何在真实项目中落地为可执行、可复现的 Agent 验收流程。读完本文你将掌握 CCGS 如何用「静态断言 行为用例 协议合规」三层结构约束一个 UI 实现型 Agent以及如何把它接入/skill-test测试框架进行逐条验证。一、文档定位一份用于质量验证的 Agent 行为测试规范在 CCGS 中Agent 的岗位说明书并不直接描述功能而是描述应当表现出的行为。UI Programmer 的这份文档属于agents/specialists/层级与 agent-test-spec.md 模板 同构由 Agent Summary、Static Assertions静态断言、Test Cases测试用例、Protocol Compliance协议合规、Coverage Notes覆盖说明五个部分构成。它在整个质量保障体系中的位置可以从 catalog.yaml 中确认ui-programmer的spec字段被登记为CCGS Skill Testing Framework/agents/specialists/ui-programmer.mdcategory为specialist——即与 gameplay-programmer、technical-artist、ux-designer 等并列的核心专项 Agent。根据 CCGS Skill Testing Framework/CLAUDE.md 的说明Agent 规范文件agents/[tier]/[name].md统一包含「5 条测试用例 协议合规断言」并且这些规范描述的是当前行为而非理想行为——它们是从 Agent 定义中逆向读出的可能编码了 bug。因此当 Agent 在实践中表现异常时正确顺序是先修正 Agent 本体再更新规范使其与修复后的行为一致规范失败应被理解为需要调查而非Agent 绝对错了。二、UI Programmer 的职责领域与边界2.1 明确拥有的域文档在 Agent Summary 中划定了 UI Programmer 的核心领域菜单界面Menu screensHUDHeads-Up Display物品栏/库存界面Inventory screens对话气泡Dialogue boxesUI 框架代码UI framework code数据绑定Data binding2.2 明确不拥有的域同时文档严格声明了两条边界防止越权UX 流程设计不属于 UI Programmer归属ux-designer交互流程、信息架构、输入方案设计视觉风格方向不属于 UI Programmer归属art-director/technical-artist。这一划分在 ux-designer 测试规范 中形成了双向印证ux-designer 的 Case 2 明确写着UI 代码实现属于ui-programmer应重定向并补充UX 流程规格应作为实现参考提供给 ui-programmer。也就是说两份规范互为对方的边界契约——设计端不写代码实现端不设计流程。2.3 模型档位与门禁Model tierSonnet默认——与 quality-rubric.md 中 specialist 类目S1–S3以及Sonnet model tierdefault per coordination-rules的 lead 类目 L3 一致No gate IDs assigned——UI Programmer 不触发导演级director门禁属于纯执行型专项 Agent。三、静态断言结构性检查Static Assertions规范要求通过 4 项静态断言来约束 Agent 定义文件本身的结构#断言含义1description:字段存在且领域相关必须提及 menus / HUDs / UI framework / data binding 等关键词2allowed-tools:列表包含 Read、Write、Edit、Bash、Glob、Grep具备读写与检索能力可产出实现代码3模型档位为 Sonnet符合 specialist 默认档位4Agent 定义不得声称拥有 UX 流程设计与视觉美术方向的权威与 2.2 的边界契约一致这些断言与通用模板 agent-test-spec.md 中Frontmatter hasname,description,model,toolsfields的要求呼应只是针对 UI 领域做了更细的约束——尤其是第 4 条用结构化的方式把不越权写死成可检查的规则而不是依赖模型自觉。四、五条行为测试用例判定逻辑逐条拆解Case 1域内请求——按 UX 规格实现库存界面输入Implement the inventory screen from the UX spec indesign/ux/inventory-flow.md.期望行为先读规格再写码生产任何代码前必须先读取 UX 规格使用项目配置的 UI 框架UI Toolkit、UGUI、UMG 或 Godot Control 节点按项目实际引擎选择实现规格中定义的全部状态default、hover、selected、empty-slot、locked-slot——注意 empty-slot 与 locked-slot 这两个易被遗漏的空态/锁定态数据绑定走项目数据模型禁止硬编码值公开 UI API 需带文档注释遵循编码规范。这条用例的本质是验证实现忠实于规格 遵守工程规范两个维度。它隐含了一个值得注意的映射五个 UI 状态default/hover/selected/empty-slot/locked-slot与 ux-designer 测试规范 Case 1 中要求定义的交互状态完全一致——设计端产出状态定义实现端逐状态落地规范层面已经预埋了同一份状态清单的契约。Case 2域外请求——正确重定向输入Design the inventory interaction flow — what happens when the player equips, drops, or combines items.期望行为不得产出交互流程设计或用户流程图明确声明 UX 流程设计归属ux-designer将请求重定向给ux-designer同时注明流程规格就绪后UI Programmer 可以接手实现。这是一条拒绝但不沉默的用例不是简单拒绝而是指明归属方 说明后续可承接的时机。这与 quality-rubric.md 中 specialist 类目的 S3 指标域外请求应重定向到正确的 Agent而不是沉默拒绝完全对齐。Case 3自定义动画协调——与 technical-artist 协作输入The item selection in the inventory needs a custom bounce animation when selected.期望行为识别出动画曲线与手感feel的定义属于 technical-artist 领域在没有规格时不得自行发明动画参数时长、缓动与technical-artist协调获取动画规格duration时长、easing curve缓动曲线、overshoot amount过冲量规格到位后产出将动画绑定到选择状态的实现。对照 technical-artist 测试规范 的域声明Shaders、VFX、渲染优化、美术管线工具动画参数的手感定义确实落在 technical-artist 一侧。这条用例精准地检验了 Agent 对参数所有权的敏感度实现动画代码是 UI Programmer 的活但定义弹得有多狠、缓多久不是——没有规格就乱填数值正是项目设计哲学中要避免的hardcoding magic numbers见 README.md 的 Why This Exists 章节。Case 4模糊 UX 规格——标记回写而非猜测输入UX 规格写了show item details on selection但没有定义空槽位被选中时该发生什么。期望行为识别出规格中的歧义空槽位选择状态未定义不为该未定义状态做武断的实现决策将歧义回传ux-designer并附上具体问题What should the detail panel show when an empty inventory slot is selected?可提出两种常见选项隐藏面板 / 显示占位符帮助 ux-designer 快速决策。这条用例把规格缺口路由回作者变成了硬性要求。Coverage Notes 中特别强调此用例验证 Agent 把规格缺口路由回创作方 Agent而不是自行猜测。它与 CCGS 的协作协议Ask → Present options → You decide → Draft → Approve见 README.md一脉相承——用户和创作方始终保留决策权。Case 5上下文传递——引擎 UI 工具链Godot 4.6输入引擎上下文为 Godot 4.6 Control 节点 UI。请求Implement a scrollable item list for the inventory.期望行为使用 Godot 的ScrollContainerVBoxContainerItemList或等价模式不得产出 Canvas 或 UGUI 代码对 Godot 项目不得产出 Unity UGUI 或 Unreal UMG 代码严禁跨引擎代码使用具体 API 前**核对引擎版本参考4.6**中 4.4/4.5 起的 Control 节点 API 变化产出与项目配置语言一致的 GDScript 或 C# 代码。这条用例在仓库中有着扎实的支撑材料。首先docs/engine-reference/godot/VERSION.md 记录了引擎钉住版本为Godot 4.62026 年 1 月发布且明确指出LLM 训练数据大概率只覆盖到约 4.34.4/4.5/4.6 引入了模型不知道的重大变更建议任何 Godot API 前必须先对照本目录——这正好解释了为什么规范要求用 API 前先查版本参考。其次docs/engine-reference/godot/modules/ui.md 给出了与本例直接相关的 4.6 新行为双焦点系统4.6 变更鼠标/触摸焦点与键盘/手柄焦点已分离二者可同时作用于不同控件UI 必须同时用鼠标和键盘/手柄测试——这直接关系到 inventory 列表的选中高亮与滚动交互4.5 新增FoldableContainer手风琴式折叠节点与Recursive Control 行为单属性递归禁用整个节点层级本地化就绪实践可见字符串一律用tr()标签开启autowrap_mode——与 UI Programmer 域中对话气泡、菜单文案场景强相关。一个典型的 Godot 实现骨架基于该参考文档的 API 模式大致形如extends Control onready var item_list: ItemList %ItemList func _ready() - void: # 数据绑定从项目数据模型填充而非硬编码 for item in InventoryModel.items(): item_list.add_item(item.display_name) # 键盘/手柄焦点4.6 中 grab_focus 仅影响键盘/手柄焦点 %InventoryButton.grab_focus()五、协议合规清单验收时逐项勾选规范末尾给出 6 项协议合规断言作为任何一轮测试的汇总判定依据停留在声明域内menus、HUDs、UI framework、data binding将 UX 流程设计重定向给 ux-designer实现动画前与 technical-artist 协调动画规格模糊 UX 规格回传 ux-designer而非擅自做实现决策返回结构化输出实现代码、数据绑定模式、UI 状态的状态机对项目使用正确的引擎 UI 工具集——永不跨引擎输出代码可以看到6 项中有 4 项都在约束边界与协作只有 2 项关乎产出质量本身。这反映了 CCGS 的设计取向对执行型 Agent最大的风险不是代码写得差而是越权决策和规格失配。六、覆盖说明验收后的落地动作Coverage Notes 补充了三条跟进约定Case 1 的库存实现应在production/qa/evidence/下留有 UI 交互测试或人工走查文档——实现不算完要有证据沉淀Case 3 的动画协调确认 Agent 不会在无规格时发明手感参数Case 4 的模糊规格验证 Agent 将规格缺口路由回创作方而非猜测。这三条把验收通过延伸到证据归档层面与 quality-rubric.md 中 QA 类目 Q2测试用例须符合项目的测试证据格式的设计思路一致。七、如何用 /skill-test 跑通这套规范根据 CCGS Skill Testing Framework/CLAUDE.md 定义的测试工作流验证 ui-programmer 的标准流程是读 catalog.yaml拿到 Agent 的spec:路径CCGS Skill Testing Framework/agents/specialists/ui-programmer.md与categoryspecialist读 Agent 定义文件.claude/agents/ui-programmer.md即被测试对象本体读规范文件本文讨论的这份文档逐用例评估断言对 5 个 Case 分别给出 PASS / FAIL / PARTIAL将结果写入results/并更新catalog.yaml中的last_spec/last_spec_result字段该目录为 gitignore不影响仓库本体。结构断言前文第三节的 4 项静态断言由/skill-test static自动执行行为断言第四节 5 个 Case则依赖人工或 LLM 逐条对照。若想进一步把 ui-programmer 纳入类别评分可参考 skill-test.md 中定义的四种模式static / spec / audit / category与 quality-rubric.md 中 specialist 类目的三把尺子指标判定标准S1 — Stays in domain明确将自身限定在声明域内域外请求予以延迟/转交S2 — No binding cross-domain decisions不单方面决定其他专项 Agent 管辖的事项S3 — Defers correctly域外请求重定向到正确的 Agent而非沉默拒绝对照可见ui-programmer 规范的 5 个 Case 与 S1–S3 形成了一一对应的可执行投影Case 2/3/4 分别就是 S3正确重定向到 ux-designer、S2动画参数不越权、S1规格歧义不越权决策的行为化表达。结语UI Programmer 测试规范是 CCGS「用结构约束协作」理念的一个缩影一份不足百行的规范通过 4 项静态断言守住 Agent 定义的结构底线通过 5 条行为用例覆盖实现规格、重定向、动画协调、规格回传、引擎工具链选择五个高频风险场景再以 6 项协议合规清单收口。配合catalog.yaml的编目登记、quality-rubric.md的 specialist 类目评分以及 Godot 4.6 引擎参考 这类版本证据文件任何团队都可以把这套流程直接复制到自己的游戏项目中对UI 实现型 AI 工程师进行可复现、可追溯的质量验收。输出文章【免费下载链接】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），仅供参考