知识库管理如何从混乱走向高效？本文揭秘一套经过半年实战检验的解决方案：从目录结构重构到自动化脚本设计，从状态驱动到主题分类的巧妙平衡，再到四层深度讨论技能的打磨。这套系统不仅解决了知识分类的痛点，更通过AI与脚本的精准分工，实现了知识加工的效率革命。

上一篇我聊了搭知识库这半年的认知变化——从“存文章”到“经营认知资产”，从“文章驱动”到“主题驱动”。这篇咱们聊聊具体的工程实操干货：目录怎么分、脚本怎么串、Skill 怎么设计、CLAUDE.md 怎么写、质量怎么守。

先说结论：这套系统不是一开始就设计好的。我的做法更像是在做一个产品——先搭一个最小闭环跑起来，每次在真实使用中发现问题、找到方向，再做下一轮迭代。每轮迭代不是为了“系统更完整”，而是因为上一步跑着跑着，下一步该做什么就自己冒出来了。半年下来，从一个一开始臆想出来的分主题管理的简陋结构，迭代成了现在这套相对稳定的个人知识库产品。

这篇文章，就是把每一轮迭代中发现的问题和做出来的解法，一层一层拆出来。

我推倒重来了一次目录结构

2025 年底刚开始搭知识库的时候，我做的第一件事和大多数人一样：建主题目录。

产品方法论、行业洞察、AI 学习、业务领域知识、洞察思考……我建了五六个目录，设想得很美好——看过的文章按主题分类放进去，后续再在每个分类下做深度加工。

然后这个方案在第二周就崩了。

原因很现实：第一，分不准。一篇讲 AI 产品经理能力模型的文章，到底放“AI 学习”还是“产品方法论”？一篇讲 Agent 在信贷风控中应用的案例，到底放“业务领域知识”还是“行业洞察”？每篇文章进来我都要纠结一次。第二，懒得分。工作间隙看到一篇好文章，用 Web Clipper 存进来已经是我能付出的最大努力了，让我再花两分钟想它该放哪？大概率不会。结果就是大量文章堆在 Inbox 里，主题目录形同虚设。

后来我想明白了一件事：人工分类最大的敌人不是技术，是人性。

于是推倒重来。我把目录从“按主题分”改成了“按状态分”，整个知识库的生产加工像流水线作业一样，只不过最关键的加工工序是需要知识库主人亲自参与——用自己的理解和迁移点亮知识：

当前 Vault 根目录/

├── 00 个人知识库工厂/

│ ├── 01 Inbox/ # 原始文章收集目录，主要来自obsidian web clipper

│ ├── 02 Processed/ # 对原始文章进行批量AI总结提炼后的结构化文章

│ ├── 03 Review/ # 被人工完成深度讨论后迁移过来的Processed文章

│ ├── 04 Archives/ # 被批量AI总结提炼的原始文章归档目录

│ ├── 05 Discussion Insights/ # DI 文档：高价值讨论的过程知识

│ ├── 06 Templates/ # 批量预处理模板/DI模板/知识卡片模板

│ ├── 07 Dataview/ # 查询与盘点层：知识网络总览/治理等视图

│ ├── 08 Scripts/ # 自动化脚本（batch_ai_process / validate / batch_fix / migrate / health_snapshot）

│ ├── 09 Prompts/ # 批量预处理的提示词模板

│ └── 10 Reports/ # 校验/修复/治理/巡检报告 + evolution_logs

├── 01 Knowledge Cards/

│ ├── 00 Index/ # wiki 导航层：归类总览 + 7 个主题域索引

│ ├── 01 方案设计/

│ ├── 02 知识库工作流与知识治理/

│ ├── 03 RAG与知识调用/

│ ├── 04 Eval与质量保障/

│ ├── 05 AI PM转型与能力迁移/

│ ├── 06 Agent_Skill_多Agent协作/

│ ├── 07 AI产品设计与运行治理/

│ └── 08 模型基础_AI技术认知/

Inbox 里的就是还没碰的，Processed 里的就是处理完等待讨论的，Review 里的就是讨论过的。不需要想“这篇文章该放哪个主题”，只需要知道“它走到哪一步了”。

这个改动看起来不大，但对我来说是整套系统能跑下去的起点。

目录即状态：不加多余字段

