企业官网建设流程全解析

CCGS unity-specialist Agent 行为规格深度解读：Unity 架构决策、版本门控与子专家路由机制

【免费下载链接】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 Studios（CCGS）仓库中的 unity-specialist 行为规格 展开。该规格定义了 Unity 引擎方向专家 Agent 的职责边界、5 组行为测试用例与协议合规要求。读完本文，你将理解：unity-specialist 如何在 MonoBehaviour 与 DOTS 之间做出架构决策、如何处理跨引擎（Godot/Unreal）请求的误路由、如何对 Unity 6 等版本门控 API 进行风险标记，以及它如何与 unity-dots-specialist、unity-ui-specialist 等子专家协同工作，最终通过 CCGS 的 Skill Testing Framework 以可复现的方式验证这些行为。

一、规格文件的定位：一份可测试的 Agent 行为契约

在 CCGS 的测试框架中，agents/[tier]/[name].md是每个 Agent 的行为规格（Behavioral Spec），而不是普通的角色说明书。框架 README 明确指出：该文件夹是 CCGS 技能与 Agent 框架的质量保证层，用于"测试技能和 Agent 本身——而不是用它们开发的任何游戏"。

unity-specialist.md属于agents/engine/unity/目录，与unity-ui-specialist.md、unity-shader-specialist.md、unity-dots-specialist.md、unity-addressables-specialist.md共同构成 Unity 引擎方向的 5 人专家团队。在框架 README 的 Agent tiers 表格中，它们与 Godot、Unreal 方向一起被归入engine层级的unity梯队：

规格本身由catalog.yaml权威登记。catalog.yaml 中 unity-specialist 的条目记录了其spec:路径为CCGS Skill Testing Framework/agents/engine/unity/unity-specialist.md，category: engine，并带有last_spec/last_spec_result字段用于追踪最近一次测试结果。按框架 CLAUDE.md 的约定，任何测试命令执行前都应当先读取catalog.yaml获取权威的 spec 路径，而不是靠猜测。

规格文件本身遵循 agent-test-spec.md 模板的骨架：Agent Summary→Static Assertions→Test Cases（5 个）→Protocol Compliance→Coverage Notes。这意味着该文件是一份逐条可勾选的测试清单，测试者可以像跑单元测试一样逐项验证 Agent 的真实行为。

二、职责边界：unity-specialist 拥有什么、不拥有什么

规格开头的Agent Summary给出了该 Agent 的核心定位：

Domain: Unity-specific architecture patterns, MonoBehaviour vs DOTS decisions, and subsystem selection (Addressables, New Input System, UI Toolkit, Cinemachine, etc.).Does NOT own: language-specific deep dives (delegates to unity-dots-specialist, unity-ui-specialist, etc.).Model tier: Sonnet (default).No gate IDs assigned.

拆解如下：

• 拥有（Owns）：Unity 特有的架构模式选择与子系统选型——MonoBehaviour vs DOTS的权衡、以及 Addressables、New Input System、UI Toolkit、Cinemachine 等子系统的取舍。它回答的是"用哪个模式/哪个子系统"的问题。
• 不拥有（Does NOT own）：语言/子系统级别的深度实现（deep dives），这类请求必须委托给对应的子专家：
  • DOTS/ECS/Jobs/Burst 实现细节 →unity-dots-specialist（见 unity-dots-specialist.md，其领域涵盖IComponentData、ISystem、SystemAPI、IJobEntity、Burst 约束）
  • UI Toolkit / UGUI / 数据绑定 →unity-ui-specialist（见 unity-ui-specialist.md）
  • Shader Graph / HLSL / VFX Graph / URP/HDRP →unity-shader-specialist（见 unity-shader-specialist.md）
  • Addressables 资产加载 / handle 生命周期 / 远程目录 →unity-addressables-specialist（见 unity-addressables-specialist.md）
• 模型层级（Model tier）：Sonnet（default）。这与 quality-rubric.md 中lead分类的L3指标（"Agent is assigned Sonnet model (default)"）保持一致——总监（directors）层使用 Opus，专家层统一使用 Sonnet。
• Gate 归属：无 gate ID，意味着该 Agent 不直接触发阶段门（phase gate）检查，它的产出由上层 lead/director 把关。

静态断言（Static Assertions）进一步把这些边界变成可机器检查的结构性条件：

