Vibe Coding 多人游戏（十二）—— AI 辅助编程 → OpenClaw 全自动 → OpenCode 引入

第一阶段：AI 辅助编程（局部功能 + 代码补全）

多人版开发之前，单机版「巨大娘的玩耍」v1.0 就是用 AI 辅助编程写的。工作流很简单，也很有"打工感"：

  1. DeepSeek 网页版：做优化、算法实现等局部功能的处理
  2. Trae VSCode 插件：代码补全

说真的，最开始我还挺兴奋的。AI 帮我写碰撞检测算法、帮我生成动画系统的模板代码，听起来很美好对吧？

但实际的日常是：在网页和 IDE 之间来回切换，把大段的上下文粘贴进去，等 30 秒生成，复制回来，跑一下，报错，切回网页重新描述问题。

举个例子：我在写单机版的一个碰撞检测函数时，在网页上告诉 AI 我的需求、Three.js 的版本、场景结构——等它生成完后贴到 IDE，tsc 直接报错：某个 import 路径不对。我切回网页，告诉 AI 正确的 import 路径，再复制回来，发现这次的代码风格和上一段不一致——一个用了 as 类型断言，一个用了类型标注。虽然功能正确，但看着别扭。

更痛苦的是修 bug。 AI 生成的代码跑不起来，你需要在网页和 IDE 之间反复切，描述上下文的时间比 AI 生成代码的时间还长。而且切出去回来后，IDE 里的代码改了，网页那边的对话还停留在上一个版本——每次都要手动更新上下文。久而久之你会发现，你不是在用 AI 提高效率，你在给 AI 当翻译官。

好在 DeepSeek 网页版完全是免费的，没有 token 费用压力——只是体验上很折磨人。单机版完成后，我其实心里清楚：靠这种模式做多人版，工作量太大，光搬运上下文就能把人耗死。

第二阶段：OpenClaw 全自动（零代码指挥）

转折点出现在 2026 年 6 月初。我引入了 OpenClaw——一个 AI 网关/代理平台。

这个阶段的变化是根本性的。我不再打开任何编辑器，不再复制粘贴，不再在网页和 IDE 之间来回切。我的全部工作就是在 Webchat 界面中给 OpenClaw 发消息。

我（Webchat）→ OpenClaw（执行）

我只需要做一件事：描述目标。 飞书只是用来通知我任务完成——OpenClaw 做完事后给我发一条提醒。

例如，我发了一条消息：

"房间服务的架构是 packages/room-service/src/，参考 packages/logic/ 下的单机逻辑，把它转成多人版本，用 TSRPC 通信"

OpenClaw 会自动去读单机代码，理解业务逻辑，分析 State.ts 的状态数据结构，然后直接生成多人版本的 ApiPlayerReady.ts、ApiFinished.ts、Server.ts 等文件，再跑 tsc 检查编译——整个过程我完全不需要介入。

有几天我甚至感觉自己在度假。 我在 Webchat 中说一句"修复退房后 isEnterGame 标志位未重置"，十分钟后 OpenClaw 回复"已修复，提交了，部署已上线"。我去浏览器刷新一下，bug 真的没了。

但是，自由是有代价的：token 消耗太高了。

平均每天花费 100 多元。为什么？

因为 OpenClaw 在做"所有事情"——它要调度、要分析代码结构、要写代码、要跑测试、要管理记忆、要维护上下文。它的系统 prompt 里夹带了大量信息：项目结构、编码红线、记忆管理规则、通信协议说明……所有这些在每一次 tool call 中都占用 token。

一个典型的场景：我让 OpenClaw 修复一个 bug。它先是搜索记忆库找相关决策记录，然后读 agent-context.md 了解项目结构，再读相关源码文件（每个文件可能几十 KB），然后分析问题所在，生成修复代码，跑 tsc，跑测试——这一串操作下来，付费模型上下文中可能耗了上百万 token，而真正有用的"生成代码"只占其中一小部分。

每天 100+ 元持续了将近两周，我才意识到这个模式不可持续。

第三阶段：引入 OpenCode（调度层与编码层分离）

问题清楚了：OpenClaw 擅长做调度层（管记忆、管流程），但写代码应该交给专门干这个的工具。

2026 年 6 月 22 日，我做了一个关键的决策——引入 OpenCode，将调度和编码分离。

方案很简单：

你（决策）→ OpenClaw（调度） → OpenCode（编码）

OpenClaw 的角色变了。它不再自己写代码，而是：

  1. 收到需求
  2. 写一份 Brief（需求说明 + 上下文 + 红线）
  3. 调度 OpenCode 去执行
  4. 检查 OpenCode 的输出结果
  5. 如果编译失败或测试没过，把错误信息写入新的 Brief 再调度一次

OpenCode 的角色很纯粹：只写代码，只修 bug，只跑测试。 它的上下文里不需要记忆、不需要流程管理、不需要编码规则体系——它只需要 Brief 里的内容。所以 token 利用率极高。

这个决策的效果立竿见影。

