Architecture Design Book
Architecture Design · PCS

个人上下文系统 · 架构设计书

本地优先 · Markdown 单一事实源 · AI 提议—人确认 · 六层分工 · 可重放编译。
一条贯穿全文的原则:AI 消灭"怎么做",人只负责"做什么"。

14章
12条架构决策 ADR
55代码 / Schema 块
167表格行
① 收件层② 编译层③ 长期沉淀层④ 纠错进化层⑤ 学习能力层⑥ 主动输出层

代号 PCS(Personal Context System)

本地优先 · Markdown 单一事实源 · AI 提议—人确认 · 六层分工 · 可重放编译


0. 先回答那个元问题

你开篇那段话其实是整个方案的题眼,值得先翻译成设计语言。

AI 消灭了偶然复杂度,但软件工程没有银弹,软件本身的复杂度依旧存在。

这句话在个人知识系统里精确对应两层复杂度:

复杂度类型具体表现AI 能否消灭谁负责
偶然复杂度分类、命名、摘要、去重、双链、格式统一、检索、生成日报✅ 基本能消灭AI 全权
本质复杂度判断什么值得沉淀、什么算真教训、什么该复习、阶段边界在哪❌ 消灭不了人给约束(Gate)

这就是全案唯一的核心架构原则:AI 消灭"怎么做",人只负责"做什么"。

它推导出四条贯穿全文的具体规则:

  1. AI 可以全权做:采集、摘要、索引、检索、去重、聚类、草稿生成、调度计算。
  2. AI 只能提议,人来确认:写入长期资产(说明书/阶段记录/语录/原则)、错误根因归类、掌握度晋级。
  3. 读写不对称:写全部要人确认(低频、高价值、不可逆);读全自动(高频、低价值、可逆)。这是系统能长期跑下去的关键。
  4. 产出可重放:任何 AI 产出必须带指纹(模型 ID + 提示词哈希 + 管道版本),这样模型升级后你能看出"变了什么",而不是被静默改写历史。

一个反直觉但重要的推论:你不需要给 AI 装一个"更聪明的模型",你需要给它装一个"更好的上下文"和"更硬的门禁"。 系统的复利来自后者。


1. 总体架构

1.1 六层 + 两条正交轴

原方案里六层是串行流水线,实际应理解为"六层 × 两条正交轴"。两条轴分别是时间和置信度,很多设计冲突正是这两条轴没理清导致的。

TEXT
                        ┌──────────────────────────────────────────┐
   时间轴(短 → 长)    │                                          │
                        │  ① 收件层 Inbox      (分钟 ~ 天)          │
                        │  ② 编译层 Compile    (小时 ~ 周)          │
                        │  ③ 长期沉淀层 Vault  (周 ~ 年)            │
                        │  ④ 纠错进化层 Fault  (月 ~ 年)            │
                        │  ⑤ 学习能力层 Learn  (月 ~ 年)            │
                        │  ⑥ 主动输出层 Output (天 ~ 月)            │
                        │                                          │
   置信度轴(低 → 高)  │  raw ──────────► wiki ──────► spec/stage │
                        │  (未验证)         (已验证)     (已确认)   │
                        └──────────────────────────────────────────┘

关键洞察:④⑤ 不是 ①③ 的下游,而是 ①③ 的反馈源。

TEXT
     ①收件 ──► ②编译 ──► ③沉淀 ──┐
        ▲                         │
        │                         ▼
     ⑤学习 ◄── ④纠错 ◄──────── 复盘引擎
        │        ▲
        └────────┘
     错误归因 → 掌握度下调 → 复习调度 → 表现提升 → 教训验证

第 ④ 层(错误)向下影响第 ⑤ 层(学习),第 ⑤ 层的复习表现又回流验证第 ④ 层的教训是否真的有效。这个闭环是"可复利"的机械来源——不是数据变多了,而是下一次犯同类错的概率下降了。

1.2 全景数据流

TEXT
┌─────────────┐
│ 真实世界     │  收藏/文件/语音/截图/对话
└──────┬──────┘
       │ 采集器(浏览器插件 / 快捷指令 / 目录监视 / MCP)
       ▼
┌─────────────┐   只增不改   原始素材永不被 AI 触碰
│ ① 收件层    │   raw/
└──────┬──────┘
       │ 编译任务(夜间批处理,幂等)
       ▼
┌─────────────┐   指纹化产物   可重放
│ ② 编译层    │   compile/
└──────┬──────┘
       │ 人工审核闸门(Gate)
       ▼
┌─────────────┐   唯一事实源   SSOT
│ ③ 长期沉淀层 │   vault/
│  说明书/阶段/语录/wiki │
└──────┬──────┘
       │
       ├──► ④ 纠错进化层(错误库 / 教训库 / 原则)◄── 复盘
       │              │
       │              ▼ 降级掌握度
       │        ⑤ 学习能力层(掌握度 / DAG / 复习队列)
       │              │
       │              ▼ 复习表现
       │        (回流验证教训有效性)
       │
       └──► ⑥ 主动输出层 ◄── 上下文装配器(Context Assembler)
              网页总结 / 晨间播报 / 主动提问        ▲
                                                        │
                                        ┌───────────┴───────────┐
                                        │   MCP 工具集          │
                                        │   (日常 AI 对话入口)  │
                                        └───────────────────────┘

1.3 上下文装配器:系统的心脏

原方案里"AI 每次对话都引用个人说明书"这句话需要精确化,否则要么 token 爆掉,要么说明书注水。

真实做法是分层装配 + token 预算:

TEXT
ContextPack = {
  spec_core      : str       # 身份/价值观/沟通风格 —— 永远携带,约 400-600 tok
  spec_state     : str       # 当前阶段目标/活跃项目 —— 按会话相关性携带,约 200-400 tok
  stage_active   : [Stage]   # 匹配的阶段记录(最多 2 条)
  errors_matched : [Error]   # 情境匹配的历史错误(最多 3 条,含触发条件)
  kp_due         : [KP]      # 今日到期复习(最多 5 条,只带标题+卡点)
  kp_blocked     : [KP]      # 前置缺失导致的卡点(最多 2 条)
  quotes_matched : [Quote]   # 匹配的历史语录(最多 2 条)
  pointers       : [Pointer] # 媒体/大文件指针(最多 3 条,含路径+摘要)
  notes          : [Note]    # 语义检索命中的笔记片段
  warnings       : [Warning] # ★ 主动预警,见 §4.4
}

装配是分级的、按 token 预算裁剪的,不是"全塞进去"。 预算建议:日常对话 2.5k token,深度任务 6k token。

这个装配器同时是:MCP 工具的后端、主动提问的生成器、晨间播报的取材器、周报的取材器。一次实现,四处复用——这是整个架构里最值得投入的地方。


2. 架构决策记录(ADR)

以下 12 条是对原方案的修正或补强,每条标注「为什么必须改」和「不改会怎样」。逐条对照原需求,标注 ✅ 采纳 / 🔧 修正 / ⚠️ 补充。

ADR-01 🔧 收件层与编译层必须分离,且 raw 不可变

原话:「资料原样丢进收件层,由 AI 自动完成摘要、双链、索引」。

问题:摘要是有损的,且会被模型版本污染。若 raw 和编译产物混在一起,模型升级后重跑一次,你无法回答"我三个月前看到的内容是什么"——历史被静默改写。

决策:

  • raw/ 只增不改,AI 只读不写。
  • 编译产物独立存放,带指纹:compiled_by: {model, prompt_hash, pipeline_version, compiled_at}。
  • 编译幂等可重放:缓存键 = sha256(content) + pipeline_version + model_id。同键命中缓存,不重复调模型。
  • 升级模型?改 pipeline_version,旧产物进 compile/history/,可对比、可回滚。

不改的后果:半年后你无法信任任何一条 AI 生成的摘要,因为不知道它是哪版模型、哪版提示词生成的。信任一旦不可审计,整个系统退化成"看起来很整齐的垃圾场"。

ADR-02 ⚠️ 指针笔记必须带内容哈希,且要做"指针健康检查"

原话:「大文件不搬家,只保留路径、索引 ID、语义摘要等指针笔记」。

问题:路径会腐烂。网盘挂载失败、文件被移动、目录重构、账号过期、照片被删。纯路径指针会集体失效,且失效时机不可控——往往正好是你最需要找它的时候。

决策:指针笔记(type: pointer)强制字段:

YAML
type: pointer
id: ptr_20261101_a3f9
uri: "oplist://nas/photos/2026/11/IMG_0031.jpg"
storage: op-list          # 存储后端标识
size_bytes: 4821993
content_hash: sha256:9f2c...   # ★ 必需
captured_at: 2026-11-01T09:12:00+08:00
index_status: indexed     # indexed | unindexed | dead
last_probed_at: 2026-11-01T09:15:00+08:00
semantic_summary: "..."
ocr_text: "..."           # 会议截图 OCR
media_tags: [会议, 架构图]

