AI 变聪明了,你没有:用 LLM Wiki 重建古典政治哲学知识库-夜雨聆风

AI 变聪明了,你没有:用 LLM Wiki 重建古典政治哲学知识库

你有没有这种感觉：

在 ima 里追问了半小时，终于搞清楚了一个问题
关掉窗口，下次再开，什么都要重来
用了一年 AI，读过很多材料，脑子里却没留下一张清晰的知识网络

我花时间问了，但知识没有留下来。

四月初，Karpathy 发了一条推，戳中了这个痛点。

流量很高。

我把原文及翻译贴在下面：

LLM Knowledge BasesLLM 知识库Something I’m finding very useful recently: using LLMs to build personal knowledge bases for various topics of research interest. In this way, a large fraction of my recent token throughput is going less into manipulating code, and more into manipulating knowledge (stored as markdown and images). The latest LLMs are quite good at it. So:最近我发现一件非常有用的事：用 LLM 为我感兴趣的各种研究主题构建个人知识库。如此一来，我最近消耗的 token 大部分不再用于摆弄代码，而是用于摆弄知识（以 Markdown 和图片的形式存储）。最新的 LLM 在这方面已经很擅长了。所以：

Data ingest: I index source documents (articles, papers, repos, datasets, images, etc.) into a raw/ directory, then I use an LLM to incrementally “compile” a wiki, which is just a collection of .md files in a directory structure. The wiki includes summaries of all the data in raw/, backlinks, and then it categorizes data into concepts, writes articles for them, and links them all. To convert web articles into .md files I like to use the Obsidian Web Clipper extension, and then I also use a hotkey to download all the related images to local so that my LLM can easily reference them.数据摄取：我把源文档（文章、论文、代码库、数据集、图片等）索引到 raw/ 目录，然后用 LLM 逐步”编译”出一个 wiki——本质上就是一个按目录结构组织的 .md 文件集合。这个 wiki 包含 raw/ 中所有数据的摘要、反向链接，还会把数据归入不同概念，为每个概念撰写文章，并将它们全部链接起来。把网页文章转成 .md 文件，我喜欢用 Obsidian Web Clipper 扩展，另外我还会用一个快捷键把相关图片全部下载到本地，方便 LLM 引用。IDE: I use Obsidian as the IDE “frontend” where I can view the raw data, the the compiled wiki, and the derived visualizations. Important to note that the LLM writes and maintains all of the data of the wiki, I rarely touch it directly. I’ve played with a few Obsidian plugins to render and view data in other ways (e.g. Marp for slides).IDE：我把 Obsidian 当作 IDE 的”前端”，在这里查看原始数据、编译后的 wiki 以及各种衍生可视化图表。有一点很重要：wiki 里的所有数据都由 LLM 来写和维护，我几乎不直接碰它。我也试过一些 Obsidian 插件，用其他方式来渲染和查看数据（比如用 Marp 做幻灯片）。Q&A: Where things get interesting is that once your wiki is big enough (e.g. mine on some recent research is ~100 articles and ~400K words), you can ask your LLM agent all kinds of complex questions against the wiki, and it will go off, research the answers, etc. I thought I had to reach for fancy RAG, but the LLM has been pretty good about auto-maintaining index files and brief summaries of all the documents and it reads all the important related data fairly easily at this ~small scale.问答：真正有趣的地方来了——一旦你的 wiki 足够大（比如我最近做的研究 wiki，大约 100 篇文章、40 万词），你就可以向 LLM agent 提出各种基于 wiki 的复杂问题，它会自己去查找答案等等。我本来以为得上花哨的 RAG，但 LLM 在自动维护索引文件和所有文档的简要摘要方面做得相当好，在这种”小规模”下，它读起相关重要数据来也相当轻松。Output: Instead of getting answers in text/terminal, I like to have it render markdown files for me, or slide shows (Marp format), or matplotlib images, all of which I then view again in Obsidian. You can imagine many other visual output formats depending on the query. Often, I end up “filing” the outputs back into the wiki to enhance it for further queries. So my own explorations and queries always “add up” in the knowledge base.输出：我不喜欢在终端里拿纯文本答案，更愿意让它给我渲染成 Markdown 文件、幻灯片（Marp 格式）或 matplotlib 图表，然后我再回到 Obsidian 里查看。根据查询类型，你还可以想出很多别的可视化输出格式。我常常会把输出”归档”回 wiki，让它更好地支撑后续查询。这样一来，我的每一次探索和提问都会沉淀到知识库里。Linting: I’ve run some LLM “health checks” over the wiki to e.g. find inconsistent data, impute missing data (with web searchers), find interesting connections for new article candidates, etc., to incrementally clean up the wiki and enhance its overall data integrity. The LLMs are quite good at suggesting further questions to ask and look into.检查（Linting）：我对 wiki 跑过一些 LLM”健康检查”——比如查找不一致的数据、补全缺失数据（配合网络搜索）、发现有趣关联来发掘新文章选题等等，逐步清理 wiki、提升整体数据的完整性。LLM 非常擅长建议接下来可以追问和深入研究的问题。Extra tools: I find myself developing additional tools to process the data, e.g. I vibe coded a small and naive search engine over the wiki, which I both use directly (in a web ui), but more often I want to hand it off to an LLM via CLI as a tool for larger queries.额外工具：我发现自己会顺手开发一些处理数据的辅助工具，比如我 vibe coding 了一个架在 wiki 上的小型朴素搜索引擎——我既可以直接用它（在 web 界面上），但更常见的用法是通过 CLI 把它作为工具交给 LLM，用来处理更大范围的查询。Further explorations: As the repo grows, the natural desire is to also think about synthetic data generation + finetuning to have your LLM “know” the data in its weights instead of just context windows.进一步探索：随着知识库不断增长，很自然地会想去考虑合成数据生成 + 微调，让你的 LLM 把这些知识”内化”到模型权重里，而不只是装在上下文窗口里。TLDR: raw data from a given number of sources is collected, then compiled by an LLM into a .md wiki, then operated on by various CLIs by the LLM to do Q&A and to incrementally enhance the wiki, and all of it viewable in Obsidian. You rarely ever write or edit the wiki manually, it’s the domain of the LLM. I think there is room here for an incredible new product instead of a hacky collection of scripts.一句话总结：从若干来源收集原始数据，由 LLM 编译成 .md wiki，再由 LLM 通过各种 CLI 工具对 wiki 进行操作——问答、逐步完善——所有内容都可以在 Obsidian 中查看。你几乎不需要手动写或编辑 wiki，那是 LLM 的领地。我觉得这个方向完全可以做出一款出色的新产品，而不是现在这样一堆拼凑的脚本。

