Open GDD。 为 AI Agent 而生。
告别 vibe coding 的混乱，把游戏想法写成 13 章可评审的 Real GDD。AI 按章节执行，团队用 Git 审阅每一次改动。
变更记录 · Markdown 文件 · 维护者
一切都可追踪、可引用、可验真：模板演进、 Markdown 文件、以及是谁在维护。
和你已有的工具链直接兼容。
Open GDD 本质是 Git 里的 Markdown：天然适配 AI 编程工具与 Diff 评审流程。
开源许可与商用边界说清楚。
你能复用什么、你拥有什么、以及上线与收费时你需要承担什么责任。模板仓库： https://github.com/wanghaisheng/GDDMarkdownTemplate
没有 Real GDD 的 Vibe Coding
AI 能写代码，但它需要一份可审阅的设计蓝图
下游：Vibe Coding Crisis
没有上游约束，你会在“能跑的原型”和“能交付的版本”之间反复返工。
- 同一个需求反复解释，上下文漂移，token 成本飙升。
- 玩法、经济、关卡互相打架，系统缺少统一约束。
- 改动很难评审：没有章节边界、没有清晰 Diff、也不好回滚。
- 越做越像重写。问题往往不是代码，而是没对齐。
上游：Open GDD → Real GDD
先把关键决策写成章节，再让 AI 负责扩写与实现。
- 13 章模板 = 可引用的结构：用 slug 锚定上下文。
- 按章填到“最小可评审”，先对齐，再迭代。
- 按章引用减少幻觉，AI 更清楚哪些是约束，哪些能发挥。
- 把 GDD 变成 backlog，让各类 AI 工具按任务交付。
AI 时代做游戏最大的坑：没有上游桥梁
Vibe coding 不等于坏。问题是缺少 Real GDD 时，它会很快走向下游混乱：上下文漂移、系统失衡、反复重写。Open GDD 做的事很简单：先把想法变成可执行的设计，再去加速实现。
上下文漂移
Agent 会忘记之前的决定，机制与设定互相冲突。
隐含假设炸弹
难度曲线、经济边界、性能预算等没写清楚，最终都以 bug 形式爆炸。
不可审阅的变更
没有章节边界，任何改动都像一团；难以评审、分工、回滚。
原型墙
原型很快，但缺少数据结构、规则表、接口契约，就无法进入可持续开发。
写给人读，也写给 Agent 执行。
默认覆盖关键面
13 章结构能防止盲区：玩法、UI、AI、技术与制作项一应俱全。
Markdown 协作友好
可 PR 审阅、可 Diff、可合并。你的文档变成“可维护资产”，而不是 PDF 墓碑。
适合 Agent 的粒度
独立章节让你能分段提示与迭代，不需要把 Agent 淹死在一个巨文件里。
制作期附录可落地
资产清单、术语表、KPI 定义与检查清单放在团队会持续更新的位置。
让 AI 真正能执行的 GDD 结构。
独立游戏制作人
把模糊灵感变成可迭代、可落地的结构化文档。
策划与叙事团队
让玩法、故事、UI、数值在同一套结构里对齐。
制作人与主策/主程
在开工前把范围、依赖与审批点写清楚。
AI 协作工作流
按章节喂给 Agent，不丢上下文，也不丢结构。
你会得到什么
完整、可审阅的结构，一章一章扩写。
13 章标准结构
从概述到技术、UI、AI 与附录，不留缺口。
Markdown 优先
可 Diff、可合并、可搜索，适配任意协作流程。
面向 AI 的章节设计
每章都可安全地交给 Agent 扩写与补齐。
团队对齐与可追溯
关键决策可见、可回溯、可评审。
用 AI 从 Open GDD 生成 Real GDD，并驱动工具落地
每次只处理一章：可引用、可评审、可追踪。
复制模板到你的仓库
从你的游戏创意出发，创建一个 repo，把 13 章作为唯一事实源。
让 AI 先补“最小可评审信息”
按章生成：先写清楚目标、约束、例子与关键数值，不追求一次写完。
逐章评审与锁定决策
看 Diff、做取舍、把假设变成明确的规则与数据，避免系统漂移。
用章节引用驱动工具链
在提示词里引用 /docs/{slug}：让 Cursor/Claude Code/各类 Agent 只在约束内实现与扩写。
我们会把这套流程产品化：一键把 Open GDD 填成 Real GDD，并继续扩展到“从 GDD 直接驱动游戏开发”的阶段。
加入极速构建者社群
获取 Open GDD 模板更新、章节写作指南与工作流示例。
关于 Open GDD 与 Real GDD 的关键问题。
Open GDD 是一套公开的 GDD 章节结构与写法模板（13 章）。Real GDD 是你项目的具体版本：填了数据、做了取舍、能评审、能执行。
可以，但把它当下游加速器：先用 Open GDD 把关键决策写清楚，再让 AI 去实现与扩写。没有上游约束的 vibe coding 往往会导致系统漂移与反复重写。
从能锁定方向与范围的章节开始：核心概念/玩法循环、受众与平台、经济与进度、内容与关卡，再补技术与制作计划。按章推进，保证每章都“最小可评审”。
把你的创意与约束给 AI，让它按章节填充，并要求每个小节给出可验证的例子/数值/表格。每次只生成一章，结合 Diff 审阅，避免一次性长文幻觉。
用章节 slug 作为引用锚点：在提示词里明确“只依据 /docs/{slug} 的约束生成”。把每章拆成可执行任务（数据表、规则实现、UI 需求、资产清单），让不同 AI 工具各做其事。
适合大多数类型，尤其是系统复杂、内容多、需要跨角色协作的项目。小项目也能用：只保留必要章，其他章标注 N/A 或待定即可。
不需要。先写到“足以开始第一轮可玩原型”的程度，然后随着验证逐章补全。关键是让每次迭代都有明确的上游依据。
它是结构，不是负担。按章最小化填写、按章引用、按章评审，反而能降低 token 成本并减少返工。