notion-life-cascade

name	notion-life-cascade
description	当用户想在 FIOS（个人 Notion 生活管理系统）里自上而下「创建或拆解」规划时使用——设定目标、把目标拆成规划、规划拆成项目、项目拆成任务、定义新习惯、从一本书或主题启动学习链路产出笔记，或把选题安排进创作计划与任务。触发动词是 设定/制定/拆解/拆分/安排/新建（+ 目标/规划/项目/任务/习惯/创作），如 做季度规划、年度规划、为这本书做学习计划、新选题、设个新习惯、拆这个目标。不要用于：纯查看/查询/列出 目标或任务记录（那是 notion-life-system 的只读查询，别误触发本技能去新建）、一次性记录（花钱/吃饭/打卡一次 → notion-life-capture）、每日复盘起草、跨库分析——那些是独立的技能。

Notion 生活向下拆解（Life Cascade）

概述

FIOS 中自上而下逐层规划的"向导层"。四条链路：

• 执行链路：目标设定 → 规划设定 → 项目执行 → 任务执行
• 学习链路：兴趣学习/书籍阅读 → 学习笔记/书籍笔记
• 创作链路：选题收集 → 创作计划 → 任务执行
• 习惯设置：习惯分类 → 日常打卡/次数打卡

L1 目标设定 遵循 FIOS 目标管理助手方法论——严格按 ANALYZE → DESIGN → EXECUTE → FORMAT 流程。更低层级使用更轻量的循环。所有 schema 查询、读取与写入都经由 notion-life-system。

REQUIRED BACKGROUND（必备前置）： notion-life-system —— 提供 ntn CLI、scripts/notion_query.zsh、scripts/notion_page_io.zsh、references/notion-intake-rules.json。

何时使用

典型场景：

• "帮我设定 2026 目标" / "做年度规划" / "拆下半年规划" / "拆这个目标"
• "为'工作愿景'拆几个规划" / "为这个规划列项目" / "为这个项目列任务"
• "为《XXX》做笔记规划" / "为这个技术学习做笔记计划"
• "新选题 / 安排创作 / 把这个选题挂到创作计划"
• "设个新习惯，每周三次 / 每天必做"

不要用于：一次性记录（走 notion-life-system 入库）、每日复盘（走 notion-life-reflection）、跨库分析（走 notion-life-insights）。

目标方法论（仅 L1 执行链路）

以下规则来自 FIOS 目标管理助手。更低层级（L2–L4）和其他链路不需要这套。

顶层用「领域」，专项降为规划（重要约定）

FIOS 顶层目标只用「领域」年度目标（三层级）：事业精进 / 知识沉淀 / 健康基线 / 关系经营 / 财务稳健 等。具体专项（甲方项目、产品发布、认证考试…）不要建成跟领域平级的🎯目标，一律作为对应领域下的「规划」。例：必扑甲方项目 → 事业精进下规划；FIOS 公开发布 → 事业精进下规划；精力管理 → 健康基线下规划。

• 自下而上挂靠：已完成/进行中的工作要记录时，先 Survey 找对应领域目标 → 挂到它下面的规划/项目，别新开平级目标。
• 降级注意层级：FIOS 固定 4 层（领域目标→规划→项目→任务）。专项若已用满 4 层，降级时压缩（原阶段规划→项目、原项目→任务），别让最底层溢出第 5 层。
• 空壳领域（只有领域目标、还没规划）下要挂任务，必须先建规划+项目层，不能把任务直接挂到领域目标。

三层级 vs 四层级

	三层级	四层级
适用	人生领域年度系统化（学习/工作/健康/生活/财务等）	具体单一目标专项（考研/认证/产品交付/活动）
周期	年度（≈365 天）	季度到年度
拆解	按子领域 / 主要方向 → 多个规划	按 OKR Key Results → 多个规划
预定规划数	3–5	2–4

标题格式

• 三层级: 🎯 [领域]-[年度成果] 例如 🎯 学习领域-建立系统化知识管理体系
• 四层级: 🎯 [具体目标名称] 例如 🎯 通过 PMP 认证考试

三阶段规划（年度目标）

