用 Obsidian、Claudian 和 LLM Wiki 搭建车载法规知识库

今天用 Obsidian + Claudian 搭了一个个人知识库，主题聚焦在车载相关的法律法规和测试标准。资料来源都限定为公开资料，比如公开发布的法规条文、标准目录、测试方法说明、官方解读、行业白皮书和公开论文。

这个知识库不是简单地把 PDF、网页、Markdown 丢进一个文件夹，然后等大模型临时检索。我的目标更像 Karpathy 在 LLM Wiki 里描述的模式：让大模型把资料逐步编译成一个持续维护的、互相链接的 Markdown wiki。原始资料保持不动，知识库页面持续更新，问题和结论可以沉淀下来。

从 Obsidian 开始

我没有把它做成一个复杂系统，而是先从 Obsidian vault 开始。原因很简单：Obsidian 天然适合 Markdown、双链、图谱、标签和本地文件管理。它不像传统数据库那样重，也不像纯文件夹那样散。

我的基本配置思路是：

1. 新建一个独立 vault，只放车载法规和测试标准相关内容；
2. 安装 Claudian 插件，让 AI agent 能直接在 vault 里读写和整理笔记；
3. 按 LLM Wiki 的思路建立 raw sources、wiki、schema、index、log；
4. 每次新增资料时，让大模型先理解资料，再更新 wiki，而不是只做一次性问答。

注意：这里不写 Claude Code 怎么安装，只从 Obsidian 里的配置和知识库组织开始。

安装和启用 Claudian

Claudian 是一个 Obsidian 插件，它的作用是把 Claude Code、Codex、Opencode、Pi 等 agent 型工具嵌入到 Obsidian vault 里。它不是一个普通聊天插件，而是让 vault 变成 agent 的工作目录：agent 可以读文件、写文件、搜索、执行多步整理任务，也可以在笔记里做 inline edit。

我在 Obsidian 里按这个流程配置：

1. 打开 Obsidian 的 Settings；
2. 进入 Community plugins；
3. 关闭 Safe mode，如果之前没有开启社区插件；
4. 点击 Browse；
5. 搜索 Claudian；
6. 安装并启用插件；
7. 在左侧 ribbon 或 command palette 中打开 Claudian 侧边栏；
8. 在插件设置里确认 agent provider 和 CLI 路径能正常识别；
9. 给 vault 设置必要的环境变量或 PATH，让桌面版 Obsidian 能找到本机 agent 命令。

Claudian 的 README 里提到，它支持侧边栏聊天、选中文本 inline edit、通过 @ mention vault 文件或外部目录、通过 / 或 $ 调用 prompt 模板和 skills，还支持 MCP servers。这些能力对知识库很有用，因为知识库维护不是一次问答，而是持续的文件整理和多步编辑。

Vault 目录结构

我给 vault 设计了一个比较直接的结构：

vehicle-kb/
  raw/
    regulations/
    standards/
    whitepapers/
    cases/
    assets/
  wiki/
    index.md
    log.md
    overview.md
    regulations/
    standards/
    concepts/
    tests/
    entities/
    comparisons/
  schema/
    instructions.md
    page-templates.md
    ingest-workflow.md
  questions/
  outputs/

这里最重要的是三层：

• raw/：原始资料层，只放公开来源资料，尽量保持不可变；
• wiki/：LLM 维护的知识层，放总结、概念页、标准页、法规页、对比页；
• schema/：约束层，告诉 LLM 如何命名、引用、更新、记录日志。

raw/ 是事实来源，wiki/ 是可读的知识产品，schema/ 是维护规则。

raw sources：原始资料不要乱改

车载法规和测试标准类知识库最怕“二手转述污染事实”。所以我把 raw/ 当成 source of truth。

例如：

raw/regulations/
  gb-xxx-xxxx-xxx.md
  eu-xxx-summary.md
  un-rxxx-official.md

raw/standards/
  iso-xxxxx-overview.md
  gb-t-xxxxx.md
  test-method-xxx.md

raw/assets/
  diagrams/
  tables/
  screenshots/