并且，Karpathy 在 GitHub Gist 写了 LLM Wiki 的详细实现路径。有点长，地址在这里：https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

之后，国内外出现了很多关于 LLM Wiki 的 Skill、App 和文章，主要的论调是说这个方法如何优秀，”RAG 已死”之类的极端观点。

但效果展示？几乎没有。

很多文章不用看，追热点的，完全不顾实际效果。

LLM Wiki 是一个完全”绝知此事要躬行”的方法论。不实践，真的不知道妙在哪里，因为粗略看一眼，都是”概念””实体””双链”这样的旧东西。

所以这篇文章注定没多少流量：

热度过去了不少，月初火的，我月末才写
字有点多，主要聊自己在实践中的理解，没有”XX已死”的爽点
用古典政治哲学作为例子，虽然我做的也是半成品，但迫不及待想聊聊
LLM Wiki 是一个长期方法论，时间短了效果不明显，需要有这样的预期
费钱，token 如流水般消耗，要做好准备

但我还是坚持要写，因为 LLM Wiki 真的可以改变一个人的学习方式，前提是这个人会主动学习。

如果你看到这里还没退出，那我们就开始吧！

为什么是 LLM Wiki，不是 RAG

这个问题值得直接回答。

RAG 很好。它解决了”AI 不知道你的专有资料”这个问题。你把合同、判决书、学习材料放进去，AI 检索时能调取相关内容，回答更准确。没有问题。

