Vibe Coding 多人游戏（三十）—— 给下一个 Vibe Coder 的起步指南

最佳起步路径（5 步，约 2 周）

Step 1：先跑通 Demo（1 天）

用 Three.js + WebSocket，做一个最简单的 Demo——两个方块在同一个场景里移动。不用 monorepo、不用 TSRPC、不用任何工程化。30 行服务端代码 + 50 行前端代码。

我这步踩了个坑：一开始想用 Node.js 的 ws 库，发现要自己写序列化、路由、错误处理——写了 200 行什么都没干。后来改用 TSRPC，50 行就搞定了。但这是第二天的故事，第一天我确实花了 200 行在"架架子"上。

目标是：看到"网络能通"。 不追求任何不是"网络通"的东西。演示时就是两个方块，一个是你动的，另一个是从 WebSocket 收到数据后动的。看到这个效果，你就可以进入下一步了。

Step 2：状态同步（3 天）

不要帧同步。直接上状态同步——服务端权威，全量状态下发。

你可能会踩这几个坑：

1. 浮点数精度问题：A 机器计算的和 B 机器计算的不一样 → 解决方案：服务端算，客户端只展示
2. 竞态：两个操作到达顺序不对 → 解决方案：帧号打包 + 排序
3. 断连：WebSocket 断连后重连 → 解决方案：指数退避心跳

每个坑都是值的学习机会。但如果你看了本系列前面的文章，这些坑你都可以跳过——直接用我们已经验证过的方案。

Step 3：工程化（1 周）

当代码超过 1000 行时，进入 monorepo 阶段。分 packages、统一构建、共享类型。同步引入 TSRPC 或其他 RPC 框架。

为什么是 1000 行？因为这个线是人脑和工程之间的分界线。1000 行以下，你一个人能记住所有代码在哪里。1000 行以上，你需要工具帮你管理了——构建、测试、部署。

Monorepo 的具体结构可以抄 GTS-Play 的：

packages/
├── frontend/         # React 前端
├── logic/            # 游戏逻辑（纯函数共享）
├── room-service/     # 房间服务（WebSocket, 4003）
├── match-service/    # 匹配服务（HTTP, 3000）
└── backend/          # 后端

Step 4：部署上线（3 天）

WebSocket 游戏的服务端部署和普通 Web 应用不一样。需要：

• 支持长连接的平台（SCF / AWS Lambda + WebSocket Gateway）
• 心跳保活（防止 warm container 回收）
• 冷启动优化（控制 bundle 大小、减少依赖）
• 日志监控（排查 online bug）

我最开始在部署阶段花了整整一周，踩了 6 个连环坑（P10 详细讲了）。如果重来一次，我会这样做：

1. 第一天：部署一个最简单的"Hello World" WebSocket 服务，确认能连
2. 第二天：逐步加入游戏逻辑，每次部署都验证
3. 第三天：配好日志和监控

不要在第一天就塞所有功能，否则出问题你根本不知道是部署的问题还是功能的问题。

Step 5：自动化（持续，不是终点）

引入 AI 工具（OpenCode / OpenClaw）做编码和调度。写 Skill 固化流程，从手动到半自动到全自动。

自动化不是一步到位的。GTS-Play 的自动化经历了三个阶段：

1. 手动阶段：兄弟手动写 Brief → AI 跑 → 兄弟手动检查 → 一天 4-5 个任务
2. 半自动阶段：Skill 处理常见任务 → AI 自动选择 Skill → 兄弟确认 → 一天 10-12 个任务
3. 全自动阶段：入口检查 + 模型选择 + 引用规范 → AI 全自动执行 → 一天 15+ 个任务

我现在的状态是第 3 阶段。每天打开电脑，AI 已经完成了前一天遗留的任务，新的任务排队等兄弟确认。而且 90% 的 bug 修复都在 15 分钟内完成。

---

技术栈推荐

模块	推荐	理由
渲染	Three.js	WebGPU 就绪，生态成熟，AI 训练数据丰富
通信	WebSocket	实时性足够，浏览器原生支持，AI 理解度高
RPC 框架	TSRPC 或 ws	全链路类型安全，AI 容易写对
状态管理	SoA TypedArray	性能好、WebGPU 就绪、AI 可读
部署	SCF / AWS Lambda	Serverless，按量付费，个人项目几乎不花钱
AI 调度	OpenClaw	Skill 系统，流程可执行，支持多模型
AI 编码	OpenCode	终端 AI Agent，上下文窗口大，付费模型 1M context

选择标准不是"谁最好"，而是"AI 最容易理解"。Three.js 和 TSRPC 都有大量的在线文档和 AI 训练数据——AI 写它们的代码时出错率最低。

WebSocket 也符合这个标准——浏览器原生 API，不需要额外引入库。TSRPC 在 WebSocket 之上提供了类型安全，减少了 AI 出错的可能。

---

从 Builder 到 Conductor

整个系列想传达的核心观点是：

你不需要成为编码专家才能做多人游戏。但你需要成为"指挥者"——知道做什么、怎么分步、怎么验收。

传统多人游戏开发需要懂网络编程、帧同步、回滚、防作弊。每一个都需要 3-5 年的经验。在 Vibe Coding 环境下，这些都不需要——状态同步、纯函数共享层、开闭原则、隔离部署，用更简单的方式做到了同样的事情。

AI 负责"怎么做"，你负责"做什么"。

这也是 I am 从 Builder（建造者）到 Conductor（指挥者）的转变。第一天我亲手写代码，每天写 200-300 行，bug 率 10%。一个月后我指挥 AI 写代码，每天产出 2000+ 行，bug 率 5%——不是因为我变强了，而是因为 AI 写出了我写不出来的代码。

---

这个系列的延伸阅读

如果你的时间只够看几篇，这 5 篇是你最需要读的：

篇	为什么看
P5 实战总览	一张图看完整个系列——从哪里开始、在哪里停下
P6 Phase 1：帧同步	坑怎么踩的，为什么放弃——让 AI 做帧同步是灾难的开始
P7 Phase 2：状态同步	核心架构，最重要的一篇——多人游戏正确的方向
P10 SCF 部署	部署坑最密集的总结——6 个连环坑，每个都配了自动化规则
P22 Token 优化	月费从 3000 降到几百元的实操——省下的钱够你请朋友喝咖啡了
P31 Loop Engineering	理解五个积木和三个差距——找到进一步优化工作流的方向

---

最后的建议

我开发 GTS-Play 最大的感受是："一个人做多人游戏"不是不可能，而是"一个人 + AI 协作"才成为可能。

没有 AI，我不可能在 30 天里写完 16 个 Skill、300+ BDD 测试、40+ ADR、部署到生产环境。没有 AI，写一个多人游戏（即使是最简单的 PvE 踩踏游戏）也需要 3-5 个人的团队干 3 个月。

AI 让 Vibe Coding 做多人游戏成为可能。而本系列 32 篇文章，就是"AI 做多人游戏"的完整路线图。

最后一句话：

Vibe Coding 多人游戏（零）—— 目录 ← 从这里开始

用 AI 做多人游戏，一个人就够了

系列继续：

（零）目录 →

Vibe Coding 多人游戏（三十一）—— Loop Engineering：我们的实践与改进方向