taptap-maker-builder

---
name: taptap-maker-builder
description: 在 TapTap 制造（TapTap Maker，UrhoX 引擎 + Lua，对话即创作、完成即发布）上把一份游戏策划案落成可玩、可发布的项目：判断用浏览器工作区还是本地 MCP、解析策划案五要素、生成首轮需求、按官方顺序迭代、预览与实机验收、核对发布物料，并守住积分与凭证红线。当用户询问 TapTap 制造 / Maker / UrhoX / 积分 / UI 主题 / Benchmark / 本地 MCP 的问题，或上传游戏策划案要求搭项目、写需求、生成素材、做发布准备时使用。
argument-hint: "[策划案文件，或一个 TapTap Maker 问题]"
---

# taptap-maker-builder（TapTap 制造项目搭建）

## 这个 Skill 做两件事

1. **让 Agent 快速上手**：用一屏讲清 TapTap 制造是什么、两种创作方式怎么选、首轮需求五要素、积分与主题、Benchmark 怎么读；遇到具体问题时按路由只读对应的一篇 reference。
2. **从策划案到发布**：用带确认门的阶段 0–6，把一份策划案逐步搭成可玩项目。每阶段都有交付物、模板、验收清单，用户确认后才进入下一阶段。

本 Skill 只负责「怎么推进」，**不替用户启动真实项目**。所有对项目的改动都发生在用户自己的 Maker 项目里，并且先得到确认。

## 什么时候用

- 用户问 TapTap 制造 / Maker / UrhoX / 制造研究所 / 排行榜 / 积分 / UI 主题 / 本地 MCP 怎么接。
- 用户上传或粘贴游戏策划案、需求文档，要求「搭一个」「做成能玩的」「按这个做」。
- 用户要写 Maker 对话需求、判断积分消耗、核对发布物料、排查预览或实机问题。

不适用：Unity / Unreal 等其它引擎；纯美术外包；与 Maker 无关的通用编程。

## 三条铁律（违反即停下）

1. **在线文档优先**：产品迭代快，先读 <https://maker.taptap.cn/llms.txt>，再按需读对应文档。本 Skill 的知识有整理日期，与在线文档冲突时以在线文档为准；文档没有的功能、参数、模型名、价格、上限，一律不编。
2. **确认门不可跳**：阶段 0–5 每阶段结束先交「阶段报告」，等用户明确确认（「确认」「继续」「可以」）再往下。用户没确认就停在原地问一句。
3. **不擅自花钱、不擅自动文件**：未经用户在对话中明确要求，不调用消耗积分的生成工具；不自动替换模型或通道；不移动、删除、覆盖用户的文件；超出策划案范围的新系统先征得同意。

## 60 秒产品速览

| 维度 | 要点 |
|---|---|
| 产品 | TapTap 制造（TapTap Maker）：面向游戏爱好者的 AI 游戏创作工具，用自然语言完成方案设计、代码实现、素材制作、预览迭代、发布准备 |
| 底层 | UrhoX 引擎 + Lua 脚本；内置 Astroon / BrawlForge / PixelForge 三套 UI 主题 |
| slogan | 对话即创作，完成即发布 |
| 两种创作方式 | 浏览器工作区（项目、对话、预览、发布同一页面）；本地开发模式（Maker MCP 接入本地目录，支持 Codex / Cursor / Claude Code） |
| 权威入口 | <https://maker.taptap.cn/llms.txt>（一切文档的总索引，时效性最高） |

**首轮需求五要素**（写需求前必须能回答）：**玩法目标 / 表现形式 / 操作方式 / 核心循环 / 首轮范围**。

**积分**：通用、基础、活动、项目、付费五类；默认消耗顺序 **活动 → 项目 → 基础**，通用与付费是否可用还受当前模型、项目范围与服务端校验影响。发布面板操作不消耗创作积分。

**Benchmark**：真实 UrhoX 无头执行 + 确定性断言，主榜头条是 **L2 通过率**；每个分数带 95% 置信区间，每个名次带可能范围——范围重叠就读作「当前样本量还分不出先后」。

## references 导航（按需只读一篇）