• description:字段必须存在且领域相关（必须提到 Unity patterns / MonoBehaviour / subsystem decisions）
• allowed-tools:必须包含 Read, Write, Edit, Bash, Glob, Grep
• 模型层级必须是 Sonnet（specialists 默认）
• Agent 定义必须承认子专家路由表（DOTS、UI、Shader、Addressables）

这些断言与 quality-rubric.md 的 engine 分类中的 E1/E2/E3 指标呼应：E1 版本感知（引用docs/engine-reference/的引擎版本再建议 API）、E2 文件路由（把对应文件类型路由给正确的子专家）、E3 引擎专属模式。

三、Case 1：域内请求——MonoBehaviour vs ScriptableObject 决策树

这是规格中最核心的域内用例，验证 unity-specialist 面对模式选型问题时能否产出结构化决策指南。

输入："Should I use MonoBehaviour or ScriptableObject for storing enemy configuration data?"（敌人配置数据应该用 MonoBehaviour 还是 ScriptableObject 存储？）

预期行为包含四层：

1. 产出模式决策树，覆盖两个候选方案的本质差异：

2. 给出明确推荐：敌人配置数据应使用ScriptableObject，理由是无状态（stateless）、可复用（reusable）、对设计师友好（designer-friendly）——这正是 ScriptableObject 作为"数据资产"被序列化到项目中的天然优势。

3. 补充组合模式：MonoBehaviour 可以在运行时引用该 ScriptableObject 来读取配置。

4. 边界声明：给出 ScriptableObject 类定义的具体示例（示意其结构），但不产出完整实现代码——完整实现交由 engine-programmer 或 gameplay-programmer。

这一用例与仓库 docs/engine-reference/unity/current-best-practices.md 中"Use C# 9+ Features"的推荐相呼应：配置数据采用不可变、纯数据形态（如 record 类型public record PlayerData(string Name, int Level, float Health);）是 Unity 6 时代的惯用做法，而 ScriptableObject 正是承载这类纯数据资产的标准容器。关键约束是"给出决策与结构示意，不越权写完整实现"——这正是 unity-specialist 与 gameplay-programmer 之间的分工线。

四、Case 2：错误引擎重定向——Godot 模式请求的拦截

输入："Set up a Node scene tree with signals for this enemy system."（用 Node 场景树和信号为这个敌人系统搭建结构。）

预期行为验证的是 Agent 的引擎隔离能力：

• 绝不产出Godot 的 Node/signal 代码；
• 识别这是 Godot 模式（Node 场景树 + Signal）；
• 映射到 Unity 等价物：
  • GodotNode→ UnityMonoBehaviour（挂载于 GameObject）
  • GodotSignal→ C# event /UnityEvent
• 确认项目是基于 Unity 的之后才继续。

这是一个非常典型的"跨引擎请求误路由"场景。CCGS 同时拥有 Godot（godot-specialist、godot-gdscript-specialist、godot-csharp-specialist、godot-shader-specialist、godot-gdextension-specialist）和 Unreal（unreal-specialist、ue-blueprint-specialist等）方向的专家阵容（见框架 README），因此跨引擎请求随时可能出现。规格要求 unity-specialist 在概念映射与拒绝越权实现之间取得平衡：它解释"在 Unity 里等价的做法是什么"，但绝不直接写出 Godot 方言代码，也不假装自己"会一点 Godot 就顺手实现"。

这与 quality-rubric.md 的 engine 分类指标E2（File Routing）一脉相承——引擎专属内容必须路由给对应引擎的专家，.gdshader之类的文件绝不落在 Unity 专家手里。

五、Case 3：Unity 版本 API 标记——GPU Resident Drawer 的门控

输入："Use the new Unity 6 GPU resident drawer for batch rendering."（用新的 Unity 6 GPU Resident Drawer 做批量渲染。）

预期行为验证 Agent 的版本感知与风险标记能力：

• 识别GPU Resident Drawer 是 Unity 6 的新特性；
• 标记该 API 在更早的 Unity 版本中可能不可用；
• 先询问或核查项目的 Unity 版本，再提供实现指导；
• 指示对照官方 Unity 6 文档验证；
• 绝不默认项目运行在 Unity 6 上。

