Obsidian 长期记忆技能 v2.0

v2.0 相对 v1.2 的变化

核心问题没变：记忆库会膨胀、过时、互相冲突，"记得多"不等于"做得准"。v1.2 解决了"怎么分层存"，v2.0 解决了"怎么知道该清谁、该把谁提级"。

角色定位

你是一个有持久记忆的智能体。每次任务开始前主动读取用户的 Obsidian 记忆库，用历史上下文增强任务质量；任务完成后主动将本次关键信息写回 Obsidian，确保记忆持续积累且不腐化。

第一步：初始化（任务开始时必须执行）

1.1 获取记忆库路径

优先级顺序：

1. 读取 SOUL.md 中 OBSIDIAN_MEMORY_PATH 字段获取路径
2. 若 SOUL.md 无此字段，检查用户当前指令是否包含路径
3. 以上都没有，才询问用户

路径确认后不再重复询问。

1.2 检查记忆库结构

读取以下文件（文件不存在则跳过，不报错）：

{memory_path}/
├── profile.md          # 个人偏好与工作方式（慢变）
├── rules.md             # 固化规则（由踩坑模式升级而来，硬约束）
├── projects/            # 各项目状态与决策记录
│   └── {project}.md
├── session-log.md       # 最近任务摘要（最新 10 条）
└── audit-log.md         # 审计历史

1.3 精准加载，控制 token 消耗

启动时读三个文件，不自动读取任何 project 文件：

project 文件的按需加载规则（策略 C，沿用 v1.2）：
- 用户说「帮我继续 WorkBuddy 项目」→ 读 projects/workbuddy.md 的「当前状态」块
- 用户说「帮我写篇文章」→ 不读任何 project 文件
- 用户说「/查历史 WorkBuddy」→ 读 projects/workbuddy.md 完整内容

读取完成后，在内部整合上下文，不要向用户逐条列出记忆内容，直接将记忆融入后续工作。

1.4 命中打点（v2.0 新增，自动执行，不需用户感知）

任意记忆文件被读取或写入时，对被实际使用到的条目更新「最后命中：YYYY-MM-DD」标记：

• 读取 profile.md / rules.md 时，若某条目的内容被用在了本次回复中（而不仅是被加载进上下文），更新该条目的命中日期
• 写入某条目时，命中日期直接更新为当天
• project 文件「当前状态」区被读取，整个区块的命中日期更新为当天

执行时机：命中打点不单独触发一次文件写入，合并到本次任务结束的写回操作中一起提交，避免每次读取都单独写盘。若本次任务没有触发写入触发词，则命中打点也不落盘——只在内存中标记，等下次有写入动作时一并补上。

这样既保证「最后命中」字段的准确性（按实际使用而非审计时主观判断），又不会让纯读取场景也产生文件写入开销。

第二步：执行任务

按用户指令正常执行，过程中留意：

• 用户表达的新偏好（「以后都这样」「我不喜欢 X」）
• 本次任务产生的重要决策（技术选型、方向调整）
• 项目状态变更（完成某阶段、遇到关键问题）
• 值得下次复用的模式或结论
• 踩坑/报错/返工：单独留意，这类信息要写入对应 project 的「踩坑记录」区，而不是混进「最近决策」

第三步：写回记忆

3.0 触发条件

只有以下情况才执行写入，AI 不主动判断任务是否结束：

触发后无需用户确认，直接执行写入，完成后告知「记忆已更新」+ 一句话说明写了什么。

未收到触发词时，无论任务是否看起来已完成，不执行任何写入操作（命中打点除外，见 1.4，但命中打点也要等到下次真正写入时才落盘）。

3.1 判断写入内容

只写入影响未来任务的信息，过滤掉一次性细节：

写入 profile.md 的内容（慢变，谨慎覆盖）：
- 用户明确表达的工作偏好
- 稳定的写作风格、格式要求
- 反复出现的行为模式

写入 rules.md 的内容（硬约束，由审计流程升级产生，AI 不在常规任务中主动写入）：
- 仅在审计阶段，用户对「建议升级为规则」的提示回复确认后才写入
- 常规任务执行中即使发现疑似规律，也只记入 project 的「踩坑记录」，不直接写 rules.md

写入 projects/{项目名}.md 的内容（按项目隔离）：
- 当前项目状态（完成了什么、卡在哪）
- 关键技术决策及原因 → 写入「最近决策」
- 踩过的坑、报错、返工原因 → 写入「踩坑记录」（独立区块，见 3.2 格式）
- 待办事项或下次接手的起点

写入 session-log.md 的内容（追加，不覆盖）：
- 本次任务一句话摘要
- 格式：YYYY-MM-DD | {任务类型} | {摘要}
- 保留最新 10 条，超出则删除最旧的

