5 个阶段 × 6 步工作流进化 × 13 个知识主题 从 0 到 1 做一个 AI 驱动的多人游戏需要知道的一切。我用自己的项目 GTS-Play巨大娘主题单机产品「巨大娘的玩耍」已发布 v1.0多人在线版基于 Three.js ReactLerna monorepo从单机改多人的真实经历把每个决策、每次踩坑、每次重构都记下来。时间线速览5 个阶段basic1 帧同步 → new_basic2 状态同步 → 大重构 → 迭代开发 → SCF 部署↓ ↓ ↓ ↓ ↓P6 P7 P8 P9 P10P6 帧同步basic1 原型— 2026年5月底一切从这开始。basic1 是我自己手写的帧同步原型通信层使用了 TSRPCWebSocket。方案很经典服务端只做中继转发指令所有客户端同步执行相同的逻辑确保结果一致。看起来很美。服务端超级轻量只需中转指令包。每个客户端独自计算物理、碰撞、游戏逻辑。理论上只要种子一样、指令顺序一样各端结果就一样。但实际跑起来第一个问题就是浮点数各平台不一致。同样的位置计算用 Chrome 和用 Firefox 跑两帧就开始偏移。我拉了两台电脑手动对比发现 Math.atan2 和浮点加减法在各浏览器里的 NaN 处理、denorm 行为微妙不同差一个 ULP 都会在下一帧放大。当时我问 AI 原因它自信地说「JavaScript 的 IEEE 754 浮点是确定的」但实际跑起来却不是那么回事。第二个问题是代码里不慎用了 Date.now() 做时间戳。按 Lockstep 理论所有客户端必须使用完全相同的逻辑时钟但作为同步敏感细节被我忽略了。结果每个客户端自说自话地推进时间游戏进程很快就不一致了。第三个问题暴露得更晚单人逻辑与多人进入逻辑耦合。从单机小 demo 改多人时保持了原有的流程——必须从单人关卡创建进入、再切换到多人。这导致测试极其麻烦每次都要走一遍完整的单人创建流程。2026年5月底到6月初我在 basic1 上磨了一周。到后来我已经清楚——Lockstep 虽美但手动维护所有同步细节实在太难。6月初我决定放弃 basic1换了方向。P6 会完整展开这个阶段的故事。P7 状态同步new_basic2 原型— 2026年6月上旬basic1 的 TSRPC 通信层保留了下来但同步模型要彻底换——从帧同步改为服务端权威状态同步服务端统一算 tick所有客户端只做渲染。这个改动是翻天覆地的服务端新建 room-service15FPS tick 循环读命令 → 执行逻辑 → 广播状态客户端只渲染不再参与逻辑计算帧同步 → 状态同步之前写的 Lockstep 代码几乎全部作废TSRPC 本身在这个阶段也踩了坑bigint 传不过去。TSRPC 内部用 JSON 序列化JSON 不支持 bigint。服务端用 bigint 做时间戳客户端收到的却是 {“n”:12345} 对象直接崩溃。最后把所有 bigint 换成 string 或 number 了事。更关键的问题是——我对代码的控制权在快速下降。之前辅助编程时出现多次「AI 拍脑袋修 bug」的问题我说位置不同步AI 不加日志排查而是直接在客户端加一行 position serverPosition掩盖了真正的根因。新阶段我决定换工具——引入 OpenClaw让它作为我的人机接口全面接管日常开发。这正是后续工作流进化的开端。P7 会完整展开状态同步方案的设计和坑。P8 大重构Monorepo 双服务 Logic 共享层— 2026年6月8日-6月12日状态同步 MVP 跑通后代码处于可运行但不可维护的状态。demos/new_basic2/ 目录里前端和逻辑搅在一起服务端代码也是一团乱麻。6月8号这天我和 OpenClaw 面对一个关键决策要不要真正重构架构重构意味着做几件事从 demos/ 目录移到真正的 packages/frontend/接管单机版的整个前端抽出 packages/logic/ 共享层——纯逻辑无任何框架依赖room-service 和 match-service 依赖 logic 包引入 IRenderer 接口抽象与 Three.js 解耦这个决策之前我犹豫了很长时间。单机版的前端代码量巨大Three.js React Ant Design MMD FBX代码耦合度极高。AI 以前在这个代码里做过几次修改每次至少改坏一两个地方。但我提出的方案是不改单机代码只做扩展。在单机代码基础上加多人渲染层、加多人逻辑层、加 IRenderer 接口。多人部分的代码全部新建不影响单机。重构过程很痛苦。遇到的坑循 环 依 赖logic 包引用 commonlib、frontend 引用 logic、room-service 引用 logic——tsconfig.json 的 paths 和 references 配置了好几轮才正确warm container 残留第一版 room-service 没有正确处理代次守卫旧服务的 tick loop 不清理新版启动后两个 loop 同时跑zip 深度问题之后部署 SCF 时才发现zip 里的目录扁平导致 …/…/…/logic/src 解析失败Schema 协议不同步改了 playerState 字段但忘了更新 serviceProto.ts数据传过去对不上为了彻底解决不可维护的问题我还引入了 ReScript 来重写 logic 包的逻辑层代码。ReScript 的类型系统够强OCaml 的血统编译成 JavaScript适合做游戏逻辑这种类型密集且容不得运行时错误的部分。但 ReScript 又带来了一整条依赖链的问题后来部署时差点被 rescript/runtime 的 ESM 问题搞崩溃。这是后话。P8 会详细展开这次大重构的全过程。P9 迭代开发Tick Loop 碰撞检测 状态管理演进— 2026年6月13日-6月29日重构后的代码结构清晰了可以真正进入产品迭代。这个过程大约持续了两周半按日迭代。每天的工作模式基本是兄弟下需求 → OpenClaw 调度 OpenCode 写代码 → 跑测试 → 验证 → 记录 → 收工。典型的功能点MMD 巨大娘接入把单机版的 MMD 模型白希.pmx引入多人版用 VMD 动画替换 FBX 动画。这里有一个经典坑MMD 的脚部 IK 在多人 Transform 下失效。排查了一下午最终发现是 meta3d 修改了 Three.js 的 updateMatrixWorld只更新左右足的骨骼矩阵其他骨骼的 matrixWorld 是 stale 值。修复方案是把 mesh 的 transform 归零后跑 IK再恢复 transform碰撞检测演进从 AABB 到 OBB 到 hull 碰撞精度逐步提升。每次改碰撞都加 BDD 测试最多 4 人限制添加玩家上限管理房主/Ts 等角色逻辑动画 Clip 冲突FBX 文件里所有动作 clip 都叫 “mixamo.com”。mixer.clipAction(“mixamo.com”) 永远返回第一个导致所有人动画相同。修复加载后重命名 clip退出清理beforeunload 发 disconnect服务端清理玩家状态。HMR 热更新时 WebSocket 断连导致玩家意外退房的问题折腾了好久这个阶段最有意思的是 OpenCode 的引入。之前 OpenClaw 一个人做调度 写代码 记忆 测试上下文膨胀严重平均每天 token 花费 100 多元——兄弟直接喊「太贵了」。6月12日我们做了调度分离OpenClaw 做调度层写代码的任务交给专门的 OpenCode使用 Go 套餐但实际的编码任务走的是 OpenClaw 调度的 Flash Free 免费模型。这个改变让月费降了 96%。P9 会展开迭代开发的具体流程和功能演进。P10 SCF 部署 — 2026年6月30日写再多代码不上线都是白搭。6月30日我们开始部署到腾讯云 SCFServerless Cloud Function。这一天是所有踩坑的大总结。如果说前阶段是「写代码难」这一天就是「让写过代码跑在别人的机器上更难」。一共踩了 6 个连环坑严格按出现顺序undici7 File is not defined — cloudbase/functions-framework 链式依赖 undici7需要 Node 20 的 File APISCF 只有 Node 18。解决去掉 framework直接启动 TSRPC HttpServerzip 深度补偿 — 扁平 zip 下 …/…/…/logic/src 解析到根目录外。解决zip 内加 svc/ 子目录scf_bootstrap 权限 — Windows 压缩不保留 x。解决.NET ZipArchive reflection 设 ExternalAttributesESM/CJS 冲突 — rescript/runtime/package.json 有 “type”:“module”。解决打包时删掉Module._load hook 失败 — 尝试拦截 Node 模块加载复杂且不稳定。解决直接注入 node_moduleswarm container 定时器残留 — 旧 tick loop 不清理。解决代次守卫自毁每个坑从发现到修复都经历了「症状 → 排查 → 根因 → 修复」的完整链路。最终我们写了一套自动化部署脚本 deploy-scf.js纯 Node.js 零依赖一行命令搞定打包 上传 配置 BDD 验证。P10 会完整展开这 6 个坑的逐坑故事。工作流进化6 步从手动到全自动AI 辅助编程单机→ OpenClaw 全自动 → 引入 OpenCode → TDD Skill 自动部署 E2E Specs(DeepSeek网页) (0代码指挥) (调度分离降本) (流程标准化闭环)Step 1AI 辅助编程单机开发阶段2026年5月之前这个工作流并非从多人版才开始。早在单机版「巨大娘的玩耍」的开发中我就一直在用 AI 辅助编程。基本模式是「人指挥 AI 写代码」的传统做法用 DeepSeek 网页版写需求 → 把代码贴进去让 AI 分析/改 → 手动复制粘贴到 VSCode。网页版我用来优化局部代码、实现算法、资料搜索、出设计方案Vs Code的Trae 插件我安装了用来做代码补全。痛点很明确大部分代码都是由我手写要在 DeepSeek 和 Vs Code 之间来回切换AI 的上下文都要由我从代码库中粘贴过去Trae虽然可以获得整个代码库的上下文但是太慢了而且不准确且免费版有限制。Step 2OpenClaw 全自动写代码零代码指挥阶段2026年6月上旬引入 OpenClaw 是一个转折点。OpenClaw 的本质是「一个能自己用工具干活的 AI」。我不再写代码只需告诉它架构设计、单机逻辑在哪、要改什么方向——它会自己去读单机代码、理解逻辑、写多人版本。当时的做法是我在浏览器的OpenClaw窗口WebChat中喊「小龙虾」OpenClaw 的昵称给它需求OpenClaw 读代码 → 分析 → 写代码 → 编译 → 报结果我再通过飞书反馈效果提升非常明显。以前一个简单功能至少半天有了 OpenClaw 半小时搞定。复杂功能以前要 2-3 天现在半天到一天。但新问题来了OpenClaw 做所有事情——调度、分析、写代码、跑测试、记忆管理——上下文里夹带大量资产token 消耗极高。平均每天 100 多元。兄弟说「这才几天快上千了」让我必须降本。Step 3引入 OpenCode 写代码调度分离2026年6月12日问题清楚了OpenClaw 负责调度层记记忆、管流程是它的强项但写代码这件事本身就是 token 大头——应该交给专门干这个的工具。方案很直接OpenClaw 调度 OpenCode 来写代码。做得更巧妙的一点是 OpenClaw 并不把全部上下文丢给 OpenCode 让它从头理解。OpenClaw 先分析需求、写好 Brief、标好要改的文件和改动要点再让 OpenCode 执行具体的改动。OpenCode 不关心项目全局和记忆只关心这个 brief 里的事。模型方面OpenClaw 调度 OpenCode 时使用它的 DeepSeek Flash Free 免费模型。每天有免费额度超出后自动回退到 Flash 模型——二者是同一个模型缓存命中率不受影响。而 OpenCode 本身使用的是 Go 套餐按量付费。这一改当天 token 费用从 100 降到个位数。兄弟表示满意。Step 4-6TDD 流程固化 Skill 标准化 自动部署 E2E 自测 Specs2026年6月中旬-7月初完整的 6 步工作流进化为AI 辅助编程 → OpenClaw 全自动 → OpenCode 引入 → TDD → Skill 固化 → 自动部署/E2E/Specs。后面几步是持续优化TDD 流程先写 BDD 测试让 bug 真实 RED → 再修复让测试 GREEN。这是代码质量的基础。任何没测试覆盖的代码都被视为「不存在的代码」Skill 固化把固定流程写成 SKILL.md。比如「部署流程 Skill」「E2E 测试 Skill」「记忆保存 Skill」。AI 严格执行不走样自动部署deploy-scf.js 一键部署部署前自动跑 BDD 验证E2E 自测 根因修复让 AI 自己复现 bug → 打日志定位 → 修复 → 验证。配合 Chromium CDP 实现 WebSocket 连接的验证Specs 体系先出规格再开工。Main Specs 概览Delta Specs 讲清楚这次改动什么、不动什么。兄弟确认后再干活每一步的详细过程在 P12-P16 工作流进化 篇展开。测试体系进化从零到三层的历程测试体系的建立不是一蹴而就的它跟整个项目的成熟度同步演进时间 测试状态 痛点 转折事件basic1 时期 (5月底) 没有测试全靠手动跑 修了 A bug → B bug 回归 → 再修 → 又回归 同一个 bug 一周内回归 3 次new_basic2 (6月初) 单元测试AI 自动写 单元测试 mock 太多测不到真实路径 AI mock 了 60 行代码实际测试只有 5 行大重构后 (6/9) BDD 集成测试用 Cucumber BDD 不经过真实服务端mock 了整个 Server 测试全通过但部署后挂了迭代开发 (6/10-6/28) 50 BDD 场景6 个模块 没有 E2E 环境位置跳变从日志看不出来 位置同步 bug 查了一周OpenCode 引入后 E2E 自测Playwright CDP AI 修 bug 不看日志拍脑袋修 一个 bug 修了 7 轮没修好Skill 固化后 自动化验收gts-acceptance 流程太长人忘了某步 部署前忘记重启 roomWS 断连每个阶段的测试故事分别在相应篇中展开P9 讲 BDD 在迭代中建立P14 讲 E2E 自测的引入P21 讲完整的测试策略体系。知识管理速览P17-P2913 个主题主题 一句话说清编码规则体系 基础/模块/流程三层规则 agent-context.md 宪法机制——不是一开始就有的是 AI 犯错后建起来的重构标准 审查清单——最高频 bug 是 End 逻辑重置每次都要专门检查Specs 体系 Main Specs Delta Specs 变更管理。Big change 必须有方案文档 兄弟确认决策记录 40 ADR 精选——还有反面决策选了后悔的比如锁步帧同步和 Immutable.js测试体系 单元 AI 自动集成半自动带 mock 问题E2E 手动辅助配合 PlaywrightToken 优化 月费从 3000 降到几百元的实操方案调度分离 缓存优化 上下文精简记忆管理 33 个锚点词检索协议。每天自动存档对话结束后强制总结Agent Brief 体验式反馈 技术 spec——给 AI 反馈「角色走路不自然」比「radius 设 360」更有效部署管理 SCF 双环境production/test双实例room1/room2全自动化工具链 23 个 Skill 全家桶从 gts-save-flow 到 gts-e2e-test 到 gts-deploy前端性能 SoA、帧管理、MMDFBX 双轨——更是个架构决策为 WebGPU 多线程铺路通信可靠性 WS 断连、重连、竞态、防御式编程。beforeunload 发 disconnect 修复了 HMR 断连问题反模式与设计模式 6 类坑 root cause 17 个可复用模式——我自己常犯的错也列进去了坑的速览清单
