个人知识库

2026-07-11-woshipm-knowledge-base-engineering-practice

22分钟阅读

2026-07-11-woshipm-knowledge-base-engineering-practice

@Sean 半年实战复盘：把个人 AI 知识库当产品来做——目录从”按主题分”推倒重来为”按状态分”，用 3 个脚本固化确定性劳动、4 个 Skill 承接语义理解、CLAUDE.md 做行为宪法、3 层防线守质量，核心方法论是”先手动跑通、痛点出现时再加能力”。

基本信息

  • 标题：【万字长文】3 个脚本、4 个 Skill、3 层防线：我的 AI 知识库是怎么一步步长出来的
  • 作者：@Sean
  • 来源：人人都是产品经理
  • 阅读量：1677 浏览 / 34 分钟
  • 原始链接：https://www.woshipm.com/ai/6427281.html
  • 素材类型：网页文章（万字长文）
  • 消化日期：2026-07-11

这是作者知识库系列的第二篇（工程实操篇）。上一篇讲的是从”存文章”到”经营认知资产”、从”文章驱动”到”主题驱动”的认知转变，本篇聚焦具体工程实操：目录怎么分、脚本怎么串、Skill 怎么设计、CLAUDE.md 怎么写、质量怎么守。

核心观点

  1. 目录从”按主题分”推倒重来为”按状态分”：作者 2025 年底最初和大多数人一样建了五六个主题目录（产品方法论、行业洞察、AI 学习……），第二周就崩了。原因有二——第一”分不准”（一篇讲 Agent 信贷风控的文章到底放”业务领域知识”还是”行业洞察”？每篇都要纠结）；第二”懒得分”（工作间隙用 Web Clipper 存进来已是最大努力，不会再花两分钟想放哪）。结论是”人工分类最大的敌人不是技术，是人性”。于是改成按状态分：Inbox（未处理）→ Processed（AI 批量提炼后的结构化笔记）→ Review（人工深度讨论后迁移）→ Archives（原文归档），加 Discussion Insights、Templates、Dataview、Scripts、Prompts、Reports 等工厂配套目录。

  2. 目录即状态，不加多余布尔字段：很多人喜欢加 processed: true、discussed: true、archived: true，作者发现根本不需要——文件在 Processed 目录下就说明处理过了，在 Review 下就说明讨论完了，目录位置本身就是状态。而且字段和目录容易不一致（笔记从 Processed 移到 Review 但忘改 status 字段，该信谁？）。作者的做法是让 status 字段值和目录名保持一致（inbox/processed/review/archived），Dataview 直接按目录筛选，比扫描全库布尔字段可靠。而 Knowledge Cards 目录之所以又按主题分，是因为那是沉淀后的知识层（不再是流动中间态），主题分类交给大模型在深度讨论阶段完成。

  3. 脚本与大模型的分工边界：脚本做确定性劳动，大模型只做语义理解：作者用 Claude Code 写的第一个脚本 batch_ai_process.js，用 DeepSeek V4 Pro API 调用预设 Prompt 把 Inbox 文章批量提炼成统一格式笔记（摘要、关键知识点、对 PM 的启发、金句摘录），处理完由 migrate 脚本自动把原文移到 Archives、结构化笔记进 Processed。关键判断是”预处理脚本里不是所有环节都适合交给大模型”——脚本里只把”总结提炼要点”这步交给大模型且不发散不延伸，读取原文/生成文件/格式化/迁移文件等确定性步骤全固化在代码里。理由是成本（每次调用消耗 token，让它做深度理解成本翻好几倍）和能力边界（大模型提炼的是”文章的理解”不是”我的理解”）。脚本职责收敛到三件事：压缩噪声、统一格式、降低后续讨论门槛。

  4. 三个脚本形成”三层护栏”，把大模型的自由发挥限制在标准框架内：batch_ai_process（处理原文、生成结构化笔记、归档原文）→ validate_notes（校验元数据完整性：缺字段、callout 格式不对等）→ batch_fix_notes（自动修复校验发现的问题）。为什么需要三层？因为大模型输出不一定每次符合标准格式（大概处理 8 次就有 1 篇会出现”好的，我作为资深产品知识分析专家”的 AI 式回复，有时漏掉 callout 块、frontmatter 少必填字段）。印象最深的 bug 是换行符问题——Windows 是 \r\n 但脚本用 \n，导致校验时 20 篇笔记报假阳性，排查大半天，踩一次 auto-memory 就记住了。

  5. 四个 Skill 是被真实需求一个个催生出来的，顺序即需求演进：产出顺序是 deep-discuss → topic-deep-discuss → card-govern → kb-apply，对应”先学会理解一篇文章，再学会聚合一个主题，然后学会治理整体结构，最后学会输出面向外部的内容”。每个都是先粗略跑通试验、再反向蒸馏复盘长出来的，不是规划出来的。deep-discuss 是迭代最狠的试验田（改了几十次），从结构（拆分为 SKILL.md + assets + references 三层，解决超长文件”漏规则”问题）、讨论模式（常规发问→批判性讨论→双向模式→带教模式）、流程（加”历史卡片扫描”判断 UPDATE/EXTEND/LINK/NEW，加 Discussion Insights 记录”结论之外的推理增量”）三个角度改进。

  6. “准入准出条件”是治理 LLM 流程漂移的关键机制：用了十几次 deep-discuss 后发现 LLM 不总是严格按 Skill 流程节点推进——校准没做完就跳到共创，跳过历史卡片扫描直接写新卡。这就是”漂移”（LLM 理解规则但不严格遵守，尤其在长流程中容易”走着走着就偏了”）。最终有效的方案是在每两个上下游节点之间加准入准出条件（如阶段 6 动作判断的准入是”阶段 5 已形成稳定主框架”，准出是”动作清单已锁定且历史卡片已正式扫描”），相当于工作流里加检查点，每个节点完成后要”盖章”才能放行。核心洞察：“给 AI 写流程，最难的不是告诉它做什么，而是拦住它不做什么”，能力越强漂移的破坏力越大。

  7. CLAUDE.md 是”行为宪法”，给每次新会话植入记忆：每次新会话 LLM 对项目一无所知，CLAUDE.md 是 Claude Code 启动时自动读取的项目指令文件（“创造知识库工厂的加工厂的厂规”）。作者的 CLAUDE.md 包含五块：项目定位（“由 LLM 协同维护的个人领域 wiki 系统”而非笔记收集系统）、系统结构（完整目录树+流转）、当前系统能力（3 脚本 4 Skill 各干什么）、规范和约束（frontmatter 最小字段集、知识卡片五种 type、状态流转规则、YAML 引号规则、禁区如”不能修改 Archives 原始文档、不能跳过校验直接产卡”）、当前知识库 Dashboard（统计数据+摘要，以最低成本让 Claude Code 了解基线）。它本身也在演进：第一版二十几行→高峰期大几百行→系统学习 Claude Code 的 memory 能力后精简到 100 多行（规则迁移到 .claude/rules、进展计划迁移到 ROADMAP.md，用 @ 引入）。

  8. 三层防线（作者称为”知识库自己的 Harness”）分层守质量：第一层脚本层守格式（validate_notes + batch_fix_notes，机器能查的不靠人眼）；第二层 Skill 层守结构（card-govern 治理孤儿卡、重复卡、主题结构失衡、frontmatter 合规，做了单卡/主题/增量/全库巡检四个模式，目前全库巡检 clean）；第三层 Dataview 层守全局（各主题卡片数量、最近新增、缺字段清单、未挂载主题页清单，每周扫一眼）。建设顺序是格式→结构→全局，因为格式问题最先暴露、结构问题卡片多了才出现、全局视角最后才需要。

  9. 搭建方法论：先手动跑通，痛点出现时再加能力：作者建议不要一上来就搭完整系统，先做最小闭环——装 Obsidian + Claude Code、建四个目录（Inbox/Processed/Review/Archives）、写一份 CLAUDE.md、手动处理三篇文章（处理→讨论→产卡），第一篇暴露问题、调整 CLAUDE.md、第二篇验证、第三篇看流程是否稳定，连续三篇跑得通最小闭环就成了。作者前十篇纯手动，第十篇后才写批处理脚本和蒸馏 deep-discuss，三四十张卡片才做治理 Skill。核心：“先手动跑通，痛点出现时再加能力，每次迭代都有真实需求驱动”。