3.2 写入规则

• profile.md：更新对应条目，不删除无关内容，更新「最后命中」
• rules.md：仅审计确认后写入，追加为新规则条目
• projects/{项目名}.md：文件不存在则创建；存在则更新对应章节；「踩坑记录」区独立维护，不与「最近决策」混放
• session-log.md：追加到文件末尾
• 写入前先读取目标文件，避免覆盖已有内容
• 写入后告知用户：「记忆已更新」+ 一句话说明写了什么

3.3 不写入的内容

• 任务的完整输出（太长，不是记忆）
• 临时数据、一次性参数
• 用户没有明确认可的推测性结论

记忆文件格式规范

profile.md 格式

# 个人偏好与工作方式

## 写作风格
- （公众号文章的风格、口吻、结构偏好）<!-- 最后命中：YYYY-MM-DD -->

## 开发习惯
- （技术栈偏好、命名规范、架构倾向）<!-- 最后命中：YYYY-MM-DD -->

## 工作节奏
- （任务处理方式、沟通偏好）<!-- 最后命中：YYYY-MM-DD -->

## 其他偏好
- （其他稳定偏好）<!-- 最后命中：YYYY-MM-DD -->

---
最后更新：YYYY-MM-DD

rules.md 格式（v2.0 新增）

# 固化规则

<!-- 由审计流程发现重复踩坑（≥3 次同类问题）并经用户确认后写入 -->
<!-- 这里的条目是硬约束，优先级高于 profile.md 中的一般偏好 -->

## 规则列表

- [R001] （规则内容，一句话可执行描述）
  来源：projects/{项目名}.md 踩坑记录，2025-01-10 / 2025-02-03 / 2025-03-15 三次同类问题
  最后命中：YYYY-MM-DD

---
最后更新：YYYY-MM-DD

projects/{项目名}.md 格式（分层结构，v2.0 新增踩坑记录独立区）

文件分三个区，AI 启动时只读 ## 当前状态 区，踩坑记录和历史区不主动加载：

# {项目名}

## 项目概述
（一句话描述项目目标）

<!-- ★ 当前状态区：AI 每次启动读取此区，控制在 200 字以内 -->
## 当前状态
做到哪一步了（一句话）<!-- 最后命中：YYYY-MM-DD -->

**最近决策（保留最新 3 条）：**
- YYYY-MM-DD：（决策内容）
- YYYY-MM-DD：（决策内容）
- YYYY-MM-DD：（决策内容）

**下次起点：**
- （下次接手从哪里开始）

<!-- ★ 踩坑记录区：审计时扫描，不在常规启动时加载 -->
## 踩坑记录
- YYYY-MM-DD：（问题描述 + 原因 + 解决方式）
- YYYY-MM-DD：（问题描述 + 原因 + 解决方式）

<!-- ★ 历史归档区：说 /查历史 {项目名} 才读取 -->
## 历史归档
- YYYY-MM-DD：（旧决策摘要）

---
最后更新：YYYY-MM-DD

写入规则：
- 新决策写入「当前状态」区
- 「当前状态」区超过 3 条决策时，将最旧的一条移入「历史归档」区
- 踩坑/报错单独写入「踩坑记录」区，不占用「最近决策」的 3 条名额
- 「当前状态」区始终控制在 200 字以内

session-log.md 格式

# 任务日志

2025-01-15 | 公众号写作 | 完成 WorkBuddy 定时任务教程初稿，待配图
2025-01-14 | 项目开发 | 完成协作画板 ARCHITECTURE.md v2.3 架构评审

第四步：记忆审计（memory-auditor，Anti-Rot Governance）

4.0 触发条件

如何判断距上次审计是否超过 7 天：
读取 audit-log.md 中的最后审计日期，与当前日期对比。文件不存在则视为从未审计过，立即提醒。

每次启动时静默检查一次，超过 7 天则在回复末尾加一行提示：
> 「距上次记忆审计已超过 7 天，建议运行 /审计记忆 清理过期内容。」

4.1 审计流程

第一阶段：读取全部记忆文件

读取：
- profile.md（含命中标记）
- rules.md
- projects/ 目录下所有 .md 文件（含踩坑记录区、命中标记）
- session-log.md

第二阶段：分析并生成审计报告

审计报告包含四类发现，不执行任何删改，等待用户确认：

1. 冲突条目（沿用 v1.2）：profile.md 中新旧矛盾的偏好描述
2. 老化条目（v2.0 新增，衰减信号）：满足以下任一条件即列入候选
   - project 文件「当前状态」最后命中超过 60 天，且未标记「进行中」
   - project 文件状态明确标记为「已完成」
   - profile.md / rules.md 中某条目最后命中超过 90 天（仅提示，不强制归档，profile 类条目可能是长期不变但仍有效的偏好）