按状态分目录之后，我发现了一个额外的好处：不需要给笔记打很多状态标签。

很多人设计笔记系统时喜欢加布尔字段：processed: true、discussed: true、archived: true。我一开始也想这么干，后来发现根本不需要——文件在 Processed 目录下，就说明它已经被处理过了；在 Review 下，就说明讨论完了。目录位置本身就是状态，再加一个 discussed: true 纯属多余。

更麻烦的是，字段和目录可能不一致。比如一篇笔记已经从 Processed 移到了 Review，但你忘了把 status 字段从 processed 改成 review。这时候到底信谁？

我的做法是：让 status 字段的值和目录名保持一致，inbox / processed / review / archived，不做额外发明。Dataview 查询时直接按目录筛选，比扫描全库的布尔字段可靠得多。

你可能会问：那 Knowledge Cards 目录为什么又是按主题分的？因为那是沉淀后的知识层，不再是流动中的中间态。主题分类的事，我留给了大模型在深度讨论阶段来完成——它比我更擅长判断一张卡片应该归到“知识库工作流”还是“AI PM 转型”。

让脚本程序处理不需要人来介入的重复劳动，让大模型来负责语义理解和知识推理，把人的精力留给关键结果的最终决断上。 这是我在目录设计上踩完坑后形成的习惯。

三步预处理：用脚本把规则固定下来

目录稳定之后，下一个问题是：怎么把 Inbox 里的原文变成可以讨论的对象？

手动一篇篇读、一篇篇做笔记？我试过，坚持了不到两周就放弃了。每篇文章几千到上万字，做一篇结构化笔记至少二十分钟。如果每周攒了十篇文章，光处理就要三四个小时。这个成本太高了，高到我一定会放弃。

所以我通过Claude Code写了第一个自动化脚本：batch_ai_process.js。

它的逻辑很简单：用 DeepSeek API 调用预设的 Prompt（DeepSeek V4 Pro对文章提炼总结完全够用，关键是性价比极高），把 Inbox 里的文章批量总结提炼处理成统一格式的笔记。输出结构是固定的——摘要、关键知识点、对产品经理的启发、金句摘录。处理完的文章会被migrate脚本自动移到 Archives，新创建的结构化笔记进入 Processed。

但这里有一个关键判断：预处理脚本里不是所有环节都适合交给大模型。 批处理脚本能做的事是有边界的——它擅长的是“按固定规则把结果框在一个标准框架里”，不擅长“替你理解知识”，说白了，脚本里只是把需要总结和提炼文章要点的步骤交给了大模型，而且不做发散，不延伸，其他确定性的步骤，比如读取原文/生成文件/格式化/迁移文件这些都固化在代码里。

为什么？一方面是成本：大模型每次调用都消耗 token，如果让它做深度理解，十篇文章的处理成本会翻好几倍。另一方面是能力边界：大模型提炼的知识点是“文章的理解”，不是“我的理解”。一篇讲 AI PM 能力迁移的文章，大模型可以列出五个核心观点，但这五个观点和我有什么关系？在我的业务里哪些成立、哪些不成立？这些问题需要领域知识、个人经验和判断力，不是调一次 API 就能回答的。

所以脚本的职责收敛到三件事：压缩噪声、统一格式、降低后续讨论的门槛。理解的事，留给后面的人工+AI 深度讨论。

脚本的工作是让大模型按规矩交作业，不是替你思考。 这条界限想清楚之后，才有了后续的Skill四连——因为深度讨论本来就不是脚本该干的活。

后来，随着雏形的不断验证和演化，脚本从一个变成了三个，形成了三层护栏：

1. batch_ai_process：处理原文，生成结构化笔记，归档原文
2. validate_notes：校验笔记的元数据完整性（缺字段、callout 格式不对等）
3. batch_fix_notes：自动修复校验发现的问题

为什么需要三层？因为大模型的输出不一定每次都符合标准格式（大概处理8次就有1篇结构化文章会出现AI式回复：好的，我作为资深产品知识分析专家），有时候它会漏掉一个 callout 块（倒不影响后续的深度分析，只不过在Obsidian中显示会有色块斑秃，有点审美洁癖），有时候 frontmatter 少了个必填字段。校验脚本能发现这些问题，修复脚本能把大部分自动修正。三层走下来，预处理结果就被限制在了一个标准框架里，不管大模型怎么“自由发挥”，最终产出的格式是稳定的。