但 RAG 的受益者是 AI，不是你。

查询，AI有了数据，AI 变聪明了，你没有。你的知识库里多了几条 token，你脑子里没有多一条神经元。关掉窗口，下次再来，你还是你，AI 还是 AI，两件事没有发生关联。

更进一步：现在很多 Agent 工具已经能做到”全自动学习”，你订阅一个话题，它每天给你发一份摘要，自动建立索引、自动分类、自动关联。效率很高，很省心。

但这里有一个问题：你在这个过程里，学到了什么？

Agent 替你做完的事情，你没有经历那个”理解”的过程。摘要是它写的，关联是它建的，判断是它给的。你看了一眼，觉得不错，然后关掉。下次遇到同样的问题，你还是不会推导，因为你从来没有推导过。

让 AI 越来越聪明，和让你越来越强，是两件不同的事。

LLM Wiki 在意的是后者。

这套方法的设计里，有一个反直觉的地方：它故意不让 AI 全自动运行。你必须在场，你必须判断，你必须追问，你必须决定下一步读什么。LLM 做的是体力活，你做的是方向判断。这个分工不只是效率问题，本质上是在强迫你持续思考。

每次录入一本新书，你会问：这个概念和上一本书里的哪个概念有冲突？这个思想家的逻辑推进顺序是什么？LLM 写的摘要抓住重点了吗？这些问题你不问，wiki 就只是在变大，不是在变好。

但你每问一次，你自己的知识网络就变密一点。

这才是我选 LLM Wiki 的原因。不是因为它比 RAG”技术更先进”，而是因为它在让 AI 做事的同时，也在推着你做事。AI 积累知识，你也积累知识。最后，wiki 是你的，理解也是你的。

人机协同进步，不是让机器替你进步。

LLM Wiki 方法论

对 Karpathy 关于 LLM Wiki 实现思路的原始文件感兴趣的，复制上文的 GitHub Gist 链接。

这里不会机械翻译这个方法论，只介绍主要部分和流程。用之前推荐的 architecture-diagram Skill 做了一张图：

RAG 只是查了，没有学

Karpathy 认为，大多数人在学习时，RAG 是没有知识积累的。这是 LLM Wiki 需要解决的核心问题。

你想一下用 ima 的场景：通过对话框提出一个问题，ima 给你回复了答案，如果你满意，事项就此结束。下一次再用，新开一个聊天窗口，继续让 ima 在知识库范围中检索和回答，而上一次检索所得的成果，并不会成为本次检索的来源。

每次对话都是一次性的，结束了就结束了。你花了半小时追问、澄清、深挖出来的东西，缩在聊天记录里，下次要找回都费劲，更别说让它在下一轮研究中自然”可用”了。

LLM Wiki 换了一种组织方式：不把 LLM 当问答前端，而是把它当知识库的编辑和维护者。 你往里加原始资料，LLM 负责读、提炼、整理、链接，把你读进去的东西持续编译成一个结构化的知识网络。你下次再问问题，LLM 在你积累过的、整理过的、标注过关联的知识网络上工作，而不是在原始文档里现翻。

打个比方。传统 RAG 像你每次去图书馆现查书，查完合上，下次重新来。LLM Wiki 像你有一个研究员，你每给他一份新资料，他读完后更新你的卡片盒，写摘要、标关联、改旧笔记、告诉你”这条跟你之前那张卡片矛盾了”。随着卡片越积越多，你问的每个问题，他都是站在你整个知识体系的基础上回答的。

你是主编，LLM 是编辑

这里有一件事要说清楚：这套方法的受益者是人。

不是交给 Agent 自动运行、每天吐一份学习报告给你，那样没用。你必须自己在场，选什么资料进来、判断 LLM 提取得对不对、追问你觉得重要的方向、质疑它做出的综合判断。LLM 替你做的，是那些即使你会做也懒得做的事：给每份资料写摘要、把相关页面串起来、更新索引、保持几十个页面之间的一致性。

