用 Claude Code 编排游戏发布流水线：深入解析 team-release 技能与 CCGS 的七阶段发布协调系统

导读

team-release 是 Claude-Code-Game-Studios（CCGS）中负责从候选版本到部署上线的发布编排技能：它以"真人游戏工作室发布组"为模型，通过 Task 工具并行调度 release-manager、qa-lead、devops-engineer、producer 等子 Agent，执行从版本规划、候选构建、质量门禁、Go/No-Go 决策到部署与监控的完整流水线。读完本文，你将掌握如何调用该技能、理解七阶段流水线的每个决策点与产物、了解 Agent 阻塞时的错误恢复协议，以及它与仓库中 release-checklist、changelog、patch-notes 等子技能的协作机制——这套模式可以直接复用到任何需要"多人协作发布"的软件项目。

---

一、技能定位：发布不是一次部署，而是一次团队协作

在 CCGS 的 Agent 体系中，team-release 属于 .claude/skills/team-* 系列（同系列还有 team-qa、team-combat、team-ui 等），它们共同的特征是编排型技能（orchestrator skill）：本身不直接写文件，而是通过 Task 工具把工作委派给专业子 Agent。

技能的 YAML 前置元数据定义了它的契约：

---
name: team-release
description: "Orchestrate the release team: coordinates release-manager, qa-lead, devops-engineer, and producer to execute a release from candidate to deployment."
argument-hint: "[version number or 'next']"
user-invocable: true
allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task, AskUserQuestion, TodoWrite
---

关键信息解读：

• user-invocable: true 意味着它是用户可以显式调用的技能（/team-release），与 release-checklist 的"仅显式调用"约束保持一致；
• allowed-tools 中同时包含 Task（委派子 Agent）与 AskUserQuestion（决策交互）——这正是"编排 + 人工确认"双引擎的设计基础；
• 参数提示 [version number or 'next'] 表明调用时可传入版本号，也可以传 next 或省略。

参数检查：版本号从哪来

技能开篇规定了严格的参数检查流程，禁止硬编码默认版本：

1. 若未传版本号，先读取 production/session-state/active.md 与 production/milestones/ 下最近的文件（若存在）以推断目标版本；
2. 若推断成功，向用户报告 "No version argument provided — inferred [version] from milestone data. Proceeding." 并用 AskUserQuestion 确认；
3. 若完全无法发现版本信息，则必须通过 AskUserQuestion 询问用户"应该发布哪个版本号？（如 v1.0.0）"，等待输入后才能继续。

这一设计体现了 CCGS 的核心协作原则：Agent 可以推断，但最终决定权在用户手中。production/session-state/ 目录目前为空，意味着实际使用时这些状态文件由工作流按需生成，技能对此做了充分兜底。

---

二、发布团队组成：七个（或更多）专业角色

team-release 将真人工作室的发布职能映射为一组可委派的 Agent。下表汇总了技能定义的团队成员及其职责，对应的 Agent 定义文件位于仓库 .claude/agents/ 目录：

角色	职责	对应 Agent 定义
release-manager	发布分支、版本号、changelog、部署	release-manager.md
qa-lead	测试签核、回归套件、发布质量门禁	qa-lead.md
devops-engineer	构建流水线、产物、部署自动化	devops-engineer.md
security-engineer	发布前安全审计（游戏含联机/多人/玩家数据时启用）	security-engineer.md
analytics-engineer	验证遥测事件正确触发、看板就绪	analytics-engineer.md
community-manager	补丁说明、发布公告、面向玩家的沟通	community-manager.md
producer	Go/No-Go 决策、干系人沟通、排期	producer.md
network-programmer	网络代码稳定性签核（游戏含多人时启用）	network-programmer.md

值得注意的是，技能同时支持条件启用角色：只有游戏具备在线/多人特性或收集玩家数据时才拉起 security-engineer，只有包含多人玩法时才拉起 network-programmer。这种"按需组队"避免了资源浪费。

Agent 背后的源码级设计

每个 Agent 定义不仅是角色描述，还携带了工具权限、模型档次与技能绑定：