| 问题或场景 | 读哪篇 | 里面有什么 |
|---|---|---|
| 产品是什么、两种方式怎么选、MCP 怎么装、目录长什么样、怎么加协作者 | ./references/01-product-overview.md | 定位与能力边界、方式对比、安装命令、目录结构、本地 Runtime、协作规则 |
| 积分怎么扣、什么会花积分、结果未知怎么办、怎么省 | ./references/02-credits-and-cost.md | 五类积分、消耗顺序、成本控制、uncertain 台账 |
| 选哪套主题、主题怎么指定、素材规格与上限、AI 生图提示怎么写 | ./references/03-ui-themes-and-assets.md | 三套主题的适用品类与视觉规则、素材五类限制、DWP、素材目录约定 |
| 排行榜怎么看、L2 是什么、置信区间与名次范围怎么读 | ./references/04-benchmark-guide.md | 三级判分、各维度含义与误读、统计方法、局限性 |
| 策划案怎么拆、五要素缺了怎么问、第一条需求怎么写 | ./references/05-brief-parsing-and-first-prompt.md | 提取表、追问上限与问法、确认单要点、首轮需求好/坏对照 |
| 迭代怎么提、四段式怎么写、预览五项 / 发布前六项 / 数据六条 | ./references/06-iteration-and-acceptance.md | 四段式写法、官方推进顺序、验收清单、常见失败模式 |
| 发布要准备哪些物料、二维码测试版怎么走、分享页怎么开 | ./references/07-publish-checklist.md | 物料清单与规格、发布流程、测试版同步、发布后动作 |
| 凭证怎么放、哪些动作不可逆、原子写、素材版权、协作安全 | ./references/08-safety-and-credentials.md | 时效、成本、凭证、不可逆动作、原子写、范围与版权 |

规则：**一次只读与当前问题相关的那一篇**；读完再回答，不凭印象补细节。

## 阶段总览（0–6）

| 阶段 | 目标 | 交付物 | 确认门 | 工具 / 模板 |
|---|---|---|---|---|
| 0 接入 | 定创作方式；本地模式确认 MCP、项目绑定与现有目录 | 接入确认 + 目录核对结果 | 用户确认方式与环境 | ./scripts/check_project_layout.py |
| 1 解析 | 结构化提取五要素，缺失一次性追问（≤4 问） | 策划案理解确认单 | 用户逐项确认五项后才写需求 | ./assets/brief-confirmation-template.md、./scripts/check_brief.py |
| 2 首轮需求 | 转写成符合官方规范的第一条需求，只做最小可玩核心循环 | 首轮需求文本 + 主题与画面方向 | 用户确认需求与主题方向 | ./assets/first-prompt-template.md |
| 3 迭代 | 最小可玩 → 阻断 → 节奏数值手感 → 素材音效引导物料 | 每轮四段式需求 + 验证结果 | 每轮结果验收后才进下一轮 | ./assets/feedback-four-part-template.md、./references/06-iteration-and-acceptance.md |
| 4 预览实机 | 五项验收 + 真机测试二维码 | 验收记录、问题清单 | 五项全过才进发布 | ./references/06-iteration-and-acceptance.md、./references/07-publish-checklist.md |
| 5 发布 | 物料逐项核对，版本一致后发布 | 发布物料核对单 | 用户确认物料与版本一致 | ./scripts/check_publish_materials.py、./assets/stage-report-template.md |
| 6 贯穿 | 成本与安全守护，每阶段都生效 | 风险提示与确认记录 | 高危动作逐次确认 | ./references/02-credits-and-cost.md、./references/08-safety-and-credentials.md |

推进纪律：每个阶段结束先给「阶段报告」→ 等用户明确确认 → 才进入下一阶段。

## 阶段 0：接入

先一次问清三件事，不要来回挤牙膏：

1. 用**浏览器工作区**，还是**本地 MCP**（本地目录 + Codex / Cursor / Claude Code）？
2. 是已有项目还是新建？项目名、游戏方向？
3. 有没有要复用的现有素材或代码目录？

| 情形 | 建议 |
|---|---|
| 第一次做、想最快看到画面 | 浏览器工作区 |
| 已有本地代码或素材、要用 Codex / Cursor / Claude Code 工作流 | 本地 MCP |
| 要接 Git、多人协作、在本地做检查 | 本地 MCP |
| 只想在手机上快速试玩 | 浏览器工作区 + 分享二维码 |