这三个脚本是我和 Claude Code 一起写的，从第一版到现在的稳定版，修了五六个 bug。印象最深的一个是换行符问题——Windows 的换行符是 \r\n，但脚本里用的是 \n，导致校验时 20 篇笔记报假阳性。排查了大半天才定位到。这种坑不大，但踩一次auto- memory就记住了，后续可以继续沉淀为标准规则。

现在每次处理十篇文章，跑一遍三连脚本大概几分钟。校验和修复也是自动的（但是目前还是通过Obsidian里的QuickAdd执行宏命令的方式手动触发的，因为在Obsidian里直接处理还比较丝滑，后续如果完全成熟稳定了，打算用Hooks来搞个自动化），我花几分钟扫一眼结果，确认没问题，就可以进入深度讨论了。

四个 Skill 是怎么一个个长出来的

批处理脚本解决了“把原文变成结构化中间态”的问题，但真正产生知识增量的，是后面的深度讨论。

深度讨论说起来也有个有意思的小坑，因为刚开始对Obsidian的QuickAdd插件的路径依赖，最早是在 Obsidian 里用脚本+AI API 做的，体验不够好——你需要在笔记里写 prompt，等 AI 返回，再手动整理，继续脚本触发二轮交互。执行了两次发现很傻，而且讨论内容很难沉淀，后来迁移到 Claude Code 的对话交互，体验一下子上了一个台阶：可以在终端里和 AI 来回追问，讨论完了直接让它在当前项目里生成知识卡片。从这个角度来说，Obsidian其实只是我知识库的外在表现形式，真正的幕后本体还是Claude Code搭建的一系列底层能力。

我把跟Claude Code针对某一篇文章的深度讨论过程，反向蒸馏，这就是我的第一个 Skill：deep-discuss。从它开始，用同样的方式——先粗略做个跑通的试验，再反向蒸馏复盘，后来长出了其他几个 Skill，每一个都是被真实需求催生出来的。

deep-discuss：被改得最多的那个试验田

deep-discuss 是我迭代最狠的 Skill，没有之一。它从一个 SKILL.md 文件开始，前前后后改了几十次，主要是从三个角度改的：

结构上，一开始我把流程、约束、模板、规则、输出要求一股脑全塞在一个 SKILL.md 里。这个文件一度膨胀到上千行。后来发现 AI 在处理超长 Skill 文件时容易“漏规则”——它不是没读到，而是上下文太长时某些约束被“稀释”了。后来参考标准 Skill 目录方案做了拆分：SKILL.md 只放核心流程和触发条件，模板放 assets/，细则放 references/。metadata/workflow描述/各流程节点规则约束，三层体系各司其职，按需加载。拆完之后效果明显改善。

讨论模式上，最开始是 AI 读完文章后的常规发问——“你觉得这个观点怎么样？”“在你的业务中适用吗？”这种四平八稳的问题。后来我加了批判性讨论模式，AI 会主动找反例、质疑边界条件。再后来加了双向模式，支持我主动发问，AI 来回答和追问，而不是固定的“AI 问我答”。对于我不太理解的领域，还加入了带教模式，由AI扮演老师来引导我的学习和理解（这个灵感后来激发了我构建一个AI导师学习平台，后续专题再聊）。模式丰富后的讨论深度完全不同。以前是“你觉得这个观点怎么样”，现在是“你确定吗？如果这个边界条件不满足呢？如果和你已有的另一个判断冲突呢？”，会让你不得不静下心来深入思考这些问题，而不是敷衍了事。

流程上，有一段时间我发现讨论完产出的卡片经常和已有卡片重复——明明知识库里已经有一张讲“中间层价值”的卡片，结果讨论完又新建了一张差不多的。后来我在产卡之前强制加了一个“历史卡片扫描”阶段：先扫描现有卡片网络，判断应该 UPDATE（更新旧卡）、EXTEND（扩展子卡）、LINK（建立关联）还是 NEW（新建）。而不是每次都奔着新建去，无限膨胀知识库，卡片在精不在多。