指针健康检查:编译任务每 24h 抽样探测(不全探,太慢),对失效指针:

  1. 标 index_status: dead
  2. 尝试内容寻址恢复:用 content_hash 在各存储后端反查,找到则更新 uri(这正是哈希的价值)
  3. 找不到 → 在日报"资产健康"里提示,且不删除原指针(标记墓碑,保留历史)

不改的后果:一年后 40% 的媒体指针是死的,而你在写方案时引用不到那张架构图。

ADR-03 🔧 说明书必须分三层,不能只有一份

原话:「个人说明书:记录我的身份、价值观、原则、偏好……供 AI 每次对话作为长期上下文引用」。

问题:一份说明书同时承担「永久不变的身份」和「每月都变的当前状态」,两种互相矛盾的更新频率打架,最后说明书膨胀成 3000 字垃圾文档,每次对话都塞 3000 token,核心信息被淹没。

决策:拆三个文件,不同更新频率,不同注入策略:

文件内容更新频率注入策略
spec/core.md身份、价值观、原则、沟通风格、禁忌季度级常驻注入(每次对话必带)
spec/state.md当前阶段目标、活跃项目、近期关注点周级按会话相关性注入
spec/appendix.md详细偏好、历史决策背景、专有名词表低频不注入,按需检索

叠加可回滚:所有 spec 变更走 git,spec/history/ 存快照。因为人会改主意,而"你曾经是怎么想的"本身是资产。

不改的后果:说明书变成"越长越没人读"的黑洞,AI 从中抽不出任何东西。

ADR-04 🔧 错误根因归类必须人工确认;AI 只提议

原话:「AI 维护"错误与教训库"……定期聚类相似错误、识别反复出现的模式,把经过验证的教训提炼为可执行原则」。

问题:原需求里已经给出了正确的四分类(可避免错误 / 信息不足导致的失误 / 他人因素 / 运气成分),但若这个分类由 AI 自动做,它会系统性把"运气成分"误判为"可避免错误"——因为运气成分没有可提取规律,AI 倾向于强行找规律。

后果很严重:你得到一条虚假的教训("我下次要提前沟通"),然后在未来每次相关场景都引用它,污染判断。错误库的毒化是单向棘轮——一条假教训进去,要靠很多真教训才能稀释。

决策:

  • AI 提议根因分类 + 置信度,status: proposed
  • 人确认后 status: confirmed
  • 只有 confirmed 的错误才能被提炼成原则、才能触发主动预警
  • proposed 状态的错误仍可检索("我可能在这类场景出过问题"),但预警文案降级为"待确认的相似历史"

不改的后果:错误库越用越脏,最终你不再相信它,整个第 ④ 层报废。

ADR-05 🔧 掌握度与记忆保持必须分成两条独立的轨

原话:「掌握程度:采用分级制(如初识—理解—掌握—精通…)」+「遗忘复习:结合间隔重复调度(如 SM-2、FSRS)」。

问题:这是两个正交的东西被混成了一套:

  • 掌握度是语义层级——「我理解 Redis 分布式锁到什么程度」→ 0~4 级
  • 记忆保持是遗忘曲线状态——「上次学完 3 天后还记得吗」→ FSRS 的 stability/difficulty

用一套数字表达两者,必然出现"我精通这个概念但就是记不住公式"这种真实情况无法表达。而且把「掌握」直接当成 FSRS 的 Good 评分去调度,会导致语义上已精通的内容仍被反复排进复习队列(因为公式记不住)。

决策:双轨模型。

TEXT
轨 A:掌握度 Mastery(语义,人/AI 评级,进阶需证据)
  L0 未测试 → L1 初识 → L2 理解 → L3 掌握 → L4 精通
  晋级必须携带 evidence:自测 / 复述 / 实践产出 / AI 评估

轨 B:保持度 Retention(记忆,FSRS 调度,机器维护)
  FSRS state: {stability, difficulty, due, last_review}

两轨的交互:
  FSRS 复习"Again" → Mastery 最多降 1 级,且必须标记降级证据
  Mastery ≥ L3 且 FSRS 逾期 → 优先复习(高分高价值)
  Mastery = L0 且从未复习 → 还没进入调度器,不占复习额度

复习队列的排序不是纯 FSRS 序,而是三因子加权(见 §5.3): priority = fsrs_overdue × value × (1 + blocking_impact)

不改的后果:复习队列变成"推一堆你早就懂了的老概念",这是绝大多数间隔重复系统被弃用的第一原因。

ADR-06 🔧 知识依赖必须分级,不能全是硬阻塞

原话:「用前置依赖关系(DAG)管理……当我在前置知识缺失时硬学进阶内容,AI 应提示卡点并推荐回补路径」。

问题:把所有依赖当硬阻塞,系统会退化成课程表——「你必须先学完 30 门课才能做任何事」。这跟"边做边学"直接矛盾,也是绝大多数个人知识库失败的方式。

问题之二的更细处:真正有用的提示不是「你没学 A」,而是「你学 B 时卡住的症状,和 A 缺失的特征吻合」。前者是官僚,后者才是洞察。

决策:依赖分三级。

依赖类型含义卡点时的行为
hard不懂 A 完全无法进行 B阻断,给出回补路径(拓扑最短路径)
soft学 B 会更吃力,但可以硬啃提示,不阻断,可选"先硬啃 B 回头补 A"
related主题相邻,融合能加深理解仅在生成学习计划时推荐

卡点检测改为症状匹配驱动,而非依赖图驱动:

TEXT
当用户在学 KP_B 且表现不佳时:
  1. 查 B 的前置集合
  2. 过滤出 mastery < L2 的前置
  3. 对每个候选前置 A,检查「用户在 B 上的失败模式」是否匹配「A 的缺失特征」
     (缺失特征由 A 的标准验证题错误类型定义,见 §5.2)
  4. 匹配度最高且 > 阈值 → 提示:
     「你卡在 B 的『并发竞态』维度,而 A『JVM 内存模型』你只到 L1。
       回补 A 比死磕 B 更快。」

不改的后果:你会在"先学 A 提示"里积累挫败感,然后放弃系统。

ADR-07 🔧 主动提问要有预算,不是每天固定 3-5 个

原话:「每天动态生成 3–5 个问题……避免通知轰炸」。

问题:3-5 个/天 + 每日复盘 + 晨播 = 每天 8-10 次打断。你自己写了"避免通知轰炸",但这个设计恰恰在制造轰炸。三周后你会本能地忽略所有推送——包括真正重要的。

决策:提问队列 + 硬预算。

TEXT
每日预算:
  主动提问 ≤ 2 个(硬上限,不可突破)
  其余候选问题进入「待提问池」,按优先级在对话中自然带出

优先级排序(分数高者入队):
  阻塞性   +40   有 hard 依赖卡点等待解决
  错误复发 +35   命中历史错误模式
  阶段里程碑 +25 距阶段目标节点 ≤7 天
  复习到期 +20   FSRS 逾期
  捕获缺口 +15   当天有未归档的高价值素材
  反思洞察 +10   连续 3 天无错误记录但日志异常活跃

跳过规则(硬规则):
  同类型问题 48h 内不重复
  当天已有 ≥2 个主动提问 → 全部延后
  用户 7 天内对同类问题反馈「无用」→ 该类降权 50%
  静默模式(用户开启专注)→ 全部延后

反馈即调参:用户对每个问题的反馈(有用/没用/太泛)直接写回该问题类型的权重。这条反馈回路本身就是「主动交互层」的一部分。

不改的后果:第 ⑥ 层变成噪音源,然后被关掉。

ADR-08 🔧 晨间播报走 xiaomi_miot TTS,反馈回路走手机而非语音

原话:「通过 Home Assistant 的 TTS 服务或支持 DLNA 的小爱音箱推送播放……允许我通过语音或手机一键反馈」。

现状核对(2026-11):

  • 小爱音箱 DLNA 需在米家 App「实验室功能」手动开启,且 HA 通过 DLNA 推 URL 播放要求音箱能反连到你的服务器地址——NAT/端口映射下常失败。
  • xiaomi_miot 集成(HA 内)提供 xiaomi_miot.intelligent_speaker 动作直接 TTS 朗读,不依赖音箱主动连你,更稳。
  • 存在走小米账号 Cookie 的第三方集成(E7G/xiaoai-speaker),能力全但属逆向接口,有账号风控风险,不建议用于长期方案。
  • 小爱音箱没有开放给第三方的自由语音输入回调,所以"用语音回复这条有用/没用"在技术上很脆(要 ASR、要会话状态、要判断用户在对谁说话)。

决策:

TEXT
播报链路(生成 → 播放):
  复盘引擎 → 播报脚本(text, ≤ 90s)
           → TTS 引擎(edge-tts 本地生成 mp3 / 或直接送 HA TTS)
           → HA → xiaomi_miot.intelligent_speaker  → 小爱音箱

反馈链路(避开语音的技术限制):
  播报同时推送一条手机通知(PushDeer / ntfy / Bark)
    「今天有 1 条错误预警、2 个待复习。有用/没用 →」
  用户点按钮 → 写入 feedback 表 → 回写提问权重 + 播报素材评分
  语音反馈作为可选增强:识别到「下一条/跳过」等固定口令时生效,
  但不作为主回路

