积木路线图 · 初版想法沉淀¶
结论：这个想法成立。核心是补上「版本」这一层对象。
状态：草稿 v1 日期：2026-10-13 范围：本文件只写想法。本文件不写实现。 后续：研究结论和修订建议见
02-研究综述.md。本文件保持研究前的原样。
0. 结论¶
这个想法成立。核心是补上「版本」这一层对象。
它和现有工具的区别只有一条：层级结构从画布上长出来，不需要人另外维护。
1. 问题¶
开发过程中，想法持续产生。
表单解决单条需求的问题。表单保证每条提交的格式一致。表单让需求和验收标准对齐。这一层已经成熟。
表单之上缺一层。这一层是「大版本」。没有工具表示「赛季 1 包含哪些大功能」。
于是策划或运营手工收集条目。然后写一个文档，或者拉一张表格。文档和条目之间没有连接。
手工整理有三个代价。
- 版本视图和条目脱节。条目改了，文档不跟着变。
- 版本视图只有一个人维护。这个人离开后，视图失效。
- 文档和表格看不出比重。看不出哪个模块占用最多工作量。
2. 概念与术语¶
本想法用一个比喻：积木和房子。以下是正式术语。
| 术语 | 英文 | 定义 |
|---|---|---|
| 积木 | Block | 最小工作单元。积木是一张卡，同时是一张表单。 |
| 积木组 | Group | 若干积木的容器。积木组本身也是积木。 |
| 汇总卡 | Summary Card | 积木组顶部的卡。汇总卡描述组内的内容。 |
| 版本 | Version | 最顶层的容器。游戏团队称版本为「赛季」。 |
| 白板 | Board | 自由摆放积木的画布。 |
| 树图 | Treemap | 用矩形面积表示权重的嵌套视图。 |
| 权重 | Weight | 一个数值。权重决定积木在树图中的面积。 |
| 上卷 | Rollup | 子级的数据汇总到父级。 |
术语规则：
- 一个概念只用一个词。「积木」不再叫「卡片」「节点」「块」。
- 一个词只表示一个概念。「组合」只表示动作，不表示对象。对象叫「积木组」。
3. 对象模型¶
结构是树。布局是视图。两者分开保存。
{
"id": "blk_7f3a",
"type": "block", // block | group | version
"title": "赛季通行证奖励重构",
"parentId": "grp_02", // 树结构：每个积木只有一个父级
"children": [], // 积木组和版本才有子级
"form": { // 表单：积木的结构化字段
"schemaId": "feature_request_v3",
"fields": { "目标": "...", "验收标准": "...", "负责人": "..." }
},
"weight": 8, // 权重：面积来源
"status": "进行中",
"tags": ["赛季1", "奖励"],
"layout": { // 布局：只属于某一块白板
"boardId": "board_main",
"x": 320, "y": 180, "w": 240, "h": 160
}
}
三条设计约束。
- 树是数据，坐标是视图。 同一棵树可以有多个布局。换布局不改变结构。
- 积木组是一种积木。 类型相同，行为相同。因此嵌套没有层数上限。
- 表单挂在积木上。 点开积木就点开表单。表单不是另一个页面。
4. 两种视图¶
同一个数据，两种看法。两种视图可以互相切换，也可以并排。
| 视图 | 回答的问题 | 主要操作 |
|---|---|---|
| 白板 | 「这些事怎么摆放？」 | 拖动、分组、连线的自由摆放 |
| 树图 | 「这一版里谁最重？」 | 点击下钻、缩放、比较面积 |
白板视图
- 积木是自由摆放的矩形。
- 把积木拖到另一个积木上，两者自动成组。
- 积木组显示为一个带标题栏的大矩形。
- 白板表达人的意图。位置有意义。
树图视图
- 积木组是容器矩形。子积木是容器内的矩形。
- 矩形面积等于权重。面积一眼看出比重。
- 点击一个积木组，此组放大到全屏，子级展开。
- 顶部显示面包屑。面包屑显示当前位置。
- 位置自动计算。位置没有意义，只有面积有意义。
两种视图的张力
白板保留人的摆放意图。树图自动计算面积。两者可能冲突。
处理方式：白板保存手动坐标。树图只读权重。白板加一个「按权重整理」按钮。按下后手动坐标按权重重排。
5. 关键交互¶
- 拖动积木。积木移动到新位置。
- 把积木拖到另一个积木上。系统弹出确认。确认后两者成组。
- 点击积木组。视图下钻一层。子级填满屏幕。
- 点击面包屑。视图回到指定层。
- 点击积木。侧栏打开表单。
- 拖动积木组边框。权重随面积变化。
- 点击「折叠」。积木组收起为一个矩形。矩形显示汇总卡的标题。
- 按
Esc。视图回到上一层。
警告： 删除积木组会连带删除组内所有积木。系统在删除前要求输入组名确认。
6. 汇总卡规则¶
汇总卡是父级卡片。汇总卡回答「这一组是什么」。
汇总卡的内容分两类。
自动事实（系统生成，人不能改）
- 子级数量
- 状态分布（未开始 / 进行中 / 已完成）
- 权重合计
- 完成百分比
- 风险项数量
人工叙述（人写，系统不覆盖）
- 一句话目标
- 这一组为什么存在
- 验收标准
这个划分解决一个冲突：纯自动的汇总卡读起来像报表。纯人工的汇总卡会过期。自动事实保证不过期，人工叙述保证可读。
7. 走查场景¶
场景：赛季 1 上线前两周
- 策划打开树图视图。顶层显示「赛季 1」。
- 赛季 1 下有四个积木组：战斗、社交、商业化、技术债。
- 商业化组的矩形最大。策划立刻知道商业化占用最多工作量。
- 策划点开商业化组。组内是 12 个积木。
- 其中 3 个积木是「未开始」。策划把这 3 个积木拖到「赛季 2」。
- 商业化组的汇总卡自动更新。权重合计从 48 降到 31。
- 策划在汇总卡里补一句话：本季只做首充礼包，不做订阅。
- 策划切到白板视图。四个组的位置是上周排好的。位置没有变。
场景：新想法进入
- 任何人在表单里提交一个想法。
- 想法先落在「待分类」区。待分类区是一个特殊积木组。
- 每周评审时，负责人把想法拖进对应的积木组。
- 拖入即归属。不需要另外更新文档。
8. 未决问题¶
这些问题没有答案。它们决定产品形态。
| 编号 | 问题 | 影响 |
|---|---|---|
| Q1 | 一个积木能否同时属于两个积木组？ | 树要求单父级。树图要求单父级。真实需求常跨版本。跨版本需要图结构。 |
| Q2 | 面积表示什么？工作量、条目数、还是优先级？ | 三者不能同时表示。必须选一个。建议选工作量。 |
| Q3 | 权重由人填还是由子级累加？ | 叶子节点由人填。非叶子节点由子级累加。这条规则要写死。 |
| Q4 | 层级上限是几层？ | 树图超过 4 层后标签放不下。建议可见 3 层，逻辑不限层。 |
| Q5 | 这是新工具还是现有工具的视图？ | 如果是视图，就要接 Jira、Linear、GitHub Issues。如果是新工具，就要自己做表单和权限。 |
| Q6 | 1000 个积木在同一屏时如何显示？ | 面积小于阈值时只显示颜色。文字改为悬停显示。 |
| Q7 | 谁有权改结构？ | 如果所有人可改，结构会乱。如果只有负责人可改，负责人成为瓶颈。 |
| Q8 | 白板的手动坐标和树图的自动面积冲突时，以谁为准？ | 建议：白板优先显示，树图优先统计。 |
9. 命名候选¶
名称要能被记住，也要能搜索到。
| 候选 | 说明 | 风险 |
|---|---|---|
| BlockMap | 积木 + 树图 | 太通用，重名多 |
| Brick | 砖 | 已有同名产品 |
| NestPlan | 嵌套 + 计划 | 偏企业风 |
| 积木图 | 中文直译 | 中文圈易记 |
| Trellis | 花架 | 隐喻好，但不好念 |
命名规则：不要用「Block」单独做名字。「Block」已经被大量产品占用。
10. 最小可用版本¶
第一版只做四件事。
- 三种对象：积木、积木组、版本。
- 一种视图：树图。带点击下钻。
- 一张表单：积木的结构化字段。
- 汇总卡：自动事实 + 一句话叙述。
第一版不做白板。白板是第二版。
理由：树图验证核心假设。核心假设是「层级结构可视化能替代手工文档」。白板验证的是次要假设。
11. 下一步¶
- 用 20 个真实条目做一次手工树图。检查层级是否够用。
- 访谈 3 个正在手工维护版本文档的人。记录他们现在的文档长什么样。
- 回答第 8 节的 Q1 和 Q2。这两个问题决定数据模型。
- 见
02-研究综述.md。研究综述列出已有的同类产品。