最近这两天，我为了做这个 skill，是真的被折腾得不轻。

一开始我用 Opus 4.6 做。前前后后烧了 20 刀都不止。结果还是没做出来。我一度怀疑，是不是 2026 年 4 月 8 日早上爆出来的新模型，把他们的算力都抽走了。不然怎么同样一句话，前面还说懂了，后面又给你跑偏。

后来我转去用 Codex，东西倒是做出来了。

但新的问题又来了：做出来，不等于能稳定用。

尤其是你开始认真测试的时候，它又会时不时不遵循指令，自作主张改东西，把我气得够呛。

所以这篇文章，我不打算只讲“我做了一个 skill，欢迎下载”。

我更想讲清楚另一件事：Karpathy 提出的那套 LLM Wiki 方法，怎么才能真的落到一个 Obsidian 笔记库里。

上一篇 Obsidian教程20 讲的是方法。这一篇，我们讲实践。

如果你想直接下载我现在这版脱敏后的 skill，地址我先放前面：

https://blog.discoverlabs.ac.cn/downloads/obsidian-wiki-skill/

里面我已经把 API Key、本地路径这些都处理掉了。但我先提前说一句：别照抄。

这个方法你可以学。这个 skill 你也可以拿去改。但不要幻想直接套上去就能跑。因为每个人的笔记库，真的差太多了。

我做的不是“AI 帮我整理笔记”，而是“AI 帮我做簿记”

先回顾一下 Karpathy 那篇 Gist。

原文地址在这里：

https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

他讲的核心其实很简单：

大多数人现在用 LLM 处理文档，走的还是 RAG 路线。就是把一堆文件丢进去。查询的时候，再临时检索、临时生成答案。

这当然能用。

但问题是，每次都是临时拼。

问一次，拼一次。下次再问，又从头来一遍。没有积累。

所以他提出了一个中间层：不要每次查询都现场拼答案，而是持续维护一个 Wiki。

这件事我看完之后，第一反应不是“这很酷”。

而是：这不就是 Obsidian 最适合接的那类活吗？

因为 Obsidian 本来就是本地 Markdown 文件库。

Karpathy 说的 Wiki，本质上也是一堆 Markdown 文件。

两边底层载体几乎是一样的。

差别只在于：

• 以前是你自己手动维护双链、主题页、结构页
• 现在是 AI 帮你做这些“簿记”工作

注意，是簿记，不是思考。

这一点我越来越认同。

你读文章、做判断、写自己的观点，这些还是要你自己来。

但像双链补全、作者归一、格式检查、派生页刷新这种事情，说白了就是体力活。完全可以让 AI 接手。

Karpathy 的三层结构，我是怎么落到 Obsidian 里的

Karpathy 那套方法，最重要的是三层：

• Raw Sources
• The Wiki
• The Schema

我这个 obsidian-wiki skill，基本也是按这三层来做的。

第一层：Raw Sources

这一层在我这里，就是：

• 01笔记/
• 04输出/

也就是原始收藏、原始笔记、我自己写出来的文章。

这一层我现在很克制。

它的职责就是：保存原始内容。

不让它承担太多额外功能。

不在里面混写一堆派生内容。

不让一篇原始文章同时又变成半个主题页、半个索引页。

因为一旦混起来，后面就很难维护。

这也是我后来修这个 skill 时最深的体会之一：原始层越干净，后面越好做。

第二层：The Wiki

这一层在我这里，是单独的：

01笔记/wiki/

这里面放的是 AI 派生出来的结构层，比如：

• 作者页
• 主题页
• index
• log
• 双链目录

也就是说，原文还是原文。

Wiki 是 Wiki。

两层分开。

这件事听起来很小，实际上非常重要。

因为如果你不分层，AI 每次整理的时候，就很容易把原文越改越脏。

今天补一个主题块。

明天塞一段索引。

后天再插一段自动生成的总结。

最后整个库看起来就像一间一直有人收拾、但越收越乱的房间。

第三层：The Schema

这一层很多人会忽略。