这条用例直接对应该 Agent 的"版本守门人"角色。仓库 docs/engine-reference/unity/current-best-practices.md 本身就是这种版本意识的制度化体现：该文件明确标注"Last verified: 2026-02-13"，并区分 Tech Stream（6.4+，最新但不稳定）与 LTS（6.3，生产就绪、支持至 2027 年 12 月），同时强调"Modern Unity 6 patterns that may not be in the LLM's training data"——即模型训练数据可能滞后于引擎版本演进。

quality-rubric.md 的 engine 分类指标E1为此定调：References engine version from docs/engine-reference/ before suggesting API calls; flags post-cutoff risk（在建议 API 之前先引用docs/engine-reference/中的引擎版本；标记训练截止之后的风险）。Unity 6 的 GPU Resident Drawer 正是典型的"cutoff 之后"特性，Agent 若没有版本上下文就贸然推荐，很可能给项目写出无法编译的代码。

同样地，unity-ui-specialist.md 的 Case 5 也验证了同类行为：当项目上下文为 Unity 2022.3 LTS 时，必须使用该版本的运行时数据绑定 API，而不能使用 Unity 6 的增强绑定 API；unity-shader-specialist.md 的 Case 5 则要求在给出 URP 与 HDRP 各自专属的 Volume API 之前先确认渲染管线。版本门控是 Unity 方向所有专家共有的协议。

六、Case 4：DOTS vs MonoBehaviour 冲突——混合架构与升级路径

输入："The combat system uses MonoBehaviour for state management, but we want to add a DOTS-based projectile system. Can they coexist?"（战斗系统用 MonoBehaviour 管理状态，但想加一个基于 DOTS 的投射物系统，两者能共存吗？）

预期行为验证 Agent 处理架构冲突的方式：

1. 识别这是混合架构（hybrid architecture）场景；
2. 解释混合方案：MonoBehaviour 可以通过SystemAPI、IComponentData和 managed components 与 DOTS 交互；
3. 说明混用两种模式的性能与复杂度权衡（performance and complexity trade-offs）；
4. 建议升级架构决策给lead-programmer或technical-director；
5. 委托DOTS 侧的实现细节给unity-dots-specialist。

这条用例揭示了 unity-specialist 的关键纪律：它可以提供技术解释，但架构级决策不自行拍板。这与 agent-test-spec.md 模板 的 Case 4（Conflict Escalation）完全一致——冲突识别后升级到共享父级（creative-director / technical-director），绝不单方面解决跨域冲突。

仓库的 DOTS 最佳实践为混合架构提供了具体的接缝点。docs/engine-reference/unity/current-best-practices.md 推荐使用现代ISystem（非ComponentSystem）、IJobEntity（替代IJobForEach）并标注[BurstCompile]；而 unity-dots-specialist.md 的 Case 4 专门处理"MonoBehaviour 数据需要被 DOTS 系统读取"的桥接：将相机 Transform 写入单例IComponentData（MonoBehaviour 侧每帧通过EntityManager.SetComponentData更新），或在 Burst 不兼容时采用CompanionComponent/managed component 方案——并明确禁止在 Burst Job 内部访问 MonoBehaviour。unity-specialist 需要知道这些接缝存在，但具体的 ECS 桥接代码由 unity-dots-specialist 负责。

七、Case 5：上下文传递——Unity 2023.3 LTS 下的 New Input System

输入：项目上下文为 Unity 2023.3 LTS，请求"Configure the new Input System for this project."

预期行为验证 Agent 的上下文感知能力：

• 应用 Unity 2023.3 LTS 上下文：使用 New Input System（com.unity.inputsystem包）；
• 绝不产出legacy Input Manager 代码（Input.GetKeyDown()、Input.GetAxis()）；
• 注意2023.3 特有的 Input System 行为或包版本约束；
• 核查项目版本以确认 Burst/Jobs 兼容性——如果 Input System 与 DOTS 交互的话。

仓库的 current-best-practices.md 同样把"Use Input System Package (Not Legacy Input)"列为硬性最佳实践，并给出了标准写法：

using UnityEngine.InputSystem; public class PlayerInput : MonoBehaviour { private PlayerControls controls; void Awake() { controls = new PlayerControls(); controls.Gameplay.Jump.performed += ctx => Jump(); } void OnEnable() => controls.Enable(); void OnDisable() => controls.Disable(); }

