企业官网建设流程全解析

Claude Code Game Studios 中的 dev-story 技能：从故事到代码的完整实现流水线

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

导读：/dev-story是 Claude Code Game Studios（CCGS）这套"AI 游戏开发工作室"体系中衔接规划与编码的核心技能。它以 Story（用户故事）文件为输入，自动加载 GDD 需求（TR Registry）、架构决策记录（ADR）、分层控制清单（Control Manifest）与引擎技术偏好，路由到正确的程序员 Agent 与引擎专家，驱动实现与测试同步完成。读完本文，你将掌握如何用一条/dev-story [story-path]命令，把一个通过story-readiness校验的故事，变成src/中可运行的源码与tests/中的配套测试，并理解其背后的七阶段编排协议与错误恢复机制。

一、dev-story 在 CCGS 工作流中的定位

CCGS（Claude Code Game Studios）将游戏研发流程拆解为 49 个 AI Agent 与 72 个工作流技能，dev-story是其中被明确定位为"核心实现技能"的环节。其技能声明（.claude/skills/dev-story/SKILL.md）中写明：

"Read a story file and implement it. Loads the full context (story, GDD requirement, ADR guidelines, control manifest), routes to the right programmer agent for the system and engine, implements the code and test, and confirms each acceptance criterion."

它在整个工作流中处于承上启下的位置，官方给出的每个 Story 的标准循环为：

/qa-plan sprint ← 在 sprint 开始前定义测试需求 /story-readiness [path] ← 在开始前校验故事就绪状态 /dev-story [path] ← 实现它（本技能） /code-review [files] ← 评审实现 /story-done [path] ← 验证并关闭故事

当 sprint 内所有故事完成后，还需运行/team-qa sprint执行完整 QA 循环并获得签署结论，之后才能推进项目阶段（phase gate）。也就是说，dev-story的上游是 story-readiness（确保故事"可开工"），下游是 story-done（验收并闭环）。dev-story的输出被严格定义为：项目src/目录下的源码文件 +tests/目录下的测试文件。

从仓库结构可以印证：CCGS 的 Agent 定义文件（.claude/agents/ 与 CCGS Skill Testing Framework/agents/）按层级划分了 directors、leads、specialists、operations、qa 等角色，而 .claude/docs/agent-roster.md 则给出了完整的角色名册与模型分层（Opus/Sonnet/Haiku），dev-story正是通过这张名册把任务路由给正确的程序员。

二、Phase 1-2：定位故事并加载完整上下文

2.1 找到要实现的 Story

/dev-story的参数是一个可选的[story-path]：

• 提供了路径：直接读取该故事文件。
• 未提供参数：先检查production/session-state/active.md中的当前活动故事，若找到则向用户确认"是否继续该故事"；若没有，则询问用户，并通过 Glob 搜索production/epics/**/*.md，列出所有Status: Ready的故事供选择。

2.2 前置文件存在性校验（硬门禁）

在加载任何上下文之前，dev-story首先根据故事中的ADR Governing Implementation字段提取 ADR 路径，并校验三类关键文件是否存在：

若 TR 注册表或治理 ADR 缺失，故事状态被置为BLOCKED并写入会话状态，且不派生任何程序员 Agent。这条规则保证了"没有设计依据就不写代码"。

仓库中实际的 docs/architecture/tr-registry.yaml 正是这一机制的落地文件，它维护着每个 GDD 技术需求的稳定 ID（格式TR-[system-slug]-[NNN]），并明确声明"ID 永久有效、绝不重编号、删除只能标记 deprecated"、需求改写只更新requirement文本并追加revised日期。这也解释了为什么dev-story要求以注册表中的当前requirement文本为唯一事实来源——故事文件内联引用的需求文本可能已过期（stale）。

2.3 并行读取四类上下文

通过校验后，dev-story会同时（independent reads）读取以下上下文，且明确要求"所有上下文加载完成前不得开始实现"：

