notion-life-capture

name	notion-life-capture
description	当用户想把随手输入「记录/录入」进 FIOS（个人 Notion 生活管理系统）时使用——记一笔支出/收入、记个任务待办、记读书/学习笔记、记一个选题/想法、记美食/健康/打卡、记一件人际事项等。触发词：记一下、记一笔、记个、收藏、存一下、帮我记、备忘，以及"今天/刚才 + 花了/吃了/读了/想到/联系了/买了…"。一段话含多件事会拆成多条分别入库。不要用于：查看/查询/列出已有记录（那是 notion-life-system）、成体系地设定/拆解目标规划（那是 notion-life-cascade）、写日/周/月复盘叙述（那是 notion-life-reflection）、跨库分析对比（那是 notion-life-insights）。

Notion 生活记录（Life Capture）

概述

随手说一句 → 分条 → 路由到正确的 direct_write 业务库 → 智能填好「非公式」字段 → 入库。这是和 查询 / 分析 / 设定 / 复盘 并列的「记录」动词入口。

字段权威 = notion-life-system 的 references/notion-intake-rules.json（单一事实来源）。 它由 schema 刷新脚本从用户真实 Notion 生成，含每个库的可直填字段 / 类型 / options / relation。本技能内的「高频速查卡」只是加速参考，一切以 json 为准；用户改了 Notion 属性后，多数情况靠刷新 json 即自愈，无需改本技能。

REQUIRED BACKGROUND： notion-life-system —— 复用 ntn CLI、scripts/notion_query.zsh、references/notion-intake-rules.json / .md，以及 schema 刷新三件套脚本。

何时使用（动词边界）

用本技能：把一条/多条新信息记进库。触发词 记一下 / 记一笔 / 记个 / 收藏 / 存一下 / 帮我记 / 备忘，或 "今天/刚才 + 花了/吃了/读了/想到/联系了/买了/跑了…"。

不要用于（这些是负向用例，必须分流出去）：

• 查看 / 查询 / 列出 已有记录 → notion-life-system（只读查询）
• 成体系地 设定 / 拆解 目标·规划·项目·任务 → notion-life-cascade（capture 只管零散记一条事实/事件/想法，不做向下拆解）
• 写 日/周/月 复盘叙述（今日复盘 / 周报 / 月报）→ notion-life-reflection
• 跨库 分析 / 对比 / "做得怎么样" → notion-life-insights

核心流程 —— 4 步

1. 分条 —— 把输入拆成 1 条或多条待记项。"今天午饭花了 35，还读完了《原则》" = 2 条（支出事项 + 书籍阅读）。

2. 路由 —— 按 notion-intake-rules 的场景 / 触发词，把每条匹配到一个 direct_write 业务库（共 31 个）。

   • 命中速查卡的高频库 → 直接用卡。
   • 未命中 → 读 references/notion-intake-rules.json，按各库的场景与触发词匹配。
   • 命中维度库（conditional_write）的内容 → 不直接建，转「维度库」一节处理。
   • 命中只读库（avoid_manual_write）→ 拒写并提示。

3. 智能默认决策（核心 —— 明确就写，含糊才问）：

   • 明确无歧义 + 纯 direct_write + 不需关联/新建维度 → 直接写完即报。
   • 需解析 relation（挂到某项目/账户/人物/分类）→ 先 scripts/notion_query.zsh <目标库> 查 page_id；查到就写，查不到或多义 → 一句话确认。
   • 要新建维度对象（新账户/新分类/新联系人）→ 先确认再建（见「维度库」一节）。
   • 库不明确 或 缺关键直填字段 → 一句话确认，只问最少必要项。

4. 写入与回报 —— ntn api v1/pages -X POST（带目标 data_source_id + properties）。每条记录回报：库 / 标题 / page_id / 设置的关联 / 未解析字段。批量多条时先给一行式预览再统一写。

智能填充规则

• 日期：缺省 = 今天；"明天 / 下周二 / 周末"解析成具体日期。
• 金额 / 数字：从自然语言抽取（"花了三十五" / "35 块" → 35）。
• select / status / multi_select：拿话里的词去匹配该字段的 options（取自 json）。匹配不到就用最接近的或留空 + 提示，绝不臆造新选项。⚠️实测两者行为不同：select / multi_select 塞不存在的值，Notion 不报错、自动新建该选项 → 悄悄污染选项库（比报错更隐蔽有害）；status 塞越界值则直接 400 失败。两种都 →匹配不到必须留空，仅当用户明确说"新增『X』选项"才对 select 传新值（status 选项无法这样加）。
• relation：先 notion_query.zsh 查目标库拿 page_id，不编造、不写成纯文本。归类型关联（分类/账户/类型）缺省时按「关键关联兜底」兜到「其他」(无则自动建)；身份型关联（人/项目/书）查不到才留空或问。
• title：必填，从输入提炼一个短标题。
• 绝不填：formula / rollup / button / created_time / last_edited_time / unique_id 等计算或同步字段。

高频录入速查卡（~10 库 · 字段权威以 intake-rules.json 为准）

