研究综述：积木路线图¶

结论：没有找到同时具备四个特征的产品。这四个特征是：自由空间组合、组可嵌套、父级汇总卡、卡片带结构化表单。

日期：2026-10-13 范围：外部研究。树图、卡片工具、路线图工具、开源件、社区证据。 状态：完成。Reddit 通过 Arctic Shift 存档接口取得。方法与限制见第 1 节。

0. 结论¶

没有找到同时具备四个特征的产品。 这四个特征是：自由空间组合、组可嵌套、父级汇总卡、卡片带结构化表单。

最接近的三个产品各缺一块。

主要风险是命名。 Notion 已经占用「block」这个词。多数买家听到「积木」会想到 Notion。另外「乐高 / 积木」在营销文案里已经用滥。

1. 方法与限制¶

本次研究在 2026-10-13 进行。研究过程有三个工具限制。读者需要知道这些限制，才能判断证据强度。

另外两点。

1. 星标和许可证数字来自 GitHub，日期 2026-10-13。数字是近似值。
2. 产品功能以官方文档为准。官方文档没写的，标注为「未确认」。

2. 卡片 / 积木 / 空间画布工具¶

这一节回答一个问题：别人做到哪一步了。

2.1 四个特征的定义¶

1. 自由空间组合。 用户能自由摆放卡片。
2. 组可嵌套。 一个组能放进另一个组。
3. 父级汇总卡。 组有一个卡片，自动汇总子级。
4. 卡片带结构化表单。 卡片有自定义字段。

2.2 结果表¶

2.3 三个发现¶

1. 画布类工具都没有汇总卡。 Miro、FigJam、Milanote、Heptabase 都能嵌套，都不能自动汇总。嵌套只解决摆放，不解决「这一组是什么」。
2. 结构化工具都没有自由画布。 Notion、Coda、Tana、Anytype 都有字段和上卷，都没有空间画布。Notion 的 rollup 需要手工建 relation，不自动。
3. 「积木」这个词已经被占用。 Notion 的核心单元就叫 block。「block-based」现在等于「Notion 那种编辑方式」。

3. 版本层规划与路线图工具¶

这一节回答一个问题：现在的人怎么表示「大版本」。

3.1 事务跟踪器的层级模型¶

关键发现：顶层要么不存在，要么只是一个标签，要么是目标层而不是容器。 上卷存在的场合，上卷的是状态、日期和点数，从来不是「这些条目构成这个版本」。

Jira 的不满有据可查。「JIRA is an antipattern」1012 分；「I fucking hate Jira」971 分、526 评论；还有专门的站点 ifuckinghatejira.com。

3.2 路线图工具¶

共同点：路线图是「功能的视图」，不是一等嵌套容器。 没有工具让你在画布上画出版本和它的内容。

3.3 「路线图活在表格里」的证据¶

来源：HN 讨论（421 分，123 评论）。

另一条关键说法解释了为什么大家还在手工做。有人指出，视觉好看和从源数据自动生成，两者不可兼得，所以只能「do it by hand」。这条直接命中本想法的核心假设。

3.4 游戏赛季规划¶

游戏行业用「dense annual update planning」表示年度内容规划。来源：GDC 2024 演讲「Keeping the Flame Burning for 'Dead Cells'」。

行业里对 live ops 的描述：「Live ops are basically a combination of promotions, contests, events and tournaments」。

赛季是异构内容的容器，不只是工单。 这一点影响数据模型：积木不能只有「功能需求」一种类型。

工具方面：Favro 自称「The Collaborative Planning Platform for Tech & Games」，有专门的 live ops 工作流。它仍然把工作建模成卡片和表格。这是目前最接近游戏赛季规划的工具。

术语纠正：「feature pillar」不是行业标准说法。行业说「design pillars」（GDC 用词）或「content pillars」（营销用词）。

3.5 轻量替代模式¶

故事地图工具有 StoriesOnBoard、Avion、FeatureMap，Miro 也有模板。

3.6 空白在哪¶

现有方案的共同缺口是三条同时不满足。

1. 版本不是一等嵌套容器。
2. 上卷不包含「范围」。
3. 版本不能在可视化画布上编辑。

没有工具同时做到这三条。

3.7 可以借用的词汇¶

工具应该复用行业已有的词，不要自己造。

• 结构：backbone、walking skeleton、slice、epic、initiative、theme、workstream、parent work item、hierarchy level、rollup、portfolio
• 时间：cycle、iteration、sprint、release、release train、milestone、PI（Program Increment）
• 决策：bet、pitch、appetite、scope hammering、circuit breaker、hill chart、rabbit hole
• 置信度：Now / Next / Later、horizon、outcome roadmap
• 游戏：season、battle pass、content drop、update cadence、live ops、design pillar