1. 故事文件：提取故事标题、ID、层级（layer）、类型（Logic / Integration / Visual/Feel / UI / Config/Data）、TR-ID、治理 ADR 引用、故事头部的 Manifest Version、逐条验收标准（acceptance criteria）、实现备注（ADR guidance 段落）、Out of Scope 边界、Test Evidence（要求的测试文件路径）、Dependencies（依赖列表）。
2. TR 注册表：读取docs/architecture/tr-registry.yaml，按 TR-ID 查找当前需求文本。
3. 治理 ADR：读取docs/architecture/[adr-file].md，提取完整 Decision 部分、Implementation Guidelines（程序员遵循的指南）、Engine Compatibility（cutoff 后的 API 与已知风险）、ADR Dependencies。
4. 控制清单：读取docs/architecture/control-manifest.md，提取该故事所属 layer 的 Required patterns、Forbidden patterns、性能护栏（performance guardrails）。

2.4 Manifest 版本一致性检查

dev-story会比对故事内嵌的Manifest Version与当前控制清单头部的版本日期：

• 一致：直接继续。
• 不一致：通过AskUserQuestion让用户三选一——
  • [A]更新故事中的 Manifest Version 并按当前规则实现（推荐）；
  • [B]按旧规则实现（用户自担不合规风险）；
  • [C]停止，先人工审查 manifest 差异。

选[A]时需在派生程序员之前先编辑故事文件的Manifest Version:字段；选[B]时仍要求细读新规则，并在 Phase 6 总结的 "Deviations" 中记录版本不匹配；选[C]则彻底停止、不派生任何 Agent。

2.5 依赖校验（Dependency Validation）

从故事提取 Dependencies 列表后，逐项验证：

1. Glob 搜索production/epics/**/*.md定位每个依赖故事文件；
2. 读取其Status:字段；
3. 若任一依赖状态不是Complete或Done，通过AskUserQuestion询问——
   • [A]仍然继续（接受依赖风险）；
   • [B]停止，先完成依赖；
   • [C]依赖实际已完成但状态未更新——将其标记为 Complete 并继续（需先征求同意）。

选[B]时该故事被置为BLOCKED且不派生 Agent；选[A]则必须在 Phase 6 总结的 "Deviations" 下注明"在有未完成依赖的情况下实现"。依赖文件找不到时给出警告" Dependency story not found: [path]"，并提示核对路径或创建故事文件。

2.6 引擎技术偏好

最后读取 .claude/docs/technical-preferences.md，获取：

• Engine:值——决定派生哪些程序员 Agent；
• 命名约定（类名、文件名、信号/事件名）；
• 性能预算（帧预算、内存上限）；
• Forbidden patterns。

该文件由/setup-engine填充（当前仓库中仍是[TO BE CONFIGURED]占位状态），是后续路由与编码规范的依据。

三、Phase 3：路由到正确的程序员 Agent

dev-story根据故事的Layer、Type 与系统名决定通过Task派生哪个专家。

3.1 特殊分支：Config/Data 故事跳过 Agent 派生

若故事类型为Config/Data，完全不需要派生程序员 Agent 或引擎专家，直接跳到 Phase 4 的 Config/Data 处理分支——实现本质是一次数据文件编辑，无需路由表评估。

3.2 主程序员路由表

这些角色在 .claude/docs/agent-roster.md 中有明确定义，例如engine-programmer（引擎系统、渲染、物理、内存管理）、gameplay-programmer（玩法代码）、ai-programmer（AI 系统）、network-programmer（网络代码）均为 Sonnet 层级的 Specialist。而 CCGS Skill Testing Framework/agents/specialists/engine-programmer.md 进一步展示了这些 Agent 的能力边界测试，例如：对象池实现（含单元测试）、越域请求重定向到ui-programmer、内存泄漏诊断流程、跨域协作时与lead-programmer协调 API 变更、以及在给出 Godot 4.6 引擎版本参考时以VERSION.md为准（Jolt 成为默认物理引擎）而非依赖训练数据。

3.3 引擎专家：代码类故事的次级 Agent

对于代码类故事，需从 .claude/docs/technical-preferences.md 的Engine Specialists段落读取配置的主专家，并在故事涉及引擎特定 API、模式，或 ADR 标注 HIGH 引擎风险时，将其与主 Agent 一起派生：

