| 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 条或多条待记项。"今天午饭花了 35，还读完了《原则》" = 2 条（支出事项 + 书籍阅读）。
-
路由 —— 按 notion-intake-rules 的场景 / 触发词，把每条匹配到一个 direct_write 业务库（共 31 个）。
- 命中速查卡的高频库 → 直接用卡。
- 未命中 → 读
references/notion-intake-rules.json，按各库的场景与触发词匹配。
- 命中维度库（
conditional_write）的内容 → 不直接建，转「维度库」一节处理。
- 命中只读库（
avoid_manual_write）→ 拒写并提示。
-
智能默认决策（核心 —— 明确就写，含糊才问）：
- 明确无歧义 + 纯
direct_write + 不需关联/新建维度 → 直接写完即报。
- 需解析 relation（挂到某项目/账户/人物/分类）→ 先
scripts/notion_query.zsh <目标库> 查 page_id；查到就写，查不到或多义 → 一句话确认。
- 要新建维度对象（新账户/新分类/新联系人）→ 先确认再建（见「维度库」一节）。
- 库不明确 或 缺关键直填字段 → 一句话确认，只问最少必要项。
-
写入与回报 —— 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 不上去、成了汇不进第二大脑的孤儿（例：收入不挂「账户」→ 进不了 收支账户→财务监管→第二大脑）。所以这类关联即使用户没指定也不能空——按维度的"类型"分别处理：
① 归类型维度（分类 / 类型 / 账户 等通用归类，参与向上汇总）—— 用户没指定时自动兜底到「其他」，不留空、不打断：
scripts/notion_query.zsh <维度库> 查名为「其他」（或"未分类/默认"）的对象；- 有 → 关联其 page_id；
- 没有 → 自动新建 title=「其他」的维度对象（免确认，这是受控的唯一兜底对象），再关联。
- 典型：收入事项/支出事项 的「分类」(→收入分类/支出分类) 与「账户」(→收支账户)；其它库的「分类/类型」同理。
- 用户明确说了具体分类/账户（"记到招行""算饮食类"）→ 查该具名对象；查不到 → 先问是否新建该具名对象；用户不建 / 暂不回应时回退兜底到「其他」（归类型关联永不留空），并提示"已暂挂『其他』，回头可改成 X"。
② 身份型关联（指向具体 人物 / 项目 / 书籍 / 具体对象）—— 不塞「其他」： 查到才关联，查不到就留空或一句话问。给身份关联硬塞"其他"会造成错误关联，比留空更糟。
③ 日记关联（→每日复盘）—— 尽量关联「今天的每日复盘」： notion_query.zsh 每日复盘 找当天那条，有就关联（让当日数据汇进日复盘 rollup），查不到不强建。
通则：绝不因为"维度库有可填字段"就往里塞业务记录；除归类型的「其他」兜底对象外，新建具名维度对象都先确认。
只读库：绝不写（11 个 avoid_manual_write）
9 个监管（时间/知识/人际/习惯/财务/旅游/家庭/影视/复盘监管）+ 月度展示 + 第二大脑。这些是公式 / rollup / 总控看板，任何情况都不手动写——把底层业务数据记对，它们会自动汇总。误判要往这里写时，停下并提示。
Schema 漂移自愈（用户改了属性导致写入报错）
触发：ntn api 写入返回错误（属性不存在 / select option 不在列表 / 类型不符 / HTTP 400）。
- 诊断 —— 判断是 schema 漂移（字段被改名/删除、option 变了、库结构变了），还是其它错误（网络 / 权限 / TLS）。后者不刷新，直接报。
- 自动刷新快照（只读拉取 + 重建本地 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
- 重试一次 —— 用新
intake-rules.json 重新映射字段 / options，再写一次。
- 仍失败 → 报 diff —— 把"字段 X 不见了 / 改名为 Y / option 由 A 变成 B"清楚讲给用户，交他决定怎么填，不盲目反复重试。
- 是否回改本技能 —— 因为字段以 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，还读完了《原则》"
- 分条 → ①支出 ②读书。
- 路由 → ①支出事项 ②书籍阅读，都是
direct_write，无歧义、无需关联。
- 决策 → 两条都直接写。
- 写入：
- 支出事项：事项=午饭、支出金额=35、入账时间=2026-06-03 → page_id
a1…
- 书籍阅读：书籍名称=原则、阅读状态=读完(匹配 options)、读完时间=2026-06-03 → page_id
b2…
- 回报两条 page_id。
输入："约了张三下周二喝咖啡"
→ 事项处理（具体事项=和张三喝咖啡、发生日期=下周二解析）；relation→社交信息：先 notion_query.zsh 社交信息 查"张三"，查到则关联，查不到 → 问"通讯录没有张三，要新建联系人吗？"
负向："看看我有哪些目标" → 不处理，提示这是查询 → notion-life-system。
