游戏策划案生成器 (ym-game-design-doc)

产出来自模板，不堆砌功能。一个合格 GDD 的标志是：核心循环能一句话说清、MVP 系统能在给定产能内做完、每个风险都有可执行砍法。本技能按 templates/gdd-skeleton.md 逐节产出，按 references/scope-control.md 的产能基准把里程碑折算成周。

何时使用

• 用户说「写个游戏策划案」「出 GDD」「玩法设计」「游戏企划」时
• 用户给了一个游戏概念（如「肉鸽卡牌」「种田+探索」）想落到纸面时
• 用户已有想法但系统越想越多、理不清优先级时
• 用户想估算一个独立游戏要多久能做出可玩版本时

运行前提

• 依赖：无第三方依赖，纯文本产出，无需联网
• 模型按 templates/gdd-skeleton.md 的章节结构产出，不自由发挥章节顺序
• 产能折算引用 references/scope-control.md 的基准表，不按理想效率估算
• 不调用任何脚本，不读写技能目录以外的文件

输入契约

缺失处理：

• 缺平台 → 默认 PC，并在文档开头注明「平台未指定，按 PC 设计」
• 缺团队规模 → 默认 solo，按每周 15 小时有效开发折算
• 概念为空 → 直接说明无法生成，列出需要提供的信息，不编造概念

执行步骤

1. 写电梯陈述 — 用一句话说清「玩家是谁、在做什么、爽点在哪」，套用模板的电梯陈述格式。这一步是后面所有章节的锚，写不清就回去重想概念，不要带着模糊概念往下写。

2. 定义核心循环 — 必须能一句话说清「玩家每 1~3 分钟在做什么」，并画成文字环（如 探索→拾取→合成→战斗→死亡→探索）。核心循环里出现的动作，才是 MVP 必须实现的；环外的都是后期候选。

3. 列系统清单 — 对照 templates/gdd-skeleton.md 的系统表，逐个系统标注【MVP】或【后期】。判定依据：该系统是否在核心循环闭环里。MVP 合计必须能在「solo 3 个月 / 小团队 6 个月」内做完，否则要把后期系统从 MVP 移走，直到产能兜得住。

4. 定数值框架 — 只定框架不定死值：列成长维度、货币种类、产出/消耗节点。具体数值留给试玩调参，本技能不替用户定最终数值，文档里明确标注「数值待调」。

5. 定美术风格 — 给 2~3 个参考作品 + 资产量估算（角色/地图/特效数量级）。用 references/scope-control.md 的资产基准表把估算落到工时，不按风格笼统说「简单」。

6. 排开发里程碑 — 按团队规模查 references/scope-control.md 产能基准，把 MVP 系统折算成周。solo 每周有效开发约 15 小时；小团队按人数×15 小时再扣协作损耗（2-3 人扣 20%，5 人以上扣 35%）。输出甘特式周表，标注每个里程碑的可玩判定。

7. 列风险清单 — 每条风险配一个「砍法」，砍法的合格标准是：砍掉该风险对应功能后核心循环仍成立。砍法不成立的风险，要升级为「必须解决」并写应对，不能留空。

8. 自检 — 输出前逐条核对：核心循环一句话是否成立？MVP 是否超产能？每个风险是否都有合格砍法？缺任一项则补，不交付半成品。

输出格式

Markdown，套用 templates/gdd-skeleton.md 的章节顺序：电梯陈述→核心循环（文字环）→系统清单（MVP/后期 标注）→数值框架→美术风格→开发里程碑（周表）→风险清单（带砍法）。末附「产能核算」一段，给出 MVP 总工时与折算人月，供用户复核排期是否现实。

## 电梯陈述
【玩家】硬核卡牌玩家；【动作】组牌打肉鸽；【爽点】每局都能凑出一套新流派

## 核心循环
组牌 → 进入地牢 → 战斗掉落 → 强化卡组 → 死亡结算 → 组牌

