设计与多媒体

Game Design Document CN

中文游戏系统策划案（GDD）编写。按国内研发流程逐节推进：先对齐定位与竞品，再写规则、公式、配置表结构、边界、依赖、数值可调项、验收标准。数值优先落配置表，落笔前过一遍专家视角自检。触发词：写策划案、做系统策划案、GDD、系统拆解、配置表设计。

它能做什么

技能文档

系统策划案（GDD）编写

面向国内研发流程的单系统策划案编写。逐节推进，每节先对齐再落笔，写完即存盘。

三条铁律

文档写规则，数值进表。 凡是策划能改的数字，必须落到配置表字段，不允许散在正文里当裸数值。
没你确认，不落盘。 每段草稿出来必须过你一道，不静默写文件。
不推翻已有结论。 与已定稿文档冲突时，先摆冲突，你拍板，不偷偷改数。

0. 先读什么

开始写之前按顺序读（不存在就跳过，不要报错中断）：

顺序	文件	缺了怎么办
必读	`references/naming-glossary.md`	术语与文风，写任何一段前先读
必读	`references/config-table-spec.md`	写第五段（配置表）前必读
按需	`references/section-playbook.md`	每段的提问清单、完成标准、正反面样例
按需	`references/review-checklists.md`	lean/full 模式做专家视角自检时读

项目文档（有则读）：

策划案/游戏概念.md ← 缺则提示先做概念梳理
策划案/系统索引.md ← 缺则提示先梳理系统清单
策划案/核心支柱.md、策划案/实体登记表.yaml、策划案/一致性问题记录.md

目录容错：若项目里已有 design/gdd/ 且无 策划案/，问一句「沿用现有目录还是迁到 策划案/？」，不要自作主张。

1. 解析参数

/gdd-cn <系统名> [--review full|lean|solo]

模式解析（一次定好，全程沿用）：

命令行传了 --review → 用它
否则读 策划案/.session/review-mode.txt
否则默认 lean

补缺模式：参数以 补缺 开头、或是 策划案/GDD/ 下已存在的 .md 路径 → 进入补缺模式。扫已有章节，只填空缺，不动已有内容；用 Edit 只替换 [待设计] 占位或空段。

系统名必填。没给就看 策划案/系统索引.md，找出优先级最高的「未开始」系统，问你要不要做它。

2. 收集上下文

读完了再开口，别空手问。

必读：游戏概念、系统索引、实体登记表（grep 本系统相关条目，作为「已锁定数值」）、一致性问题记录（grep 本系统分类的历史冲突，作为「踩过的坑」）。

依赖：从系统索引找出上游（我依赖谁）和下游（谁依赖我），有文档就提炼：接口（两边传什么数据）、公式（谁引用我输出）、边界（谁假设我行为）、可调项（哪些旋钮喂进我）。

技术可行性预检：按系统分类映射到技术域（战斗/物理→物理，UI→UI，AI→AI与寻路……），读项目里已有的技术方案文档与 ADR（glob 一下），没有就跳过并提示。

然后才向用户开口，先给简报：

正在设计：[系统名]
- 优先级 / 层级：[来自索引]
- 上游依赖：[列表，标注哪些已有文档]
- 下游依赖：[列表，标注哪些已有文档]
- 必须尊重的既有结论：[关键约束]
- 服务的核心支柱：[哪几条]
- 已锁定的跨系统数值：[实体: 属性=值（归属 XX 系统）]
  ↑ 这些值已锁定。要用别的数，先把冲突摆出来，不要悄悄改。
- 踩过的坑：[本系统分类下的历史冲突模式]

上游还没设计？提示：「[依赖] 还没文档，得先假设它的接口。可以先设计它，或者先定个契约标『待定』。」

然后用 AskUserQuestion 问：「有要补充的约束吗，还是按上面这些开始？」

3. 建骨架

确认后立刻建文件，后续每节都是往里填。模板见 references/section-playbook.md 的骨架模板。

问一句「在 策划案/GDD/[系统名].md 建骨架可以吗？」，拒绝就停，说明没法继续。建完更新 策划案/.session/active.md（Glob 判断存在与否，不存在用 Write，存在用 Edit）。

4. 八段逐节设计

每段走同一个循环：

对齐上下文 → 提问 → 给方案 → 你拍板 → 出草稿 → 你确认 → 落盘 → 记进度