你是主编，LLM 是编辑。方向你定，质量你把关，体力活它干。

不是三个步骤，是一个越滚越大的循环

很多介绍 LLM Wiki 的文章会列出”录入、查询、检查”三个操作。但实际操作起来，它是一个循环，不同阶段侧重点不同。

刚起步的时候，主要做录入。你把手头觉得重要的材料往里放，论文、判决书、经典文本、讲义笔记、网页文章。每放一份，LLM 读完，跟你讨论它看出了什么，然后写摘要、建页，把相关概念串起来。这个过程很慢，但很扎实。你会在 LLM 写的摘要里发现自己之前没意识到的关联。

积累到一定量之后，查询就变得有意思了。你问的不是”搜索关键词”，而是一些需要综合多个材料才能回答的问题。比如”霍布斯的自然状态和洛克的自然状态，在人的理性能力假设上有什么不同？”这个问题需要同时调动霍布斯页、洛克页、自然状态概念页，以及你导入的相关论文摘要。LLM 读一圈，给你一个带引用的回答。如果这个回答有分量，直接让它存成一个新页面，下次问相关问题时，这个分析就已经在那里了。

再往后，需要巡检。 wiki 长到几十上百个页面之后，人会跟丢。哪些页面写了但没人引用？哪些概念被反复提到但没有自己的页面？哪两篇摘要对同一个问题的判断互相矛盾，而你没注意到？这些都可以让 LLM 定期扫一遍，出报告，你来决定怎么处理。

录入 → 查询 → 发现新问题 → 补充新资料 → 检索修补 → 继续查询。 你参与得越多，wiki 和你的思维方式就越接近。

工具选两个就够了

核心工具就两个：一个能读写本地文件的 LLM 客户端（Claude Code、Cursor、Codex 都行），以及 Obsidian。

Obsidian 不是必须的，你完全可以用 VS Code 或任何文本编辑器浏览 Markdown 文件。但 Obsidian 的图谱视图能让你直观看到 wiki 的形状：哪些页面是枢纽，哪些是孤岛，哪些概念群已经自成一体。这个视角在思考”我还缺什么”时特别有用。

整个 wiki 就是一堆 Markdown 文件放在一个文件夹里，天然适合用 Git 做版本管理。改了什么、什么时候改的，Git 全记着。

工具不要贪多，先跑起来再说。等 wiki 真的长到 index 文件不够用了，再考虑加搜索引擎。工具跟着需求长，不要因为看了别人的工具链就一步配齐。

为什么这套方法你真的会坚持下去

我自己做下来，最大的感受是：把”整理知识”这件事的摩擦力降到了最低。

整理知识本身是有价值的，但没有人真的喜欢做。读一篇重要文章，你知道该写摘要、标关联、想清楚它跟之前读的另一篇是什么关系，但你不会做，因为太麻烦了。一篇两篇还能坚持，十篇二十篇就放弃了。

LLM 把这件事变得几乎不需要意志力。你扔给它，它帮你整理好。你只需要判断：整理得准不准？遗漏了什么？哪条关联是你没想到的？这样就从”写作者”变成了”编辑者”，心理门槛完全不一样。

所以 LLM Wiki 能运转下去，不是因为 LLM 比你更懂你的领域，而是因为它替你做了那些你知道该做但懒得做的事。更重要的是，在这个基础上，进一步激发了你的思考

实践：古典政治哲学

我的 LLM Wiki，从整理古典政治哲学的著作开始。

因为最近有一个事项，需要整理阿奎那的自然法思想，手写笔记在几百公里外的老家。我就按照 LLM Wiki 的方法整理了《阿奎那政治著作选》，效果很不错。

于是顺势整理古典政治哲学的代表著作，有些著作虽然严格意义上不属于该范畴，但和古典政治哲学或自然法学派高度相关，也纳入进来。目前的范围从柏拉图的《理想国》到卢梭的《社会契约论》。

从一个现成的 Skill 开始，不要从零摸索