结论：「赛季」在游戏行业是通用词，可以直接用。 非游戏场景要用「版本」或「release」。

4. 树图与层级可视化¶

这一节回答一个问题：树图这条路，前人和研究走到了哪一步。

4.1 树图谱系¶

长宽比、顺序、稳定性三者互相冲突。 改善一个，恶化另一个。这是布局层面的固有取舍。

4.2 树图的已知弱点¶

来源：马里兰大学 HCIL 树图历史页。

1. 用面积编码线性变量违反图形设计准则。 人对面积的感知不线性。
2. 小元素聚成黑块。 需要放大才能看清。
3. 新手需要 10–15 分钟学习。
4. 新手在 1–3 层、20–50 个节点时表现更好。 在 5–7 层、数千节点时更差。
5. 标签放不下。 细矩形里放文字是未完全解决的问题。深层和小面积处尤其严重。

对想法的影响： 第 4 条直接冲突。本想法要递归到顶层。建议：逻辑不限层，但同屏可见限制在 3 层。

4.3 可缩放界面（ZUI）的研究¶

4.4 最直接的先例：2004 年 PMI 研究¶

Cable、Ordóñez、Chintalapani、Plaisant，2004 年 PMI 研究会议。

做法：用树图显示 41 个项目的组合。矩形面积等于预算。颜色等于成本绩效指数（CPI）。 按项目生命周期阶段分组，并且可以按任意属性重新分组。

作者的经验结论：用户在「一次显示 50–100 个项目」时最舒适。

这是本想法最直接的先例。它在 2004 年已经做出原型。但它没有变成主流产品。 作者自己说，还需要和排程软件集成。

这是机会，也是警告信号。

4.5 工作分解结构（WBS）¶

WBS 是项目范围的层次分解，通常画成嵌套方块。成本向上汇总到父节点。「父卡片汇总子卡片」是 WBS 的标准做法。

深度经验值：多数项目 2–4 层足够。软件项目到 5 层。火控系统到 7 层。

对想法的影响： WBS 不按面积编码。深度建议 2–4 层，和「递归到顶层」的目标有张力。

4.6 实证证据比想象中弱¶

这一条最重要：不能引用「研究证明树图更好」。 证据不支持这个说法。树图在读取任务上有竞争力，在整体结构任务上弱。

4.7 没被解决的问题¶

1. 没有主流产品把面积编码用于日常工作项规划。 磁盘工具是唯一的大规模用户群。
2. 没有「树图做项目规划」的对照实验。 2004 年论文只有经验报告。
3. 编辑未被研究。 所有树图工作都是只读可视化。在面积编码的布局里拖动、新建、重排一个方块，没有先例。
4. 面积必须编码一个可量化的数值。 文件大小、预算、销售额是客观的。「工作量」是主观估计。
5. 递归深度与可读性冲突。
6. 标签在小面积处放不下。 无完全解法。
7. 语义缩放的内容设计未定义。 每层该显示什么，研究只给了零散例子。

第 3 条是真正的机会。 所有既有工作都是「看」数据，没有「用方块做规划」。这是未被探索的领域。

4.8 替代方案¶

注意：缩进树是强基线。 Kobsa 2004 显示树图没有超过普通列表浏览器。

5. 开源件与可复用组件¶

这一节回答一个问题：如果要动手做，从什么开始。

5.1 画布引擎分两族¶

这个分法决定一个关键问题：卡片里能不能放真实表单。

A 族：DOM / SVG 渲染。节点里可以放真实 HTML 表单。

B 族：canvas / WebGL 渲染。HTML 需要单独叠一层。

Konva（MIT，14.9k）、Fabric.js（MIT，31.5k）、PixiJS（MIT，48.4k）、ZRender（BSD-3，6.3k）。这些引擎没有卡片语义。HTML 需要手工覆盖。

5.2 树图库¶

没有库同时给 HTML 标签和下钻动画。 要 HTML 标签就用 d3-hierarchy 自己渲染。要现成动画就用 ECharts，放弃 HTML 标签。

5.3 最接近的先行项目¶

AFFiNE 是最接近的先行项目。 它已经把无限画布和结构化积木数据库放在一起。没有项目把空间画布和树图视图同步起来。这个配对是空白。

另外：GitHub 搜索「treemap project management」只有 6 个仓库，全部无关。这说明树图做项目管理基本没有人做。

5.4 许可证陷阱¶

1. tldraw 不是开源。 许可证只允许开发使用。原文写「Not to use the Software in Production Environments」。生产环境要付费密钥，并且不能关掉密钥校验。这是最危险的一条，因为 tldraw 技术上最合适。
2. AGPL-3.0（Plane、Vikunja、AppFlowy、Teable 核心、Formbricks 核心）。改代码并提供网络服务时，必须公开源码。不要抄进闭源产品。
3. 源码可见但不是开源：NocoDB（Sustainable Use License）、Directus、form.io。都有商业限制。
4. Focalboard 已停止维护。 仓库自己写明。不要基于它做。
5. 可以商用：React Flow、Vue Flow、Excalidraw、Konva、Fabric.js、PixiJS、d3-*、ECharts、Nivo、Recharts、visx、react-hook-form、zod、Payload、Yjs、Automerge、PartyKit。

