用 AI 做游戏 · 通用方法论

这篇讲的是一套用多个 AI 对话协作做游戏的实践方法——包括对话怎么分、文档怎么写、讨论怎么进行、工程怎么组织。

适合：一个人、用网页端 AI（上下文有限）、做长期项目的场景。

不适合：一次性小工具，或者你自己会写代码、AI 只是辅助的场景。

本文整理的是 2026-10 当前阶段的做法，会随实践继续调整。有更好的方式欢迎讨论。

为什么要分多个对话

先说清楚这套方法要解决什么问题。

网页端 AI 的上下文是有限的。一个对话里塞太多信息——设计讨论、代码细节、美术要求、测试反馈——它会开始"忘事"：前面说过的东西后面不认，或者把不同阶段的需求混在一起。

分多个对话解决的就是这个问题。每个对话只承担一类工作，通过文档互相传递。这样每个对话的上下文压力小，能活得久。

代价：跨对话要手动传递文本，改东西要手动同步文档。
收益：每个对话能长期用，不会很快用尽上下文。

什么时候才需要分：项目大到"一个对话装不下"时。小项目一个对话就够。

一、总览

核心思路

用多个独立的 AI 对话协作做游戏，每个对话只承担一类工作，通过文档互相传递，你做决策。

适用前提

• 项目持续做很久（不是一次性小工具）
• 你不写代码（或写得很少，主要靠 AI）
• 愿意花时间维护文档体系
• 用网页端 AI（上下文有限，所以需要分）

不太适用的情况

• 一次性小工具——一周做完就扔
• 项目很小，一个对话就能装下
• 你自己会写代码——AI 只是辅助
• 不需要长期迭代——做完就完，文档维护是负担

二、四个对话的分工

分工骨架

为什么这么分：

• 必分——创意（视角独立）、程序（代码占上下文）
• 推荐分——技术对话不被代码占上下文，能活更久，站在参谋位置
• 按需分——美术对话的触发条件是"预估图标量大"或"程序画得不满意、经常需要改"，任一满足就分

临时对话

定位：临时需要就开，用完即弃。不是常驻。

典型用途：合并文档、批量任务、特定排查、探索性任务。

美术对话是临时对话的特化案例——美术方向 + 有专属美术指南。

每个对话做什么

创意对话

• 做什么：讨论设计、组织需求、输出任务文档
• 不做什么：不写代码、不看代码
• 输入：设计文档 + 用户需求
• 输出：任务文档

程序对话

• 做什么：改代码、跑验证、更新交接文档
• 不做什么：不参与设计
• 输入：交接文档 + 任务文档
• 输出：代码改动 + 文档更新 + 报告

技术对话

• 做什么：技术判断、文档维护、任务整理、审核程序输出
• 不做什么：不直接改代码、不主动介入
• 输入：拿不准的问题 + 相关文档 + 相关代码
• 输出：判断 / 方案 / 替换对 / 文档

美术对话

• 做什么：画图标、统一画风
• 不做什么：不碰逻辑、不碰数据
• 输入：美术指南 + 图标清单 + 相关绘制代码
• 输出：图标绘制函数

每个对话的启动方式

从创意到美术的传递链

当任务涉及美术时：

1. 创意输出两份
   • 创意 to 程序（代码任务）
   • 创意 to 美术（美术任务：中文名 + 视觉要求）
   • 只有涉及美术时才生成两份
2. 用户分发
   • 创意 to 程序 → 给程序对话
   • 创意 to 美术 → 暂存
3. 程序输出"程序 to 美术"，含四项
   • 函数名（程序按项目约定命名）
   • 函数在文件中的位置
   • 该位置的当前占位内容
   • 替换式交付引导（美术按"找到占位 → 替换为完整实现"输出）
   • 注：程序看不到"创意 to 美术"的原文，两份是独立信息
4. 合并者合并（临时对话或技术对话）
   • 合并者高亮冲突
   • 和用户沟通解决
   • 用户拍板