• release-manager.md 使用 model: sonnet，skills: [release-checklist, changelog, patch-notes]，即它天然拥有生成发布检查清单、变更日志与补丁说明的能力；它还定义了完整的六步发布流水线（Build → Test → Cert → Submit → Verify → Launch）、语义化版本号规则（MAJOR.MINOR.PATCH，内部构建号 MAJOR.MINOR.PATCH.BUILD）以及平台认证（TRC/TCR/Lotcheck）要求；
• qa-lead.md 定义了 S1（致命，阻断一切构建）/ S2（严重，阻断里程碑）/ S3（轻微）/ S4（琐碎）四级 Bug 严重度，并执行 shift-left 测试策略；
• devops-engineer.md 使用 model: haiku（成本更低），负责构建流水线与分支策略（main / develop / feature/* / release/* / hotfix/*）；
• producer.md 使用 model: opus（推理最强），是"最高层级顾问"，负责战略决策、排期与干系人沟通。

这些 Agent 都遵循同一套 Collaboration Protocol：协作式实现者而非自主代码生成器，任何写文件动作前必须征得用户许可（"May I write to [path]?"）。

---

三、七阶段发布流水线：每个阶段的委派与产物

技能的核心是七阶段流水线。决策点（Decision Points）规则贯穿始终：每个阶段过渡时，用 AskUserQuestion 将子 Agent 的方案作为可选项呈现给用户；Agent 须先在对话中写出完整分析，再用简洁标签记录决策，用户批准后才能进入下一阶段。

Phase 1：发布规划（Release Planning）—— 委派给 producer

• 确认所有里程碑验收标准均已达成
• 识别本次发布延期的范围项
• 设定目标发布日期并传达给团队
• 输出：含范围确认的发布授权

对应 producer.md 的里程碑管理与范围管理职责：producer 负责识别风险、协调跨部门并保证范围不蔓延。

Phase 2：候选版本（Release Candidate）—— 委派给 release-manager

• 从约定的提交点切出发布分支（对应 devops-engineer 分支策略中的 release/*）
• 在所有相关文件中提升版本号（语义化版本 MAJOR.MINOR.PATCH）
• 调用 /release-checklist 生成发布检查清单
• 冻结分支——不再接受新功能，只允许 Bug 修复
• 输出：发布分支名与检查清单

Phase 3：质量门禁（Quality Gate）—— 并行委派

此阶段是流水线中的第一个并行窗口，四个角色可同时运行：

角色	任务
qa-lead	执行完整回归测试套件；测试所有关键路径；确认零 S1/S2 Bug；质量签核
devops-engineer	为所有目标平台构建发布产物；验证构建干净且可复现；在 CI 中运行自动化测试
security-engineer（条件）	发布前安全审计：认证、反作弊、数据隐私合规
network-programmer（条件）	网络代码稳定性签核：延迟补偿、断线重连、负载下带宽使用

技能明确指出"Phase 3 的 Agent 可以并行运行"——这是 Task 工具能力的具体体现，也呼应了发布实践中"QA 与构建并行、互不阻塞"的真实工作方式。

Phase 4：本地化、性能与分析（Localization, Performance, and Analytics）

• 验证所有字符串均已翻译（有可用时委派给 localization-lead）
• 对照目标运行性能基准（有可用时委派给 performance-analyst）
• analytics-engineer：验证发布构建上所有遥测事件正确触发；确认看板收到数据；检查关键漏斗（onboarding、progression、按需 monetization）已埋点
• 输出：本地化、性能与分析签核

该阶段与 Phase 3 在资源允许时可并行。analytics-engineer 的事件命名规范在 analytics-engineer.md 中有明确定义：[category].[action].[detail]，例如 game.level.started、economy.currency.spent、progression.milestone.reached。

Phase 5：Go/No-Go 决策 —— 委派给 producer

• 收集签核：qa-lead、release-manager、devops-engineer、security-engineer（若在 Phase 3 启用）、network-programmer（若启用）以及 technical-director
• 评估未决问题——是阻断性还是可上线
• 做出 Go/No-Go 决定
• 输出：带理由的发布决策

若 producer 宣布 NO-GO：

• 立即向用户呈现："PRODUCER: NO-GO — [rationale, e.g., S1 bug found in Phase 3]."
• 用 AskUserQuestion 提供三个选项：
  1. 修复阻断项并重跑受影响的阶段
  2. 将发布推迟到更晚的日期
  3. 覆盖 NO-GO（用户必须提供书面理由）
• 完全跳过 Phase 6——不打标签、不部署到 staging、不部署到生产、不启动 community-manager
• 产出部分报告，总结 Phase 1–5 及被跳过的内容（Phase 6）及原因
• 判定：BLOCKED —— 发布未部署

Phase 6：部署（Deployment）—— 仅当 GO 时执行

委派给 release-manager + devops-engineer：

• 在版本控制中打发布标签（对应 version tags 规则：每次发布点必须打 git tag）
• 调用 /changelog 生成变更日志
• 部署到 staging 进行最终冒烟测试
• 部署到生产环境
• 发布后监控 48 小时

同时（与部署并行）委派给 community-manager：

• 使用 /patch-notes [version] 定稿补丁说明
• 准备发布公告（商店页更新、社交媒体、社区帖子）
• 若有任何 S3+ 问题随版本发布，起草已知问题帖
• 输出：所有面向玩家的发布沟通文案，在部署确认后即可发布

Phase 7：发布后（Post-Release）

角色	动作
release-manager	生成发布报告（发布内容、延期内容、指标）
producer	更新里程碑跟踪，与干系人沟通
qa-lead	监控新到的 Bug 报告中的回归
community-manager	发布所有面向玩家的沟通，监控社区情绪
analytics-engineer	确认线上看板健康；关键事件缺失时告警
团队	若出现问题则安排发布后复盘（retrospective）

---

四、配套子技能：让流水线"有据可依"

team-release 是编排者，具体工件由子技能生成，形成"技能调用技能"的层级：

/release-checklist —— 发布前验证清单

release-checklist 支持参数 [platform: pc|console|mobile|all]（缺省 all）。它扫描代码库中的 TODO / FIXME / HACK 注释计数、检查测试结果，然后生成结构化清单，包含：

• Codebase Health：TODO/FIXME/HACK 计数（FIXME 全部列出——潜在阻断项）
• Build Verification：干净构建、零告警策略、构建体积预算、版本号正确、可从 tag 复现
• Quality Gates：零 S1、零 S2（或经 producer 批准的文档化例外）、性能预算（最低配 FPS、内存、加载时长、无内存泄漏）、无回归、Soak Test 通过（4+ 小时连续游玩）
• Content Complete：占位资源替换、文本校对、本地化就绪、音频混音定稿、制作名单
• 平台专属区块：PC（Steam/Epic/GOG SDK、云存档、Steam Deck）、Console（TRC/TCR/Lotcheck、暂停/恢复、家长控制）、Mobile（商店指南、隐私政策、应用体积、内购流程）
• Store / Distribution 与 Launch Readiness：商店页元数据、年龄分级（ESRB/PEGI 等）、EULA、崩溃上报、首发补丁、72 小时 On-call 排班、回滚预案
• Go / No-Go 判定区块与四角色签核（QA Lead / Technical Director / Producer / Creative Director）

清单落盘前会询问 "May I write this to production/releases/release-checklist-[version].md?"——这正是技能提到的"May I write to [path]?"协议的具体体现。该技能与 qa-lead.md 的 skills: [bug-report, release-checklist] 绑定，也与 release-manager.md 的技能列表重合。

/changelog —— 双版本变更日志

changelog 从 git 提交、冲刺数据与设计文档自动生成内部版（含技术细节、提交哈希、负责人、指标统计）与玩家版（面向体验、无内部引用）两份 changelog。其上下文脚本直接调用 git：

!git log --oneline -30 2>/dev/null
!git tag --list --sort=-v:refname 2>/dev/null | head -5

内部版包含 Metrics 段（总提交数、文件变更数、新增/删除行数、无任务引用的提交数），并检查提交中是否含 [STORY-123]、TR-、#NNN 等任务引用。写入 docs/CHANGELOG.md 前提供三个选项：追加（默认推荐）、覆盖、不写。

/patch-notes —— 玩家向补丁说明

patch-notes 支持 [version] [--style brief|detailed|full]，将开发语言翻译为玩家语言（如 "Refactored damage calculation pipeline" → "Improved hit detection accuracy"）。它还会检测语气指南（.claude/docs/technical-preferences.md、docs/PATCH-NOTES-STYLE.md、design/community/tone-guide.md）与补丁模板（docs/patch-notes-template.md）。该技能绑定 agent: community-manager，产出写入 docs/patch-notes/[version].md 并归档到 production/releases/[version]/patch-notes.md。

这三个子技能的"写文件需先询问、产出需归档、判定用 Verdict"的模式，与 team-release 完全一致，形成了可预测的流水线行为。

---

五、错误恢复协议：当一个 Agent 卡住时

发布是最不该"悄悄失败"的流程。team-release 定义了严格的错误恢复协议：

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

技能还预先枚举了常见阻塞场景及处理方式：

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

这套协议的本质是"失败也要留痕"：即使发布被阻断，Phase 1–5 的部分报告仍会产出，跳过项和原因都会被记录，确保没有工作白白丢失。

---

六、文件写入协议与最终产物

技能特别强调：所有文件写入（发布检查清单、变更日志、补丁说明、部署脚本）都委派给子 Agent 与子技能，每个子技能强制执行 "May I write to [path]?" 协议，编排者（orchestrator）不直接写文件。这与仓库中所有 Agent 的 Collaboration Protocol 一脉相承——写文件是用户授权的动作，而非 Agent 的自动行为。

技能最终输出

A summary report covering: release version, scope, quality gate results,
go/no-go decision, deployment status, and monitoring plan.

Verdict: COMPLETE — release executed and deployed.
Verdict: BLOCKED — release halted; go/no-go was NO or a hard blocker is unresolved.

Next Steps（发布成功后）

• 监控发布后看板 48 小时
• 若发布期间出现重大问题，运行 /retrospective 复盘
• 部署成功后更新 production/stage.txt 为 Live

production/ 目录目前仅含 session-state/ 空目录，说明状态文件（active.md、milestones、releases 归档等）均由工作流按需创建——技能的路径约定（如 production/releases/release-checklist-[version].md、docs/patch-notes/[version].md）即为后续状态的落地规范。

---

七、实战调用示例与可复用要点

调用方式

/team-release v1.2.0
# 或
/team-release next
# 或直接调用，由技能从 milestone 数据推断版本并请你确认

从该技能可复用的设计模式

1. 条件角色：按项目特性（是否有联机/多人/玩家数据）动态启用专业角色，避免"全员上场"的资源浪费；
2. 并行窗口：识别流水线中可并行的阶段（Phase 3 四个角色并行），用 Task 同时拉起；
3. 显式决策点：阶段间用 AskUserQuestion 呈现方案选项，用户批准才推进——发布权始终在人；
4. NO-GO 短路：决策失败立即冻结后续全部动作（不打 tag、不部署、不发布公告），避免"半发布"状态；
5. 失败留痕：任何 Agent 阻塞都产出部分报告，跳过项与原因可追溯；
6. 写文件授权：编排者不直接写文件，所有落盘动作由子 Agent/子技能经用户授权执行。

这套"编排技能 + 专业子 Agent + 显式决策 + 失败恢复"的架构，正是 CCGS 将真人游戏工作室的发布管理流程完整映射到 Claude Code 的体现——它证明了一个可靠的发布流程，其核心不在于自动化本身，而在于谁在什么时候、以什么授权、做什么决策。

---

附：相关文件索引

• 技能主体：.claude/skills/team-release/SKILL.md
• 子技能：release-checklist、changelog、patch-notes、retrospective
• 团队成员 Agent：release-manager、qa-lead、devops-engineer、producer、security-engineer、analytics-engineer、community-manager、network-programmer、technical-director
• 状态与归档目录：production/session-state/、production/releases/、docs/patch-notes/