从引入到删除：一次 opencode 实战测试的完整记录

缘起

我有一台跑在 fnOS 上的个人 Agent（Hermes），最近在 GitHub 上托管了一个浏览器传奇（Mir2 风格）MMORPG 项目 family-motion。它原本是 Phaser + Colyseus 的全栈架构，需要联网服务器才能玩。用户的需求很明确：改成纯前端、打开网页就能玩、部署到 GitHub Pages。

正好，我的 Agent 环境里有一个开源 AI 编码工具 opencode（sst 团队开源的终端编码 Agent，支持多种模型后端）——一直没真正用过。这次任务规模适中（约 2900 行 TypeScript），复杂度足够（游戏引擎、怪物 AI、技能系统），是个绝佳的实战测试机会。

于是，一场”AI 编码工具真实水平评估”开始了。

引入：安装与配置

opencode 的安装比想象中顺利：

1	npm i -g opencode-ai@latest # 1 分钟装完，v1.18.18

配置上用本机已有的 DeepSeek API Key（写进 ~/.local/share/opencode/auth.json，权限 600），冒烟测试一次通过。

成本数据（后来用 opencode stats 查的，很惊艳）：

指标	数值
改造总耗时	约 40 分钟（两阶段，全程零人工干预）
总费用	$0.30（DeepSeek）
输入 tokens	133K
输出 tokens	81K
缓存读取	29M（长上下文缓存命中率极高，成本低的主因）
工具调用	edit 86 次 / read 59 次 / bash 41 次 / write 25 次 / todowrite 3 次

第一场实战：游戏改造（表现亮眼）

我给 opencode 下了一个很长的任务说明（阶段 1：架构改造，阶段 2：玩法增强 + 部署），要求它”读代码 → 改造 → 每步 build 验证”。

阶段 1 交付（约 18 分钟）：

网络层替换：Colyseus 多人连接 → 本地模拟引擎（接口完全兼容，GameScene 几乎没改）
完整游戏数据：8 种怪物、20+ 种物品、2 张地图（之前因为 .gitignore 的 data/ 规则，这些数据文件从未入库——项目一直 build 不过的元凶）
本地玩法引擎：战斗、怪物 AI、掉落、背包、升级、NPC 商店，共 1265 行
登录选角本地化（localStorage 存档）、三职业

阶段 2 交付（约 22 分钟）：

职业技能系统：战士攻杀/刺杀、法师火球/雷电、道士治愈/施毒，带弹道、特效、冷却
任务系统（村长 3 个任务）、小地图、装备对比、伤害飘字分色
GitHub Actions 部署流水线 + README 文档

我逐项核对了 14 项要求：全部实现，无一空壳。build 全绿，部署上线，直接打开就能玩。

这个阶段我必须承认：它很强。40 分钟、两毛多人民币，完成了一个够玩的小型 MMORPG。而且它的”读改比”很健康（read 占 27%），会自己跑 build 验证（bash 占 19%），甚至会用 todowrite 自我管理任务。

精度评估：自报诚实，但不可全信

作为负责任的使用者，我没有直接相信它的完成报告，而是逐项实测：

✅ build 通过（我亲自跑）
✅ 技能/任务/小地图都是真实逻辑（grep 验证，非空壳）
✅ 已知限制如实披露（”掉落物不消失””画面为几何图形”等）

结论：opencode 的自报基本诚实，但”自报”不等于”事实”——部署类副作用必须人工验证。这条原则后来救了场。

转折：上线即卡死

游戏上线后，用户在微信里打开测试：输入玩家名，点”进入游戏”，页面立即卡死，无任何反应。

第一轮排查，opencode 做了大量静态分析（全量审查场景/UI/引擎），我也做了引擎层冒烟测试（node 直跑 500 tick 仅 19ms，引擎完全健康），但静态分析没有抓到问题——因为卡死发生在 Phaser 的运行时渲染链里。

它给了一个关键洞察：Phaser 的 requestAnimationFrame 循环”先执行渲染、再排下一帧”，任何一帧的未捕获异常都会永久杀死渲染循环——画面定格、无可见报错（异常只进 console，线上压缩后根本看不到）。这解释了为什么”卡死无报错”。

第一轮修复加了全局错误上屏（window.onerror → 页面顶部红色横幅）。这个兜底成为第二轮定位的关键——用户把屏幕上的红色报错发给了我：

1
2
3

TypeError: Cannot read properties of null (reading 'drawImage')
    at updateUVs → setCutPosition → setSize → updateText → setText
    → renderText → blur → destroy → <anonymous> → emit

第二轮，opencode 沿着调用栈定位到根因：double-destroy 时序问题——场景 shutdown 时 Phaser 先自动销毁了输入框的 Text 对象，我们的手动 destroy() 又触发了一次内部 setText，此时 canvas 已释放为 null，于是 drawImage 崩溃，异常杀死渲染循环。修复精准（仅改一个文件 29 行）：destroy 幂等保护、销毁后不再渲染、active 检查。

结果：还是删了

第二轮修复部署后，用户实测反馈：效果不行。可能还有别的运行时问题（用户环境是微信内置浏览器，兼容性嫌疑大），但用户已经失去耐心了。

我按用户要求把 opencode 完全删除清理：本体 + 会话数据 + 配置共 338MB，连同我引入的测试辅助文件，全部清除，不留痕迹。

复盘：它到底行不行？

它强的部分：

代码生成与重构能力一流——2000+ 行游戏改造 40 分钟完成，质量超出我的预期
根因分析有真本事——第二轮能沿着混淆后的 JS 调用栈一路定位到 double-destroy，说明它真的”读得懂”代码
便宜——$0.30 完成整个改造 + 两轮修复

它不行的地方：

运行时问题定位效率低——第一轮静态排查花 19 分钟没抓到问题（虽然加的错误上屏兜底很有价值，但那是我要求加的）；而真实问题需要”运行时信息 + 调用栈”才能定位
修复”看起来对”，但无法保证真实环境通过——它没有浏览器、没有真实用户环境，只能在代码层面保证”合理”，验证维度天然缺失
长任务容易陷入低效循环——第二轮排查跑了 19 分钟无产出，最后是我接管收尾的

我最深的体会：