5. 合并后交给美术对话
6. 美术产出替换式代码
7. 交付程序集成

关于名字对齐：创意起中文名（暂定），程序沿用。如果程序这边有变更（比如命名冲突需要改），"程序 to 美术"里要体现变更。

三、讨论方式

和创意讨论的粒度

讨论到"任务不产生歧义"——模糊的想法不够，要讨论到能直接交付给程序执行。

和程序讨论的粒度

讨论到"不需要提供更多信息，不需要程序臆测"。

决策权

AI 做推荐，但不默认执行。最终拍板是用户。

信息提供原则

按需给，但不让 AI 猜：

• 讨论到哪个文件 → 给那个文件
• 讨论到哪个功能 → 给那个功能涉及的文档 / 代码
• 不给 AI 猜的余地（宁可多给，也不让它臆测）
• 但不是无脑全给（全给会占满上下文）

代码和文档都是按需给——不是"文档全给代码按需"，是两者都按功能给。

讨论归档

创意 / 程序讨论完，产出结果——归档走技术对话：

• 用户把创意 / 程序的正式产出给技术对话
• 和技术对话讨论"这个改动应该加到哪个文档的哪一节"
• 技术对话决定归档位置（可能涉及跨文档协调）
• 用户执行

为什么走技术对话：程序可能需要改设计文档，创意可能需要改交接文档——交叉是存在的，技术对话站全局位置能看清。

给技术对话的材料：给正式产出（文档片段 / 变更记录条目），不是对话过程。

常规任务（加内容 / 调数值 / 改文案）不告知技术对话；只有关键改动（影响机制 / 影响文档结构 / 涉及跨对话）才告知。

用户也可以跳过技术对话直接归档——但跳过需要告知技术对话。

四、文档体系

五类文档

文档维护规则

按"节功能"分配维护者，不按"整份文档"分配。

典型：

• "当前已有内容"类节 → 程序对话维护（它最清楚代码现状）
• "方向 / 思考状态"类节 → 创意对话维护（它的视角）
• "工作约定 / 流程"类节 → 用户维护（稳定信息）
• 所有文档 → 技术对话都能改（它是文档维护者）

交叉是正常的——不同节服务不同读者，不必强行统一。

文档间的传递

• 创意 → 程序：任务文档
• 程序 → 创意：更新设计文档的"当前内容"
• 创意 / 程序 → 技术：正式产出（讨论归档）
• 技术 → 用户：判断 + 替换文本
• 创意 / 程序 → 美术：任务拆分（美术部分）

归档

旧文档不删，移到归档目录。保留原因：查"为什么这么设计"时有用。

五、工作流

主线（普通任务）

1. 用户 ↔ 创意对话讨论设计
2. 创意输出任务文档
3. 用户转给程序对话
4. 程序复述理解 + 给分批建议
5. 用户确认分批
6. 逐批执行：
   • 程序要文件
   • 用户贴文件
   • 程序出改动（找到 X → 替换为 Y）
   • 用户改文件
   • 验证（跑校验 + 人工测）
7. 全部批完成 → 程序走收尾清单（更新文档）
8. 用户把正式产出给技术对话 → 归档判定

带美术的任务

1. 创意输出两份：创意 to 程序 + 创意 to 美术
2. 用户分发：创意 to 程序给程序对话，创意 to 美术暂存
3. 程序输出"程序 to 美术"（函数名 + 位置 + 占位内容 + 替换式引导）
4. 用户合并（临时对话或技术对话）：合并者高亮冲突，和用户沟通解决
5. 用户把合并结果给美术对话
6. 美术产出替换式代码
7. 交付程序集成
8. 程序继续主线

技术对话的介入点

• 技术判断（用户 / 创意 / 程序拿不准时）
• 归档判定（正式产出给技术对话）
• 改指导性文档

临时对话的使用场景

• 合并任务（省技术对话的上下文）
• 批量任务
• 排查
• 探索

