代号 PCS(Personal Context System)
本地优先 · Markdown 单一事实源 · AI 提议—人确认 · 六层分工 · 可重放编译
0. 先回答那个元问题
你开篇那段话其实是整个方案的题眼,值得先翻译成设计语言。
AI 消灭了偶然复杂度,但软件工程没有银弹,软件本身的复杂度依旧存在。
这句话在个人知识系统里精确对应两层复杂度:
| 复杂度类型 | 具体表现 | AI 能否消灭 | 谁负责 |
|---|---|---|---|
| 偶然复杂度 | 分类、命名、摘要、去重、双链、格式统一、检索、生成日报 | ✅ 基本能消灭 | AI 全权 |
| 本质复杂度 | 判断什么值得沉淀、什么算真教训、什么该复习、阶段边界在哪 | ❌ 消灭不了 | 人给约束(Gate) |
这就是全案唯一的核心架构原则:AI 消灭"怎么做",人只负责"做什么"。
它推导出四条贯穿全文的具体规则:
- AI 可以全权做:采集、摘要、索引、检索、去重、聚类、草稿生成、调度计算。
- AI 只能提议,人来确认:写入长期资产(说明书/阶段记录/语录/原则)、错误根因归类、掌握度晋级。
- 读写不对称:写全部要人确认(低频、高价值、不可逆);读全自动(高频、低价值、可逆)。这是系统能长期跑下去的关键。
- 产出可重放:任何 AI 产出必须带指纹(模型 ID + 提示词哈希 + 管道版本),这样模型升级后你能看出"变了什么",而不是被静默改写历史。
一个反直觉但重要的推论:你不需要给 AI 装一个"更聪明的模型",你需要给它装一个"更好的上下文"和"更硬的门禁"。 系统的复利来自后者。
1. 总体架构
1.1 六层 + 两条正交轴
原方案里六层是串行流水线,实际应理解为"六层 × 两条正交轴"。两条轴分别是时间和置信度,很多设计冲突正是这两条轴没理清导致的。
┌──────────────────────────────────────────┐
时间轴(短 → 长) │ │
│ ① 收件层 Inbox (分钟 ~ 天) │
│ ② 编译层 Compile (小时 ~ 周) │
│ ③ 长期沉淀层 Vault (周 ~ 年) │
│ ④ 纠错进化层 Fault (月 ~ 年) │
│ ⑤ 学习能力层 Learn (月 ~ 年) │
│ ⑥ 主动输出层 Output (天 ~ 月) │
│ │
置信度轴(低 → 高) │ raw ──────────► wiki ──────► spec/stage │
│ (未验证) (已验证) (已确认) │
└──────────────────────────────────────────┘关键洞察:④⑤ 不是 ①③ 的下游,而是 ①③ 的反馈源。
①收件 ──► ②编译 ──► ③沉淀 ──┐
▲ │
│ ▼
⑤学习 ◄── ④纠错 ◄──────── 复盘引擎
│ ▲
└────────┘
错误归因 → 掌握度下调 → 复习调度 → 表现提升 → 教训验证第 ④ 层(错误)向下影响第 ⑤ 层(学习),第 ⑤ 层的复习表现又回流验证第 ④ 层的教训是否真的有效。这个闭环是"可复利"的机械来源——不是数据变多了,而是下一次犯同类错的概率下降了。
1.2 全景数据流
┌─────────────┐
│ 真实世界 │ 收藏/文件/语音/截图/对话
└──────┬──────┘
│ 采集器(浏览器插件 / 快捷指令 / 目录监视 / MCP)
▼
┌─────────────┐ 只增不改 原始素材永不被 AI 触碰
│ ① 收件层 │ raw/
└──────┬──────┘
│ 编译任务(夜间批处理,幂等)
▼
┌─────────────┐ 指纹化产物 可重放
│ ② 编译层 │ compile/
└──────┬──────┘
│ 人工审核闸门(Gate)
▼
┌─────────────┐ 唯一事实源 SSOT
│ ③ 长期沉淀层 │ vault/
│ 说明书/阶段/语录/wiki │
└──────┬──────┘
│
├──► ④ 纠错进化层(错误库 / 教训库 / 原则)◄── 复盘
│ │
│ ▼ 降级掌握度
│ ⑤ 学习能力层(掌握度 / DAG / 复习队列)
│ │
│ ▼ 复习表现
│ (回流验证教训有效性)
│
└──► ⑥ 主动输出层 ◄── 上下文装配器(Context Assembler)
网页总结 / 晨间播报 / 主动提问 ▲
│
┌───────────┴───────────┐
│ MCP 工具集 │
│ (日常 AI 对话入口) │
└───────────────────────┘1.3 上下文装配器:系统的心脏
原方案里"AI 每次对话都引用个人说明书"这句话需要精确化,否则要么 token 爆掉,要么说明书注水。
真实做法是分层装配 + token 预算:
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)强制字段:
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 抽样探测(不全探,太慢),对失效指针:
- 标
index_status: dead - 尝试内容寻址恢复:用
content_hash在各存储后端反查,找到则更新uri(这正是哈希的价值) - 找不到 → 在日报"资产健康"里提示,且不删除原指针(标记墓碑,保留历史)
不改的后果:一年后 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 评分去调度,会导致语义上已精通的内容仍被反复排进复习队列(因为公式记不住)。
决策:双轨模型。
轨 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 | 主题相邻,融合能加深理解 | 仅在生成学习计划时推荐 |
卡点检测改为症状匹配驱动,而非依赖图驱动:
当用户在学 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 次打断。你自己写了"避免通知轰炸",但这个设计恰恰在制造轰炸。三周后你会本能地忽略所有推送——包括真正重要的。
决策:提问队列 + 硬预算。
每日预算:
主动提问 ≤ 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, ≤ 90s)
→ TTS 引擎(edge-tts 本地生成 mp3 / 或直接送 HA TTS)
→ HA → xiaomi_miot.intelligent_speaker → 小爱音箱
反馈链路(避开语音的技术限制):
播报同时推送一条手机通知(PushDeer / ntfy / Bark)
「今天有 1 条错误预警、2 个待复习。有用/没用 →」
用户点按钮 → 写入 feedback 表 → 回写提问权重 + 播报素材评分
语音反馈作为可选增强:识别到「下一条/跳过」等固定口令时生效,
但不作为主回路内容筛选的"克制"是可量化的(原话"要克制、有温度",那就给数字):
每周播报总时长上限: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/月)。
决策:三层可见性分级。
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。
通道 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 条,然后这个库再也无法被使用。
决策:三层门槛。
候选提取(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 物理布局
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 契约
所有笔记共享四个基础字段,类型专属字段另加。
# ── 通用 ──
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
① 收件层
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 的 idtype: 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: [会议, 架构图]② 编译层产物
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 # 人工是否已确认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③ 长期沉淀层
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"]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: "..." # 现在的认知(可更新)type: quote
id: q_20261101_001
text: "..."
source_ref: daily_20261028
context: "复盘时谈到自己的判断方式"
emotion: reflective
strength: 78
applicable_to: [决策, 复盘]
my_reading: "..." # ★ 我的解读(AI 不写)
confirmed: true # 人工确认后才为 true④ 纠错进化层
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]type: principle
id: pri_P-03
text: "..."
derived_from: [err_20261012_002, err_20260903_001] # ≥2 条已确认错误才可提炼
checklist: # 可执行形式
- "..."
validated_count: 2 # 被验证有效的次数
status: active⑤ 学习能力层
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: ["并发竞态"]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⑥ 主动输出层
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: ["..."] # 美好时光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),自建检索:
索引构建(增量,随编译任务一起跑):
① 全文索引: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 装配算法
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_chat | spec_state, kp_due | "今天状态怎么样" |
decision | errors_matched, spec_state, stages | "这个方案你怎么看" |
review | daily(近7天), errors_matched, kp_due, quotes | "帮我复盘这周" |
learn | kp_due, kp_blocked, deps | "我该学什么" |
write | quotes, wiki, spec_core | "帮我写一段" |
lookup | notes, pointers | "我上次关于 X 的结论" |
plan | stages, kp_blocked, principles | "这季度怎么安排" |
4.4 主动预警:四条规则
这是需求里反复追问的能力,落成四条可执行规则:
规则 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,用于调参:
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 每日节奏
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 的症状匹配基础):
# 挂在 kp 的 assessments 字段
assessments:
- q: "解释 happens-before 的三条规则,并各举一个反例"
tags: ["并发竞态", "可见性"]
checks: ["并发竞态"]
- q: "..."
tags: ["内存屏障"]用户在 B 上答错时,用 B 的题目标签去匹配 A 的验证题标签(ADR-06 卡点检测)。
5.3 复习队列排序
纯 FSRS 序不够。加权:
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 依赖图与回补路径
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。
deps:
- from: kp_20260801_002 # MySQL 隔离级别
to: kp_20260901_007 # JVM 内存模型与并发竞态
kind: hard
note: "..."
source: manual | ai_suggested
confirmed: trueAI 可以建议依赖,但 hard 类型必须人工确认(confirmed: true)—— 否则一次错误推断就能把你卡死。
5.5 编译任务与回写规则
这是需求里明确问的"资料沉淀的触发频率和回写规则",完整回答如下。
触发频率:
实时(<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)幂等与缓存键:
cache_key = sha256(content_bytes + pipeline_version + model_id)
# 命中 → 跳过;未命中 → 编译并写产物(带指纹)回写冲突处理:同一 wiki 被两条编译任务同时更新 → 用文件锁 + 版本号检查,冲突时保留两份并标记 conflict: true,人工选择,绝不自动合并。
6. 主动输出层
6.1 交互式网页总结
频率:周报每周日 03:30 生成;月报每月 1 日 03:30 生成。
数据来源(全部来自 vault,可离线重算):
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。补充内容生成规则:
选材池(昨日复盘 / 历史上的今天 / 阶段进展 / 语录 / 错误预警 / 学习复习 / 美好时光)
↓ 打分
score = 0.35×信息密度 + 0.25×与当前阶段相关性 + 0.20×未播报过 + 0.20×情绪温度
↓ 取 top 1-3,累计 ≤ 90 秒
↓ TTS 文本生成(口语化,去掉 markdown 与符号)"历史上的今天":从往年同日的 daily 中检索,但必须过滤掉当时状态差的记录——早上播报"去年今天你项目延期很痛苦"是反人类的。只播报往年同日的美好时刻或突破。
反馈:手机推送一键(有用/没用),写入 broadcasts/feedback.yaml,影响下次选材的 score。
6.3 主动提问
见 ADR-07。生成规则:
候选问题来源:
① 捕获型:当天 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 双通道配置
{
"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/:
{
"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)
目标:验证"记录本身"能不能持续。零自动化。
做什么:
□ 建 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)
目标:把"手动搬运"变成"自动入箱 + 自动摘要"。
做什么:
□ 装核心插件: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)
目标:让系统开始产生复利——同类错误不再犯第二次。
做什么:
□ 建 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)
目标:把学习变成有调度的系统,把系统变成会主动说话的助手。
做什么:
□ 装 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+,可选)
做什么:
□ 媒体语义索引:RecallForge(本地多模态)或 Immich(相册向)
□ 指针健康全量探测 + 内容寻址恢复
□ 语音转写接入(会议 / 灵感)
□ 阶段记录自动里程碑检查
□ 若有余力:数字花园(Quartz)+ 公开版周报
验收:
✓ "帮我找一下去年那张架构图"能命中
✓ 语音碎片不再丢失阶段间的时间分配建议
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 选型原则
1. Markdown 是硬边界。 任何工具都不能成为唯一事实源
2. 能离线就离线。 云端服务是可选增强,不是依赖
3. 优先选有 MCP 的。 让 AI 用标准接口接入
4. 优先选可替换的。 工具随时会死,格式不会
5. 警惕"全家桶"营销。 一站式方案 = 一站式锁定9.2 选型表
| 环节 | ★ 首选 | 备选 | 关键说明 |
|---|---|---|---|
| 底座 | Obsidian(本地 Markdown 仓库) | Logseq / 思源 | Obsidian 生态最成熟,MCP 插件最多。不是任何云笔记(本地优先是前提) |
| 同步 | Obsidian Git(私有仓库) | Syncthing / iCloud | Git 顺带给你版本历史——这是"说明书可回滚"的基础。多设备同时编辑会冲突,Obsidian Git 在移动端不稳定 |
| 模板 | Templater | 核心 Templates | Templater 能跑 JS、可自动归档到指定目录,是自动化入口 |
| 查询/看板 | Dataview + 核心 Bases | 手工 DataviewJS | Bases 是核心插件,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 或 LanceDB | Chroma / Qdrant | 本地优先选前两者。RecallForge 本身就是 LanceDB + Qwen3-VL 的路线 |
| 嵌入模型 | Qwen3-Embedding(本地) | bge-m3 / OpenAI Embedding | 中文语料优先 Qwen 或 bge 系列;RecallForge 用 Qwen3-VL-Embedding-2B |
| 重排模型 | bge-reranker-v2-m3(本地) | cross-encoder | RecallForge 数据显示重排带来 R@1 +20.7%,是最大的单点提升 |
| MCP(vault) | MCPVault(filesystem,7×24) | mcp-obsidian / obsidian-mcp-server(需 Obsidian 常驻) | 见 ADR-10,这是最容易踩的坑 |
| MCP(媒体) | RecallForge | Immich API | 直接就是 MCP server |
| 播报 | Home Assistant + xiaomi_miot | HA + DLNA | xiaomi_miot.intelligent_speaker 直连 TTS 最稳;DLNA 需米家实验室开启且音箱要能反连你 |
| TTS | edge-tts(免费高质量) | HA 内置 TTS / Piper(离线) | 中文自然度高 |
| 推送 | PushDeer / ntfy / Bark | 企业微信机器人 | Bark iOS 体验最好,ntfy 自托管最自由 |
| 报告托管 | Cloudflare Pages + Basic Auth | Obsidian Publish / Quartz | 见 ADR-09。Quartz v4 需 Node 22+ |
| 静态站 | Quartz v4 | Jekyll/Hugo | Quartz 原生支持 wikilink / 双链 / 图谱 / Callout / LaTeX |
| 编排 | Windows 任务计划 / cron | n8n | 编译、复习计算这些用 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 | 本案选择 | 理由 |
|---|---|---|---|---|
| 底座 | Obsidian | Notion | Obsidian | 本地优先 + Markdown + git 友好 |
| MCP 入口 | Obsidian REST | 文件系统直读 | 双通道 | 后台任务不能依赖 GUI 常驻 |
| 语义检索 | 纯向量 | 混合+重排 | 混合+重排 | 重排带来 R@1 +20.7%,性价比最高的一步 |
| 媒体索引 | Immich | RecallForge | RecallForge 为主 | 它是检索引擎且出 MCP;Immich 强在相册管理,可并存 |
| 复习调度 | Obsidian 插件 | py-fsrs 自建 | py-fsrs 自建 | 需要双轨掌握度 + 三因子排序,插件表达不了 |
| 报告托管 | Obsidian Publish | CF Pages + Auth | CF 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 消灭了偶然复杂度,但软件复杂度还在;程序员要从代码生产者走向系统价值设计者。
这个个人上下文系统,恰好是这个命题的一个具体实例:
偶然复杂度(AI 消灭的部分) 本质复杂度(人必须守住的)
───────────────────────────── ─────────────────────────────
分类 / 命名 / 摘要 / 去重 什么值得沉淀
双链 / 索引 / 检索 / 生成 什么算真教训(运气 vs 失误)
调度 / 提醒 / 编译 / 播报 阶段边界在哪
优先级计算 / 排序 / 统计 哪些门禁不能拆AI 让"维护一份高质量的个人上下文"从一件消耗意志力的事,变成了一件有确定性的事。 这是"代码生产者 → 系统价值设计者"的个人版本:你的产出不再是每周写了多少行,而是这套系统是否在持续降低你犯同类错的概率、持续提高你复用已有资产的能力。
而复利的来源不是数据量,是这个闭环:
记录 → 归因 → 提炼原则 → 提前预警 → 成功阻断 → 验证有效 → 原则升级 → 更多预警每转一圈,下一圈的起点就高一点。这正是软件工程里唯一真正复利的东西——不是代码行数,是系统本身的可演进性。
至于"没有银弹"——对,这个系统没有银弹。它有 12 个门禁、30 个 schema、5 个自动化阶段。但这些门禁不是复杂度,它们是你和 AI 之间那份被明确定义过的契约。 没有契约的自动化才叫没有银弹。
附录 A · 需求对照索引
| 原始需求 | 落在哪 | 关键决策 |
|---|---|---|
| 六层各放什么 | §3.1 / §3.3 | 目录 + schema |
| 说明书如何生成/更新/调用 | §3.3 / §4.3 / §7.1 | ADR-03 三层拆分 + 常驻注入 |
| 阶段记录如何生成/更新/调用 | §3.3 / §4.3 | belief_then 不回改,支持回溯 |
| 经典语录如何生成/更新/调用 | §3.3 / §6.1 | ADR-11 强度分门槛 |
| 错误与教训库如何生成/更新/调用 | §3.3 / §4.4 / §7.1 | ADR-04 人工确认根因 |
| 待学习清单与掌握度 | §3.3 / §5.2 / §5.3 | ADR-05 双轨模型 |
| 资料沉淀的触发频率 | §5.5 | 实时/15min/日/周/月 五级 |
| 资料沉淀的回写规则 | §5.5 | 严格单向 + 冲突人工裁决 |
| 每日九宫格复盘 | §3.3 / §5.1 | 9 维度 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.2 | L0-L4 + 证据必填 + L3 要真实任务 |
| 遗忘复习调度落地 | §5.3 / §9.2 | py-fsrs + 双轨 + 三因子排序 |
| 交互式网页总结的频率 | §6.1 | 周日 03:30 / 月 1 日 03:30 |
| 交互式网页总结的数据来源 | §6.1 | 全部来自 vault,可离线重算 |
| 交互式网页总结的托管方式 | §6.1 / ADR-09 | CF Pages + Basic Auth,默认私有 |
| 晨播内容筛选 | §6.2 / ADR-08 | 打分 + 配额硬上限 + 禁止项 |
| TTS 推送链路 | §6.2 / ADR-08 | HA + xiaomi_miot,反馈走手机 |
| 反馈闭环 | §4.5 / §6.2 | 反馈 → 权重调参 |
| MCP 如何同时调用各层 | §7.1 | 20 个粗粒度领域工具 |
| 主动预警历史错误 | §4.4 规则 1 | 相似度 > 0.72,confirmed 才预警 |
| 提示前置知识缺失 | §4.4 规则 2 / §5.4 | hard 依赖 + 症状匹配 |
| 推荐下一步学习/复习 | §4.4 规则 3 / §5.3 / §7.1 | 三因子排序队列 |
| 分阶段起步路径 | §8 | 5 阶段,各带验收标准 |
| 关键工具选型建议 | §9 | 20 个环节 + 6 个关键取舍 |
附录 B · 分享版设计(用于技术分享场合)
B.1 一个可讲的叙事主线
这套系统本身是个很好的分享素材,因为它恰好是"程序员从代码生产者走向系统价值设计者"的最小可运行样本。建议的讲法:
开场(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 分钟版)
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 可复用的三张图(分享时用)
- 六层 + 反馈闭环(本文档开头已给)——讲整体结构
- 双轨模型对比图——讲掌握度 vs 记忆保持
- 门禁矩阵——讲人机分工(§3.4 那张表的可视化)