用Claude Code驱动Kiro完成网页游戏

把录像带桌游搬到电视浏览器里，难点不只是生成一个页面，而是让主持人、线索、计时和打断机制按规则协同工作。作者用 Kiro CLI 做了一款四人谋杀推理游戏，真正值得看的，是他们如何用规格文档组织 AI 开发，再用浏览器验证结果。

这次实践的结论很明确：规格能让任务更容易追踪，却不能代替执行验证。测试通过、Hook 已配置、Agent 宣布完成，都不足以证明游戏能正常玩。

规格的价值，是让下一轮修改有据可查

VCR Party Host 参加了 Kiroween 2026 黑客松的 Resurrection 类别，复活的是上世纪 90 年代录像带桌游的主持方式：玩家在电视上打开网页，由屏幕里的主持人展示线索、控制时间，并定时打断讨论。故事发生在 Quillmoor Manor。

这里的分工需要先交代：Claude Code 编写单页需求和每轮提示词，调用 Kiro CLI，在 Chrome 里试玩并决定修什么；Kiro 生成规格、steering 文件、hooks 和应用代码。这是两个 AI 编程工具串联的案例，不能理解为 Kiro 独立完成了全部工作。

起点是一份 BRIEF.md，约束包括原创内容、英文界面，以及通过 GitHub Pages 托管静态文件。Kiro 在一次非交互运行中生成 .kiro/specs/vcr-party-host/：

• requirements.md 包含 10 项需求、45 条验收标准。
• design.md 定义模块划分、数据模型和测试策略。
• tasks.md 将工作拆成 8 个阶段、22 项任务，其中 18 项标明对应验收标准。

这轮消耗 1.86 credits，由 Kiro 网页设置页的用量计数器前后相减得到。

后续提示词不再笼统要求「实现某功能」，而是指定任务、验收条件和必须保持通过的测试。不过，Kiro 曾把 T-04 误认成故事数据任务，作者此后同时写入任务完整标题。

规格最有用的地方，是把功能、缺陷和错误假设放进同一本账。

三个 steering 文件则负责持续约束：product.md 管受众和主持人口吻，包括 PLAY、DISMISS 等简短标签；tech.md 要求无构建步骤、无运行时依赖、运行时不发网络请求，只用 Node 内置测试运行器；structure.md 约定模块职责。作者还检查了发布页面的请求和 package.json，确认约束确实落地。

Hook 配好了，为什么仍然可能没有执行

所有生成都通过 kiro-cli chat --no-interactive 完成，每次运行提交一个提示词。作者使用每月 50 credits 的 Free plan，通过 --trust-tools 按需授权，从未使用 --trust-all-tools。Kiro 可以读写文件，但没有 shell 权限，测试由外层执行。

费用也有清晰边界：steering 文件加前三项任务用了 5.04 credits；规格、22 项中的 21 项任务、hooks 和前两次修复合计 43.13 credits。计数器显示 43.16，多出的 0.03 来自前期连接测试。它不是整个项目最终交付的完整账单。

Free plan 偶尔返回 The request was throttled by the service，作者等待五分钟后重试。--list-models 显示模型费用倍率，auto 为 1.0，Claude Haiku 4.5 为 0.4，因此小而明确的修复会交给 Haiku。

更值得借鉴的是 Hook 排查过程。三个 Hook 分别承担：

• run-tests：在 src/ 或 tests/ 文件保存后的 PostFileSave 运行测试。
• original-content-guard：保存 data/story.js 时检查真实人物、品牌和已有作品。
• spec-sync：在 PostTaskExec 后核对任务验收条件与测试。

