Claude Code Game Studios 叙事团队编排技能（team-narrative）实战指南：五阶段管线、并行委派与一致性治理

Claude Code Game Studios 叙事团队编排技能（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

在 Claude Code Game Studios 中，/team-narrative是专为叙事内容生产设计的团队编排技能（skill）：它把「导演—编剧—世界构建—美术—关卡」这条真实游戏工作室叙事生产线搬进单个 Claude Code 会话，用一条五阶段管线把 story beat、对话、世界观、关卡叙事集成与 i18n 合规串起来。读完本文，你将掌握如何用一个带参数的命令驱动多个专职 subagent 并行产出叙事内容，理解AskUserQuestion决策门、BLOCKED恢复协议与「May I write?」文件写入协议的具体用法，并能在实际项目中直接套用这套流程。

技能定位：从「单次聊天」到「叙事团队编排」

team-narrative位于 .claude/skills/team-narrative/SKILL.md，是仓库 72 个 skills 中负责「叙事团队编排」的入口。它的 frontmatter 明确声明了能力边界：

name: team-narrative description: "Orchestrate the narrative team: coordinates narrative-director, writer, world-builder, and level-designer to create cohesive story content, world lore, and narrative-driven level design." argument-hint: "[narrative content description]" user-invocable: true allowed-tools: Read, Glob, Grep, Write, Edit, Task, AskUserQuestion, TodoWrite

• user-invocable: true：这是一个用户可直接调用的 slash command；
• allowed-tools中的Task是编排的核心——编排器（orchestrator）本身不亲自写作，而是通过Task生成独立 subagent 会话去执行；
• 它不包含Bash，说明这是一个纯文档生产编排技能，不触碰构建或运行环境。

无参数时的用法引导

技能规定：如果调用时没有提供参数，不得生成任何 subagent，也不得使用AskUserQuestion猜测主题，而是直接输出使用引导并退出：

Usage:/team-narrative [narrative content description]— describe the story content, scene, or narrative area to work on (e.g.,boss encounter cutscene,faction intro dialogue,tutorial narrative).

对应的测试规格 CCGS Skill Testing Framework/skills/team/team-narrative.md 中的 Case 3 专门验证了这一行为：断言「技能不生成任何 agent」「不尝试从项目文件推测叙事主题」「不使用AskUserQuestion，直接输出引导」。

团队构成：六个角色与职责边界

team-narrative编排的团队由 6 个专职 agent 组成（其中 5 个为核心生产角色，1 个为本地化合规角色）：

Agent	职责	不负责
narrative-director	故事弧、角色设计、对白策略、叙事愿景	视觉风格、技术系统、生产排期
writer	对白撰写、lore 条目、物品描述、游戏内文本	故事架构、世界规则、UX 文案
world-builder	世界规则、阵营设计、历史、地理、环境叙事	具体 NPC 对白、机制规则、故事弧
art-director	角色视觉设计、环境视觉叙事、过场/电影感基调	音频方向、UX 交互流程、代码实现
level-designer	服务于叙事的关卡布局、节奏、环境叙事节拍	叙事对白、视觉风格、AI 行为代码
localization-lead	i18n 校验、字符串 key 合规、翻译余量评估	叙事内容本身、翻译工作、i18n 代码实现

这些角色定义在仓库两份位置中都有落实：实际生效的 agent 定义位于 .claude/agents/（如 narrative-director.md、writer.md、world-builder.md、art-director.md、level-designer.md、localization-lead.md），而CCGS Skill Testing Framework目录下则提供了对应 agent 的测试规格。

职责边界的源码级印证

以narrative-director为例，.claude/agents/narrative-director.md 中「What This Agent Must NOT Do」清单明确禁止：写最终对白（委托给 writer）、做玩法机制决策（与 game-designer 协作）、指导视觉设计（与 art-director 协作）、做对白系统技术决策。其「Delegation Map」指出它委派writer与world-builder，向creative-director汇报，与game-designer、art-director、audio-director协调。

writer的定义则细化了文本生产标准（.claude/agents/writer.md）：