本地模式命令（在目标目录执行；init 会拉取项目到当前目录，**先确认目录为空或用户同意合并**）：

~~~bash
npx -y @taptap/maker install --ide codex,cursor,claude   # 只写三家 MCP 配置
npx -y @taptap/maker init                                # 登录 + 选/建项目 + 绑定目录 + 拉取
~~~

- 初始化后典型目录：assets/（含 image、sprites、audio、video）与 scripts/；实际结构随项目变化。
- 动手前跑 `python ./scripts/check_project_layout.py <项目根>`，并读一遍现有目录与说明，避免覆盖在用资源。
- 更新组件：「更新当前项目的 Maker MCP 和 AI DevKit，然后告诉我实际使用的版本」；生产用 pd/stable，试验用 rnd/latest。
- 凭证只存受信任的本地环境，不写进项目文件、不进 Git。

确认门 0 话术：「我准备用 X 方式接入，项目目录是 Y，现有结构是 Z，不会覆盖 A。确认后进入策划案解析。」

## 阶段 1：策划案解析

流程：

1. 通读策划案，直接抽五要素表，不要整段复述。
2. 每项标注：**有**（原文依据）/ **推断**（须确认）/ **缺失**。
3. 缺失与关键歧义**一次性**提问，≤4 问，每问给 2–3 个候选答案，降低回答成本。
4. 产出「策划案理解确认单」，必须含「我理解的 / 我不确定的 / 我建议首轮砍掉的」。
5. 用户确认后才进入阶段 2。

硬规则：

- 关键设定（题材、主角、核心胜负条件、操作方式、目标平台与画面方向）**不允许脑补**；缺就问，或明确标「待定」并给出默认建议。
- 策划案里的后期系统（养成、商店、联机、排行榜、多章节）一律放进「后续版本」，不进首轮。
- 确认单里必须写清「首轮不做什么」。

可先用脚本检查五要素是否齐全（JSON 结构见脚本头部注释）：

~~~bash
python ./scripts/check_brief.py brief.json
~~~

## 阶段 2：首轮需求生成

写首轮需求的顺序：**一句话定位 → 五要素 → 操作与胜负 → 界面清单 → 范围外**。

- 一条需求只解决一个结果；先做最小可玩核心循环。
- 明确「这一轮不做什么」，比列一堆功能更能收敛范围。
- 同时确认：UI 主题（Astroon / BrawlForge / PixelForge）、画面方向（横屏 / 竖屏）、视角（2D / 3D）、美术基调。
- 模板：./assets/first-prompt-template.md；好 / 坏对照见 ./references/05-brief-parsing-and-first-prompt.md。

主题与方向确认话术：「我建议 A 主题（理由：品类契合），竖屏 2D；若你更想要 B，我按 B 改。确认后我发第一条需求。」

## 阶段 3：迭代搭建

官方推进顺序（不得跳）：

1. 最小可玩版本（能开始、能操作、能结束、能重开）
2. 修阻断流程问题（卡死、按钮点不到、状态不重置）
3. 调节奏、数值、手感
4. 补素材、音效、引导、发布物料

每轮需求用四段式：**目标 / 现状 / 约束 / 验收**（模板 ./assets/feedback-four-part-template.md）。

- 一次只聚焦一个结果；「加音效 + 改数值 + 换主题」不要写进同一条。
- 「约束」写必须保留的东西（现有操作、已确认主题、不要重构的模块）。
- 「验收」写成可观察的现象，不写「更好玩」。
- 要求 AI **自行构建、检查错误，并说明验证结果**；复杂改动先让它给简短计划。
- 同目标留在同一对话；换方向新建对话。

报 bug 时给全五件事：设备 / 页面、操作步骤、实际现象、期望现象、能否复现（可附截图或录屏）。

## 阶段 4：预览与实机

五项验收（官方清单，逐项记录结论）：

1. 能正常开始吗？
2. 操作是否符合预期（含触控区域、按钮可点）？
3. 成功 / 失败 / 重开是否完整？
4. 画面在目标设备上是否清楚（字号、对比、安全区）？
5. 有没有卡住流程的问题？

设备与分享：