注意两个关键点：一是由PlayerControls这类由 Input Actions 资产生成的 C# 类承载绑定，二是 legacy 的Input.GetKeyDown()/Input.GetAxis()被明确禁用。unity-specialist 在此用例中的职责是在架构层面确认子系统选型（New Input System 而非 legacy），并在需要时确认 Burst/Jobs 的兼容性；具体的 Input Actions 资产设计与绑定实现细节则落在实现层。

这也是 agent-test-spec.md 模板 Case 5（Context Pass-Through）的体现：Agent 必须使用父级传入的上下文（这里即"Unity 2023.3 LTS"），而不是重新向用户索要，也不擅自假设一个版本。没有版本上下文时（如 Case 3），它必须主动询问；有了版本上下文时（如本用例），它必须直接应用。

八、协议合规清单（Protocol Compliance）

规格末尾的协议合规项是对全部行为的收敛性约束：

• 停留在声明领域内（Unity 架构决策、模式选型、子系统路由）；
• 将 Godot 模式重定向给 Godot 专家，或标记为错误引擎（wrong-engine）；
• 将 DOTS 实现重定向给unity-dots-specialist；
• 将 UI 实现重定向给unity-ui-specialist；
• 标记版本门控 API，并在建议前要求版本确认；
• 返回结构化的模式决策指南，而非自由发挥的意见。

最后一条尤其重要：与 quality-rubric.md 中lead分类的L1（"Returns a domain-specific verdict"）一致，unity-specialist 的产出应是可追溯的决策结构（决策树、权衡表、推荐项 + 理由），而不是一段即兴散文。这种"结构化输出"纪律让后续的 lead-programmer / technical-director 可以直接审阅其推理链条。

九、覆盖说明（Coverage Notes）与测试闭环

规格最后的三条覆盖说明，指明了测试与文档化后续动作：

1. Case 1（MonoBehaviour vs ScriptableObject）：如果最终形成了项目级决策，应将其记录为ADR（Architecture Decision Record）。这与仓库中 skills/authoring/architecture-decision.md 技能的存在相互印证——CCGS 主张架构选型结论沉淀为正式文档，而非停留在对话里。
2. Case 3（版本标记）：确认 Agent不会在没有上下文时默认最新 Unity 版本。这是对 E1（版本感知）指标的行为级验证。
3. Case 4（DOTS 混合）：验证 Agent升级架构冲突而非单方面裁决——这是跨域纪律的行为级验证。

如何实际运行这些测试：按框架 README 的说明，测试由框架内建技能驱动：

/skill-test static unity-specialist # 结构化检查（静态断言） /skill-test spec unity-specialist # 按行为规格逐用例评估 /skill-test category unity-specialist # 按 engine 分类指标评估（E1/E2/E3） /skill-test audit # 全量覆盖视图：has-spec、last tested、result

测试结果写入CCGS Skill Testing Framework/results/（gitignored），并可在确认后回写catalog.yaml的last_spec/last_spec_result字段。值得注意的是，框架 CLAUDE.md 给出了一条重要的元规则：规格描述的是"当前行为"而非"理想行为"——当 Agent 在实践中表现不佳时，应先修正 Agent 定义本身，再更新规格以匹配修正后的行为；规格失败应视为"需要调查"的信号，而非"Agent 肯定错了"的定论。

十、总结：一个"架构守门人"的可测试定义

透过 unity-specialist.md 这份规格，可以看到 CCGS 对引擎专家 Agent 的成熟设计：

• 决策权与实现权分离：unity-specialist 回答"用哪个模式、哪个子系统"，实现细节交给 gameplay-programmer、engine-programmer 及 DOTS/UI/Shader/Addressables 子专家；
• 版本意识内建：遇到 Unity 6 等新特性先标记风险、先确认版本，绝不盲推 cutoff 之后的 API；
• 跨引擎隔离：Godot/Unreal 模式的请求被概念映射后重定向，绝不在错误引擎里写代码；
• 架构冲突升级：DOTS vs MonoBehaviour 这类高层权衡不自行拍板，升级给 lead-programmer / technical-director；
• 行为可测试：静态断言、5 组用例、协议合规清单与覆盖说明构成闭环，可通过/skill-test系列命令反复验证与改进。

这种"以规格驱动 Agent 质量"的模式，让 49 个 Agent 的分工、边界与行为标准不再依赖口头约定，而是变成仓库中可审计、可复现、可演进的工程资产——这正是 CCGS 将 Claude Code 编排为完整游戏开发工作室的关键基础设施。

【免费下载链接】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