【迭代】日记采集 v2026.11：Agent 接管写入口，判重成为规则

发表评论
6 views

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

1. 变更声明

版本号：v2026.11（2026-11-03）

锚点：采集的瓶颈从"记什么"移到"谁来写、重复怎么办"；Agent 接管写入口，判重从临场判断变成规则。

v2026.09 定了只记改变，v2026.10 把日记留给手记，本版改的是最后一段：日记的写入口不再只属于我。Agent 在任务收尾时写入一条变化，同一天同一变化只允许一条。

结果不是记录变多，是"回到 Obsidian 再补"这一步消失。

2. 症状与旧证据

  • 记录滞后于判断。 任务在会话里结束，记录要等切回 Obsidian 再补；补的时候只剩结论，为什么这么改、当时否掉了什么，已经散了。
  • 判据不可执行。 "只记改变"是一条判据，不是格式。每次都要重新想：这算不算改变、算一条还是两条、补充说明是改原条目还是再写一条。
  • 同一天多次交付会分叉。 同一个功能上午写完、下午补一个边界，容易追加成两条；反过来也会只留最早一条，后一次状态推进没写进去。
  • 位置靠记忆。 日程计划在模板里是空段，没有锚点。Agent 无法可靠定位，人也只能从头翻。

对应的旧记录：v2026.09 的五条整改里，第 3 条只写了"只记改变"，没写"重复怎么办"；v2026.10 的 AI 工作单里，日记一行明确是"由我手记"。也就是说，采集层的内容标准有了，写入口从未被规则覆盖。

3. 诊断

  1. 采集准入只定义了内容，没定义入口。 谁写、写在哪、写几次，全靠人记着。
  2. 判断不可复用，是因为没有拆成可比对的结构。 "同一变化"听起来是语义问题，其实可以拆成对象、类型、结果三项，逐项比对。
  3. 手记的真实成本是上下文切换，不是打字。 Agent 已经在上下文里，写一条的边际成本最低；我切回去的成本最高。
  4. 自动写入的第一风险不是写错，是写多。 没有判重，自动化只会更快地制造重复，而且重复得理直气壮。

4. 设计方案

4.1 写入口与边界

  • 触发：库内完成有可验证状态变化的需求，收尾时写；纯查询、无变化不写。
  • 位置：当天日记的「日程计划」段；只改这一段和 frontmatter 的 modify_time。
  • 不碰：看板、其他段落、Git 提交。日记不存在时不裸复制模板（模板含动态元数据），直接停。

4.2 判重三要素

对象（项目标签、文件名或模块）、变化类型（功能、修复、重构等）、结果。三项都相同才算同一变化。

4.3 决策表

情况 动作
当天已有同对象、同类型、同结果的条目 修改原条目，补细节或链接
当天只有计划条目，现在完成 改 - [x]，补完成日期，描述改成实际结果
同对象、不同独立交付 新增
更早日记已记录，今天没有新状态 不写，说明"无新增"
两个以上高度相似候选 停下来问人，不猜

4.4 格式契约

- [x] [HH:mm:ss ]<变化描述> #Project/<项目>[/<子模块>] #Topic/Develop/<类型> [created:: YYYY-MM-DD] [completion:: YYYY-MM-DD]

默认不写优先级；时间前缀只给"发生时刻本身有意义"的事件；子条目用 Tab 缩进，跟在父条目下。写的是结果，不是"读了文件、跑了测试"的过程。

4.5 触发方式

两层：库级 AGENTS.md 负责"什么时候做"，Skill 负责"怎么判、怎么写、怎么校验"。另配一个只读脚本，输出段落行号与当天已有条目，避免手数行号、也避免把"有条目"误当成"已记录"。

5. 首次运行证据

2026-11-03 首次运行，对象是这次改动本身：

  • 当天段内已有 4 条，逐条比对后判定"无同对象、同类型条目"→ 新增；
  • 写入后 YAML 可解析、标题唯一，diff 只落在新增 1 行与 modify_time；
  • 历史 4 条未被动过；
  • "修改"分支尚未被真实触发。这是本版最大的未验证项——规则写了一整套，实际只用到了其中一格。

一条样本只能证明"能写对"，不能证明"判得准"。

6. 信息流向

graph TD
    A[任务收尾] --> B[读当天日程计划段]
    B --> C{判重三要素}
    C -->|三项都命中| D[修改原条目]
    C -->|部分命中/无命中| E[新增条目]
    C -->|无状态变化| F[不写]
    D --> G[校验: YAML/标题/格式/重复]
    E --> G
    G --> H[更新 modify_time]

7. 边界与残余

  • 只覆盖项目与交付类变化。 身体、家庭、外界线索仍手记——Agent 不在现场，也没有这些上下文。
  • 判重是语义的，三要素只是下限。 同名但不同批次可能被误合并；歧义必须转人工，不能靠相似度硬判。
  • 自动写入会提高污染速度。 靠"只记改变 + 判重 + 只改一段"三道闸，但不是零风险，前两周按验证计划盯。
  • 并发没有锁。 Obsidian 与 Agent 可能同时写同一文件，目前只靠"编辑前重读、最小改动"规避，没做版本合并。
  • 未做：跨天合并、看板联动、写入失败回滚。
  • 工程位置：Skill 在 .agents/，不进 Git，靠 Syncthing 同步；库级约定在 AGENTS.md，进 Git。换机时两者要一起到。

8. 验证计划

跑 W45–W46 两周。

失败信号（触发补丁）：① 一天内出现语义重复条目 ≥2 次/周；② 条目数相对旧基线翻倍但信息量不增；③ 出现过程记录（"跑了测试""读了文件"）；④ 误改历史条目——任一条命中即回退手记。

成功信号：当天完成但未记录的交付 ≤1 天；"修改"分支被真实使用 ≥3 次；周末回顾不再需要补记。

样本门槛：至少 10 个交付日、20 条写入后再判断是否保留，不做一周就下结论。

本次迭代基于 2026-11-03 时间切片。下一次采集入口的结构性改变将触发新迭代记录；若被现实打回，则产出翻车实录。