【翻车实录】 以下内容记录了一套精密逻辑在现实中遭遇"不兼容"的完整过程，以及事后打上的补丁。这里没有顿悟，没有共情，只有真实的报错与修复。如果你在找"原来不止我一个人这样"的安慰，这里没有；如果你在找"那后来怎么改的"，正文开始。
我的系统为"回顾准入"设计了一张 60 格的索引映射表。运行两周后，数据告诉我：这张表里的 60 个格子，实际查询只执行了 3 个；而为了让这张表成立，优先级字段被迫一人分饰两角——先管执行排序，再管回顾粒度，最后两个都没做好。
一、基准线：当规则精细到 60 个格子
2026 年 7 月，回顾体系完成一次大整改：个人信息的采集—清洗—装载，从双通道收敛成单通道。
整改前，同一件事存在两个数据源：日记元属性的事件字段记一份，待办体系记一份。回顾时不知道以谁为准。整改后，感知层只负责 E（Extract）——原始信息落入统一日记容器，不做任何分类，记录动作的摩擦降到零；周回顾负责 T（Transform）——补标签、校准优先级；月/季/年回顾负责 L（Load）——按规则查询。交集消失。
整改的下半场紧跟着出台：层截流 准入规则。
为了让"高级别回顾不出现低优先级待办"，我给每个 Topic/Focus 标签和每个优先级指定了可被哪一级回顾索引的矩阵。
10 行标签 × 6 档优先级 = 60 个格子，覆盖日、周、月、季、年五个级别。每个格子填着"日周月季年"之类的准入字串。Adjust 的 Highest 是"日周月季年"，Thoughts 的 Lowest 是"该组合极少出现"。
当时这套系统显得极其干净。感知层零摩擦，规则全部写死，查询即规则。周回顾模板新增步骤 2.1.3："根据索引映射表调整优先级"；迭代文档同步记录：W32 起，周回顾增加对已完成待办进行标签优先级调整。
对这套规则的信心很足：规则越精细，回顾越不会被污染。这个判断在两周后收到了对账单。
二、变量入侵：周回顾变成了全量格式化流水线
2026 年 8 月中旬，我数了数过去一周的数据：156 条完成待办，其中 85 条带着优先级，71 条空白。85 条里：high 32 条、highest 9 条、medium 5 条、lowest 37 条。
这 156 条，每一条都在周回顾里等着同一个问题："按映射表，它应该是什么优先级？"
而这个问题的前提是另一个更难的问题："它值得被哪几级回顾看到？"
问题不难答。难的是量。
周回顾的核心目标原本是"系统维护、执行对齐、任务管理"。那个下午，它变成了全量格式化流水线。
光标停在一条已完成待办上：创建时是 high，因为那天必须做完。现在做完了。按表，high 意味着日周月。但它只是一份当天必须交的表格。
我意识到优先级字段正在被两个系统同时读写：执行系统读它来排序，回顾系统读它来定粒度。一个字段，两种语义，两个时刻，两次决策——156 条待办，乘两条语义，全部堆在一个周回顾 session 里。
工作量是设计成本，还是执行问题？当时无法分辨。能确认的是：60 格表的维护成本按全量收税，每周一次，一次 156 条。
三、强行拟合：优先级的一人分饰两角
为了让 60 格表逻辑自洽，优先级不得不继续扛着双语义活下去。
完成前，它决定当天展示排序：Highest 严格限制 0-1 个/天，High 限 2-4 个，Lowest 存在的意义只是记录。完成后，它决定回顾粒度：high 意味着日周月，highest 直通季/年。
于是每一条完成待办都陷入身份分裂："这条 high，到底是因为今天急，还是值得进月回顾？"
更隐蔽的是执行残留：当天因为紧迫设了 high 的任务，完成后没人碰它，它就带着"日周月"的准入资格躺进月回顾的查询结果。层截流本要拦截的污染，以执行残留的方式绕了回来——系统自己成了污染源。
真正的对照数据出现得很晚。我翻回 7 月的月回顾模板，数优先级过滤条件：priority is above high（一个板块）、priority is above lowest（主查询）、priority is lowest（一个板块）。三处。
60 个格子里 Medium 与 Normal 的区分——"日周月"与"日周"——查询从未执行。
纸面规则与执行脱节，维护成本却按全量收取。这是第一层错位。
第二层错位更根本：月回顾的真实需求是 AI 对全量待办做模式识别——迭代文档 自己写死了"层截流约束展示，不约束分析"。
季/年回顾的真实需求是里程碑——方向层本就不该查原始待办。层截流只剩"月回顾展示板块"一个真实消费者，而它只需要粗桶过滤。
链条在此闭合：因为整改时砍掉了周回顾报告，月回顾失去结构化输入，才需要层截流；层截流需要优先级当粒度轴；优先级因此双语义；双语义导致周回顾全量查表。
每一环都自洽，合起来是灾难，这也是现有 AI 的通病。
四、补丁：从准入表到守卫表
补丁的第一步是承认：这不是查询没跟上实现，而是需求本身错位。60 格表在回答一个几乎不存在的问题。
第二步，优先级回归纯执行语义。创建时定一次，只决定当天展示排序；完成后永不触碰。"完成后没填优先级"从"日记忘了填"变成"不需要填"。
第三步，60 格映射表退役，降级为 10 行标签天花板守卫——只回答"这个标签最多能进哪一级回顾展示"。粗过滤，一行一条，不需要查表。Thoughts 与 Meals 不进月回顾展示，Change 与 Risk 有资格被选为里程碑。
| 标签 | 月回顾展示 | 可升级为里程碑（季/年） | 说明 |
|---|---|---|---|
| Topic/Focus/Change | ✓ | ✓ | 战略级机遇/方向性改变，通过里程碑进入季/年回顾 |
| Topic/Focus/Risk | ✓ | ✓ | 重大风险处理通过里程碑进入季/年回顾 |
| Topic/Focus/System | ✓ | ✓ | 系统迭代通过里程碑进入季/年回顾 |
| Topic/Focus/Health | ✓ | 异常节点可 | 例行记录只到月回顾（分析）；异常升级为里程碑 |
| Topic/Focus/Habit | ✓（趋势） | 否 | 以趋势形式在月回顾中展现 |
| Topic/Focus/Adjust | ✓ | 否 | 一次性优化，月回顾分析即可 |
| Topic/Focus/Clue | ✓ | 否 | 线索在月回顾中聚类；升级为 Change/Adjust 后跟随新标签 |
| Topic/Focus/Meals | ✗ | 否 | 例行记录，不进月回顾展示 |
| Topic/Focus/Thoughts | ✗ | 否 | 记录性质，不进月回顾展示 |
| 无标签 | ✗ | 否 | 未结构化的原始记录 |
第四步，季/年回顾改走里程碑机制：月回顾显式挑选每责任领域 2-5 条里程碑，逐月沉淀。待办进入季/年回顾，是因为被选中，不是因为达标。
落地清单：周回顾删除"按映射表调整优先级"步骤与"高优先级最终检查"板块，标签补全的定位改为"月回顾 AI 分析原料"。
月回顾新增里程碑挑选板块；日记模板结束语删除"按映射表指定优先级"；架构图 同步改写成"全量分析 + 里程碑沉淀"。
补丁不完美，登记两处。
其一，历史遗留的执行优先级残留仍在数据里，需要时间自然沉降。过渡期内，季度查询模板仍以优先级做粗过滤，噪声无法完全避免——它们会在下一次季度回顾时被当作历史数据清洗掉。
其二，里程碑机制把复杂度从"每周全量"转移到了"每月挑选"：决策量从 156 条/周降到每领域 2-5 条/月。但纪律负担仍在——月回顾若偷懒，年回顾就没有里程碑可吃。这个风险登记在案，等待数据验证。
五、结语：系统定性
该事件被系统标记为：准入规则过度设计。60 格索引映射表退役，降级为标签天花板守卫；季/年回顾的准入机制改为里程碑沉淀；优先级字段回滚为单一执行语义。v2026.08 补丁已覆盖。
遗留的执行残留等待自然沉降，里程碑机制的纪律风险登记在案。
本次翻车基于 2026-08-21 时间切片。准入规则的起源与退役全程见 迭代文档，补丁后的回顾体系见回顾体系架构图，系统全景见关于页面。