我一直想要一个更顺手的知识整理工作流。
不是"先和 AI 聊完，再手动复制粘贴进笔记"，而是让对话、资料整理、项目排障和知识沉淀直接进入 Obsidian，变成可以长期复用的资产。
claude-obsidian 就是在这个目标下做出来的一个 Claude Code skill。它做的事情很直接：把 Claude Code 里的自然语言输入，转换成结构化的 Obsidian 笔记，并自动写入本地 vault 的合适位置。
这个项目不是一个泛化的 Markdown 生成器。它的重点不是"帮你写一篇像样的笔记"，而是帮助你把零散输入持续收敛成真正可用的知识。
为什么会做这个项目
多数 AI 工作流的问题，不是生成能力不够，而是产出无法沉淀。
一个很常见的流程是这样的：
-
聊天时冒出一个想法，先放着
-
读到一篇文章，觉得有用，但懒得整理
-
做项目时排查了半天，结论散落在终端、聊天记录和临时文件里
-
几天后再回头，信息都还在，但已经很难重新组织
问题不在于"有没有内容"，而在于"内容能不能在产生的时候进入知识系统"。
claude-obsidian 的出发点就是这个。它试图打通 Claude Code 和 Obsidian，让输入在产生的当下就带着结构落地，而不是事后再手工搬运。
它是怎么工作的
这个项目的结构比较克制。
-
SKILL.md负责识别用户意图和抽取字段 -
obsidian_writer.py负责模板渲染和文件写入 -
最终输出直接进入本地 Obsidian vault
它目前支持几类核心操作：
-
fleeting记录闪念，直接追加到当天的 daily note -
capture抓取网页或本地文件，整理成高密度literature笔记 -
log把一段 Claude Code 对话整理成结构化笔记 -
write显式创建literature、concept、topic、project -
organize搜索已有笔记并合并成topic或MOC -
query在已有知识库上做带引用的问答 -
lint检查断链、孤立笔记、Inbox 积压等问题 -
index重建全局索引页 -
init初始化 vault 目录结构
也就是说，它不是单点功能，而是一条从输入、整理、组织到检索的完整链路。
这个项目最重要的设计，不是模板，而是知识模型
claude-obsidian 里最关键的部分，其实不是具体命令，而是笔记类型的划分。
项目围绕四类核心笔记展开：
-
fleeting用来低成本捕捉临时想法 -
literature用来保存外部材料，例如文章、论文、博客、文档 -
project用来记录实际工作里的问题、排查过程和解决方案 -
topic用来把literature和project中的内容继续整合成主题理解页
这四类笔记里，真正重要的是 topic。
因为 topic 不是原始输入，而是已经形成的理解。它应该承载的是你当前对某个问题的认知：核心问题是什么，当前结论是什么，关键资料有哪些，还没解决的问题有哪些。
这也是我为什么说，这个项目的重点不是"写一篇笔记"，而是"把输入逐步收敛成可复用知识"。
如果只有 literature 和 project，你只是积累材料。 有了 topic，你才开始积累理解。
它和普通 AI 笔记工具的区别
很多 AI 笔记工具停留在"帮我总结一下"这一步。
这当然有用，但价值通常是一次性的。总结完，文本被保存下来，可是它未必能自然进入后续的知识网络，也未必知道自己该挂在哪个主题下。
claude-obsidian 更关注的是另一件事：一条新输入应该落在哪个位置，应该和哪些既有主题发生关系。
因此项目里除了写入逻辑，还有一层"主题发现"和"链接建议"机制。写入一篇新笔记后，系统会优先尝试推荐相关的 topic，其次才是 MOC，目的是帮助用户判断这篇笔记应该归到哪里。
重点不是自动把链接乱加一遍，而是帮助用户发现归属关系。
这个方向我觉得比"再多做几个模板"更重要。因为知识系统真正难的不是新增一篇笔记，而是新增之后，它能不能被后续继续找到、继续组织、继续复用。
今天修掉的几个问题，也很能说明这个项目的难点
今天我处理了几个看起来很小、但本质上很说明问题的 bug。
1. 已经在写 topic，还提示"再创建一个同名 topic"
之前如果你正在写一篇 topic 笔记，而 vault 里没有其他匹配主题，系统会给出一个新建 topic 的建议，结果变成建议你"创建一个和自己同名的 Topic"。
这显然是错误的。
它说明系统虽然有"新建 topic 建议"这个机制，但没有正确区分两类场景：
-
当前输入还是待归档的原始内容
-
当前输入本身已经是
topic
修复以后，topic 类型不会再触发 "Topic suggestion"。这个改动很小，但它让系统的行为更符合知识整理的语义。
2. link suggestion 会把日期当关键词，却把 RAG 过滤掉
这类问题更典型。
之前 suggest_links() 的关键词提取逻辑要求词长至少为 4，所以像 RAG 这样的三字母缩写会被直接过滤掉。与此同时，如果因为文件名冲突自动追加了日期后缀，例如：
Literature - RAG 2026-04-10.md
那么 2026 反而会被当作候选词参与匹配。
结果就是，真正有语义价值的词被过滤掉，噪音词却留下了，最后推荐理由里会出现类似 body=2026 的输出。这种推荐看起来"有结果"，但实际上对知识组织没有帮助。
今天的修复做了三件事：
-
关键词提取单独收敛成 helper
-
自动剥离文件名碰撞带来的日期后缀
-
支持三字母大写缩写，例如
RAG
这类问题很能说明一个事实：知识工具真正难的地方，不是"能不能生成内容"，而是"能不能在很多边界条件下做出语义正确的判断"。
为什么我觉得这个方向值得继续做
因为多数人不是缺一个更大的模型，而是缺一条能够把输入持续组织起来的工作流。
如果 AI 只是回答问题，那价值是瞬时的。 如果 AI 可以把回答、资料、排障过程和闪念收进同一套知识系统，价值才会累积。
claude-obsidian 现在还很轻量，但它已经有几个我认为足够重要的方向：
-
结构化，而不是纯文本堆积
-
面向收敛，而不是只面向一次性生成
-
本地优先，直接写入用户自己的 Obsidian vault
-
有组织、索引、lint 和链接建议这些围绕长期维护的能力
-
能把 AI 对话变成长期可复用的知识资产
这也是我最看重它的地方。它不只是"把 AI 输出存下来"，而是在尝试建立一条从输入到知识的连续路径。
接下来还能继续往哪里做
这个项目后面还有不少可以继续打磨的地方。
-
更稳健的
topic匹配和排序逻辑 -
更清晰的
MOC和topic协同关系 -
更好的
organize流程，把 Inbox 里的内容自然收敛到主题结构中 -
更强的
query引用和答案归档能力 -
更贴近真实使用场景的知识演化路径，而不只是静态模板
如果你本来就在用 Claude Code 和 Obsidian，这个项目的价值会很直接：你不再需要在"对话"和"知识库"之间反复搬运内容，而是可以让它们从一开始就是同一条链路。
对我来说，这也是这个项目最值得继续投入的原因。