个人知识库

知识库构建工程

20分钟阅读

知识库构建工程

如何用 LLM（尤其是 Claude Code）+ Obsidian/Markdown + 脚本 + Skill，把碎片化信息编译成持续积累、互相链接的个人或组织知识库。核心不是工具，而是一套”先跑通、痛点驱动迭代”的工程方法论与质量守卫体系。

核心观点

  1. 目录设计的第一性问题是”按状态分”还是”按主题分”：@Sean 最初和多数人一样建主题目录，第二周就崩了——“分不准”（跨主题文章每篇都要纠结）+“懒得分”（人性使然）。他推倒重来改成按状态分（Inbox→Processed→Review→Archives），流动中间态用状态目录、沉淀后的知识层才按主题分（主题分类交给大模型）。核心洞察是”人工分类最大的敌人不是技术，是人性”。（来源：2026-07-11-woshipm-knowledge-base-engineering-practice）

  2. 脚本与大模型必须分工：脚本做确定性劳动，大模型只做语义理解，人做最终决断：预处理脚本里只把”总结提炼要点”交给大模型且不发散，读取原文/生成文件/格式化/迁移全固化在代码里，理由是成本（token）和能力边界（大模型给的是”文章的理解”不是”我的理解”）。这条边界是脚本层与 Skill 层分野的根本依据。（来源：2026-07-11-woshipm-knowledge-base-engineering-practice、2026-05-28-woshipm-llm-wiki-qmd-architecture）

  3. CLAUDE.md 是整套系统的”行为宪法”/“地基”：它是 Claude Code 启动时自动读取的项目指令文件，给每次新会话植入记忆，让 LLM”接着上次继续”而非”从零开始”。两篇讲个人 LLM Wiki 的素材都把 CLAUDE.md 定位为行为规范手册而非配置文件，内容都覆盖角色定义、系统结构、核心流程、约束禁区，维护方式都是”先写能跑的、一次改一条、用下一篇文章验证”。（来源：2026-07-11-woshipm-knowledge-base-engineering-practice、2026-05-28-woshipm-llm-wiki-qmd-architecture）

  4. Skill 是被真实需求一个个催生的，不是规划出来的：@Sean 的四个 Skill 产出顺序（deep-discuss→topic-deep-discuss→card-govern→kb-apply）正是需求演进——先学会理解一篇、再聚合一个主题、再治理整体结构、最后输出外部内容。每个都是”先粗略跑通、再反向蒸馏”长出来的。这与 Skill 词条的”先跑通再封装""Skill 是长出来的不是设计出来的”完全一致。（来源：2026-07-11-woshipm-knowledge-base-engineering-practice）

  5. 给 AI 写流程，最难的是拦住它不做什么：LLM 理解规则但会”漂移”（长流程中走着走着就偏了），最有效的治理是在流程节点间加”准入准出条件”（检查点/盖章机制），而不是把提示词写得更长。“能力越强漂移的破坏力越大”。（来源：2026-07-11-woshipm-knowledge-base-engineering-practice）

  6. 质量必须分层守（Harness 意识）：脚本层守格式、Skill 层守结构、Dataview/视图层守全局，建设顺序对应问题暴露的先后（格式最先、结构随卡片增多、全局最后）。这与 lint”只抓结构问题不判断内容真伪”的原则同源——机器能查的不靠人眼，内容判断留给人。（来源：2026-07-11-woshipm-knowledge-base-engineering-practice、2026-05-28-woshipm-llm-wiki-qmd-architecture）

  7. 知识库的核心本体是”认知资产”而非知识集合：收集只回答了”知识怎么进来”，没回答”知识怎么变成我的”。@Sean 存了两百多篇好文章却”没有一篇是我的”，由此提炼出目标应从”存了多少篇文章”变成”沉淀了多少只有我理解和迁移后才能写出来的判断”——即 认知资产（经个人经验、场景、失败与成功校准过、不可替代）区别于通用的”资料”。这为整个工程方法论提供了本体论目标：所有脚本、Skill、治理动作都是为了服务认知的淬炼而非知识的堆积。（来源：2026-07-14-woshipm-hoarding-to-cultivation-cognitive-assets）

  8. 批量处理跳过了”理解”，必须加中间层 + 讨论机制：纯脚本批量处理只产出”大模型理解后的输出，不是我的”。解法是把批量产物定义为 Processed 中间层（讨论输入而非终点），之后加入讨论机制让 AI 扮演作者或领域专家来回质疑碰撞。同一篇文章，批量只产 5 个知识点，一轮深度讨论却能生出属于自己的判断。这补齐了脚本与大模型分工之外”语义理解如何变成个人判断”的关键一环。（来源：2026-07-14-woshipm-hoarding-to-cultivation-cognitive-assets）

  9. 别急着做 RAG，先让知识轻量级用起来：顺序不能反——知识结构还在高频变动期就做向量化和 RAG，只会放大不稳定结构，检索到一堆格式不统一、边界不清、互相重叠的碎片。更基本的问题是”你的知识库被用起来了吗”：系统没进入真实使用场景就无法暴露真实知识缺口，“自动进化”也缺少反馈源。检验方式是用知识卡片四分机制沉淀后的卡片网络去写一篇需要跨主题、论据可追溯的文章，写不出来就说明有结构缺口——这个信号比任何自动化指标都直接。（来源：2026-07-14-woshipm-hoarding-to-cultivation-cognitive-assets）

  10. 搭建方法论：先手动跑通最小闭环，痛点出现时再加能力：不要一上来搭完整系统。先建四目录 + 写 CLAUDE.md + 手动跑三篇（处理→讨论→产卡），连续三篇跑通最小闭环就成了；之后处理太慢就写脚本、讨论太浅就设计 Skill、卡片乱了就加治理、缺全局视角就加 Dataview。每次迭代都由真实需求驱动。（来源：2026-07-11-woshipm-knowledge-base-engineering-practice）

  11. 个人本地知识库与组织级云端知识库是两条演化路径：本地路径（Markdown + Claude Code + qmd 检索）重在”经营认知资产、少花 token 多沉淀”；组织路径（RAG + 云端 + 多端 + 权限）重在”多人协作、可运营产品化”。本地 RAG 足以验证价值，但离开电脑就不可用、难以复用，这是它天然卡住的地方。（来源：2026-05-21-woshipm-ai-knowledge-base-product-design、2026-05-18-woshipm-ai-knowledge-management-design-practice、2026-06-17-woshipm-ai-knowledge-base-product-design）

  12. 第三条路径：产品知识库——镜像的是产品运行现状，不是外部文章或企业文档：诸葛铁铁指出需求文档堆积却无法还原产品现状；解法是系统→模块→页面→功能 + 影响关系 + 三层能力（可定位/可追踪/可验证），让一句需求穿透 PRD、UI 与代码。它与个人知识库在“结构、生效态、关系边、防版本冲突”上同构，对象却是产品自身规则。（来源：2026-07-10-woshipm-product-knowledge-base-prd-ui-code）

