编写下一次制作真正需要的文档
游戏设计文档应说明要制作什么、暂时不做什么，以及如何判断原型是否正常运行。对于 AI 辅助开发，最有用的部分是具体规则、操作方式、范围边界和验收检查。再长的故事大纲，也无法回答同一个拾取物是否会被重复计数，或重新开始时必须重置哪些状态。
本指南始终使用同一个教学示例：Rain Route，一款小型机器人送信游戏。它的 GDD、提示词、修改和测试都指向同一个拟议游戏。这不是实际生成的项目，也不是用户体验报告。下面的工作流展示如何把决策连接到实现，并不声称这个版本已经存在。
复制这份已填写的小型 GDD
Rain Route，设计版本 0.1。
游戏概念：一名俯视角机器人穿过一条雨中的城市街区，运送装有记忆的包裹。
玩家与平台：单人游戏，在桌面浏览器中使用键盘操作。首次体验约五分钟是设计目标，不是实测结果。
体验承诺与核心支柱：平静的导航、清晰可辨的目的地和小范围路线选择。优先保证反馈清楚，而不是增加系统。
核心循环：在配送站领取一个包裹，走到编号匹配的门前投递，再返回领取下一个。完成三次投递获胜。
操作与镜头：固定俯视镜头。使用 WASD 或方向键移动。在标记的交互区域内按 E 领取或投递。获胜后按 R 重新开始。屏幕显示操作说明。
规则：一次只能携带一个包裹。按 1 号、2 号、3 号门的顺序投递。在错误门前按 E 会显示提示，但不会移除包裹。每次正确投递只增加一次计数。重复按 E 不能重复计算已经完成的投递。
地图与挑战：一个街区、一个配送站、三扇门、一处积水路段和一条干燥的绕行路线。在积水中移动速度为正常速度的一半。没有生命值损失、敌人或计时失败。
反馈：显示当前目的地、携带的包裹和已完成投递数。门使用清楚不同的编号，投递成功时显示确认信息。雨声音量应保持轻柔，并提供静音选项。
技术范围：一个浏览器原型，不包含账号、云存档、联网、购买、额外地图或解锁系统。重新加载会开始新的一局。循环通过检查前，使用简单原创图形。
获胜与重置：完成第三次投递后显示胜利面板。按 R 将机器人、包裹、目的地、投递计数和胜利面板恢复到初始状态。
审查问题：新玩家能否只靠屏幕上的说明完成第一次投递？
第一步：将 GDD 转换成一次制作请求
把文档作为输入，而不是已实现功能的证明。提交前检查范围、操作和胜利条件是否矛盾。“重新加载开始新的一局”意味着不能承诺投递进度持久保存；“只能携带一个包裹”意味着不能暗中引入物品队列。应在 GDD 中解决这些决定，不要让实现自行猜测。合适的第一次提示可以是：
根据设计版本 0.1 制作 Rain Route。首先只实现地图、移动、配送站领取和 1 号门投递。保留后续门的可见外观，但暂不启用。显示当前目的地和携带状态。使用简单原创图形。不要增加天气效果、解锁、失败计时器或额外机制。说明修改了哪些组件，以及如何测试领取、错误门交互、正确投递和重复按 E。
首次请求只包含一个投递切片。它的输出应让你能在增加目的地数量之前检查一次完整交互。如果无法使用文档规定的操作完成路线，应修正这个切片，而不是扩展地图。
第二步：在同一游戏中将需求对应到测试
为重要规则设置简短标识，并在提示词、笔记和测试记录中保持一致：
| 需求 | 在 Rain Route 中的操作 | 预期结果 |
|---|---|---|
| R1：最多一个包裹 | 在配送站按 E 两次 | 仍然只携带一个包裹 |
| R2：只能投递到正确目的地 | 携带 1 号包裹前往 2 号门 | 显示提示，包裹仍保留 |
| R3：投递只计数一次 | 在 1 号门投递后反复按 E | 计数保持为一 |
| R4：按顺序推进 | 完成全部三次投递 | 目的地按 1 → 2 → 3 前进；胜利只显示一次 |
| R5：积水减速 | 分别在水中和水外对同一段标记路线计时 | 积水中的速度符合指定的正常速度一半 |
| R6：完整重置 | 获胜后按 R | 恢复初始位置、双手为空、零次投递，胜利面板消失 |
在独立运行日志中记录实际观察，并附上构建版本和环境。只有执行操作之后，才能标记通过、失败或受阻。如果第一个切片未通过 R2，应先修复该交互，再请求三次投递。输入步骤要足够准确，让其他人能够复现失败。
第三步：扩展循环，然后添加氛围
第一次投递通过后，请求加入 2 号门、3 号门，以及胜利和重置状态。重新运行 R1 至 R4 和 R6，再请求积水减速，并在不改变拾取逻辑的情况下检查 R5。
只有这些规则通过后，才添加雨天视觉效果和轻柔环境音。检查雨效是否遮挡门牌数字或交互标记，以及静音是否有效。如果天气效果让地图难以辨认，应减弱效果，而不是为了氛围牺牲文档中的玩家体验承诺。
第四步：证据改变决策时更新 GDD
假设未来的试玩显示玩家经常看漏当前目的地。这在本文中是假设观察，并非实际结果。范围明确的修改可以要求目的地标签更加醒目，同时保持门的顺序和投递规则不变。然后请新玩家再次回答同一个首次投递问题。
将决定记录为版本 0.2，说明变化原因，并关联受影响的需求和构建版本。保留以前的决定，避免把旧测试结果误认为新规则的证据。修改后的需求应指出哪些早期检查需要重新运行。
如果生成的修改破坏了先前需求，应回退或隔离该修改。报告失败的需求、确切输入、预期结果和实际结果。“重复按 E 后 R3 计数两次”比“原型感觉有 bug”更便于处理。
在规格与测试日志之间使用 SEELE
SEELE 支持使用自然语言创建游戏，并对玩法、场景和素材进行迭代修改。将小型 GDD 作为设计输入，再请求一个范围明确的实现切片。有用的输出是能够与同一份文档对照的候选版本，而不是设计判断的替代品，也不是已经完成的测试记录。
每次追加请求都应指出发生变化的需求，以及必须保持稳定的需求。要求目的地标签更清楚，不应悄悄引入计时器或改变门的顺序。通过版本号关联文档、提示词和实际观察，让精美的描述不能代替真实行为。
用 GDD 启动制作，而不是拖延制作
有用的 GDD 缩短决策与检查之间的距离。Rain Route 在需要更长的故事大纲之前，需要清楚的领取规则、目的地顺序和重置定义。文档应保持精简，但规则要准确到足以让不同的人判断同一个版本。
将规格复制到 SEELE，请求实现第一次投递切片。通过版本号保持文档、可用版本和测试日志一致。只有同一游戏的现有规则在实现和修改后仍然成立时才扩展范围；证据改变决策时，及时更新 GDD。
将设计追踪到可玩的检查
下表整理的是本文提出的检查项，并非已经完成的测试报告。
| GDD 要素 | 回答的问题 | 验收检查示例 |
|---|---|---|
| 玩家与输入 | 谁在玩，如何操作？ | 桌面玩家能使用指定键盘操作移动机器人。 |
| 目标与范围 | 这个版本必须完成什么？ | 玩家能在指定场景中投递指定包裹。 |
| 规则与边界 | 规则触发时会发生什么？ | 投递或拾取只按设计规定的方式计数。 |
| 失败与恢复 | 玩家无法完成任务时会发生什么？ | 规定的失败或重新开始行为使游戏恢复到文档所述状态。 |
| 修改日志 | 哪项决定发生变化，为什么？ | 记录观察、修改后的规则和重新检查的结果。 |
常见问题
原型 GDD 应该有多长？
在能解决下一步实现决策的前提下尽量简短。已填写示例规定了范围、操作、规则和测试，不需要一整套制作宝典。只有当某个章节会改变制作或检查内容时，才加入它。缺少一条交互规则的代价，通常比缺少一页背景设定更高。
AI 可以替我编写文档吗？
AI 可以起草章节并指出模糊之处，但你仍需决定规则并验证可行性。可以要求它找出互相冲突的需求和缺失的验收标准。不要把精美文档当作趣味性、实现质量、素材权利或未经检查的产品能力已经得到验证的证明。
GDD 和测试日志有什么区别？
GDD 记录预期行为和设计决定；测试日志记录在特定构建版本和环境中实际发生了什么。两者应关联但保持独立：预期可以通过，不等于测试已经通过。当观察结果足以改变规则时，应明确更新设计，并重新运行受影响的检查。
较大 GDD 的章节清单
只添加能帮助决定下一版构建内容的章节。先写目标受众、平台和一句话简介，再写核心循环、操作方式、成长系统、世界观或叙事、美术和音效约束，以及技术要求。为范围内的每项功能记录负责人、最小可玩验证和团队能重复运行的测试。把可选想法放进独立待办列表。
