# Game Build

> 游戏构建执行。把批准后的 GAME_DESIGN 与 ART_DIRECTION 压缩成最小 BUILD_BRIEF，交给当前编码智能体、Kimi K3、Claude Fable 5 或其他强模型实现可完整游玩的网页游戏原型，并通过真实运行和截图迭代。用于把批准的游戏方案实现成可运行游戏。

- Skill: `majiayu000/game-build` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add majiayu000/game-build`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/game-build/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/game-build

---

# 游戏构建执行

保护已批准的游戏设计并驱动强模型完成，不用教程限制模型本来就会的实现能力。

读取 [build-brief-contract.md](references/build-brief-contract.md)。必须已有
`GAME_DESIGN.md` 和 `ART_DIRECTION.md`；缺少产品决策时回到设计阶段。

可玩交付始终是网页可玩的垂直切片，但要按 `PRODUCT_BRIEF.md` 的目标平台惯例来做：竖屏或
横屏、单局时长、控制方式、小程序/移动的轻量与即开即玩、分级对应的内容边界。原型是目标
形态的可玩证明，不因"反正是网页"就套用桌面网页的默认布局。

引擎按 `PRODUCT_BRIEF.md` 的两层决定：**生产引擎**是成品方向，原型这一趟落到**网页零构建
切片**（vanilla / Phaser / Three，或生产引擎的 Web 导出）。原型层的具体 web 实现（选哪个库、
文件拆分、渲染细节）仍由实现模型在既定引擎与平台意图内决定，但不得静默改掉 `PRODUCT_BRIEF`
锁定的生产引擎方向与目标形态。

## 构建说明

只固定：成品目标、核心体验、类型契约中会改变结果的不变量、视觉锚点、原型范围、
非目标和完成证据。框架、架构、文件拆分、渲染技术和资产制作由实现模型根据环境决定。

同时固定首发界面语言和已批准的其他语言。玩家可见文案必须集中、可替换，不把文字
烙进图片；第一版只实现策划明确要求的语言，不擅自扩大本地化范围。

把 `GAME_DESIGN.md` 定的**文案声口与去AI味标准**写进构建说明，要求实现模型照它写所有
玩家可见文本（标题、引导、按钮、提示、事件、对话、结算、结局）。文案是核心体验面，
晦涩、书面、AI 腔的文本第一屏就让玩家出戏——它和玩法、美术一样是完成标准，不是收尾附属。
若 `GAME_DESIGN.md` 未定义声口标准，视为缺产品决策，回设计阶段补齐（最低含各角色声口
一句 + 禁用 AI 腔句式清单）后再开工，不得留白施工。

当前会话能编码时直接实现；需要外部模型服务时发送同一份批准设计。外部模型服务
不可用时只交付完整构建说明，不声称游戏已经生成。不要发送与原型无关的完整受版权
保护原文。

可复用技法见 [production-techniques.md](references/production-techniques.md)：灰盒先行 +
皮肤层（资产可替换）、可复现的种子随机、把实现模型当导演对象驱动、多视角试玩 → 设计期
品类保真门、手感打磨(juice) 清单（按类型取用、动效可关）、批量资产受管子流程（视觉键
清单 + 一致性审查），以及行为保护式文案重构与存档迁移。

## 完成循环

1. 用灰盒实现最小但完整的核心循环，先验证规则和范围。
2. 启动真实游戏并修复浏览器控制台、资源和运行错误。
3. 核心规则走通后再补批准的视觉方向：对照 `ART_DIRECTION.md` 的招牌时刻清单与功能色 /
   构图规则逐帧核对，每张招牌画面从真实游玩状态触发并截一张干净证据帧记入构建证据，
   到不了或不符的按缺陷修复；一轮核对零新缺陷即停，证据帧随构建完成记录交 QA 复核。
4. 操作核心路径、设计要求的结果和重开；根据证据修复并重复。

游戏必须提供一种可重复核心路径和足够的可观察状态，但具体使用界面、网址参数、
测试接口或自动演示由实现模型决定。

## 输出

生成 `build/BUILD_BRIEF.md` 和实际游戏。构建说明在完成后补充运行命令、验证结果与已知
限制。构建证据（测试输出、证据帧、招牌帧、导出清单）必须落在工作区内 qa/evidence/ 或
build 目录下的持久路径（本阶段默认 `build/evidence/`），BUILD_BRIEF 用相对路径引用，
不得只留在系统临时目录；成人向内部验收截图放在项目内不进 README / 公开清单的子目录，
并在导出清单标注。实现若降级任何「必须提供」项，必须写进构建完成记录的已知限制并回
设计确认，不得静默省略。只有可运行路径和构建证据存在时才交回总入口进入质量验证，
不自行调用下一阶段。