5.5 建议的技术起点¶

1. 画布视图：React Flow（MIT）。DOM 节点里放真实表单。子流程提供父子嵌套。
2. 树图视图：d3-hierarchy（ISC）算布局，用 React 渲染，标签保持 HTML。
3. 单一数据模型：两个视图读同一棵积木树。不要维护两份模型。
4. 表单：每种积木类型存一份 JSON Schema，用 react-jsonschema-form 渲染。
5. 协同：先上普通 WebSocket。需要无冲突编辑再加 Yjs。

6. 社区证据（Reddit + Hacker News）¶

Reddit 域名无法直接抓取。这一节的 Reddit 证据来自 Arctic Shift 存档接口，返回真实的标题、正文和永久链接。HN 证据来自 Algolia 接口。查不到结果的查询，下文如实写出。

6.1 痛点证据：手工维护版本视图¶

结论：痛点在两个层面都被证实。 一是「向上汇总到高管」，二是「表格和现实脱节」。发帖人不是在抱怨工具难看，是在抱怨缺一层对象。

6.2 失败模式：重复、过期、单点维护¶

这一节是最重要的反证。产品要活下来，必须回答这些。

失败模式不是「视觉工具不好看」，是三条：重复、过期、单点维护。

对本想法的要求： 结构必须直接从工作项长出来，不能是第二份数据。草案的「拖动即归属」正好满足这一条。

6.3 树图的实际批评¶

来源：HN 讨论「Treemaps are awesome」（340 分，73 评论，2023-07-25）。

树图的强项也有共识。

1. 无论嵌套多深，都能看见最大的那几项。
2. 树图是少数能概括大型层级数据的可视化方式。

对想法的影响： 树图适合回答「谁最重」。树图不适合回答「这一组是什么」。所以汇总卡必须存在，不能只靠面积。

6.4 视觉工具的采用与放弃¶

来源：HN 讨论「Should you standardise tools in your company? Case of Miro vs. MS Whiteboard」（29 分，68 评论，2023-06-20）。

1. 采购决定压过使用体验。 公司已经买了 Office 365，不想再付一份钱。做决定的人往往不是使用者。
2. 被迫换工具会降低质量。 有团队从 Miro 换到 Lucid，评论是「It's so much worse, I hate using it」。
3. 标准化会切碎信息。 文档散在 Jira、Confluence、Figma 板里，结果是「nobody knows where to look」。
4. 留存的理由是抗人员流动。 有管理者留用 Miro，理由是它在人员流动中「reasonably good at managing data」。

6.5 路线图工具的抱怨¶

来源：HN 讨论「Ask HN: What are the most popular product roadmap tools?」（34 分，11 评论，2016）。

1. 有人用 Excel 管大里程碑和整体愿景，认为够用。
2. ProductBoard、Aha、ProductPlan 都有人推荐。
3. 最重的一条抱怨：这类工具是「the ultimate busywork tools」。使用者最后只是在「linking pieces of text together」。

6.6 负面信号¶

两条负面信号需要记录。

1. HN 上「Ask HN: What do you think about a roadmap builder tool?」（2023-11-07）只有 6 分、0 评论。同类提问在 HN 上的互动普遍很低。
2. 「Ask HN: What tools do you use to create project's public roadmap?」（2022-01-28）只有 9 分、6 评论。

解读： HN 人群对这个品类兴趣低。但是，Reddit 的 r/ProductManagement 有真实的痛点帖（见 6.1）。

结论：目标用户在产品经理群体里，不在 HN 上。 后续验证要直接找人访谈，不要靠 HN 发帖等反馈。

另外，r/gamedev 的检索没有找到赛季规划相关的痛点帖。游戏方向的证据只来自 GDC 演讲，强度弱于产品管理方向。

6.7 顶层容器的词汇¶

「wave」「train」「pillar」在任何查询里都没有找到可靠用法。

重要修正： 第 3.4 节说「赛季」在游戏行业通用。那一条的依据是 GDC 演讲里的 live ops 词汇。社区证据没有证实「赛季」被当作规划容器使用。

建议：顶层容器的名称做成用户可设置，不要写死。

7. 综合判断¶

7.1 空白是真的¶

四条独立证据都指向同一个结论。

