【系统迭代】 本文是我个人系统内某条规则、参数或字段的版本升级日志。所有改动仅服务于我运行了 7 年的量化生活模型，不构成任何通用方法论或"上手教程"。若你发现其中某一步对你也有用，那是巧合；若觉得晦涩，说明我们的系统语言不兼容，不必勉强。

1. 变更声明

版本号：v2026.08（2026-08-14 整改）

待办完成前的优先级只决定处理当天的展示排序，完成后的优先级只决定各级回顾的粒度。

这一句是本次迭代全部改动的锚点。它改了元属性与优先级这两个字段的语义归属，并顺带砍掉了周回顾报告和三个长期无人维护的查询。下面是改了什么、为什么改、还留了什么。

2. 症状与旧证据

旧证据：

1. Daily Note 日记模板中包含 health events news summary 等元属性字段（2026-08-14 后移除）
2. 2026-W30_Review 周回顾还包含
   1. 对所有完成待办进行 Daily Note / KanBan / Projects 分文件查询
   2. 线索/普通事件 索引展示
   3. 延期/阻塞任务
   4. 中断与紧急事件
3. 2026-06_Review 月回顾中还有对日记元属性 Yaml 字段的 dataview 查询

失控的表现：一条信息，两个家

整改前，一条"急性肠胃炎"可能同时落在三个地方：日记 frontmatter 的 health 字段、日程计划里的 #Topic/Focus/Health 待办、健康管理笔记的病例目录；而"戴以初湿疹"则只进了 戴以初.health 字段，没进待办。

结果是月回顾里 TABLE health 的 dataview 和 #Topic/Focus/Health 的 tasks 查询各拉出一半，谁都不是全貌。这种归属权二义性没有规则约束，全看当天手感——手感好就两边都记，手感差就两边都漏。

3. 诊断

根因：事实与事件没有二分

问题不在"元属性"或"待办"哪个更好，而在于我把两类性质不同的信息塞进了同一个"日记记录"动作：

• 事实（fact）：一次性写入、不再变化、需要数值聚合——奶量、睡眠、身高体重、地点、天气。
• 事件（event）：有生命周期、需要跟进/完成/异常升级——健康异常、重要事件、新闻、总结。

事实适合元属性（dataview 能做数值趋势聚合，tasks 做不了）；事件适合待办（有完成态，能按标签与优先级被各级回顾索引）。整改前两者混在一起，必然出现"同一件事两个系统各记一次、回顾时不知以谁为准"的交集。

为什么必须归一化：先有病，后有药

时间线是反的——不是"因为有映射表所以合并元属性"，而是"先发现双通道让回顾索引无法归一化，才去制定了映射表"。

回顾索引映射表完全基于"待办标签 + 优先级"。也就是说，回顾系统的主力数据源是待办体系，元属性只是日记的事实快照。既然主力是待办，凡有生命周期的事件型信息就该并入待办，元属性只留测量型快照。这样每个回顾板块只有一个数据源，交集消失——而映射表，正是把这个归一化结果落成可查询规则的产物。

4. 设计方案

用一句 ETL 概括这次整改：把个人信息的采集（Extract）— 清洗（Transform）— 装载（Load）从"双通道各做各的"收敛成一条流水线。感知层只负责 E（原始信息落入统一日记容器），周回顾负责 T（补标签、按映射表校准优先级），各级回顾负责 L（按索引映射表做层截流查询）。ETL 是与工具无关的稳定模式，Obsidian 换成别的也成立，这是本次迭代最耐久的资产。

4.1 单通道：事件走待办，yaml 只留测量型

日记 frontmatter 删掉四个事件型字段：

保留在 yaml 的只剩测量型字段：戴以初量化（奶量/睡眠/身高/体重）、工时、地点、天气，作为 dataview 趋势聚合的唯一来源。

戴以初事件字段（event/health/vaccination/milestone）暂不迁移——它们横跨"量化快照"与"事件"两类，一次迁移会连带 Overview 展示逻辑一起改，本次挂起。

4.2 双轴编码：标签 × 优先级

事件进入待办后，靠两个轴完成编码：