再后来，受 Karpathy 的 LLM Wiki 方法论启发，我又加了一步：讨论结束后，判断这轮讨论是否产生了值得沉淀为独立文档的高价值推理过程——比如某个关键边界条件是怎么被识别的，某个设计取舍背后的推理链。如果有，就生成一份 Discussion Insights 文档，记录“结论之外的推理增量”。这样知识库保存的不只是“当前共识”，也保存了“共识是怎么形成的”。

一次逼出“准入准出”的翻车

这里要特别说一个坑，因为它是 Skill 设计中最容易忽略的问题。

用了十几次deep-discuss之后，我发现 LLM 并不总是严格按照 Skill 里写的流程节点推进。比如流程写的是“先完成证据理解校准，再进入经验共创讨论”，但有时候 LLM 在校准还没做完的时候就跳到了共创。又比如流程要求“先扫描历史卡片，再判断动作类型”，但 LLM 有时会跳过扫描直接开始写新卡片。

这就是“漂移”——LLM 理解规则，但不一定严格遵守规则。尤其在长流程中，它容易“走着走着就偏了”。

我试了好几种方式，最终有效的方案是：在每两个上下游节点之间加入准入准出条件。

举个例子，阶段 6（动作判断）的准入条件是“阶段 5 已形成稳定主框架”，准出条件是“动作清单已锁定且历史卡片已正式扫描”。准入条件不满足，就不应该跳到下一阶段。

这相当于在工作流里加了检查点，每个节点完成后要“盖章”才能放行。加了这套机制后，漂移问题消失了。

给 AI 写流程，最难的不是告诉它做什么，而是拦住它不做什么。 能力越强，漂移的破坏力越大——一个不吝啬输出的 LLM 如果跳过了校验步骤就开始产卡，后果比一个“笨一点的”LLM 严重得多。这也是这个知识库产品的Harness实践的一部分。

从讨论到治理到输出

deep-discuss 稳定之后，我又先后做了三个 Skill：

topic-deep-discuss：解决“同主题多篇文章聚合讨论”的问题。deep-discuss 一次只处理一篇，但很多时候同一个主题下攒了好几篇候选文章，需要聚合起来形成主题卡片网络。我还给它加了一个“双通道”机制——优先判断新内容能不能补强现有主题域的空白带，不能的时候再考虑开新主题。

card-govern：解决“知识网络结构退化”的问题。卡片越来越多之后，孤儿卡、重复卡、主题结构失衡这些问题开始冒出来。card-govern 可以扫描整个知识库，识别这些结构异常并给出修复建议。

kb-apply：解决“知识库能不能用起来”的问题。用卡片网络来写一篇完整的文章——如果写不出来，说明卡片网络有缺口。这也是我正在用的知识输出工具，这篇文章的雏形本身就是 kb-apply 的产出。

四个 Skill 的产出顺序是 deep-discuss → topic-deep-discuss → card-govern → kb-apply。这个顺序就是我的真实需求演进：先学会理解一篇文章，再学会聚合一个主题，然后学会治理整体结构，最后学会输出面向外部的内容。不是规划出来的，是一个痛点解决了，下一个痛点冒出来，再接着做，产品就这样逐渐趋于完善。

这些 Skill 是怎么被搭出来的：CLAUDE.md 是地基

四个 Skill 看起来各自独立，但它们能被 Claude Code 统一按一套规范标准构建出来，并能正确理解和执行，靠的是一个共同的底座：CLAUDE.md。

问题是这样来的：每次在 Claude Code 里启动新会话，LLM 对你的项目一无所知。你得重新告诉它目录结构是什么样的、Skill 怎么用、哪些事情不能做。如果这些信息不在一个固定的地方等着它，每个新会话就像一次失忆重来。

CLAUDE.md 就是 Claude Code 启动时自动读取的项目指令文件。这就是创造我这个知识库工厂的加工厂的厂规——有了它，LLM 每次开始工作时都知道：你是谁、当前的知识库工厂长什么样、哪些事可以做、哪些事不能做。

我的 CLAUDE.md 大概包含这几块：

项目定位。明确告诉 LLM：这不是一个笔记收集系统，而是一个“由 LLM 协同维护的个人领域 wiki 系统”。这句话决定了 LLM 在后续所有操作中怎么理解自己的角色。

系统结构。目录怎么分层、每层的职责是什么、文件在各层之间怎么流转。CLAUDE.md 里有一棵完整的目录树，LLM 读完后能知道一篇笔记从 Inbox 到 Knowledge Cards 要经过哪些阶段。

