游戏GDD写作指南：从许愿池到可执行设计文档

做游戏这行十多年，我见过最离谱的一种场面：项目复盘会上，每个人都坚称自己"看过设计文档"，可美术画出来的角色和策划脑子里想的完全不是一个人，程序写出来的战斗节奏跟文档上写的差了两倍，测试同学拿着一份三页纸的文档试图验证一百多项功能。回头翻出那份文档，上面写着"打击感要强""玩法要有趣""经济系统要平衡"。这不是设计文档，这是许愿池。

游戏设计文档，也就是圈内常说的 GDD（Game Design Document），本质上不是一份"给老板看的汇报材料"，而是团队成员之间关于"这个游戏到底怎么运转"的一份共识契约。它要解决的核心问题只有一个：当策划、程序、美术、音频、QA 五拨人各自坐在工位上干活的时候，凭什么大家做出来的东西最后能拼成一个完整的游戏，而不是五个平行宇宙。

这篇内容适合三类人看。第一类是刚入行、被要求"写一份 GDD"但完全不知道从哪下笔的新人策划；第二类是独立开发者和小团队，没有专职文档岗，需要自己一边做一边写；第三类是从程序或美术转过来做设计的朋友，技术能力很强，但不知道该怎么把自己的想法翻译成别人能执行的文字。全文我会从"为什么这么写"讲到"具体怎么写"，中间夹大量实操细节和我自己踩过的坑，尽量做到看完就能上手改自己那份文档。

1. GDD 到底是什么：先把概念和使用场景说透

1.1 一句话定义，以及它和另外几份文档的分工

我给 GDD 的定义是：用可验证、可执行的方式，描述游戏在运行时如何响应玩家行为的一份动态说明书。这句话里有两个关键词值得掰开说。

"可执行"意味着文档里的每一条描述，理论上都能被转成代码、模型、音频文件或者测试用例。如果你写"角色跳跃手感要舒服"，程序没法执行；但如果你写"起跳速度 12 单位/秒，重力加速度 -30 单位/秒平方，下落时重力系数乘以 1.6，落地后 0.1 秒内禁用再次起跳"，程序立刻就能做出第一版，然后你们再一起调手感。

"动态"意味着 GDD 不是一次写完就封存的合同，而是随项目推进不断收敛的文档。这点和很多新人想象的不一样——他们以为文档是"先想清楚再开工"，实际上更多时候是"先写清楚假设，再用手感去验证假设"。

这里必须区分几份经常被混为一谈的文档。GDD 管的是游戏本身怎么运转；技术设计文档（TDD）管的是这套运转逻辑用什么架构实现，关注模块划分、数据结构、性能预算；制作排期表管的是谁在什么时候交付什么，关注人力、里程碑、风险。我见过新手把三者揉成一份文档，结果策划不想看架构图，程序不想看玩法故事，两边都痛苦。分文档不是为了形式主义，是因为三份文档的读者和更新频率完全不同：GDD 随设计迭代改，TDD 随技术方案改，排期表每周都在改。

1.2 谁在读你的 GDD：读者视角决定写法

判断一份 GDD 写得好不好，有个很土但很有效的办法：把它丢给三个不同岗位的人，让他们各自说出"我这周要做什么"。如果三个人说出来的东西能拼到一起，这份文档就算及格。

程序读 GDD，找的是边界条件和状态变化。他会盯着"玩家在什么条件下能触发这个技能""这个状态持续多久""两个效果同时触发时谁优先"这类问题。所以涉及逻辑的部分，状态机、优先级、异常分支必须写清楚，不能只写happy path。

美术读 GDD，找的是视觉锚点和参考。他要的不是"一只很酷的怪物"，而是体型比例、材质倾向、配色范围、动作节奏、参考图链接。我通常会在美术需求里放三张图：一张主参考、一张反面参考（明确不要什么风格）、一张细节参考。