Karpathy 原文里提到 schema。我自己的理解是：你得先告诉 AI，这个库到底应该长什么样。

在我这里，这部分就是：

• SKILL.md
• 一堆 scripts/
• frontmatter 规范
• 作者和 topics 的写法约束
• lint 和 ingest 的流程约束

比如我现在强制要求：

• 作者必须是双链
• topics 必须是双链列表
• 作者页和主题页只能放在 01笔记/wiki/
• 00收集箱/ 只是待处理入口，不直接混进 Wiki
• 原始文章不再混写派生段落

你会发现，真正让 skill 能工作的，不是那句 prompt 写得多漂亮。真正关键的，是这些约束先立住了。

再把三个动作，翻译成真正能跑的流程

Karpathy 那边还有三个核心动作：

• Ingest
• Query
• Lint

我也是照这个思路落的。

如果换成这个 skill 里的实际流程，大概就是这样：

• Ingest：wiki_lint.py --preflight + ob_shuanglian.py suggest/apply + wiki_ingest.py
• Query：先读 wiki/index.md、authors/*.md、topics/*.md，再回到原文补细节
• Lint：wiki_lint.py、wiki_migrate.py、wiki_build_skeleton.py

Ingest：新内容进来以后，先检查，再入库

我没有让 AI 一上来就“看到文章然后自由发挥”。

我现在的流程是先做 preflight。

先检查 frontmatter 对不对。

再看是不是有历史污染。

再去做双链建议。

用户确认以后，才真正 apply。

最后再统一刷新 Wiki 派生层。

为什么要这么麻烦？

因为我已经被模型教育过很多次了。

你要是不加这些护栏，它真的会特别积极地帮你“做决定”。

问题是，它做的决定，未必是你想要的。

所以我后面加了很强的确认门。

topics 不让它乱写。

双链不让它直接落。

作者别名不让它自己拍板。

先给建议，我确认，再写。

这看起来效率低一点。

但知识库这种东西，最怕的不是慢，最怕的是悄悄写错。

Query：不是在原文海里乱捞，而是先读 Wiki 层

查询这块，我现在的思路也不是“全库全文搜索完就交给 AI 总结”。

而是先走：

• wiki/index.md
• authors/*.md
• topics/*.md

先让 AI 在结构化层里看。

必要的时候，再回到具体文章里补细节。

这样做的好处很明显：

不是每次都在一堆零散原文里重新拼。

而是先站在已经整理过的一层上回答。

这才更接近 Karpathy 说的“有积累”。

Lint：这是最重要、也最容易被低估的一步

很多人看到 LLM Wiki，会把注意力都放在 Query 上。

但我自己越做越觉得，真正值钱的是 Lint。

因为知识库一旦大了，你最头疼的不是“问不出答案”，而是：

• frontmatter 乱了
• 作者写法不统一
• topics 到处漂
• 历史结构残留在原文里
• 派生页越长越歪
• 同一个概念出现了几个不同名字

这些东西，如果靠人手工维护，会烦死人。

而且你根本坚持不住。

AI 最适合干的，恰恰就是这个。

不是替你理解世界。

而是替你巡库、对账、找脏数据、补交叉引用。

这就是 Karpathy 那个词为什么特别准：bookkeeping。

真正的大坑，不是模型，而是我以前的笔记库

这件事也是我这次最想提醒大家的。

很多人看到这种文章，会下意识觉得：

“哦，那我把 skill 下载下来，装上，AI 就能帮我管理知识库了。”

真不是。

我这个 skill 最大的难点，不是 prompt，不是脚本，甚至都不是模型。

而是：我以前的笔记太多，而且格式不统一。

我现在跑 lint，看出来的规模大概是这样：

• 文章型 Raw Sources：457 篇
• 全部 Raw 文件：833 篇
• 待处理队列：249 篇
• 双链目录里光主题就已经有 471 个

你想想这个量。

这已经不是“整理几篇笔记”的问题了。

这更像是在接手一个历史很长、没有统一规范的旧系统。

有的文章作者是全名。

有的是别名。

有的 topics 写得很细。

有的又特别散。

有些旧文件里还混着之前遗留的结构。

所以我后来越来越确定一件事：

你想做 LLM Wiki，第一步不是让 AI 接管。第一步，是先把你的库收拾到“值得接管”。

不然 AI 越勤快，反而越容易把脏东西扩散出去。

所以这个 skill 到底做了什么额外的事

如果只看 Karpathy 原文，你会觉得这是一个很优雅的方法论。

但真的做起来，我发现还得补很多工程细节。

比如：

• frontmatter 统一
• 作者别名归一
• topics 强制双链
• 原始层和派生层彻底拆开
• 00收集箱/ 作为待处理入口
• 关键步骤加用户确认门
• 用 lint、migrate、ingest 这些脚本把流程拆开

这些东西 Karpathy 不是没想到。

而是他的 Gist 讲的是模式，不是你这个库的具体实现。

真正落地的时候，你必须自己补这一层。

我现在这个 obsidian-wiki skill，本质上就是在做这件事：

把一个抽象模式，翻译成一个我自己的 Obsidian 库能跑的 workflow。

所以你如果把它下载回去，最该学的不是“复制我的目录”。

而是看我为什么这么分层。为什么这里要确认。为什么这里要做 lint。为什么这里不能直接自动 apply。

如果你也想做，先改这几样

我把脱敏版放到博客下载页了：

https://blog.discoverlabs.ac.cn/downloads/obsidian-wiki-skill/

但你下载以后，第一件事不是运行。

而是先改。

至少要先看这几样：

1. 你的 Vault 路径是不是和我一样
2. 你的 01笔记/、04输出/、00收集箱/ 结构是不是一样
3. 你的 frontmatter 字段是不是跟我一致
4. 你的作者命名、topics 命名，是不是已经比较统一
5. 你要不要保留我现在这种“先建议、再确认、再写入”的流程
6. 如果脚本里涉及 API，你有没有换成你自己的 Key

我放出来的这个版本，已经把 API Key 和本地路径都脱敏了。

你拿到以后，必须按你自己的环境改回去。

而且我还是建议一句：别把我的方法当模板，当参考就行。

你的库如果是读书笔记为主，规则可能跟我不一样。

你的库如果是项目笔记为主，topics 的粒度也会不一样。

你的库如果还处在“先收集、后整理”的阶段，那你可能根本不该先做 Query，而该先把 Lint 和 Ingest 跑顺。

所以别照抄。

照着思路改，才比较靠谱。

总结

这篇文章写到最后，我自己的感觉反而更明确了。

Karpathy 提出的，不只是一个“AI 可以帮你整理知识库”的想法。

它真正有价值的地方是：它重新划分了人和 AI 在知识管理里的分工。

人负责判断。

AI 负责簿记。

这句话，我现在是越做越信。

今天学到了什么：

1. Karpathy 的 LLM Wiki，真正重要的是三层结构和三种操作，不是某个单独的 prompt
2. obsidian-wiki 这类 skill 的关键，不是“会不会总结”，而是能不能把 Raw Sources、Wiki、Schema 分开
3. 真正落地时，Lint 往往比 Query 更重要，因为历史数据清理才是大头
4. 旧笔记越多、格式越乱，越不能直接照搬别人的 skill
5. 下载一个 skill 很容易，真正难的是把它改造成适合你自己知识库的样子

核心要点：

• AI 最适合接手的是簿记，不是替你思考
• 原始层和派生层一定要分开，不然知识库会越整理越脏
• 用户确认门不是多余步骤，而是防止 AI 自作主张的必要护栏
• 先统一格式，再谈自动化；顺序反了，后面一定会痛苦
• 这个 skill 可以拿去改，但不建议原样照抄

下期预告

如果你们感兴趣，下期我就把这个 skill 真正跑一遍：从一篇新文章进来，到双链建议、作者归一、刷新 Wiki 派生层，完整演示一次。

如果觉得有帮助，记得关注这个系列！