taptap-maker-builder（TapTap 製造項目搭建）
這個 Skill 做兩件事
- 讓 Agent 快速上手：用一屏講清 TapTap 製造是什麼、兩種創作方式怎麼選、首輪需求五要素、積分與主題、Benchmark 怎麼讀；遇到具體問題時按路由只讀對應的一篇 reference。
- 從策劃案到發佈：用帶確認門的階段 0–6，把一份策劃案逐步搭成可玩項目。每階段都有交付物、模板、驗收清單，用戶確認後才進入下一階段。
本 Skill 只負責「怎麼推進」，不替用戶啟動真實項目。所有對項目的改動都發生在用戶自己的 Maker 項目裡，並且先得到確認。
什麼時候用
- 用戶問 TapTap 製造 / Maker / UrhoX / 製造研究所 / 排行榜 / 積分 / UI 主題 / 本地 MCP 怎麼接。
- 用戶上傳或貼上遊戲策劃案、需求文檔，要求「搭一個」「做成能玩的」「按這個做」。
- 用戶要寫 Maker 對話需求、判斷積分消耗、核對發佈物料、排查預覽或實機問題。
不適用：Unity / Unreal 等其它引擎；純美術外包；與 Maker 無關的通用程式設計。
三條鐵律（違反即停下）
- 線上文件優先：產品疊代快，先讀 https://maker.taptap.cn/llms.txt，再按需讀對應文檔。本 Skill 的知識有整理日期，與線上文件衝突時以線上文件為準；文件沒有的功能、參數、模型名、價格、上限，一律不編。
- 確認門不可跳：階段 0–5 每階段結束先交「階段報告」，等用戶明確確認（「確認」「繼續」「可以」）再往下。用戶沒確認就停在原地問一句。
- 不擅自花錢、不擅動檔案：未經用戶在對話中明確要求，不調用消耗積分的生成工具；不自動替換模型或通道；不移動、刪除、覆蓋用戶的檔案；超出策劃案範圍的新系統先徵得同意。
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：接入
先一次問清三件事，不要來回擠牙膏：
- 用瀏覽器工作區，還是本地 MCP（本地目錄 + Codex / Cursor / Claude Code）？
- 是已有項目還是新建？項目名、遊戲方向？
- 有沒有要複用的現有素材或程式碼目錄？
| 情形 | 建議 |
|---|---|
| 第一次做、想最快看到畫面 | 瀏覽器工作區 |
| 已有本地程式碼或素材、要用 Codex / Cursor / Claude Code 工作流 | 本地 MCP |
| 要接 Git、多人協作、在本地做檢查 | 本地 MCP |
| 只想在手機上快速試玩 | 瀏覽器工作區 + 分享二維碼 |
本地模式命令（在目標目錄執行；init 會拉取項目到當前目錄，先確認目錄為空或用戶同意合併）：
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：策劃案解析
流程：
- 通讀策劃案，直接抽五要素表，不要整段複述。
- 每項標註：有（原文依據）/ 推斷（須確認）/ 缺失。
- 缺失與關鍵歧義一次性提問，≤4 問，每問給 2–3 個候選答案，降低回答成本。
- 產出「策劃案理解確認單」，必須含「我理解的 / 我不確定的 / 我建議首輪砍掉的」。
- 用戶確認後才進入階段 2。
硬規則：
- 關鍵設定（題材、主角、核心勝負條件、操作方式、目標平台與畫面方向）不允許腦補；缺就問，或明確標「待定」並給出默認建議。
- 策劃案裡的後期系統（養成、商店、聯機、排行榜、多章節）一律放進「後續版本」，不進首輪。
- 確認單裡必須寫清「首輪不做什麼」。
可先用腳本檢查五要素是否齊全（JSON 結構見腳本頭部註解）：
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：疊代搭建
官方推進順序（不得跳）：
- 最小可玩版本（能開始、能操作、能結束、能重開）
- 修阻斷流程問題（卡死、按鈕點不到、狀態不重置）
- 調節奏、數值、手感
- 補素材、音效、引導、發佈物料
每輪需求用四段式：目標 / 現狀 / 約束 / 驗收（模板 ./assets/feedback-four-part-template.md）。
- 一次只聚焦一個結果；「加音效 + 改數值 + 換主題」不要寫進同一條。
- 「約束」寫必須保留的東西（現有操作、已確認主題、不要重構的模組）。
- 「驗收」寫成可觀察的現象，不寫「更好玩」。
- 要求 AI 自行構建、檢查錯誤，並說明驗證結果；複雜改動先讓它給簡短計劃。
- 同目標留在同一對話；換方向新建對話。
報 bug 時給全五件事：設備 / 頁面、操作步驟、實際現象、期望現象、能否復現（可附截圖或錄屏）。
階段 4：預覽與實機
五項驗收（官方清單，逐項記錄結論）：
- 能正常開始嗎？
- 操作是否符合預期（含觸控區域、按鈕可點）？
- 成功 / 失敗 / 重開是否完整？
- 畫面在目標裝置上是否清楚（字號、對比、安全區）？
- 有沒有卡住流程的問題？
裝置與分享：
- 桌面預覽可切 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，寫四段式需求。