音频读 GDD，找的是情绪曲线和触发时机。战斗音乐什么时候切入、Boss 进入第二阶段音效怎么变、UI 点击音的一致性规则，这些都要在文档里提前定调，否则最后就是十几个人各发一批素材，拼在一起风格打架。

QA 读 GDD，找的是可验证的验收条件。所以数值部分尽量写成"预期值 + 容差范围"，比如"跳跃最高点约为 3.2 米，允许 ±0.2 米误差"，而不是"跳得高一点"。这一点在早期就能省下大量扯皮。

1.3 项目规模决定文档粒度

不是所有项目都需要一份上百页的 GDD。文档粒度应该跟着团队规模和项目复杂度走，这里给一个我实际用过的对照表。

关键判断标准是沟通成本。两个人的时候，你扭头喊一声比写文档快得多，这时候写详细文档反而是浪费。一旦超过八个人，信息传递开始出现衰减，这时候文档的边际价值就急剧上升。我踩过的一个坑是在四个人团队里坚持写"正规文档"，结果两周里文档改了六版，程序每次都要重新看，效率反而更低。后来改成"只维护一份数值表和一份核心循环说明"，团队节奏立刻就顺了。

1.4 GDD 的三种生命周期形态

同一个项目在不同阶段，GDD 承担的职责是不一样的。

概念期，它的核心任务是说服和收敛，篇幅短、形容词少、图示多，重点是把"这游戏好玩在哪"用一页纸说清楚。这个阶段的文档允许大量"待定"，但每个待定项都要写明负责人和截止时间。

预生产期，它的核心任务是验证。文档要围绕一个垂直切片展开，把所有关键系统的最小可用版本描述完整，包括数值、交互、资源需求。这个阶段的文档密度最高，也最容易写废——因为很多设计在这个阶段会被证伪。

生产期，它的核心任务是拆解和跟进。这时候文档本身不再是主体，工单系统变成了主体，GDD 退化成"权威参考源"。任何一条工单都应该能回溯到 GDD 的某个小节编号，否则就会出现"这个功能是谁让加的"这种经典悬案。

2. 动笔之前：把骨架搭对，后面少改一半

2.1 一份能用的 GDD 目录长什么样

我用的目录结构大致如下，模块顺序不是随便排的，基本遵循"从玩家看到什么，到系统怎么算，到内容怎么排"的认知顺序。

• 概述：一句话定位、目标平台、目标玩家、核心体验目标、参考作品
• 核心循环：玩家在 30 秒、5 分钟、1 小时、10 小时四个尺度上分别做什么
• 系统清单：每个系统的职责、输入、输出、与其他系统的依赖关系
• 数值设计：属性定义、公式、成长曲线、经济产出与消耗
• 内容规划：关卡/章节数量、节奏曲线、内容解锁顺序
• 交互与界面：操作映射、界面结构、状态流转
• 美术需求：风格定义、资源清单、命名规范
• 音频需求：音乐层次、音效清单、触发规则
• 本地化与可访问性：文本量预估、字号与色盲适配
• 附录：术语表、参考链接、变更记录

这里有个经验：目录里必须有"依赖关系"和"变更记录"这两块。前者防止你设计出一个自相矛盾的系统，后者防止三个月后没人记得某条规则为什么是现在这样。

2.2 信息分层：把"已定"和"待定"物理隔开

新人写文档最常见的结构问题，是把确定的和不确定的混在一段话里。三个月后回看，根本分不清哪句是定论、哪句是当时的猜想。

我的做法是给每条信息打状态标签，用统一的写法：

• [已定]已经通过验证，改动需要走评审
• [暂定]当前采用，预期会调整，附上调整触发条件
• [待定]尚未决策，附负责人和截止时间
• [废弃]曾经的方案，保留是为了记录决策路径

这套标签看着啰嗦，实际用起来非常省事。当程序问"这条到底是最终版吗"，你直接搜标签就能回答，不用凭记忆。

