Kubee 全景总览
本页是 Kubee 工作台的唯一入口：说明这个工作台要做什么、当前进度如何、单个小游戏怎么追踪，以及需要看工程时去哪里。
一、工作台定位
Kubee 是一个类似 TapTap Maker 的“一句话生成小游戏”项目工作台。
当前工作对象是项目中已有的 42 个历史小游戏。接手后的重点不是重新证明“能生成小游戏”，而是把这些已有结果逐个优化到更可玩、更好看、更稳定的状态。
这件事的核心难点不只是改某一个游戏，而是建立一条可复用的小游戏优化流水线：每个游戏都能被快速诊断、明确优先级、提出优化方案、执行资源或 Gameplay 改造，并留下验收结论。
第一阶段先解决三件事：
- 建立统一工作流，避免每个小游戏都靠临场判断推进。
- 建立单游戏评审卡，沉淀 Gameplay、资源、优先级和验收结论。
- 建立总进度追踪，让 42 个小游戏的状态一眼可见。
二、当前进度
| 项目 | 当前状态 |
|---|---|
| 总量 | 42 个历史小游戏 |
| 完整清单 | 已读取 [[冷启动游戏列表]]；35 条非空游戏记录，缺失序号 7、8、9、22、23、29、30 待确认 |
| 单游戏卡片 | 尚未创建 |
| 首轮分级 | 尚未开始 |
| 当前批次 | 待选择第一批 5-8 个游戏 |
| 工程入口 | 已知本机入口：F:\Coding\Kubee |
三、工作台入口
| 内容 | 位置 | 用途 |
|---|---|---|
| 全景总览 | 本页 | 工作台唯一入口、工作流、总进度、工程入口 |
| 游戏清单 | 10_游戏清单/ | 原始清单、单个小游戏的评审卡、优化方案、验收记录 |
| 优化记录 | 20_优化记录/ | 批量评审、共性问题、流程复盘、质量标准 |
| 归档 | 90_归档/ | 已结束、暂停或不再推进的历史材料 |
| 本地工程 | F:\Coding\Kubee | 代码、资源、模板、依赖、构建和运行方式 |
工程边界
- Obsidian 保存：工作流、评审标准、单游戏优化判断、进度追踪、阶段复盘。
- Kubee 工程保存：实际游戏资源、代码、构建产物、运行配置。
- 如果要看代码、资源、模板、依赖或运行方式，进入
F:\Coding\Kubee后按真实工程状态确认。 - 若后续接入 TAPD 或其他任务系统，任务状态以外部系统为准，Obsidian 只保留入口和关键决策。
四、工作流 v0
flowchart LR A["导入 42 个小游戏清单"] --> B["首轮快速分级"] B --> C["单游戏体验诊断"] C --> D["Gameplay 优化方案"] C --> E["资源优化方案"] D --> F["执行与验收"] E --> F F --> G["更新总进度"] G --> H["沉淀共性规则"]
0. 导入清单
先把 42 个小游戏整理成可追踪清单，而不是直接进入逐个修改。
每个游戏至少需要记录：
- 游戏名
- 原始一句话 prompt
- 当前玩法类型
- 当前可运行入口
- 资源入口
- 当前问题概述
1. 首轮快速分级
先用轻量标准把游戏分层，决定优化顺序。
| 分级 | 含义 | 处理方式 |
|---|---|---|
| A | 已有可玩基础，优化后适合展示 | 优先进入第一批 |
| B | 有题材或机制亮点，但需要明显改造 | 第二批或专项优化 |
| C | 体验弱、资源弱或方向不清 | 暂缓，只记录问题 |
| X | 不建议继续投入 | 归档或只保留样本价值 |
2. 单游戏体验诊断
每个游戏先诊断，再决定改什么。
诊断优先回答：
- 玩家目标是否清楚？
- 核心操作是否有趣？
- 反馈是否及时？
- 失败、成功、成长是否可感知？
- 题材和资源是否支撑玩法？
- 它最值得保留的一点是什么？
3. Gameplay 优化
Gameplay 优化只抓最关键的体验短板，不把每个小游戏都改成大项目。
常见优化方向：
- 增加明确目标
- 强化一条核心循环
- 提高操作反馈
- 增加风险 / 奖励
- 压缩无效等待
- 调整节奏和难度曲线
4. 资源优化
资源优化服务于可读性、风格统一和展示效果。
常见优化方向：
- 主角、敌人、道具的可辨识度
- 场景层次和色彩对比
- UI 信息可读性
- 动效反馈
- 题材一致性
- 封面或展示截图质量
5. 验收与沉淀
每个游戏优化完成后，至少留下：
- 优化前主要问题
- 实际改动摘要
- 当前版本结论
- 是否适合展示
- 后续是否继续投入
五、总进度追踪
已读取冷启动页签的原始清单，当前先按清单级别追踪；单游戏卡片仍待后续创建。
| 阶段 | 数量 | 说明 |
|---|---|---|
| 已读取清单 | 35 | [[冷启动游戏列表]] 中的非空游戏记录 |
| 待确认缺失序号 | 7 | 原序号 7、8、9、22、23、29、30 在当前页签中未读到非空记录 |
| 已建卡 | 0 | 单游戏卡片尚未创建 |
| 已快速分级 | 0 | 尚未完成 A/B/C/X 分级 |
| 优化中 | 0 | 尚未进入执行 |
| 已验收 | 0 | 尚未完成优化验收 |
| 已归档 | 0 | 尚未归档 |
六、单游戏卡片结构
单个小游戏进入评审时，在 10_游戏清单/ 下创建独立笔记。
建议结构：
# 游戏名
## 基本信息
- 原始 prompt：
- 当前入口：
- 资源入口：
- 类型：
- 当前状态：
- 优先级：
## 首轮诊断
- 核心玩法：
- 当前亮点：
- 主要问题：
- 最值得保留的一点：
## Gameplay 优化
- 优化目标：
- 改动建议：
- 验收标准：
## 资源优化
- 当前问题：
- 风格方向：
- 改动建议：
- 验收标准：
## 进度记录
- 待办：
- 结论：七、批量沉淀方向
随着评审推进，20_优化记录/ 里可以沉淀三类内容：
- 共性问题：42 个小游戏里反复出现的 Gameplay、资源、生成稳定性问题。
- 优化原则：哪些改动最划算，哪些改动容易过度投入。
- 展示标准：什么样的小游戏可以进入对外展示、内部评审或下一轮打磨。
八、下一步
- 读取冷启动游戏列表，形成
[[冷启动游戏列表]]。 - 确认缺失序号 7、8、9、22、23、29、30 是否在其他页签或已下架。
- 选第一批 5-8 个游戏做试评审。
- 用试评审验证 A/B/C/X 分级是否足够好用。
- 根据试评审结果更新本页工作流。
- 决定是否需要拆出独立的资源风格标准页。
九、已知模板线索
本机 F:\Coding\Kubee\本地开发包\ 下已有四类模板目录：
| 模板 | 维度 |
|---|---|
pixijs-2d-singleplayer | 2D / 单人 |
pixijs-2d-multiplayer | 2D / 多人 |
threejs-3d-singleplayer | 3D / 单人 |
threejs-3d-multiplayer | 3D / 多人 |
后续导入 42 个小游戏清单时，可以额外记录每个游戏对应的模板类型，便于横向比较同类问题。