如果直接把 Karpathy 的 llm-wiki.md 交给 Agent 工具来实践，可能会存在较大的偏差。

建议直接从相关的 Skill 开始。

我是从 Hermes Agent 内置的名为 llm-wiki 的 Skill 入手的，地址是：https://github.com/NousResearch/hermes-agent/tree/main/skills/research/llm-wiki

这个 Skill 把 Karpathy 的思路翻译成了一套可以直接执行的规范，值得细看一下它的设计思路。

wiki/├── SCHEMA.md├── index.md├── log.md├── raw/│   ├── articles/│   ├── papers/│   ├── transcripts/│   └── assets/├── entities/├── concepts/├── comparisons/└── queries/

三层结构，职责分明。 Skill 把整个 wiki 拆成三层：raw/ 放原始资料，永远不动；entities/、concepts/、comparisons/、queries/ 放 LLM 编译出来的 wiki 页面；SCHEMA.md 是整个 wiki 的”宪法”，定义命名规范、标签分类、什么情况下该建页、什么情况下只更新现有页。这个分层的意义在于：原始资料是你的，wiki 是 LLM 的。 两层不混在一起，出了问题知道去哪里找。

三个核心文件撑起导航骨架。SCHEMA.md 管规则，index.md 是所有页面的目录，log.md 是按时间排列的操作日志。每次新开一个会话，Skill 要求 LLM 必须先读这三个文件再动手。不读就操作，迟早出现重复页面、漏掉已有关联、甚至和已有内容自相矛盾的问题。”先定向再行动”，是这个 Skill 比直接丢 Prompt 要稳得多的核心原因。

三个操作形成闭环。 Ingest（录入）负责把原始资料提炼进 wiki；Query（查询）负责在 wiki 上回答问题，有分量的答案直接归档成新页；Lint（巡检）定期扫描孤立页面、断链、前后矛盾、来源漂移等问题，出一份报告让你决定怎么处理。三个操作分开，各司其职，不会因为一次查询把 wiki 弄乱，也不会因为一次录入把查询历史丢掉。

还有一个细节我很喜欢：每个 wiki 页面都有一个 confidence 字段，可以标注这个页面的内容是高置信度、中等还是低。这意味着你可以把”暂时不确定”的内容先留着，而不是非得等到完全确认才建页。知识本来就是动态的，这个设计把这件事显式化了。

Git 和模型，两件必须先想清楚的事

