企业官网建设流程全解析

第一次带团队把脑子里的想法落成能跑起来的版本时，我才真正明白游戏设计文档（GDD，Game Design Document）不是写给老板看的汇报材料，而是写给"明天就要动手做东西的那群人"看的施工图。你说"做一个打击感很强的动作游戏"，程序听到的是"要做什么动画、判定框多大、什么时候播特效"，美术听到的是"角色有几个攻击动作、每个动作几帧"，音频听到的是"要不要分图层、命中音效怎么叠"。这句口头描述在这三类人脑子里会长出三棵完全不同的树，最后拼在一起就是一场灾难。

这份文档要解决的核心问题只有一个：把一个人脑子里的模糊画面，翻译成一群人能同时理解、能并行开工、能验证对错的结构化信息。它适合刚入行的策划、独立开发者、小团队主策，也适合那些"自己既写策划又写代码"的全栈型选手。下面我把这几年写 GDD 的完整思路、结构、颗粒度取舍和踩过的坑，尽量拆细了讲一遍，你可以直接拿去当模板改。

1. GDD 到底是个什么东西：先把它的边界划清楚

很多新人一上来就问"GDD 有没有标准模板"。这个问题本身就有点偏。模板是死的，文档要服务的对象是活的。你团队三个人和三万人，需要的 GDD 完全是两种东西。所以我更愿意先花点篇幅把它的边界讲清楚，边界清楚了，模板自然就长出来了。

1.1 一段口头创意到可执行方案，中间丢了多少信息

随便举个最常见的例子。你跟团队说："我们做一个横版动作游戏，主角有三段连招，打起来很爽。"

这句话在传播过程中会衰减掉 90% 以上的信息。程序会追问：三段连招是固定顺序还是可以切入？第一段打完多久能接第二段？如果玩家在第三段中途被打了怎么办？美术会追问：三个动作共用一套骨骼还是三套？每段的时长是多少帧？音频会追问：命中音效分几种材质？挥空有没有音效？

GDD 的价值就体现在这里——它把这些"追问"提前问完，并且把答案固化下来。一段创意在脑子里是连续的、模糊的、随时可变的；一旦写成文档，它就必须变成离散的、明确的、可以被他人检验的。这个从连续到离散的过程，就是策划真正的工作量所在。

我自己的判断标准很简单：如果一份文档交给一个从没参与过讨论的程序，他能在一周内做出一个能跑通核心玩法的可玩版本，那这份 GDD 就及格了。如果他做出来的东西和你想的差了一大截，问题一定出在文档里，而不是出在他理解能力差。

1.2 它和策划案、需求文档、技术方案不是一回事

这四个词经常被混用，其实各有分工。我梳理了一张表，你可以对照着看：

看这张表会发现，GDD 是唯一一份"面向全体成员"的文档。它不需要像 PRD 那样精确到每个字段的校验规则，但它必须让美术知道氛围基调、让音频知道节奏密度、让程序知道核心数据流。它的定位介于"愿景"和"规格"之间，是一个偏中间的、需要多方对齐的载体。

注意：很多团队失败的原因是让 GDD 承担了 PRD 的职责，把每个功能的边界条件都写进去，结果文档膨胀到几百页，没人看得完，最后索性不看了。GDD 应该保持"够用即止"，细化的部分拆到单独的模块文档里。

1.3 谁读这份文档，决定了它该长什么样

写之前先列读者清单，这是我养成的一个习惯。以我最近做的项目为例，读者至少包括：主程、客户端程序、服务端程序、动作美术、场景美术、UI 美术、音频设计师、关卡策划、数值策划、QA、运营、本地化。这十几类人关心的东西完全不同。

程序最关心的是数据结构和状态流转。你把"角色可以在受击时被击退"写成一句描述，程序就得自己猜击退距离怎么算、和其他位移会不会冲突。但如果你写成"受击时播放 hit 状态，该状态持续受击硬直帧数，期间每帧沿受击方向位移击退初速度 × (1 - 当前帧 / 总帧数)"，他就能直接落地。