2.3 版本、状态与变更记录

变更记录不是应付流程的装饰。我要求每条记录至少包含四项：日期、改动内容、改动原因、影响范围。其中"改动原因"最重要，因为它是唯一能防止团队重复踩同一个坑的东西。

举个真实例子。我们曾经把技能冷却从固定值改成随等级递减，两周后又改回固定值。如果变更记录里只写"冷却机制调整"，第三周新来的策划很可能又提一次递减方案。但如果记录里写着"递减导致低等级段技能空窗过短，战斗节奏碎片化，实测后回退"，这个决策路径就被封存了。

3. 核心模块逐条拆解：从概念到可执行数值

3.1 核心循环：别写形容词，写动词和资源

核心循环是 GDD 里最容易被写空的部分。典型的失败写法是"玩家探索地图，击败敌人，获得奖励，变得更强"。这句话没错，但没有任何执行价值。

我会用"动词 + 资源 + 反馈"三件套来拆。以上面这句话为例，展开后大概是这样的：

玩家进入一张关卡（动词：进入）→ 消耗时间与生命值资源（资源：时间、HP）→ 通过战斗行为击败敌人（动词：击败）→ 获得经验、掉落物、解锁进度（资源：经验、道具、进度点）→ 属性提升或内容解锁（反馈：数值成长、新区域可达）→ 促使玩家进入更高难度的关卡（回到起点）

这样拆完之后，每个环节都能派生出具体设计问题：一场战斗预期消耗多少 HP？掉落率怎么定？进度点需要多少个才能解锁下一个区域？这些问题一旦有了答案，文档就从"描述"变成了"规格"。

我还会额外做一件事：把核心循环按时间尺度分段写。30 秒尺度是单次操作反馈，5 分钟尺度是一次战斗或一个关卡，1 小时尺度是一个章节，10 小时尺度是整体进度。四个尺度都要有明确的"玩家此刻在追求什么"，这样节奏设计才有依据。

3.2 数值设计：公式、曲线与推导过程

数值部分最忌讳只写结果不写推导。我要求任何一条数值都必须能回答"这个数字是怎么来的"。

先看伤害公式。一个最常见的结构是：

最终伤害 = 基础攻击力 × 技能倍率 × (1 + 增伤加成) × 防御减免系数 × 暴击系数 防御减免系数 = 防御力 / (防御力 + 常数 K)

选择这种"除法减免"而不是"减法减免"，原因是它天然不会出现负伤害和无敌堆防的问题。减法减免在高防御时会直接归零，除法减免则是渐近趋近于 0，曲线更平滑，也更容易做平衡。常数 K 的取值通常等于"设计上希望达到 50% 减伤时对应的防御力数值"，这个数值直接决定了防御属性的收益拐点。

再看成长曲线。经验需求常用的是幂函数：

升级所需经验 = 基础值 × 等级 ^ 指数

指数取 1.5 时，前期升级快、后期逐渐拉长，但不会像指数函数那样炸掉。取 2.0 则后期非常陡，适合强调长期投入的项目。这个指数不是拍脑袋定的，它要和内容量对齐：如果你总共设计了 40 小时的游玩内容，希望玩家在 30 小时左右满级，那就用内容时长反推每一级应该停留多久，再反推经验需求。

我习惯在文档里放一张"期望进度表"，把每个等级段的预期游玩时长、预期战斗场次、预期资源产出全部列出来，然后逐个核对总和是否和内容规划对得上。这一步能提前发现大量"数值和内容不匹配"的问题。

注意：所有公式在文档里必须写清楚变量的定义域和优先级。比如"增伤加成"是否和其他加成加法叠加、是否有上限、多个来源同时生效时的计算顺序，这些不写清楚，程序只能自己猜，最后一定是各处实现不一致。

3.3 关卡节奏：用表格描述体验曲线

关卡设计如果只写文字描述，几乎必然出现理解偏差。我推荐用表格来固定节奏。