内容筛选的"克制"是可量化的(原话"要克制、有温度",那就给数字):

TEXT
每周播报总时长上限:6 分钟(≈7 条)
每日播报时长:45-90 秒(1-3 条)
每条播报只讲一件事,句数 ≤ 3
  条型配额:昨日洞察 1 + 待办/复习 1 + 美好时光 0-1 + 语录 0-1
硬性禁止:
  · 播报"你今天还没学习"这类负向指责
  · 连续 3 天播报同类型内容
  · 播报量因"欠账"而增加(不制造焦虑)

不改的后果:每天早上被自己的 AI 骂一遍,三周后把音箱静音。

ADR-09 ⚠️ 交互式网页总结默认私有,公开需显式选择

原话:「可交互的单页 HTML 总结……支持托管到 Obsidian Publish、Quartz 或 Cloudflare Pages」。

问题:这份报告含情绪趋势、收入财务、错误清单、身体健康——是隐私密度最高的产物。而 Quartz + Cloudflare Pages 是默认公开站,Obsidian Publish 是第三方托管 + 按月 $10(非学生 40% 折扣后 $6/月)。

决策:三层可见性分级。

TEXT
private  → 只在本地 40-Output/,不上网
shared   → 部署到 Cloudflare Pages,但开启 Cloudflare Access / Basic Auth
public   → 显式勾选字段的白名单版本(如:只放九宫格雷达 + 美好时光 + 语录)

默认 private。public 走一份字段白名单模板,从源头就不含敏感字段——而不是"发布后再删"。

不改的后果:某天不小心把错误复盘发到公开站,隐私事故不可逆。

ADR-10 🔧 MCP 工具不能依赖 Obsidian 常驻 → 必须走文件系统直读

原话:「通过 MCP 让日常 AI 对话直接检索我的笔记和媒体资产」。

现状核对(2026-11,重要):市面上主流 Obsidian MCP(mcp-obsidian / obsidian-mcp-server / mcpvault)全部走 Obsidian Local REST API 插件,而该插件只在 Obsidian 桌面应用运行时才服务请求。关闭 Obsidian → 连接被拒。

这直接和需求冲突:

  • 「AI 每天主动提问」→ 需要 24h 后台进程
  • 「晨间播报」→ 需要凌晨无人值守
  • 「资料编译」→ 需要夜间批处理

这些场景下 Obsidian 桌面端不可能常驻开着。

决策:双通道 MCP。

TEXT
通道 1:交互式通道(人在用 Obsidian 时)
  Obsidian Local REST API → mcp-obsidian
  优点:享受 Obsidian 索引、插件能力
  缺点:依赖 GUI 常驻

通道 2:后台通道(无人值守,★ 主通道)
  直接以文件系统方式读 Vault 目录(.md 就是 .md)
  MCPVault(npx @bitbonsai/mcpvault)支持直接指向 vault 路径,不需 Obsidian 运行
  优点:7×24 可用、可容器化、可与编译任务同进程
  缺点:没有 Obsidian 的语义索引 → 需要自己的检索层

配套:自建轻量检索索引(见 §4.2),作为通道 2 的检索后端。这样两条通道行为一致,AI 在任何时候问"我上次关于 X 的结论是什么"都能得到同样答案。

不改的后果:所有后台自动化在第一次重启电脑后就永久失效,而这种失效是静默的——你只会觉得"AI 变笨了"。

ADR-11 ⚠️ 经典语录要有提取门槛,否则全是噪声

原话:「捕获我自己或他人的高信号句子……作为写作、决策和复盘的原子素材库」。

问题:「高信号」没有定义。AI 抽语录的默认行为是把日常对话里所有像样子的句子都标成高信号——一天能抽出 30 条,一个月 900 条,然后这个库再也无法被使用。

决策:三层门槛。

TEXT
候选提取(AI 自动,宽进):
  从日记、语音转写、会议记录中抽取「可能值得留存」的句子
  每条附:来源、语境、情绪标签、信号强度分(0-100)

强度分(AI 评分 + 规则加权):
  +30  含明确的价值判断 / 原则性表述
  +25  含具体的数字或事实(可复用的具体信息)
  +20  产生于重要情绪波动时刻
  +15  被你自己在别处复述或引用过
  -20  日常寒暄、状态播报
  -15  与已有语录语义重复

入库门槛:
  strength ≥ 60  → 进「候选语录池」(周度批量人工挑选,10 条里选 1-2 条)
  strength ≥ 85 且 AI 判定为强原则性 → 直接进正式语录库,
                     但仍会在周报里出现一次供你否决

正式语录库上限约束:宁可 200 条真正可用的,不要 3000 条稀释的。

不改的后果:语录库变成第二个收藏夹——这就是"只收藏不消化"的微观版本,而它恰好长在你最引以为傲的系统里。

ADR-12 ⚠️ "不做什么"清单(防止系统自我吞噬)

别做原因
别让 AI 自动写 spec(直接改)说明书是身份锚点,必须人写。AI 只能提 diff 建议
别建"一站式知识库应用"自研 App 是最大的时间黑洞。Markdown 是接口,工具可替换
别把媒体真的搬进 vault违反 ADR-02,搬运后原文件变动即失效
别追求 100% 自动人工确认点太少 → 垃圾入库 → 不信任 → 弃用。门槛是特性不是缺陷
别同时上 5 个插件Obsidian 社区插件 1500+,多数是噪声。先用核心 + Dataview + Templater
别在没跑通阶段 0 就做阶段 3阶段 0 的真风险不是技术,是"你能不能坚持写 10 天"
别让 Obsidian 成为唯一入口见 ADR-10,必须有纯文件系统路径
别忽略"人工确认"的心理成本每天 2 次确认可持续,每天 20 次是负担

3. 目录结构与数据契约

3.1 Vault 物理布局

TEXT
vault/
├── 00-Inbox/                    # ① 收件层 —— 永不被 AI 写入
│   ├── raw/2026-11/             #   原始素材(只增不改)
│   └── daily/                   #   每日原始流水 2026-11-01.md
│
├── 10-Compile/                  # ② 编译层 —— 指纹化、可重放
│   ├── summaries/               #   语义摘要
│   ├── links/                   #   双链候选
│   ├── clusters/                #   主题聚类
│   ├── verdicts/                #   收藏判决(值得看/片段/摘要/跳过)
│   ├── pointer_health/          #   指针健康报告
│   └── history/                 #   旧版本编译产物(按 pipeline_version 归档)
│
├── 20-Vault/                    # ③ 长期沉淀层 —— 唯一事实源
│   ├── spec/core.md             #   说明书·核心层(常驻注入)
│   ├── spec/state.md            #   说明书·状态层
│   ├── spec/appendix.md         #   说明书·附录(不注入,按需检索)
│   ├── spec/history/            #   说明书快照(可回滚)
│   ├── stages/                  #   阶段记录
│   ├── quotes/                  #   正式语录库
│   └── wiki/                    #   主题 wiki(raw→wiki 编译产物,已验证)
│
├── 30-Fault/                    # ④ 纠错进化层
│   ├── errors/                  #   错误与教训库
│   ├── principles/              #   已验证的原则 / 检查清单
│   └── patterns/                #   复发模式
│
├── 40-Learn/                    # ⑤ 学习能力层
│   ├── kp/                      #   知识点条目
│   ├── reviews/2026-11/         #   复习记录
│   └── graph/deps.yaml          #   依赖 DAG(单一文件,便于版本化)
│
├── 50-Output/                   # ⑥ 主动输出层
│   ├── daily/2026-11/           #   每日复盘
│   ├── weekly/2026-W45/         #   周报 + 交互式 HTML
│   ├── monthly/2026-11/         #   月报 + 交互式 HTML
│   └── broadcasts/2026-11/      #   晨播脚本 + 反馈记录
│
├── 60-Packets/                  # 上下文包落盘(可审计 AI 输入)
│   └── 2026-11-01T0912.json
│
└── 90-System/                   # 元层
    ├── templates/               #   Obsidian 模板
    ├── schemas/                 #   frontmatter schema
    ├── dashboards/              #   Dataview 看板
    ├── logs/                    #   运行日志
    └── config.yaml              #   全局配置(权重、预算、调度参数)

编号前缀的用意:00- 收集区 → 90- 系统区,编号即生命周期顺序。任何时候打开目录都能判断"这东西现在处于什么状态"。

3.2 统一 frontmatter 契约

所有笔记共享四个基础字段,类型专属字段另加。

YAML
# ── 通用 ──
type: raw | pointer | verdict | cluster | wiki | spec | stage | quote
     | error | principle | kp | review | daily | report | packet
id: __<4位hex>
created: 2026-11-01T09:12:00+08:00
updated: 2026-11-01T09:12:00+08:00

3.3 各类型 schema

① 收件层