素材汇总

日期素材标题核心内容路径类型
2026-07-142026-07-14-woshipm-hoarding-to-cultivation-cognitive-assets@Sean 姊妹篇：从囤积到经营，知识库核心本体是”认知资产”，补上理解层、别急做 RAG个人本地
2026-07-112026-07-11-woshipm-knowledge-base-engineering-practice@Sean 半年实战：3 脚本 + 4 Skill + 3 层防线，个人知识库的产品化演化史与方法论个人本地
2026-07-102026-07-10-woshipm-product-knowledge-base-prd-ui-code诸葛铁铁：产品知识库让需求穿透 PRD/UI/代码；层级+影响链路+三层能力产品现状
2026-05-282026-05-28-woshipm-llm-wiki-qmd-architecture秋孝隱：qmd 混合检索 + bin/wiki CLI + CLAUDE.md 四层架构，少花 token 多沉淀知识个人本地
2026-05-212026-05-21-woshipm-ai-knowledge-base-product-design王佳亮：本地 RAG 升级为组织级云端知识库（Yuxi + Docker + 多端）组织云端
2026-05-182026-05-18-woshipm-ai-knowledge-management-design-practice从个人文档检索痛点推演到企业级 AI 知识库产品化落地的完整复盘组织云端
2026-06-172026-06-17-woshipm-ai-knowledge-base-product-design基于 RAG 的云端 AI 知识库完整搭建：痛点洞察、技术选型到产品实现组织云端

