从日积月累形成的知识库是法律工作者很重要的一项“资产”，它是支撑“越老越值钱”的支柱之一。

从 OneNote 开始，到印象笔记、语雀、Wolai、Notion、腾讯文档——市面上主流的笔记软件我基本都用过；虽然也建立起了知识库体系，但一直有一个痛点：入库存入和维护的边际成本太高了。

收藏一篇文章很容易。但把它拆解、提炼、归类、和自己的其他知识建立联系——这件事需要的时间，往往比阅读本身还长。于是材料越积越多，知识库越来越像仓库而非工具。东西都在，但想用的时候找不到，或者找到了也只是一篇孤零零的文章，和其他知识没有任何关联。

Karpathy 提出基于 Markdown 和 AI 的笔记系统之后，我一直想试一试。这个系统的核心想法很简单：所有知识用纯文本 Markdown 存储，AI 负责入库和维护，人负责判断和决策。我看到这个方案的第一反应是”这就是我想要的”。但当时面临一个现实问题：能处理大规模文本的 Claude 和 Codex，订阅用量都特别有限，根本支撑不了批量处理几百份判决书的消耗。

直到最近，Claude Desktop 接入了 DeepSeek 的 API。DeepSeek 的 token 足够便宜，而且 Claude Desktop 搭配 DeepSeek 跑出来的结果，也到了可用的程度。加上Google刚刚基于Karpathy提出的理念发布了OKF标准，所以我决定试一试。

我用了两天的时间，消耗超过1亿Token，在原来笔记和日常写作、积累的基础上，搭建了一个 包含1600 多个 Markdown 文件、覆盖多个法律领域的本地知识库。这个知识库不仅可以用Obsidian查看，我还让AI帮我搭建了一个本地可更新的网页。

一、知识库的基本结构

这个知识库有三个核心理念。

**纯文本优先。**所有知识以 Markdown + YAML frontmatter 存储。不需要数据库，不需要专用软件。VS Code、Obsidian、grep——任何文本工具都可以读。十年后打开这些文件，看到的还是可读的文字。

**渐进结构化。**入库的时候只填两个必填字段：type（文档类型）和 title（标题）。其他字段——案号、法院、裁判日期、关联法官——用到了再加。知识的结构不是设计出来的，是在使用中自然长出来的。

**链接即知识图谱。**文件之间用标准 Markdown 链接互相引用。一个案例链接到它体现的裁判规则，一条规则链接到它引用的案例和法条。不需要单独的图谱数据库，链接本身就是一张网。

目录结构很简单：

├── cases/         # 案例摘要（按人民法院案例库体例）
├── rules/         # 裁判规则（从案例中提炼的可复用规则）
├── statutes/      # 法规条文梳理
├── doctrines/     # 学术观点与研究笔记
├── judges/        # 法官信息库
├── enforcement/   # 强制执行专项
├── practice/      # 实务工具与模板
├── sources/       # 判决书全文等源数据

目前 cases 下面有 560 多个案例摘要，rules 有 50 条多条裁判规则，statutes 梳理了 77 部法规的核心条款，judges 收录了 400多位法官的信息——而且每个法官页面都双向链接到了他审过的案件。

二、AI 驱动下知识库的新建与维护流程

1. 把日常积累和检索成果直接发给 AI

过去的工作流是这样的：研究一个问题 → 找到相关判决书和文章 → 读完 → 放下。下次遇到类似问题，要么重新搜，要么凭记忆翻文件夹。

AI驱动逻辑下，可以换一个做法：研究结束之后，把手里所有的材料——判决书全文、类案检索报告、自己写的专业文章——一股脑儿发给 Claude。告诉它：这是材料，按 OKF 规范入库。