YAML
type: raw
id: raw_20261101_001
origin: bookmark | file | voice | screenshot | chat_export | manual
source_uri: "https://..."
source_app: xiaohongshu | bilibili | douyin | youtube | wechat | local
raw_text: "..."              # 原始正文/转写/OCR,未加工
captured_at: 2026-11-01T09:12:00+08:00
binary_ref: null             # 二进制素材 → pointer 的 id
YAML
type: pointer                      # 见 ADR-02
id: ptr_20261101_a3f9
uri: "oplist://nas/photos/2026/11/IMG_0031.jpg"
storage: op-list
size_bytes: 4821993
content_hash: sha256:9f2c...
captured_at: 2026-11-01T09:12:00+08:00
index_status: indexed
last_probed_at: 2026-11-01T09:15:00+08:00
semantic_summary: "..."
ocr_text: "..."
media_tags: [会议, 架构图]

② 编译层产物

YAML
type: verdict            # 收藏判决
id: vrd_20261101_003
source_raw: raw_20261101_001
verdict: worth_read | skim | digest_only | skip   # ★ 四档
reason: "..."            # 判决理由(人可读)
score: 78                # 0-100 价值分
salvage: ["要点1", "要点2"]   # ★ skip 也要留可挽救的部分
compiled_by:
  model: "gpt-5.2"
  prompt_hash: sha256:ab12...
  pipeline_version: "compile-v3"
  compiled_at: 2026-11-01T02:14:00+08:00
reviewed: false          # 人工是否已确认
YAML
type: cluster            # 主题聚类
id: clu_20261101_001
theme: "AI 原生架构"
members: [raw_..., raw_...]
wiki_target: "20-Vault/wiki/ai-native-architecture.md"
novelty_ratio: 0.62      # 新内容占比 —— 低则不值得开新 wiki

③ 长期沉淀层

YAML
type: spec
id: spec_core
layer: core | state | appendix
version: 7
principles:               # core 层的结构化原则,可被 MCP 直接引用
  - id: P-01
    text: "先有结论再展开论据"
    scope: always
    evidence: ["2026-09-12", "2026-10-03"]
YAML
type: stage
id: stg_2026_h2_backend
title: "工商银行 · 后端工程能力沉淀期"
scope: life | project | theme
start: 2026-07-01
end: null
goal: "..."
state_now: "..."
timeline:
  - date: 2026-07-01
    event: "..."
    decision: "..."
    lesson_ref: err_20261012_002   # 关联错误
    belief_then: "..."              # ★ 当时的认知(不回改,用于回溯)
    belief_now: "..."               # 现在的认知(可更新)
YAML
type: quote
id: q_20261101_001
text: "..."
source_ref: daily_20261028
context: "复盘时谈到自己的判断方式"
emotion: reflective
strength: 78
applicable_to: [决策, 复盘]
my_reading: "..."          # ★ 我的解读(AI 不写)
confirmed: true            # 人工确认后才为 true

④ 纠错进化层

YAML
type: error
id: err_20261012_002
occurred_at: 2026-10-12
situation: "..."           # 情境
trigger: "..."             # 触发原因
judgment_then: "..."       # 当时的判断
actual_result: "..."       # 实际结果
cost: "..."                # 代价
root_cause:
  category: avoidable | insufficient_info | external | luck   # ★ ADR-04
  text: "..."
  confidence: 0.72
  status: proposed | confirmed                                # ★ 人工确认门
severity: 1-5
recurrence_risk: 1-5
blocking_action: "..."     # 下次如何识别和阻断
verification: "..."        # 验证方式
related_principles: [P-03]
related_kp: [kp_20260901_007]
YAML
type: principle
id: pri_P-03
text: "..."
derived_from: [err_20261012_002, err_20260903_001]   # ≥2 条已确认错误才可提炼
checklist:                 # 可执行形式
  - "..."
validated_count: 2         # 被验证有效的次数
status: active

⑤ 学习能力层

YAML
type: kp
id: kp_20260901_007
title: "JVM 内存模型与并发竞态"
mastery: L1                # L0 未测试 / L1 初识 / L2 理解 / L3 掌握 / L4 精通
mastery_evidence:          # ★ 晋级必须带证据
  - kind: self_test | recite | practice | ai_eval
    at: 2026-10-02
    detail: "能复述 happens-before 三条规则"
    score: 3
retention:                 # ★ 轨 B:FSRS 状态(独立于 mastery)
  fsrs_state: 2           # 0 New / 1 Learning / 2 Review / 3 Relearning
  stability: 4.2
  difficulty: 5.1
  due: 2026-11-03
  last_review: 2026-10-30
deps:
  - kp_id: kp_20260801_002
    kind: hard | soft | related
    note: "不懂 happens-before 完全无法判断竞态"
value: 0.9                 # 0-1,与阶段目标/错误库的关联度
blocking: true             # 是否正阻塞其他 KP
symptom_tags: ["并发竞态", "可见性", "内存屏障"]  # ★ 卡点症状匹配用
assessments:               # 标准验证题(见 §5.2)
  - q: "解释 happens-before 的三条规则,并各举一个反例"
    tags: ["并发竞态", "可见性"]
    checks: ["并发竞态"]
YAML
type: review
id: rev_20261103_007
kp: kp_20260901_007
rating: 1|2|3|4           # FSRS Again/Hard/Good/Easy
response_ms: 4200
mastery_before: L2
mastery_after: L2          # ★ 复习失败会下调 mastery
correct: false
note: "..."
at: 2026-11-03T08:12:00+08:00

⑥ 主动输出层

YAML
type: daily
id: daily_20261101
date: 2026-11-01
grid:                       # 人生九宫格,每格 0-5
  health:     {score: 3, note: "..."}
  finance:    {score: 4, note: "..."}
  social:     {score: 5, note: "..."}
  career:     {score: 3, note: "..."}
  family:     {score: 4, note: "..."}
  learning:   {score: 2, note: "..."}
  growth:     {score: 4, note: "..."}
  experience: {score: 3, note: "..."}
  leisure:    {score: 4, note: "..."}
errors_today: [err_20261101_001]
lessons_learned: ["..."]
insights:                  # AI 草稿
  - text: "..."
    confidence: 0.68
    confirmed: false       # ★ 人工确认
mainline_calibration: "..."   # 主线校准
tomorrow_actions: ["..."]
beautiful_moments: ["..."]   # 美好时光
YAML
type: report
id: rpt_2026_w45
period: week
range: 2026-11-01/2026-11-07
visibility: private | shared | public   # ★ ADR-09
data_sources: [daily, error, kp, stage, quote]
html: "50-Output/weekly/2026-W45/index.html"
generated_by:
  model: "gpt-5.2"
  pipeline_version: "report-v2"
feedback: {useful: 3, useless: 1}

3.4 人机分工总表

产出AI 做人做门禁形态
原始采集✅ 全自动触发动作无
摘要 / 双链 / 索引✅ 全自动可选抽查无
收藏判决✅ 提议批量复核(周)reviewed: false
主题 wiki✅ 起草首次确认status: draft → published
个人说明书⚠️ 提 diff✅ 写入git 式人工合并
阶段记录⚠️ 提 diff✅ 写入同上
经典语录✅ 提候选✅ 挑选 + 写解读confirmed: false
错误记录✅ 起草✅ 根因归类确认status: proposed
原则提炼✅ 提议✅ 采纳需 ≥2 条 confirmed 错误
掌握度⚠️ 建议 + 证据✅ 终审mastery_evidence 必填
复习调度✅ 全自动无无
复盘洞察✅ 起草✅ 确认confirmed
周月报✅ 全自动生成可选反馈visibility 分级
晨播内容✅ 筛选反馈调参配额硬上限
主动提问✅ 生成候选回答每日预算 ≤2

4. 上下文装配层(系统的核心实现)

4.1 为什么必须单独一层

原方案里"AI 每次对话引用个人说明书"。但真正有用的上下文远不止说明书——它需要把说明书、当前阶段、历史错误、学习卡点、历史语录、媒体指针按当前话题动态组装。

如果这些逻辑散落在各个 prompt 里,会得到 N 个不一致的 AI 入口(豆包一个说法、DeepSeek 另一个说法),也无法审计"AI 到底看到了什么"。

做法:唯一装配入口。 所有 AI 交互先调 assemble_context(intent, query, budget),返回结构化 ContextPack。

4.2 检索层(通道 2 的后端)

Obsidian 的索引不可用时(ADR-10),自建检索:

TEXT
索引构建(增量,随编译任务一起跑):
  ① 全文索引:frontmatter + 正文首段 + 标题 → SQLite FTS5
  ② 向量索引:对 spec / stage / error / kp / wiki 正文做 embedding
     → 本地存储(sqlite-vec 或 LanceDB)
  ③ 媒体索引:图片/视频/音频 → RecallForge 或 Immich
  ④ 关系索引:wikilink 图 + deps DAG → 图查询

检索策略(混合 + 重排):
  query → BM25(全文) + 向量召回 → RRF 融合 → cross-encoder 重排 → top-K
  这套流程与 RecallForge 的实测一致(BM25 R@10 85.9% → +rerank 97.8%),
  说明它是当前本地 RAG 的合理默认

4.3 装配算法