美术最关心的是参考和约束。光写"科幻废土风"没用，得给出色板范围、材质倾向、参考图链接，最好再标注一下角色在屏幕上的实际占比是多少像素，因为这会直接决定他画多细。

QA 最关心的是可验证的判定条件。所有"提升了""优化了""更好了"这类模糊表述对 QA 来说都是废的，必须换成"攻击间隔从 0.8 秒缩短到 0.65 秒"这种可以被测试复现的句式。

同一份 GDD，面对这么多读者，写法上就得做分层：核心章节人人必读，细节章节按职能拆分。这也是后面我要讲"文档不是一个文件"的原因。

1.4 GDD 从来不是一个文件，而是一组文档

新人最容易踩的坑，就是试图把所有东西塞进一个 Word 文档里。写到第三章数值的时候，你发现几十个技能的数据用文字描述简直是在自虐；写到关卡的时候，你又想画个俯视图，Word 里插图排版能把人逼疯。

我现在的做法是：主文档（Wiki 形式）负责叙述性的、需要连续阅读的部分，比如核心体验、设计理念、系统概览；数值用在线表格，一行一个技能或一个敌人，列是各种属性；流程图、状态机、UI 层级这些用白板工具画；参考图、音效样本用共享文件夹。主文档里只放大纲和链接。

这样做的好处是，每个文档都能用最适合它的工具承载。数值策划改平衡性时只动表格，不会污染主文档；程序看数据流时直接进流程图；美术看参考时进素材库。变更也更容易追踪，谁在哪一块动了什么，一目了然。

2. 动手之前先定骨架：GDD 的整体结构怎么搭

结构这件事，我的经验是"先定骨架，再填血肉"。很多人一上来就开始写玩法细节，写了三页发现漏了叙事，又回头补，补完发现和玩法对不上，来回折腾。骨架定好了，你至少知道每一块该放什么，不会跑偏。

2.1 一份能落地的 GDD，通常包含这些模块

我把这些年的结构沉淀成一个相对通用的清单，你可以按项目类型增删：

• 游戏概述：一句话定位、类型、目标平台、目标时长、目标用户
• 核心体验支柱：三到五条不可动摇的设计原则
• 核心循环：玩家在 30 秒 / 5 分钟 / 1 小时 / 长期分别做什么
• 系统与机制：战斗、成长、经济、社交、任务等各系统的规则
• 数值框架：属性定义、伤害公式、成长曲线、经济平衡
• 关卡与内容规划：关卡结构、难度曲线、内容清单
• 表现层指引：美术风格、音频设计、叙事与文本
• UI/UX：界面层级、交互流程、关键页面说明
• 技术约束：性能预算、平台限制、依赖项
• 里程碑与范围：版本划分、优先级、砍功能预案
• 附录：术语表、参考、变更记录

这份清单看起来长，但不是每个模块都要写得一样厚。独立小项目里，"社交"这一章可以只有一句"本作无社交系统"；而"核心循环"可能要写两三千字。厚度分配本身就是设计判断力的一部分。

2.2 先写一页纸：One-Pager 先行

不管项目多大，我都坚持先写一份一页纸的概述，业内叫 One-Pager。它包含：一句话定位、三到五条核心体验、核心循环的极简描述、目标平台和时长、参考作品两三个。

为什么这么执着？因为一页纸的修改成本极低。立项阶段你的想法每天都在变，如果直接写三十页详细文档，改一次要半天，你反而不敢改了，于是被一份过时的文档绑架。而一页纸改起来十分钟，可以一天改八遍，改到各方都点头，再往下展开。

更重要的是，一页纸是绝佳的"对齐工具"。制作人、主程、主美坐在一起看这一页，五分钟后就能吵起来——"你说 8 分钟一局，但核心循环里有个养成系统，8 分钟根本推不动"，这种争吵在立项期发生是好事，在开发三个月后发生就是灾难。