Git 管理 wiki，比你想象的更必要。 整个 wiki 就是一堆 Markdown 文件，天然适合版本管理。我的习惯是：LLM 每次改文件都在 wip/* 分支上操作，改完之后汇报”改了哪些文件、为什么这样归类、有哪些待确认”，我看完确认没问题，再 commit 并合入 main。这个流程的意义不是繁琐，而是把人工确认的节点放在 commit 环节，而不是放在动手之前。改完给我看 diff，比事先讨论方案要直观得多，diff 本身就是最好的方案说明。

模型选择的核心原则是：用够用的，别用贵的。 录入（Ingest）是最消耗 token 的环节，一本书摄入进来，LLM 要读原文、写摘要、更新十几个页面，这时候用 Claude Sonnet 4.6 足够。只有在做跨书比较、综合分析这类需要长程推理的任务时，才会切到 Opus。费用确实不低，但用对地方，不会浪费。文章开头提到的”token 如流水”，是真的。

当然，如果用不了 Sonnet 4.6，我推荐 DeepSeek v4 flash！超赞！以当前的定价，每天准备 2 元做日常的 LLM Wiki 完全足够。

候选区：那些还没资格建页的概念，放哪里

这个机制的原则来自 Skill，但具体的落地方式是在实践中摸索出来的，也是整个 wiki 里我最喜欢的设计之一。

Skill 的 SCHEMA.md 模板里有一条建页门槛：概念在两份以上材料中出现，或在单一材料中处于核心位置，才建页；一次性的提及不建。原则清晰，但 Skill 本身没有告诉你：那些”还没达到门槛”的概念放哪里？ 如果不记下来，下次遇到同一个概念，你根本不知道它之前出现过。

解法是加一个”候选区”。我在 _meta/ 下建了一个 概念追踪.md，所有”出现过但还不够格单独建页”的概念都先记在这里，概念名、首次来源、出现记录、简述，以及当前状态。建页门槛只有两个：在两份以上材料中持续出现，或在某本书里处于核心位置。满足其一，才从候选区”升格”成正式的 wiki 页面。

这个机制的价值不只是控制页面数量。它让每一次建页都成为一个有意识的决定，而不是顺手一建。 每次录入新材料，LLM 都必须先查一遍追踪表，这个概念之前出现过吗？现在够格升格了吗？这个动作本身就是在强迫你重新审视以经有的知识网络。

比如”政治动物”这个概念，第一次出现在亚里士多德《政治学》卷一，记入追踪表。后来读阿奎那，他在继承这个概念时做了重要扩展，从”政治动物”变成”社会的和政治的动物”，多了语言能力的论证维度。两次出现，满足升格条件，建了正式的概念页，把两处文本的异同都写进去。这个页面如果只靠第一次读亚里士多德时建，会薄很多。

古典文本不能一次读透，协作方式也要跟着变

古典政治哲学的文本，几乎不能一次读透。

《理想国》十卷，《上帝之城》二十二卷，《论法的精神》三十一卷。这些书不是读完就算，而是需要反复回来，第一次看到的东西，读了后面的书才会理解前面的意思。

渐进式读书协作模式的核心是：允许理解被修正。 每次只处理一个清晰的单元，一卷、一章、一个问题，读完之后，LLM 判断这些内容影响了哪些已有页面，优先更新旧页，实在没有合适落脚点才新建。更重要的是，每次推进完，LLM 要留下一个”接口”，下次从哪里继续，有哪些地方还没定稿，哪些判断是暂时的。

这个模式有一个具体操作规则我觉得很好：在执行写入之前，必须先逐一列出本轮涉及的所有概念和实体，再对照 index 判断哪些有现有页面可以更新、哪些是新的。 听起来像废话，但如果不强制做这一步，非常容易出现”写完正文、忘了维护结构”的情况，新概念没进追踪表，旧页面没有得到补充，wiki 悄悄欠了债。

每完成一个单元，还要做一次”阶段性结构反思”：本轮内容是否在已有概念页里有落脚点但还没更新？有没有形成新的比较轴？追踪表里有没有概念被这次读书触发了升格条件？这个环节不是额外负担，是防止结构债务悄悄积累的检查点。

自然法概念页，是怎么从一条线长成一张网的

说了这么多方法论，来看一个实际的例子。

打开我 wiki 里的《自然法》页面，sources 字段列了十个来源：西塞罗、查士丁尼、奥古斯丁、阿奎那、格劳秀斯、斯宾诺莎、霍布斯、洛克、孟德斯鸠、卢梭。

这个页面不是一次性写完的。

最开始，只有西塞罗。我读完《国家篇》第三卷，LLM 把莱利乌斯那段关于自然法的奠基性宣告写进来，”真正的法律是与本性相合的正确的理性……不会在罗马是一种规则，而在雅典是另一种”。这是”旗帜”。然后读《法律篇》，补进了西塞罗的系统性哲学论证，不从实定法推演，而从哲学深处推演。这是”旗杆”。

之后每读一本书，自然法这个概念就被更新一次。查士丁尼把它收进法学教科书，给了一个实用化的定义；奥古斯丁引入了神学框架，让自然法和上帝的永恒法发生了关联；阿奎那做了最精细的四法层级区分；格劳秀斯把自然法从神学中剥离出来，说”即使没有上帝，自然法也成立”，这是划时代的；霍布斯彻底翻转，把自然法的基础从”正确理性的普遍规范”改造为”自保理性的命令”，自然权利与自然法从此方向相反。

这四个层面是 SCHEMA 定义的分析接口，在概念页和比较页里显式体现：经验事实（文本出处、历史语境）、理想类型（该思想家把这个概念建构成什么类型）、现实偏离（他的版本与前人模型哪里断裂）、机制解释（对象之间如何发生作用）。《自然法》页里的洛克一节是好例子，显式标出了三个子标题：经验事实列出《政府论下篇》Ch.2-4 的核心命题，理想类型用一张对比表把洛克型和霍布斯型并排，机制解释用 ASCII 流程图展示自然法如何一步步推进到政府成立。落下来，这不只是”洛克认为自然法是什么”的笔记，而是一个可以直接和霍布斯、斯宾诺莎对话的分析节点。

这些不是我整理的，是 LLM 在每次录入新书之后，主动回来更新这个页面的结果。 我在做的事情，只是选下一本书读什么，以及判断 LLM 写的东西有没有跑偏。

如果用传统 RAG，你问”自然法的历史演变”，系统从原始文档里现检索，给你一段拼接的回答，下次问同样的问题还要重来一遍。而现在，这个页面就在那里，随时可以打开，随时可以继续往后追。每次都在同一个页面上叠加，前后矛盾的地方会被发现，被标注，被修正。

这就是”知识积累”具体是什么意思。

概念页之外，wiki 还有另一类产出：比较页。比较页的设计原则是”以轴驱动，而非按人头分述”。不是”霍布斯的自然状态是……洛克的自然状态是……斯宾诺莎的自然状态是……”这样按人头铺开，而是先锁定一个比较轴，比如”自然状态中人的理性能力假设”，然后让所有人在这个轴上站队，差异一眼可见。这样建出来的比较页，每读完一本新书，新思想家可以直接嵌进已有的轴，不需要重新起一张表。

关系图谱：看到 wiki 的形状

wiki 积累到一定规模，Obsidian 的图谱视图会变得很好看，也很有用。

每个页面是一个节点，wikilink 是边。当你看到某个节点连线特别密集，那通常是整个知识网络的枢纽概念，比如自然法、法与统治、正义；当你看到某个节点孤悬在外，那就是还没有被充分整合进来的页面，值得回头补充关连。

不用翻 index.md，看一眼图谱就知道哪个区域的网络还稀疏，哪些概念还是孤岛。

当然如果你喜欢 Excalidraw 或者 draw.io 的表现形式，可以通过相应的插件实现更多的可视化效果。

拓展

一些在 LLM Wiki 中好用的工具，根据用途分布在整个链路上。

Obsidian Web Clipper：输入端的利器

这几乎是必装的浏览器扩展，一键把网页文章转成格式干净的 Markdown 文件，直接存进 raw/ 目录。省去手动复制粘贴、清理排版的麻烦。读到一篇有价值的文章，剪辑进来，下次录入时 LLM 直接可以处理。

笔记在线发布：wiki 做到一定程度，可以对外

分发端。如果你想把 wiki 的部分内容公开出去，Obsidian 生态里有几种方案：Obsidian Publish 是官方服务，最省事；Quartz 是开源方案，可以自托管，部署到 GitHub Pages，免费。两者都支持双链和图谱视图在线渲染。wiki 做到一定程度，对外发布一个”知识站点”比在公众号里发一篇文章信息量要大得多。

One More Thing

我把正在做的古典政治哲学 LLM Wiki 做成了在线网站，除了 raw 中的内容，其他全部公开。如果能有一点点帮助，我会很开心。

持续更新中，目前接下来的工作是概念收缩和比较更新。

地址：https://cpp.nervonly.cn/

LLM Wiki 没有终点。你读的书越多，wiki 积累的分析层次越深；你问的问题越复杂，wiki 吐出来的答案越能站在整个知识体系的基础上。这套方法的门槛不是技术，而是你愿不愿意持续往里放东西，每读一本书，每多一次录入，这个知识网络就对你多有用一点。

如果你也有一个想长期研究的主题，不管是法学、历史、经济学还是别的什么，值得试试用这套方式把它做起来。

你的知识库，是你每次认真读过的书留下来的。