放进 raw/ 的资料最好带上来源信息：标题、发布机构、发布日期、访问日期、链接、文件类型、适用范围。公开 PDF 可以保留原文件，也可以另存一份 Markdown 摘要，但摘要要明确标注不是原文。

我的原则是：LLM 可以读 raw/，可以引用 raw/，但不要直接改 raw/。如果原始资料需要更新，应该新增版本或补充来源记录，而不是覆盖旧文件。

wiki：让知识持续累积

Karpathy 的 LLM Wiki 思路里，一个关键差异是：不是每次提问时才从原文里临时检索，而是让 LLM 把资料逐步整理成持久 wiki。

这对车载法规和标准特别合适。因为这个领域的问题经常不是单篇资料能回答的，而是需要跨文件综合：

• 某项法规适用于哪些车型或功能；
• 某个测试方法和另一个标准之间是什么关系；
• 车载软件、功能安全、网络安全、数据合规之间如何交叉；
• 某个测试项需要哪些前置条件、设备、判定标准；
• 新标准是否改变了旧流程里的判断依据。

如果每次都让 LLM 从几十份资料里现找片段，它会很累，也容易漏上下文。把知识编译成 wiki 后，LLM 只需要先读 index.md，再进入相关页面，就能更快地回答问题。

index.md 和 log.md

我把 wiki/index.md 当作内容目录。每个页面都应该在这里有一行摘要：

## 法规

- [[regulations/xxx]]：适用范围、核心要求、和测试流程的关系。
- [[regulations/yyy]]：关于数据记录和合规检查的要求。

## 测试方法

- [[tests/environmental-test]]：环境适应性测试的条件、流程和判定点。
- [[tests/cybersecurity-test]]：网络安全测试输入、过程、证据留存。

wiki/log.md 则是时间线。每次 ingest、query、lint、重构都写进去：

## [2026-06-04] ingest | 某公开标准说明

- 新增：[[standards/xxx]]
- 更新：[[tests/xxx-test]]、[[concepts/xxx]]
- 发现：和旧页面 [[standards/old-xxx]] 存在适用范围差异
- 待确认：是否需要补充官方解释文件

这两个文件能让知识库变得可导航、可审计。时间久了以后，log 还能帮助 LLM 理解最近做过什么，避免重复整理。

schema：给 LLM 的工作规约

我专门写了 schema/instructions.md，用来约束 LLM 的行为。它大概包含这些规则：

• 回答法规和标准问题时，必须标注引用来源；
• 不确定的内容要写“待确认”，不能写成结论；
• 标准编号、发布日期、适用范围不要凭记忆补；
• 发现新资料和旧页面冲突时，不要直接覆盖，先在页面中记录差异；
• 每次 ingest 后必须更新 index.md 和 log.md；
• 新概念第一次出现时，如果很重要，要创建概念页；
• 页面之间要用 Obsidian wikilink 连接；
• 不把非公开资料、账号信息、内部文件路径写进 wiki。

这个 schema 很关键。没有 schema，LLM 只是一个泛用聊天助手；有了 schema，它才更像一个守规矩的 wiki maintainer。

Ingest 流程

每次加入新资料，我会尽量一份一份处理，而不是一次丢一堆。流程大概是：

1. 把公开资料放到 raw/ 对应目录；
2. 在 Claudian 里告诉 agent：处理这份资料；
3. agent 先读原文，提取标题、来源、适用范围、关键条款、测试相关点；
4. 生成或更新 wiki/ 页面；
5. 检查是否需要创建概念页、法规页、测试方法页；
6. 更新 index.md；
7. 在 log.md 记录这次 ingest；
8. 我人工看一遍摘要和引用，纠正重点。

我比较喜欢保持人在回路里。法规和测试标准不是闲聊知识，错误会影响判断，所以不能完全自动放行。

Query 流程

查询时，我不会直接问“某法规怎么理解”，而是让 agent 先从 wiki 开始：

请先阅读 wiki/index.md，找到和车载网络安全测试相关的页面，
再回答：某测试项需要哪些输入、过程证据和判定标准？
回答时列出引用页面，并标出不确定项。

