企业官网建设流程全解析

用 Claude Code 编排战斗开发团队：CCGS team-combat 技能六阶段管线实战指南

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

导读

team-combat是 Claude-Code-Game-Studios（CCGS）项目中负责"战斗玩法端到端交付"的团队编排技能（slash command）。它把游戏设计、玩法编程、AI 编程、技术美术、声音设计和 QA 测试六个专业 Agent 串成一条从设计到验收的流水线，并内置了决策点、错误恢复与文件写入协议。读完本文，你将掌握：如何正确调用该技能、每个阶段应该委派给哪个 Agent、各角色的职责边界与可验证产出物，以及遇到阻塞时如何按协议恢复——从而让 Claude Code 真正像一家小型游戏工作室那样并行协作。

技能定位与调用方式

技能本体位于 .claude/skills/team-combat/SKILL.md，是一个user-invocable: true的 slash command。其 frontmatter 定义了关键元数据：

调用语法为/team-combat [combat feature description]，例如：

/team-combat melee parry system /team-combat ranged weapon spread

技能内置了参数检查（Argument check）：如果调用时没有提供战斗玩法描述，编排器不会启动任何子 Agent，也不会读取任何文件，而是直接输出用法提示并停止：

"Usage:/team-combat [combat feature description]— Provide a description of the combat feature to design and implement (e.g.,melee parry system,ranged weapon spread)."

这是一个值得借鉴的"fail-fast"设计：编排类技能在入参不完整时立即退出，避免浪费 token 和无意义的文件扫描。

团队构成：七个角色的职责边界

技能将战斗功能拆解为七个可并行/串行的专业角色，每个角色都对应仓库中的一个 Agent 定义文件：

从 Agent 定义文件可以进一步看到各角色的"不得为"清单（职责隔离设计）：

• game-designer不写实现代码、不做架构决策、不直接产出最终叙事内容，而是产出可被程序员直接实现的规格；
• gameplay-programmer不改设计（发现偏差需上报 game-designer）、不硬编码可配置数值、不写网络代码、不跳过单元测试；
• ai-programmer不设计敌人类型（只实现 game-designer 的规格）、不改引擎核心系统；
• technical-artist不做美学决策（归 art-director）、不改玩法代码；
• sound-designer不写音频引擎代码、不创建音频文件本体，只产出规格文档；
• qa-tester不修 Bug（只报告）、不越权判定 S2 以上严重度（上报 qa-lead）。

这种"报告链 + 规格来源"的职责网格（例如 gameplay-programmer 向 lead-programmer 汇报、从 game-designer 接收规格、与 ai-programmer/ui-programmer 平级协作）正是 CCGS 把真实工作室层级映射到 Agent 系统的体现。

委派机制：用 Task 工具派生子 Agent

编排器本身不直接干活，而是通过Task工具把每个成员作为子 Agent 启动，subagent_type与角色一一对应：

subagent_type: game-designer # 设计机制、公式与边界情况 subagent_type: gameplay-programmer # 实现核心玩法代码 subagent_type: ai-programmer # 实现 NPC/敌方 AI 行为 subagent_type: technical-artist # VFX、Shader、视觉反馈 subagent_type: sound-designer # 音频事件、打击音效、环境音 subagent_type: [primary engine specialist] # 引擎惯用法校验 subagent_type: qa-tester # 测试用例与实现验证

技能明确规定了两条委派准则：

1. 每个 Agent 的 prompt 都必须携带完整上下文——设计文档路径、相关代码文件、约束条件，避免子 Agent 在信息真空中工作；
2. 在管线允许时并行启动独立 Agent——例如 Phase 3 的实现类 Agent 可以同时运行，这是整个编排体系提升吞吐的关键。

六阶段交付管线

这是技能的核心骨架，每个阶段都有明确的输入、输出与责任 Agent：

Phase 1：设计（Design）

委派给game-designer，产出或更新design/gdd/下的设计文档。文档必须覆盖：机制总览（mechanic overview）、玩家幻想（player fantasy）、详细规则、带变量定义的公式、边界情况（edge cases）、依赖关系、带安全范围的调参旋钮（tuning knobs with safe ranges）以及验收标准（acceptance criteria）。

game-designer 的 Agent 定义进一步把这套标准固化为GDD 八段式模板（.claude/agents/game-designer.md 的 Design Document Standard 一节）：Overview、Player Fantasy、Detailed Rules、Formulas（含变量定义、输入范围、示例计算）、Edge Cases、Dependencies（数据流方向与集成契约）、Tuning Knobs（类别：feel/curve/gate，含默认值理由）、Acceptance Criteria（功能性与体验性双维度）。也就是说，Phase 1 的产出不是"大概想法"，而是程序员可以仅凭文档独立实现、QA 可以据此写用例的完整规格。