一个具体的例子。之前和同事写过一篇关于计算机软件开发合同违约赔偿责任的论文，引了 8 个案例，梳理了 24 项裁判规则。以前写完就写完了，文章是文章，案例是案例，之间没有连接。这次我把文章发给 AI，它在几分钟内做了这些事：

  • 把文章引用的 8 个案例分别写成了 case-brief——每个都按人民法院案例库的体例，包括基本案情、裁判结果、裁判理由、裁判要旨
  • 把 24 项裁判规则拆成了一条一条的独立规则文件，每条都附了支撑它的案例链接和法条引用
  • 新建了一份学说文件，提炼了文章的研究框架
  • 更新了所有相关的索引

整个过程，我的工作量是什么？是读 AI 生成的结果，判断”对还是不对”——这个案例要旨提炼准不准确，这条规则的表述是否严谨，法条引用有没有错。AI 负责”量”——把几百份判决书读一遍、写摘要、建链接。我负责”质”——确保每一条写入知识库的内容都经得起办案时的引用。

以下是提需求后AI自己写的流程（经过几轮优化）：

2. 与扩展性更强的 Workbuddy 协作

使用 Markdown 作为知识库基础格式的一个好处是，不同的 AI 工具都可以来读写。同一个文件，既可以在 Claude Desktop 里用，也可以在 Obsidian 里查看和编辑。

这一点在实际使用中比听起来的更重要。

目前 Claude Desktop 处理单次对话的质量是最好的——无论是理解法律概念、提炼争议焦点，还是按规范格式写作，都很到位。但它在扩展性上有限制，比如访问网页信息存在一些障碍，做大规模批量操作也不那么方便。

所以我用了一个分工：需要理解的任务交给 Claude Desktop，需要联网执行的任务交给 Workbuddy。

举一个例子。我希望系统性地建立法官信息库——不仅把入库案例中涉及的法官信息提取出来，还要把平时做类案检索时关注过的法官也汇总进去，形成一份”我自己的法官清单”。每个法官要知道他的审判风格、关注的核心问题、审过的关联案例。

这个工作的起点在 Claude Desktop：它把已有案例中的法官信息提取出来，创建了基本的法官页面，建立了案例和法官之间的双向链接。但补充和完善的工作，比如在网上搜索某位法官的其他判决、汇总他的裁判倾向，交给 Workbuddy 更合适——它可以直接在网络上查找、读取、整理信息，然后把结果写回到同一个 Markdown 文件中。

这些文件同步到本地以后，在 Obsidian 里打开，每个法官页面都链接到相关案例，每个案例页面也都有链接回到法官。查一个案子，顺手就能看到这个法官还审过哪些类似案件、有什么裁判倾向——这在过去的办案中是不可想象的。

三、知识库可以实现的效果

一个案例的价值是有限的。但当一个案例被链接到它所体现的裁判规则，那条规则又链接到支撑它的法条，法条又链接到相关的学术讨论——这时候再来看这个案例，它不再是孤零零的判决书，而是嵌在一整张知识网络里的节点。

举个例子。我搜一个关于委托理财保底条款的案例。打开 case-brief 以后，frontmatter 里有规则链接，正文底部有”关联案例”。点一下规则链接，我看到这条规则背后还支撑着其他 6 个案例——其中有正面的也有反面的。再点一下法官链接，我看到这个法官还审过另外 3 个委托理财的案子。

这个过程过去怎么做？要在法律数据库里反复检索，靠案由和关键词慢慢筛。现在是在自己的知识库里，顺着链接走，一分钟之内就能完成。

以下是一条总结的Rules的示例，蓝色字体均是链接可点击跳转，或者在Obsidian里面直接在本页面浮窗预览：

四、知识库的实战使用

说到底，知识库不是用来”有”的，是用来”用”的。虽然刚搭起来两天，实践中能发挥多大作用还有待检验，但从结构上看，至少有几个方向是比较值得期待的。

写代理词的时候，不再需要从零开始搜材料——争议焦点在知识库里搜一下，相关的裁判规则和支撑案例就出来了。正反两面的规则都有链接，代理词的事实部分和法律适用部分都有素材支撑。