这样问的好处是，LLM 不会立刻跳到原文海里随机抓片段，而是先利用已经整理好的知识结构。

对于复杂问题，我会要求输出成表格：

• 法规/标准名称；
• 适用范围；
• 测试对象；
• 测试条件；
• 判定依据；
• 证据材料；
• 待确认来源。

这些回答如果有长期价值，就放进 wiki/comparisons/ 或 outputs/，下次还能继续复用。

LLM Wiki 是什么

LLM Wiki 可以理解成一种“由 LLM 维护的个人知识库模式”。它和传统 RAG 最大的区别是：RAG 往往是在提问时检索原始资料片段，然后临时生成答案；LLM Wiki 则是在资料进入时就让 LLM 编译知识，把总结、链接、冲突、索引和演化记录沉淀成 Markdown 页面。

它的核心不是“更智能的搜索”，而是“知识会累积”。

这种模式有几个特点：

• 原始资料保持不可变；
• wiki 页面持续演化；
• 新资料会更新旧页面；
• 重要概念会形成独立页面；
• 矛盾和差异会被记录；
• index 帮助导航；
• log 帮助追踪历史；
• 人负责选资料和判断重点，LLM 负责整理和维护。

Karpathy 在那篇 LLM Wiki 里有一句很打动我的表达：Obsidian 是 IDE，LLM 是程序员，wiki 是代码库。这个比喻很准确。知识库不是一堆静态笔记，而是一个会被持续重构的项目。

我的车载法规知识库应用

我这个知识库目前主要服务几个场景。

第一，法规和标准速查。比如想知道某个车载功能涉及哪些公开标准、测试时应该关注哪些输入输出、是否需要记录某类证据，可以先查 wiki，而不是每次翻 PDF。

第二，测试流程拆解。公开标准里经常有很多描述性文字，我希望把它们整理成可执行的测试视角：测试对象、测试条件、操作步骤、判定标准、证据留存、异常情况。

第三，标准之间的关系梳理。车载领域的知识很容易交叉：功能安全、预期功能安全、网络安全、软件升级、数据安全、环境可靠性、EMC、人机交互都可能同时影响一个功能。wiki 的双链适合把这些关系串起来。

第四，形成自己的问题库。每次我问过的问题，如果答案有价值，就不让它留在聊天记录里，而是沉淀到 questions/ 或 wiki/comparisons/。这样问题本身也会成为知识库的一部分。

第五，做后续测试设计的辅助输入。真正写测试方案时，可以让 agent 先读相关法规页、标准页、概念页，再生成测试点草稿。我再人工审查，避免模型把不确定的内容写成结论。

我给这个知识库定的边界

因为内容涉及法规和测试标准，我给它定了几个边界：

• 只纳入公开资料；
• 不把内部项目、客户信息、未公开资料放进 vault；
• 不让 LLM 直接改原始资料；
• 所有结论尽量带引用；
• 重要结论需要人工复核；
• 不确定项单独标记；
• 新旧标准差异不直接覆盖，要保留版本和来源。

这不是为了麻烦，而是为了让知识库可以长期信任。知识库如果一开始就混入无法追溯的内容，后面越整理越危险。

后续想做的事

下一步我想给它补几类能力：

1. 给每个 wiki 页面加 YAML frontmatter，比如来源数量、更新时间、可信度、适用范围；
2. 用 Dataview 生成标准清单、待确认项、最近更新页面；
3. 定期让 LLM 做 lint，检查孤立页面、过期结论、缺少引用的段落；
4. 给高频问题建立 query templates；
5. 对测试标准建立统一页面模板；
6. 如果页面规模变大，再考虑本地 Markdown 搜索或 MCP 搜索工具。

我觉得这套方法最有价值的地方，是让知识整理从“收藏资料”变成“持续编译”。车载法规和测试标准本来就不是一次性读完就结束的东西，它们会更新、会互相引用、会影响测试流程。让 LLM 帮我维护这个结构，Obsidian 负责承载和可视化，人负责判断和校准，这个分工是比较舒服的。

参考资料

• Karpathy: LLM Wiki
• YishenTu/claudian