实操内容保留

目录结构（按状态分 + 沉淀层按主题分）

当前 Vault 根目录/
├── 00 个人知识库工厂/
│   ├── 01 Inbox/              # 原始文章收集目录（主要来自 Obsidian Web Clipper）
│   ├── 02 Processed/          # 批量 AI 总结提炼后的结构化文章
│   ├── 03 Review/             # 被人工深度讨论后迁移过来的 Processed 文章
│   ├── 04 Archives/           # 被批量提炼的原始文章归档目录
│   ├── 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技术认知/

三层护栏脚本

  1. batch_ai_process：用 DeepSeek V4 Pro API 调用预设 Prompt，处理原文、生成结构化笔记、归档原文（migrate 移原文到 Archives、笔记进 Processed）
  2. validate_notes：校验笔记的元数据完整性（缺字段、callout 格式不对等）
  3. batch_fix_notes：自动修复校验发现的问题

结构化笔记固定输出结构：摘要、关键知识点、对产品经理的启发、金句摘录。

四个 Skill 及其职责

Skill解决的问题关键机制
deep-discuss单篇文章的人机深度讨论三层文件拆分、四种讨论模式、历史卡片扫描（UPDATE/EXTEND/LINK/NEW）、准入准出条件、Discussion Insights
topic-deep-discuss同主题多篇文章聚合讨论”双通道”机制：优先判断新内容能否补强现有主题域空白带，不能时再开新主题
card-govern知识网络结构退化治理识别孤儿卡、重复卡、主题结构失衡，四模式：单卡/主题/增量/全库巡检
kb-apply检验知识库能不能用起来用卡片网络写完整文章，写不出说明卡片网络有缺口（本文雏形就是 kb-apply 产出）

