1. 为什么现代项目协作必须从“平铺清单”进化到“树形层级”？

在复杂项目研发、企业级 OKR 落地与个人知识工程管理中，任务从来都不是孤立存在的：

• 目标与行动脱节：顶层战略（如“上线海外支付功能”）如果直接塞入单一待办列表，会因为颗粒度过粗导致执行人员无从下手；而如果直接拆解成几十个琐碎碎步，又会导致项目全局看板被细碎事项淹没，管理者无法掌控总体进展；
• 多级拆解依赖沉重：在传统的数据库设计中，若为了实现“项目 -> 迭代 -> 模块 -> 任务”，往往需要创建 3~4 个彼此独立的数据库并建立复杂的跨库双向关联（Relation）。这种架构维护成本极高，视图切换繁琐，且在移动端浏览极易迷失；
• 进度难以逐级汇总：当下属各个子任务陆续完成时，项目经理必须手动修改父级需求的状态，或者依赖脆弱的传统 Rollup 汇总，无法根据子任务的不同权重进行精确的百分比计算。

Notion 官方推出的 Sub-items（子项/子任务） 功能，基于底层的**自反关联（Self-referencing Relation）**机制，完美解决了这一行业顽疾。配合 Formula 2.0 数组处理函数，我们能够在单一数据库中轻松构建任意深度的无限树状任务结构（WBS），并实现进度的毫秒级自动聚合。

---

2. 平铺任务清单 vs 跨库级联关联 vs 原生 Sub-items 架构全维度对比

在启动项目管理体系设计前，深入理解不同数据架构方案的优劣边界至关重要：

评估维度	传统平铺任务清单（Flat List）	跨库级联多表架构（Multi-DB Hierarchy）	原生 Sub-items 树形架构（Self-relation）
底层数据模型	单一数据库，无父子关系	3~4 个独立数据库通过外键级联关联	单一数据库内部构建自反双向关联
WBS 结构化展开	无法折叠展开，列表冗长臃肿	必须通过嵌套内联数据库（Linked DB）查看	原生树形缩进箭头，支持无限层级一键折叠
进度汇总便利度	仅支持全局整体百分比	依赖多层 Rollup 穿透，配置极度繁琐	Formula 2.0 直接数组计算，公式一目了然
视图复用与切换	简单，但缺乏层级感	极差，每个库需单独配置视图与筛选器	极高：同一套数据秒切甘特图、看板、表格
维护与学习成本	低，但仅适用于微型简单待办	极高，新增属性或状态机需多表同步修改	中低：字段统一，新手与资深团队皆可平滑上手
适用业务场景	个人每日即时备忘清单	跨跨国跨部门超大型矩阵式研发项目	中大型敏捷研发、Sprint 迭代、OKR 与个人 GTD

---

3. 实战配置一：开启与规范化配置原生 Sub-items 树形架构

在 Notion 中，Sub-items 并非一个独立的字段类型，而是一组由系统自动维系的一对多自反关联。

步骤 1：激活数据库 Sub-items 开关

1. 打开项目任务总表（如 Projects & Tasks），点击右上角的 ...（数据库选项菜单）；
2. 在下拉菜单中找到并点击 Sub-items；
3. 系统将弹出字段命名配置面板，默认建议保持清晰语义：
   • Parent item（父项属性）：重命名为 父任务 (Parent Task)；
   • Sub-item（子项属性）：重命名为 子任务 (Sub-items)；
4. 点击 Turn on sub-items 确认开启。

步骤 2：理解底层的自反数据结构

开启后，Notion 会在当前数据库中自动新增两个相互对绑的 Relation 属性：

• 父任务：单选关联（每个子任务只能归属于 1 个直接上级父任务）；
• 子任务：多选关联（每个父任务可以拥有 N 个直接下级子任务）。

在表格视图中，带有子任务的记录左侧将自动浮现三角形折叠手柄（▶ / ▼），点击即可展开下属所有子事项，并自动呈现层级缩进。

---

4. 实战配置二：基于 Formula 2.0 实现子任务进度自动聚合（Progress Rollup）

在项目管理中，最核心的需求是：父任务的完成百分比必须由其所有子任务的状态动态驱动。如果子任务全部完结，父任务进度应为 100%；若无子任务，则取父任务自身的勾选状态。

以往的传统 Rollup 无法实现“有子任务按子任务算，无子任务按自身算”的条件分支。在 Formula 2.0 中，我们可以使用 lets()、map() 与 filter() 一气呵成。

进阶公式：加权完成率与动态视觉进度条

新建 Formula 属性，命名为 动态进度 (Progress)，输入以下公式代码：

lets(
  /* 1. 获取直接子任务列表与当前任务自身状态 */
  subs, prop("子任务 (Sub-items)"),
  selfDone, prop("状态") == "已完成",
  
  /* 2. 统计子任务总数与已完成子任务数 */
  totalSubs, subs.length(),
  doneSubs, subs.filter(current.prop("状态") == "已完成").length(),
  
  /* 3. 计算最终百分比（无子任务则根据自身状态计算） */
  ratio, if(
    totalSubs > 0,
    round((doneSubs / totalSubs) * 100) / 100,
    if(selfDone, 1, 0)
  ),
  
  /* 4. 构建视觉进度条条块（10格刻度） */
  filledCount, round(ratio * 10),
  emptyCount, 10 - filledCount,
  barStr, "■".repeat(filledCount) + "□".repeat(emptyCount),
  
  /* 5. 结合 style() 输出高亮进度文字 */
  pctStr, (ratio * 100).format() + "%",
  
  ifs(
    totalSubs == 0,
    if(selfDone, style("✓ 独立任务已完结", "green", "b"), style("⚪ 待执行", "gray")),
    ratio == 1,
    style(barStr + " " + pctStr + " (全部完工)", "green", "b"),
    ratio >= 0.6,
    style(barStr + " " + pctStr + " (推进顺畅)", "blue"),
    ratio > 0,
    style(barStr + " " + pctStr + " (进行中)", "yellow"),
    style(barStr + " 0% (尚未启动)", "gray")
  )
)