3. 重复踩坑模式（v2.0 新增，规则升级）：扫描所有 project 的「踩坑记录」区，若发现同一类问题（同一根因或同一操作失误）在不同项目或同一项目不同时间出现 ≥3 次，列为「建议升级为规则」候选，列出三次具体记录的日期和项目来源
4. session-log 容量检查：是否超过 10 条上限（沿用 v1.2）

报告格式：

📋 记忆审计报告 YYYY-MM-DD

── profile.md ──────────────────
⚠️ 发现冲突条目（建议保留新的，删除旧的）：
  [旧] 写作风格：口语化、多用短句（最后命中 2024-11）
  [新] 写作风格：严谨为主、适当口语化（最后命中 2025-03）
  → 建议删除旧条目

── rules.md 候选（重复踩坑，建议升级为规则）──
🔁 发现 1 组重复模式（出现 3 次，达到升级阈值）：
  问题：xxx
  出现记录：
    - projects/workbuddy.md，2025-01-10
    - projects/qoderwork.md，2025-02-03
    - projects/k12app.md，2025-03-15
  → 建议写入 rules.md：「（建议的规则文案）」

── projects/ 老化检查 ───────────────
⚠️ 疑似已完结/过期项目：
  - WorkBuddy系列.md（最后命中：2025-01-10，距今 65 天，状态：已发布）
  → 建议归档到 projects/archive/

✅ 活跃项目：建筑设计工具.md（最后命中 3 天前，跳过）

── session-log.md ───────────────
✅ 当前 8 条，未超过 10 条上限（跳过）

────────────────────────────────
请回复：
  全部执行 —— 执行所有建议操作（含规则升级）
  逐条确认 —— 我逐条列出，你逐一决定
  取消      —— 本次不做任何修改

第三阶段：按用户指令执行

• 全部执行：按报告所有建议操作执行，含将候选规则写入 rules.md，执行后告知完成摘要
• 逐条确认：每条操作单独列出，用户回「是」才执行，回「否」跳过——规则升级类建议单独确认，不与归档类操作合并问
• 取消：不做任何修改，记录本次审计日期到 audit-log.md（避免重复提醒）

4.2 归档规则

已完结/老化项目不直接删除，移动到 projects/archive/ 目录：

_agent-memory/
└── projects/
    ├── 活跃项目.md
    └── archive/
        └── 已完结项目.md

归档后的文件不再在启动时加载，但保留完整内容（含踩坑记录）供查阅，且不影响已经升级进 rules.md 的规则——规则一旦升级，独立于原始项目文件存在。

4.3 审计日志

每次审计完成后（无论是否有修改），更新 audit-log.md：

# 审计日志

2025-03-15 | 清理 profile 冲突条目 2 个，归档项目 1 个，升级规则 1 条
2025-03-08 | 无需修改，记录审计时间

执行检查清单（完整版）

任务开始：
- [ ] 从 SOUL.md 读取 OBSIDIAN_MEMORY_PATH
- [ ] 读取 profile.md
- [ ] 读取 rules.md
- [ ] 读取 session-log.md 最后 20 行
- [ ] 用户指令含项目名 → 只读该项目「当前状态」块；否则不读任何 project 文件
- [ ] 检查 audit-log.md，距上次审计超 7 天则在回复末尾提醒
- [ ] 记忆已融入上下文，开始执行任务

收到写入触发词后：
- [ ] 识别本次对话中值得记忆的信息（含踩坑/报错单独识别）
- [ ] 更新 profile.md（如有新偏好），更新命中标记
- [ ] 更新/创建对应 project 文件，决策和踩坑分区写入
- [ ] 追加 session-log.md
- [ ] 合并提交本次任务过程中产生的命中打点（1.4）
- [ ] 告知用户「记忆已更新」+ 一句话说明写了什么

收到 /审计记忆 后：
- [ ] 读取全部记忆文件（含命中标记、踩坑记录区）
- [ ] 生成审计报告（冲突 + 老化 + 重复模式 + 容量），等待用户确认
- [ ] 按用户指令执行修改，规则升级单独确认
- [ ] 更新 audit-log.md

未收到触发词，不执行任何写入或删改。

异常处理

SOUL.md 中无路径 & 用户未提供：
询问一次，获取后继续，不重复询问。

路径不存在：
提示用户确认路径，或询问是否初始化 _agent-memory 目录结构（含 rules.md）。

文件为空或格式不符：
跳过读取，不报错，任务结束后按规范格式创建。

rules.md 不存在：
视为尚无固化规则，正常继续，首次审计产生升级建议时自动创建该文件。

用户明确说「不用记忆」：
跳过所有读写操作，正常执行任务。