强度指数是我自己用的一个 1 到 10 的粗略标尺，用来观察关卡的强度是否单调、是否有张弛。很多新手设计的问题就是强度一路从 3 涨到 8，中间没有波谷，玩家玩下来只会觉得累。

注意"短暂喘息"这一段。它不是可有可无的填充，而是让高峰体验成立的必要条件。没有低谷，高峰就不存在。

3.4 交互与界面：状态机加低保真线框

交互部分我会写两类内容。

第一类是操作映射表。每个平台上的每个输入对应什么行为，长按和短按是否区分，组合输入是否有优先级，全部列清楚。这张表同时也是本地化和手柄适配的依据。

第二类是界面状态流转。用文字描述状态机就行，比如：

• 主界面 → 进入关卡选择 → 选择关卡 → 加载界面 → 战斗界面
• 战斗界面可在"正常""暂停""结算"三个状态间切换
• 暂停状态只能回到战斗或退出到主界面，不能直接进入结算

写完状态流转后，我会画低保真线框，用方块和文字标出每个界面的信息层级和按钮位置，不做视觉设计，只定结构。这一步能提前暴露大量"这个按钮放不下""这个信息玩家看不到"的问题，成本极低。

3.5 美术与音频需求：写成外包能接的清单

美术需求部分，我坚持一个标准：把它写成一份可以直接发给外部供应商的清单。如果外包看完还得回来问三轮，说明清单没写清楚。

清单字段大致包括：资源名称、用途、尺寸与格式、面数或分辨率上限、风格参考、是否需要多状态（默认/悬停/禁用）、交付格式与命名规则。命名规则一定要提前定，比如ui_icon_skill_fire_01.png这种前缀加分类加序号的结构，后期资源上千个的时候，命名混乱会让人崩溃。

音频需求同理，但要多一项"触发规则"。同一个音效在不同情境下是否需要不同版本（比如敌人近处和远处的攻击音），是否允许被截断，是否优先级高于背景音乐，这些都要写明。

4. 从零到可执行：一份 GDD 的三轮迭代实操

4.1 第一轮：一页纸先把核心体验钉死

一页纸文档的目标不是描述完整的游戏，而是回答一个问题：这个游戏的核心体验是什么，凭什么它值得被做出来。

我写一页纸的时候，固定包含五块内容。第一块是定位句，格式是"这是一个面向某类玩家的某类型游戏，核心体验是某某"。第二块是核心循环的四个时间尺度。第三块是三条差异化设计，也就是"和同类作品比，我们的不同点在哪"。第四块是一个关键场景描述，用第一人称写玩家在游戏里最精彩的那三分钟。第五块是风险和未解问题，坦白列出你现在还不知道答案的东西。

这份文档原则上不超过两页，写完之后我会拿给团队里完全不了解项目的人看，让他们复述一遍核心体验。如果复述不出来，就是一页纸没写好，回去改。

4.2 第二轮：垂直切片文档，把所有系统压到最小可用

垂直切片的意思是，不做完整游戏，但把每个关键系统都做出一个能跑通的最小版本，从头到尾串成一条完整的体验线。

这个阶段的文档要做的核心工作是裁剪。比如完整的装备系统包含 200 件装备、6 个稀有度、强化、附魔、套装效果，切片版本只保留 5 件装备、2 个稀有度、无强化。文档里要明确写出"切片版本包含什么、不包含什么、不包含的部分预计何时补充"。

我踩过的坑是切片做太大。曾经有个项目，切片阶段就想把装备系统做全，结果三周过去核心战斗还没验证完，等到发现战斗手感不对的时候，装备系统已经做了一半，推翻成本极高。后来我定了个规矩：切片阶段任何单个系统的内容量不超过完整版本的 10%，超了就砍。

4.3 第三轮：生产期拆分与工单化

进入生产期，文档的角色从"主要工作物"变成"参考源"。这时候要做的是把文档拆成工单。