我通常会在一页纸里放这么一段"非目标"：明确写出"我们不做开放世界""我们不做多人对战""我们不做长线剧情"。明确不做什么，往往比明确做什么更能收窄范围。这是我吃过亏之后学到的——不写非目标，团队就会默认"什么都可能做"，需求会像滚雪球一样膨胀。

提示：一页纸定稿后务必写明版本号和日期，并且把它作为后续所有讨论的基准。后续任何偏离一页纸的设计，都要在评审里说明原因，否则就会慢慢跑偏。

2.3 颗粒度取舍：写太细和写太粗都是坑

这是写 GDD 最核心的手艺，没有之一。写太粗，程序自由发挥，做出来的东西失控；写太细，你替程序把代码都设计完了，既浪费时间又容易出错，还压制了执行者的专业判断。

我总结了一条边界线：写清"结果"和"约束"，把"实现"留给执行者。

举个例子。"角色跳跃高度是 3 格"是结果，必须写；"跳跃时用物理引擎的初速度参数"是实现，不必写。"每回合玩家最多行动 3 次"是约束，必须写；"用状态机还是计数器来实现"是实现，不必写。"伤害不能因为数值溢出变成负数"是约束，必须写；"用无符号整数还是浮点"是实现，不必写。

那什么时候必须写到实现层？有两种情况。一是这个实现方式本身就是设计的一部分，比如"卡片拖拽必须是即时响应，不能有网络延迟感"，这直接决定了要不要做本地预测，属于设计约束。二是团队里有新人或者外包，需要降维到更具体才能执行。除此之外，一律不写。

还有一个判断技巧：如果一个细节改了会让玩家感知到变化，那它是设计，要写；如果一个细节改了玩家完全无感，那它是实现，不写。玩家能感知"攻速从 1.0 变到 1.2"，但感知不到"用数组还是链表存技能"。

3. 核心章节逐个拆解：怎么写才有人看、看了能用

骨架搭好之后，真正花时间的是内容章节。我把几个最关键的章节拆开讲，每个都给出具体的写法和例子，你能直接套用。

3.1 概述与核心体验支柱：先立规矩，再谈细节

核心体验支柱（Pillars）是整份文档的灵魂，一般三到五条，每条一到两句话。它的作用是在后续无数个设计决策里当仲裁者。

拿一款横版动作 Roguelite 举例，我可能写这么四根支柱：

1. 每一刀都要有重量：命中有停顿、有震动、有音效反馈，玩家能"摸到"打击。
2. 失败是学习而非惩罚：单局失败只损失当局进度，永久成长保留，玩家永远在积累。
3. 选择在 30 秒内完成：所有三选一、路线选择，都要在 30 秒内做完，不打断节奏。
4. 一局刚好一顿饭的时长：目标单局 8 到 12 分钟。

有了这四条，后面所有争论都有了裁判。美术说"我想把命中特效做得特别华丽"，策划就能用第一根支柱回应："华丽可以，但必须能突出重量感，不能糊住画面让玩家看不清判定。"程序说"单局时长能不能到 20 分钟，内容更好排"，第二根和第四根支柱直接否掉。

我见过太多项目因为没写支柱，导致每个决策都要重新吵一遍，或者由嗓门大的人拍板。支柱写得好不好，直接决定了后续沟通成本。

写法上，每根支柱我建议配一句"反面例子"。比如"每一刀都要有重量"后面加一句"反面：命中只有音效、没有视觉和震动反馈，打击感会像砍空气"。有了反面例子，执行者才知道边界在哪。这招比只写正面描述有效得多，因为人更容易理解"不要做什么"。

3.2 核心循环：把时间轴切成四层来写

核心循环（Core Loop）是 GDD 里被误解最多的章节。很多人只写一层，比如"打怪—掉装备—变强—打更强的怪"，这太浅了，落地的时候完全不够用。