维度 OpenClaw 全做 OpenClaw 调度 + OpenCode 编码
token 消耗 高（大量调度上下文） 低（OpenCode 只带任务上下文）
费用 ~100 元/天 大幅下降
灵活性 OpenClaw 模型可选范围小 OpenCode Go 套餐很便宜
记忆复用 ✅ OpenClaw 资产继续用 ✅ 调度时传给 OpenCode

切换后第一天，费用从 100+ 元骤降到 30 元左右。但这个数字不是稳稳的 10 元以下——因为 Go 套餐流量有限，超额后需要充值计费，而 flash free 模型的免费额度每天也就够跑几次。一段时间后稳定在每天 20 元左右。费用下降了 80%，效率反而提升了。

模型选择：Flash Free + Flash

OpenClaw 调度 OpenCode 使用 DeepSeek 模型，分为三个档次：

  • opencode-go/deepseek-v4-flash：日常编码（Go 套餐，流量有限，超额后计费）
  • opencode/deepseek-v4-flash-free：免费额度版本（OpenCode 的 Zen 套餐，每天有一定额度，日常小修小改用这个）
  • opencode-go/deepseek-v4-pro --variant max：架构设计、方案评审、顽固 bug

Flash 和 Flash Free 虽然是同一个模型、共享缓存，但归属不同套餐——flash-free 走 Zen 的免费额度，flash 走 Go 套餐的付费流量。超出免费额度后自动切到 Flash。

Pro 版本用得还挺多的——方案阶段几乎都要用 Pro。它分析跨度大、理解能力强，写 brief 时让它来审一遍能发现很多架构隐患。遇到 tsc 卡了两个循环还没过的顽固 bug，也请 Pro 出场。

费用变化

阶段 日费用 月费用 我的参与度
AI 辅助（网页+补全，单机版） 免费 免费 高（搬运工）
OpenClaw 全自动 ~100 元 ~3000 元 低（但贵）
OpenClaw + OpenCode ~20 元 ~600 元 低（划算）

费用不是线性的——OpenClaw 全自动阶段比网页版贵得多，因为所有 token 都由 OpenClaw 消耗。分层之后才真正降下来。

有意思的是，费用下降的同时，我的开发效率反而提升了。 之前 OpenClaw 自己写代码时，经常因为上下文太大而响应慢，或者因为 token 限制而截断。分给 OpenCode 后，OpenClaw 只需要几 KB 的调度上下文，瞬间完成调度，OpenCode 也只需要几十 KB 的编码上下文。双方都"身轻如燕"。

手动编程 vs AI 编程：在多人联网开发中的对比

在做这个多人版之前，我自己用 basic1 纯手写了 2 周的帧同步。那 2 周的体验和后来用 AI 开发的体验，差异不是"快一点"——是完全不同的工作模式。

调试

手动调试多人联网：开两个浏览器窗口，一个 Log 里看服务端输出，一个看客户端控制台。跑两步，位置不对，回 IDE 改代码，重跑。改一行代码到验证结果，来回 2-3 分钟。如果 bug 不规律（偶现、特定条件下才出现），手动调试基本靠猜——你觉得可能是 A，改一下跑跑看；不确定就去查日志，日志太多又看不过来。

AI 调试完全是另一个维度的：AI 可以拉日志、截图分析、自动跑 E2E —— 整个流程全是自动化的。

举个例子：发一句「玩家 B 加入后位置始终是 (0,0,0)」，OpenCode 先读 Game.ts 里的 onPlayerJoin 逻辑和 setPosition 调用链，发现是 initPlayerState 里忘记把 players 的初始位置写进 State 了。OpenCode 改了，跑 BDD 测试，通过，回一句话「已修复：initPlayerState 未记录 players 的初始位置」。

这是最基础的场景。复杂的场景下，AI 的调试能力更强：

  • 拉服务端日志：OpenCode 可以直接调用 gts-logs skill 拉取 SCF 上 room-service 或 match-service 的实时日志，不需要我手动登录控制台
  • 截图分析：用 Playwright 打开浏览器、连进游戏、截当前画面——然后自己看截图，分析位置偏移或者渲染异常
  • E2E 自动验证：写一个 Playwright scenario，模拟两个玩家加入游戏 → 移动 → 退出，全流程自动化。改完代码后一键跑 E2E，不需要人手动操作浏览器

最关键的是：这整个流程可以全自动循环。 AI 发现 bug → 拉日志分析 → 截图确认 → 改代码 → 跑 E2E 验证 → 没过再循环。没有人需要在中间按一下「继续」。

差别在哪？手动调试时你只能验证"自己已经怀疑的地方"。AI 调试会遍历所有可能路径——它看到的所有代码都是平等的嫌疑对象。

开发

手动开发：先想好完整的方案、画好架构图、写 API 定义、写数据模型、写函数签名，然后填实现。一句话形容——按图纸施工。

AI 开发：给了目标后，AI 自动读全部相关代码，生成完整实现。我开始时还不太适应——以前是"想清楚了再动手"，现在变成了"先动手，再让 AI 根据反馈调整"。这个模式在多人联网这个领域特别适合，因为多人架构太容易在"想"的阶段遗漏细节。

