这是 poorvith-mp/skills-gamedev 技能库中的制作规划（production-planning）技能，页面地址为 https://www.skills.sh/poorvith-mp/skills-gamedev/production-planning。其核心主张是：游戏的“乐趣”无法直接排进甘特图，因此需要用严格的分阶段闸门来管理制作：从粗暴的概念验证推进到打磨的垂直切片，执行激进的范围取舍，并为首个可玩版本定义不可动摇的完成标准。
用途 用于游戏项目在规划里程碑、界定功能范围、决定首个可玩版本交付内容时提供结构化方法，避免瀑布式导致的赶工与无结构敏捷导致的范围蔓延。
主要能力
- 四步制作框架：
- 阶段一 原型/核心循环验证（第1-3月）：目标是在灰盒几何、零最终美术的条件下证明核心交互在机制上“好玩”；若移动与战斗在无贴图方块下不令人满意，4K 画面也无法挽救。
- 垂直切片（第4-7月）：制作10-15分钟最终品质的可玩内容，包含全部系统：最终美术、着色器、战斗、UI、音频、存档/读档、本地化管线，用以验证制作预算与速度。
- 生产/内容精简（第8-16月）：基于已建立的垂直切片管线进行流水线式资产与关卡生产。
- Alpha→Beta→Gold Master（第17-20月）：Alpha 功能完整、不允许新增系统；Beta 内容完整，仅修复缺陷、平衡与优化；Gold 零阻塞/崩溃缺陷，满足主机平台认证合规。
- 垂直切片审计标准：需包含1个完整打磨的关卡/任务；完整动画的玩家角色与至少2种敌人原型；打磨的 HUD、背包、暂停菜单与音频混音；性能分析遥测证明稳定帧预算（目标硬件60 FPS）；在全面生产前清除所有原型临时代码与“意面代码”。
- 范围取舍 MoSCoW 剃刀：Must Have（核心支柱，缺失则核心循环崩塌，如枪械后坐、掩体系统、敌人 AI）；Should Have（高价值，如武器制作、动态天气，可上线后再补）；Could Have（范围裁剪候选，进度吃紧时最先砍掉，如拍照模式、钓鱼小游戏、分支对话树）；Won't Have（上线后/续作，如单人游戏中的多人合作、程序化世界生成）。
- 速度追踪与燃尽指标：给出冲刺资产速度公式（完成的可用于游戏的资产数 ÷ 目标资产配额），并规定在认证与提交日期前始终预留25%缓冲时间，以应对主机平台合规（TRC/TCR）失败。
使用方式 技能提供交付物格式：里程碑路线图与范围取舍台账。示例包含里程碑闸门（灰盒核心循环、首次可玩、垂直切片、Alpha、Beta 等，含截止周与批准状态）以及范围裁剪应急分级表（层级、功能名、预计开发周数、裁减触发日期）。还给出一个实战示例：某动作冒险工作室进入 Alpha 时已落后14周，原计划12种武器与4类开放世界载具；制作负责人用 MoSCoW 剃刀砍掉全部4类载具（节省18周物理工程与动画），将12种武器合并为5种高度打磨的原型，追回12周进度，取消强制周末加班，并首次提交即通过主机认证。
适用场景 游戏开发团队在规划里程碑、界定功能范围、设定完成标准、制定裁剪预案时参考。
限制 资料未提供具体工具集成、平台依赖、安装命令或代码实现；该技能是方法论与文档模板，不提供自动化执行功能。资料中的里程碑月份、缓冲比例等为示例性建议，并非通用强制标准。
验证清单与反模式 清单：每个里程碑有客观、不可协商的完成定义；原型阶段在美术资产生产前验证玩法乐趣；垂直切片基准测试真实生产速度与帧预算；延迟发生前已有预定裁剪清单；为主机认证预留至少25%日程缓冲。反模式：在灰盒不好玩时启动全面生产；无休止原型（每周按创意总监周末所玩游戏添加机制）；零范围裁剪预案，把所有计划功能视为神圣需求直到资金耗尽。