1. 没有产品同时具备四个特征（第 2 节）。
2. 事务跟踪器的顶层要么不存在，要么是标签，上卷从不包含范围（第 3 节）。
3. 路线图工具把版本做成列或日期，不是嵌套对象（第 3 节）。
4. GitHub 搜索「treemap project management」只有 6 个仓库，全部无关（第 5 节）。

7.2 但空白比看起来窄¶

2004 年已经有直接先例。 Cable 等人的 PMI 研究用树图做了 41 个项目的组合规划，面积等于预算，颜色等于 CPI，还能按属性重新分组。

这个原型没有变成产品。原因值得追问，但至少说明：「树图加层级加汇总」本身不是新东西。

真正没有被做过的是另一件事。所有既有的树图工作都是只读的。 没有人在面积编码的布局里拖动、新建、重排方块。

结论：新意不在「看」，在「编辑」。 把这一点搞反，产品就变成一个好看的报表。

7.3 三条需要压低预期的说法¶

1. 不要说「研究证明树图更好」。 Fiedler 2020 综述了 69 项研究，结论是几乎没有可靠结论。Kobsa 2004 里树图没超过 Windows Explorer。
2. 不要假设递归越深越好。 新手在 1–3 层、20–50 个节点时表现最好。WBS 的经验值是 2–4 层。
3. 不要忽略缩进树。 缩进列表是强基线，而且免费。产品必须在「层次本身是重点」时才胜出。

7.4 最大的产品风险¶

有评论者指出，视觉好看和从源数据自动生成，两者不可兼得，所以大家只能手工做。

这条直接攻击核心假设。如果自动生成的视图不好看，人就会继续手工维护文档。

草案里的「汇总卡」设计正好回答了这一条。 自动事实保证不过期，人工叙述保证可读。这个划分不是装饰，它是产品的核心机制。研究支持保留它。

7.5 第二风险：找错了社区¶

HN 上关于路线图工具的提问，互动普遍是个位数。但是，Reddit 的 r/ProductManagement 有真实的痛点帖（见 6.1）。

结论：目标用户在产品经理群体里，不在 HN 上。 后续验证要直接找人访谈，不能靠 HN 发帖等反馈。

游戏方向更弱。r/gamedev 没有找到赛季规划相关的痛点帖。游戏方向的证据只来自 GDC 演讲，强度低于产品管理方向。

7.6 第三风险：命名¶

「block」已经被 Notion 占用。「乐高 / 积木」在营销文案里用滥了。

产品名不要用「积木」或「Block」单独成词。

8. 对想法的影响¶

这一节列出研究结论对草案的具体修改。草案见 01-想法草稿.md。

8.1 必须修改¶

8.2 必须新增¶

1. 同屏条目上限。 超过 50–100 项时，视图失去可读性。需要设计降级策略。
2. 小地图。 80% 的被试偏好有总览。但要注意：语义缩放提供线索时，总览反而拖慢速度。所以小地图要可关闭。
3. 标签降级规则。 面积小于阈值时只显示颜色，文字改为悬停显示。草案的 Q6 提到了，但需要写成硬规则。
4. 新的未决问题 Q9：面积的度量口径由谁定？ 研究说度量必须在团队内达成一致。这不是技术问题，是组织问题。
5. 新的未决问题 Q10：树图和缩进树如何取舍？ 缩进树是强基线。产品要在什么条件下默认用树图？

8.3 可以保留¶

1. 汇总卡的「自动事实 + 人工叙述」划分。 研究支持这个设计，它回答「自动生成不好看」的质疑。
2. 「积木组也是积木」的递归设计。 递归本身没问题。问题只在同屏可见层数。
3. 树图用 squarified 算法。 布局问题已经解决，直接用现成算法。
4. 「赛季」这个术语。 游戏行业用这个词。但社区证据没有证实它被当作规划容器。改成：顶层容器的名称由用户设置。 预设「赛季」和「版本」两个选项。

8.4 需要警惕但不必放弃¶

1. 递归到顶层。 逻辑上保留，视觉上限制。深层的浏览交给面包屑和下钻，不交给同屏显示。
2. 面积编码。 它对「谁最重」有效，对「这一组是什么」无效。所以汇总卡不能省。
3. 产品名。 避开「Block」和「积木」。

8.5 下一步的调整¶

草案第 11 节的四个动作需要修改。

1. 用 20 个真实条目做手工树图。改成：用 50–100 个真实条目做手工树图，验证同屏上限。
2. 访谈 3 个正在手工维护版本文档的人。保持不变。 但要确认受访者是游戏运营 / 策划 / 产品经理，不是工程师。
3. 回答 Q1 和 Q2。保持不变。 另外加上 Q9（度量口径由谁定）。
4. 读研究综述。已完成，即本文件。

新增第 5 个动作。

1. 做一个编辑动作的原型。 只做一件事：把积木拖到另一个积木上，两者成组，汇总卡自动更新。这一条验证唯一未被探索的假设。