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，安全）：
   ```bash
   ~/.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。