六、文档修改约定

改动格式

每条改动都要给：

• 文件路径：从项目一级目录开始（不能只有文件名）
• 类型：整个函数替换 / 局部替换 / 增加语句 / 删除语句 / 新建文件 / 整节替换
• 锚点：找到 X → 替换为 Y，锚点唯一（同一文件只在一处能搜到）
• 替换范围包含边界：整节替换说"从 X 行到 Y 行为止"，不是"到 Y 之前"

讨论节奏

先讨论改哪些（列改动点），用户确认后再给完整文本。

代码块规则

• 外层可以有一个代码块（用于整段复制）
• 内部不再出现三反引号——客户端在嵌套代码块时会渲染错乱
• 日常对话 / 展示代码用代码块没问题
• "要保存到文件的内容"用外层代码块包裹，内部不用

顺手改声明

• 发现可以顺手改的地方 → 声明 + 和用户讨论（不论打不打算做）
• 没发现 → 不提

七、基础设施

四类基础设施

校验脚本分三层

1. 数据一致性——数值守恒 / id 存在 / 引用有效
2. 加载冒烟——import 能跑通（模块拼接无误）
3. 人工清单——打勾页（覆盖"脚本验证不了"的）

校验脚本的关键设计

• 只读——不改项目文件
• 一键全跑 + 单独跑——一键能一把跑完，也能单跑某一个
• 失败不阻塞其它——某个脚本失败，其它继续跑；最终汇总显示哪些失败
• 错误清晰——输出"哪里错、怎么改"（用于人 + AI 讨论）

备份机制

• 备份方式自选（打包 / git / 其它）
• 时机：完成一个阶段 / 一天结束时
• 位置：项目目录外
• 不管选哪种，大改前必备份

辅助工具

• 合并脚本（把代码合并成单文件给 AI）
• 行数统计（避免编码坑）
• 人眼看的工具页（图标总览 / 微调工作台）

八、项目启动清单

第一步：判断规模

先判断项目做多大，再决定第一天建什么。三个档：

• 小——一个对话能装下
• 中——需要 2-3 对话
• 大——需要 4 对话

判断依据：项目的内容量 / 迭代周期 / 你会不会长期做。小项目不要上重体系，大项目不要省。

第二步：小项目第一天做什么

• 最小原型能跑（见 8.6"最小原型"）
• 一份极简交接文档——把"项目概况 + 设计理念 + 当前有什么"写清，哪怕只有半页
• 备份机制——大改前能备份

第三步：中项目相对小项目多什么

• 拆对话——至少拆成"设计"和"执行"两类
• 每个对话一份角色文档
• 操作手册——对话多了，需要写"怎么用这套体系"
• 变更记录

第四步：大项目相对中项目多什么

• 拆满四个对话（设计 / 执行 / 技术 / 美术）
• 骨架设计要预留扩展——对话多，跨对话传递成本高，一开始就要考虑接口清晰
• 工具说明——工具到一定数量后
• 辅助工具——如合并脚本、行数统计

第五步：逐步补建（按需）

• 架构盘点——打算优化架构的时候建（不是"稳定后"，是"要动手改之前"）
• 参考文档——有内容后建
• 美术指南——需要美术对话时建

最小原型

"最小原型"是能玩的最小玩法，不是"能跑的一行代码"。

至少包含游戏的基本要素：

• 产生——玩家能做什么
• 探索——玩家能去哪
• 改变——玩家的行为对世界有影响

如果一时凑不出"能玩的最小玩法"，说明设计还没清楚——先讨论清楚再开工。

"能跑" ≠ "能玩"：

• 点一下弹个提示 → 能跑，不能玩
• 有输入 / 有反馈 / 有状态变化 → 能玩的最小单位

九、一句话总结

多个 AI 对话各司其职，通过文档传递，用户做决策。
按节功能分配文档维护，讨论到无歧义再动手，分批推进。
大改前备份，改完更新文档。

署名