• 所有对白带说话人标签与上下文注释；
• 变量插入必须使用命名占位符：{player_name}、{item_count}；
• 每行不超过 120 字符，保证对白框可读性；
• 文本必须「本地化友好」：避免无法翻译的习语、使用字符串模板做变量插入。

这些标准与team-narrative在 Phase 2/Phase 5 中对 writer 的要求（120 字符上限、命名占位符、localization-ready）一一对应，是从 agent 定义到团队编排的完整闭环。

world-builder的测试规格（CCGS Skill Testing Framework/agents/specialists/world-builder.md）还揭示了它面对 lore 矛盾时的行为：不静默覆盖既有设定，而是同时陈述新旧两个版本、给出解决方案选项，并在无法定论时把裁决路由给narrative-director——这正是 Phase 2 并行生产中防止世界观漂移的关键机制。

五阶段管线：从叙事愿景到交付

team-narrative的核心是一条五阶段流水线，每个阶段生成一个专职 agent 的产出，阶段之间用AskUserQuestion作为「决策门」（Decision Point）：编排器先把 agent 的完整分析写入对话，再用简洁标签让用户选择是否批准进入下一阶段。

Phase 1 叙事方向（narrative-director） ↓ AskUserQuestion 批准 Phase 2 世界基础（world-builder + writer + art-director，并行） ↓ AskUserQuestion 批准 Phase 3 关卡叙事集成（level-designer） ↓ AskUserQuestion 批准 Phase 4 一致性审查（narrative-director 复审） ↓ AskUserQuestion 批准 Phase 5 打磨（writer + localization-lead + world-builder，并行） ↓ 总结报告 → Verdict: COMPLETE / BLOCKED

Phase 1：叙事方向（narrative-director）

委派narrative-director完成：

• 定义内容的叙事目的：它服务于哪个 story beat？
• 识别涉及的角色、动机，以及它与整体故事弧的契合点；
• 设定情绪基调与节奏目标；
• 明确此内容引入的 lore 依赖或新 lore；
• 产出：带故事需求的叙事 brief（narrative brief）。

测试规格的 Case 1 验证了顺序约束：「narrative-director 必须先于任何其他 agent 在 Phase 1 被生成」，且AskUserQuestion必须出现在 Phase 1 输出之后、Phase 2 启动之前。

Phase 2：世界基础（并行委派）

这是管线中第一个并行阶段，要求在等待任何结果之前一次性发出全部三个 Task 调用：

• world-builder：为相关内容创建或更新阵营、地点、历史 lore 条目；对照既有 lore 交叉检查矛盾；为新条目设定 canon 级别；
• writer：使用角色 voice profile 起草对白；保证所有行不超过 120 字符、使用命名占位符、可本地化；
• art-director：为登场关键角色定义视觉方向（剪影、视觉原型、区分性特征）；为每个关键空间指定环境视觉叙事元素（道具构成、光照注释、空间排布）；为过场/脚本序列定义色调板与电影感方向。

Phase 3：关卡叙事集成（level-designer）

level-designer在此阶段接手：

• 审阅叙事 brief 与 lore 基础；
• 设计关卡中的环境叙事元素；
• 放置叙事触发器、对白区域与发现点（discovery points）；
• 确保节奏同时服务于玩法与故事。

level-designer的测试规格（CCGS Skill Testing Framework/agents/leads/level-designer.md）补充了其审查词汇：它使用APPROVED / REVISION NEEDED结论词，并且遇到「挑战密度 vs 节奏张力」这类跨域冲突时应升级到creative-director仲裁，而不是单方面否决。

Phase 4：一致性审查（narrative-director 复审）

再次委派narrative-director：

• 依据角色 voice profile 复审所有对白；
• 验证新旧 lore 条目间的一致性；
• 确认叙事节奏与关卡设计对齐；
• 检查所有悬念都有文档化的「真实答案」（true answers）——防止叙事留坑。

测试规格 Case 1 断言 narrative-director 在此阶段被「重新生成」（re-spawned）执行复审，而不是复用 Phase 1 的会话。

Phase 5：打磨（并行委派）