Phase 2：架构（Architecture）

委派给gameplay-programmer（若涉及 AI 则同时带上ai-programmer）：

• 评审设计文档；
• 设计代码架构：类结构、接口、数据流；
• 识别与既有系统的集成点；
• 输出带文件清单和接口定义的架构草图。

随后启动主引擎专家（primary engine specialist）校验架构，校验清单聚焦三个问题：

1. 类/节点/组件结构对 pinned 引擎是否惯用？（例如 Godot 的节点层级、Unity 的 MonoBehaviour vs DOTS、Unreal 的 Actor/Component 设计）
2. 是否存在应优先使用的引擎原生系统，而不该自造轮子？
3. 提议的 API 在 pinned 引擎版本中是否已废弃或有变更？

引擎专家的路由信息读取自 .claude/docs/technical-preferences.md 的Engine Specialists一节。需要说明的是：在当前仓库中该节仍为[TO BE CONFIGURED — run /setup-engine]占位状态，文件扩展名路由表（游戏代码 / Shader / UI / 场景 / 原生插件）也尚未填充——这意味着该技能依赖先执行/setup-engine完成引擎配置才能精确路由到对应专家；未配置时按文档约定回退到 Primary 专家。

Phase 3：实现（Implementation，可并行）

并行委派四个角色：

• gameplay-programmer：实现核心战斗机制代码；
• ai-programmer：实现 AI 行为（如果功能涉及 NPC 反应）；
• technical-artist：制作 VFX 与 Shader 特效；
• sound-designer：定义音频事件清单与混音说明。

从实现原则看，gameplay-programmer 的 Agent 定义要求：所有数值来自外部配置文件（data-driven）、状态机必须有显式迁移表、UI 通过事件/信号解耦、所有逻辑基于 delta time 保证帧率无关、并在代码注释中标注所实现的 GDD。

Phase 4：集成（Integration）

• 将玩法代码、AI、VFX、音频接线打通；
• 确保所有调参旋钮都被暴露且数据驱动；
• 验证功能与既有战斗系统协同工作。

Phase 5：验证（Validation）

委派给qa-tester：

• 依据验收标准编写测试用例；
• 覆盖设计文档记录的所有边界情况；
• 验证性能影响在预算之内；
• 为发现的问题提交 Bug 报告。

qa-tester 的 Agent 定义提供了可直接套用的工程细节（.claude/agents/qa-tester.md）：

测试命名约定：文件[system]_[feature]_test.[ext]，函数test_[scenario]_[expected]。三种引擎的测试骨架示例：

# Godot (GdUnit4) extends GdUnitTestSuite func test_[scenario]_[expected]() -> void: # Arrange var subject = [ClassName].new() # Act var result = subject.method # Assert assert_that(result).is_equal([expected])

// Unity (NUnit) [TestFixture] public class [SystemName]Tests { [Test] public void [Scenario]_[Expected]() { var subject = new [ClassName](); var result = subject.Method; Assert.AreEqual([expected], result, delta: 0.001f); } }

// Unreal (C++) IMPLEMENT_SIMPLE_AUTOMATION_TEST( F[SystemName]Test, "MyGame.[System].[Scenario]", EAutomationTestFlags::GameFilter ) bool F[SystemName]Test::RunTest(const FString& Parameters) { [ClassName] Subject; float Result = Subject.Method; TestEqual("[description]", Result, [expected]); return true; }

每个公式必须覆盖的五类用例：正常输入、零/空输入（不得崩溃）、最大值（不得溢出或产生无穷）、负修正（如适用）、GDD 中提到的特定边界情况。

测试用例四字段格式：Precondition（前置条件）/ Steps（步骤）/ Expected Result（预期结果）/ Pass Criteria（可衡量的二值判定标准）。

Bug 报告格式：ID、标题、严重度（S1-S4）、频率、构建版本、平台、复现步骤、预期/实际行为、附加上下文。

qa-tester 还按故事类型路由测试证据：Logic 故事必须有自动化单元测试（BLOCKING 级门槛，输出到tests/unit/[system]/）；Integration 故事需集成测试或文档化试玩（tests/integration/[system]/）；Visual/Feel、UI、Config 类故事则走截图/文档/冒烟证据（ADVISORY 级）。

Phase 6：签收（Sign-off）