期	月数	关键规划数	每规划周期	主要四象限
基础启动期	1–3 月	2–4	2–4 周	重要紧急 + 重要不紧急
加速发展期	3–6 月	3–5	1–2 月	重要不紧急
深化巩固期	6–12 月	2–3	2–3 月	重要不紧急的系统建设

预定规划数 = 三阶段合计（三层级 ≈ 7–12，四层级 ≈ 5–9；用户可手动调）。

量化指标

每个 L1 目标必须在页面正文表格中写入 3 个以上指标： 核心指标 | 具体标准（数字+单位）| 验收方式 | 达成时间

现状分析（4 个维度）

• 能力基线: 现有技能水平 / 经验积累 / 知识储备
• 优势资源: 可利用的内外部资源 / 工具 / 人脉 / 平台
• 差距识别: 现状与目标的关键差距
• 风险: 内部（能力/时间/精力/动机）+ 外部（环境/竞争/政策）+ 缓解策略

奖励与可视化默认值

• 奖励 (select): 建议一个用户真正想要的实物——从 intake-rules 里取选项。不确定就问。
• 进度符号 (select): 默认 ▓（或在用户有偏好时询问）。
• 进度条长度 (select): 默认 25（3 个规划）/ 30（4–5 个规划）。

确认触发词（FIOS 标准）

写完一个层级后，等用户说出标准确认词，再向下递归：

进入下一级	用户确认词
规划	"依据这个新建规划"
项目	"依据这个新建项目"
任务	"依据这个新建任务"
推进期	"开始下一阶段" / "基础完成了"

不要自动递归。 把这些原话当作闸门。

核心循环 —— 6 步

按顺序执行。标了 [L1-only] 的步骤在 L2–L4（或其他链路）跳过。

1. Survey（盘点） —— scripts/notion_query.zsh <child_db> + 若非 L1 再查父级。展示："现有 N 条；最近的是 [...]"。

2. Analyze（分析） [L1-only] —— 用一次 AskUserQuestion 问 FIOS 的 5 个结构化问题（若用户已给上下文，则只问其中聚焦的几个）：

   1. 想实现的愿景和具体成果？
   2. 价值意义 / 为什么重要？
   3. 时间框架（年度 / 半年 / 季度）+ 三层级 or 四层级？
   4. 已有基础和资源？
   5. 主要挑战 / 约束 / 风险？

   对 L2（规划）只问：属于父目标的哪一期？关键产出？ L3–L4：跳过。

3. Intent（意图） —— 一次 AskUserQuestion：新增 / 延续 / 调整 / 重塑。

4. Propose（提案） —— 生成候选项。对 L1 执行链路，每个候选必须包含：

   • 标题 用正确格式（🎯 + 三/四层级 模式）
   • 目标摘要（1–2 句, 突出核心价值与意义）
   • 目标开始日期 / 截止日期
   • 预定规划数（= 三阶段合计）
   • 三期路径概要（基础启动 / 加速发展 / 深化巩固 —— 各阶段 2–3 个关键规划名）
   • 量化指标（3 个: 核心指标 + 标准 + 验收 + 时间）
   • 现状分析（4 个维度）
   • 奖励 / 进度符号 / 进度条长度（给默认值建议）
   • 一句话理由（"基于父目标 X + 用户历史 Y"）

   对其他层级/链路：最少需要 标题 + 必填字段 + 父级关联 + 理由。

5. Confirm（确认） —— 展示包含以上全部字段的完整候选。等用户自由回复（选择/修改/删除）。改完后重新展示。

6. Write（写入） —— L1 执行分两个阶段：

   • Phase A（properties）: ntn api v1/pages -X POST，带父级 data_source_id 和全部 properties。
   • Phase B（页面正文）: 构造一个 markdown 文件（见下方模板）→ scripts/notion_page_io.zsh append <new_page_id> <file>。

   对 L2–L4 / 其他链路：只写 properties；正文可选，仅当用户提供了丰富内容时才写。

   硬性规则（所有层级）：

   • 关联（relation）只能填 page ID。
   • 绝不写 doNotFillFields 里的字段（formula / rollup / button / created_time / last_edited_time / unique_id）。
   • select / status / multi_select 的值必须来自 options 列表。
   • 每条记录都汇报：db、标题、page_id、设置的关联、正文追加字节数。