从零搭建最小闭环八步法

  1. 装 Obsidian + Claude Code
  2. 建四个目录：Inbox、Processed、Review、Archives
  3. 写一份 CLAUDE.md：告诉 LLM 目录结构、基本规则、它的角色
  4. 手动处理三篇文章，每篇做三步：
    • 处理：把原文丢给 Claude Code，让它按预设模板生成结构化笔记（摘要、关键知识点、对职业的启发、金句），不追求深度，格式统一即可
    • 讨论：拿结构化笔记做一轮对话，不是让它总结而是追问——“这个观点在我业务里成立吗？""和已有判断冲突吗？""如果边界条件不满足呢？“讨论中产生的新判断才是真正属于你的东西
    • 产卡：把最有价值结论提炼成知识卡片——一句话核心洞见、详细阐述、适用边界、应用场景。卡片不是文章摘要，是校准过的判断
  5. 第一篇暴露问题：哪里不顺手就记下来
  6. 调整 CLAUDE.md：把暴露的问题补成规则
  7. 第二篇验证调整：看规则是否生效
  8. 第三篇看流程是否稳定：连续三篇跑得通，最小闭环就成了

日常操作节奏

  • 碎片时间：看到好文章用 Web Clipper 存进 Inbox，不用想分类和格式
  • 攒到约十篇后：用 QuickAdd 宏跑三连脚本（批处理→校验→修复），几分钟；人肉扫一眼修复报告；原文自动归档、结构化笔记进 Processed
  • 找时间深度讨论：单篇高价值用 deep-discuss，同主题多篇用 topic-deep-discuss，讨论完自动产卡、笔记迁移 Review
  • 定期全局巡检：打开 Dataview 面板看各主题卡片分布、有无空白带需补充、有无治理提示
  • 偶尔写一篇：用 kb-apply 试知识库能不能支撑完整文章，写不出说明有缺口，写出来既是分享内容初稿又是健康度体检

关键概念

  • 目录即状态 — 用目录位置表达处理状态，不额外发明布尔字段
  • 脚本与大模型分工 — 脚本做确定性劳动，大模型只做语义理解，人做最终决断
  • 准入准出条件 — 在流程节点间加检查点治理 LLM 漂移
  • CLAUDE.md 项目指令 — Claude Code 项目指令文件，给每次新会话植入记忆的”行为宪法”
  • Harness闭环工程 — 作者把三层防线称为”知识库自己的 Harness”
  • 上下文漂移 — LLM 理解规则但不严格遵守、走着走着就偏了的失败模式
  • Skill — 深度讨论反向蒸馏出的可复用能力包
  • Claude Code — 整套系统的幕后本体（Obsidian 只是外在表现形式）

与其他素材的关联

  • 与 2026-05-28-woshipm-llm-wiki-qmd-architecture 高度互补：秋孝隱那篇讲用 qmd + bin/wiki CLI + CLAUDE.md 搭本地 LLM Wiki（“怎么建”的技术实现），本篇讲的是同一类系统的产品化演化史和方法论（为什么这样建、每个能力被什么痛点催生）。两篇都把 CLAUDE.md 定位为系统的”行为规范/宪法”，都强调”先跑通三篇文章再迭代”，都区分脚本（确定性）和 LLM（语义理解）的职责。
  • 与 2026-05-21-woshipm-ai-knowledge-base-product-design 形成”个人 vs 组织”视角对照：那篇讲把本地 RAG 升级为组织级云端知识库产品，本篇讲纯个人本地知识库的工程演化。
  • 与 Harness闭环工程 直接呼应：作者把”三层防线”明确称为”知识库自己的 Harness”，与该词条”校验器独立于生成器、安全围栏把边界写进系统、失败自动修复”的主张一脉相承。
  • 与 Skill 词条的”先跑通再封装""踩坑即沉淀""三层渐进式加载”多个观点直接印证：deep-discuss 的三层文件拆分对应”SKILL.md 主流程 + references/assets 按需”，四个 Skill 的演进对应”Skill 是长出来的不是设计出来的”。
  • 与 上下文漂移 的关系：那篇讲 AI 编程中错误假设累积的漂移，本篇讲 LLM 在长流程 Skill 中”走着走着就偏了”的执行漂移，都指向”用结构（Agent 隔离 / 准入准出条件）而非提示词约束”来治理。

原文精彩摘录

人工分类最大的敌人不是技术，是人性。

让脚本程序处理不需要人来介入的重复劳动，让大模型来负责语义理解和知识推理，把人的精力留给关键结果的最终决断上。

脚本的工作是让大模型按规矩交作业，不是替你思考。

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

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

不是先规划好三层防线再动手，而是每遇到一类新问题就补一层，逐渐培养出 Harness 的意识和手感。

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

相关页面

关系图谱

快速导航

反向链接