用 /team-live-ops 编排 Claude Code 游戏工作室的 Live-Ops 团队七阶段赛季规划流水线实战解析【免费下载链接】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-live-ops是 Claude-Code-Game-StudiosCCGS项目内置的团队编排 Skill用于在发布后post-launch阶段统筹策划赛季Season、限时活动Event与实时内容更新。它以一条七阶段结构化流水线串联 live-ops-designer、economy-designer、analytics-engineer、community-manager、narrative-director 与 writer 六名 AI Agent并在每个阶段转换点通过AskUserQuestion强制用户审批。读完本文你将掌握该 Skill 的完整调用方式、每名团队成员的责任边界、并行委托与伦理审查Ethics Review机制以及它与/design-review、/sprint-plan、/team-release的交接关系。Skill 定位从 Skill 定义到仓库注册该 Skill 的源文件位于 .claude/skills/team-live-ops/SKILL.md其 frontmatter 定义了被 Claude Code 识别与调用的全部元信息--- name: team-live-ops description: Orchestrate the live-ops team for post-launch content planning: coordinates live-ops-designer, economy-designer, analytics-engineer, community-manager, writer, and narrative-director to design and plan a season, event, or live content update. argument-hint: [season name or event description] user-invocable: true allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task, AskUserQuestion, TodoWrite ---name即斜杠命令名调用方式为/team-live-ops [赛季名或活动描述]user-invocable: true表示该 Skill 可由用户直接触发allowed-tools限定了编排器可用的工具面其中Task是委派子 Agent 的核心工具AskUserQuestion用于阶段决策点。在仓库的 Skill 目录清单 CCGS Skill Testing Framework/catalog.yaml 中该 Skill 与 live-ops-designer Agent 均被登记在案且对应一份独立的测试规格文档 CCGS Skill Testing Framework/skills/team/team-live-ops.md后者以 5 个测试用例对流水线行为做静态断言本文后续会逐项引用作为验证依据。团队构成六名成员的职责与源码配置SKILL.md 首先给出了团队构成清单。结合 .claude/agents/ 目录下的各 Agent 定义文件可得到更完整的职责边界成员核心职责来自 SKILL.mdAgent 定义文件源码佐证模型 / 工具配置live-ops-designer赛季结构、活动节奏、留存机制、战斗通行证.claude/agents/live-ops-designer.mdsonnetRead/Glob/Grep/Write/Edit/Task禁用 Basheconomy-designer实时经济平衡、商店轮换、货币定价、保底计时器pity timers.claude/agents/economy-designer.mdsonnetRead/Glob/Grep/Write/Editanalytics-engineer成功指标、A/B 测试设计、事件埋点、看板规格.claude/agents/analytics-engineer.mdsonnetRead/Glob/Grep/Write/Edit/Bash/WebSearchcommunity-manager玩家侧公告、活动描述、赛季消息.claude/agents/community-manager.mdhaikuRead/Glob/Grep/Write/Edit/Task禁用 Bashnarrative-director赛季叙事主题、故事弧线、世界事件框架.claude/agents/narrative-director.mdsonnetRead/Glob/Grep/Write/Edit/WebSearch禁用 Bashwriter活动描述、奖励物品名、赛季风味文本、公告文案.claude/agents/writer.mdsonnetRead/Glob/Grep/Write/Edit从各 Agent 定义文件可以确认一个贯穿全项目的协作约束所有设计类 Agent 都遵循Question-First协作协议——先提问澄清、给出 2-4 个带理由的选项、把最终决定权交还给用户并且在写文件前必须显式询问 May I write this to [filepath]?。例如 live-ops-designer 的协议明确要求 Get approval before writing fileseconomy-designer 则要求逐节增量写入并同步production/session-state/active.md。这意味着/team-live-ops编排出来的产物本质上是六名顾问型Agent 在用户审批约束下的协作结果。委托机制Task 工具与上下文传递SKILL.md 的 How to Delegate 一节规定使用Task工具以subagent_type派生子 Agentsubagent_type: live-ops-designer—— 赛季/活动结构与留存机制subagent_type: economy-designer—— 实时经济平衡与奖励定价subagent_type: analytics-engineer—— 成功指标、A/B 测试、事件埋点subagent_type: community-manager—— 玩家侧沟通与消息subagent_type: narrative-director—— 赛季主题与叙事框架subagent_type: writer—— 全部玩家侧文本关键约束是每个 Agent 的 prompt 都必须携带完整上下文游戏概念文档路径game concept path、已有赛季文档existing season docs、伦理政策路径ethics policy path、当前经济状态current economy state。同时允许在流水线允许的位置并行启动独立 Agent——SKILL.md 明确写出 Phases 3 and 4 can run simultaneously第 3、4 阶段可并行。这条并行语义在测试规格 team-live-ops.md 的 Case 4 中被严格断言Phase 3 与 Phase 4 的两次 Task 调用必须在等待任一结果之前同时发出且 analytics-engineer 的 prompt 不得把 economy-designer 的输出作为必需输入两者输入相互独立若其中一个阻塞另一个继续产出Phase 5 必须等两者结果齐备后才开始。七阶段规划流水线Pipeline整个 Skill 的核心是一条从范围界定到签核交付的七阶段流水线。以下逐阶段梳理并补充各阶段输入输出与可验证细节。Phase 1赛季/活动范围界定Season/Event Scoping委派给live-ops-designer负责定义赛季或活动的类型seasonal / limited-time event / challenge、时长与主题方向列出内容清单新增什么模式、物品、挑战、故事节拍定义留存钩子retention hook本赛季如何驱动玩家每日/每周回归识别资源预算需要新建多少内容、复用多少旧内容输出赛季简报season brief——含范围、内容清单与留存机制概览。值得指出live-ops-designer 的 Agent 定义在内容节奏Content Cadence中给出了更细的节奏分层日更登录奖励、每日挑战、商店轮换、周更周挑战、精选物品、社区活动、双周/月度内容更新、平衡补丁、新物品、赛季级 6-12 周重大内容投放、通行证重置、叙事弧线、年度周年庆、年度回顾。该定义还要求每个节奏层级必须保有 2 周以上的生产缓冲并把完整节奏日历落在约定路径design/live-ops/content-calendar.md。Phase 2叙事主题Narrative Theme委派给narrative-director阅读 Phase 1 的赛季简报设计赛季叙事主题该事件如何与游戏世界连接定义玩家将在活动中发现的中心故事钩子story hook识别本赛季可以推进的既有剧情线索lore threads输出叙事框架文档narrative framing document——主题、故事钩子、剧情连接。narrative-director 的 Agent 定义进一步明确了其架构叙事而非逐行写作的边界它负责故事架构、世界构建规则、角色弧线与叙事节奏但不写最终对白对话草稿委托给 writer并且所有世界元素文档必须包含核心概念、规则、历史、连接、玩家相关性、矛盾检查六个部分以保证内部一致性。Phase 3经济设计Economy Design可并行委派给economy-designer阅读赛季简报与既有经济规则约定路径design/live-ops/economy-rules.md设计奖励轨reward track免费轨推进、付费轨价值主张规划赛季内经济赛季货币、商店轮换、定价为任何随机元素定义保底计时器pity timer机制与坏运气保护bad-luck protection核查付费轨中不含任何 pay-to-win 物品输出经济设计文档——奖励表、定价、货币流动。economy-designer 的 Agent 定义给出了两处重要的实操约束注册表感知Registry Awareness在编写任何物品或战利品表之前必须先读取 design/registry/entities.yaml以其中登记的物品价值gold value、weight、rarity为准绝不定义与注册条目矛盾的物品价值若确需修改必须显式标记为建议的注册表变更并在完成战利品表后请求将跨系统新物品加入注册表。奖励输出格式Reward Output Format涉及概率掉落或条件发放时必须给出显式数值而非模糊描述——输出表Output / Frequency-Rate / Condition or Weight / Notes、期望获取时间expected acquisition、保底/上限floor/ceiling三要素缺一不可若游戏本身没有概率奖励系统如纯叙事解谜游戏则整节跳过。Phase 4分析与成功指标Analytics and Success Metrics可并行委派给analytics-engineer阅读赛季简报定义成功指标参与率目标participation rate target、留存提升目标retention lift target、通行证完成率battle pass completion rate设计赛季内要跑的 A/B 测试例如不同的奖励节奏指定本赛季内容所需的新遥测事件telemetry events输出分析计划——成功标准与埋点要求。analytics-engineer 的 Agent 定义补充了埋点规范事件命名约定为[category].[action].[detail]示例包括game.level.completed、economy.currency.spent、progression.milestone.reached且每个事件都必须有文档化的目的。它还负责漏斗分析、A/B 测试框架分群、变体分配、成功指标、最小样本量与看板规格并必须遵守隐私合规提供 opt-out 机制。Phase 5内容写作Content Writing并行本阶段并行委派narrative-director如需要撰写赛季的游戏内叙事文本——过场脚本cutscene scripts、NPC 对白、世界事件描述writer撰写全部玩家侧文本——活动名、奖励物品描述、挑战目标文本、赛季风味文本两者都必须阅读 Phase 2 的叙事框架文档。writer 的 Agent 定义明确了文本质量标准对白带说话人标签与上下文注释、变量插入使用命名占位符如{player_name}、{item_count}、单行不超过 120 字符、面向本地化编写避免无法翻译的习语。测试规格的 Coverage Notes 指出Phase 5 的并行逻辑与 Phase 3/4 共用同一套并行 Task 协议因此其正确性由 Case 4 隐式验证不再单独建用例。Phase 6玩家沟通计划Player Communication Plan委派给community-manager阅读赛季简报、经济设计与叙事框架起草赛季上线公告语气、核心亮点、分平台版本规划沟通节奏上线前预热pre-launch teaser、上线日帖子launch day post、赛季中段提醒mid-season reminder、最后一周 FOMO 冲刺final week FOMO push起草首日补丁说明day-1 patch notes的已知问题占位章节输出沟通日历communication calendar——含每个触点的草稿文案。community-manager 的 Agent 定义将玩家视角写作列为标准补丁说明面向玩家而非开发者、包含变更前后数值before/after values、危机沟通遵循30 分钟内确认问题、事件期间每 30-60 分钟更新一次的节奏其危机沟通模板位于 .claude/docs/templates/incident-response.md。Phase 7审查与签核Review and Sign-off收集全部阶段产出向用户呈现整合后的赛季计划赛季简报Phase 1叙事框架Phase 2经济设计与奖励表Phase 3分析计划与成功指标Phase 4写作内容清单Phase 5沟通日历Phase 6呈现的总结必须覆盖五个维度内容范围将创建什么、经济健康检查奖励轨是否公平、非掠夺性、分析就绪度成功标准是否定义并被埋点、伦理审查见下一节、未决问题生产中前仍需决策的事项。决策点机制AskUserQuestion 与 Explain → Capture 模式SKILL.md 的 Decision Points 一节规定了阶段转换的强制交互每个阶段转换处使用AskUserQuestion把子 Agent 的提案作为可选项呈现给用户编排器先在对话中完整写出 Agent 的分析再用简洁标签捕获决策用户必须批准后才能进入下一阶段。这套先解释、后捕获Explain → Capture模式在六名 Agent 的定义文件中均有同构实现。以 live-ops-designer 为例其定义要求每次决策点选项、澄清问题都使用AskUserQuestion单次调用最多批量 4 个独立问题标签 1-5 个词、描述一句话、推荐项标注 (Recommended)开放性问题或文件写入确认则改用对话形式。该模式的最终裁决权始终保留给用户——Agent 只是顾问。伦理审查与 BLOCKED 判定不让掠夺性设计蒙混过关Phase 7 的伦理审查是/team-live-ops最独特的安全闸门SKILL.md 规定了两种精确的标记协议场景 A伦理政策文件缺失若design/live-ops/ethics-policy.md不存在必须在赛季设计输出文档中标记ETHICS REVIEW SKIPPED:design/live-ops/ethics-policy.mdnot found. Economy design was not reviewed against an ethics policy. Recommend creating one before production begins.同时在下一步行动next steps中加入创建design/live-ops/ethics-policy.md。注意此场景不阻断COMPLETE 判定——测试规格 Case 5 明确断言文件缺失时 Skill 不得报错、不得凭空捏造伦理规则仍可达成 COMPLETE但缺口必须醒目标记在输出文档与对话中。场景 B发现伦理违规若文件存在且发现违规必须标记ETHICS FLAG: [element] in Phase 3 economy design violates [policy rule]. Approval is blocked until this is resolved.此时不得发布 COMPLETE 判定、不得写输出文档而是用AskUserQuestion提供三个选项修订经济设计revise economy design/ 附带书面理由的覆盖override with documented rationale/ 取消cancel。若用户选择修订则重新派发 economy-designer 产出修正设计再回到 Phase 7 复查。测试规格 Case 2 完整演练了该路径fixture 中伦理政策明确禁止面向 18 岁以下玩家的战利品箱economy-designer 在 Phase 3 提出神秘宝箱Mystery Chest随机奖励机制且无保底——Phase 7 审查识别出该违规、给出 ETHICS FLAG、在用户批准赛季计划之前弹出解决选项且未解决前绝不输出文档。只有当用户批准且无未解决违规时才能给出最终判定Verdict:COMPLETE—— 赛季计划产出并移交生产若存在未解决伦理违规则 Verdict:BLOCKED。输出文档与文件写入协议所有文档统一保存到约定目录design/live-ops/SKILL.md 规定的命名规范文档来源命名规则赛季设计文档Phase 1-3seasons/S[N]_[name].md分析计划Phase 4seasons/S[N]_[name]_analytics.md沟通日历Phase 6seasons/S[N]_[name]_comms.md配套的File Write Protocol是编排器的核心纪律所有文件写入赛季设计文档、分析计划、沟通日历都委托给通过 Task 派生的子 Agent每个子 Agent 强制执行 May I write to [path]? 协议编排器本身不直接写文件。测试规格的 Protocol Compliance 进一步断言每个输出文档都要由对应子 Agent 单独提出一次写文件询问。测试用例 Case 1Happy Path以/team-live-ops Season 2: The Frozen Wastes为输入断言三个输出文件按命名规范落到design/live-ops/seasons/下且写入均委托给子 Agent。需要说明design/live-ops/是 Skill 约定创建的生产输出目录当前仓库 design/ 下仅有CLAUDE.md与registry/首次运行/team-live-ops时由子 Agent 按协议创建。错误恢复协议BLOCKED 不是终点SKILL.md 为任一 Task 子 Agent 返回 BLOCKED、报错或无法完成定义了四步恢复流程立即表面化在进入依赖阶段前先向用户报告 [AgentName]: BLOCKED — [reason]评估依赖检查被阻塞 Agent 的输出是否为后续阶段必需——若是未经用户输入不得越过该依赖点提供选项通过AskUserQuestion给出三种选择——跳过该 Agent 并在最终报告中注明缺口 / 以更窄范围重试 / 先停下解决阻塞始终产出部分报告输出已完成的工作绝不允许因为某个 Agent 阻塞而丢弃成果。若 BLOCKED 状态无法解决最终判定为 Verdict:BLOCKED而非 COMPLETE。测试规格 Case 4 的并行验证顺带覆盖了这一路径若 economy-designer 阻塞而 analytics-engineer 成功分析产出必须保留阻塞通过AskUserQuestion表面化。值得注意的是Skill 文档中不存在真实调用链或日志输出上述判定与输出均为该 Skill 在 Claude Code 会话中由编排器生成的运行约定。参数校验空参数时立即止损SKILL.md 的 Argument check 规定了无参数调用行为若调用时未提供赛季名或活动描述编排器必须原样输出Usage:/team-live-ops [season name or event description]— Provide the name or description of the season or live event to plan.然后立即停止——不派生任何子 Agent、不读取任何文件。测试规格 Case 3 对此做了严格断言不得猜测赛季名或虚构范围、错误信息必须包含带 argument-hint 的正确用法、在参数校验失败前不得发出任何 Task 调用、不得读写任何文件。这套宁可拒绝也不臆测的防线与/team-release的版本推断逻辑见 .claude/skills/team-release/SKILL.md形成对照——后者在版本缺失时会先读里程碑数据推断再确认而/team-live-ops选择直接要求用户提供参数。落地到生产Next Steps 与周边 Skill 协同SKILL.md 的 Next Steps 明确了赛季计划产出后的三条交接路径/design-review—— 对赛季设计文档做一致性校验/sprint-plan—— 安排赛季内容的创作排期。该 Skill.claude/skills/sprint-plan/SKILL.md会读取里程碑、上一迭代、design/gdd/中标记为可实现的特性与production/risk-register/风险登记并经过 producer 可行性门PR-SPRINT gate与 QA 计划门/team-release—— 赛季内容就绪后的发布执行由 release-manager、qa-lead、devops-engineer、producer 等组成的发布团队接手经 go/no-go 决策后部署上线。由此形成完整闭环/team-live-ops策划 →/design-review校验一致性 →/sprint-plan排期生产 →/team-release发布上线。而发布后生成的数据留存、参与率又会回流给 analytics-engineer成为下一赛季策划的输入。测试与验证从规格到可执行断言该 Skill 的质量保障不依赖运行时日志而是由测试规格 CCGS Skill Testing Framework/skills/team/team-live-ops.md 提供结构化的静态断言与行为用例静态断言Structural校验 frontmatter 字段齐全name、description、argument-hint、user-invocable、allowed-tools、≥2 个阶段标题、含 COMPLETE/BLOCKED 判定词、File Write Protocol 含 May I write 语言且声明编排器不直接写文件、结尾引用/design-review、/sprint-plan、/team-release、阶段转换使用AskUserQuestion、明确声明 Phase 3/4 可并行、存在错误恢复段、输出文档路径位于design/live-ops/seasons/行为用例Case 1 Happy Path七阶段全流程 三文档落盘 COMPLETE、Case 2 伦理违规ETHICS FLAG 不自动放行 三选项解决、Case 3 无参数usage 提示 立即停止、Case 4 并行阶段验证双 Task 同时发出、输入独立、部分结果保留、Case 5 缺失伦理政策ETHICS REVIEW SKIPPED 仍可达 COMPLETE 下一步建议创建政策文件协议合规清单Protocol Compliance每个阶段转换都用AskUserQuestion、Phase 3/4 恒为并行、编排器永不直接调用 Write/Edit、每个输出文档单独询问写权限、Phase 7 伦理审查始终显式引用伦理政策文件路径、任何 BLOCKED 立即表面化并提供 skip/retry/stop 选项、部分报告永不丢弃、COMPLETE 仅在用户批准后发布。这些用例既是 Skill 作者对自身行为的承诺也构成了后续基于 agent-test-spec 与 skill-test-spec 进行自动化回归测试的基线。结语/team-live-ops展示了 CCGS 项目把真实工作室层级结构镜像为 Agent 协作系统的核心设计思想用 frontmatter 声明能力边界、用Task委托保持编排器轻量、用AskUserQuestion把决策权留在人类手中、用伦理审查门禁阻止掠夺性变现、用 BLOCKED 判定体系保证失败可追溯、用测试规格让行为可断言。无论你是在为一个全新赛季做首发规划还是想复用其并行委托 伦理门 部分报告模式设计自己的多 Agent 编排 Skill这份七阶段流水线都提供了可直接落地的参考实现。【免费下载链接】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），仅供参考