PYTHON
def assemble(intent, query, budget=2500):
    pack = ContextPack()
    # 1. 常驻层(不可裁剪)
    pack.spec_core = load_spec_core()          # ~400-600 tok
    # 2. 意图路由:决定拉哪些模块
    plan = route(intent)
    # 3. 按优先级填充,直到 token 预算耗尽
    for module in plan.priority_order:
        items = retrieve(module, query, k=plan.k[module])
        pack.add(module, items, remaining_budget)
    # 4. 生成预警(见 §4.4)
    pack.warnings = generate_warnings(pack, query)
    # 5. 落盘审计
    write_packet(pack)
    return pack

意图路由表:

intent额外拉取典型问题
daily_chatspec_state, kp_due"今天状态怎么样"
decisionerrors_matched, spec_state, stages"这个方案你怎么看"
reviewdaily(近7天), errors_matched, kp_due, quotes"帮我复盘这周"
learnkp_due, kp_blocked, deps"我该学什么"
writequotes, wiki, spec_core"帮我写一段"
lookupnotes, pointers"我上次关于 X 的结论"
planstages, kp_blocked, principles"这季度怎么安排"

4.4 主动预警:四条规则

这是需求里反复追问的能力,落成四条可执行规则:

TEXT
规则 1 · 错误复发预警
  触发:当前 query 语义相似度 与 某条 confirmed 错误的 situation > 0.72
  产出:「这类场景你 8 月 12 日踩过一次——当时判断『需求方会接受降级方案』,
        实际结果是延期两周。这次的关键差别是……」
  降级:命中 proposed 错误时,文案改为「有一条待确认的相似记录」

规则 2 · 前置缺失预警
  触发:query 涉及 KP_B,且 B 有 hard 前置 A 且 A.mastery ≤ L1
  产出:「这段涉及『分布式事务』,它的前置『MySQL 隔离级别』你目前只到初识。
        要不要先花 10 分钟补一下?或者直接往下走,我会标注不确定的地方。」

规则 3 · 到期复习预警
  触发:today 有 FSRS 逾期且 value ≥ 0.6 的 KP
  产出:「今天有 2 个到期复习,其中『Redis 持久化』上次答错了。」

规则 4 · 阶段偏离预警
  触发:当前活动与 stage.goal 连续 3 天无交集(时间/金钱/注意力分布)
  产出:「这周你的记录几乎都在『学习成长』,
        但当前阶段目标是『完成 XX 迁移』。要不要重排一下?」

预警的节流:单次对话最多 2 条预警,按置信度取前 2。同类预警 7 天内不重复。

4.5 反馈闭环

所有交互都落一条 feedback,用于调参:

YAML
type: feedback
id: fb_20261103_012
target_type: question | broadcast | report | verdict
target_id: q_20261103_004
verdict: useful | useless | too_generic | too_deep
weight_delta: -0.5
at: 2026-11-03T10:20:00+08:00

反馈直接改 ADR-07 的优先级权重表(存 90-System/config.yaml),以及 verdict 规则的 salvage 策略。


5. 复盘、纠错与学习调度

5.1 每日节奏

TEXT
06:50  ┊ 晨间播报(45-90s)—— 昨日洞察 / 今日复习 / 1 条美好时光
07:30  ┊ 主动提问窗口 1(≤1 问,捕获型:今天有什么值得记的)
12:30  ┊ 主动提问窗口 2(≤1 问,反思型或学习型)
21:30  ┊ 晚间复盘 —— 九宫格 + 今日错误与失误 + 学习状态更新
22:00  ┊ AI 生成复盘草稿 → 人工确认 → 写入 daily
22:30  ┊ 编译任务启动(异步,见 §5.5)
02:00  ┊ 复习队列计算(FSRS 到期扫描)

核心原则:人工确认点每天 ≤3 个(2 个提问 + 1 次复盘确认)。这个数字是整个系统可持续性的关键指标。

5.2 掌握度的证据体系

L0 未测试 → L1 初识 → L2 理解 → L3 掌握 → L4 精通,晋级必须携带证据:

级别定义判定证据谁来判
L0未测试无—
L1初识能复述定义/用途AI 可判
L2理解能讲清机制 + 举出一个自己的例子AI 可判(附证据)
L3掌握独立完成一次真实任务人确认(AI 不可判)
L4精通能教别人 / 能做技术选型 / 踩过坑后仍能避坑人确认

L3 必须是"真实任务"——这是刻意的摩擦。因为"我懂了"和"我能在真实约束下用出来"之间有巨大鸿沟,而绝大多数学习系统的"掌握"其实停在 L2。

标准验证题:每个 KP 配 3-5 道题(可自动生成),题目带 symptom_tags(ADR-06 的症状匹配基础):

YAML
# 挂在 kp 的 assessments 字段
assessments:
  - q: "解释 happens-before 的三条规则,并各举一个反例"
    tags: ["并发竞态", "可见性"]
    checks: ["并发竞态"]
  - q: "..."
    tags: ["内存屏障"]

用户在 B 上答错时,用 B 的题目标签去匹配 A 的验证题标签(ADR-06 卡点检测)。

5.3 复习队列排序

纯 FSRS 序不够。加权:

TEXT
priority = fsrs_overdue_ratio × value × (1 + blocking_impact)

  fsrs_overdue_ratio = (today - due) / max(1, interval)      逾期程度
  value              = 0.3 + 0.4×(与阶段目标关联) + 0.3×(错误库关联频次)
  blocking_impact    = 1.0 若该 KP 阻塞其他 hard 依赖 KP,否则 0

每日复习上限:12 条(超过就顺延,宁可少也不要变成负担)

复习交互:一次一卡,先自测(遮挡答案)→ 作答 → 评级(Again/Hard/Good/Easy)→ FSRS 更新 + mastery 可能下调。

掌握度与复习的双向作用:

  • 复习 Again → 若因"记忆遗忘"导致下滑,mastery 降到 min(mastery, L2);若因"理解错误"导致,降到 L1 并生成一条 error(proposed)
  • mastery 提升到 L3/L4 → 若 value 低则降低复习频率(延长 interval),腾出额度给高价值项

5.4 依赖图与回补路径

PYTHON
def find_backfill_path(target_kp, blocked_by):
    """拓扑最短回补路径:找到能最快解除阻塞的前置链"""
    # 只在 hard 依赖上搜索
    # 优先选「mastery 低 + 预估耗时短 + 解锁收益高」的节点
    # 预估耗时 = base_cost(kp) / (1 + 0.5 * mastery)
    return shortest_path_by_cost(blocked_by, target_kp)

依赖图维护:40-Learn/graph/deps.yaml 单一文件,便于版本化和 diff。

YAML
deps:
  - from: kp_20260801_002    # MySQL 隔离级别
    to: kp_20260901_007      # JVM 内存模型与并发竞态
    kind: hard
    note: "..."
    source: manual | ai_suggested
    confirmed: true

AI 可以建议依赖,但 hard 类型必须人工确认(confirmed: true)—— 否则一次错误推断就能把你卡死。

5.5 编译任务与回写规则

这是需求里明确问的"资料沉淀的触发频率和回写规则",完整回答如下。

TEXT
触发频率:
  实时(<5 分钟)  · 收藏/截图/语音入库 → 立即生成摘要 + 双链候选
  每 15 分钟      · 判决队列批量处理(聚类判断"值得看/片段/摘要/跳过")
  每日 02:30      · 全量编译:指针健康探测、聚类、wiki 候选
  每周日 03:00    · 周度沉淀:聚类 → wiki 候选 → 主题重写
  每月 1 日 03:00  · 月度沉淀:主题页合并/拆分/归档;阶段记录里程碑检查

回写规则(严格单向,绝不反向覆盖):

  raw ──► compile/summaries        (AI 自动,可重放)
  raw ──► compile/verdicts        (AI 自动,人批量复核)
  compile ──► wiki                 (AI 起草,人首次确认 → published)
  wiki ──► spec                    (仅提议 diff,人合并)
  daily ──► stage                  (仅提议,人合并)
  error(confirmed) ──► principle   (≥2 条才提议,人采纳)
  error ──► kp.mastery 下调        (自动,但记录证据)
  review ──► kp.retention 更新     (自动,FSRS)

  ★ 永不发生:
     wiki 覆盖 raw            compile 覆盖 daily
     spec 被自动改写          error 被自动确认
     已 published 的 wiki 被静默修改(改动走 git commit,人可 review)

幂等与缓存键:

PYTHON
cache_key = sha256(content_bytes + pipeline_version + model_id)
# 命中 → 跳过;未命中 → 编译并写产物(带指纹)

回写冲突处理:同一 wiki 被两条编译任务同时更新 → 用文件锁 + 版本号检查,冲突时保留两份并标记 conflict: true,人工选择,绝不自动合并。


6. 主动输出层

6.1 交互式网页总结

频率:周报每周日 03:30 生成;月报每月 1 日 03:30 生成。

数据来源(全部来自 vault,可离线重算):

TEXT
daily/     → 九宫格雷达、情绪/能量趋势、美好时光时间线
error/     → 错误复发与阻断统计、严重度分布、Top 复发模式
kp/        → 掌握度分布(初识/理解/掌握/精通占比)、复习通过率、
              遗忘预警清单、学习进度曲线