当前系统能力。三个脚本和四个 Skill 各自干什么、什么时候触发、核心流程和约束是什么。CLAUDE.md 里是摘要版，详细内容在每个 Skill 自己的 SKILL.md 里。

规范和约束。笔记的 frontmatter 最小字段集、知识卡片的五种 type 取值、状态流转规则、YAML 引号规则等。这些规范直接影响后续的校验和治理脚本，必须写得非常具体。以及一些禁区——“不能修改 Archives 下的原始文档，不能跳过校验直接产卡”

当前知识库Dashboard。用一些统计数据和简短的摘要，描述当前的知识库现状，以最低成本让Claude Code了解当前的基线是什么。

CLAUDE.md 的维护方式和 Skill 一样：先写一版能跑的，用着用着发现哪里不对就补一条规则。不要一次改很多条，改完用下一次操作来验证。

有一个细节值得一提：CLAUDE.md 本身也在演进。我的第一版 CLAUDE.md 只有二十几行，写了目录结构和基本规则。到搭建高峰期扩展到大几百行，涵盖了项目定位、当前进展、下一步规划、Skills 摘要、技术栈等完整信息。每次系统出现新变化——比如新增了一个 Skill、完成了一轮治理升级、达成了一个阶段目标——我都会同步更新 CLAUDE.md。它不是一个写完就放在那里的文档，而是系统的实时快照。到现在我系统化的学习了Claude Code的完整产品能力后，尤其是关于memory的相关知识，又把它精简到了100多行，很多相关的规则迁移到了.claude/rules下，关于知识库项目搭建的进展和计划也迁移到了ROADMAP.md里，用@的方式在必要位置引入。（关于Claude Code本身的十大能力学习分享，咱们后续有空细聊）

CLAUDE.md 的本质不仅是给 AI 写一份说明书，而且是给每次新会话植入一份记忆。 没有它，AI 每次都是从零开始；有了它，AI 是接着上次继续。

但 CLAUDE.md 解决的是“AI 知道该怎么做”的问题。知道该怎么做，和真的做对了，是两件事。AI 有可能理解规则但不遵守，有可能输出格式不稳定，有可能在卡片越来越多的时候产生结构性问题。规则写好了，还需要一套机制来守住执行质量。

三层防线：我知识库自己的Harness

卡片越来越多之后，我遇到了各种结构问题：有孤儿卡（没被任何主题页索引），有重复卡（两张卡片讲的是同一件事），有某个主题下支卡很多但没有主卡统领，有关系字段缺失（卡片和卡片之间没有建立连接）。

我做了三层防线，不是一开始就设计好的，也是吃一堑长一智，一层一层补上去的。

第一层：脚本层——守住格式。validate_notes.js 和 batch_fix_notes.js 负责校验和修复格式问题。缺字段、callout 格式不对、YAML 语法错误——这些机器能查的事不靠人眼。这两个脚本我也和 Claude Code 一起写了好几版，印象最深的就是前面提到的换行符 bug。

第二层：Skill 层——守住结构。card-govern 负责治理知识网络的结构问题。它做了很多事：识别孤儿卡、识别重复卡和高相似卡、检查主题结构是否失衡、检查 frontmatter 是否合规。我给它做了四个模式：单卡治理、主题治理、增量治理、全库巡检。目前全库巡检的结果是 clean——孤儿卡 0、重复卡 0、结构失衡 0。不是因为没有问题，而是之前几轮治理已经把问题都修了。

第三层：Dataview 层——守住全局。用 Obsidian 的 Dataview 插件搭了几个视图：各主题卡片数量、最近新增卡片清单、缺少关键字段的卡片清单、未挂载主题页的卡片清单。每周打开一次，扫一眼全局，就知道下一步该补什么、该治什么。

这三层防线的建设顺序是：先有脚本校验（因为格式问题最先暴露），再有 Skill 治理（因为结构问题在卡片多了之后才出现），最后有 Dataview 视图（因为需要一个全局视角来做决策）。不是先规划好三层防线再动手，而是每遇到一类新问题就补一层，逐渐培养出Harness的意识和手感。

我的日常操作节奏

最后还原一下我的日常操作流程，让你感受一下这套系统实际跑起来是什么样子。