我的做法是把循环按时间尺度切成四层，每层都写清楚"玩家做什么"和"获得什么反馈"：

这么写的好处是，你能立刻发现循环里的断点。比如"30 秒层"设计得很爽，但"5 分钟层"没有任何反馈，玩家打了五分钟后会觉得"我图啥"。很多小体量游戏就死在这里——爽点密度不够，中间层是空的。

我还会在核心循环下面补一段"循环断裂分析"，写明如果某一层缺失会发生什么。比如"如果 1 小时层没有永久成长，玩家会认为失败没有意义，重复游玩意愿下降"。这种反向分析看着有点啰嗦，但它是团队里最有价值的一段内容，因为它把设计意图显性化了，程序在做系统时会主动帮你留出成长接口。

3.3 系统与机制：数值、公式、状态机三件套

这是 GDD 里最硬核也最容易写崩的部分。我的经验是，把它拆成三样东西来处理，每样用不同的表现方式。

**第一样是数值表。**能用表格的绝不用文字。假设我现在定义技能，一张表就够了：

这张表的价值在于，程序可以直接把它转成配置表，美术可以按帧数排动作，音频可以按帧数对音效点，QA 可以按备注写测试用例。一份表服务四个职能，这就是结构化的力量。

**第二样是公式。**所有涉及计算的系统都要写公式，而且要写清楚每个参数的含义和取值范围。以伤害为例：

最终伤害 = 基础攻击 × 技能倍率 × (1 + 增伤率) × 暴击系数 × 防御减免 防御减免 = 防御力 / (防御力 + K) K = 100 + 10 × 关卡等级 暴击系数 = 暴击时取 1.5，非暴击取 1.0

写完公式还不够，我会补一段"参数取值范围"：基础攻击 10 到 200，增伤率 0 到 1.5，防御力 0 到 500。这样数值策划调平衡时，一眼就知道哪个参数还能加、加到多少会失衡。没有取值范围，数值策划会调到填出天文数字。

**第三样是状态机。**用来描述角色或系统会经历哪些状态、状态之间怎么切换。还是角色的例子：

状态机用表格写就很好，不用非得画图。关键是穷举状态，并且穷举切换条件。我经常发现新人漏写"受击打断攻击"这种切换，结果程序做完发现角色被打了还能继续挥刀，又得返工。

提示：状态机表格里所有的"帧"都要注明是按 60 FPS 还是 30 FPS 计的。我踩过这个坑——动作美术按 30 FPS 做了个 12 帧的后摇，程序按 60 FPS 实现，实际手感快了一倍，整个战斗节奏全乱。

3.4 关卡与内容规划：把难度画成一条曲线

关卡章节如果只写"第一章是森林，第二章是城堡"，那就是在写作文。真正有用的关卡规划应该包含难度曲线、内容密度和关卡结构三个维度。

难度曲线我习惯用一张表来表示，每五到十分钟一个检查点：

"预期通关率"这一列是我强烈建议加的。它逼着你想清楚每个关卡段到底想要多少玩家通过。如果 1-4 的预期通关率你填了 80%，实际测下来只有 30%，那一定是难度断层了，得查是不是新机制引入太陡。没有这个列，你只能靠感觉说"这关有点难"。

内容密度指的是玩家在这段时间里接触到多少新东西。我的经验是，前十五分钟至少每分钟一个新鲜刺激，之后可以放缓到每三分钟一个。太密会让人疲劳，太疏会让人腻。

关卡结构是指在空间上怎么组织。是线性一条线，还是有分支路线，还是有枢纽房间？这直接决定了美术的资产量和程序的地图系统。我会在关卡章节里画一张极简的节点图（用表格或列表描述连接关系即可），标明每个区域的功能和规模。

3.5 表现层指引：美术、音频、叙事的"不越界"写法

表现层最容易写成散文，什么"营造出孤寂而宏大的氛围"，执行者看完一头雾水。我给表现层定的规矩是：每一项都要落到可执行的参数或清单上。

