game-studio-harness

游戏工作室生产框架

由制作人协调的 5 Agent 团队，用于完整的游戏制作周期，遵循 bmad-gds 方法（需求简报 → 一种运行模式 → 协调文档 → 专家分派 → 里程碑线程），并设有数值质量门槛。 该框架是一套常设机制：周期会不断重复，直到游戏发布， 发布后也会持续用于运营。

创建运行前，请先阅读 references/quality-gates.md、references/stage-cycle.md 和 references/artifact-contract.md。references/quality-gates.md 中的门槛阈值优先于本指南中的任何转述。

何时使用此技能

• 从创意、GDD、原型或现有构建版本开始新的游戏制作周期
• 恢复进行中的周期（请先阅读 _workspace/current/production/task-manifest.md）
• 对当前构建版本进行阶段门审查（G1–G8 判定）
• 当试玩反馈、缺陷和里程碑压力发生冲突时，重新确定优先级
• 在同一个团队中开展游戏制作/平衡/变现/QA 周期

将范围更窄的任务分派给相应技能：原始构建/日志故障 → game-build-log-triage；分析器捕获数据 → game-performance-profiler； 仅反馈的分诊 → game-demo-feedback-triage；商店页面/发布运营 → steam-store-launch-ops；制作前的创意构思 → bmad-idea。

团队

角色	模板	负责内容
game-production-director	templates/agents/game-production-director.md	需求接收、任务清单、阶段门判定、仲裁、回顾
game-designer	templates/agents/game-designer.md	平衡表、连招矩阵、核心循环、新颖度评分卡、世界观、呈现规范、趋势调研
game-pm	templates/agents/game-pm.md	收入规划、奖励区间（回流奖励 ≤30%、免费/付费平衡为 10–20 局、胜率差 ≤5%p）、协商记录、收入预测
game-programmer	templates/agents/game-programmer.md	架构约定、性能预算（p95 ≤16.7ms，输入 ≤100ms）、移动路径优化、技术验证、遥测、缺陷响应
game-qa	templates/agents/game-qa.md	原型轮换（≥5 种）、漏洞登记、基准调研、阶段门测量、缺陷/回归登记

沟通拓扑：总监负责分派和把关；QA 将每项漏洞/发现广播给所有 Agent，并请求反馈；设计师↔PM 在签署的记录中协商奖励/收入关联；程序员在每个周期内答复所有缺陷（fixed 或 deferred + 原因）。

说明

步骤 0：准备

原因：每项产出都必须可追溯，且工作区只能有一个活动文件夹。

1. 在目标仓库根目录创建 _workspace/current/{intake,design,pm,engineering,qa,ops,ui,production,messages,retrospectives}/。不要创建带日期的运行目录——run-id（{YYYYMMDD}-{cycle-label}）是写在文档中的值，只有归档时才会成为目录名（_workspace/archive/{run-id}/）。
2. 如果是恢复周期，请阅读 _workspace/current/production/task-manifest.md 和最近一次回顾；从记录的阶段继续，而不是从第 1 阶段开始。
3. 周期结束时，将已被取代的工作流材料用 git mv 移入 _workspace/archive/{run-id}/。绝不要删除 _workspace/ 中的产出。

第 0.5 步：编写仓库规则文件

原因：该套件只约束运行它的会话。工作室学到的一切——职责分工、引擎边界、各生成器负责的资源类别、Git 安全协议——都会在本次会话结束时消失，除非将其写入所有后续会话都必须读取的位置。

1. 将 templates/repo-rules.md 复制到目标仓库的 Agent 指令文件中（Claude Code 使用 CLAUDE.md；为 Codex/Gemini/OpenCode 镜像到 AGENTS.md 作为指针，而不是另一份副本——两份契约会逐渐偏离，而发生偏离的契约比没有契约更糟）。
2. 根据真实仓库解析每个 {PLACEHOLDER}。残留占位符就是缺陷。删除不适用的部分：无人遵守的规则会让后续会话误以为规则是可选的。
3. 对任何违反起来很诱人或代价不明显的规则，在旁边说明原因。Never rename X 会被忽略；renaming X orphans every existing player's save data 则会得到遵守。
4. 每个周期结束时都重新推导一次，不要只在创建运行时推导。规则文件是周期产物——当 current/ 新增一条工作线、生成器被替换，或发现来之不易的不变量时，在更新之前它都是过时的。

第 1 步：组建团队

原因：Agent 必须基于文件，以便会话能够复用。