stage/     → 阶段目标进度条、里程碑时间轴
quote/     → 经典语录轮播
spec/      → "本月 AI 眼中的我"(基于本月数据与 spec 的偏差描述)

实现:Python 生成自包含 HTML(内联 CSS/JS,数据以 JSON 内嵌),零外部依赖,可离线打开。图表用轻量 SVG 手绘或 Chart.js CDN(可选离线降级)。

托管(ADR-09):

方案成本隐私运维适合
本地 + Cloudflare Pages + Basic Auth免费好(密码保护)3 条命令★ 默认推荐
Cloudflare Pages + Access(零信任)免费最好需域名有域名时
Obsidian Publish$6-10/月差(第三方托管)零懒得配 CI
Quartz免费取决于部署需 Node + Git顺便做数字花园

Quartz v4 需 Node 22+;Cloudflare 自 2025 起重心转向 Workers,Pages 仍可用但新功能优先落 Workers。

public 版本:字段白名单模板——只渲染九宫格雷达(模糊化数值)、美好时光、语录、阶段标题,不含错误明细、收入、健康具体项、时间戳精确到天。

6.2 晨间播报

见 ADR-08。补充内容生成规则:

TEXT
选材池(昨日复盘 / 历史上的今天 / 阶段进展 / 语录 / 错误预警 / 学习复习 / 美好时光)
  ↓ 打分
  score = 0.35×信息密度 + 0.25×与当前阶段相关性 + 0.20×未播报过 + 0.20×情绪温度
  ↓ 取 top 1-3,累计 ≤ 90 秒
  ↓ TTS 文本生成(口语化,去掉 markdown 与符号)

"历史上的今天":从往年同日的 daily 中检索,但必须过滤掉当时状态差的记录——早上播报"去年今天你项目延期很痛苦"是反人类的。只播报往年同日的美好时刻或突破。

反馈:手机推送一键(有用/没用),写入 broadcasts/feedback.yaml,影响下次选材的 score。

6.3 主动提问

见 ADR-07。生成规则:

TEXT
候选问题来源:
  ① 捕获型:当天 raw 有未归档的高价值素材 → "这条 X,要记下来吗?"
  ② 反思型:昨日有未分类的错误 → "昨天的判断,你后来觉得哪里不对?"
  ③ 学习型:KP 到期 / 有 hard 卡点 → "阻塞在 Y,要先补 Z 吗?"
  ④ 阶段型:阶段目标节点临近 → "离 X 只剩 5 天,进展如何?"
  ⑤ 校准型:九宫格某维度连续 3 天下降 → "X 连续走低,是发生了什么?"

每个候选打分 → 取 top 2 → 队列 → 每日预算约束

7. MCP 工具集设计

需求是让 MCP "让 AI 在对话中同时调用笔记、媒体索引、长期沉淀层、纠错进化层和学习与能力层,并在相关情境下主动预警历史错误、提示前置知识缺失和推荐下一步学习或复习内容"。

关键设计决定:暴露粗粒度的领域工具,而非一堆细碎 CRUD。 因为 LLM 面对 20 个细工具时的选择准确率远低于面对 5 个语义清晰的工具。

7.1 工具清单

工具作用覆盖层
assemble_context(intent, query, budget)★ 主入口:返回完整 ContextPack(含 warnings)全层
search_notes(query, types, limit, since)跨类型检索笔记①②③
search_media(query, modality, limit)媒体语义检索①(媒体索引)
read_note(path)读指定笔记全层
append_daily(date, section, content)追加到某日日记①⑥
capture(source, content, meta)收件(写 raw/pointer)①
log_error(context, trigger, judgment, result, cost, root_cause_guess)记录错误(proposed)④
confirm_error(error_id, root_cause, severity)确认错误根因④
get_errors(query, confirmed_only)查历史错误④
get_kp_due(date)今日待复习⑤
rate_kp(kp_id, rating, response)复习评分(更新 FSRS + mastery)⑤
assess_kp(kp_id, evidence)提交掌握度证据⑤
get_learn_plan(date)今日该学什么 / 该复习什么 / 前置缺什么⑤
add_dep(from, to, kind)添加依赖(hard 需确认)⑤
get_stage(scope)阶段记录③
get_quotes(query, limit)语录检索③
propose_spec_patch(section, diff)提说明书修改建议(不直接写)③
generate_report(period)生成周/月报⑥
daily_brief(date)晨播脚本⑥

7.2 双通道配置

JSON
{
  "mcpServers": {
    "pcs-filesystem": {
      "command": "npx",
      "args": ["-y", "@bitbonsai/mcpvault@latest", "D:/vault/pkb/vault",
               "--exclude", "90-System/logs"],
      "env": { "MCP_LOG_LEVEL": "info" }
    },
    "pcs-obsidian": {
      "command": "uvx",
      "args": ["mcp-obsidian"],
      "env": {
        "OBSIDIAN_API_KEY": "<本地 REST API 插件的 key>",
        "OBSIDIAN_HOST": "127.0.0.1"
      }
    },
    "recallforge": {
      "command": "recallforge",
      "args": ["serve", "--mode", "hybrid", "--backend", "torch"]
    }
  }
}

注意事项(都是实测踩坑点):

  • mcp-obsidian / obsidian-mcp-server 走 Local REST API,Obsidian 关闭即失效 → 只用于交互式通道
  • mcpvault 直接指 vault 路径,不需 Obsidian 运行 → 后台通道主力
  • RecallForge 需 Python 3.12+;embed 模式 ~4GB VRAM、hybrid ~8GB、full ~12GB。多数人选 hybrid
  • 密钥按 vault 隔离;不要把整个 vault 暴露给需要读全部的 agent
  • 读工具可全开,写工具建议在 client 白名单里关闭 delete,用 append 代替 write

7.3 审计

每次工具调用记录到 60-Packets/:

JSON
{
  "at": "2026-11-01T09:12:33+08:00",
  "intent": "decision",
  "query": "这个降级方案能接受吗",
  "budget": 2500,
  "used_tokens": 2180,
  "modules": {
    "spec_core": ["P-01", "P-04"],
    "errors_matched": ["err_20260812_001"],
    "kp_blocked": ["kp_20260901_007"],
    "notes": ["20-Vault/wiki/..."]
  },
  "warnings": [
    {"rule": "error_recurrence", "target": "err_20260812_001", "confidence": 0.81}
  ]
}

能回答"AI 当时到底看到了什么"——这是信任的物理基础。


8. 分阶段落地路径

原则:每阶段结束时你都有一个能独立用起来的系统,而不是一个半成品大工程。阶段 0 的真风险不是技术,是"你能不能坚持写 10 天"。

阶段 0 · 手写基线(Week 1-2)

目标:验证"记录本身"能不能持续。零自动化。

TEXT
做什么:
  □ 建 vault 目录结构(只有 20-Vault / 50-Output / 90-System)
  □ 手写 spec/core.md —— 一次写透,200-500 字,只写真正不可变的
  □ 建 daily 模板(九宫格 + 今日错误 + 明日行动)
  □ 建 kp 模板 + 手写 10 个当前最想掌握的知识点
  □ 每天写 daily,连续 10 个工作日不漏
  □ 手写 3 条错误(真实的,疼的那种)

不做什么:
  × 不装任何插件(除了核心)
  × 不搞自动采集
  × 不搞 MCP
  × 不做网页报告

验收:
  ✓ 10 个工作日 daily 不断档
  ✓ spec/core.md 写完后你自己愿意每天读一遍
  ✓ 手写的 3 条错误里,至少 1 条让你意外("我居然是这样想的")

这一步的产出是你后面所有自动化的"分类体系"。跳过它,后面 AI 生成的摘要无处可放。

阶段 1 · 收件与编译(Week 3-6)

目标:把"手动搬运"变成"自动入箱 + 自动摘要"。

TEXT
做什么:
  □ 装核心插件:Templater + Dataview + Obsidian Web Clipper
  □ 装 Python 环境,写第一个编译脚本(raw → summary + 双链候选)
  □ 接入 2-3 个真实来源(Web Clipper + 手机分享 + 一个网盘目录)
  □ 实现 verdict 四档判决 + 每周批量复核
  □ 实现每日 02:30 定时编译(Windows 任务计划 / cron)
  □ 编译产物带指纹(ADR-01)
  □ 写第一版 spec/state.md

不做:
  × 不做 MCP(还没到)
  × 不做 FSRS
  × 不做网页报告

验收:
  ✓ 连续 2 周,收藏不需要手动搬运和分类
  ✓ 编译任务零手工触发
  ✓ verdict 判决的人工改动率 < 20%(超了说明提示词要调)
  ✓ 指针笔记带 content_hash,健康检查能发现失效指针

关键指标:判决改动率。如果 AI 判决经常被改,说明 AI 对"什么值得看"的理解和你的不一致——这时要改提示词或调整四档定义,而不是增加人工复核量。

阶段 2 · 纠错进化闭环(Week 7-10)

目标:让系统开始产生复利——同类错误不再犯第二次。

