法律人如何用 LLM 搭建个人知识库？这套方法值得抄作业
大概两个月前，我干了件事——把自己散落在各处的判决书摘录、法律论文、实务笔记、合同模板，全部喂给了 LLM。
不是让它帮我总结，是让它帮我"编译"成一套能用的知识库。
结果有点出乎意料。这套东西现在成了我每天都会打开的工具。不是那种"买了会员就再也不打开"的效率工具，是真的在用。
今天把这套方法完整梳理出来。7 个环节，一个一个讲。
一、数据摄取：raw/ 目录是你的资料仓库
第一步不是想"怎么组织"，而是先把东西收进来。
我建了个 raw/ 目录，往里扔东西：裁判文书、法学论文 PDF、法规汇编、实务文章、庭审笔录、合同范本。不分类，不整理，先堆着。
网页剪藏我用的 Obsidian Web Clipper 扩展——看到好的实务文章、法规解读，一键剪进来。剪完之后有个关键动作：把图片下载到本地。不然 LLM 读不了。
这一步的核心原则：别在摄入阶段搞分类。分类是后面的事。很多法律人（包括我之前）卡在这一步，就是因为想一边收一边整理，结果什么都没收进来。
说白点，资料仓库不需要整齐，需要全。
二、IDE 选择：Obsidian 当前端，LLM 当后端
我试过不少笔记工具。Notion、Logseq、印象笔记、Heptabase。
最后还是回到 Obsidian。
不是因为功能最强，是因为它不锁定。所有数据都是本地 .md 文件，随时能迁移。这个特性对法律人格外重要——你的案例摘录、法规笔记、实务心得，这些东西是职业生涯的积累，不能被任何一家工具厂商绑定。
Obsidian 当"显示器"，LLM 当"处理器"。
我很少自己在 Obsidian 里写东西。大部分内容是 LLM 写进来的。它负责编译 wiki、生成摘要、建立反向链接、按法律概念分类。我只负责看和提问。
这套分工让我把精力放在"用知识"而不是"整理知识"上。
三、让 LLM 编译你的法律 wiki
这是整套方法的核心。
有了 raw/ 目录的原材料，接下来让 LLM 逐步"编译"成 wiki。wiki 本质上就是一堆 .md 文件，按目录结构组织。
LLM 做几件事：
生成摘要——每份裁判文书生成一个精炼摘要：争议焦点、法院观点、裁判结果、参考价值。存成独立的 .md 文件。
建立反向链接——在摘要里标注"这篇判决涉及哪些法律问题"，然后在对应概念的文章里自动引用回来。
概念分类——把 raw/ 里的内容按法律概念拆分。比如 raw/ 里有 15 份关于违约金的判决，wiki/ 里就有一篇"违约金裁判规则综述"，把 15 份判决的核心观点整合进去。
互相链接——概念之间建立双向链接。点击"违约金过高调整"，能跳到"合同解除后果"，再跳到"损害赔偿范围"。
整个过程我不动手。我只在 LLM 编译完之后检查一下，偶尔纠正几个分类错误。
四、问答：当 wiki 足够大，它就开始产生价值
有趣的是，当 wiki 积累到一定规模，你就可以直接向 LLM 提问了。
我的法律 wiki 现在大约 100 篇文章，40 万字左右。不算大。
但已经够用了。
我提问的方式很简单：直接告诉 LLM "去我的 wiki 里找答案"。它会自动查找相关案例、交叉引用法规、给出分析。
比如我问："违约金过高的认定标准，最高院近三年的态度有变化吗？"它会去翻我 wiki 里的相关判决摘要，告诉我：2023 年 XX 案还坚持 30% 的红线，但 2025 年 YY 案已经转向"实际损失为主、兼顾过错程度"的思路。
原本以为需要复杂的 RAG 系统。结果发现——LLM 在维护索引文件和摘要方面做得相当不错。小规模知识库（几十万字），它能比较轻松地读取关键信息。
一个问题：** wiki 多大才算"够用"？**
我不确定。可能因执业领域而异。但我感觉，当你能从 wiki 里找到 50% 以上你需要的答案时，它就开始值了。
五、输出：不要在终端里看答案
这是另一个关键点。
我不喜欢在终端里直接看文本答案。太干，没上下文，看完就忘。
我让 LLM 把输出渲染成几种格式：
Markdown 文件——归档回 wiki，成为新的一部分。比如一次问答产出的"违约金问题综述"，下次还能引用。
幻灯片——用 Marp 格式，准备内训或者客户汇报时直接用。
案例检索报告——表格形式，案号、法院、争议焦点、裁判观点一列列排好。
这样一来，每次问答都在"喂养" wiki。检索和研究的过程本身，也在积累知识。
这个习惯改变了我使用 LLM 的方式——从"问完就忘"变成"问完留下点什么"。
六、维护：LLM 能帮你"体检"
wiki 用久了会出问题。法规更新了、判决被改判了、观点过时了。
我让 LLM 定期做几件事：
健康检查——找出 wiki 里的过时法规、被推翻的判例引用、孤立的文章。
填补空白——发现缺失的知识点。比如"违约金"写了十篇，但"定金"一篇没有，LLM 会提醒我。
发现联系——找出看起来不相关但实际有关联的问题。比如"合同解除"和"不当得利"在某些场景下的交叉。
提出问题——LLM 擅长发现"这里好像还缺了什么"，比我自己翻一遍更敏锐。
这些维护工作不需要频繁做。我大概两周跑一次。每次能发现几个值得优化的地方。
七、工具链：按需搭建
除了核心的 Obsidian + LLM 组合，我还加了一些辅助工具。
法规检索——对接北大法宝或威科先行的 API，法规更新时自动提醒。
格式转换——处理各种来源的文档，Word 判决书、PDF 论文，统一转成 .md。
版本控制——git 管理 wiki 的变更历史。不是必须，但有了更安心——万一改错了还能回退。
这些工具不用一次配齐。用到什么加什么。
我现在的状态是：核心流程稳定运行，工具链按需迭代。
最后：这套方法的核心逻辑
核心逻辑其实很简单。
输入——从多个渠道收集法律资料：裁判文书、法规、论文、实务文章，存到 raw/ 目录。
编译——LLM 把原始资料编译成结构化的 wiki（.md 文件集合），按法律概念组织。
交互——通过对话向 wiki 提问，让 LLM 检索、分析、整合。
输出——Markdown 笔记、检索报告、幻灯片，归档回 wiki。
维护——定期检查过时信息、补齐缺失、发现关联。
可视化——Obsidian 当前端，查看原始资料和编译结果。
整个过程中，我很少手动编辑 wiki。写和整理都是 LLM 做。我只负责提问、审核、决策。
说句实话，这套方法不一定适合所有法律人。搭建知识库本身就有门槛，需要折腾。
但如果你跟我一样，每天接触大量案例和法规、需要反复调用过去的积累、不想让收藏夹变成"数字坟场"——
这可能值得试一试。
参考资源：
- Andrej Karpathy：用 LLM 构建个人知识库的方法论
- Obsidian + Cursor 构建知识库系统
- 2026 个人 AI 知识库最优解
- AI 时代知识管理方法（2025 年版）
- Best Practices for Knowledge Management - Glean