企业官网建设流程全解析

Claude-Code-Game-Studios 多 Agent 审查工作流（Review Workflow）详解：代码、设计、架构与跨域变更的分层审批机制

【免费下载链接】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）的审查工作流文档（.claude/docs/review-workflow.md）展开，系统讲解该开源项目中"谁有权审批哪一类变更"的四级审查矩阵：代码变更由部门负责人审查、设计变更需 game-designer 与 creative-director 双签、架构变更由 technical-director 签核、跨域变更由 producer 统筹。读完本文，你将掌握 CCGS 审查体系与 Gate 门禁机制（.claude/docs/director-gates.md）的完整对应关系，理解 review-mode 三档强度（full / lean / solo）的运作原理，并学会在 49 个 AI Agent、72 个工作流技能构成的分层组织中，正确判定某次变更应该触发哪一层审批。

一、审查工作流总览：四条核心规则

原文档 .claude/docs/review-workflow.md 以四条规则定义了整个项目的变更审批骨架：

1. 代码变更（Code changes）需要相关部门负责人 Agent（department lead agent，如 lead-programmer）审查；
2. 设计变更（Design changes）需要game-designer与creative-director双重签核（sign-off）；
3. 架构变更（Architecture changes）需要technical-director签核；
4. 跨域变更（Cross-domain changes）需要producer签核。

这四条规则本质上是把真实游戏公司的组织结构搬进了 Claude Code 会话：负责人对应垂直管理线、双签对应创意共识、技术总监对应架构主权、制作人对应跨部门调度。它们不是孤立的审批动作，而是被 .claude/docs/director-gates.md 中定义的数十个具名 Gate（如LP-CODE-REVIEW、CD-GDD-ALIGN、TD-ARCHITECTURE、PR-SCOPE）以标准化的方式落地执行的。

二、规则 1：代码变更 — 部门负责人审查与 LP-CODE-REVIEW 门禁

"Code changes require review by the relevant department lead agent" 在技能层由 code-review 技能 承载，其 frontmatter 中agent: lead-programmer明确了审批人身份。该技能把代码审查拆成 9 个阶段，核心检查项包括：

• Phase 3 — ADR 合规检查：搜索 story 文件、提交信息和头注释中的ADR-NNN或docs/architecture/ADR-引用，对每个被引用的 ADR 提取 Decision 与 Consequences 章节，将偏差分为三类：ARCHITECTURAL VIOLATION（阻塞级，使用了 ADR 明确拒绝的模式）、ADR DRIFT（警告级）、MINOR DEVIATION（信息级）；
• Phase 4 — 编码标准合规：公开方法/类有文档注释、圈复杂度 < 10、单方法不超过 40 行、依赖注入（游戏状态禁止静态单例）、配置值从数据文件加载、系统暴露接口而非具体类依赖；
• Phase 5 — 架构与 SOLID：依赖方向正确（engine ← gameplay）、模块间无循环依赖、UI 不持有游戏状态、跨系统通信使用事件/信号、五条 SOLID 原则逐一核查；
• Phase 6 — 游戏专项：帧率无关性（delta time）、热路径（update 循环）零分配、空/空值状态处理、线程安全、资源清理无泄漏；
• Phase 7 — 专家并行复审：按引擎配置（.claude/docs/technical-preferences.md 的 Engine Specialists 节）并行 spawn 引擎专家（.gd/.cs/.cpp→ 语言专家、shader 文件 → shader 专家、UI 代码 → UI 专家），对 Logic/Integration 类 story 还并行 spawnqa-tester评估可测试性。

最终输出包含 9 个区块的结构化审查报告，Verdict 三档为APPROVED / APPROVED WITH SUGGESTIONS / CHANGES REQUIRED，且该技能是只读的（不写任何文件）。这与 director-gates.md 中 Tier 2 的LP-CODE-REVIEW门禁完全对应——该门禁在/dev-story、/story-done或/code-review时触发，要求对照 story 验收标准与管辖 ADR 检查实现。

三、规则 2：设计变更 — 双签机制（game-designer + creative-director）

设计变更的"双签"体现为"单人深度审查 + 创意总监终审"的两层结构，由 design-review 技能 实现：

