AI Coding 最大的短板,可能藏在你的笔记里

最近我一直在想一个问题：

AI coding 越来越强，但它每次开始工作时，还是像刚加入项目的新人。

它能读代码，能改代码，也能解释一段逻辑。

但它不知道我们之前为什么这么设计，不知道某个方案为什么被放弃，也不知道那些散落在会议纪要、复盘、灵感笔记里的上下文。

而这些东西，刚好都在我的 Obsidian 里。

所以我试着把 Obsidian 接进 Codex。

让 AI 在写代码前，能先翻一翻我的知识库。

01 AI coding 最大的问题之一，是它没有来源

我们平时和 AI 一起写代码时，经常会遇到一种微妙的断裂感。

你让它改一个模块，它能很快读懂当前文件。

你让它修一个 bug，它也能顺着调用链往下查。

但一旦问题涉及到“为什么当初这么做”，事情就变得麻烦了。

比如：

• 这个接口为什么没有继续抽象？
• 这个组件为什么没有复用已有方案？
• 这个目录为什么看起来有些别扭，但大家一直没动？
• 某个设计约束是技术原因，还是历史遗留？
• 上次评审时到底否掉了哪几个方向？

这些信息通常不在代码里。

它们在需求文档、会议纪要、个人笔记、复盘、聊天记录、临时方案里。

对于人来说，这些是“工作现场”的一部分。

但对于 AI 来说，如果你没有显式告诉它，它就像从没发生过一样。

所以很多时候，我们不是在让 AI coding。

而是在反复给 AI 补课。

左边是每次重新解释背景，右边是让笔记、决策和代码重新连起来。

02 我的很多上下文，其实早就写在 Obsidian 里

我一直用 Obsidian 记录一些不太适合放进代码仓库里的东西。

比如一次重构前的判断。

一次线上问题的复盘。

一个产品需求背后的讨论。

一个技术方案被放弃的原因。

或者某个灵光一闪、但还没到实现阶段的想法。

这些内容不一定整洁，也不一定都能形成正式文档。

但它们很有价值。

因为真实的工程判断，往往不是只靠代码就能还原的。

代码记录了“最后怎么做”。

笔记里才经常藏着“当时为什么这样做”。

以前这些笔记主要是给我自己看的。

需要的时候，我手动打开 Obsidian，搜索关键词，找到相关上下文，再复制一段给 AI。

这个动作不复杂。

但会打断心流。

更重要的是，它会让 AI 永远停留在“等我喂上下文”的状态。

它不会主动去查，也不知道哪些笔记可能和当前问题有关。

于是我开始想：

能不能让 Codex 直接访问 Obsidian？

03 MCP 做的事很朴素：把门打开

MCP 可以理解成 AI 应用和外部工具之间的一种连接方式。

这次我用的是 obsidian-mcp-server。

它本身不直接扫描磁盘里的 Markdown 文件，而是通过 Obsidian 的 Local REST API 插件去访问当前打开的 vault。

整体链路大概是这样：

Codex  ↓Obsidian MCP Server  ↓Obsidian Local REST API  ↓Obsidian Vault

也就是说，Codex 不再只能看当前代码仓库。

它可以通过 MCP 去读 Obsidian 里的笔记，搜索标题、内容、标签，也可以在需要的时候写入新的笔记。

这件事听起来有点技术感。

但真正的变化其实很朴素：

以前是我先想起“某个背景可能在笔记里”，然后手动找出来给 AI。

现在可以变成我对 AI 说：

先去 Obsidian 里查一下这个项目之前的设计记录。

这一步差别不大。

但工作流的手感完全不同。

04 安装过程不难，但有两个地方容易绕

我这次的安装路径是：

1. 在 Obsidian 中安装 Local REST API 插件。
2. 复制插件生成的 API key。
3. 在本地安装 obsidian-mcp-server。
4. 在 Codex 的 config.toml 里配置 MCP server。
5. 重启 Codex。

Codex 里的配置大概长这样：

[mcp_servers.obsidian]command = "/path/to/node_modules/.bin/obsidian-mcp-server"args = []startup_timeout_sec = 120[mcp_servers.obsidian.env]MCP_TRANSPORT_TYPE = "stdio"OBSIDIAN_API_KEY = "your-local-rest-api-key"OBSIDIAN_BASE_URL = "https://127.0.0.1:27124"OBSIDIAN_VERIFY_SSL = "false"