当引擎风险为 HIGH 时（来自 ADR 或 VERSION.md），即使是非引擎面向的故事也必须派生引擎专家——因为 HIGH 风险意味着 ADR 记录了对 cutoff 之后引擎 API 的假设，需要专家验证。仓库中的引擎文档体系（docs/engine-reference/）按 Godot / Unity / Unreal 分别维护了 modules、plugins、VERSION.md、breaking-changes.md 等参考，正是这些专家 Agent 的校验依据。

四、Phase 4-5：实现与测试编写

4.1 向程序员 Agent 传递完整上下文包

通过Task派生程序员 Agent 时，必须提供 8 项内容：

1. 完整的故事文件内容；
2. TR 注册表中的当前 GDD 需求文本；
3. ADR 的 Decision + Implementation Guidelines（逐字传递，不得摘要）；
4. 该 layer 的控制清单规则；
5. 引擎命名约定与性能预算；
6. ADR Engine Compatibility 段落中的引擎特定注意事项；
7. 必须创建的测试文件路径；
8. 显式指令：实现这个故事并编写测试。

Agent 的行为约束包括：按 ADR 指南在src/中创建/修改文件、遵守控制清单的 Required/Forbidden patterns、不得越过故事的 Out of Scope 边界触碰无关文件、为公开 API 编写带文档注释的干净代码。

4.2 三种特殊故事类型

• Config/Data 故事：无需 Agent，直接编辑数据文件，并记录每个值从什么改为什么（from/to）。
• Visual/Feel 故事：派生gameplay-programmer实现代码/动画调用，但注意其验收标准无法自动验证——"手感是否到位"（does it feel right?）在/story-done阶段通过人工确认完成。
• Logic 与 Integration 故事：测试必须随实现一同编写，绝不允许推迟。技能要求以如下提醒告知程序员 Agent：

"The test file for this story is required at:[path from Test Evidence section]. The story cannot be closed via/story-donewithout it. Write the test alongside the implementation, not after."

4.3 测试编写标准

依据 .claude/docs/coding-standards.md 的 Testing Standards 章节，测试要求如下：

• 文件命名：[system]_[feature]_test.[ext]；
• 函数命名：test_[scenario]_[expected_outcome]；
• 每个验收标准至少有一个测试函数覆盖；
• 禁止随机种子、禁止时间相关断言、禁止外部 I/O；
• 必须测试 GDD Formulas 章节的公式边界值。

同时该文档明确了按故事类型的测试证据要求：Logic 故事需要tests/unit/[system]/下的自动化单元测试（BLOCKING 门禁）、Integration 需要集成测试或文档化 playtest（BLOCKING）、Visual/Feel 需要截图 + 负责人签署（ADVISORY）、UI 需要人工走查文档或交互测试（ADVISORY）、Config/Data 需要 smoke check 通过报告（ADVISORY）。在 CI/CD 层面还给出了各引擎的测试命令示例：Godot 用godot --headless --script tests/gdunit4_runner.gd，Unity 用game-ci/unity-test-runner@v4，Unreal 用带-nullrhi标志的无头 runner。

对于Visual/Feel 与 UI故事：不写自动化测试，提醒 Agent 在实现总结中注明需要的人工证据："Evidence doc required atproduction/qa/evidence/[slug]-evidence.md."；对于Config/Data故事：不写测试文件，以 smoke check 作为证据。

五、Phase 6-7：结果收集、总结与会话状态更新

5.1 收集项

程序员 Agent 完成后，收集：创建/修改的文件（带路径）、测试文件（路径与测试函数数量）、对 Out of Scope 边界的任何偏离（需标记）、Agent 提出的问题或阻塞项、专家标记的引擎特定风险。

5.2 实现总结模板

技能给出了标准的总结输出模板，要点如下：

## Implementation Complete: [Story Title] **Files changed**: - `src/[path]` — created / modified ([brief description]) - `tests/[path]` — test file ([N] test functions) **Acceptance criteria covered**: - [x] [criterion] — implemented in [file:function] - [x] [criterion] — covered by test [test_name] - [ ] [criterion] — DEFERRED: requires playtest (Visual/Feel) **Deviations from scope**: [None] or [list files touched outside story boundary] **Engine risks flagged**: [None] or [specialist finding] **Blockers**: [None] or [describe] Ready for: `/code-review [file1] [file2]` then `/story-done [story-path]`