TEXT
做什么:
  □ 建 error/ 与 principle/ 结构,配 frontmatter schema
  □ 写错误确认流程(AI 起草 → 人确认根因)
  □ 在复盘里固定"今日错误与失误"环节
  □ 实现「错误相似度检索」与主动预警规则 1
  □ 上下文装配器 v1(先只用 spec + error + daily)
  □ 上 MCP(双通道,filesystem 为主)
  □ 写第一份周报(Markdown 先出,HTML 不急)

不做:
  × 不做 FSRS(先把错误闭环跑通)
  × 不做主动提问
  × 不做语音

验收:
  ✓ 错误库 ≥ 10 条,且 ≥1 条被提炼成 principle
  ✓ 主动预警至少命中过 1 次并且有用
  ✓ MCP 在日常 AI 对话里能回答"我上次关于 X 怎么想的"
  ✓ ★ 某条 confirmed 错误在真实场景中被成功阻断  ← 核心验收

最后一条是唯一真正重要的验收。错误库写了 100 条但一条都没阻断过,说明它只是个好看的日记。

阶段 3 · 学习调度与主动输出(Week 11-16)

目标:把学习变成有调度的系统,把系统变成会主动说话的助手。

TEXT
做什么:
  □ 装 FSRS 调度(py-fsrs 或 Obsidian 插件)
  □ 实现双轨掌握度 + 证据体系 + 标准验证题
  □ 建依赖 DAG,手工录入 20-30 条 hard/soft 依赖
  □ 实现复习队列三因子排序 + 每日上限 12
  □ 实现主动提问(预算 ≤2/天)+ 反馈权重调参
  □ 实现晨间播报(HA + xiaomi_miot)+ 手机反馈
  □ 实现交互式周报/月报 HTML(先本地,再 CF Pages + Basic Auth)
  □ 实现"历史上的今天"(过滤负面记录)

不做:
  × 不做多模态媒体索引(媒体量大且非核心)
  × 不追求 100% 自动化

验收:
  ✓ 连续 4 周,复习队列未被放弃(每日完成率 > 70%)
  ✓ 主动提问的"有用"反馈率 > 60%
  ✓ 晨播连续 2 周没有被静音
  ✓ 周报 HTML 真的会被你打开看(打开率 > 50%)

阶段 4 · 多模态与规模化(Week 17+,可选)

TEXT
做什么:
  □ 媒体语义索引:RecallForge(本地多模态)或 Immich(相册向)
  □ 指针健康全量探测 + 内容寻址恢复
  □ 语音转写接入(会议 / 灵感)
  □ 阶段记录自动里程碑检查
  □ 若有余力:数字花园(Quartz)+ 公开版周报

验收:
  ✓ "帮我找一下去年那张架构图"能命中
  ✓ 语音碎片不再丢失

阶段间的时间分配建议

TEXT
Week 1-2   阶段 0    ████                      40%
Week 3-6   阶段 1    ████████████              30%
Week 7-10  阶段 2    ████████                  20%
Week 11-16 阶段 3    ██████████████            10%
Week 17+   阶段 4    ████                      ← 可选

不要跳阶段。 每一阶段都是下一阶段的输入,跳过去会导致后面返工。


9. 工具选型

9.1 选型原则

TEXT
1. Markdown 是硬边界。 任何工具都不能成为唯一事实源
2. 能离线就离线。      云端服务是可选增强,不是依赖
3. 优先选有 MCP 的。   让 AI 用标准接口接入
4. 优先选可替换的。    工具随时会死,格式不会
5. 警惕"全家桶"营销。  一站式方案 = 一站式锁定

9.2 选型表

环节★ 首选备选关键说明
底座Obsidian(本地 Markdown 仓库)Logseq / 思源Obsidian 生态最成熟,MCP 插件最多。不是任何云笔记(本地优先是前提)
同步Obsidian Git(私有仓库)Syncthing / iCloudGit 顺带给你版本历史——这是"说明书可回滚"的基础。多设备同时编辑会冲突,Obsidian Git 在移动端不稳定
模板Templater核心 TemplatesTemplater 能跑 JS、可自动归档到指定目录,是自动化入口
查询/看板Dataview + 核心 Bases手工 DataviewJSBases 是核心插件,0 依赖,新手友好;Dataview 表达力更强
网页抓取Obsidian Web Clipper单点官方插件,逐条抓正文并存 Markdown
快速采集QuickAdd + 手机快捷指令手势 / 分享到文件手机端「快捷指令 → 存到 iCloud Drive → Obsidian 同步」是最低摩擦路径
媒体语义索引RecallForge(MCP,16-26 工具)Immich(相册向,CLIP+人脸+相似图)RecallForge 跨模态(文本/图/文档/视频/音频),本地优先,出 MCP;需 Python 3.12+,hybrid 模式 ~8GB VRAM。Immich 强在相册管理和人脸,做语义索引也行,但它偏"相册"不是"检索引擎"
大文件访问OpenList(Alist fork)+ Rclone直接本地路径OpenList 提供全站 WebDAV(/dav)+ 本地存储/OneDrive/S3/WebDAV 驱动;海外 VPS 挂国内网盘大概率限速,国内盘建议留官方客户端
间隔重复py-fsrs(自建)Obsidian Spaced Repetition / Decks / True Recall见下方说明
向量检索sqlite-vec 或 LanceDBChroma / Qdrant本地优先选前两者。RecallForge 本身就是 LanceDB + Qwen3-VL 的路线
嵌入模型Qwen3-Embedding(本地)bge-m3 / OpenAI Embedding中文语料优先 Qwen 或 bge 系列;RecallForge 用 Qwen3-VL-Embedding-2B
重排模型bge-reranker-v2-m3(本地)cross-encoderRecallForge 数据显示重排带来 R@1 +20.7%,是最大的单点提升
MCP(vault)MCPVault(filesystem,7×24)mcp-obsidian / obsidian-mcp-server(需 Obsidian 常驻)见 ADR-10,这是最容易踩的坑
MCP(媒体)RecallForgeImmich API直接就是 MCP server
播报Home Assistant + xiaomi_miotHA + DLNAxiaomi_miot.intelligent_speaker 直连 TTS 最稳;DLNA 需米家实验室开启且音箱要能反连你
TTSedge-tts(免费高质量)HA 内置 TTS / Piper(离线)中文自然度高
推送PushDeer / ntfy / Bark企业微信机器人Bark iOS 体验最好,ntfy 自托管最自由
报告托管Cloudflare Pages + Basic AuthObsidian Publish / Quartz见 ADR-09。Quartz v4 需 Node 22+
静态站Quartz v4Jekyll/HugoQuartz 原生支持 wikilink / 双链 / 图谱 / Callout / LaTeX
编排Windows 任务计划 / cronn8n编译、复习计算这些用 cron 就够,别上工作流引擎
备份Git + 定期全量快照—代码化的资产在 git 里,原始媒体在别处

9.3 关于间隔重复插件的一个提醒

Obsidian 生态里有 4-5 个闪卡插件(Spaced Repetition 60万+下载 / Decks / True Recall / Lemma / Obsidian_to_Anki)。它们都很好,但这里的需求不是背卡片——要管的是"知识点的掌握度 + 依赖 + 优先级",这三样都不是卡片插件能表达的。

建议:py-fsrs(Python 官方实现,MIT)自建调度器,FSRS 状态直接存在 KP 的 frontmatter 里。这样:

  • 状态跟着 Markdown 走,Git 可版本化,不被插件锁死
  • 能实现三因子优先级排序(插件做不到)
  • 能把 mastery 与 retention 双轨建模(插件做不到)
  • 换调度器(FSRS → SM-2)不影响数据结构

卡片式插件(Spaced Repetition)可以留作补充,用来存碎片化的"问答型"知识点(比如 API 参数、术语定义),而系统性的概念 KP 走自建调度。

9.4 六个关键取舍的速查

议题选 A选 B本案选择理由
底座ObsidianNotionObsidian本地优先 + Markdown + git 友好
MCP 入口Obsidian REST文件系统直读双通道后台任务不能依赖 GUI 常驻
语义检索纯向量混合+重排混合+重排重排带来 R@1 +20.7%,性价比最高的一步
媒体索引ImmichRecallForgeRecallForge 为主它是检索引擎且出 MCP;Immich 强在相册管理,可并存
复习调度Obsidian 插件py-fsrs 自建py-fsrs 自建需要双轨掌握度 + 三因子排序,插件表达不了
报告托管Obsidian PublishCF Pages + AuthCF Pages + Auth免费 + 数据自主 + 有密码保护

10. 风险清单与缓解

