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 StudiosCCGS仓库中的 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梯队TierAgentsunityunity-specialist, unity-ui-specialist, unity-shader-specialist, unity-dots-specialist, unity-addressables-specialist规格本身由catalog.yaml权威登记。catalog.yaml 中 unity-specialist 的条目记录了其spec:路径为CCGS Skill Testing Framework/agents/engine/unity/unity-specialist.mdcategory: engine并带有last_spec/last_spec_result字段用于追踪最近一次测试结果。按框架 CLAUDE.md 的约定任何测试命令执行前都应当先读取catalog.yaml获取权威的 spec 路径而不是靠猜测。规格文件本身遵循 agent-test-spec.md 模板的骨架Agent Summary→Static Assertions→Test Cases5 个→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.拆解如下拥有OwnsUnity 特有的架构模式选择与子系统选型——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.mdShader Graph / HLSL / VFX Graph / URP/HDRP →unity-shader-specialist见 unity-shader-specialist.mdAddressables 资产加载 / handle 生命周期 / 远程目录 →unity-addressables-specialist见 unity-addressables-specialist.md模型层级Model tierSonnetdefault。这与 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 decisionsallowed-tools:必须包含 Read, Write, Edit, Bash, Glob, Grep模型层级必须是 Sonnetspecialists 默认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 存储预期行为包含四层产出模式决策树覆盖两个候选方案的本质差异维度MonoBehaviourScriptableObject用途运行时行为runtime behavior纯数据/配置pure data/configuration载体必须挂载到 GameObject 上作为资产asset存在生命周期有Update()等生命周期回调与场景无关no scene dependency共享性每个实例独立跨实例共享给出明确推荐敌人配置数据应使用ScriptableObject理由是无状态stateless、可复用reusable、对设计师友好designer-friendly——这正是 ScriptableObject 作为数据资产被序列化到项目中的天然优势。补充组合模式MonoBehaviour 可以在运行时引用该 ScriptableObject 来读取配置。边界声明给出 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挂载于 GameObjectGodotSignal→ C# event /UnityEvent确认项目是基于 Unity 的之后才继续。这是一个非常典型的跨引擎请求误路由场景。CCGS 同时拥有 Godotgodot-specialist、godot-gdscript-specialist、godot-csharp-specialist、godot-shader-specialist、godot-gdextension-specialist和 Unrealunreal-specialist、ue-blueprint-specialist等方向的专家阵容见框架 README因此跨引擎请求随时可能出现。规格要求 unity-specialist 在概念映射与拒绝越权实现之间取得平衡它解释在 Unity 里等价的做法是什么但绝不直接写出 Godot 方言代码也不假装自己会一点 Godot 就顺手实现。这与 quality-rubric.md 的 engine 分类指标E2File Routing一脉相承——引擎专属内容必须路由给对应引擎的专家.gdshader之类的文件绝不落在 Unity 专家手里。五、Case 3Unity 版本 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 Stream6.4最新但不稳定与 LTS6.3生产就绪、支持至 2027 年 12 月同时强调Modern Unity 6 patterns that may not be in the LLMs 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 的增强绑定 APIunity-shader-specialist.md 的 Case 5 则要求在给出 URP 与 HDRP 各自专属的 Volume API 之前先确认渲染管线。版本门控是 Unity 方向所有专家共有的协议。六、Case 4DOTS 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 处理架构冲突的方式识别这是混合架构hybrid architecture场景解释混合方案MonoBehaviour 可以通过SystemAPI、IComponentData和 managed components 与 DOTS 交互说明混用两种模式的性能与复杂度权衡performance and complexity trade-offs建议升级架构决策给lead-programmer或technical-director委托DOTS 侧的实现细节给unity-dots-specialist。这条用例揭示了 unity-specialist 的关键纪律它可以提供技术解释但架构级决策不自行拍板。这与 agent-test-spec.md 模板 的 Case 4Conflict 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 写入单例IComponentDataMonoBehaviour 侧每帧通过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 Systemcom.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 5Context 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分类的L1Returns a domain-specific verdict一致unity-specialist 的产出应是可追溯的决策结构决策树、权衡表、推荐项 理由而不是一段即兴散文。这种结构化输出纪律让后续的 lead-programmer / technical-director 可以直接审阅其推理链条。九、覆盖说明Coverage Notes与测试闭环规格最后的三条覆盖说明指明了测试与文档化后续动作Case 1MonoBehaviour vs ScriptableObject如果最终形成了项目级决策应将其记录为ADRArchitecture Decision Record。这与仓库中 skills/authoring/architecture-decision.md 技能的存在相互印证——CCGS 主张架构选型结论沉淀为正式文档而非停留在对话里。Case 3版本标记确认 Agent不会在没有上下文时默认最新 Unity 版本。这是对 E1版本感知指标的行为级验证。Case 4DOTS 混合验证 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
CCGS unity-specialist Agent 行为规格深度解读：Unity 架构决策、版本门控与子专家路由机制
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 StudiosCCGS仓库中的 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梯队TierAgentsunityunity-specialist, unity-ui-specialist, unity-shader-specialist, unity-dots-specialist, unity-addressables-specialist规格本身由catalog.yaml权威登记。catalog.yaml 中 unity-specialist 的条目记录了其spec:路径为CCGS Skill Testing Framework/agents/engine/unity/unity-specialist.mdcategory: engine并带有last_spec/last_spec_result字段用于追踪最近一次测试结果。按框架 CLAUDE.md 的约定任何测试命令执行前都应当先读取catalog.yaml获取权威的 spec 路径而不是靠猜测。规格文件本身遵循 agent-test-spec.md 模板的骨架Agent Summary→Static Assertions→Test Cases5 个→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.拆解如下拥有OwnsUnity 特有的架构模式选择与子系统选型——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.mdShader Graph / HLSL / VFX Graph / URP/HDRP →unity-shader-specialist见 unity-shader-specialist.mdAddressables 资产加载 / handle 生命周期 / 远程目录 →unity-addressables-specialist见 unity-addressables-specialist.md模型层级Model tierSonnetdefault。这与 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 decisionsallowed-tools:必须包含 Read, Write, Edit, Bash, Glob, Grep模型层级必须是 Sonnetspecialists 默认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 存储预期行为包含四层产出模式决策树覆盖两个候选方案的本质差异维度MonoBehaviourScriptableObject用途运行时行为runtime behavior纯数据/配置pure data/configuration载体必须挂载到 GameObject 上作为资产asset存在生命周期有Update()等生命周期回调与场景无关no scene dependency共享性每个实例独立跨实例共享给出明确推荐敌人配置数据应使用ScriptableObject理由是无状态stateless、可复用reusable、对设计师友好designer-friendly——这正是 ScriptableObject 作为数据资产被序列化到项目中的天然优势。补充组合模式MonoBehaviour 可以在运行时引用该 ScriptableObject 来读取配置。边界声明给出 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挂载于 GameObjectGodotSignal→ C# event /UnityEvent确认项目是基于 Unity 的之后才继续。这是一个非常典型的跨引擎请求误路由场景。CCGS 同时拥有 Godotgodot-specialist、godot-gdscript-specialist、godot-csharp-specialist、godot-shader-specialist、godot-gdextension-specialist和 Unrealunreal-specialist、ue-blueprint-specialist等方向的专家阵容见框架 README因此跨引擎请求随时可能出现。规格要求 unity-specialist 在概念映射与拒绝越权实现之间取得平衡它解释在 Unity 里等价的做法是什么但绝不直接写出 Godot 方言代码也不假装自己会一点 Godot 就顺手实现。这与 quality-rubric.md 的 engine 分类指标E2File Routing一脉相承——引擎专属内容必须路由给对应引擎的专家.gdshader之类的文件绝不落在 Unity 专家手里。五、Case 3Unity 版本 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 Stream6.4最新但不稳定与 LTS6.3生产就绪、支持至 2027 年 12 月同时强调Modern Unity 6 patterns that may not be in the LLMs 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 的增强绑定 APIunity-shader-specialist.md 的 Case 5 则要求在给出 URP 与 HDRP 各自专属的 Volume API 之前先确认渲染管线。版本门控是 Unity 方向所有专家共有的协议。六、Case 4DOTS 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 处理架构冲突的方式识别这是混合架构hybrid architecture场景解释混合方案MonoBehaviour 可以通过SystemAPI、IComponentData和 managed components 与 DOTS 交互说明混用两种模式的性能与复杂度权衡performance and complexity trade-offs建议升级架构决策给lead-programmer或technical-director委托DOTS 侧的实现细节给unity-dots-specialist。这条用例揭示了 unity-specialist 的关键纪律它可以提供技术解释但架构级决策不自行拍板。这与 agent-test-spec.md 模板 的 Case 4Conflict 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 写入单例IComponentDataMonoBehaviour 侧每帧通过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 Systemcom.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 5Context 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分类的L1Returns a domain-specific verdict一致unity-specialist 的产出应是可追溯的决策结构决策树、权衡表、推荐项 理由而不是一段即兴散文。这种结构化输出纪律让后续的 lead-programmer / technical-director 可以直接审阅其推理链条。九、覆盖说明Coverage Notes与测试闭环规格最后的三条覆盖说明指明了测试与文档化后续动作Case 1MonoBehaviour vs ScriptableObject如果最终形成了项目级决策应将其记录为ADRArchitecture Decision Record。这与仓库中 skills/authoring/architecture-decision.md 技能的存在相互印证——CCGS 主张架构选型结论沉淀为正式文档而非停留在对话里。Case 3版本标记确认 Agent不会在没有上下文时默认最新 Unity 版本。这是对 E1版本感知指标的行为级验证。Case 4DOTS 混合验证 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考