SuperAPI AI 工具集

game-vibe-code

编程与开发

查看项目

更新于 11-09 11:49

技能介绍

用途

该技能用于在 Claude Code 等编码智能体中,以一套短循环把小型游戏从想法推进到可玩、可验证、可提交的状态:先确定“完成”的标准,再由智能体构建,通过实际游玩验证,提交,并记录变更。适用于从零构建一个完整小游戏、AI 友好的 game jam、从 progress.md 恢复智能体构建的游戏,以及抢救已变得难以修改的智能体构建游戏。若只是临时测试单个机制、需要 jam 日程规划、深入 Three.js/Phaser/Godot/Unity/Unreal 引擎细节、生成美术音频、多人联网或完整 GDD 等,应改用对应的其他技能。

主要原则与能力

  • 规格先于代码:在 design/vibe-spec.md 中写出钩子句、核心动词和可判定的完成标准之前,不发出构建提示。
  • 每轮迭代以通过或失败的检查收尾;“看起来完成”不算完成,需要命令、输出和截图作为证据。
  • 截图需经实际查看并描述,且与旁边的状态 JSON 对照。
  • 每轮只做一个功能、一次提示只改一处;回退回归而不是打补丁覆盖。
  • 每次检查通过即提交,Git 作为检查点。
  • 构建始终可玩:首小时内可玩,故障不超过一轮迭代。
  • 客户端不放密钥、可信分数、状态或购买等权威数据;所有依赖与素材记录来源和许可。
  • 原创性护栏:只做原创游戏、类型机制和用户自己的设计与素材,不复刻特定现有游戏(名称、角色、美术、音乐、关卡、UI、故事),即使改名或“仅作练习”也不行;遇到“克隆 X”的请求,先了解用户喜欢的具体机制,用中性类型术语命名,并改变幻想、美术方向和至少一条规则,记录在规格的原创性章节。

使用方式(流程概览)

  • 步骤 0 接单:先读 .gameforge/project.json、progress.md、design/vibe-spec.md、CLAUDE.md、production/session-state/active.md 和最近提交记录;恢复模式先跑检查,失败先修。新游戏最多问四个问题(运行平台、用途、是否多人、美术音频来源)。
  • 步骤 1 选技术栈:资料给出默认组合——Web 3D 用 Vite 8 + three@0.187.0(WebGLRenderer),需要物理时加 @dimforge/rapier3d-compat@0.21.0;Web 2D 用 Vite 8 + phaser@4.2.1(WebGL、Arcade 物理);桌面/主机路线用 Godot 4.7.2 stable(GDScript);已用 Unity 6.3 LTS 或 Unreal Engine 5.8 则转对应专家技能,本循环仍适用。工具要求 Node 20.19+ 或 22.12+、Playwright 1.64.1。
  • 步骤 2 先写规格:通过访谈写出 design/vibe-spec.md,构建前先评审设计;范围收束到一个玩家约五秒能理解的想法;写简短的 CLAUDE.md(命令、规则、注意事项);在新会话中开始构建。
  • 步骤 3 搭脚手架,首小时可玩:清单包括固定版本脚手架可运行、玩家用基础图元、核心动词可操作、失败状态与无需刷新的重开、仅在开发/测试构建中的测试钩子 window.render_game_to_text() 与 window.advanceTime(ms)、?seed= 生效、npm run verify 通过、progress.md 存在、首次提交。
  • 步骤 4 迭代循环:从规格中选一个功能 → 先写检查场景 → 用含 Feature/Check/Constraints/Done 的契约提示 → 智能体实现 → 运行验证 → 查看截图与状态 → 人工试玩约两分钟 → 通过则提交并更新 progress.md 与迭代日志;失败则先修第一个新的控制台错误,改一个变量再验证,两次修正仍失败就回退、清空会话、用更小的提示重来。
  • 步骤 5 手感打磨:把所有手感数值集中到 src/tuning.ts(或 Godot 的 Tuning 自动加载),通过 ?tune=1 的开发面板调节;让智能体列出按“每小时影响力”排序的五项趣味改进,不立即实现;调试覆盖层、关卡编辑器、AI 对 AI 模拟等工具对智能体来说成本低,可用于平衡测试。
  • 步骤 6 并行会话:按子系统拆两到三个会话并明确文件归属,各自用 worktree(如 claude -w levels);共享契约是 progress.md 和 CLAUDE.md 的模块边界;一次合并一个会话并在每次合并后验证;并发超过三个通常不划算。
  • vibe debt 控制:源文件约 400 行时按职责拆分;每 5 轮迭代及 jam 过半时做重构检查;新依赖先查许可和体积;上线前做安全审查;发布前在中端安卓手机上评估性能预算和门户包体预算。模块边界建议为 src/core/、src/game/(纯规则、无 DOM 和引擎导入)、src/render/、src/ui/、src/net/、src/tuning.ts。
  • 安全:客户端不存放机密或权威数据;没有 API 密钥进入打包产物;不信任浏览器传来的分数、状态或购买。

适用场景

从零构建小型完整游戏、AI 友好 game jam、从进度文件恢复项目、抢救难以修改的智能体构建游戏。

限制

详细的安全审查章节在资料中被截断,暂未提供完整内容;其他专用领域(引擎细节、美术音频生成、发布、多人、完整 GDD 等)不在本技能范围内。