5.3 会话状态更新

静默向production/session-state/active.md追加会话摘录（记录故事路径与标题、变更文件、测试路径或 "None — Visual/Feel/Config story"、阻塞项、下一步动作），文件不存在则创建。随后向用户确认 "Session state updated."。

六、错误恢复协议（Error Recovery Protocol）

任何通过 Task 派生的 Agent 若返回 BLOCKED、报错或无法完成，按以下流程处理：

1. 立即上报：在进入依赖阶段前向用户报告 "[AgentName]: BLOCKED — [reason]"；
2. 评估依赖：判断被阻塞 Agent 的输出是否为后续阶段所需；若是，则在得到用户输入前不得越过该依赖点；
3. 提供选项（AskUserQuestion）：跳过该 Agent 并在最终报告中注明缺口 / 以更小范围重试 / 停止并先解决阻塞；
4. 始终产出部分报告：保留已完成的工作，绝不因单个 Agent 阻塞而丢弃。

常见的阻塞场景及处理：

• 输入文件缺失（故事找不到、GDD 缺失）→ 转给创建它的技能；
• ADR 状态为 Proposed → 不实现，先运行/architecture-decision；
• 范围过大 → 通过/create-stories拆分为两个故事；
• ADR 与故事指令冲突 → 上报冲突，不得擅自猜测；
• Manifest 版本不匹配 → 向用户展示 diff，询问按旧规则继续还是先更新故事。

七、协作协议：编排器不直接写文件

dev-story作为编排器遵循严格的协作协议：

• 文件写入全部委托：所有源码、测试文件、证据文档都由通过 Task 派生的子 Agent 写入，每个子 Agent 单独执行 "May I write to [path]?" 协议，编排器自身不直接写文件；
• 先加载后实现：上下文（story、TR-ID、ADR、manifest、引擎偏好）未加载完不得开始编码，否则代码会偏离设计；
• ADR 即法律：实现必须遵循 ADR 的 Implementation Guidelines；若指南与"看起来更好"的做法冲突，应在总结中标记而非默默偏离；
• 严守范围：Out of Scope 段落是契约；若实现某验收标准必须触碰越界文件，停下来上报："Implementing [criterion] requires modifying [file], which is out of scope. Shall I proceed or create a separate story?"；
• Logic/Integration 的测试不可缺席：测试文件不存在就不能标记实现完成；
• Visual/Feel 标准是延迟而非跳过：在总结中标记为 DEFERRED，由/story-done人工验证；
• 重大结构性决策前先询问：若故事需要 ADR 未覆盖的架构模式，先上报："The ADR doesn't specify how to handle [case]. My plan is [X]. Proceed?"

这套"编排器收集上下文 → 派生专职 Agent 实现 → 汇总报告 → 更新会话状态"的模式，与仓库中 .claude/docs/coordination-rules.md 定义的纵向委派（领导 Agent → 部门主管 → 专家）、并行 Task 协议（独立输入同时派生、BLOCKED 立即上报、部分报告机制）完全一致，是 CCGS 多 Agent 编排哲学在实现环节的集中体现。

八、从 dev-story 出发的完整闭环

实现完成后，dev-story的 Recommended Next Steps 指向：

• 运行/code-review [file1] [file2]在关闭故事前评审实现；
• 运行/story-done [story-path]验证每条验收标准并标记故事完成——该技能会读取 TR 注册表中的当前需求文本、比对 Manifest 版本、检查测试证据门禁（Logic/Integration 缺测试为 BLOCKING）、生成"验收标准 ↔ 测试"追溯表，并最终更新故事状态与会话状态；
• sprint 内所有故事完成后，运行/team-qa sprint执行完整 QA 循环，再推进项目阶段。

至此，一条从/qa-plan sprint到/story-done的研发闭环完整成形：dev-story扮演着"把设计承诺兑现为可运行代码与可验证测试"的关键枢纽，其七阶段流程、硬门禁校验、按类型差异化路由与测试策略，构成了 CCGS 体系中防止"实现漂移于设计"的核心机制。

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