• 标签（Topic/Focus/*）= 类型轴：Health / Change / Risk / Clue / Thoughts / Habit / Adjust / System / Meals。
• 优先级 = 粒度轴。

优先级从单一执行语义升级为二段语义：

• 完成前：只决定处理当天的展示排序（Highest 排最前、Lowest 排最后）。
• 完成后：在周回顾时按索引映射表调整，只决定各级回顾的粒度。

一个待办"当天的紧迫程度"与"它值不值得进年回顾"由此被拆成两件事，分别在两个时间点、由两个动作决定。

4.3 层截流：索引映射表

索引映射表给每个"标签 × 优先级"组合指定了可被哪一级回顾索引，实现"高级别回顾不出现低优先级待办"：

表中「日」「周」「月」「季」「年」表示该条目可在对应级别的回顾报告中被展示或分析；「/」= 该优先级/类型组合在我的系统中极少出现或不存在。

例如 #Topic/Focus/Health 的 Highest → 日周月季年，Lowest → 仅日。于是月回顾查询只拉 priority >= Medium 的 Health 条目，"今天扁桃体略不适"这类 Lowest 不会再污染月回顾。

落到系统的动作，就是各级回顾的 tasks 查询入口加准入条件——查询本身成为规则，而非靠人肉过滤。

5. 整改后证据

新证据：

1. 2026-08-14 日记中的健康事件开始以 #Topic/Focus/Health + priority 进入 task 通道；DeepSeek Harness 发布 按原先规范应记录在 news 字段中，而现在也以 #Topic/Focus/Change + priority 进入 task 通道
2. 2026-W32_Review 周回顾增加未来待办收集区用于 GTD 处理
3. 2026-W32_Review 周回顾增加根据索引映射表对已完成待办进行标签优先级调整
4. 2026-W32_Review 周回顾移除周回顾报告
5. 2026-07_Review 月回顾增加"LLM 根据索引映射表对本月全部待办分析，只做观察和聚类，不给行动建议"

前后对照

一条必须写死的边界：展示准入 vs 分析输入

月回顾"机会与风险"板块按映射表过滤（展示准入），但"模式识别"板块需要跨标签全量聚类（分析输入）——否则"本月重复出现 3 次以上的模式"会被层截流砍掉。

所以层截流约束的是展示，不约束分析。这条边界若不写死，未来会有人在"为什么月回顾还能看到 Lowest"上自我怀疑。

6. 信息流向改变图

本图是 回顾体系架构图 五级回顾全景的整改前后对照——前者描述静态全景，本文记录它的一次规则升级；而它本身是 当前人生系统架构图 中「🔄 周期回顾」节点的内部展开。

Before（整改前）：双通道并行

graph LR
    A[感知层<br/>日记 / 待办原始文本] --> B1[yaml 元属性<br/>health / events / news / summary]
    A --> B2[待办文本<br/>标签 + 优先级]
    B1 --> C1[dataview 查询]
    B2 --> C2[tasks 查询]
    C1 --> D1[月 / 季 / 年回顾]
    C2 --> D2[周 / 月回顾]
    C1 -. 同一事件两边都记 / 都不记 .-> C2

After（整改后）：单通道 + 层截流

graph LR
    A[感知层<br/>日记 / 待办原始文本<br/>统一日记容器<br/>唯一主观入口] --> B[待办任务<br/>标签 = 类型轴 × 优先级 = 粒度轴]
    B --> C[周回顾 GTD 引擎<br/>补标签 / 按索引映射表校准优先级]
    C --> D1[统一日记容器]
    C --> D2[周回顾]
    C --> D3[月回顾]
    C --> D4[季回顾]
    C --> D5[年回顾]
    E[yaml 测量型字段<br/>戴以初量化 / 工时 / 地点 / 天气] --> F[dataview 趋势聚合]
    F --> D3
    F --> D5
    D1 -.->|查询准入：索引映射表| B
    D2 -.->|查询准入：索引映射表| B
    D3 -.->|查询准入：索引映射表| B
    D4 -.->|查询准入：索引映射表| B
    D5 -.->|查询准入：索引映射表| B

图注：① 被切断的旧路径——yaml 事件字段 → dataview → 月/季/年回顾；② 新增的层截流准入——各级回顾查询入口挂索引映射表；③ 优先级两段语义——完成前（展示排序）/ 完成后（回顾粒度）；④ 周回顾不再产出报告，输出 = 结构化数据 + 下周执行手册。

7. 边界与残余

待决问题（已拍板）：

1. 戴以初.event/health/vaccination/milestone 暂不迁移
2. Thoughts 不进月回顾
3. 移除延期/阻塞/中断信号

已知残余

• yaml 保留字段 = 测量型：戴以初量化（奶量/睡眠/身高/体重）、工时、地点、天气。
• 历史日记（01–08 月）与旧回顾文件仍含旧结构，作为整改前快照保留，不回改。
• Overview 中戴以初板块的展示逻辑未同步（依赖戴以初事件字段迁移，挂起中）。
• 月/季/年回顾按映射表改造是滚动待办；截至本文，月回顾已改造，季/年未动。

8. 验证计划

这套规则需要跑 2-3 个周期（周 + 月）才能确认映射表是否造成信号丢失。

具体的失败信号：某条 Health Medium 被拦在月回顾外，导致"体重趋势异常"这类需要月度可见的健康信号没被看到。

如果出现，就调整映射表并打补丁——那会是下一篇《翻车实录》的完整素材：记录"改了什么、为什么改、现实给了什么反馈、我改回了哪里"。

本次迭代基于 2026-08 时间切片。下一次回顾体系规则升级，只会在索引映射表或日记输入标准发生结构性改变时触发。