美术部分至少包含：色板（给出具体色值范围）、参考图（三到五张，注明"参考的是构图不是风格"）、屏幕占比（角色在 1080p 下实际占多少像素高）、资产清单（需要多少种敌人、多少个场景、多少套 UI）。

音频部分至少包含：音乐风格参考、音效清单（按事件分类，如"命中""受击""拾取""UI 点击"）、混音优先级（哪些声音不能被盖住，比如敌人攻击预警音）、动态音乐触发条件（血量低于 30% 时切到紧张层）。

叙事部分要区分"硬设定"和"软氛围"。硬设定是会影响玩法的东西，比如"这个世界里角色不能飞"，必须写清楚；软氛围是文本风格和世界观碎片，可以放到单独的叙事文档里。把两者混在一起写，程序读的时候会分不清哪些是约束、哪些是装饰。

我踩过的一个坑是，叙事里随手写了一句"主角是失忆的"，结果程序做开场动画时真的做了个失忆剧情，但玩法上设定主角一开始就拥有全部技能，逻辑对不上，临时改稿折腾了一周。教训是：任何叙事设定，只要和玩法有潜在冲突，都要在 GDD 里显式标注"此设定不影响玩法"或"此设定约束玩法 X"。

3.6 UI/UX：把界面写成人能看懂的层级表

UI 章节我建议用界面层级表来写，而不是画十张线框图。线框图留给交互原型，GDD 里只需要讲清楚界面之间的关系。

这张表一出来，UI 美术就知道要做几个界面，程序就知道界面栈怎么管理，交互设计就知道哪些是模态、哪些是覆盖。比画图高效多了。

交互流程再补一张"关键操作路径表"，比如"从主菜单到进入第一关需要几步点击"。我给自己定的标准是核心操作不超过三步。超过一步，玩家就可能在犹豫中退出。

4. 实操：从零写出一份能玩的 GDD

前面讲了那么多结构和方法，现在我把它们串起来，用一个完整案例走一遍。这个案例是一款小体量横版动作 Roguelite，目标单局 10 分钟，适合一到两人的小团队。

4.1 案例设定与目标拆解

先写一页纸。定位：横版动作 Roguelite，目标平台 PC，单局 8 到 12 分钟，目标用户是下班后想快速爽一把的玩家。核心体验支柱就是我前面举的那四条。

然后做目标拆解，把大目标切成可验证的小目标：

• 首局体验目标：玩家在 90 秒内理解移动、攻击、闪避三个操作
• 单局目标：玩家每局遇到 3 个随机房间，每房间有一次三选一
• 长期目标：每局结束保留 20% 的永久成长货币
• 手感目标：每次命中有 4 帧停顿和轻微屏幕震动
• 难度目标：首次通关率控制在 40% 左右

这些目标都可以被测试验证，写出来之后团队心里就有数了。"90 秒内理解三个操作"这种目标，直接可以拿去做新手测试。

4.2 核心循环与数值框架搭建

核心循环按四层时间尺度写，前面已经给过表格，这里补充数值框架。

角色基础属性：初始血量 100，初始攻击 10，初始移速 8 格/秒，闪避无敌帧 12 帧，冷却 0.6 秒。

成长框架我设计成乘法叠加而不是加法叠加，因为它更容易保持平衡：

最终攻击 = 基础攻击 × (1 + 所有加成之和) 所有加成包括：装备加成、局内 buff、永久成长

为什么用乘法？因为加法叠加在多轮循环后会失控。假设每局给固定 +5 攻击，玩十局后攻击到 60，怪物的血量没法设计了。而乘法叠加保持相对比例，你只需要调整怪物的血量和防御，整个系统就能稳定延展。

敌人设计用"威胁值"来统一衡量强度。威胁值 = 血量 ÷ 100 + 每秒伤害 ÷ 10 + 特殊机制权重。一个房间的总威胁值控制在玩家当前战力的 0.7 到 1.1 倍之间，这样既不会太难也不会太简单。这个系数范围是我实测出来的，低于 0.7 玩家觉得无聊，高于 1.1 玩家觉得不讲理。