写完后：停下。 引用下一个 FIOS 确认触发词（"等你说『依据这个新建规划』我就拆 L2"）。不要自动递归。

L1 目标页面正文模板

POST 返回 page_id 后，用 notion_page_io.zsh append 追加这段 markdown。纯 markdown —— 让 Notion 原生渲染。

## 目标概览与价值定位

- **目标愿景**: <1 句>
- **价值意义**: <1–2 句, why this matters>
- **时间框架**: 2026-MM-DD → 2026-MM-DD
- **管理模式**: 三层级 / 四层级
- **挑战等级**: 简单 / 中等 / 复杂

## 现状分析

- **能力基线**: ...
- **优势资源**: ...
- **差距识别**: ...
- **风险与缓解**: ...

## 三期实现路径

### 基础启动期（MM 月 – MM 月）
关键规划:
- <规划 1>: <核心内容与预期成果>
- <规划 2>: ...
成功标志: ...

### 加速发展期（MM 月 – MM 月）
关键规划:
- ...
成功标志: ...

### 深化巩固期（MM 月 – MM 月）
关键规划:
- ...
成功标志: ...

## 量化成果指标

| 核心指标 | 具体标准 | 验收方式 | 达成时间 |
|---|---|---|---|
| ... | ... | ... | ... |
| ... | ... | ... | ... |
| ... | ... | ... | ... |

## 激励机制

- 基础期完成: <具体奖励>
- 发展期完成: <具体奖励>
- 巩固期完成: <具体奖励>
- 目标达成: <终极奖励，关联 心愿奖励 db 时给出 page_id>

四条链路

执行链路

层级	DB	指向父级的反向关联	父级上的预定数字段
L1	目标设定	（无）	预定规划数
L2	规划设定	关联目标	预定项目数
L3	项目执行	规划	预定任务数
L4	任务执行	项目	（末级）

各层级预填：

• L1 目标设定 —— 见上方"目标方法论" + "页面正文模板"。必填：标题（格式）、目标摘要、目标开始日期、截止日期、预定规划数、奖励、进度符号、进度条长度。页面正文必写。
• L2 规划设定 —— 规划（标题，如 📋 [规划名]）、开始日期、截至日期、规划描述（1–2 句 + 关键产出）、预定项目数（2–4）、关联目标（L1 page_id）。
• L3 项目执行 —— 项目（标题，如 🚧 [项目名]）、开始日期、截至日期、项目描述、备注（select: 工作 / 个人成长 / 小红书 / 微信公众号 / 技术学习 / 考试学习）、四象限法则、颜色、预定任务数（3–10）、规划（L2 page_id）。
• L4 任务执行 —— 事项（标题，如 ✅ [动词+成果]）、事项日期、事项描述、任务时长(分钟)（15–240 分钟粒度）、任务四象限法则、项目（L3 page_id）。

跨链路可选项（仅当用户明确点名时才设）：项目 → 技术学习 / 书籍阅读 / 物品 / 次数打卡；任务 → 创作计划 / 电影视频 / 书籍阅读 / 技术学习。

学习链路

分支	父级	子级	反向关联
兴趣	兴趣学习	学习笔记	技术
书籍	书籍阅读	书籍笔记	书籍阅读

拆解从子级批量处开始进入（"为《X》规划 N 篇笔记"）。兴趣学习/书籍阅读 本身通常通过 notion-life-system 录入，而非 cascade。

创作链路

层级	DB	反向关联
L1	选题收集	（无，常由 n8n 填充）
L2	创作计划	选题收集
L3	任务执行	创作计划

创作计划 字段：选题、计划日期、内容分类、矩阵平台、目标用户、预计流向、核心观点、选题收集（父级）。平台状态字段（千帆投流 / 商品笔记 / 薯条加热 / 状态）保持默认。

习惯设置链路

分支	父级	子级	反向关联
日常	习惯分类	日常打卡	习惯分类
次数	习惯分类	次数打卡	习惯分类

cascade 只创建定义——不打每日勾、不写 打卡记录。