• 收集所有成员的结果；
• 报告功能状态：COMPLETE / NEEDS WORK / BLOCKED；
• 列出未决问题及其责任归属。

决策点机制：AskUserQuestion 驱动的人工闸门

技能在每个阶段转换处强制设置决策点（Decision Points）：编排器先用AskUserQuestion把子 Agent 的方案呈现为可选项，并在对话中输出完整分析，然后用简洁标签捕捉决策——用户必须批准后才能进入下一阶段。这与 game-designer Agent 中的 "Explain -> Capture" 模式一脉相承：先充分论证（pros/cons、理论依据），再让用户以结构化 UI 做选择。这意味着 team-combat 不是"一键生成"，而是"每阶段一个可干预的人工闸门"，从根本上避免失控的自动化产出。

错误恢复协议：阻塞不阻塞交付

任何通过 Task 派生的 Agent 返回 BLOCKED、报错或无法完成时，按四步协议处理：

1. 立即上报：在进入依赖阶段前，向用户报告"[AgentName]: BLOCKED — [reason]"；
2. 评估依赖：判断被阻塞 Agent 的产出是否为后续阶段必需——若是，在没有用户输入前不得越过该依赖点；
3. 提供选项：用 AskUserQuestion 给出三条路——跳过该 Agent 并在最终报告中标注缺口 / 缩小范围重试 / 停下先解决阻塞；
4. 始终产出部分报告：已完成的工作绝不丢弃。

技能还预置了四个常见阻塞场景及处置路由：

这条协议的价值在于：把"某个子任务失败"从灾难性事件降级为"一次可决策、可恢复的流程事件"，同时通过"部分报告"保证任何阻塞都不会让已有工作白费。

文件写入协议：编排器不直接写文件

技能明确要求：所有文件写入（设计文档、实现文件、测试用例）都委派给通过 Task 派生的子 Agent，每个子 Agent 都执行"May I write to [path]?"（征得许可再写入）协议，编排器本身不直接写文件。这是 CCGS 全局协作规范的一部分——文件权限永远下放到具体执行者，编排层只负责调度、汇总与决策呈现，避免编排器越权覆盖子 Agent 的产出。

输出报告与判定

最终交付是一份汇总报告，覆盖：设计完成状态、各成员实现状态、测试结果与未决问题。终结判定二选一：

• COMPLETE—— 战斗功能已完成设计、实现与验证；
• BLOCKED—— 一个或多个阶段无法完成，已产出带未解决事项清单的部分报告。

后续衔接：交付不是终点

技能内置了三个明确的下一步动作（Next Steps），指向仓库中对应技能：

• 在关闭 story 前对已实现的战斗代码运行/code-review（对应 .claude/skills/code-review/SKILL.md）做架构级代码审查；
• 运行/balance-check（.claude/skills/balance-check/SKILL.md）验证战斗公式与调参数值；
• 若需要 VFX、音频或性能打磨，运行/team-polish（.claude/skills/team-polish/SKILL.md）——该技能是平行设计的"打磨团队"编排器，管线（Assessment → Optimization → Visual/Audio Polish → Hardening → Sign-off）与 team-combat 同构，二者衔接形成"开发→打磨"的完整闭环。

适用前提与限制

从源码结构看，本技能的正常运行依赖以下前提，读者需知悉：

1. 引擎配置先行：引擎专家路由依赖.claude/docs/technical-preferences.md的 Engine Specialists 一节，当前仓库该节为待配置占位，需先运行/setup-engine；
2. 设计文档目录约定：技能约定 GDD 存放于design/gdd/，而当前仓库design/目录仅包含 design/registry/entities.yaml 与 design/CLAUDE.md，gdd/由 game-designer 按需创建；
3. 引擎版本安全：gameplay-programmer 与 technical-artist 的 Agent 定义都要求实现前核对docs/engine-reference/[engine]/VERSION.md的 pinned 版本，训练数据与版本参考冲突时以仓库参考文档为准，并遵守docs/architecture/中既有 ADR 的 Implementation Guidelines。

总而言之，team-combat 的工程价值在于它把"多人多角色协作开发一个战斗功能"这一天然复杂的流程，压缩为一条受控的六阶段管线：设计产出可实现的规格、架构先经引擎专家把关、实现并行推进、QA 按证据路由表兜底、每个阶段由人工闸门把关、任何阻塞都有恢复路径。这套模式完全可以迁移到其他类型的功能开发（关卡、UI、剧情等），仓库中team-level、team-ui、team-narrative等平行技能即是同一编排范式的复刻。

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