## 系统清单
| 系统 | 标注 | 理由 |
| 卡组构筑 | MVP | 核心循环必需 |
| 局内战斗 | MVP | 核心循环必需 |
| 联机对战 | 后期 | 环外，首作不做 |

## 数值框架
成长维度：等级、卡牌稀有度；货币：金币（局内）、钻石（跨局）
产出节点：战斗掉落、事件奖励；消耗节点：卡牌升级、复活

## 美术风格
参考：杀戮尖塔、月圆之夜、盗贼之海；资产量：30 张卡面 + 8 个敌人立绘

## 开发里程碑
| 周 | 交付 | 可玩判定 |
| 1-4 | 核心战斗+组牌 | 能打一局 |
| 5-10 | 地牢生成+掉落 | 有重玩价值 |

## 风险清单
| 风险 | 砍法 | 砍后核心循环 |
| 内容量不足 | 砍到 3 章地牢 | 仍成立 |

## 产能核算
MVP 总工时约 280h，solo 折算约 18.7 周（不超 6 个月）✓

能力边界

• 不写代码、不实现任何系统
• 不做美术、不产出任何素材文件
• 不预测市场销量、不做发行与商业评估
• 不替代引擎选型；引擎建议只作为备注，不写进交付承诺
• 不保证按文档做出来的游戏一定好玩或卖座

常见坑

1. 系统堆砌没有核心循环 — 现象：文档列了 30 个系统却没有一句话能说清玩家每分钟在干嘛。原因：从「我想要的功能」出发而非从「玩家每刻在做的动作」出发。规避：先写核心循环文字环，环外系统一律先标【后期】，MVP 只留闭环必需。

2. 里程碑按每天 8 小时理想效率估 — 现象：小团队 2 个月排了 6 个系统，实际做了一年没完。原因：用全职理想工时而非有效开发工时。规避：solo 直接按 15 小时/周、小团队按人数×15 小时扣协作损耗折算，详见 references/scope-control.md。

3. 第一个项目就做多人联网 — 现象：solo 第一作上联机，网络同步吃掉全部工期，单机内容为零。原因：把「看起来高级」当优先级。规避：联机默认标【后期】，除非核心循环本身依赖他人同场（如合作解谜）才进 MVP，且需单独写砍法。

4. 把「创意」当差异化 — 现象：文档反复强调「市面上没见过这个组合」，但对执行质量无要求。原因：用创意掩饰对美术、手感、留存的无计划。规避：差异化写「为什么这个组合能成立」而不是「它很新」；执行质量（手感、反馈、节奏）单列一节并给可检判定。

5. 数值框架一次定死值后面全推翻 — 现象：早期把攻击/血量精确到个位数，试玩一次全重做。原因：把框架当配置。规避：数值框架只定维度和节点（产出在哪、消耗在哪、成长沿哪条线），具体数值在试玩迭代里定，文档明确标注「数值待调」。

6. 美术估算按成品级不计资产量 — 现象：写「像素风很简单」，实际 50 个角色立绘做崩。原因：低估资产数量级。规避：按 references/scope-control.md 的资产基准，先数清角色/地图/特效的数量级再估工时，不按风格笼统说「简单」。

验收用例

• 正常：输入「solo、PC、肉鸽卡牌」→ 产出 GDD，MVP 系统按产能折算不超过 6 个月；核心循环一句话能说清（如「每 2 分钟组一套牌、打一波、选一张强化」）；每个风险都有砍法，且砍后核心循环仍成立
• 边界 1：输入「5人以上、手机、开放世界」→ MVP 仍只含核心循环必需，开放世界按产能约束大幅削减，标注哪些进【后期】
• 边界 2：输入只有概念缺平台/团队 → 按默认（PC/solo）折算并在开头注明
• 失败：概念为空 → 拒绝生成，列出所需信息

目录说明

• templates/gdd-skeleton.md — 策划案模板，每节附填写说明与原创示例段
• references/scope-control.md — 砍功能优先级方法 + 产能基准表
• scripts/ — 预留（本技能为纯文本产出，无需脚本）