这里有两个点值得单独说一下。

第一个是 API key。

这个 key 本质上就是 Obsidian vault 的本地访问凭证，不要写进公开仓库，也不要直接贴到公开文章里。

如果不小心暴露了，最好在插件里重新生成一个。

第二个是多个 .obsidian 目录。

.obsidian 不是笔记目录，而是 vault 的配置目录。

真正的 vault 根目录，是 .obsidian 的父目录。

比如：

/Users/me/Notes/Work/.obsidian

这个 vault 实际上是：

/Users/me/Notes/Work

如果你电脑上有很多 .obsidian，不要让 AI 直接扫全盘。

那里面可能有旧 vault、备份 vault、同步副本，也可能只是一些插件配置。

.obsidian 是配置目录；真正要理解的是它的父目录，也就是 vault 本身。

更稳的方式是：

先在 Obsidian 里打开你要用的 vault。

确认这个 vault 启用了 Local REST API。

然后让 Codex 通过 MCP 访问它。

MCP 连接的是 Obsidian 当前暴露出来的那个 vault，而不是磁盘上所有看起来像 vault 的目录。

05 我现在会怎么用它

接通以后，我最直观的感受不是“AI 变聪明了”。

而是它不再那么孤立。

以前我让 AI 帮我写方案，它只能基于我当前给出的材料组织语言。

现在我会先让它去 Obsidian 里查：

• 这个项目之前有没有相关讨论？
• 某个技术选型之前有没有比较过？
• 最近几次复盘里反复出现的问题是什么？
• 有没有和当前需求相似的历史案例？

如果我要改代码，也可以先让它读一下相关笔记，再进入仓库。

比如我会这样问：

先从 Obsidian 里查一下这个项目过去关于权限模型的设计记录，再结合当前代码，判断这次改动应该落在哪一层。

这个动作很像让一个同事在动手前先翻一下历史资料。

它不保证每次都完美。

但会减少很多“凭空开始”的感觉。

还有一个我挺喜欢的用法：

把 coding 过程再沉淀回 Obsidian。

比如一次重构结束后，让 AI 帮我整理：

• 这次改动解决了什么问题？
• 保留了哪些约束？
• 哪些地方暂时没动？
• 后面的人接手时应该注意什么？

这些内容如果直接放进代码注释，可能太重。

但放进 Obsidian，刚好可以成为下一次工作的上下文。

06 权限最好从一开始就收紧

接入个人知识库这件事，方便和风险是同时出现的。

我不建议一上来就给 AI 完整读写权限。

尤其是 vault 很大、内容很杂，或者里面有私人信息时，更应该先缩小范围。

比较稳的做法是先设成只读：

OBSIDIAN_READ_ONLY = "true"

或者只开放几个明确目录：

OBSIDIAN_READ_PATHS = "Notes/,Projects/,Inbox/"

如果需要写入，也可以只允许写入 inbox：

OBSIDIAN_WRITE_PATHS = "Inbox/"

这样 AI 可以帮你整理和归档，但不会在整个 vault 里随意改动。

我自己的习惯是：

先读，后写。

先小范围，后扩大。

07 真正改变的是上下文的流动方式

这件事对我最大的启发，不在于 Obsidian，也不在于 MCP。

而是我开始重新看待 AI coding 的上下文问题。

过去我们总觉得上下文是“当前对话里塞了多少 token”。

但在真实工作里，上下文远不止这些。

它包括：

• 过去的设计判断
• 项目的演化历史
• 需求背后的取舍
• 团队形成的默契
• 一些没有写进代码的经验
• 那些当时看起来零散、后来却不断回响的笔记

这些东西原本就存在。

只是没有和 AI 的工作现场连起来。

把 Obsidian 接进 Codex 后，我感觉像是在给 AI 多开了一扇窗。

它仍然需要判断，仍然会犯错，仍然需要人来把关。

但至少它有机会靠近我已经留下的思考痕迹。

这比“让 AI 替我记住一切”更实际。

我真正想要的，也不是一个无所不知的助手。

而是当我开始做一件事时，它能和我一起回到现场：

看看代码，也看看当初写下这些代码时，我们到底在想什么。