风险症状缓解
门禁太松半年后库里 80% 是 AI 垃圾写操作一律要人确认;定期做"清理周",把 reviewed: false 超过 30 天的批量归档
门禁太严每天确认 20 次,两周后弃用每日人工确认点硬上限 ≤3(ADR-07);自动化优先扩"读"而非"写"
静默改写历史模型升级后摘要全变,不知道变了什么编译指纹 + 缓存键 + compile/history/ 归档(ADR-01)
指针集体失效网盘限流后所有媒体引用打不开content_hash + 健康检查 + 内容寻址恢复(ADR-02)
错误库毒化AI 把运气归类成"可避免错误",产生假教训根因分类必须人工确认(ADR-04);只有 confirmed 才可提炼原则
复习队列变成负担推的都是你早就懂的老概念双轨建模 + 三因子排序 + 每日上限 12(ADR-05)
学习被依赖图卡死必须先学完 30 门课才能动手依赖三级分类 + 症状匹配驱动(ADR-06)
通知疲劳推送全被无视,包括重要的提问预算 ≤2/天 + 反馈降权 + 静默模式(ADR-07)
隐私泄漏错误复盘被发到公开站三级可见性 + public 走字段白名单模板(ADR-09)
后台自动化静默失效重启电脑后 AI 突然变笨文件系统通道为主通道(ADR-10)+ 每周心跳检查
规格说明书膨胀spec 变成没人读的 3000 字三层拆分 + token 预算裁剪(ADR-03)
语录库稀释900 条"语录",一条都用不上强度分门槛 + 上限约束(ADR-11)
"完美系统"陷阱一直在设计架构,一个月没写一条日记阶段 0 硬门槛:先手写 10 天

11. 回到那个元问题

回到开篇:你说 AI 消灭了偶然复杂度,但软件复杂度还在;程序员要从代码生产者走向系统价值设计者。

这个个人上下文系统,恰好是这个命题的一个具体实例:

TEXT
偶然复杂度(AI 消灭的部分)        本质复杂度(人必须守住的)
─────────────────────────────      ─────────────────────────────
分类 / 命名 / 摘要 / 去重          什么值得沉淀
双链 / 索引 / 检索 / 生成          什么算真教训(运气 vs 失误)
调度 / 提醒 / 编译 / 播报          阶段边界在哪
优先级计算 / 排序 / 统计            哪些门禁不能拆

AI 让"维护一份高质量的个人上下文"从一件消耗意志力的事,变成了一件有确定性的事。 这是"代码生产者 → 系统价值设计者"的个人版本:你的产出不再是每周写了多少行,而是这套系统是否在持续降低你犯同类错的概率、持续提高你复用已有资产的能力。

而复利的来源不是数据量,是这个闭环:

TEXT
记录 → 归因 → 提炼原则 → 提前预警 → 成功阻断 → 验证有效 → 原则升级 → 更多预警

每转一圈,下一圈的起点就高一点。这正是软件工程里唯一真正复利的东西——不是代码行数,是系统本身的可演进性。

至于"没有银弹"——对,这个系统没有银弹。它有 12 个门禁、30 个 schema、5 个自动化阶段。但这些门禁不是复杂度,它们是你和 AI 之间那份被明确定义过的契约。 没有契约的自动化才叫没有银弹。


附录 A · 需求对照索引

原始需求落在哪关键决策
六层各放什么§3.1 / §3.3目录 + schema
说明书如何生成/更新/调用§3.3 / §4.3 / §7.1ADR-03 三层拆分 + 常驻注入
阶段记录如何生成/更新/调用§3.3 / §4.3belief_then 不回改,支持回溯
经典语录如何生成/更新/调用§3.3 / §6.1ADR-11 强度分门槛
错误与教训库如何生成/更新/调用§3.3 / §4.4 / §7.1ADR-04 人工确认根因
待学习清单与掌握度§3.3 / §5.2 / §5.3ADR-05 双轨模型
资料沉淀的触发频率§5.5实时/15min/日/周/月 五级
资料沉淀的回写规则§5.5严格单向 + 冲突人工裁决
每日九宫格复盘§3.3 / §5.19 维度 score+note
错误复盘§5.1 / §5.4每日固定环节 + confirmed 门
学习复习§5.3三因子排序 + 每日上限
AI 主动提问§6.3 / ADR-07预算 ≤2/天 + 五类候选
周报 / 月报如何衔接§6.1 / §5.5周日/月 1 日,与编译任务串联
学习顺序的依赖管理§5.4 / ADR-06三级依赖 + 症状匹配
掌握度分级标准§5.2L0-L4 + 证据必填 + L3 要真实任务
遗忘复习调度落地§5.3 / §9.2py-fsrs + 双轨 + 三因子排序
交互式网页总结的频率§6.1周日 03:30 / 月 1 日 03:30
交互式网页总结的数据来源§6.1全部来自 vault,可离线重算
交互式网页总结的托管方式§6.1 / ADR-09CF Pages + Basic Auth,默认私有
晨播内容筛选§6.2 / ADR-08打分 + 配额硬上限 + 禁止项
TTS 推送链路§6.2 / ADR-08HA + xiaomi_miot,反馈走手机
反馈闭环§4.5 / §6.2反馈 → 权重调参
MCP 如何同时调用各层§7.120 个粗粒度领域工具
主动预警历史错误§4.4 规则 1相似度 > 0.72,confirmed 才预警
提示前置知识缺失§4.4 规则 2 / §5.4hard 依赖 + 症状匹配
推荐下一步学习/复习§4.4 规则 3 / §5.3 / §7.1三因子排序队列
分阶段起步路径§85 阶段,各带验收标准
关键工具选型建议§920 个环节 + 6 个关键取舍

附录 B · 分享版设计(用于技术分享场合)

B.1 一个可讲的叙事主线

这套系统本身是个很好的分享素材,因为它恰好是"程序员从代码生产者走向系统价值设计者"的最小可运行样本。建议的讲法:

TEXT
开场(3 min)
  「AI 消灭了偶然复杂度,但软件工程没有银弹。」
  「今天我不讲技术,讲一个我把这句话落到自己身上的方案。」
  抛出问题:你的 AI 是不是每次都从零开始?

中段(12 min)
  六层架构 → 核心原则(AI 消灭怎么做,人守住做什么)
  → 三个反直觉的设计决策(错误根因人工确认 / 掌握度双轨 / 依赖分级)
  → 上下文装配器(一次实现四处复用)
  → MCP 双通道(那条会静默失效的坑)

收尾(5 min)
  复利闭环:记录→归因→提炼→预警→阻断→验证→升级
  「复利不来自数据量,来自下一圈起点更高」
  落地路径:先手写 10 天,别先设计架构

B.2 三个最值得单独讲的"反直觉决策"

如果时间只够讲三件事,讲这三个——它们最能体现"设计"和"堆功能"的区别。

① 错误根因必须人工确认

AI 会系统性把"运气成分"误判为"可避免错误"——因为运气没有可提取的规律,AI 倾向于强行找规律。

一条假教训进去,要靠很多真教训才能稀释。错误库的毒化是单向棘轮。

② 掌握度与记忆保持是两条独立的轨

"我精通这个概念但记不住公式"——用一套数字表达两者,这个真实情况就表达不了。

更糟的是把「掌握」直接当 FSRS 评分去调度,你会反复被推已经懂的老概念。这是间隔重复系统被弃用的第一原因。

③ 主动提问要设预算,不是设条数

3-5 个/天 + 复盘 + 晨播 = 每天 8-10 次打断。三周后你会本能地忽略所有推送,包括真正重要的。

硬上限 ≤2 个/天,其余进待提问池。 门禁的价值不在于严,在于可持续。

B.3 分享时的"翻车预案"

观众会问怎么答
"这不就是又搞了个笔记软件?"差别在四类资产的分层:说明书/阶段记录/语录/错误库,各有独立的生成频率、人工门禁和注入策略。不是文件夹分类。
"AI 不就能全自动吗?"能,但全自动的错误库是有毒的。自动归因会系统性误判运气,而错误库一旦被污染就不可逆。见 ADR-04。
"这些工具会不会很快死?"会。但 Markdown 是硬边界——工具死掉,数据还在,换个工具接着用。这是选型原则第 1 条。
"我要不要自己写个 App?"不要。自研 App 是最大的时间黑洞,Markdown 是接口。你这套系统里最值钱的不是代码,是那 12 条 ADR。
"每天确认 3 次会不会烦?"会烦,所以这是硬指标。如果确认点涨到 5 次以上,人设上限就会破——门禁是特性不是缺陷。

B.4 现场演示建议(10 分钟版)

TEXT
1. 打开 60-Packets/ 里一个真实的 ContextPack 落盘
   → "这就是 AI 刚才看到的全部内容,可审计"

2. 现场问豆包/DeepSeek:"我上次关于 X 是怎么想的?"
   → MCP 调 assemble_context → 返回带 warnings 的 ContextPack
   → 命中一条历史错误,现场展示预警文案

3. 打开一个 kp 文件,展示 mastery 与 retention 两个字段
   → "看,这是两个正交的维度,被塞在一起就废了"

4. 打开一个 error 文件,展示 root_cause.status: proposed
   → "这条还没被我确认,所以它还不能变成原则"

5. 打开 deps.yaml,展示 hard / soft / related 三级
   → "如果全是 hard,这个系统三周内就会变成课程表"

演示的核心不是功能多,是"每一步都能被质询"——这正是"系统价值设计者"和"代码生产者"的区别。

B.5 可复用的三张图(分享时用)

  1. 六层 + 反馈闭环(本文档开头已给)——讲整体结构
  2. 双轨模型对比图——讲掌握度 vs 记忆保持
  3. 门禁矩阵——讲人机分工(§3.4 那张表的可视化)