知识体系

一、目录与状态设计

知识库的第一个工程决策是目录怎么分。@Sean 的答案是流动态按状态分、沉淀层按主题分：处理流水线（Inbox/Processed/Review/Archives）用目录位置直接表达处理进度，避免人工分类的心智负担；只有真正沉淀下来的 Knowledge Cards 才按主题组织，且主题归类交给大模型。配套原则是 目录即状态——不额外发明 processed: true 之类布尔字段，避免字段与目录不一致，Dataview 直接按目录筛选。

二、脚本层：把确定性劳动固化

预处理脚本负责”压缩噪声、统一格式、降低后续讨论门槛”。关键是 脚本与大模型分工：脚本里只把”提炼要点”交给大模型，其余读取/生成/格式化/迁移全部写死在代码里。@Sean 的三连脚本（batch_ai_process→validate_notes→batch_fix_notes）形成”生成→校验→修复”的格式护栏；秋孝隱的 bin/wiki CLI 则把 qmd 底层命令封装成语义化动作（search/get/find-related/search-chunks），让 LLM 像调 API 一样稳定操作知识库。

三、Skill 层：承接语义理解与深度加工

脚本管不了的”理解”交给 Skill。Skill 是深度讨论反向蒸馏出的可复用能力包，@Sean 的四个 Skill 覆盖”理解单篇→聚合主题→治理结构→输出内容”完整链条。Skill 内部用三层文件（SKILL.md 主流程 + references + assets）避免超长文件”漏规则”，用四种讨论模式（常规/批判/双向/带教）提升讨论深度，用”历史卡片扫描”（UPDATE/EXTEND/LINK/NEW）避免重复产卡。

四、行为规范层：CLAUDE.md

CLAUDE.md 项目指令 是整套系统的地基，让每次新会话都带着统一的项目记忆和行为约束开工。它约束脚本和 Skill 按同一套规范被构建和执行，并随系统演进持续更新（膨胀后用 .claude/rules + ROADMAP.md + @ 引入做减法）。

五、质量守卫层：三层防线 / Harness

知识库长大后会出现孤儿卡、重复卡、断链、结构失衡。@Sean 用三层防线守质量——脚本守格式、Skill（card-govern）守结构、Dataview 守全局；这被他称为”知识库自己的 Harness闭环工程”。治理 LLM 流程漂移的关键机制是 准入准出条件，把”拦住 AI 不做什么”系统化为节点检查点。

六、检索与长文档处理

当知识库变大，检索底座变得关键。秋孝隱用 qmd 做 BM25 + 向量混合检索，并为超长文档设计 search-chunks + WIP 续传机制，解决”上下文爆、处理中断、读了前面忘了后面”三件事。这一层是个人本地知识库从”能存”走向”能查、能用”的分水岭。

综合分析

