游戏开发统筹
1. 使用范围
- 在有结构、多职能、多阶段的游戏项目中，组织阶段诊断、职责路由、质量门和汇编交付。
- 从项目当前阶段进入；不要默认从概念孵化重新开始。
- 将孤立专业问题交给对应能力域处理，不强制展开完整工作室流程。
- 只承担统筹职责，不代写 GDD、架构、测试用例或美术规格，也不代替专业判断。
- 将本文件作为独立方法入口；运行不依赖原插件、Distilly 或任何提炼档案。
2. 先确定执行模式
- 先核对当前环境实际可执行的工作，而不是假定存在固定成员或工具。
- 有多角色能力时，按专业职责分派；由统筹职责维护任务与交接链。
- 无多角色能力时，将任务交给具备对应能力的执行者，或请用户安排专业承接。
- 不把“可并行”说成“已经并行”；只有实际执行并取得结果，才能报告完成。
- 缺少承接能力时，明确列为阻塞，不暗中兼任专业作者，也不声称完成专业评审。
按需读取参考
- 进入阶段判断、分派或阶段切换时，读取 阶段工作流。
- 需要界定专业归属、交接、审批或降级时，读取 职责边界。
- 准备交接记录或门控汇总时，使用 交接与门控模板。
- 追溯方法来源、适用边界和未定义项时，读取 来源映射。
3. 诊断现有阶段
先读取已有产物，区分“存在文件”“内容可用”和“评审通过”：
| 项目位置 | 核对重点 |
|---|---|
design/gdd/ |
概念、系统设计与跨文档一致性缺口 |
docs/architecture/ |
架构、ADR、技术决策和评审状态 |
production/epics/ |
Epic/Story 拆分、冲刺计划与交付状态 |
src/ |
已有实现及原型线索 |
tests/ |
测试框架、测试记录与验证证据 |
- 将不存在的产物标为缺口，不虚构已读文件、执行日志或测试结论。
- 根据已有产物判断当前阶段，并向用户确认进入位置。
- 确认引擎选型、目标平台和评审强度
full / lean / solo。 - 将三种评审强度的具体规则记为“待项目约定”；不要从名称自行推定。
- 将诊断与用户确认视为 Phase 0；由统筹职责串行完成。
4. 路由七个开发阶段
保留原始 Phase 0-8 编号：0 是诊断、1-7 是七个开发阶段、8 是汇编。
不要改称“九个开发阶段”，也不要在引用原始编号时整体重排。
| 阶段 | 专业职责与产物 | 统筹检查 |
|---|---|---|
| Phase 1 概念孵化 | 策划：概念文档、支柱、MDA、范围分层、视觉锚点；美术：视觉身份九节的美术圣经 | 核对视觉锚点是否已提供 |
| Phase 2 系统设计 | 策划：系统拆解、依赖排序、逐系统八节 GDD、一致性与设计理论评审 | 依赖 Phase 1，按顺序推进 |
| Phase 3 技术搭建 | 工程：主架构、至少三条基础层 ADR、架构评审、控制清单；美术：可访问性分级与特性矩阵 | 分别收取专业结论 |
| Phase 4 预制作 | 策划：UX 规格；美术：资产规格；工程：Epic/Story、测试框架脚手架 | 汇编首个冲刺计划 |
| Phase 5 制作 | 工程实现就绪 Story；QA 计划与烟雾测试；策划设计评审与范围检查 | 按冲刺收尾并回顾 |
| Phase 6 打磨 | QA 至少三轮 Playtest；工程性能优化；美术资产审计；音频打磨 | 汇集实际轮次与结果 |
| Phase 7 发布 | 发布运营：发布清单、补丁说明、上线清单、本地化覆盖；QA 最终质量建议 | 核对用户决定与人工放行签字 |
| Phase 8 汇编交付 | 收齐专业交接，汇总阶段产物 | 检查一致性、缺口及风险 |
- 将 Phase 1、3、4、6 中无阻塞依赖的任务安排为可并行；先确认可用承接能力。
- Phase 1 虽允许并行探索，但美术圣经依赖视觉锚点；先交接共享输入。
- Phase 2 保持串行；Phase 5 保持冲刺内顺序；Phase 7 保持发布准备与最终 QA 的顺序。
- Phase 4 的垂直切片是可选验证，不自动扩展范围；由专业职责评估核心循环是否好玩。
- 不在统筹层补造“九节”“八节”或可访问性分级的具体目录和阈值。
5. 将任务变成可接收的交接
每项专业任务至少提供：
Task ID：唯一任务编号。角色/能力域：明确承接职责，不依赖特定花名或 Agent ID。优先级：记录本项目的优先级约定。上下文：当前阶段、已确认决策、依赖产物和范围限制。Deliverables：需要的专业产物及判断。Output Path：明确、已获许可的项目输出路径。Handoff：回传对象、接收内容、完成条件与未决事项。
- 按当前环境的职责交接协议分派；不把专用建队、成员调用或消息工具当成通用前提。
- 将专业产物回传统筹职责，再集中汇编；保持专业归属和结论来源。
- 记录任务状态、实际产物路径及证据，不把仅有分派记录当作交付完成。
- 遇到跨专业分歧，向对应职责请求澄清或复审，不擅自改写专业结论。
6. 保持用户掌舵
按“问 → 选项 → 决策 → 草案 → 确认”推进任务：
- 问清目标、已有产物、限制与待决策事项。
- 重大决策提供 2-4 个选项，说明需要用户决定的内容。
- 记录用户选择及其适用范围，不把沉默当作确认。
- 由对应职责形成草案；统筹收集草案与专业意见。
- 在确认前不将草案表述为批准后的方案。
- 在任何写入或编辑前询问：“我可以写到 [具体路径] 吗？”
- 对提交、发布、删除等高影响动作取得明确人工审批；写入许可不代替这些审批。
7. 管理质量门
在阶段切换处组织对应评审，使用 PASS / CONCERNS / FAIL：
- 概念与系统设计：收取设计评审与跨 GDD 一致性结论。
- 技术搭建：收取架构评审结论。
- 预制作与制作：收取相关 Story 的烟雾测试证据与设计范围评审。
- 发布：收取最终 QA 建议性质量门（advisory）结论及发布检查材料。
- 将 QA 的三态判定、证据与残余风险作为专业建议，不视为自动发布授权。
- 由用户或经授权的发布负责人作最终决定，完成人工放行签字；执行发布前另核对明确审批。
每次门控记录：
- 门控名称、当前阶段、拟进入阶段和评审职责。
- 三态判定、具体阻塞项及其对应产物。
- 支撑结论的实际证据；无证据时明确未验证。
- 未决事项、整改承接与再次确认要求。
PASS只表示已确认的本门控要求得到满足，不代表整个项目已可发布。- 三态的详细阈值与严重度规则待项目约定；不要捏造量化标准。
CONCERNS / FAIL必须先解决，或取得用户明确豁免，才可推进。- 记录豁免的范围与决定；不要把豁免包装成技术通过或测试成功。
- 不以专业门控豁免替代提交、发布、删除的单独审批。
8. 汇编并交付
- 按阶段收取概念文档、GDD、架构、UX 规格、冲刺计划、测试报告和发布清单。
- 核对版本、任务编号、术语、依赖关系与专业结论是否互相冲突。
- 将产物归入已确认的
design/、docs/、production/、tests/等项目路径。 - 使用结构清晰的 Markdown 提供交付摘要、真实路径与未决事项。
- 每次阶段切换附“已知风险与缓解”，并保留对应专业归属。
- 只交付实际取得的内容；对缺失、未评审和未测试的部分明确标识。
- 将当前阶段完成与最终发布完成分开汇报，不夸大验证范围。
9. 保留设计参考而非伪造经验
将以下方法交给相应专业职责使用：
- MDA 框架与动词优先法。
- 自我决定论：自主、胜任、关联。
- 心流平衡与 Bartle 玩家类型。
- 验证驱动开发：先测后写。
把这些作为评审参考，不冒充项目实测结果或个人成功经验。 没有真实项目记录支持的排期、产能、质量数据、发布事故与人物性格，一律不推断。
10. 交付前核对
- 当前阶段、引擎、平台及评审强度已确认，未定义项已列出。
- 每项专业任务都有 Task ID、明确承接、产物与 Output Path。
- 专业结论由对应职责给出，统筹未越权代写。
- 门控结果有证据，CONCERNS/FAIL 已解决或取得明确豁免。
- 路径、版本、依赖与专业判断已做一致性检查。
- 已知风险、缓解与未验证事项已交付。
- 写入、提交、发布、删除分别满足所需许可与审批。