最后一个阶段再次并行：

• writer：最终自审——确认无一行超出对白框约束、所有文本使用字符串 key 而非裸字符串、占位符变量名一致；
• localization-lead：验证 i18n 合规——检查字符串 key 命名规范、标记无法在翻译中存活的硬编码格式、验证字符上限余量（德语/芬兰语等语言通常膨胀 +30%）、确认文本中没有需要各语言区变体的文化假设；
• world-builder：为所有新 lore 条目定稿 canon 级别。

测试规格 Case 1 断言 Phase 5 必须同时生成 writer、localization-lead、world-builder 三个 agent。

阶段决策门的实现约定

技能在「Decision Points」一节给出了编排器与用户交互的硬性约定：每个阶段转换都用AskUserQuestion把 subagent 的方案呈现为可选选项；agent 的完整分析先写入对话，然后用简洁标签捕获决策；未经用户批准不得进入下一阶段。对应的测试规格要求「每个阶段输出后、下一阶段启动前都必须使用AskUserQuestion」，且并行阶段（Phase 2 与 Phase 5）必须在等待结果前把全部 Task 调用一次性发出。

如何委派：Task 调用与上下文传递

编排器通过Task工具把每个团队成员作为独立 subagent 生成，subagent_type决定其身份：

• subagent_type: narrative-director— 故事弧、角色设计、叙事愿景
• subagent_type: writer— 对白撰写、lore 条目、游戏内文本
• subagent_type: world-builder— 世界规则、阵营设计、历史、地理
• subagent_type: art-director— 角色视觉档案、环境视觉叙事、电影感基调
• subagent_type: level-designer— 服务叙事的关卡布局、节奏
• subagent_type: localization-lead— i18n 校验、字符串 key 合规、翻译余量

上下文传递原则

技能明确要求：每个 agent 的 prompt 必须携带完整上下文——叙事 brief、lore 依赖、角色档案。这是因为 subagent 是拥有独立上下文的独立 Claude 会话，编排器不传、agent 就拿不到。design-review技能（.claude/skills/design-review/SKILL.md）中对 Task 的定义与此相互印证：「Task 生成的是拥有独立上下文窗口的独立会话，不是任务追踪；不要在自己内部模拟专家视角」。

并行性约束

「管线允许处并行启动独立 agent」（例如 Phase 2 的 agent 可同时运行）。测试规格把这一点写成了断言：Phase 2 的 world-builder 与 writer Task 调用必须同时发出（而非顺序发出），Phase 5 的三个 agent 同理。这意味着编排器应一次性发出全部 Task 调用再等待结果，而不是逐个等待。

错误恢复协议：BLOCKED 的响应链路

任何通过 Task 生成的 agent 返回 BLOCKED、报错或无法完成时，执行以下四步：

1. 立即呈现：在继续依赖阶段之前，先向用户报告[AgentName]: BLOCKED — [reason]；
2. 评估依赖：检查被阻塞 agent 的产出是否为后续阶段必需；若是，未经用户输入不得越过该依赖点；
3. 用AskUserQuestion提供选项：
   • 跳过该 agent 并在最终报告中标注缺口；
   • 以更窄的范围重试；
   • 停在当前点，先解决阻塞；
4. 始终产出部分报告——已完成的工作绝不因某个 agent 阻塞而丢弃。

常见阻塞场景（附路由）

阻塞原因	处理方式
输入文件缺失（story 未找到、GDD 不存在）	转交创建该文件的技能
ADR 状态为 Proposed	不实施，先运行/architecture-decision
范围过大	通过/create-stories拆分为两个 story
ADR 与 story 指令冲突	呈现冲突，不猜测

测试规格中的阻塞演练

team-narrative的测试规格用两个 Case 具体化了恢复协议：