• 第一层 — 结构审查：Phase 2 对照设计文档标准清单检查 8 个必需章节（Overview、Player Fantasy、Detailed Rules、Formulas、Edge Cases、Dependencies、Tuning Knobs、Acceptance Criteria），并做依赖图验证——对 Dependencies 节每个系统用 Glob 确认其 GDD 是否存在于design/gdd/，不存在的标记为断裂引用；
• 第二层 — 对抗式专家评审（full 模式强制）：按 GDD 涉及的领域并行 spawn 多个专家 Agent，包括基线必选的game-designer与systems-designer，以及按需加入的 economy-designer、ai-programmer、level-designer、ux-designer、network-programmer 等（Phase 3b 提供完整的领域→Agent 映射表）。关键约束是：必须发出真实 Task 调用，禁止内部模拟专家视角；
• 第三层 — 创意总监综合：所有专家反馈收集后，spawncreative-director作为高级评审者做最终裁决（senior verdict），专家之间的分歧必须显式列出供用户仲裁，不得静默化解。

这正是原文档"Design changes require sign-off fromgame-designerandcreative-director"的落地形态。对应到 Gate 体系，设计类门禁还包括CD-PILLARS（支柱压力测试）、CD-GDD-ALIGN（GDD 与支柱对齐）、CD-SYSTEMS（系统分解愿景检查）等。design-review 的裁决等级为APPROVED / NEEDS REVISION / MAJOR REVISION NEEDED，其 Phase 5 用三个连续的AskUserQuestion部件处理修订、系统索引更新与评审日志追加（design/gdd/reviews/[doc-name]-review-log.md），确保复审可追踪。

四、规则 3：架构变更 — technical-director 签核与 TD 系列门禁

"Architecture changes require sign-off fromtechnical-director" 由两条执行路径承载：

4.1 architecture-review：架构的全面审计

architecture-review 技能 是"架构版的 design-review"，frontmatter 标注agent: technical-director、model: opus。它提供 5 种聚焦模式：full（全部阶段）、coverage（仅追踪缺口）、consistency（仅跨 ADR 冲突）、engine（仅引擎兼容性审计）、single-gdd [path]（单 GDD 覆盖审查），以及rtm模式——构建 GDD 需求 → ADR → Story → 测试文件的完整需求追踪矩阵（输出到docs/architecture/requirements-traceability.md）。

其核心产出是追踪矩阵：从每个 GDD 提取技术需求（数据结构、性能约束、引擎能力、跨系统通信、状态持久化、线程/时序、平台需求七大类），生成稳定的TR-[system]-NNN编号（与 docs/architecture/tr-registry.yaml 中的既有条目匹配复用，绝不重编号），再逐条核对 ADR 覆盖状态（✅ Covered / ⚠️ Partial / ❌ Gap）。随后是跨 ADR 冲突检测（数据所有权、集成契约、性能预算、依赖环、架构模式、状态管理六类冲突）与 ADR 依赖拓扑排序，最后是引擎兼容性交叉检查（版本一致性、post-cutoff API、废弃 API、缺失 Engine Compatibility 章节）。

4.2 TD 系列门禁：架构签核的标准化判定

director-gates.md 定义了 technical-director 名下的 6 个门禁，覆盖架构生命周期：

以TD-ARCHITECTURE为例，其审查要点为：(1) 每个技术需求是否都有对应架构决策覆盖；(2) 所有 HIGH RISK 引擎域是否被显式处理或标记为开放问题；(3) API 边界是否干净、最小、可实现；(4) Foundation 层 ADR 缺口是否在实现前解决——这与 .claude/docs/coordination-rules.md 中"技术冲突升级到 technical-director"的规则互为表里。

五、规则 4：跨域变更 — producer 统筹与 PR 系列门禁

"Cross-domain changes require sign-off fromproducer" 对应 .claude/docs/coordination-rules.md 中的两条协调规则：

• Rule 4 — Change Propagation：当设计变更影响多个领域时，由producer协调传播；
• Rule 5 — No Unilateral Cross-Domain Changes：Agent 未经显式授权不得修改其指定目录之外的文件。

producer 名下共有 5 个门禁：PR-SCOPE（范围与时间线校验，REALISTIC / OPTIMISTIC / UNREALISTIC）、PR-SPRINT（冲刺可行性，REALISTIC / CONCERNS / UNREALISTIC）、PR-MILESTONE（里程碑风险评估，ON TRACK / AT RISK / OFF TRACK）、PR-EPIC（史诗结构可行性，REALISTIC / CONCERNS / UNREALISTIC）、PR-PHASE-GATE（阶段转换生产就绪度，READY / CONCERNS / NOT READY）。

跨域变更的协同在 .claude/docs/agent-coordination-map.md 的 Common Workflow Patterns 中有完整呈现：例如"新功能全流水线"模式中，producer 在第 3 步排期、识别依赖，在第 13 步标记任务完成；"里程碑检查点"模式中 producer 主持 go/no-go 讨论并在所有总监达成一致后记录决策。