• 日常打卡（"每天必做"）：习惯、创建日期、习惯分类、进度条长度。周一到周日不勾。
• 次数打卡（"每周 N 次 / 周期累计"）：主题、开始打卡日期、打卡截止日期、目标次数、习惯分类、可选 隶属项目。

时间编排（多领域并行排到每天）

把多个领域/项目的任务排进每天时间轴时：

• 落到具体时段：事项日期用带时间的 datetime（2026-06-03T14:00:00.000+08:00），不只给日期。
• 区分工作日 / 休息日，按用户作息分配（用户作息以记忆/USER 为准；默认：工作日上班 9–18、晚间 19:30–22 自由、周末弹性）。
• 领域归时段：主业（甲方项目）排工作日白天；副业（内容/学习/产品）排晚间+周末；健康（晨练/作息）每天固定打卡。
• 每天 4–5 个任务（用户偏好，强度高）：典型工作日 = 主业白天 ×2–3 + 晚间副业 ×2 + 🌅晨练打卡；周末 3–5 个（含 120–180min 深度块）。单任务拆到 ~60min 粒度，别一天只丢 1–2 个大任务。
• 颗粒度对齐：单任务时长 ≤ 所在时段块长；晚间副业总时长 ≤2.5h 防超载。
• 已完成的不算待办：历史/已交付任务标「完成」状态，别堆在当天当待办（否则某天虚高、误导）。
• 排完用 notion_query.zsh 或带 date filter 的 query 按天回看分布，确认每天数量与不冲突。

通用规则

• L1 执行链路：ANALYZE 阶段不可省。 跳过会产出空洞的目标。5 个问题是下限，不是上限。
• L1 执行链路：页面正文不可省。 只有 properties 的一行 = 有数据没方法论。
• 先 Survey 再 Propose。 永远。
• 写入前展示完整方案。 L1 包括页面正文 markdown。
• 关联里填 Page ID，不填名称。
• 默认只拆一层。 用 FIOS 确认触发词（"依据这个新建规划"等）当闸门。不要自动递归。
• 预定规划数 / 项目数 / 任务数 是非约束性目标值 —— Notion 的公式会拿它们跟实际数量对比。
• 不写 formula/rollup/button/系统时间 字段。
• 每步只问一次 AskUserQuestion。 多问题打包会让用户跟丢。

常见错误

• L1 跳过 ANALYZE → 空洞目标，没有价值意义、没有现状基线。L1 执行链路永远跑那 5 个问题。
• L1 只有 properties 没有页面正文 → 用户看到一行目标，但背后没方法论。永远追加模板。
• 标题不是 🎯 领域-年度成果 格式（比如写成 事业精进 2026 而非 🎯 事业-XXX体系建设）→ 看起来像随手记的笔记，不像结构化目标。
• 缺 量化指标 + 三期路径 → 目标无法被追踪或执行。
• L1 page_id 还没生成就建 L2 → 孤儿行，关联目标 为空。
• 关联字段里填了标题字符串 → 关联为空。永远填 page_id。
• select/status 值不在 options 里 → API 400。先读 intake-rules。
• 没等用户说出 FIOS 触发词就自动递归 → 用户觉得被催；拆解深度变浅。
• 预填跨链路关联（比如在任务上设 电影视频）而用户没提 → 多余的关联。

完整示例："帮我设定 2026 年度目标"

1. Survey: notion_query.zsh 目标设定 → 现有目标，大多已过期。
2. Analyze（仅 L1, 5 个问题）: 用 AskUserQuestion 打包 愿景 / 价值意义 / 时间框架+模式 / 已有基础 / 风险。
3. Intent: 新增 / 延续 / 调整 / 重塑（一个问题）。
4. Propose: 3–5 个候选，每个带 标题（🎯 格式）+ 摘要 + 三期路径 + 量化指标 + 现状分析 + 奖励。每个候选附理由。
5. Confirm: 用户审阅完整方案，就地修改，批准。
6. Write: 对每个被批准的候选 —— POST properties → 拿 page_id → 构造 markdown 正文 → notion_page_io.zsh append <page_id>。汇报所有 page_id + 追加字节数。
7. Stop: "等你说『依据这个新建规划』我就拆 L2 规划设定。"