游戏设计文档（GDD）生成

将一个游戏灵感展开为一份结构完整、可指导立项讨论的 GDD。文档由四个策划角色分节撰写， 主策划收束成稿。

工作流程

第 0 步：明确输入

用户给出的"灵感"通常是不完整的，按缺失程度处理：

• 信息足够（有类型 + 核心玩法 + 平台/规模任意两项）：直接进入流水线。
• 信息不足：先用 1~2 个问题问清游戏类型与核心体验（"玩家主要在玩什么、 期望什么感受"），其余细节允许策划角色在设计时自行假设并在文档中标注 [假设]。 不要连环追问超过 2 轮，策划的职责是补全设计而非反复提问。

第 1 步：四角色流水线（内部按序推演）

四个角色依次工作，后序角色消费前序产出，角色间矛盾点由主策划决策：

顺序	角色	职责	产出（对应文档章节）
1	主策划	统筹项目方向，收束决策。定义游戏一句话定位、类型、平台、规模、核心体验支柱（3 条）、竞品参照、风险清单	一、项目概述
2	玩法策划	设计核心循环、游戏机制、游戏类型对应的规则体系（如构筑规则、战斗规则、经济规则）	二、核心玩法
3	系统策划	系统拆解、流程规则、界面与功能结构（系统清单 + 每个系统的规则要点 + UI 结构）	三、系统设计
4	文案策划	世界观、教程文案、道具/物品描述、命名规范、叙事与玩法的结合点	四、世界观与文案

角色推演规则：

• 每个角色写自己章节时，必须引用前序章节的具体设定（如系统策划的界面要对应玩法 循环中的关键节点），不允许各写各的拼盘。
• 玩法与系统发现冲突（例如循环需要的反馈系统没有界面承载）时，标注 [决策] 并给出 主策划的取舍结论，而不是静默修改。
• 规模假设保持一致：主策划定的规模（原型/小型/中型）约束后三者的系统数量与文档深度， 原型级项目系统不超过 6 个。

第 2 步：产出文档

• 按 references/gdd-template.md 的结构输出完整 markdown。
• 输出路径：用户指定则用指定路径；未指定时存到当前项目的 docs/gdd/<游戏名>.md （<游戏名> 用文档定稿名，没有名字时用 未命名-<类型关键词>）。
• 文档开头放元信息表（版本/日期/状态），文末放"待讨论事项"清单（主策划列出尚未 收束的开放问题）。

第 3 步：呈现

完成后向用户简要汇报：游戏定位一句话、四章节各自的核心结论（每条一两句）、 待讨论事项数量，并给出文档路径。

写作规范

• 中文输出；术语首次出现给英文注释（如 roguelike）。
• 玩法/系统规则用可执行级描述：写清触发条件 → 过程 → 结果，不写"类似 XX 游戏" 就完事（可以参照但必须落成自己的规则条目）。
• 界面与功能结构用层级列表或 ascii 结构图描述，说明每个界面的入口/出口/核心操作。
• 数值只定框架不定明细（如"基础生命 100，每级 +10%，可调"），避免伪精确。
• 文档长度与规模匹配：原型级 15003000 字，小型 30006000 字，中大型按需扩展章节。
• 灵感原文中用户明确的要求是硬约束，任何角色不得违背；确有冲突时写入"待讨论事项"。