关键：草稿和确认必须在同一条回复里出现。 只出草稿不给确认入口，你就卡在空提示里没路可走，算流程违规。

落盘用 Edit，old_string 必须带上段标题保证唯一：

old_string: "## 三、详细规则\n\n[待设计]"

八段：

#	段落	解决什么问题	何时需要专家视角
一	系统概述	陌生人一段话看懂	—
二	设计目的与体验目标	玩家应该爽在哪	full：战斗手感视角
三	详细规则	程序照着能写，不用回头问	full：战斗+表现视角
四	公式与数值	每个数怎么算出来的	lean 必过数值视角
五	配置表结构与可调项	哪些数能被策划改	full：数值视角
六	边界情况	异常别变成 bug	full：战斗手感视角
七	依赖与接口	谁跟我连、怎么连	—
八	验收标准	QA 照着能测	lean 必过验收视角

可选段：表现需求（美术/音频）、UI 需求、待定问题。

战斗/角色/UI/特效/剧情/关卡类系统，表现需求必写，不给跳过选项。
其余类型，八段写完后问你要不要加。
写了 UI 需求且有实质内容 → 提示后续补 UX 说明，别让开发直接抄 GDD。

每段的提问清单、完成标准、正反面样例 → references/section-playbook.md。

写完第四、五段后做一次数值冲突扫描：段里出现的实体名/道具名/公式名/常量，凡是登记表里有的，逐个比对。不一样就当场摆出来：「登记表里 [X] 在 [某系统] 定的是 [A]，这段写的是 [B]，哪个对？」不静默继续。

5. 专家视角自检

不派子代理，主会话自己按视角过清单（本地没有对应专家代理，派发只会空转；若你已配置对应代理，可改用 Task 派发，角色名见术语表）。清单见 references/review-checklists.md。

模式	过哪些视角
`solo`	全不过，文件里标注「未过专家视角，投产前人工过一遍」
`lean`（默认）	数值视角（四、五段）+ 验收视角（八段）
`full`	数值 / 战斗手感 / 表现 / 验收，四视角全过

输出格式固定：

[视角] 自检：[N] 项发现
- [发现] — 建议：[处理] — 采纳？

用 AskUserQuestion 让你逐条拍板，不自己改。

6. 收尾

回读校验：从文件读回全文（不靠对话记忆，文件才是准的），逐条查：

八段都有实质内容，没有 [待设计]
公式的变量都在变量表里定义了
每条边界都有明确处置结果
依赖都写了方向和接口
验收标准 QA 能独立执行（不看文档也知道怎么测）
正文里没有裸数值（数值都在配置表里）

更新实体登记表：扫全文，提出命名实体/道具/公式/常量，比对已有条目，列「新增」和「已登记（要更新被引用方）」两组，问你要不要写。已有的 value 字段不许改，要改先摆冲突。

更新系统索引：状态按流程走未开始 → 设计中 → 待评审 → 已评审 → 开发中 → 已提测 → 已验收 → 已上线。没跑评审就标「设计中（待评审）」。

提示评审：

评审要在新会话里跑 /design-review 策划案/GDD/[系统名].md。写的人和审的人不能是同一个上下文，否则带着全部设计思路去审，挑不出毛病。

下一步：用 AskUserQuestion 给选项——跑一致性检查 / 做下一个系统 / 修评审问题 / 到此为止。

7. 续写与恢复

中断后恢复：读 策划案/.session/active.md 拿进度 → 读 GDD 文件 → 有实质内容的段算过，[待设计] 的段继续 → 从下一个未完成段接上。

这就是每节落盘的意义：任何一次确认过的内容都活得下来。

协作协议

每个决策点都用 AskUserQuestion，不吞问题
写文件前先问「可以写到 [路径] 吗？」
每节确认后立刻落盘
每段落盘后更新 session 状态
每段都回头查已有文档，冲突当场摆
视角自检的发现，交给你拍板，不自己拍

绝不做的事

一口气生成整份文档然后说「写好了」
没经你确认就往文件里写
静默推翻已定稿的结论
用直译腔术语（见术语表）
在正文里留裸数值

上下文水位

跑到 70% 就在回复末尾加提示：进度已存盘，开新会话跑 /gdd-cn [系统名] 能自动接着写。

下一步建议

新会话跑 /design-review 独立评审
跑 /consistency-check 查跨文档数值冲突
系统都设计完且评审过了，跑 /gate-check