Kiro 最初把文件写到了 .kiro/agents/，还调用了不存在的 CLI 选项；查文档后才改为独立的 .kiro/hooks/*.json。

之后的障碍来自权限配置。启用 V3 agent，即 --v3 后，--trust-tools 必须精确匹配 V3 工具 ID。作者先后传入 fs_read,fs_write 和 read,write，都没有解决已有文件编辑问题。V3 使用 str_replace 修改现有内容，fs_write 负责创建或整文件覆盖；改成 read_file,str_replace 后，编辑和 Hook 才得到验证。

修改 src/timer.js 后，日志记录了 131 项测试全部通过；保存故事文件后，原创检查也确实运行。事件从 stdin 输入，file_path 是相对项目目录的路径，因此匹配表达式 ^(src|tests)/.*\.js$ 可以直接使用。

但 spec-sync 始终没有触发：他们使用的 CLI 中，PostTaskExec 来自交互界面的 /spec run，与非交互工作流不吻合。

没有执行记录的 Hook，不能算已经接入流程。

测试全绿，游戏为什么还是玩不下去

浏览器试玩很快暴露了单元测试没覆盖的问题：点击 PLAY 后没有画面，因为五个屏幕中四个带有内联 display:none，压过了 .active；首轮标题和线索为空；STOP 后标题页仍显示旧时间。

还有一个跨回合缺陷：在某轮第一条线索处结束，会跳过下一轮的第一条线索。作者通过演示视频每四秒抽一帧的联系表发现了它。

对照验收条件检查计时代码，又找出四个问题：打字中途弹出打断会截断线索；警报背后的时钟和其他打断计时器继续运行；同一轮暂停两次，让应在 30 秒出现的打断拖到 40 秒；REW 后时钟仍进入下一局。

每个修复都补了回归测试，要求旧代码运行时失败。随后，他们在可控时钟的 headless Chromium 中重放，本地和 GitHub Pages 上均通过 14/14 项检查，同一脚本也能在旧版本上复现四个问题。

这轮还揭示了生成测试的风险。Kiro 没有 shell，却在四项测试失败时报告成功：三项是测试代码写错，一项是新暂停逻辑的真实缺陷；它还误删了一项已有测试，审查后才恢复。最终测试套件达到 145 项。

验收条件本身也会错。规格承诺直接从磁盘打开应用，但浏览器限制 file:// 下的 ES module 脚本。作者验证后把要求改为使用静态 HTTP 托管。故事的庄园初名也撞上了已有游戏标题，发布前跨六个文件改成 Quillmoor。自动原创检查没有发现这些命名问题。

我的判断

这篇最有价值的，是把几种证据分开了：写了规则、执行了检查、检查能够发现旧问题，是三个不同层次。尤其是让回归测试在旧代码上失败，比单纯增加测试数量更能说明修复有效。

但它没有提供无规格开发的对照，也没有统计总耗时、提示词成本或最终全部费用。因此，「规格驱动更省钱、更快」仍不能从这个案例推出。能确认的是，它给后续修复留下了明确记录。

这套流程也有前提：项目是无运行时依赖的静态应用，约束相对集中。换成复杂前端或 Node 服务，构建、接口和外部依赖都会增加验证范围。普通团队未必需要两个 Agent 串联；单个 Agent 配合人工审查、显式测试命令或 CI，也能落实相同原则。

不给 shell 权限是一种权限取舍，同时也要求外层承担执行责任。作者证明的不是 Agent 能自行闭环，而是有人持续检查，能把它的错误追回来。

能拿来做什么

• 给前端交互任务补上具体状态条件，例如 PLAY 后必须显示首条线索、STOP 后时间必须复位，并在提示词中同时写任务编号和完整标题。
• 在实际使用的 CLI 模式下触发一次文件修改，留下 Hook 执行日志；对非交互流程无法触发的检查，安排显式执行步骤。
• 对计时、暂停和跨回合逻辑使用可控时钟验证，并确认新增回归测试在旧代码上会失败，避免只看到新版本全绿。
• Agent 没有执行权限时，每轮修改后自行运行测试并审查差异，同时检查已有测试是否被删除；把发现的缺陷和错误前提回填到 tasks.md。