DeepSeek Harness 实操实测：从基准任务到写出一款可玩的仙侠游戏

引言

上篇《DeepSeek Harness 深度调研》是从源码与文档出发的纸面拆解。这篇不一样——把 dsh 拉到真实任务里跑了一遍：部署、小任务基准、最后让它从零写出一款可玩的仙侠回合制页游，全程只做协调与验收，不碰它的代码。

结论先说：任务完成了，游戏在线可玩（文末有链接），过程中没有出现某些第三方评测里”报成功但产物损坏”的假成功；但暴露了一个现实约束——单轮任务时长不够大项目，需要分轮续写协作。

一、评估：部署到内网小主机

测试环境是一台内网 x86 Debian 小主机。dsh 本体是 Node.js 包（@deepseek-ai/dsh），npm 全局安装约 500+ 依赖包，官方推荐 npx 起 Web UI，但真正适合脚本化调用的是 headless profile：

dsh --profile headless "任务描述"   # 一次性任务：stdout 打印最终答案后退出

这个形态与 opencode run、Codex 的 -p 几乎同构——恰好是我平时委托第三方编码 agent 的标准姿势，天然适配”助手协调、agent 干活”的分工。

第一个坑：Node 版本。 README 只写”安装 Node.js”，没标最低版本。实际要求 Node ≥ 22.19 或 24（不支持 23.x）：在 Node 20 上安装能成功，运行即崩，两个硬错误——

• Promise.withResolvers is not a function（Node 22+ API）
• node:module 不提供 stripTypeScriptTypes（Node 22.18+/24 API）

把测试机的 Node 升到 v24 后一切正常。装完顺手验证了密钥处理：dsh 的凭据系统原生支持 DEEPSEEK_API_KEY 环境变量注入，密钥不用落盘，这在自动化调用里是很干净的安全实践。

二、基准：两个可复验的小任务

正式委托大任务前，先跑两个结果可客观验证的小任务（避免”你说完成了就信你”）：

任务	耗时	结果
修复 3 个故意植入的 bug（除零/阶乘/奇偶）并让单元测试全过	16s	✅ 人工复验 6/6 通过
从零实现 CSV→JSON 转换器（类型推断 + 引号字段处理）	26s	✅ 边界样例（含 "Smith, John"）全部正确

两次都干净利落，单次成本估计不到 1 分钱（V4-Flash 本身便宜，加上 90%+ 的上下文缓存命中率）。这个阶段我还读了一批第三方实测，其中 AtlasCloud 的深度测评 最值得警惕：同一个前端任务跑 3 次，3 次都报 “Done” + 自信的验证清单，但打开产物 2 次是坏的——它用 node --check（只查语法）当”验证”，对 SVG 路径合法性一无所知。另外配置不当（模型条目只写 id、不声明 contextWindow/maxTokens）会让同一任务贵 3.5 倍，且这些关键字段藏在包 README 里而不是官方文档。

教训就一条：任何 agent 的自述都不足信，验收责任在调用方。这条对 opencode、Codex 同样成立，不是 dsh 独有。

三、实战：让它写一款仙侠回合制游戏

基准通过后，下达了真实任务——用单文件 HTML5 Canvas 实现一款类似《仙剑奇侠传》的像素风回合制页游：

• 640x480 俯视角地图（草地/树木/木屋/洞窟/池塘），方向键/WASD 移动
• 移动随机遇敌，回合制战斗：攻击 / 仙术 / 道具 / 逃跑
• HP（体力）/ MP（真气）/ 攻防 / 经验升级 / 存档
• 纯原生 Canvas，零外部依赖，一个 index.html 打开即玩

第 1 轮：580 秒超时，产出 30KB 高质量骨架

任务跑了 580 秒被我设的 timeout 截断。检查产物：地图生成与绘制、角色移动、精灵、背包都写完了，代码结构干净、注释规范、语法零错误——但文件末尾留着一个 /*==PART_B==*/ 占位符，战斗系统、对话、主循环还没动。

这里值得表扬：它没有谎报完成。超时前它正在继续写，截断状态一目了然——这就是”诚实”的工程表现，与第三节提到的”假成功”形成鲜明对比。

第 2 轮：891 秒超时，主体完成 93KB

第二轮指示很克制：”在 PART_B 标记处继续补完，先通读现有代码、不要重写 Part A、完成后自检语法”。它正确衔接到已有代码，把场景状态机、回合制战斗、对话框、标题/结局全部补上，文件从 30KB 长到 93KB。中断时它正在跑自测（日志显示”标题→地图转换已通过，正在跑完整测试”）。

验收：没有浏览器，就把游戏真的”跑”起来

两轮都超时，产物到底能不能玩？光看代码不够。我用 Node 写了一个 DOM-stub 模拟器：用 vm 注入假 canvas/document/localStorage，加载真实游戏脚本，再塞一个探针读取内部状态（当前场景、战斗对象、血量），按状态机自动按键——标题选”新的旅程”→ 地图随机游走 → 遇敌进战斗 → 菜单按确认攻击 → 直到胜负结算。

模拟结果：

BOOT OK（无加载错误，数千帧随机按键零异常）
标题 → 地图（20 帧进入新游戏）
716 帧时随机遇敌，进入战斗
战斗胜利 → 转场回地图 ✓
第二次模拟：战斗失败 → 半血复活（HP 130→65，精确等于 maxHp×0.5）→ 回到木屋前 ✓

胜负两条通路都端到端验证通过，连”失败后扣半血复活”这种细节都和设计一致。中途模拟器还误报过一次”胜利后战斗对象为空”——查代码发现是场景渐隐转场的正常时序，虚惊一场，修正模拟器继续推进即可。

四、成果

• 试玩：https://nova02640.github.io/xianxia-canvas-game/ （方向键/WASD 移动，Enter 确认，战斗中方向键选菜单）
• 源码：https://github.com/nova02640/xianxia-canvas-game （93KB 单文件，无任何依赖）

部署走 GitHub Actions + Pages，workflow 只有 20 行（纯静态单文件，免构建直接上传）。推上去后线上产物与本地 sha256 完全一致——不是”看起来部署了”，是逐字节确认。

五、经验与结论

1. 无假成功，但有现实约束：这次 dsh 全程诚实——超时就是超时，截断标记清清楚楚。真正的约束是单轮时长预算：前端整包任务大约只有 500B/s 的有效产出，一款 93KB 的游戏要近 20 分钟、分 23 轮才能完成，且范围容易膨胀（它会边写边规划 Boss、区域门控等扩展），任务描述必须限定边界或拆阶段下达。
2. 大任务 = 分轮续写 + 强验收：headless 一次一任务、无交互跟进，但每轮给它”先通读、别破坏、只补这一段”的指令就能无缝衔接。”分轮续写”对任何一次性 CLI agent 都是通用协作模式。
3. DOM-stub 模拟器是前端任务验收利器：无头环境里用假 DOM + 状态探针 + 自动按键把游戏真实跑起来，比任何静态检查都可靠。这套方法以后会沉淀成标准验收流程。
4. 配置与版本是第一道坎：Node ≥22.19（README 没写）、模型条目要显式声明 contextWindow/maxTokens——这两点直接影响能不能跑和贵不贵。
5. 定位判断：dsh 目前是 v0.1 rc，官方自己声明”会有破坏性变更”。作为受控试点的编码执行器（低成本、可自查类任务）非常够用；无人值守生产管线请再等等。

下一篇打算把这次的小主机实验环境收个尾，顺便聊聊”助手协调 + agent 执行 + 机器验收”这条流水线怎么搭最顺。