六、审查的强度控制：Review Mode 三档机制

审查工作流文档的四条规则是"必须审批"的默认前提，但 CCGS 提供了可配置的强度控制，让单人开发者不会被困在繁重的审批流程中。根据 .claude/docs/director-gates.md 的 Review Modes 章节：

全局配置：production/review-mode.txt，单行写入full、lean或solo三选一，在/start时设置一次，之后直接编辑文件即可修改。

单次运行覆盖：任何使用门禁的技能都接受--review [full|lean|solo]参数，只对该次运行生效：

/brainstorm space horror → 使用全局模式 /brainstorm space horror --review full → 本次强制 full 模式 /architecture-decision --review solo → 本次跳过所有门禁

每次 spawn 门禁前的强制解析顺序为：--review参数 >production/review-mode.txt> 默认lean。解析结果决定是否 spawn：solo跳过所有门禁并在输出中注明[GATE-ID] skipped — Solo mode；lean仅保留四个 PHASE-GATE（CD / TD / PR / AD）；full正常 spawn。

七、并行门禁协议与裁决升级规则

跨域变更审查（规则 4）的最典型场景是阶段转换。/gate-check会并行spawn 四位总监（详见 gate-check 技能 的 Director Panel Assessment 阶段）：

Spawn in parallel（先发出全部 Task 调用再等待结果）: 1. creative-director → gate CD-PHASE-GATE 2. technical-director → gate TD-PHASE-GATE 3. producer → gate PR-PHASE-GATE 4. art-director → gate AD-PHASE-GATE 收集四个裁决后应用升级规则: - 任一 NOT READY / REJECT → 总体裁决最低为 FAIL - 任一 CONCERNS → 总体裁决最低为 CONCERNS - 全部 READY / APPROVE → 才可判 PASS（仍需通过物项检查）

所有 Gate 统一返回三种裁决，技能必须处理全部三种：

门禁结果需记录在相关文档的状态头中：> **[Director] Review ([GATE-ID])**: APPROVED [date] / CONCERNS (accepted) [date] / REVISED [date]；阶段门禁记录在docs/architecture/architecture.md或production/session-state/active.md。/gate-check还会在出裁决前执行Chain-of-Verification（生成 5 个反证问题逐一复核裁决），并在 PASS 后把新阶段名写入production/stage.txt以更新状态栏。

八、审查在各生产阶段的门禁覆盖矩阵

原文档的四条规则覆盖全部阶段，director-gates.md 末尾给出了完整矩阵。CCGS 的 7 个生产阶段（Concept → Systems Design → Technical Setup → Pre-Production → Production → Polish → Release）各阶段必需与可选门禁如下：

从这个矩阵可以清晰看到四条规则的分布：代码审查（LP-CODE-REVIEW）密集出现在 Production 阶段，设计签核（CD-*系列）集中在 Concept 与 Systems Design，架构签核（TD-*系列）集中在 Technical Setup，而 producer 的PR-*门禁贯穿 Pre-Production 至 Release——这正是跨域统筹职责的体现。

九、扩展新门禁与维护规范

当新的技能或工作流需要新门禁时，director-gates.md 规定了三条维护规则：

1. 门禁 ID 规范：[DIRECTOR-PREFIX]-[DESCRIPTIVE-SLUG]，现有前缀CD-TD-PR-LP-QL-ND-AD-；新 Agent 增加新前缀（如AudioDirector → AU-、UX → UX-）；
2. 五字段完整：每个门禁必须包含 Trigger、Context to pass、Prompt、Verdicts 及特殊处理说明；
3. 技能中只引用 ID：技能通过 ID 引用门禁，绝不内联复制 Prompt 文本——这避免了提示词更新时的漂移（drift），正是 .claude/docs/review-workflow.md 这类"短规则 + 集中式定义"设计的核心动机。

这一"短规则文档 + 集中门禁库"的组合，让 CCGS 在保持四条审批规则极简可读的同时，把完整的审查深度沉淀在 .claude/docs/director-gates.md 单一事实源中，并经由 .claude/docs/coordination-rules.md（垂直委派、水平咨询、冲突升级、变更传播四条协调规则）与 .claude/docs/agent-coordination-map.md（组织层级、委派矩阵、升级路径、九种工作流模式）形成闭环。审查工作流因此不再是一纸约定，而是由 49 个 Agent、72 个技能和数十个标准化 Gate 共同执行的可运行工程机制。

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