Claude Code Game Studios 中 ai-programmer 智能体的测试规格解析领域边界、行为树验证与跨 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 StudiosCCGSSkill Testing Framework 中 ai-programmer 智能体测试规格展开系统拆解该 AI 智能体Agent的职责域声明、结构断言、5 个行为测试用例以及协议合规清单。读完本文你将掌握CCGS 如何用「领域声明 静态断言 测试用例 协议清单」四层结构验证一个游戏 AI 编程智能体的行为ai-programmer 与 gameplay-programmer、engine-programmer、level-designer 之间的边界划分与重定向规则以及如何用行为树规格、数据驱动 NPC 配置、关卡上下文传递等判据对 Agent 输出做可复现的自动化评判。一、背景Spec 是 CCGS 质量保障层的「行为契约」Claude Code Game Studios 将一次 Claude Code 会话组织成包含 49 个 Agent、72 个 Skill 的完整「虚拟游戏工作室」见 README.md。这些 Agent 按导演DirectorOpus、部门负责人LeadSonnet、专家SpecialistSonnet/Haiku三层组织ai-programmer 属于第三层专家之一。CCGS Skill Testing Framework/是整个体系独立的质量保障层其 CLAUDE.md 明确了两种核心测试文档的定位Skill specskills/[category]/[name].md某技能Slash 命令的行为规格Agent specagents/[tier]/[name].md某智能体的行为规格——本文主角 ai-programmer 的规格即属此类位于agents/specialists/目录下。每个 Agent spec 统一包含四层内容Agent Summary领域与反领域声明、Static Assertions结构断言、Test Cases5 个行为测试用例、Protocol Compliance协议合规清单。这套结构源自 agent-test-spec.md 模板模板同样要求Agent Summary、Static Assertions、五个测试用例域内请求、域外重定向、Gate 裁决、冲突升级、上下文传递、Protocol Compliance与Coverage Notes。所有 Agent 的统一登记与权威路径记录在 catalog.yaml 中其中 ai-programmer 的条目为- name: ai-programmer spec: CCGS Skill Testing Framework/agents/specialists/ai-programmer.md last_spec: last_spec_result: category: specialistspec:字段是该 Agent 规格的权威路径——按照CCGS Skill Testing Framework/CLAUDE.md的约定执行任何测试命令前都应先读取catalog.yaml而不是凭猜测找路径。二、领域声明ai-programmer 拥有什么、不拥有什么2.1 核心领域Domain规格的Agent Summary对 ai-programmer 的管辖范围做了精确声明Domain: NPC behavior, state machines, pathfinding, perception systems, and AI decision-making.即五大主题主题典型产出物NPC 行为NPC behavior巡逻 / 追击 / 逃跑等行为编排状态机state machinesPatrol / Alert / Pursue 等状态迁移定义寻路pathfinding导航网格使用、路径查询、agent radius 调优感知系统perception systems检测半径、视野锥、条件节点AI 决策AI decision-making行为树Selector / Sequence / Leaf选型2.2 反领域Does NOT own——边界即协议规格明确写出两个「不拥有」的领域这是整个 spec 的灵魂玩家机制player mechanics→ 属于gameplay-programmer渲染与引擎内部rendering or engine internals→ 属于engine-programmer。这与同级专家规格的声明完全对仗例如 gameplay-programmer 规格 的领域是「游戏机制代码、玩家系统、战斗实现、交互功能」并明确「不拥有 UI 实现ui-programmer、AI 行为树ai-programmer、引擎/渲染系统engine-programmer」engine-programmer 规格 则声明拥有渲染管线、物理集成、内存管理与资源加载反领域为「游戏机制gameplay-programmer、编辑器/调试工具 UItools-programmer」。这种「互斥领域声明」从根上杜绝了多个 Agent 争抢同一块代码的情形也是quality-rubric.md中 specialist 类别三条指标的落地前提详见第六节。2.3 模型层级SonnetAgent Summary注明Model tier: Sonnet (default)与规格声明「Sonnet 为专家的默认层级」一致quality-rubric.md 的specialist类别同样列出 ai-programmer 属于 Sonnet 层级专家Director 层才使用 Opus。另注明No gate IDs assigned即 ai-programmer 不触发任何阶段门禁裁决它属于执行型专家而非裁决型角色。三、结构断言Static Assertions可机器校验的 4 项硬性条件规格第一部分定义了 4 条静态断言用于在不运行真实行为的前提下对 Agent 定义文件做结构性体检description:字段存在且领域相关引用 NPC 行为 / AI 系统——防止 description 写成泛泛的「全能程序员」allowed-tools:列表包含 Read, Write, Edit, Bash, Glob, Grep——执行型专家需具备读写与搜索代码的能力模型层级为 Sonnet专家的默认层级Agent 定义不宣称对玩家机制或引擎渲染拥有权限——结构上强制声明反领域。这四条断言与 skill-test.md 规格 描述的静态检查机制呼应/skill-test static会逐项输出 PASS/FAIL 表格并给出 COMPLIANT / NON-COMPLIANT / WARNINGS 裁决。结构断言的价值在于廉价——无需夹具即可自动化执行能第一时间发现「Agent 定义越权」这类致命问题。四、五个行为测试用例从域内产出到性能升级规格用 5 个输入-期望对Input / Expected behavior定义 ai-programmer 在真实任务中的可接受行为。下面逐例拆解并结合仓库中的引擎参考文档补充可实现细节。Case 1域内请求——巡逻-警报行为树输入「实现一个守卫 NPC 的巡逻-警报行为树在路点间巡逻10 单位内检测到玩家后进入警报状态并追击。」期望行为产出一份行为树规格节点Selector、Sequence、Leaf actions加上对应的代码骨架定义命名清晰的状态Patrol、Alert、Pursue用感知/检测检查作为条件节点而非内联在移动代码里路点是数据驱动的以资源或 export 方式传入而非硬编码坐标输出包含公共 API 的文档注释。这条用例实质在验证三个工程原则组合式行为编排行为树而非散落的 if-else、感知与移动解耦检测是条件节点移动是执行节点、数据驱动配置路点、检测半径不应是魔法数字。规格的Protocol Compliance末尾同样要求「使用数据驱动的 NPC 配置路点、检测半径绝不硬编码值」——这条在框架层面是反复强调的红线。从仓库的引擎参考文档看这类需求的落地 API 是现成的Godot 导航快速参考Godot 4.6给出了巡逻/追击所需的底层原语例如NavigationAgent3D的典型用法onready var nav_agent: NavigationAgent3D %NavigationAgent3D func _ready() - void: nav_agent.path_desired_distance 0.5 nav_agent.target_desired_distance 1.0 nav_agent.velocity_computed.connect(_on_velocity_computed) func navigate_to(target: Vector3) - void: nav_agent.target_position target func _physics_process(delta: float) - void: if nav_agent.is_navigation_finished(): return var next_pos: Vector3 nav_agent.get_next_path_position() var direction: Vector3 global_position.direction_to(next_pos) nav_agent.velocity direction * move_speed func _on_velocity_computed(safe_velocity: Vector3) - void: velocity safe_velocity move_and_slide()结合该文档的「Common Mistakes」一节如未检查is_navigation_finished()就调用get_next_path_position()、启用 avoidance 后必须设置 velocity、修改几何后忘记烘焙导航网格可以推断ai-programmer 在产出行为树代码骨架时还需要把寻路 API 的正确使用姿势版本感知、avoidance 启用条件、导航层位掩码纳入输出质量要求——这正是 spec 之外、源码级可验证的深化点。Case 2域外请求——正确重定向输入「实现 WASD 移动和冲刺技能的玩家输入处理。」期望行为不产出玩家输入或移动代码明确说明这超出其领域玩家机制属于 gameplay-programmer将请求重定向到gameplay-programmer可以补充说明一旦玩家位置通过 API 可用AI 感知可以引用它。这条用例是整个 spec 最重要的行为判据之一越权比无能更危险。AI 智能体收到域外请求时正确动作是「拒绝 说明 重定向」而不是「顺手写了再说」。quality-rubric.md的 specialist 指标 S3「正确 defer」对此做了量化域外请求必须重定向到正确的 Agent而非默默拒绝。重定向目标gameplay-programmer的规格见前文反过来确认了玩家系统正是它的领地形成闭环验证。Case 3跨域协调——关卡约束下的寻路输入「为仓库关卡设计寻路但关卡中有误导导航网格的狭窄走廊。」期望行为不单方面修改关卡布局或导航网格资源与level-designer协调澄清导航网格需求与走廊尺寸提出一种依赖关卡几何条件的寻路方案如带 agent radius 调优的导航网格、流场 flow fields明确记录假设并标记阻塞项。这里体现的是跨 Agent 的协商协议寻路方案不能脱离关卡几何凭空设计而关卡几何归 level-designer 所有。对照 level-designer 规格 可见level-designer 同样「不拥有」AI 行为逻辑实现——两个 spec 在 AI 与关卡的交界处形成清晰的握手点ai-programmer 提需求与约束level-designer 拥有布局决策任何一方都不得单方面越界。这也对应quality-rubric.md的 S2「不做有约束力的跨域决策」。从工程角度agent radius tuning在导航 API 中确实有直接对应物Godot 导航文档中NavigationAgent3D.radius配合avoidance_enabled与neighbor_distance实现 RVO2 局部避障以及navigation_layers位掩码区分地面/飞行/游泳单位都是「在几何约束下调参」的具体落点。Case 4性能升级——自定义数据结构输入「寻路优先队列是瓶颈需要自定义二叉堆实现来提升性能。」期望行为识别出「低层、引擎集成的数据结构」属于 engine-programmer 的领域将任务升级给engine-programmer并清晰描述瓶颈与所需接口可以提供算法规格二叉堆接口、期望操作来指导 engine-programmer不在需要引擎内存管理的情况下单方面实现低层结构。这条用例定义了「专家如何向上传递性能类任务」ai-programmer 不假装自己能做引擎级优化但也不甩锅——它把算法规格interface 期望操作整理清楚让 engine-programmer 按接口实现。这与 engine-programmer 规格 的领域内存管理、资源加载、核心引擎框架完全对齐。注意规格措辞「如果它需要引擎内存管理」——若只是纯算法层面与引擎无耦合的堆实现ai-programmer 自行完成是被允许的判定关键在于是否触及引擎内存管理边界。Case 5上下文传递——利用关卡布局设计巡逻输入上下文中提供关卡布局文档显示两个咽喉点门洞 (12, 0) 与桥梁 (40, 5)。请求「为该关卡中的敌人设计巡逻路线与威胁响应。」期望行为引用所提供上下文中的具体咽喉点坐标设计利用咽喉点作为战术位置的巡逻路线指定在追击时将 NPC 引导至已识别咽喉点的警报状态迁移不虚构布局文档中不存在的几何。这条用例与模板中的「Context Pass-Through」用例对应验证 Agent 是否真正阅读并应用提供的文档而非凭空发挥——这正是 AI 编程中「上下文遵循」的核心能力。规格的Coverage Notes也明确说明Case 5 用于验证 Agent 会读取并应用给定文档而不是自行发明。坐标必须来自上下文(12, 0) 门洞、(40, 5) 桥梁方案必须锚定这些事实点任何额外的几何假设都是失败。五、协议合规清单Protocol Compliance六条行为红线规格的Protocol Compliance部分列出 6 条全局断言作为 5 个用例之上的汇总性验收保持在声明领域内NPC 行为、寻路、感知、状态机将域外请求重定向到正确 Agentgameplay-programmer、engine-programmer、level-designer返回结构化产出行为树规格、状态机图示、代码骨架而非散漫观点未经明确授权不修改玩家机制文件将性能关键的低层结构升级给 engine-programmer使用数据驱动的 NPC 配置路点、检测半径不硬编码其中「返回结构化产出」与模板 agent-test-spec.md 中「Output format matches expected structure」「Collaborative protocol followed (ask → draft → approve)」的断言一脉相承——CCGS 对智能体输出的评判不依赖主观印象而是检查产出物是否有可验证的结构规格中行为树节点类型、状态命名、数据驱动属性都是可机械核对的点。六、与质量准则的映射specialist 类别指标quality-rubric.md定义了specialist类别的 3 条评分指标ai-programmer 规格的每条断言几乎都能映射到其中指标PASS 判据ai-programmer spec 中的对应S1 — Stays in domain明确限定在声明领域延后域外请求Agent Summary 的 Domain / Does NOT own 声明Case 2 重定向S2 — No binding cross-domain decisions不单方面决定其他专家拥有的事项Case 3 不修改关卡布局与导航网格Case 4 升级二叉堆实现S3 — Defers correctly域外请求重定向到正确 Agent而非默默拒绝Case 2 点名 gameplay-programmerCase 4 点名 engine-programmerCase 3 点名 level-designer这套映射意味着ai-programmer 的 spec 不仅是行为文档其满足程度可以直接换算成 rubric 打分供/skill-test categorycategory 模式按 rubric 逐条评 PASS/FAIL等工具消费——规格与量化评估之间不存在断裂。七、测试落地方式与覆盖边界7.1 如何执行测试按CCGS Skill Testing Framework/CLAUDE.md的流程要验证 ai-programmer 规格标准操作是读取 catalog.yaml取得 ai-programmer 的spec:路径与category: specialist读取 Agent 定义文件与规格文件逐用例评估断言Case 15 逐一判 PASS / FAIL / PARTIAL产出逐用例结果表整体裁决 PASS / PARTIAL / FAIL如需修正可走/skill-improve的「测试 → 诊断 → 修复 → 重测 → 保留或回滚」闭环。skill-test.md 规格 同时强调spec 描述的是当前行为而非理想行为——当 Agent 在实践中表现异常应先修 Agent 本身、再更新 spec 使之与修复后的行为一致spec 失败意味着「需要调查」而非「skill 一定是错的」。7.2 Coverage Notes已知覆盖缺口规格末尾的Coverage Notes指出三处已知边界Case 1 的行为树产出应由tests/unit/ai/下的单元测试验证——即行为树规格不是终点产出代码必须能被单测断言Case 5 验证 Agent 读取并应用提供的文档而非凭空发明——这是上下文遵循能力的专项覆盖Case 4 确认 Agent 能识别 engine-programmer 的边界——性能升级路径的专项覆盖。由此可以推断若要扩展该 spec 的覆盖面可补充的方向包括「感知系统视野锥、检测层级专项用例」「NavMesh 版本差异如 Godot 4.6 的 2D 导航服务器拆分感知用例」等——这些在docs/engine-reference/godot/modules/navigation.md中均有据可查属于规格尚未覆盖、但仓库资料已充分支撑的领域。八、总结ai-programmer 的 Agent 测试规格展示了 CCGS 智能体治理的核心方法论用互斥的领域声明划清边界用结构断言做廉价巡检用 5 个行为用例覆盖域内产出、域外重定向、跨域协调、性能升级、上下文遵循五种典型场景再用协议合规清单做最终验收。对读者而言这套 spec 既是一份「AI 编程专家应该怎么被约束」的模板也是一份可复用的验收清单——无论你是在为 CCGS 添加新 Agent还是想为自研的 AI 编程 Agent 建立质量门槛都可以直接参考 agent-test-spec.md 模板 和本文拆解的五用例结构把「不越权」「结构化产出」「数据驱动」「上下文忠实」变成可机器判定的断言。【免费下载链接】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 中 ai-programmer 智能体的测试规格解析：领域边界、行为树验证与跨 Agent 协作协议
Claude Code Game Studios 中 ai-programmer 智能体的测试规格解析领域边界、行为树验证与跨 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 StudiosCCGSSkill Testing Framework 中 ai-programmer 智能体测试规格展开系统拆解该 AI 智能体Agent的职责域声明、结构断言、5 个行为测试用例以及协议合规清单。读完本文你将掌握CCGS 如何用「领域声明 静态断言 测试用例 协议清单」四层结构验证一个游戏 AI 编程智能体的行为ai-programmer 与 gameplay-programmer、engine-programmer、level-designer 之间的边界划分与重定向规则以及如何用行为树规格、数据驱动 NPC 配置、关卡上下文传递等判据对 Agent 输出做可复现的自动化评判。一、背景Spec 是 CCGS 质量保障层的「行为契约」Claude Code Game Studios 将一次 Claude Code 会话组织成包含 49 个 Agent、72 个 Skill 的完整「虚拟游戏工作室」见 README.md。这些 Agent 按导演DirectorOpus、部门负责人LeadSonnet、专家SpecialistSonnet/Haiku三层组织ai-programmer 属于第三层专家之一。CCGS Skill Testing Framework/是整个体系独立的质量保障层其 CLAUDE.md 明确了两种核心测试文档的定位Skill specskills/[category]/[name].md某技能Slash 命令的行为规格Agent specagents/[tier]/[name].md某智能体的行为规格——本文主角 ai-programmer 的规格即属此类位于agents/specialists/目录下。每个 Agent spec 统一包含四层内容Agent Summary领域与反领域声明、Static Assertions结构断言、Test Cases5 个行为测试用例、Protocol Compliance协议合规清单。这套结构源自 agent-test-spec.md 模板模板同样要求Agent Summary、Static Assertions、五个测试用例域内请求、域外重定向、Gate 裁决、冲突升级、上下文传递、Protocol Compliance与Coverage Notes。所有 Agent 的统一登记与权威路径记录在 catalog.yaml 中其中 ai-programmer 的条目为- name: ai-programmer spec: CCGS Skill Testing Framework/agents/specialists/ai-programmer.md last_spec: last_spec_result: category: specialistspec:字段是该 Agent 规格的权威路径——按照CCGS Skill Testing Framework/CLAUDE.md的约定执行任何测试命令前都应先读取catalog.yaml而不是凭猜测找路径。二、领域声明ai-programmer 拥有什么、不拥有什么2.1 核心领域Domain规格的Agent Summary对 ai-programmer 的管辖范围做了精确声明Domain: NPC behavior, state machines, pathfinding, perception systems, and AI decision-making.即五大主题主题典型产出物NPC 行为NPC behavior巡逻 / 追击 / 逃跑等行为编排状态机state machinesPatrol / Alert / Pursue 等状态迁移定义寻路pathfinding导航网格使用、路径查询、agent radius 调优感知系统perception systems检测半径、视野锥、条件节点AI 决策AI decision-making行为树Selector / Sequence / Leaf选型2.2 反领域Does NOT own——边界即协议规格明确写出两个「不拥有」的领域这是整个 spec 的灵魂玩家机制player mechanics→ 属于gameplay-programmer渲染与引擎内部rendering or engine internals→ 属于engine-programmer。这与同级专家规格的声明完全对仗例如 gameplay-programmer 规格 的领域是「游戏机制代码、玩家系统、战斗实现、交互功能」并明确「不拥有 UI 实现ui-programmer、AI 行为树ai-programmer、引擎/渲染系统engine-programmer」engine-programmer 规格 则声明拥有渲染管线、物理集成、内存管理与资源加载反领域为「游戏机制gameplay-programmer、编辑器/调试工具 UItools-programmer」。这种「互斥领域声明」从根上杜绝了多个 Agent 争抢同一块代码的情形也是quality-rubric.md中 specialist 类别三条指标的落地前提详见第六节。2.3 模型层级SonnetAgent Summary注明Model tier: Sonnet (default)与规格声明「Sonnet 为专家的默认层级」一致quality-rubric.md 的specialist类别同样列出 ai-programmer 属于 Sonnet 层级专家Director 层才使用 Opus。另注明No gate IDs assigned即 ai-programmer 不触发任何阶段门禁裁决它属于执行型专家而非裁决型角色。三、结构断言Static Assertions可机器校验的 4 项硬性条件规格第一部分定义了 4 条静态断言用于在不运行真实行为的前提下对 Agent 定义文件做结构性体检description:字段存在且领域相关引用 NPC 行为 / AI 系统——防止 description 写成泛泛的「全能程序员」allowed-tools:列表包含 Read, Write, Edit, Bash, Glob, Grep——执行型专家需具备读写与搜索代码的能力模型层级为 Sonnet专家的默认层级Agent 定义不宣称对玩家机制或引擎渲染拥有权限——结构上强制声明反领域。这四条断言与 skill-test.md 规格 描述的静态检查机制呼应/skill-test static会逐项输出 PASS/FAIL 表格并给出 COMPLIANT / NON-COMPLIANT / WARNINGS 裁决。结构断言的价值在于廉价——无需夹具即可自动化执行能第一时间发现「Agent 定义越权」这类致命问题。四、五个行为测试用例从域内产出到性能升级规格用 5 个输入-期望对Input / Expected behavior定义 ai-programmer 在真实任务中的可接受行为。下面逐例拆解并结合仓库中的引擎参考文档补充可实现细节。Case 1域内请求——巡逻-警报行为树输入「实现一个守卫 NPC 的巡逻-警报行为树在路点间巡逻10 单位内检测到玩家后进入警报状态并追击。」期望行为产出一份行为树规格节点Selector、Sequence、Leaf actions加上对应的代码骨架定义命名清晰的状态Patrol、Alert、Pursue用感知/检测检查作为条件节点而非内联在移动代码里路点是数据驱动的以资源或 export 方式传入而非硬编码坐标输出包含公共 API 的文档注释。这条用例实质在验证三个工程原则组合式行为编排行为树而非散落的 if-else、感知与移动解耦检测是条件节点移动是执行节点、数据驱动配置路点、检测半径不应是魔法数字。规格的Protocol Compliance末尾同样要求「使用数据驱动的 NPC 配置路点、检测半径绝不硬编码值」——这条在框架层面是反复强调的红线。从仓库的引擎参考文档看这类需求的落地 API 是现成的Godot 导航快速参考Godot 4.6给出了巡逻/追击所需的底层原语例如NavigationAgent3D的典型用法onready var nav_agent: NavigationAgent3D %NavigationAgent3D func _ready() - void: nav_agent.path_desired_distance 0.5 nav_agent.target_desired_distance 1.0 nav_agent.velocity_computed.connect(_on_velocity_computed) func navigate_to(target: Vector3) - void: nav_agent.target_position target func _physics_process(delta: float) - void: if nav_agent.is_navigation_finished(): return var next_pos: Vector3 nav_agent.get_next_path_position() var direction: Vector3 global_position.direction_to(next_pos) nav_agent.velocity direction * move_speed func _on_velocity_computed(safe_velocity: Vector3) - void: velocity safe_velocity move_and_slide()结合该文档的「Common Mistakes」一节如未检查is_navigation_finished()就调用get_next_path_position()、启用 avoidance 后必须设置 velocity、修改几何后忘记烘焙导航网格可以推断ai-programmer 在产出行为树代码骨架时还需要把寻路 API 的正确使用姿势版本感知、avoidance 启用条件、导航层位掩码纳入输出质量要求——这正是 spec 之外、源码级可验证的深化点。Case 2域外请求——正确重定向输入「实现 WASD 移动和冲刺技能的玩家输入处理。」期望行为不产出玩家输入或移动代码明确说明这超出其领域玩家机制属于 gameplay-programmer将请求重定向到gameplay-programmer可以补充说明一旦玩家位置通过 API 可用AI 感知可以引用它。这条用例是整个 spec 最重要的行为判据之一越权比无能更危险。AI 智能体收到域外请求时正确动作是「拒绝 说明 重定向」而不是「顺手写了再说」。quality-rubric.md的 specialist 指标 S3「正确 defer」对此做了量化域外请求必须重定向到正确的 Agent而非默默拒绝。重定向目标gameplay-programmer的规格见前文反过来确认了玩家系统正是它的领地形成闭环验证。Case 3跨域协调——关卡约束下的寻路输入「为仓库关卡设计寻路但关卡中有误导导航网格的狭窄走廊。」期望行为不单方面修改关卡布局或导航网格资源与level-designer协调澄清导航网格需求与走廊尺寸提出一种依赖关卡几何条件的寻路方案如带 agent radius 调优的导航网格、流场 flow fields明确记录假设并标记阻塞项。这里体现的是跨 Agent 的协商协议寻路方案不能脱离关卡几何凭空设计而关卡几何归 level-designer 所有。对照 level-designer 规格 可见level-designer 同样「不拥有」AI 行为逻辑实现——两个 spec 在 AI 与关卡的交界处形成清晰的握手点ai-programmer 提需求与约束level-designer 拥有布局决策任何一方都不得单方面越界。这也对应quality-rubric.md的 S2「不做有约束力的跨域决策」。从工程角度agent radius tuning在导航 API 中确实有直接对应物Godot 导航文档中NavigationAgent3D.radius配合avoidance_enabled与neighbor_distance实现 RVO2 局部避障以及navigation_layers位掩码区分地面/飞行/游泳单位都是「在几何约束下调参」的具体落点。Case 4性能升级——自定义数据结构输入「寻路优先队列是瓶颈需要自定义二叉堆实现来提升性能。」期望行为识别出「低层、引擎集成的数据结构」属于 engine-programmer 的领域将任务升级给engine-programmer并清晰描述瓶颈与所需接口可以提供算法规格二叉堆接口、期望操作来指导 engine-programmer不在需要引擎内存管理的情况下单方面实现低层结构。这条用例定义了「专家如何向上传递性能类任务」ai-programmer 不假装自己能做引擎级优化但也不甩锅——它把算法规格interface 期望操作整理清楚让 engine-programmer 按接口实现。这与 engine-programmer 规格 的领域内存管理、资源加载、核心引擎框架完全对齐。注意规格措辞「如果它需要引擎内存管理」——若只是纯算法层面与引擎无耦合的堆实现ai-programmer 自行完成是被允许的判定关键在于是否触及引擎内存管理边界。Case 5上下文传递——利用关卡布局设计巡逻输入上下文中提供关卡布局文档显示两个咽喉点门洞 (12, 0) 与桥梁 (40, 5)。请求「为该关卡中的敌人设计巡逻路线与威胁响应。」期望行为引用所提供上下文中的具体咽喉点坐标设计利用咽喉点作为战术位置的巡逻路线指定在追击时将 NPC 引导至已识别咽喉点的警报状态迁移不虚构布局文档中不存在的几何。这条用例与模板中的「Context Pass-Through」用例对应验证 Agent 是否真正阅读并应用提供的文档而非凭空发挥——这正是 AI 编程中「上下文遵循」的核心能力。规格的Coverage Notes也明确说明Case 5 用于验证 Agent 会读取并应用给定文档而不是自行发明。坐标必须来自上下文(12, 0) 门洞、(40, 5) 桥梁方案必须锚定这些事实点任何额外的几何假设都是失败。五、协议合规清单Protocol Compliance六条行为红线规格的Protocol Compliance部分列出 6 条全局断言作为 5 个用例之上的汇总性验收保持在声明领域内NPC 行为、寻路、感知、状态机将域外请求重定向到正确 Agentgameplay-programmer、engine-programmer、level-designer返回结构化产出行为树规格、状态机图示、代码骨架而非散漫观点未经明确授权不修改玩家机制文件将性能关键的低层结构升级给 engine-programmer使用数据驱动的 NPC 配置路点、检测半径不硬编码其中「返回结构化产出」与模板 agent-test-spec.md 中「Output format matches expected structure」「Collaborative protocol followed (ask → draft → approve)」的断言一脉相承——CCGS 对智能体输出的评判不依赖主观印象而是检查产出物是否有可验证的结构规格中行为树节点类型、状态命名、数据驱动属性都是可机械核对的点。六、与质量准则的映射specialist 类别指标quality-rubric.md定义了specialist类别的 3 条评分指标ai-programmer 规格的每条断言几乎都能映射到其中指标PASS 判据ai-programmer spec 中的对应S1 — Stays in domain明确限定在声明领域延后域外请求Agent Summary 的 Domain / Does NOT own 声明Case 2 重定向S2 — No binding cross-domain decisions不单方面决定其他专家拥有的事项Case 3 不修改关卡布局与导航网格Case 4 升级二叉堆实现S3 — Defers correctly域外请求重定向到正确 Agent而非默默拒绝Case 2 点名 gameplay-programmerCase 4 点名 engine-programmerCase 3 点名 level-designer这套映射意味着ai-programmer 的 spec 不仅是行为文档其满足程度可以直接换算成 rubric 打分供/skill-test categorycategory 模式按 rubric 逐条评 PASS/FAIL等工具消费——规格与量化评估之间不存在断裂。七、测试落地方式与覆盖边界7.1 如何执行测试按CCGS Skill Testing Framework/CLAUDE.md的流程要验证 ai-programmer 规格标准操作是读取 catalog.yaml取得 ai-programmer 的spec:路径与category: specialist读取 Agent 定义文件与规格文件逐用例评估断言Case 15 逐一判 PASS / FAIL / PARTIAL产出逐用例结果表整体裁决 PASS / PARTIAL / FAIL如需修正可走/skill-improve的「测试 → 诊断 → 修复 → 重测 → 保留或回滚」闭环。skill-test.md 规格 同时强调spec 描述的是当前行为而非理想行为——当 Agent 在实践中表现异常应先修 Agent 本身、再更新 spec 使之与修复后的行为一致spec 失败意味着「需要调查」而非「skill 一定是错的」。7.2 Coverage Notes已知覆盖缺口规格末尾的Coverage Notes指出三处已知边界Case 1 的行为树产出应由tests/unit/ai/下的单元测试验证——即行为树规格不是终点产出代码必须能被单测断言Case 5 验证 Agent 读取并应用提供的文档而非凭空发明——这是上下文遵循能力的专项覆盖Case 4 确认 Agent 能识别 engine-programmer 的边界——性能升级路径的专项覆盖。由此可以推断若要扩展该 spec 的覆盖面可补充的方向包括「感知系统视野锥、检测层级专项用例」「NavMesh 版本差异如 Godot 4.6 的 2D 导航服务器拆分感知用例」等——这些在docs/engine-reference/godot/modules/navigation.md中均有据可查属于规格尚未覆盖、但仓库资料已充分支撑的领域。八、总结ai-programmer 的 Agent 测试规格展示了 CCGS 智能体治理的核心方法论用互斥的领域声明划清边界用结构断言做廉价巡检用 5 个行为用例覆盖域内产出、域外重定向、跨域协调、性能升级、上下文遵循五种典型场景再用协议合规清单做最终验收。对读者而言这套 spec 既是一份「AI 编程专家应该怎么被约束」的模板也是一份可复用的验收清单——无论你是在为 CCGS 添加新 Agent还是想为自研的 AI 编程 Agent 建立质量门槛都可以直接参考 agent-test-spec.md 模板 和本文拆解的五用例结构把「不越权」「结构化产出」「数据驱动」「上下文忠实」变成可机器判定的断言。【免费下载链接】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），仅供参考