深度原理解析：

1. subs.filter(current.prop("状态") == "已完成")：Formula 2.0 赋予了列表对象原地遍历求值的能力，直接跨记录提取子任务状态，无需额外创建中间 Rollup 属性；
2. totalSubs > 0 分支防御：当节点为底层独立原子任务时，自动回退到自身状态判定，确保整张数据表的展示逻辑自洽；
3. style() 动态配色：进度在 100% 时呈现醒目的绿色粗体，进行中呈现蓝色，0% 呈现灰色，极大提升了看板扫描效率。

---

5. 实战配置三：自动计算任务层级深度（Depth Level）与分类标识

在导出报表或设置视图过滤时，我们常常需要区分“哪些是顶层 Epic/里程碑，哪些是中间模块，哪些是底层的微任务”。

我们可以编写一个自动判定任务层级深度的公式属性 层级架构 (Level)：

lets(
  hasParent, not(empty(prop("父任务 (Parent Task)"))),
  parentItem, prop("父任务 (Parent Task)").first(),
  hasGrandParent, hasParent and not(empty(parentItem.prop("父任务 (Parent Task)"))),
  hasSubs, prop("子任务 (Sub-items)").length() > 0,
  
  ifs(
    not(hasParent) and hasSubs,
    style("  一级目标 (Epic)  ", "purple", "purple_background", "b"),
    hasGrandParent,
    style("  三级执行 (Sub-task)  ", "gray", "gray_background"),
    hasParent and hasSubs,
    style("  二级模块 (Feature)  ", "blue", "blue_background"),
    style("  独立事项 (Task)  ", "default", "gray_background")
  )
)

通过这一公式，系统会自动为所有记录打上“一级目标”、“二级模块”或“微任务”胶囊标签，为后续的看板分组与高级筛选提供结构化支撑。

---

6. 实战配置四：多维视图下的子任务呈现与过滤策略

树形结构的强大之处，在于它能够根据不同团队角色的关注点进行精准视图投射：

视图 A：项目总监专用的“顶层看板（Executive Board）”

• 业务诉求：总监只关心核心交付物（Epic），不希望看板被几百个小任务卡片挤爆。
• 配置规则：
  1. 新建 Board（看板）视图，按 状态 分组；
  2. 点击右上角 Filter（筛选），添加规则：父任务 (Parent Task) 为空（Is empty）；
  3. 卡片展示属性勾选：动态进度 (Progress) 与 负责人员。
• 效果：看板上仅展示一级大任务，但每张卡片都能实时看到下属所有子任务的完成百分比进度条。

视图 B：工程师每日执行专用的“原子待办清单（My Tasks）”

• 业务诉求：一线开发者只关心分派给自己的具体动作，且需要明确知道它归属于哪个上级需求。
• 配置规则：
  1. 新建 Table 或 List 视图；
  2. 筛选规则 1：负责人 包含 当前登录用户 (Me)；
  3. 筛选规则 2：状态 不等于 已完成；
  4. 显示字段勾选：任务名称、父任务 (Parent Task)、截止时间。

视图 C：研发甘特图（Timeline View）联动展开

在时间线视图中，开启 Sub-items 后，可以直接点击展开父任务排期。配合 Dependencies（前后置依赖） 连线，子任务的时间变动可以自动推移后续关联项，实现端到端的 WBS 动态排期。

---

7. 工程化避坑指南与性能优化建议

在实际团队落地 Sub-items 时，若缺乏规范约束，容易引发数据混乱甚至页面卡顿：

1. 严格规避循环依赖（Circular Self-reference）： 切勿将任务 A 设为任务 B 的父任务，又反向将任务 B 设为任务 A 的父任务。尽管 Notion 具有底层防死锁保护，但这会导致 Formula 2.0 的递归调用抛出计算异常并中断进度汇总；
2. 控制层级深度在 3 层以内： 在工程实践中，推荐采用 Epic (一级) -> Feature (二级) -> Task (三级) 的 3 层结构。超过 4 层的树状结构不仅会使前端折叠缩进在小屏幕下严重挤压，还会增加团队认知负荷；
3. 删除父任务时子任务的级联处理： 在 Notion 中删除父任务时，其下属的子任务不会被级联删除，而是会变为没有父级的“孤儿记录”。在重构项目架构时，建议先使用批量选择工具迁移或归档子任务，再删除父级节点。

---

8. 站内相关高阶教程与扩展阅读

掌握 Notion Sub-items 树形架构后，建议结合以下数据库模型与自动化工作流进行联动构建：

• Notion 数据库多维模型设计与多对多关联进阶实战
• Notion 甘特图与任务依赖（Dependencies）实战指南
• Notion 自定义按钮（Buttons）与复合自动化工作流实战
• Notion Formula 2.0 函数与正则表达式速查手册
• Notion 数据库架构与多维模型速查手册
• 研发团队 Sprint 敏捷项目管理全景指南