4.3 系统细节表格化：把策划案写成可实现的说明书

到了这一步，就是把我前面讲的三件套填满。技能表、公式、状态机都要有。

我举个具体的：连招系统。三段连招，每段可以取消。

"输入窗口"和"可取消时机"这两列是新人和老手的最大差距。老策划会精确到帧，新策划只会写"连招要连贯"。而"连贯"到底是多少帧？程序不知道，只能自己猜，猜出来手感不对，反复返工。写清楚帧数，一次就过。

再补一个打击感参数表：

这张表是整份文档里被美术和音频翻阅频率最高的一页。因为它把"打击感"这个玄学词拆成了可以被执行的参数。我每次做动作游戏，这一页都是最先定稿的。

4.4 版本迭代与变更记录

GDD 是活文档，必须维护变更记录。我的做法是在文档头部放一张变更表：

变更记录看着琐碎，但它是团队里最省事的一个设计。程序改了代码想查当初为什么这么设计，翻变更记录比翻聊天记录快十倍。外包美术隔了两个月回来问参数，你直接让他看变更记录，不用重新解释一遍。

注意：变更记录里一定要写"影响范围"。我见过因为一次数值改动没通知音频，导致音效长度和新的动作时长对不上，发布前一周才发现，加班重录。

5. 协作与工具链：让 GDD 真正活起来

文档写完了不代表工作结束，恰恰相反，真正的挑战是让它别躺在网盘里吃灰。这一章讲协作和工具，都是实操层面的干货。

5.1 工具选型：文档、表格、白板各司其职

我现在固定用三类工具组合。文档用在线 Wiki，负责叙述性内容；表格用在线协作表格，负责所有数值和配置；白板工具负责流程图和状态机。为什么不合成一个？因为它们的协作模式不同。文档要的是版本对比和历史追溯，表格要的是多人同时编辑和公式，白板要的是随意拖拽。强行合并，每一样都用得别扭。

还有一点经验：能用表格的绝不用文档。数值、技能、敌人、关卡，全部表格化。因为表格可以被程序直接导出成配置，可以被数值策划直接用公式计算，可以被 QA 直接生成测试用例。文档做不到这些。我在文档里只保留"为什么这样设计"的说明，具体数据一律进表格。

5.2 评审机制：什么时候评审，评审什么

GDD 不能自己写完就发出去，得有评审。但我反对全文档大评审，一次评审三十页，参与的人会走神，最后变成走过场。我的做法是分模块小评审，一次一到两小时，只评审一到两个模块。

评审节奏上，我遵循"先核心循环，后系统细节，最后表现层"的顺序。因为核心循环一旦确定，后面的所有细节都建立在它之上；核心循环没定就评审表现层，属于白费功夫。

评审的产出必须落到文档里。我的规矩是：评审当场记录结论，会后 24 小时内更新文档，并且把变更写进变更记录。否则评审完大家都记得改了，但没人写下来，两周后又是各说各话。

提示：评审时一定要拉上一个"刺头"。就是那个总爱挑毛病的人。他提出的问题往往是最尖锐但最有价值的。让他在评审阶段挑毛病，比让他在发布后挑毛病划算得多。

5.3 GDD 和原型的关系：谁先谁后

这个问题我纠结过很久。到底是先写文档再做原型，还是先做原型再补文档？我的答案是：核心循环先做原型，系统细节先写文档。

原因很简单，核心循环这种东西，写再多文字都不如做出一个 30 秒的可玩片段来验证。手感、节奏、爽点，这些是体验层面的，只有玩到才知道对不对。你先写五千字描述"打击感很强"，不如做个只有一刀的原型，让团队上手砍两下。

而系统细节，比如成长曲线、经济公式、状态机，这些东西做原型成本太高，而且逻辑性的东西用文字和表格推演就够了。把这块先写清楚，再交给程序实现，效率远高于先写代码再回头补设计。

