用 Obsidian Wiki 接续编程助手上下文

AI 编程会话结束后，最容易丢掉的不是代码，而是「为什么这样改」「哪条路已经失败」「还有什么没确认」。作者把这些上下文集中到一个由 Agent 维护的 Obsidian wiki，让不同项目、不同会话接着读，减少反复交代背景。

从 2026-08-20 到 2026-11-08，这套系统积累了 166 个 wiki 页面、140 条日志。它值得看的地方，是怎样限制保存范围、区分事实与推测，以及避免多个会话同时写坏记录。

保存上下文，为什么不能只堆聊天记录

作者采用了 Andrej Karpathy 的 LLM Wiki 模式：知识以 Markdown 页面保存，Agent 负责整理和持续更新，新信息进来后会修改已有页面，并标出冲突。

原文将它与 RAG（检索增强生成）比较：RAG 每次提问时检索相关文档片段，wiki 则提前把信息整理成可继续维护的知识。大白话理解，前者偏向「临时找材料」，后者偏向「维护一份工作手册」。

目录分成三层，各有用途：

• raw/ 保存文章、外部文档和对话日志，由用户添加，Agent 只读。
• wiki/ 保存提炼后的决策、失败记录和项目上下文，由 Agent 更新。
• conversations/ 保存尚未定论的会话交接材料。

聊天记录是材料，能指导下一次工作的结论才进入正式知识页。

作者设置了五项保存判断：信息是否会复用，其他会话或同事是否需要接手，是否需要追溯决策理由及决策人，是否属于不该重试的失败，是否是共同遵守的规则。五项都不满足，就不保存。

一次性回答、中间思考、未经用户批准的方案和缺少依据的猜测，不进入正式 wiki。可能有取证价值的内容，最多暂存到 conversations/。这样做的理由很实际：页面越多，下次会话越难辨认重点。

新会话怎样找到它，谁决定何时写入

用户先把 wiki 文件夹作为 Obsidian vault 打开，再在目录内运行一次安装脚本：

./scripts/install-global.sh

注意这条命令要在 wiki 文件夹内执行；原文没有提供脚本内容，不能只凭这行命令复现完整系统。

脚本会向 Claude Code 全局设置链接一份简短的路由说明。它只负责告诉 Agent：听到指定短语，先读取 wiki 目录中的 CLAUDE.md。实际规则集中放在这一个文件里，因此用户可以从任意项目目录调用 wiki。换电脑时，需要克隆 wiki 仓库并重新运行脚本。

说出「check the wiki」后，Agent 读取索引和最近日志，简要整理关键上下文与未完成工作。如果同时附带问题，例如支付模块此前如何决策，就直接围绕问题查找。

原文说共有五个命令，实际触发短语使用韩语，但没有列出完整命令表，也没有交代中文触发方式。

读取和保存是分开的。Agent 不会自行写入 wiki，用户必须明确要求保存。 每次保存后，它会报告新增或修改了什么、哪些内容没存及原因，以及下次会话应优先阅读哪些页面。由于 wiki 是 Git 仓库，每次保存还会提交并推送，结果一并报告。

共享记忆最怕把猜测写成事实

作者给知识页记录了证据状态，区分实际运行确认、人或文档提供的信息，以及 Agent 推断。只有推断支撑的页面，不能标成已定论。

2026-10-25，一次新会话检查了多个会话留下的真机测试工具记录。其中，一项功能失效的原因原先只是猜测，后来通过 issue 评论核实并修正；另一条无法完整验证的记录，则降为「仅有间接证据」。

这说明知识库需要保留不确定性。否则，上一轮的猜测很容易成为下一轮推理的前提。

多个项目同时保存时，还有文件竞争。作者按主题拆分页面，并在修改所有保存操作都会触碰的 index.md 和 log.md 前加锁。原文给出的实测是：不加锁时，120 条记录丢了 77 条；加锁后没有丢失。锁的做法来自先实现同类思路的 oh-my-claudecode wiki skill。

提交也要隔离。Agent 只提交本任务修改的文件，其他会话遗留的改动另行提交或保留不动。Agent 提交使用 Claude (agent) 作者身份，可通过下面的命令筛选：

git log --author="Claude" --oneline   # what the agent recorded

注意 --author="Claude" 筛选的是作者字段，它方便追踪 Agent 记录，不能证明记录内容正确。

维护也没有自动完成。2026-11-08 的 lint 检查发现 23 项问题：21 个大页面可能整段复制了来源，另有 2 个页面没有入链。大页面究竟是照搬原文，还是正常增长后需要拆分，仍由人判断；lint 也只有用户要求才会运行。

我的判断

我认可这套方案对「写什么」的克制，以及把推断与验证分开的做法。程序员真正需要继承的是决策依据、失败条件和待办状态，这些内容比完整聊天记录更适合长期维护。

但它的收益仍主要是作者经验。166 个页面和 140 条日志说明系统持续使用过，不能证明它比项目内的 CLAUDE.md、决策记录或 RAG 更准确、更省时间。原文也没有提供检索命中率或交接耗时的对照数据。实际的 RAG 系统同样可以维护摘要、证据与元数据，两者并非只能二选一。

并发测试的数据值得重视，但原文没有说明进程数量、测试环境、锁的范围和故障恢复方式。因此，「加锁后零丢失」只能视为该次测试结果，不能直接推广到多台电脑同时推送 Git 仓库的场景。

这套方案还有一个使用前提：用户愿意记得保存、请求 lint，并审核含糊结论。缺少这些维护动作，集中知识库也会逐渐积累过期信息。

能拿来做什么

• 在前端或 Node 项目结束一次重要排障后，要求 Agent 保存失败条件、已经验证的解决办法和仍待确认的问题，避免下次重复尝试同一条路。
• 先整理项目内的决策记录与 CLAUDE.md；当多个项目确实需要共享知识时，再采用全局路由和集中 wiki，减少重复维护规则。
• 给长期保存的结论附上证据状态，明确区分运行结果、文档陈述和推测；新会话读取旧结论时，也要核对其适用条件。
• 多会话共用仓库时，检查索引与日志的写入锁、提交文件范围，并定期请求 lint，人工处理大页面和没有入链的页面。