01
你现在在哪一步
不同阶段该关注的事不一样。先找到自己的位置，再往下读。
02
怎么开始
这一段只做一件事：把想法变成一版自己能玩通的游戏。剩下的交给下一段。
先确认你的运行环境支不支持 CLI
- 在终端执行 taptap-cli --version，有版本号就说明可用
- 公司内网、受限设备或某些在线 IDE 会拦住 npm 安装，这种情况不要硬试
- 装不上就用本地 Agent：把这一页交给本机的 AI 助手，让它按同一套流程带你做
把这段话发给你的助手
尖括号里的内容换成你自己的。一次说清楚，比来回补充有效。
帮我做一个能在浏览器里玩的游戏。
玩法：<一句话说清玩家在做什么>
目标玩家：<谁会玩，在什么场景下玩>
第一版只做：<一个核心循环，能玩 2 分钟>
技术上：纯 HTML + JS 单文件，不用构建工具，双击就能打开。
做完告诉我怎么在本地打开，我来试玩。 让你的助手先追问你
不要急着让它写代码。先让它把下面这几件事问清楚，再动手。
- 核心玩法是什么：玩家在反复做哪一件事
- 什么时候算赢、什么时候算输，一局大概多久
- 操作方式：键盘、鼠标还是触屏，用几个键
- 第一版明确不做什么：把范围钉死，避免越做越大
什么叫"能玩通"
这是可以拿去上架的最低标准，四条都要满足。自测是这里最关键的一步，别跳过。
- 打开就能玩，不用注册，不用先读说明
- 有一个完整循环：开始 → 玩 → 结束 → 能再来一局
- 白屏、卡死、按钮没反应这类问题在真机上不出现
- 你自己连着玩三局，中途没有想关掉的念头
最常见的两个卡点
- 打不开。这是上架被驳回最常见的原因，第一版就要解决
- 进去之后不知道要干什么。玩家得在一屏之内明白该做什么
03
开发建议
用 AI 做游戏，卡住的地方通常不在写代码，而在范围失控和技术栈选错。
第一步：把技术栈和产物定下来
这一步定不下来，后面每一步都会返工。先把这两件事写清楚，再开始写代码。
- 技术栈：用什么引擎或框架，比如纯 H5、Unity、Cocos、Godot
- 最终产物：交付的是 APK 包、PC 包、H5 站点，还是 TapTap 制造版本
- 把这两条写进项目说明里，让助手每次都照着它走，不要中途漂移
第二步：按玩法选方案，不要让助手混着来
| 你打算怎么做 | 对应方案 | 产物形态 |
|---|---|---|
| 在 TapTap 制造里做 | 用制造本地插件开发 | TapTap 制造版本 |
| 用 Unity / Cocos / Godot 等引擎 | 按引擎的开发流程做 | APK 或 PC 包 |
| 直接写网页 | 纯 H5 开发 | H5 站点（部署在平台域名下） |
选定之后不要混淆
- 引擎方案和 H5 方案的技术细节不通用，别让助手把两套写法混在一份代码里
- 同一个需求先确认属于哪一套，再让助手动手，不要让它自己猜
- 发现助手引用了另一套方案的文档或 API，停下来纠正它，这通常是要返工的信号
让 AI 老老实实照范围做
- 第一版只留一个玩法、一个场景、一个循环，多出来的想法先记下来
- 先能玩通，再谈好看，美术风格留给第二版
- 每次让 AI 改之前，先让它说明准备动哪些文件
- 每完成一小段就自己玩一次。「改好了」和「真的能玩」是两件事
- 一次只提一个需求。连着提五个，出问题很难定位是哪一处
第一版先别做这些
- 先别接账号、排行榜、云存档。等有人玩了再回来接，那时你才知道该接哪个
- 先别做多语言和多平台打包，跑通一个平台就够了
- 先别优化包体和性能，卡顿到影响玩法再处理
- 先别自己写联网和支付，平台有现成的能力，见下一段
什么时候该回头接平台能力
出现下面这些情况，说明该去下一段了。
- 玩家隔天不回来：接 TapTap 登录和 TapDB，先搞清楚人在哪一步走的
- 玩家进度会很长：接云存档，换设备能接着玩
- 玩法本身有可比性：接成就与排行榜，给玩家一个回来的理由
04
接入平台能力
这些能力不影响能不能上架，但接了玩家体验更好。按需要接，不用一次全接。下面按游戏形态分开，每一种都有自己的文档，不要交叉引用。
第一步：先认清自己的形态，再挑能力
| 形态 | 是什么 | 走哪条文档 |
|---|---|---|
| Tap 小游戏 | 用 WebGL 跑的 Tap 小游戏，不是 H5，也不是网页游戏 | 小游戏文档 |
| H5 游戏 | 以 H5 形式打包，部署在平台域名下运行 | 小游戏体系下的 MCP |
| APK / PC 包 | 原生客户端包体 | 游戏服务（SDK）文档 |
| TapTap 制造 | 在制造里完成，不用手动打包 | 制造本地插件 |
第二步：按需要挑一两个能力
| 能力 | 解决什么问题 | 什么时候接 |
|---|---|---|
| TapTap 登录 | 玩家不用再注册一个账号 | 有进度、存档或社交需求时 |
| TapDB 数据分析 | 知道玩家在哪一步流失 | 上线前就接，第一天就能看 |
| 云存档 | 换设备能接着玩 | 玩家会有长进度时 |
| 成就与排行榜 | 给玩家一个回来的理由 | 玩法本身有可比性时 |
| 礼包系统 | 做活动、发福利 | 有运营计划时 |
| 内嵌动态 | 游戏内直接看社区内容 | 想引导玩家进社区时 |
先分清形态：不同形态的文档不能混用
- Tap 小游戏（WebGL）只读小游戏文档，不要拿 APK 的 SDK 文档来接
- H5 游戏是另一类形态，走小游戏体系下的 MCP 配置，不走 APK 那套 SDK
- 制造版本用制造本地插件，不要去找 APK 的上传接口
- 让助手动手前先说明它准备看哪一份文档，读错档是返工最常见的原因
Tap 小游戏（WebGL）→ 只看小游戏文档
- 小游戏开发指南Unity / Cocos 导出，经打包工具出 zip/minigameapidoc/
- 登录管理/minigameapidoc/dev/tutorial/open-capabilities/login-management/
- 云存档/minigameapidoc/dev/tutorial/open-capabilities/cloud-save-tutorial/
- 排行榜/minigameapidoc/dev/tutorial/open-capabilities/leaderboard-tutorial/
- 分包与 Wasm/minigameapidoc/dev/tutorial/performance/launch/wasm-subpackage/
- 调试与真机预览/minigameapidoc/dev/dev-support/debugging/
H5 游戏 → 走小游戏体系下的 MCP
APK / PC 包 → 走游戏服务文档
TapTap 制造 → 用制造本地插件
让助手帮你接
它需要先知道平台有哪些能力，再动手改代码。
读一下 https://developer.taptap.cn/agents.md
我要给现在的项目接入 TapDB。
先告诉我需要改哪些文件、动哪些地方，不要直接改。接入时的三个坑
- 一次接三个能力。出问题时不知道是谁引起的，一次接一个
- 照着网上旧版示例写。以开发者文档的最新版本为准
- 把密钥写进前端代码。客户端只放 appId 这类公开标识
上面每一份文档都在对应形态下有效，不要跨形态引用。
05
怎么上架
手游、PC 游戏、网页游戏、TapTap 制造游戏都走这条链路。AI 做的游戏同样能上架。
先用 CLI 走完上架
六步走完，顺序不要调
- 1建游戏填最小必填信息，生成一个游戏草稿。做完是这样 控制台里能看到这个游戏，状态是草稿。
- 2传包体按游戏形态上传，平台自动做基础校验。做完是这样 包体校验通过，能生成一张测试二维码。
- 3自测扫码在自己手机上完整玩一遍，把打不开、卡死、玩不懂的问题先解决掉。做完是这样 你自己连玩三局没问题，没有明显的卡顿、白屏和死路。
- 4补资料图标、截图、简介。这一屏是玩家在商店里看到的东西。做完是这样 用手机扫码进去，看到的图标和截图就是最终版本。
- 5给玩家开测试开测试计划，让真实玩家进来玩几轮，收集反馈再迭代。做完是这样 跑完几轮测试，玩法稳定，没有重大 bug。
- 6正式上线确认玩法稳定后提交审核，通过后执行上线动作。做完是这样 游戏对外可见，玩家能直接下载或游玩。
让助手代你走完
先跑预览确认信息，再执行。
# 预览，不会真的创建
taptap-cli app create-app \
--dev-id <developerId> \
--data '{"title":"<游戏名>","category":"<类型>","package_type":"apk"}' \
--idempotency-key <唯一键> \
--dry-run
# 确认无误后，用同样的数据和幂等键执行
taptap-cli app create-app ... --yes 提交前自己过一遍
- 游戏能打开，玩得下去，没有卡死和白屏
- 图标、截图和游戏里的实际内容一致
- 没有未成年人不宜内容，没有没授权的素材和音乐
- 需要版号或备案的形态，资质先补齐
- 测试跑完、玩法稳定了再去提审，不要拿未验证的版本冒这个险
提审和上线不是即时的
- 提交后进入人工审核，时长以控制台显示为准
- 被驳回时先看驳回原因，改完再提交，不要原样反复提交
- 上线是一个独立动作，审核通过不等于已经上线
06
上架之后
上线只是开始。这里有三件事要持续做：读玩家反馈、看游戏数据、盯留存。
一、读玩家评价，修问题，和玩家聊
- 把评价区的差评逐条看一遍，找出重复出现的那几个问题
- 能修的排进下一版，修完在评价区回复，让玩家看到你确实改了
- 在社区和评论区跟玩家互动，回复提问、认领 bug，这是最省力的口碑积累
- 不要只回好评。差评下面的回复，其他玩家也会看到
二、看游戏数据，及时优化商店素材
- 重点看商店页的曝光到下载，转化低说明图标、截图或简介没打动玩家
- 图标和首图是转化影响最大的两个素材，先换它们
- 商店素材改完不用重新提审整包，改完提交即可
- 做一次小的内容更新，比反复改图标更容易重新拿到曝光
三、看玩家游玩时间，找流失点
- 看玩家平均玩多久，掉得最快的是第几分钟
- 如果在某个关卡或某个操作上集中流失，多半是难度或引导出了问题
- 把「第几分钟流失最多」和「玩家在评价里抱怨什么」对照着看，两边指向同一处就是真问题
让助手替你读数
读一下 https://developer.taptap.cn/agents.md
帮我查这个游戏上线一周的表现。我要看三件事：
1. 玩家评价里重复出现的问题
2. 商店页曝光到下载的转化
3. 玩家在第几分钟流失最多
查完给我一份按优先级排的改动建议。 什么时候该更新，什么时候该做下一款
- 玩家在同一处反复失败或退出：修，这是明确的卡点
- 好几个玩家提同一个建议：做，这是真实的信号
- 数据没变化，也没人提：先别动，把精力放到下一款
- 改资料和文案不用重新提审整包，改完提交即可
几个有效的运营动作
- 把玩家反馈里出现最多的那句话，用在商店页简介里
- 做一次小的内容更新，比改一遍图标更容易被玩家看到
- 有测试计划时先跑小范围测试，再决定要不要放大
07
边界与安全
这些限制在答复用户之前就要说清楚，不要承诺超出范围的能力。
能力范围
- CLI 覆盖创建游戏、资料素材、包体、资质、测试计划与数据表现
- 具体支持范围以 taptap-cli skills list 的实际输出为准，不要凭这份说明推断
- Tap 小游戏上传目前在控制台完成，不走 CLI 上传命令
- 需要版号或备案的形态，资质没补齐不能上线
这些动作必须先问人再做
- 提交审核、撤销审核、上线、下线
- 删除游戏、删除包体、清空草稿
- 修改开发者账号权限、增加协作者
- 任何涉及付费、用户数据或对外发布的动作
不确定的参数先查再执行：taptap-cli --help 或 taptap-cli schema <service> <method>。
08
文档索引
按用途分组。带 .md 后缀的链接是纯文本，AI 助手可以直接读。
CLI 与 Skills
- CLI 使用文档安装、登录、上手/v3/cli/
- 命令参考/v3/cli/command-reference.md
- AI 能力参考/v3/cli/skill-reference.md
- 入口与路由/v3/cli/skills/taptap-cli.md
- 身份与上下文定位/v3/cli/skills/taptap-identity.md
- 创建游戏/v3/cli/skills/taptap-publish-game.md
- 资料编辑与版本发布/v3/cli/skills/taptap-app-edit.md
- 上架资质/v3/cli/skills/taptap-qualification.md
- 包体管理与自测/v3/cli/skills/taptap-package-management.md
- 测试计划/v3/cli/skills/taptap-test-plan.md
- 数据表现/v3/cli/skills/taptap-dashboard-stats.md
- 图片素材库/v3/cli/skills/taptap-asset-library.md
游戏服务 SDK
先把这一页交给你的助手
装一次 CLI，之后的建游戏、传包体、提审、看数据都可以交给命令或 AI 助手完成。