碎片时间：看到好文章，用 Web Clipper 存进 Inbox。不用想分类，不用想格式，存完就走。

攒到一定量后（一般十篇左右）：可能是周末或某天晚上打开 Obsidian，用 QuickAdd 宏跑三连脚本——批处理、校验、修复。整个过程几分钟。等脚本跑完，人肉扫一眼修复报告，确认没有未修复的问题。原文已经自动归档到 Archives，结构化笔记进了 Processed。

找时间深度讨论：看 Processed 里的笔记，判断是单篇高价值还是同主题多篇。单篇用 deep-discuss，同主题多篇用 topic-deep-discuss。讨论完自动生成知识卡片，笔记迁移到 Review。

定期全局巡检：打开 Dataview 面板，看各主题域的卡片分布，看有没有空白带需要补充，看有没有治理提示需要处理。

偶尔写一篇：用 kb-apply 试试知识库能不能支撑一篇完整的文章。写不出来，说明卡片网络有缺口；写出来了，就是一篇既可以发布的分享内容初稿，又是对知识库健康度的一次体检验证。

整轮下来一两个小时。不长，但知识库的清晰度和完整度又推进了一点，这种能直观感受到的知识库成长进化的过程，正是让人欲罢不能的产品体验（上篇说的每天不交互一轮就浑身难受）。

如果你想从零搭一套

如果你看到这里，心痒手痒想自己搭一套，我的建议是：不要一上来就搭完整系统。

先做最小闭环：

1. 装 Obsidian + Claude Code

2. 建四个目录：Inbox、Processed、Review、Archives

3. 写一份 CLAUDE.md：告诉 LLM 你的目录结构、基本规则、它的角色

4. 手动处理三篇文章：先不写脚本，手动走一遍“放入→处理→讨论→产卡”的全流程。具体来说，每篇文章做三步：

• 处理：把原文丢给 Claude Code，让它按你预设的模板生成一篇结构化笔记——摘要、关键知识点、对你职业的启发、金句。这一步不用追求深度，格式统一就行
• 讨论：拿着结构化笔记和 Claude Code 做一轮对话。不是让它总结，而是追问——“这个观点在我的业务里成立吗？”“和我已有的某个判断冲突吗？”“如果边界条件不满足呢？”讨论中产生的新判断，才是真正属于你的东西
• 产卡：讨论结束后，把最有价值的结论提炼成一张知识卡片——一句话核心洞见、详细阐述、适用边界、应用场景。卡片不是文章摘要，是你校准过的判断

5. 第一篇暴露问题：哪里不顺手就记下来

6. 调整 CLAUDE.md：把暴露的问题补成规则

7. 第二篇验证调整：看规则是否生效

8. 第三篇看流程是否稳定：如果连续三篇都跑得通，最小闭环就成了

之后再按需加能力：处理太慢？写脚本。讨论太浅？设计 Skill。卡片开始乱了？加治理。没有全局视角审视你的知识库？加Dataview查询。

我在前十篇文章时完全没有脚本，纯手动。到第十篇之后发现重复劳动太多，才写了批处理脚本和蒸馏出深度讨论的Skill。到三四十张卡片时发现结构开始乱，才做了治理 Skill。

先手动跑通，痛点出现时再加能力，每次迭代都有真实需求驱动。 不要为了“系统完整”而提前搭一堆用不上的东西。

写在最后

回头看这套系统，真正有用的不是某个具体脚本或 Skill，而是几个设计选择：

• 让目录表达状态，不靠人工分类
• 让脚本做压缩，把理解留给人
• 让 Skill 做workflow流程协议，不让 LLM 自由发挥
• 让 CLAUDE.md 做行为宪法，让每次会话不失忆
• 让质量守卫分层建设，不让系统长期失控

这些选择没有一个是提前规划好的。每一个都是在某个痛点上被卡住之后，试了几种方案，选了一个最稳的。

搭建知识库最难的部分不是技术实现（没有技术基础完全不是障碍），而是在每个痛点出现时做出对的产品设计选择。而这些选择，只有在你真正开始用、真正遇到问题时，才有条件做。

所以别等了。先建四个目录，存三篇文章，写一份 CLAUDE.md，跑起来再说。

在你的实践中遇到什么真实问题，欢迎沟通交流。