← #792

让 AI 来玩我自己的游戏：构建 agentic 测试夹具辅助 playtesting

查看原文 HN 讨论

文章摘要

作者（HN 上 ID 为 fishtoaster）独立开发的游戏叫 Crossword Dungeon，是一款把字谜跟 RPG 地下城结合的回合制文字冒险——纵横字谜的每个字母对应一个房间，房间里可能藏着宝藏、陷阱或怪物，解开字谜则会”升级”相邻房间的难度，把”填字”和”练级”这两种机制变成相互制约的设计。

问题：他用 AI 辅助开发的工作流已经很顺，但每次迭代都要花大量时间手动 playtest——单元测试通过 ≠ 手感对、状态机正确、边界条件不出 bug。他决定把”playtest”本身也交给 AI agent。

Agent 架构（关键工程决策）：

• 不动游戏源码。在游戏外面包一层 Node.js HTTP 服务（”playtest 服务器”），暴露：启动 / 读快照 / 发按键 / 创建自定义 fixture 这几类工具。
• 观察空间是文本：渲染出 ASCII 地下城网格、紧凑地图视图（房间-走廊数据结构）、英雄状态/遭遇/字谜线索面板等多个结构化文本块。完全跳过截图——回合制+文字游戏的特性让这条路成立。
• 游戏完全无感知：游戏逻辑、事件流、状态机不变，只是多了一个”渲染器”——这意味着 AI 看到的状态和真实玩家看到的状态等价。

模型与成本：使用 Claude Code v2.1.119 + Sonnet 4.6（Claude Pro 订阅），最长一次 playtest 会话约 120k–135k tokens（200k 上限）。一次完整的”5 个新敌人 + 完整 playtest”里程碑用时 12 分 34 秒。

找到的真实 bug 案例（这是最有说服力的部分）：

• 笼陷阱状态未清除：玩家解开字谜后房间标记为”已完成”，但 state.caged 没被清空——表现是房间已通关却仍然不能离开。AI 通过尝试不同动作复现并定位修复点。
• 还顺便测了：盗贼怪物的偷金币机制（验证猜对单词时不掉钱）、史莱姆在相邻房间分裂、沉睡哨兵 5 回合内未被击败会觉醒并伤害翻倍等。

AI vs 人类测试的边界：

• AI 强于：”照着 spec 验证新功能”和”系统化跑过 happy path + 多个分支”，且能在自定义 fixture 上精准复现 edge case；现代 LLM 在解纵横字谜上极强，所以”探索游戏”这一步特别快。
• AI 弱于：”开放式发现意料之外的 bug”（比如尝试从墙后进入锁着的房间）和”判断游戏好不好玩”——平衡感、心流、节奏这种主观维度仍然要人。
• 最实用的工作流是：作者人工 playtest 30 分钟收集主观印象 → AI 系统化验证作者指出的具体功能与 bug → AI 把测试用例固化为 fixture。这是”人定方向，AI 做地毯式覆盖”。

踩过的坑：

• 自动化截图路线被否，因为成本高、信号噪声比低；文字接口对回合制游戏是更好的选择。
• AI 需要先教——作者写了一份”如何使用 playtest 服务器”的 skill 文档，否则 agent 容易自己重新发明工具。
• 长 multi-turn 对话里 AI 会丢游戏状态记忆——靠 fixture 系统给每次测试一个明确的初始状态。

升级路径：

最初：让 AI 自由探索游戏（信号弱）
→ 中期：AI 自己设计 fixture（开始对路）
→ 终态：分配 milestone，要求每个 feature 完成前自我 playtest 验证（自主质量守护）

核心结论：对回合制 + 文字密集的游戏，agentic playtest 是当下立即可落地的辅助手段；对实时游戏、大状态空间游戏，路径还不清楚（评论里也有相关讨论）。

HN 评论精华

• jschomay：”你考虑过别用 LLM 吗？” 他自己做的是另一款游戏，逻辑完全确定（除玩家输入外无随机），所以他把渲染和逻辑彻底拆开，跑 Monte-Carlo 风格的 headless 模拟——一台机器并行跑几百场 5 分钟的游戏只要几秒，把 AI 参数调到”完美”。这是不依赖 LLM 的另一条路：传统大规模仿真+确定性回放。作者回应说自己也想过这条路，但 LLM 的强项在”按规范验证新功能”和”找意料之外的 bug”，两条路其实互补。
• deadbabe（CRPG 独立开发者） 提了三个尖锐的问题：是否需要为已经文字化的游戏再做一层 harness（因为他用方向键+回车做菜单选择）、prompt 里怎么写让反馈更有用、有什么死胡同要避免。fishtoaster 回复：1) 文字接口仍有价值，因为可以把状态用更 AI 友好的方式压缩；2) 写一份”playtester 通常会做什么”的 skill 文档比写自由 prompt 有用；3) “让 AI 漫无目的地发现 bug” 效果不好，”指着具体 feature 让它验证”效果最好——这是工程上最重要的一条经验。
• justindz（另一种思路）：他的做法不是让 LLM 直接玩，而是让 LLM 写一个确定性的机器人系统去玩——bot 行为是确定的，调试和回放都可控；LLM 用来快速迭代 bot 决策剖面（”让 bot 在 10 步内到达 3 号房间”）。这是把 LLM 当代码生成器而不是 player。
• StephenAshmore：用 Godot + Copilot CLI + Godot MCP Pro 做了一样的事——”我睡觉时它跑通了我让它写的功能并修了几个回归 bug”。
• jongalloway2：在自己的游戏里加了 E2E 测试 + 截图，于是可以下达”睡觉前实现并自验”这种长任务。
• Jabrov（实时物理游戏）：用 MCP 测一款行星弹弓游戏失败——AI 截一张图、再截下一张，中间玩家已经飞出地图。后来他给 AI 同时开了”代码级时间步进”和”window.game 浏览器 API”两个接口，物理 bug 用前者、动画 UI 用后者。但仍然经常出现 “I tested it and it works perfectly!” 而玩家其实卡在行星里——实时游戏的 agentic test 远比回合制困难。fishtoaster 回应里提到 Bret Victor 的 Inventing on Principles “把时间塌缩成静态轨迹”那段演讲，认为也许是物理游戏 agentic test 的可能方向。
• nunu.ai 团队：他们做了 2 年类似的事，最初也走文字接口，最后转去做”纯像素 + 操作系统输入”的通用方案，目前在移动平台上线。说明文字接口虽然好用，但只适用一小部分游戏类型。
• ZeidJ（强烈反对者）：”我不想玩一个被 AI playtest（很可能也由 AI 搭建）的游戏。游戏需要一种 AI 永远抓不到的微妙感觉：好玩。” 这是评论区最尖锐的反对声音，文章作者也在文中承认平衡感和”游戏感觉”仍然需要人。
• MUD/MOO 的副作用：评论扩展到一个有趣方向——把 MCP 接到 MUD 上，让 Claude 在不同窗口里互相协作扩建一个虚拟世界。Sohcahtoa82 说他用 evennia + Claude 几小时内造出了带教程、战斗的完整虚拟世界。这是 agentic playtest 思路的”反向延展”：AI 不只是测试游戏，也开始生产游戏世界。