8.3
深览指数
成长人人都是产品经理·Sean··AI 生成
3 个脚本、4 个 Skill、3 层防线：我的 AI 知识库是怎么一步步长出来的
这是一篇个人知识库系统的工程实践复盘，而非理论指南。作者以半年的真实迭代历程，展示了如何从混乱的按主题分类，演进到一套由目录即状态、三步自动化预处理脚本、四个深度讨论 Skill 以及三层质量防线构成的协作系统。核心洞见在于：人工分类的敌人是人性，应用目录表达状态而非主题；脚本只负责格式压缩，深度理解留给人机协作的深度讨论；CLAUDE.md 作为项目行为宪法，为 LLM 每次会话植入记忆。文章提供了从零搭建的最小闭环步骤，强调“先手动跑通，痛点驱动迭代”，适合有知识管理需求的产品经理、技术爱好者或深度信息工作者阅读，用于获得一套可落地的实操框架，而非方法论空谈。原文 ↗
核心观点
- ▍知识库管理的核心不是技术实现，而是在每个真实痛点出现时做出正确的产品设计选择，如让目录表达状态而非主题，让脚本做压缩而把理解留给人，让 Skill 做流程协议约束 LLM 自由发挥。
- 01作者在 2025 年底首次尝试按主题分类（产品方法论、行业洞察等）后，因分类困难和人性的惰性导致该方案在第二周即告失败，推倒重来为按状态分类的流水线结构。
- 02目录按状态划分（Inbox/Processed/Review/Archives）后，作者发现无需额外布尔字段，因其本身即状态标识，且避免了字段与目录不一致的冲突。
- 03作者设计了三步自动化预处理脚本：batch_ai_process（压缩噪声、统一格式）、validate_notes（校验元数据）、batch_fix_notes（自动修复），每处理 8 篇文章约有 1 篇出现格式异常（如 AI 式回复“好的，我作为资深产品知识分析专家”）。
- 04deep-discuss Skill 经历了几十次迭代，包括结构上拆分超长 SKILL.md 为三层体系、讨论模式上增加批判性和双向模式、流程上强制加入历史卡片扫描以防重复产卡。
- 05LLM 在长流程中容易出现“漂移”跳过检查点，作者通过在每个节点加入准入准出条件（如阶段 6 的准入条件是阶段 5 已形成稳定主框架）有效解决了该问题。
- 06CLAUDE.md 从第一版的 20 多行（仅目录和基本规则）演进到高峰期的大几百行（涵盖项目定位、系统结构、能力、约束），后又精简到 100 多行，部分规则迁移至 .claude/rules 下。
- 07三层防线按问题暴露顺序建设：先有脚本校验解决格式问题，再有 card-govern Skill 解决结构问题，最后有 Dataview 视图提供全局决策视角，目前全库巡检结果为孤儿卡 0、重复卡 0、结构失衡 0。
反方 / 局限
- — 作者承认这套系统高度依赖 Claude Code 和 Obsidian 生态，对于不熟悉终端操作或命令行工具的用户，入门门槛较高。
- — 作者未明确讨论该知识库在团队协作或多机同步场景下的可用性与稳定性，当前设计偏向个人单机环境。
ObsidianClaude CodeDeepSeek APIQuickAddDataviewSKILL.mdCLAUDE.mdHarnessKarpathybatch_ai_processvalidate_notesbatch_fix_notescard-governkb-applyLLM Wiki
23 分钟 · 4 卡片 · 11 资料
读原文 →