不同素材的交叉视角

  • 个人本地 vs 组织云端：@Sean 和秋孝隱代表个人本地路径（Markdown + Claude Code，重沉淀轻检索成本），王佳亮等代表组织云端路径（RAG + 多端 + 权限，重协作与产品化）。两条路径的共同起点都是”明明存过却找不到”的检索痛点，分岔点在于是否需要多人协作与随处访问。
  • CLAUDE.md 的定位高度一致：两篇个人 LLM Wiki 素材都把 CLAUDE.md 从”配置文件”提升为”行为规范/宪法”，都强调渐进式、一次一条的维护纪律，形成互证。
  • 方法论收敛到同一句：无论个人还是组织，都强调”先跑通三篇/三天再迭代”——@Sean 的”先手动跑通痛点驱动加能力”、秋孝隱的”先写一版能跑的每次改一条”、王佳亮的”三天跑通全链路的粗糙行动，胜过三个月精致犹豫”，本质是同一种 MVP + 迭代的产品思维（见 闭环沉淀、知识资产）。
  • 目标本体：认知资产 vs 知识集合：@Sean 的姊妹篇把整套工程的目标锚定在 认知资产——收集只解决”知识怎么进来”，真正稀缺的是”淬炼成带个人判断、可持续演化的资产”。这与组织路径把金牌销售经验写进 SOP 的 知识资产 命题同源，只是落在个人层面，也解释了为什么四分机制、讨论层、kb-apply 都是为”沉淀判断”而非”堆积文本”服务。
  • 对 RAG 的克制态度：个人本地路径普遍主张”先让 wiki 层稳定、知识轻量级用起来，再考虑向量化和 RAG”——结构还在高频变动期就做 RAG 只会放大不稳定；这与组织云端路径”直接上 RAG 做产品化”形成鲜明对照，分野依据仍是知识结构是否已稳定、是否需要多人协作。
  • 个人/组织知识库 vs 产品知识库：@Sean/秋孝隱编译的是外部文章与个人判断；组织 RAG 编译的是企业文档检索；诸葛铁铁编译的是产品当前运行规则与影响边。三者都强调“目录/层级 + 生效态 + 关系 + 防漂移”，但验收标准不同：个人路径看能否写出带判断的文章，产品路径看一句需求能否安全穿透 PRD/UI/代码。

趋势与判断

  • 知识库正从”存储工具”演化为”由 LLM 协同维护的认知资产系统”：价值不在存了多少，而在能否被持续编译、检索、复用、输出。kb-apply”能不能用知识库写出一篇文章”是检验知识库健康度的高杠杆动作。
  • 工程重心从”提示词”转向”结构与护栏”：随着模型变强，单次输出质量不再是瓶颈，如何用目录结构、Skill 边界、准入准出条件、分层校验来约束 LLM 的长流程行为成为核心工程问题。这与 上下文漂移、Harness闭环工程 的主张一致——用结构而非叮嘱治理漂移。
  • 确定性 vs 语义理解的分工会越来越清晰：脚本/CLI 固化确定性步骤、Skill/LLM 承接语义理解、人负责最终决断，三者职责边界的清晰程度直接决定系统的成本与稳定性。
  • 产品侧知识库会与 AI 写 PRD 工作流合流：当产品现状可机读，需求不再是等待扩写的文字，而是变更指令；个人知识库方法论中的“生效态、关系边、验证门禁”将直接复用到 AI产品PRD 与 AI产品经理工作流。

未解决的问题

  1. 个人本地知识库如何低成本获得组织级的多端访问与协作能力，而不必整体迁到云端 RAG？
  2. 准入准出条件、三层防线这类治理机制能否被标准化、模板化，让新手直接复用而非各自踩坑重造？
  3. 知识库”卡片在精不在多”的judgment（何时 UPDATE/何时 NEW）目前仍依赖人的判断，能否被更可靠地 Skill 化？
  4. 跨知识库、跨工具（Obsidian / Claude Code / qmd / RAG）的知识如何互通与迁移？
  5. 产品知识库如何与代码仓库、设计稿、接口文档持续双向对齐，避免“图谱很美、实现已变”？

相关页面

关系图谱

快速导航

反向链接