一个具体的例子：实现「玩家 A 进入房间后通知玩家 B」这个功能。手写的话我要定义新的 API type（MsgPlayerJoined），注册到 TSRPC 的服务端路由，在 ApiPlayerJoin.ts 里写服务器端通知逻辑，前端 MultiPlayerManager.ts 里加监听回调，测一下收到消息后的状态更新。这些步骤缺一不可，且每个步骤都可能踩坑（API 类型名字冲突、注册时 protocol 路径写错了、前端忘记 use 协议）。

AI 开发的话，它一次把全部步骤做了——我只需要说「玩家加入后其他玩家需要收到通知」。OpenCode 读了 ApiPlayerJoin.ts 发现没有通知逻辑，读了 MultiPlayerManager.ts 发现没有监听器，然后自动补全了一整套流程。

其它方面

维度 手动编程 AI 编程
进入门槛 高——要理解整个技术栈 低——说清楚目标就行
改大范围代码 心理负担大——改 10 个文件？下次吧 无所谓——说一句跑全程
一致性 容易手滑：if 写成了 fi、括号没闭合 100% 一致——知道模式就全程用
心智负担 高——要同时记着架构、协议、数据结构 低——只需要把当前目标说清楚
成就感 "我今天写了 300 行" "我今天指挥 AI 写了 3000 行"

最重要的一点

本来这次从 0 重写为多人联网我是下不了手的。通过 basic1 这个 demo，我知道要改的东西太多——服务的分层、状态的同步、协议的格式、前端的多人渲染……想想就头大。

但使用 OpenClaw 后，爱不释手，一晃一个月就过去了，每天都很有激情。我对别人说这是升维了！

以前：你是一个程序员在写代码。 现在：你是一个导演在指挥 AI 演员——你告诉 AI 你要什么效果，AI 去自动调灯光、走位、后期。你从演员变成了导演，不用操心中间细节，精力全放在"要做什么"上面。

这是根本性的变化。不是"我用 AI 写了更多代码"，而是"我不再写代码了"。

带来的文化变化

OpenCode 引入不仅省了钱，还改变了开发方式。

1. 不再怕重构

以前重构 = 手动改几十个文件。在多服务架构下（room-service、match-service、frontend 共享 logic 包），一个字段名的改动可能涉及 3 个包的十多个文件。以前我会犹豫"改不改"，现在重构 = 一句话描述目标，OpenCode 执行全程。

有一次我需要把 isEnterGame 改为 hasEnteredGame，这个字段在 Game.ts、State.ts、各种 Api 文件的协议定义里出现了 20 多处。我发了条消息："大重构：把 isEnterGame 改为 hasEnteredGame"，不到 3 分钟后 OpenCode 回复了："已修改全部 23 处引用，tsc 通过，BDD 测试全部通过。"

2. 小修小改不再烦躁

改一个类型定义要在 5 个文件里同步改？丢一句话，十秒完事。最典型的一次是调整 Config 接口：isDebug 从 boolean 变成 { enabled: boolean; showCollisionBoxes: boolean }。这个改动涉及 five 个 .ts 文件和三个 .feature 文件。以前我会想"等所有东西一起改再说"，现在直接一条消息搞定。

3. 代码质量反升

AI 对一致性很敏感——你告诉它"所有 API 都用这种模式"，它就真的在所有新代码里用同样的模式。三层编码规则体系（通用编码红线 + 项目特定规范 + 运行时规则）一旦设定，AI 100% 遵守。

最让我意外的是：AI 的代码比我的更少 bug。 因为 AI 不会"手滑"，不会忘记处理边界情况。只要你在 Brief 里写了"处理空数组情况"，它就真的会处理。

OpenCode 的局限性

当然不是万能药。以下几个坑我反复踩过：

1. 上下文窗口有限——大跨度重构需要额外注入。比如跨 3 个包的大重构，OpenCode 一次只能处理一个包。我的做法是拆成多次调度，每次聚焦一个范围。

2. 没有流程意识——OpenCode 不知道"改完要部署"、"部署完要验证"。它只执行当前 Brief，不操心上下文。这就是为什么需要 OpenClaw 在调度层管理流程。

3. 卡住不自知——同一个编译错误反复尝试是 OpenCode 最让我头疼的毛病。我见过它因为 tsconfig.json 里少了一个 exclude 导致 tsc 报错，然后以为是自己代码写错了，改了 6 次代码去绕开——实际上只需要修正 exclude 配置。

4. 需要明确的红线——如果不告诉 OpenCode "不改 node_modules 里的文件"，它遇到编译报错时真的会去改。不信你看看 node_modules/some-package/dist/index.js 的 git blame——有 3 次 commit 是我后来手动还原的 AI 改动。

这些局限性，就是我下一期要讲的内容——OpenClaw 调度层 + Skill 固化 + 自动部署，为 AI 编码建立完整的流程护栏。

下一篇：Vibe Coding 多人游戏（十三）—— OpenClaw 调度层 + Skill 固化 + 自动部署

posted @ 2026-07-08 11:38  杨元超  阅读(0)  评论(0)    收藏  举报