- 桌面预览可切 PC / 手机 / 平板与分辨率（含 iPhone 17 的灵动岛遮罩，会挡住该区域点击）。
- 真机：预览工具栏「分享」→ 链接 / 二维码；创建分享页前需在发布面板选好已完成开发者认证的发布厂商。
- 实机测试二维码：「扫码在手机上测试」→「更新测试版」→ 扫码；改了代码 / 方向 / 配置 / 物料后要重新更新，否则会扫到旧版本。
- 横竖屏切换必须让 AI **同时**改界面布局与项目方向配置；改完重新构建，并在预览 / 实机验证按钮、文字与触控。

验收不过就回阶段 3 写四段式需求，不要跳去发布。

## 阶段 5：发布准备

物料清单（逐项核对）：

- 游戏图标
- 至少 3 张游戏截图
- 宣传图、横版封面、竖版封面
- 竖屏游戏另需方形宣传图
- 游戏名称
- 游戏简介 ≥10 字
- 「开发者的话」≥10 字
- 首次正式发布所需的实机测试视频

流程：物料生成（消耗积分，需用户明确同意）→ 发布面板核对 → 更新测试版并扫码复验 → 正式发布。

- 多发布厂商时先选厂商；物料生成阶段完成后发布按钮才可用。
- 发布面板操作本身不消耗创作积分。
- 发布前健康检查见 ./references/06-iteration-and-acceptance.md（发布前 6 项、数据检查 6 条）。
- 核对命令：`python ./scripts/check_publish_materials.py materials.json --root <项目根>`。

## 阶段 6（贯穿）：成本与安全守护

每阶段都要执行：

- **积分**：未经用户在对话中明确要求，不调用消耗积分的生成工具；高消耗前说明「会花什么、大概多少、能不能更省」；不自动换模型或通道。
- **结果未知不重投**：提交后没拿到明确结果 → 标记 uncertain，先查状态；确需重投要让用户确认，并说明可能已扣费。
- **凭证**：不回显、不代写、不写入项目文件或 Git；只给可信客户端授权。
- **不可逆动作**：删除或覆盖素材、替换模型、切换通道、清空配置、正式发布——先停下说明后果与撤销方式，拿到明确「是」再做。
- **范围**：只在策划案范围内搭；新增系统或玩法先征得同意；不擅自移动、删除用户文件。
- **原子写**（脚本或工具写文件时）：临时文件 + 改名；空值不覆盖已有值；损坏文件另存留现场。

细节见 ./references/08-safety-and-credentials.md 与 ./references/02-credits-and-cost.md。

## 阶段报告

每次进入下一阶段前，用 ./assets/stage-report-template.md 输出四块：本阶段做了什么 / 产出物 / 验证结果 / 下一步与需要你确认的点。报告末尾必须是一句可回答的确认请求。

## 维护与时效

- 本 Skill 知识整理日期：**2026-11-03**。产品迭代快，凡涉及功能、参数、模型、价格、上限，一律以在线文档为准。
- 冲突处理：在线文档 > 本 Skill。发现不一致，按在线文档执行，并在回复里说明差异。
- 刷新方式：先读 <https://maker.taptap.cn/llms.txt> 找对应页面；需要原文时把对应 .md 地址取纯文本。
- 禁止编造：文档里没有的功能、参数、模型名、价格、上限，一律回答「文档没写，我去查或请以页面为准」。

## 示例提示词

- 「我想做一个竖屏 2D 躲避游戏，先帮我看看这条路怎么走。」→ 阶段 0 / 1。
- 「这是我的策划案（附件），帮我搭起来。」→ 阶段 0 起，逐阶段确认。
- 「Maker 的积分怎么扣？生成一张图要多少？」→ 只读 references/02，直答，不进工作流。
- 「排行榜上 60% 和 63% 的 L2 通过率差得多吗？」→ 只读 references/04，讲置信区间与名次范围。
- 「按 Astroon 主题把开始界面做出来，别动玩法。」→ 阶段 3，写四段式需求。

• .gitignore 1 KB
• CHANGELOG.md 1 KB
• LICENSE 1 KB
• README.md 3 KB
• README.zh-CN.md 6 KB
• SKILL.md 16 KB
• cordis.patch.yml 1 KB
• package.json 1 KB