下表是最常记的库的加速参考。字段名是各库「最小字段」，* 标记最常用的几个；options 值不在此硬写（最易漂移），运行时从 json 取并匹配。

你随口说	路由到	自动填的非公式字段	智能默认
花了X / 记一笔 / 买了X	支出事项	事项*(title)、支出金额*(number)、入账时间*(date)、描述(rich_text)、备注日期(date)；relation→支出分类·收支账户·每日复盘	日期=今天；金额抽取；账户/分类未指定→兜底「其他」(无则自动建)
收到X / 进账X	收入事项	事项*、收入金额*、入账时间*、描述；relation→收入分类·收支账户·每日复盘	日期=今天；账户/分类未指定→兜底「其他」(无则自动建)，保证汇入财务监管→第二大脑
任务 / 待办 / 明天要做X	任务执行	事项*(title)、事项日期*(date)、事项描述(rich_text)、任务时长(分钟)(number)、备注(select)、任务四象限法则(status)	日期解析"明天"；四象限/时长可空待补
读完/在读《X》	书籍阅读	书籍名称*(title)、阅读状态*(status)、读完时间/开始时间(date)、标签关键词(multi_select)、URL	状态按"读完/在读"映射 options
学习笔记 / 笔记：X	学习笔记	专注笔记*(title)、创建时间*(date)、标签(multi_select)、来源(select)、状态(status)、URL	时间=今天
想到个选题 / 选题：X	选题收集	选题标题*(title)、主要内容(rich_text)、来源(select)、状态(status)、备注	来源按 options 匹配
收藏 / 资料 / 链接X	资源收集	名称*(title)、URL*、核心思想(rich_text)、主要内容(rich_text)、标签(multi_select)、来源(status)、备注日期	有链接填 URL
吃了X / 美食 / 记菜谱	美食记录（营养菜谱库）	美食*(title)、时间(date)、标签、类型(早午晚餐)、主菜/副菜/配菜(select 选食材)、主油脂、其他配料 + 每食材的 用量/热量/碳水/脂肪/蛋白	见下方专门注释 ⬇️
体检/睡眠/身体X	身体健康	时间*(title)、记录时间*(date)、起床时间/睡眠时间(date)
打卡了X / 做了N次	次数打卡 / 日常打卡	主题/习惯*(title)、相关日期(date)；按习惯查 习惯分类 relation	先查习惯是否已存在
见了/联系了某人	事项处理	具体事项*(title)、发生日期*(date)、事项描述、状态、备注(select)；relation→社交信息	先查此人 page_id，查不到问是否建联系人

其余 21 个 direct_write 库（旅游计划、景点选择、电影视频、影视评论、物品管理、固定收支、就医跟踪、事项跟踪、打卡记录、兴趣学习、书籍笔记、每日/周/月复盘、规划设定、项目执行、目标设定、心愿奖励 等）不在卡里硬写——运行时读 intake-rules.json 取该库的可直填字段、options、relation 后再填。

注意：目标设定 / 规划设定 / 项目执行 虽是 direct_write，但它们是有方法论的结构化对象（要量化指标、三期路径、页面正文模板），一律走 notion-life-cascade，capture 不碰——别把体系化目标当普通记录草草塞一条。任务执行 是唯一例外：孤立待办（"明天要做 X"）归 capture；从项目拆解出来的任务归 cascade。

美食记录 = 营养菜谱库（特殊填法，踩过坑）：它不是简单"吃了啥"打卡，而是带营养计算的菜谱库。食材分 主菜/副菜/配菜（select，从 options 选：鸡蛋/猪肉/牛肉/鱼肉/西红柿/青椒/茄子…，不臆造新选项）+ 主油脂（花生油/橄榄油…）+ 其他配料（葱姜蒜/酱油…）。⚠️营养字段（X热量/X碳水/X脂肪/X蛋白）填「每克值」（≈每100g ÷ 100，如鸡蛋热量 1.4、花生油 9），用量填克数 —— 公式 总热量/总营养 = Σ(用量 × 每克值) 会自动汇总，另有 菜谱评分 / 营养成分 公式。别把整道菜的总热量直接填进去（会炸成几万卡）。菜谱来源 relation 可挂 家人亲人（跟谁学的）。

维度库与关键关联兜底（保证数据流向第二大脑）

FIOS 靠逐级 rollup 把底层数据汇总到第二大脑。归类/账户类 relation 一旦留空，这条记录就 rollup 不上去、成了汇不进第二大脑的孤儿（例：收入不挂「账户」→ 进不了 收支账户→财务监管→第二大脑）。所以这类关联即使用户没指定也不能空——按维度的"类型"分别处理：

① 归类型维度（分类 / 类型 / 账户 等通用归类，参与向上汇总）—— 用户没指定时自动兜底到「其他」，不留空、不打断：

1. scripts/notion_query.zsh <维度库> 查名为「其他」（或"未分类/默认"）的对象；
2. 有 → 关联其 page_id；
3. 没有 → 自动新建 title=「其他」的维度对象（免确认，这是受控的唯一兜底对象），再关联。

