Kubee 全景总览
本页是 Kubee 工作台的唯一入口：说明这个工作台要做什么、当前进度如何、单个小游戏怎么追踪，以及需要看工程时去哪里。
一、工作台定位
Kubee 是一个类似 TapTap Maker 的“一句话生成小游戏”项目工作台。
当前工作对象是项目中已有的 42 个历史小游戏。接手后的重点不是重新证明“能生成小游戏”，而是把这些已有结果逐个优化到更可玩、更好看、更稳定的状态。
这件事的核心难点不只是改某一个游戏，而是建立一条可复用的小游戏优化流水线：先把每个游戏的试玩截图和评价轻量记录下来，再把反复出现的问题横向沉淀，后续再决定哪些进入具体优化执行。
第一阶段先解决三件事：
- 建立统一工作流，避免每个小游戏都靠临场判断推进。
- 建立单游戏轻量记录，只保留截图和用户评价，避免每个游戏都写成重方案。
- 建立总进度追踪，让 42 个小游戏的状态一眼可见。
二、当前进度
| 项目 | 当前状态 |
|---|---|
| 总量 | 42 个历史小游戏 |
| 完整清单 | 已读取 [[冷启动游戏列表]]；35 条非空游戏记录，缺失序号 7、8、9、22、23、29、30 待确认 |
| 单游戏笔记 | 已创建 35 张；明细见 冷启动游戏列表 |
| 首轮评级 | 已评级 34 个；分布：S 8、A 9、B 17；明细见 冷启动游戏列表 |
| 放弃状态 | 已放弃 1 个；放弃是状态，不影响已给出的 S/A/B 评级 |
| 当前批次 | 试评审进行中；明细见 冷启动游戏列表 |
| 工程入口 | 已知本机入口：F:\Coding\Kubee |
三、工作台入口
| 内容 | 位置 | 用途 |
|---|---|---|
| 全景总览 | 本页 | 工作台唯一入口、工作流、总进度、工程入口 |
| 游戏清单 | 10_游戏清单/ | 游戏台账：作者、游戏类型、评级、状态和单游戏入口 |
| 优化记录 | 20_优化记录/ | 流程讨论、共性问题记录、阶段复盘 |
| 流程讨论 | 01_冷启动游戏优化流程讨论 | 冷启动评审流程的讨论稿，跑完第一批后再沉淀为稳定 SOP |
| 归档 | 90_归档/ | 已结束、暂停或不再推进的历史材料 |
| 截图附件 | 附件文件夹/Kubee/ | 遵循全库附件规范的 Kubee 项目附件命名空间 |
| 本地工程 | F:\Coding\Kubee | 代码、资源、模板、依赖、构建和运行方式 |
工程边界
- Obsidian 保存：工作流、单游戏试玩评价、共性问题、进度追踪、阶段复盘。
- Kubee 工程保存：实际游戏资源、代码、构建产物、运行配置。
- 如果要看代码、资源、模板、依赖或运行方式，进入
F:\Coding\Kubee后按真实工程状态确认。 - 若后续接入 TAPD 或其他任务系统，任务状态以外部系统为准，Obsidian 只保留入口和关键决策。
四、工作流 v0
flowchart LR A["导入 42 个小游戏清单"] --> B["首轮快速评级"] B --> C["单游戏轻量记录"] C --> D["抽取共性问题"] C --> E["判断是否进入优化"] D --> F["阶段复盘"] E --> F F --> G["更新总进度"]
0. 导入清单
先把 42 个小游戏整理成可追踪清单，而不是直接进入逐个修改。
清单层面至少保留：
- ID
- 游戏名
- 作者
- 游戏类型
- 当前评级
- 当前状态（已评 / 待评 / 未建）
1. 首轮快速评级
先用轻量标准把游戏分层，核心用途不是评价好坏，而是决定后续投入强度。
| 评级 | 评价 | 投入方式 |
|---|---|---|
| S | 游戏类型和核心玩法有高潜力，值得作为重点样本打磨 | 投入较多精力，从玩法、资源、交互、节奏、反馈和展示包装等方面推进精品化 |
| A | 游戏类型和玩法方向成立，但不需要按 S 级深度重做 | 目标是提高整体成品感，补齐资源、交互、反馈、UI、节奏和展示页等短板 |
| B | 当前投入优先级较低，玩法不作为主要优化对象 | 以资源、交互、表现、可读性和基础体验补强为主，不做深度 gameplay 改造 |
2. 单游戏轻量记录
每个游戏进入真实试玩后，再建立独立笔记。单游戏笔记只记录截图和用户评价，不重复写 Kubee 入口、基本信息、完整优化方案和进度清单。
如果用户只要求放图、补图或记录截图，单游戏笔记只保存图片和 embed，不自动补画面描述、评价、评级、优化方向或 - 评价： 占位。
笔记结构只保留：
- 笔记名：
序号_游戏名 - ID，需与
[[冷启动游戏列表]]的序号保持一致 - 回到
[[冷启动游戏列表]]的双链 - 游戏类型：与
[[冷启动游戏列表]]保持一致 - 评级与优化方向：使用 Obsidian callout 强调，标题写
评级：S/评级：A/评级：B/评级：待定，正文用一两句话记录当前最值得投入的方向；如果用户给出评级理由，可在 callout 内增加评级理由，没有则不写占位 - 截图，区块标题和附件名统一使用
展示页、游戏开始界面、游戏运行界面 - 用户明确给出的评价
3. 共性问题沉淀
多个游戏反复出现的问题，不堆在单游戏笔记里，统一记录到 [[02_共性问题记录]]。
当前共性问题类型包括：
- 开始界面和玩法说明模板
- 游戏目标与阶段反馈
- 展示页图片和 Description
- 游戏内资源占位
- 战斗 / 操作反馈不足
- UI 可读性与移动端适配
- 加载、重开、报错等工程体验问题
4. 后续优化执行
只有当某个游戏决定进入优化执行时，再写具体优化目标、改动建议和验收标准。执行方案可以放在外部工程或后续专项文档里，不塞回首轮试玩笔记。
5. 验收与沉淀
每个游戏优化完成后，至少留下：
- 优化前主要问题
- 实际改动摘要
- 当前版本结论
- 是否适合展示
- 后续是否继续投入
五、总进度追踪
已读取冷启动页签的原始清单，当前先按清单级别追踪；单游戏笔记只在真实试玩后创建。
| 阶段 | 数量 | 说明 |
|---|---|---|
| 已读取清单 | 35 | [[冷启动游戏列表]] 中的非空游戏记录 |
| 待确认缺失序号 | 7 | 原序号 7、8、9、22、23、29、30 在当前页签中未读到非空记录 |
| 已建笔记 | 35 | 明细见 冷启动游戏列表 |
| 已评级 | 34 | S 8、A 9、B 17；评级只统计 S/A/B，明细见 冷启动游戏列表 |
| 已放弃 | 1 | 38；放弃是状态，不覆盖评级 |
| 优化中 | 0 | 尚未进入执行 |
| 已验收 | 0 | 尚未完成优化验收 |
| 已归档 | 0 | 尚未归档 |
六、单游戏笔记结构
单个小游戏进入试玩记录时，在 10_游戏清单/ 下创建独立笔记。
截图遵循 [[Note规范|全库附件规范]]。Kubee 项目统一使用 附件文件夹/Kubee/；单游戏附件目录与笔记同名，使用 附件文件夹/Kubee/序号_游戏名/，并在笔记中用 Obsidian embed 引用。截图标题和附件名统一使用 展示页、游戏开始界面、游戏运行界面；没有对应截图时不写占位。
建议结构：
# 序号_游戏名
- ID：
- 清单：[[冷启动游戏列表]]
- 游戏类型：
> [!important] 评级：待定
>
> **优化方向**：待补充
## 01_展示页
![[附件文件夹/Kubee/序号_游戏名/01_展示页.png]]
## 02_游戏开始界面
![[附件文件夹/Kubee/序号_游戏名/02_游戏开始界面.png]]
## 03_游戏运行界面
![[附件文件夹/Kubee/序号_游戏名/03_游戏运行界面.png]]七、批量沉淀方向
随着评审推进，20_优化记录/ 里先分两类内容：
- 流程讨论：评审怎么跑、批次怎么选、是否需要调整流程。
- 共性问题记录：所有游戏反复出现的问题，例如展示页图片和 Description、资源占位、战斗表现不足。
八、下一步
- 读取冷启动游戏列表，形成
[[冷启动游戏列表]]。 - 确认缺失序号 7、8、9、22、23、29、30 是否在其他页签或已下架。
- 选第一批 5-8 个游戏做试评审。
- 用试评审验证 S/A/B 评级是否足够好用。
- 根据试评审结果更新本页工作流。
- 决定是否需要拆出独立的资源风格标准页。
九、已知模板线索
本机 F:\Coding\Kubee\本地开发包\ 下已有四类模板目录：
| 模板 | 维度 |
|---|---|
pixijs-2d-singleplayer | 2D / 单人 |
pixijs-2d-multiplayer | 2D / 多人 |
threejs-3d-singleplayer | 3D / 单人 |
threejs-3d-multiplayer | 3D / 多人 |
后续导入 42 个小游戏清单时，可以额外记录每个游戏对应的模板类型，便于横向比较同类问题。