我的拆分方式是：每个工单必须包含四项——功能描述、验收标准、依赖项、文档锚点。其中"文档锚点"就是 GDD 里的章节编号，比如GDD 3.2.1。这样任何人都能顺着工单回溯到设计原文，避免口头传达造成的偏差。

拆分粒度上有个经验值：单个工单的预期完成时间控制在半天到三天之间。超过三天的工单，往往意味着它其实包含多个独立功能，应该继续拆；低于半天的工单，管理成本会超过收益。

4.4 工具链怎么选：够用就好

工具选择上我没什么执念，几家都用过，关键看团队现状。

我个人的组合是：正文用在线文档、数值用表格、工单用项目管理工具、配置表进版本控制。四者之间靠命名规范和小节编号串起来。工具越少越好，多一个工具就多一份同步成本。见过不少团队为了"管理规范"上了五六个平台，最后没人愿意维护。

5. 常见问题与排查：最容易翻车的八个地方

5.1 内容层面的四个高频问题

问题一：形容词替代规格。文档里出现"流畅""爽快""有深度"这类词，基本等于没写。排查方法是全文搜索这类形容词，每出现一次就追问"具体表现是什么"。替代方案是把形容词翻译成可测量的指标，比如"流畅"可以翻译成"输入到反馈的延迟低于 80 毫秒"。

问题二：只写正常流程，不写异常分支。玩家在加载中掉线、技能释放瞬间角色死亡、背包满时拾取道具，这些情况永远会发生。我的做法是在每个系统后面强制加一节"异常情况"，至少列出五条边界条件。这个习惯让我们的 bug 数量在测试期明显下降。

问题三：数值之间互相矛盾。单看每条公式都对，合在一起就出问题。比如掉落率设计成 5%，但玩家每小时需要 20 个材料，而每小时只能打 30 场战斗，算下来期望产出只有 1.5 个，完全对不上。解决方法就是前面提到的"期望进度表"，把所有数值放在同一张表里做总量核对。

问题四：内容量与工期不匹配。文档里规划了 60 个关卡，但按团队产能算下来需要 20 个月，而项目周期只有 12 个月。这类问题在文档阶段发现成本最低，进入制作就是灾难。我习惯在文档里加一节"内容产能测算"，把每个内容的预估工时列出来求和。

5.2 协作层面的四个高频问题

问题五：文档只在策划内部流转。程序、美术靠口头传达获取信息，导致实现和设计脱节。解决方法是在需求确认环节要求每个岗位的人回复"我理解的是这样，对吗"，形成书面确认。

问题六：没有单一数据源。同一个数值在文档、表格、代码里各有一份，改了一处忘了另外两处。我的做法是明确声明"数值以配置表为唯一标准，文档中的数值仅供参考"，并在文档对应位置标注配置表路径。

问题七：文档更新滞后于实现。做出来的东西和文档不一样，久而久之没人再信文档。这个问题的根源是流程里没有"实现后回写文档"这一步。我把它加进了验收检查项：功能验收通过后，必须有人回写文档并更新状态标签。

问题八：术语不统一。同一个东西在不同文档里叫不同名字，沟通时各说各话。解决方法是在附录里维护一份术语表，规定每个概念的唯一中文名和英文名，所有文档统一使用。这份表看起来不起眼，但在跨部门沟通时价值极高。

5.3 一份问题速查表

最后分享一个我自己用了很多年的小习惯：每份 GDD 的最后一页，我都会留一块"未解问题清单"，把所有当前没有答案的设计问题列在上面，标注负责人和截止日期。项目推进过程中，这块清单会不断缩短又不断新增，它其实是整份文档里最有信息量的部分——因为它记录的是一个项目真实的思考进度，而不只是已经想清楚的东西。等到某天你发现这块清单连续两周没有新条目，而且旧条目全部清空，那大概就是这份文档真正成熟的时候了。