所以我的流程通常是：一页纸 → 核心循环原型 → 核心循环定稿进 GDD → 系统细节文档 → 系统实现 → 表现层文档 → 打磨。两条腿走路，哪边效率高用哪边。

6. 常见问题与排查技巧实录

写了这么多年 GDD，踩过的坑基本能归类。我整理成一张速查表，你可以拿它当自查清单。

6.1 GDD 常见问题速查表

这张表里，我个人觉得最值得警惕的是第一条。"程序做出来的和想的不一样"，90% 的情况不是程序理解力问题，而是文档里有一条隐含假设没写出来。比如你理所当然地认为"攻击可以打断移动"，但没写，程序就实现成"移动中不能攻击"。这种隐含假设是最隐蔽的 bug 源。

排查方法也很简单：每次发现做出来的不一样，回头问自己"我假设了什么没说"。把这些假设逐条补进文档，几轮之后文档质量会明显上一个台阶。

6.2 几条踩过坑才懂的避坑心得

**第一条，别在文档里写"参考某某游戏"。**新人最爱这么写，因为省事。但"参考某某游戏"的问题是，不同人对同一个游戏的记忆是不一样的，有人记得它的战斗，有人记得它的美术，有人记得它的付费。你写"参考 A 游戏的战斗"，美术可能跑去参考了 A 游戏的美术。正确做法是拆解清楚："战斗节奏参考 A 游戏，具体是它的攻击间隔约 0.6 秒、后摇约 0.3 秒、命中停顿 3 帧"。把参考拆成具体参数，才叫真参考。

**第二条，留一页"设计决策记录"。**有些设计选择不是因为有数据支撑，而是当时的权衡结果。比如"我们没有做多角色切换，因为单角色已经占满了美术资源"。这类决策如果不记下来，三个月后必然有人问"为什么不做多角色"，你得重新解释一遍，甚至有人会提议加多角色，把范围又撑开。把决策和理由记下来，能省下大量重复讨论。

第三条，文档的行文要用"断言句"，不要用"愿景句"。"我们希望玩家感到紧张"是愿景句，执行者不知道怎么做。"当玩家血量低于 30% 时，背景音乐切换为紧张层，屏幕边缘出现红色渐晕，且该状态持续到血量回到 50% 以上"是断言句，可以被实现和被测试。整份文档我都尽量用断言句写，读起来可能没那么"有文采"，但落地效率高得多。

**第四条，定期做一次"文档体检"。**我习惯每两周挑一个小时，把文档从头翻一遍，问三个问题：有没有和当前版本对不上的地方？有没有模糊词？有没有没人认领的段落？文档和人一样，放着不管就会腐化。特别是项目做到中期，变化快，旧描述很容易过时，而程序还在照着旧描述做，等发现的时候已经晚了。

**第五条，给不同职能做"阅读路径"。**文档写好后，我在开头放一张表，告诉不同角色该看哪几章。程序看第 2、3、4、5 章，美术看第 1、3.5、3.6 章，音频看第 3.5、4.3 章，QA 看第 3、4、6 章。这样每个人都不用读全文，上手快，也更容易形成"这份文档跟我有关"的认知。

这套方法我是从一个老制作人那里学来的，当时觉得有点小题大做，后来带了一个二十多人的项目才发现，没有阅读路径的文档，基本等于没有文档——因为没人有耐心从头看到尾。

最后再分享一个我自己的小技巧：每次写 GDD 的时候，我会在文档最后留一个"待定问题"清单，把所有暂时没想清楚、但又不影响当前开发的点列在那里。这样做的好处是，我不用在写文档时被这些悬而未决的问题卡住，同时也不会遗忘它们。清单每周过一遍，能解决的划掉，解决不了的升格成需要评审的议题。写文档最怕的就是为了"写完整"而硬凑内容，留一个诚实的"待定"，比编一个假答案有价值得多。