• 典型：收入事项/支出事项 的「分类」(→收入分类/支出分类) 与「账户」(→收支账户)；其它库的「分类/类型」同理。
• 用户明确说了具体分类/账户（"记到招行""算饮食类"）→ 查该具名对象；查不到 → 先问是否新建该具名对象；用户不建 / 暂不回应时回退兜底到「其他」（归类型关联永不留空），并提示"已暂挂『其他』，回头可改成 X"。

② 身份型关联（指向具体 人物 / 项目 / 书籍 / 具体对象）—— 不塞「其他」： 查到才关联，查不到就留空或一句话问。给身份关联硬塞"其他"会造成错误关联，比留空更糟。

③ 日记关联（→每日复盘）—— 尽量关联「今天的每日复盘」： notion_query.zsh 每日复盘 找当天那条，有就关联（让当日数据汇进日复盘 rollup），查不到不强建。

通则：绝不因为"维度库有可填字段"就往里塞业务记录；除归类型的「其他」兜底对象外，新建具名维度对象都先确认。

只读库：绝不写（11 个 avoid_manual_write）

9 个监管（时间/知识/人际/习惯/财务/旅游/家庭/影视/复盘监管）+ 月度展示 + 第二大脑。这些是公式 / rollup / 总控看板，任何情况都不手动写——把底层业务数据记对，它们会自动汇总。误判要往这里写时，停下并提示。

Schema 漂移自愈（用户改了属性导致写入报错）

触发：ntn api 写入返回错误（属性不存在 / select option 不在列表 / 类型不符 / HTTP 400）。

1. 诊断 —— 判断是 schema 漂移（字段被改名/删除、option 变了、库结构变了），还是其它错误（网络 / 权限 / TLS）。后者不刷新，直接报。
2. 自动刷新快照（只读拉取 + 重建本地 json，安全）：

   ~/.claude/skills/notion-life-system/scripts/fetch_raw_schema.zsh
   NOTION_SCHEMA_BUILD_ONLY=1 ~/.claude/skills/notion-life-system/scripts/refresh_schema.js --build-only
   ~/.claude/skills/notion-life-system/scripts/build_intake_rules.js
   

3. 重试一次 —— 用新 intake-rules.json 重新映射字段 / options，再写一次。
4. 仍失败 → 报 diff —— 把"字段 X 不见了 / 改名为 Y / option 由 A 变成 B"清楚讲给用户，交他决定怎么填，不盲目反复重试。
5. 是否回改本技能 —— 因为字段以 json 为单一来源，多数漂移靠刷新 json 自愈，不用动本技能。只有当某个高频库的录入模式整体变了（常用字段增减、库改名），才提示更新本文件的「速查卡」。

通用规则

• 明确就写，含糊才问 —— 智能默认是核心；别为每条都确认，也别在多义时硬写。
• 一次最多一个确认问题 —— 多条待记项的确认合并成一次。
• relation 填 page_id，先查不编造。
• select/status 值必须取自 options，不臆造。
• 不碰公式/汇总/系统字段。
• 只读库绝不写；维度库仅确认后建。
• 写入偶发失败先重试一次 —— ntn 偶有间歇性失败（返回空 / 非 page 对象，但 JSON 合法、并非字段或 option 错误）；原样重试一次通常即成功。连续失败再按「Schema 漂移自愈」诊断。
• 写完逐条回报 page_id，让用户可核对。

常见错误

• 把一段含多件事的话只记成一条 → 该分条的没分条。
• 关联字段写人名/项目名的纯文本而非 page_id → 关联为空。Fix：先查。
• select 值硬塞一个 options 里没有的词 → API 400。Fix：匹配 options，匹配不到留空+提示。
• 往监管/第二大脑/月度展示写 → 违反只读。Fix：记到底层 direct_write 库，让它自动汇总。
• 漂移报错后凭印象改字段名重试 → 越改越乱。Fix：先刷新 json 拿真实结构，再重试一次。
• 把"成体系建目标/规划"当普通记录处理 → 应转 notion-life-cascade。

完整示例

输入："今天午饭花了 35，还读完了《原则》"

1. 分条 → ①支出 ②读书。
2. 路由 → ①支出事项 ②书籍阅读，都是 direct_write，无歧义、无需关联。
3. 决策 → 两条都直接写。
4. 写入：
   • 支出事项：事项=午饭、支出金额=35、入账时间=2026-06-03 → page_id a1…
   • 书籍阅读：书籍名称=原则、阅读状态=读完(匹配 options)、读完时间=2026-06-03 → page_id b2…
   • 回报两条 page_id。

输入："约了张三下周二喝咖啡" → 事项处理（具体事项=和张三喝咖啡、发生日期=下周二解析）；relation→社交信息：先 notion_query.zsh 社交信息 查"张三"，查到则关联，查不到 → 问"通讯录没有张三，要新建联系人吗？"

负向："看看我有哪些目标" → 不处理，提示这是查询 → notion-life-system。