一、AI 时代：仅靠 Idea 已难以满足代码迭代需求
先分享几个核心判断。在使用 Idea 搭配 AI 插件编写代码时，常遇到以下挑战：
- 以问答形式逐句沟通，生成代码片段后需要人工审查结果
- 与 AI 的对话记录不易检索，信息散落
- 多次交流后上下文累积，AI 注意力下降；重新开启会话后记忆清零，需从头教它写代码
- 一个需求可能涉及多个微服务，代码变更分散在不同代码库中
- Idea 仅关注代码，缺乏数据库结构、中间件等元信息
因此，在 AI 时代，仅靠 Idea 已无法支撑高效的代码迭代流程。
二、Obsidian 是什么
obsidian.md/
Obsidian 是一款本地优先、基于纯 Markdown 文件的知识管理工具，其核心特点十分突出：
- 数据本地化：所有笔记均为磁盘上的
.md文件，不绑定任何云服务，离线可用，用户完全掌控数据。 - 双向链接：通过
[[note-name]]将碎片信息串联成网络，任意笔记均可反向查询“谁引用了我”。 - 图谱视图：以可视化方式展示笔记之间的引用关系，一目了然知识网络的形态。
- 插件生态：开放插件市场，社区已将其扩展为任务管理、日历、Data view 查询、AI 助手等多种形态。
- 纯文本 = AI 友好：文件均为 UTF-8 Markdown，对 AI 而言是可读、可写、可 diff 的一等公民，无需像 Idea 那样依赖专用插件桥接。
回到前面列出的 Idea + AI 痛点，Obsidian 恰好能够逐一对症解决。
| Idea + AI 的痛点 | Obsidian 的解决方案 |
|---|---|
| 问答式碎片，结果难以审查 | 笔记是持久化文档，AI 每次修改都留下痕迹，便于回溯 |
| 沟通记录难以搜索 | 全文搜索 + 双向链接 + 标签，历史对话变成可检索的知识资产 |
| 上下文累积，重开会话记忆归零 | 通过笔记显式记录项目上下文，新会话让 AI 先读取笔记恢复记忆 |
| 一个需求涉及多个微服务 | 一个 Vault 可同时容纳 A、B、C 服务的笔记，链接跨服务打通 |
| Idea 只有代码，缺乏数据库/中间件视角 | Vault 中可并列存放代码分析、数据库 Schema、Kafka Topic、部署拓扑等 |
简而言之，Obsidian 并非取代 Idea 的编辑器，而是取代其认知承载层——代码继续在 Idea 中编写，但围绕代码的所有上下文（设计决策、AI 对话历史、数据库结构、跨服务调用图）都迁移到 Obsidian 中，实现长期沉淀。
三、环境准备
- 下载 Obsidian 并启用插件
- 安装 Claudian 插件：github.com/YishenTu/cl…
四、理论基础
gist.github.com/karpathy/44…
Karpathy 在这篇 Gist 中给出了本文所有做法的理论出处，一句话点破核心：你写的每份笔记都不是“文档”，而是 LLM 正在维护的一份代码库——只不过存储的是关于世界的结构化知识，而非可执行指令。
Open: Pasted image 20260715234540.png
attachments/使用 Obsidian 作为 IDE/abb7ed0b8ab97cb4b1f0a13519e1e09a_MD5.jpg
4.1 三层架构
Karpathy 将整个系统分为三层，恰好对应 Vault 中的三类文件：
| 层级 | 定义 | 对应内容 |
|---|---|---|
| Raw sources | 不可变的原始资料，LLM 只读不修改 | 粘贴进来的会议纪要、PDF、代码 Diff、剪藏文章 |
| The wiki | LLM 生成/维护的 Markdown 页面 | 你的分析笔记、决策记录、概念页 |
| The schema | 让 LLM 成为“有纪律的维护者”的配置 | Vault 根目录下的 CLAUDE.md |
关键点在于：CLAUDE.md 不仅仅是“避免重复告知 AI 项目背景”的便利工具，它本身就是 schema——决定了 LLM 是随手回答的聊天机器人，还是纪律严明的 Wiki 维护者。
4.2 三个操作
LLM 需要在这份 Wiki 上执行三项任务：
- Ingest —— 摄入新的原始资料，更新多份 Wiki 页面，维护交叉引用
- Query —— 搜索 Wiki 综合答案，优质答案回写成新页面
- Lint —— 检查矛盾、过时声明、孤儿页面、缺失链接
前两项大多数用户已在实践，Lint 是新增能力——为知识库运行健康检查，与为代码运行 Lint 是同一道理。
4.3 为什么现在才可行
过去人们普遍放弃维护内部 Wiki，因为维护成本超过收益——没人有精力持续更新交叉引用、消除矛盾、补充链接。
LLM 恰好弥补了这一瓶颈：人类负责筛选原始资料、指定分析方向、提出好问题，LLM 承担所有记账工作——一次 Ingest 可触及数十份文件，成本几乎为零。
并非 Obsidian 变强了，而是 Wiki 的维护成本从人身上转移到了 LLM 身上。
五、如何使用：四个关键动作
5.1 一个项目一个 Vault + CLAUDE.md
不要用一个 Vault 装所有内容。请为每个项目创建一个子文件夹，在 Vault 根目录放置 CLAUDE.md——将技术栈、目录结构、提交规范、常见陷阱以及每次新对话都需要重复告知 AI 的信息一次性写清楚。Claudian 每次启动时自动读取该文件，重开会话时无需从零开始。
5.2 需求进入时的典型流程
对比过去（打开 AI 侧边栏 → 问一句 → 复制代码 → 关闭 → 记忆归零），现在的路径如下：
- 创建需求笔记 —— 记录背景、目标、约束
- 让 AI 读取上下文 —— 使用
[[]]引用架构、数据库 Schema、历史需求笔记，Claudian 自动读取 - 对话式分析 —— 提出方案，追问，决策，关键决策让 AI 写回笔记
- 在 Obsidian 中直接让 AI 修改代码 —— 笔记中的方案作为提示
- 回写决策 —— 代码完成后，将“为什么这样改 / 踩了什么坑 / 提交哈希”记入笔记
- 下一个需求 —— 旧笔记成为新对话的上下文
心态需要转变：AI 的输出不再是“用完即弃的问答”，而是沉淀为文档。
5.3 日常高频操作
@引用文件 —— 直接将某笔记塞入对话上下文，跨服务对齐特别有效- 将代码粘贴到笔记中让 AI 修改 —— 结果留在笔记内，便于回看
- 决策记录 (ADR) —— 每个架构决策创建一个笔记，使用
[[]]串联，半年后无需猜测“当时为什么这么设计” - Daily Note 记录排查过程 —— 实时思路直接进入当天日记，AI 基于流水推进
- 图谱视图 —— 一眼看出哪些模块笔记密集（核心区域）、哪些孤立（遗漏区域）
5.4 与 Idea 的分工
| 场景 | Idea | Obsidian + Claudian |
|---|---|---|
| 写代码、调试、运行测试 | ✅ | |
| 断点调试、性能分析 | ✅ | |
| 需求分析、方案设计 | ✅ | |
| 架构文档、数据库 Schema | ✅ | |
| 与 AI 长对话、决策落地 | ✅ | |
| 跨服务上下文串联 | ✅ | |
| 团队共享知识、复盘 | ✅ |
一句话总结：Idea 负责“码”，Obsidian 负责“脑”。
六、实战案例：一次为期两周的跨阶段重构
在本地完成了一个项目 P1~P6 六个阶段主体 + 4 轮架构重构，涉及 15 个技术决策（D1-D15），持续两周。
如果仅在 Idea 中操作，几乎不可能完成——每次新会话记忆归零，反复解释项目背景就要耗费一半时间。Obsidian 在此过程中发挥了五点作用：
- 一份主计划笔记贯穿始终 —— 所有对话从该笔记出发，笔记本身也被 AI 补充和修订
- 15 个决策全部记录 —— 每个决策都记下“背景 / 备选方案 / 选择 / 理由”，不留在对话中
- 跨会话无缝续接 —— 第七天开启新会话，只需一句“读一下这份笔记继续”即可
- 提交哈希回写笔记 —— 13 个提交全部登记，笔记直接变成变更日志
- 最终沉淀到
CLAUDE.md—— 下一轮改造开始时，新会话直接了解当前状态
反之，如果仅在 Idea 中操作？15 个决策散落在几十次对话中无法检索、无法复现；每次新会话浪费 20 分钟重建上下文；提交之间的“设计意图”三个月后自己都看不懂。
结论明确：改造规模越大、跨度越长，Obsidian + Claudian 的杠杆效应越明显。这不是可有可无的辅助，而是让“AI 参与长周期复杂改造”变得可行的基础设施。
七、实操：为 Vault 运行一次 Lint
理论讲完，回到最实用的操作：定期让 AI 为你自己的 Vault 运行健康检查。这是将 Wiki 当作代码库进行代码审查。
推荐两类基础 Lint，只需一句 Prompt 即可运行。建议在自己的 Vault 上实际跑一遍才有意义，这里提供模板和结论解读。
7.1 死链扫描
Prompt（直接扔给 Claudian）：
运行后的报告通常可分成六类：
| 类别 | 典型示例 | 处理方式 |
|---|---|---|
| A. Daily 前后日跳转 | [[2026-05-14_周四]] |
模板机制造成的常态，可忽略；或让 Templater 仅在文件存在时渲染 |
| B. 模板占位符误识别 | [[<% after_date %>]] |
假死链，忽略 |
| C. 剪藏工具事故 | 网页中带 [[]] 的评论者昵称、URL 被误转为 Wikilink |
批量搜索替换清理 |
| D. 想链但未创建 | 某个概念被反复引用，却始终没有对应的笔记 | 明确行动——被引用次数越多，越应优先补写 |
| E. 拼写 / 格式错误 | 结尾多反斜杠、大小写不匹配 | 像修改 Bug 一样直接修正 |
| F. MOC 目录缺失 | 目录名被链接但无同名索引页 | 创建索引页 |
Lint 的核心价值在于 D 类——高频死链意味着你反复觉得“这里应该有一篇笔记”，但一直未写。这是知识网络为你提供的具体行动清单。不跑这一遍，你根本不知道自己欠了多少“债”。
7.2 孤儿扫描
Prompt：
运行后通常会看到三种模式：
- 成规模的孤儿集群 —— 某个目录（某本书的章节笔记、某个专题的系列文章）整批全部是孤儿 → 缺少一个 MOC 索引将系列串联起来。这不仅仅是“补一条链接”的问题，而是知识组织结构存在漏洞。这种结构性问题只有通过 Lint 才能发现，单独打开某篇笔记时永远看不出来。
- 孤儿入口文件 —— 文件名类似入口（
xx 总览、xx 看板）但没有任何入链 → 入口已创建但无人访问，需要在其他笔记中显式引用它。 - 空 / 单行笔记 —— 未命名、只写了标题就无下文 → 直接删除。
7.3 定期运行 Lint 的收益
一次 Lint 能带来四类具体产出：
- 明确的下一步行动：高频死链 = 该创建的核心笔记清单
- 结构性问题的暴露：成群的孤儿集群 = 缺少的 MOC 索引
- 数据清洁：剪藏事故、拼写错误、空笔记
- 入口文件的自我审计：名字是入口但无入链 = 走不通的入口
建议节奏：每月一次，或每次大批量向 Vault 导入资料后运行一次。
不进行 Lint 的 Vault，两三年后基本沦为“大坟场”——链接密度看似很高，但绝大多数是死链和孤岛。反之，坚持做 Lint，Vault 就能始终保持“活跃”状态——每一条链接都可到达，每一个节点都被引用。这就是 Karpathy 所说的 Lint。
八、小结
- Idea 是代码编辑器，依然好用，没有改变
- Obsidian 是认知承载层，补全了 Idea 缺失的另一半——设计意图、AI 对话历史、跨服务上下文、决策脉络
- Claudian 是粘合剂，让 AI 直接读写你的知识网络，不再是“一次性问答机”
CLAUDE.md是 Schema，让 LLM 从聊天机器人升级为纪律性维护者- Lint 操作是自我维护的核心动作，确保 Vault 长期不腐烂
组合起来，你才真正拥有一个“AI 时代的 IDE”——不是将 AI 塞进 Idea 侧边栏的拼贴，而是围绕知识组织重新设计的开发工作流。