接到新案件，第一反应不是去裁判文书网大海捞针，而是在自己的知识库里先搜一遍。搜出来的结果都是自己筛选、验证过的——这种信任感，和检索任何第三方数据库都不一样。

当然，这些都是推演。真的在办案中用起来，可能会有新的惊喜，也肯定会暴露出新的问题。但方向是对的。

五、建立知识库 Skill 的过程

这个Skill建立过程本身也是AI驱动的，我只是提想法和诉求，具体怎么实现由AI来搭建。当然这个过程当中需要告诉他Karpathy的笔记理念，Google所发布的OKF标准。当然只要提到这些东西就可以了，剩下的可以由AI自己去检索和自己理解。

需要注意的是，这个Skill并不是一蹴而就的，它需要在执行的过程当中，一遍遍的进行细节的修正，并且在经过几次实际的知识库建立对话和修正以后，可以让AI自己回顾历史对话，来总结有哪些内容是可以进行更新和优化的，然后由AI自己重新更新Skill。不得不说这是一个很让人上瘾的过程。分享一下积累下来的几个知识库的原则：

  1. 不编造：不确定的信息一律标注 [待补充] 或 [待核实]，宁可留白也不臆造。没有判决书全文时，case-brief 的裁判理由必须原文引用而非扩写，缺失处标注 [待补充]。
  2. 脱敏不可逆：入库前完成当事人、金额等敏感信息脱敏，入库后不可还原
  3. 源文件必留：判决书全文、文章全文必须保存到 sources/ 对应子目录
  4. 双向链接：每新增一个文件，必须在被引用文件中建立反向链接
  5. 聚合而非每篇新建：Rules 和 Doctrines 都是聚合体——一条 rule 收集同一法律命题下的多个案例，一个 doctrine 收集同一研究主题下的多篇论文。绝大多数新案例应归入已有 rule，绝大多数新论文应归入已有 doctrine。只在确立了前所未有的新原则或开创了全新研究主题时才创建新文件
  6. 先查后写：操作前先读对应域 INDEX.md 确认无重复，有则更新，无则新建
  7. 构建顺序：Statutes → Sources（判决书全文）→ Case-briefs → Rules → Doctrines。不可反过来——Rules 需要引用前两者，必须先有底层再建上层
  8. YAML 链接加引号：frontmatter 中所有 Markdown 链接值（cases/sources/related_rules 等字段）必须用双引号包裹——“text”。不加引号会导致 Obsidian 属性面板整段标红（YAML 将 […] 误解析为数组语法）。这是最常见的 frontmatter 错误，参见下文”YAML 链接格式专项警告”
  9. Rule 正文所有引用即超链接：Rule 正文中每个引用的案号、法条、学说都必须是可点击的 Markdown 链接——案号指向 case-brief，法条指向 statutes/ 对应文件（如有锚点则精确到 #第X条），学说指向 doctrines/ 对应文件。不可写纯文本引用。这是最常见的漏修项——只改了 frontmatter 字段而正文和表格中的引用仍是纯文本，必须逐字检查正文和所有表格单元格
  10. 判决书缺口主动告知：Rule 需要引用但知识库缺少完整判决书的，告知用户案号让用户下载，不创建信息残缺的 case-brief 后再补救
  11. 条文级锚点优先：statute 文件中每个法条必须有独立标题（### 第X条），方可被精确锚点定位。入库 statute 文件时检查正文是否为平面粗体文本——若是，必须将 第X条 转为 ### 第X条 标题。所有指向单一条文的链接必须精确到 文件名#第X条 锚点，而非仅文件级链接。只有多条文引用（如”第12-14条”）或一般性引用（不指向具体条文）时才保留文件级链接

搭建知识库是AI驱动律师工作的一个小方向，但是它可以充分地说明，现在的模型水平和Agent水平已经可以初步实现AI驱动下的部分律师工作了。如今写代码的工作已经在快速地向AI驱动转型；当下或者说不久的将来，律师工作如何与AI相互磨合，优化工作流程，也是律师不得不思考的问题。