• Case 2（lore 矛盾）：Phase 2 中 world-builder 发现叙事 brief 与既有 lore（design/narrative/lore/ironveil-history.md）关于建派时间的矛盾，返回 BLOCKED。编排器必须立即呈现矛盾、评估「writer 的对白依赖 canon lore」这一依赖链、通过AskUserQuestion提供三个选项（改 brief 以匹配旧 canon / 更新旧 lore / 先停下解决矛盾）。writer 已完成的对白草稿必须保留在部分报告中，不得丢弃；在用户解决矛盾前不得启动 Phase 3。
• Case 5（缺失 voice profile）：writer 因design/narrative/characters/下找不到角色 voice profile 而 BLOCKED。编排器须明确指出缺失的角色名与期望路径，提供「先建 voice profile / 提供内联的迷你 voice 方向并重试 / 停下先创建」等选项，不得凭空捏造角色声音，且 writer 阻塞期间不得启动 Phase 3。
• Case 4（本地化阻塞）：localization-lead 在 Phase 5 发现某行对白（如dialogue.ironveil.intro.003）使用了硬编码日期格式，无法本地化——这被标记为 BLOCKING 级问题并带具体 key 进入报告，用户可选择「立即修复 / 标注缺口继续交付 / 停下解决」；若选择带缺口继续，Verdict 为 COMPLETE 但附带本地化债务备注。

文件写入协议：编排器不碰文件

team-narrative有一个严格的写入纪律：所有文件写入（叙事文档、对白文件、lore 条目）都委派给通过 Task 生成的 subagent 执行，每个 subagent 都要遵循「May I write to [path]?」协议（先征得用户同意再写），编排器本身不直接写文件。

这与整个仓库的协作哲学一致：narrative-director与writer的 agent 定义都内置了「增量文件写入 + 写入前征得批准」的流程（先建骨架、逐节起草、显式询问「May I write this section to [filepath]?」）。测试规格把「编排器不直接写文件」「subagent 写入前必须征得同意」列为静态断言与协议合规项。

输出与判定：COMPLETE / BLOCKED

管线结束时产出总结报告，覆盖：叙事 brief 状态、创建的/更新的 lore 条目、已写对白行数、关卡叙事集成点、一致性审查结果、任何未解决的矛盾。

• 若管线因依赖未解决而中断（如 lore 矛盾或缺失前置未被用户解决）：Verdict: BLOCKED — [reason]；
• 否则：Verdict: COMPLETE — narrative content delivered。

测试规格的协议合规清单确认：Verdict 只能取COMPLETE或BLOCKED二者之一，不允许其他取值。

后续衔接：叙事产出的交付链路

技能末尾给出了三个标准下一步，形成与仓库其他 skills 的衔接：

1. /design-review：对叙事文档做一致性校验（.claude/skills/design-review/SKILL.md 中 GDD 域判定表把「Dialogue, quests, story, lore」路由给narrative-director）；
2. /localize extract：对白定稿后抽取新字符串进入翻译流程（.claude/skills/localize/SKILL.md 的 extract 模式会按[category].[subcategory].[description]规范生成 key，并要求每个新条目带context字段记录位置、字符上限与占位符含义）；
3. /dev-story：在引擎中实现对白触发器与叙事事件（.claude/skills/dev-story/SKILL.md 负责读取 story 文件、加载 ADR/TR registry/control manifest 上下文并路由到正确的程序员 agent 实现代码与测试）。

这三步完整覆盖了「叙事内容 → 设计校验 → 字符串抽取 → 引擎实现」的后续生命周期，team-narrative是其源头。

总结

team-narrative是 Claude Code Game Studios 中把「一个人」扩展为「一个叙事部门」的编排枢纽：通过五阶段管线（方向 → 并行世界基础 → 关卡集成 → 一致性复审 → 并行打磨）、每阶段必经的AskUserQuestion决策门、严格的 BLOCKED 恢复协议与「May I write?」写入纪律，它把叙事一致性、角色声音统一与本地化合规做成了可重复、可测试、可验证的流程。仓库中与其配套的 agent 定义（.claude/agents）、测试规格（CCGS Skill Testing Framework）与后续衔接技能（design-review、localize、dev-story）共同构成了从叙事创作到引擎落地的完整证据链——这也是这套「AI 游戏工作室」体系中叙事侧最具可操作性的工作流之一。

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