• 使用启用了 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 的 Claude Code：将 templates/agents/*.md 复制到目标仓库的 .claude/agents/（跳过已存在且匹配的文件），然后使用 TeamCreate + SendMessage + TaskCreate/TaskUpdate。
• 使用任何其他运行时（Codex、Gemini、OpenCode），或团队标志未启用：按照 references/stage-cycle.md 中的阶段顺序，将相同角色作为顺序子 Agent 运行；同级消息保存为 _workspace/current/messages/{seq}-{from}.md 中的编号文件。

第 2 步：接收需求（总监）

将需求规范化为 intake/production-brief.md（bmad-gds 架构： game_type, team_shape, engine, current_stage, next_public_beat, source_packet, main_constraint, main_question）。为本周期选择一种运行模式，并明确说明下一个公开节点。

第 3 步：运行 3 阶段运营周期

严格遵循 references/stage-cycle.md。摘要：

• 阶段 1 — 概念、呈现、动画、资源、核心构建： 设计师（概念 + 世界观 + 数值框架 + 通过 survey 技能开展趋势调查 + 核心循环候选方案 + 呈现规格）∥ PM （收入点草案）∥ QA（基准调查 + 测试计划 + 原型集合）。 然后设计师↔PM 进行第 1 轮协商，接着程序员构建核心循环 + 呈现/动画 + 资源清单 + 遥测草案。 关卡：G7 草案、G1 草案、G6-ops 草案。
• 阶段 2 — 平衡性、核心循环稳定性、新颖性开发： QA 针对原型搜寻可利用漏洞 → 设计师调整 → PM 调整奖励区间 → 第 2 轮协商 → 程序员应用仅涉及数据的更改 → QA 重新验证。关卡：G2、G3、G5、G7 最终版、G8。
• 阶段 3 — 运营稳定性和游玩影响（演出/剧情/特效）： 程序员进行性能、内存、移动优化和运营加固 ∥ 设计师+程序员进行呈现/剧情/特效影响检查 ∥ QA 全面回归测试 + 沉浸感评分 ∥ PM 收入一致性预测。 关卡：G4、G6 最终版、G1 最终版。

关卡判定结果为 PASS / FIX（最多 2 轮修订）/ REDO（退回上一阶段）。 未关闭的 S1 缺陷或缺失的证据会阻止任何 PASS。

步骤 4：周期收尾（总监）

1. 编写 retrospectives/cycle-{n}-retrospective.md：记录每道关卡的实测值、未解决的风险，以及下一周期的进入决策（阶段 1 概念调整，还是阶段 2 重新调校）。
2. 如果本周期更换了赛道、替换了生成器，或发现了值得强制执行的不变量，则重新推导仓库规则文件（步骤 0.5）。
3. 使用 git mv 将被取代的赛道材料移入 _workspace/archive/{run-id}/。current/ 只保留下一周期要延续的内容；任何内容都不得移出 _workspace/。

周期会循环进行——工作室是一种常设结构，而不是一次性流水线。

步骤 5：错误处理

场景	响应
Agent 超时	重试一次 → 将任务标记为 failed，继续处理部分结果，并在关卡评审中标记
数据冲突	记录到 conflicts.md；优先采用较新的测量值；由总监根据数值裁定
缺少输出	关卡不得判定为 PASS；在评审中发出警告
消息发送失败	通过 messages/ 使用基于文件的备用方案

示例

示例 1：从一个想法开启新周期

输入：“基于黑暗奇幻 RTS 的想法，开始游戏制作周期” 预期：创建 run-id，编写制作简报，组建团队， 分配阶段 1 任务；设计师趋势调研和 QA 基准调研通过 survey 技能执行； 周期以回顾总结和 G1–G8 关卡表结束。

示例 2：评审现有构建的阶段关卡

输入：“用当前构建进行阶段关卡评审” 预期：QA 针对该构建测量 G1–G8；总监根据证据路径逐关给出 PASS/FIX/REDO 判定；FIX 项转为清单任务。

示例 3：平衡性紧急问题

输入：“QA 发现无限组合漏洞，重新进入周期” 预期：从阶段 2 第 2a 阶段进入，并预先填入漏洞登记表； 设计师重新调校，PM 检查奖励耦合，程序员只修改数据， QA 在关卡关闭前重新验证数值区间。

最佳实践

1. 每个周期只采用一种运行模式——在同一轮中混合概念工作和发行运营会削弱二者的效果。
2. 一切都以数字为准：任何形容词都不能让关卡通过（references/quality-gates.md）。
3. 先调研，再创新：设计师趋势调研和 QA 基准调研是阶段 1 的前置条件，不是可有可无的点缀。
4. 保留 _workspace/ 中的产物——它们是工作室跨周期的记忆。归档，永不删除。
5. 规则文件是工作室唯一持久的输出。一次测试运行若交付了构建，却没有留下契约，就没有给下一次会话带来任何经验。
6. 保持里程碑脉络：每项任务都要注明它服务于下一个公开节点的哪一部分。
7. 遵守 QA 广播纪律：每个漏洞或发现都要发送给所有 Agent，并明确请求反馈——QA 的感知是工作室共享的感知。

参考资料

• 质量关卡 G1–G8
• 阶段周期详情
• 产物契约
• 仓库规则文件模板