2026-07-14-woshipm-hoarding-to-cultivation-cognitive-assets
@Sean 半年重构 Obsidian 知识库的复盘：知识库的核心本体不是知识集合而是”认知资产”，收集只解决”知识怎么进来”，真正稀缺的是”把外部信息淬炼成带个人判断、可持续演化的资产”；用 Inbox→Processed→Review 三层结构补上”理解”这一层，受 Karpathy 的 LLM Wiki 隐喻启发给 LLM 赋予批量引擎/对话伙伴/巡检员三重角色，并主张”别急着做 RAG，先让知识轻量级用起来”。
基本信息
- 来源类型：文章
- 原文位置：raw/articles/2026-07-14-110746-tg-42c5fd.md
- 原文 URL：https://www.woshipm.com/ai/6426767.html
- 作者：@Sean（人人都是产品经理）
- 阅读量：1278 浏览 / 2 收藏 / 20 分钟
- 发布日期：2026-07-08
- 消化日期：2026-07-14
核心观点
-
知识库的核心本体是”认知资产”而非知识集合：作者存了两百多篇好文章，但”没有一篇是我的”——收集只回答了”知识怎么进来”，没回答”知识怎么变成我的”。提炼出的原则是：个人知识库长期有价值的，不是收集了多少知识，而是能否把外部信息逐步淬炼成带有个人判断、可持续演化的认知资产。认知资产 vs 资料的区别在于：资料通用、谁都能搜到；认知资产经过你的经验、场景、失败和成功校准过，不可替代。目标从”存了多少篇文章”变成”沉淀了多少只有我理解和迁移后才能写出来的判断”。
-
批量处理之后缺了”理解”这一层，需加中间层 + 讨论机制：最初写脚本把文章批量处理成”摘要+知识点+启发+金句”的统一格式，跑了几个月几十篇后发现”这些只是大模型理解后的输出，不是我的”。批量处理降低了信息噪声，但跳过了最关键的”理解”。解法是把批量产物定义为 Processed 中间层（不是终点而是讨论输入），之后加入讨论机制——让 AI 扮演文章作者或第三方领域专家，来回追问、质疑、碰撞。同一篇 AI PM 能力迁移的文章，批量只产出 5 个知识点，一轮深度讨论却让作者得出”能力迁移的关键不是学新技能，而是重新定义旧技能在新场景下的表达方式”这个属于自己的判断。
-
用目录位置而非布尔字段表达工作流状态：三层结构 Inbox（待处理）→ Processed（待讨论）→ Review（已讨论），不额外加
discussed: true这种字段——“目录本身就是最高效的筛选器，状态语义也更清晰”。中间层看似”多了一步”，实为必要缓冲层：没有它会面临”原文噪声太大讨论效率低”和”讨论与沉淀不分开、单次理解直接污染主知识层”两个问题。 -
知识系统从”积累阶段”进入”治理阶段”的标志是结构问题出现：到 2026 年 4 月已有六十多张卡片，出现内容重叠、卡片相关却未连接、成簇卡片无主卡统领、新卡默认 NEW 旧卡不更新等问题。判断标志不是内容变多了，而是”结构问题开始出现，单纯新增已不能继续提升系统清晰度”。伴随三个认知：选题逻辑反转（文章驱动 → 主题驱动，看主题网络缺口在哪）、建立 Discussion Insights 机制沉淀”结论之外的高价值推理”、治理要深入网络结构层（有没有主卡、主支卡角色是否失衡、有无孤儿卡/重复卡）。
-
受 Karpathy 的 LLM Wiki 隐喻启发，给 LLM 赋予随工作流阶段变化的多角色：核心隐喻是”Obsidian 是 IDE，LLM 是程序员，wiki 是代码库”。LLM 在处理层是批量引擎（对应 Ingest）、讨论层是有知识储备的对话伙伴（AI 带教/相互 battle/批判质疑）、治理层是巡检员（扫描孤儿卡/重复卡/结构失衡，对应 Lint）。围绕三层角色形成收集→处理→讨论→沉淀→审视→治理→输出的七步闭环，每步都有 LLM 参与，但每步决策权都在人手上。还受 Karpathy”log 本身就是知识资产”启发建立了 Evolution Logs 机制，记录”什么变了、为什么这样定、放弃了什么方案”。
-
别急着做 RAG，知识先能轻量级用起来：顺序不能反——知识结构还在高频变动期（模板没稳、索引没成形、治理规则没固化）就急着向量化和 RAG，只会把不稳定结构放大，检索到的是格式不统一、边界不清、互相重叠的碎片。更基本的问题是”你的知识库被用起来了吗”，很多参考 LLM-wiki 方法论的库在收集沉淀后直接跳到”活体进化/自动化更新”，但系统没进入真实使用场景就无法暴露真实知识缺口，自动进化缺少反馈源。作者的做法是先用”知识应用 Skill”检验可用性——写一篇需要调用多个主题域、论据可追溯、叙事连贯的文章，写不出来就说明卡片网络有结构缺口，这个信号比任何自动化指标都直接。
实操内容保留
本文以方法论叙述为主，含一套可直接套用的日常七步闭环流程，无代码/Prompt 模板，保留流程步骤如下。
操作步骤：围绕三层角色的日常七步闭环
- 收集：每周定期抽时间阅读和筛选，好文章入池
- 处理：执行脚本三连（预处理→验证→修复），把原文变成结构化中间层（Processed）
- 讨论：与 AI 开启深度讨论，产出知识卡片和 Discussion Insights
- 沉淀：把讨论结果固化为知识卡片网络——最关键的动作不是新建卡片，而是先判断它应该 UPDATE（更新旧卡）、EXTEND（扩展子卡）、LINK（建立关联）还是 NEW（新建）。这套四分机制是防止知识库退化为流水账的核心规则
- 审视：通过 Obsidian 的 Dataview 视图全局扫描知识网络的健康度
- 治理：对异常指标运行治理 Skill，完成知识库修复
- 输出：运行知识应用 Skill，检验知识库能否支撑一篇逻辑连贯的文章，同时完成面向外部的知识输出
作者示例：把三篇 Agent 协作文章入池 → 跑脚本三连得 Processed → 一轮批判性讨论识别出与已有卡片相关的边界判断 → 做 LINK 而非 NEW 补主题缺口 → Dataview 面板扫一眼发现 RAG 主题域两张卡长期没更新 → 跑治理 Skill 确认正常。整轮约两小时。
关键概念
- 认知资产 — 本文核心本体：经个人经验/场景校准、不可替代、可持续演化的判断，区别于通用的”资料”
- LLM Wiki — Karpathy 提出的隐喻（Obsidian=IDE / LLM=程序员 / wiki=代码库），本文的方法论源头之一
- Obsidian — 作者选用的本地化知识库工具，看重本地数据自治权
- 目录即状态 — 用目录位置（Inbox/Processed/Review）表达工作流状态，不用布尔字段
- 知识卡片四分机制 — 沉淀时先判断 UPDATE / EXTEND / LINK / NEW，防止知识库退化为流水账
- 知识资产 — 组织级”经验→标准”的资产化命题，与本文个人级”认知资产”互补
- Skill — 深度讨论/主题治理/知识应用等能力包，承接脚本管不了的语义理解
与其他素材的关联
- 与 2026-07-11-woshipm-knowledge-base-engineering-practice 的关系：同一作者 @Sean 的姊妹篇。上一篇讲”怎么搭”（3 脚本 + 4 Skill + 3 层防线的工程实现与演化史），本篇讲”为什么这么搭”（认知资产的本体论 + 缺了理解层的反思 + 别急着做 RAG 的顺序判断）。两篇的目录状态设计、脚本与大模型分工、七步闭环、四分机制、三层治理完全一脉相承，可互为背景。
- 与 2026-05-28-woshipm-llm-wiki-qmd-architecture 的关系：两篇都以 Karpathy 的 LLM Wiki 为方法论源头，都强调 LLM 承接 Ingest/Lint 类重复维护、人负责判断；本篇更侧重”认知资产 vs 资料”的目标澄清与”先用起来再做 RAG”的克制。
- 与 知识资产 词条的关系：本文的”认知资产”是知识资产命题在个人层面的具体化——晏涛三寿等讲组织把金牌销售经验写进 SOP，本文讲个人把外部文章淬炼成只属于自己的判断，两者同源（隐性经验不显性化就会流失）。
原文精彩摘录
一篇讲企业 RAG 落地的文章，作者踩过坑、做过判断、形成了自己的框架。我把它存进我的 Obsidian，它只是一段文本。我读了一遍，草草记录几行笔记，它依然只是”作者的理解”，不是”我的判断”。只有当我拿着这篇文章里的方法，去对照自己负责的业务、对照自己做过的产品决策，在真实场景里校准过之后，它才开始带上我的印记。
我用目录位置而不是布尔字段来表达工作流状态。Inbox 里的就是待处理的，Processed 里的就是待讨论的，Review 里的就是已讨论的。不需要额外加 discussed: true 这种字段——目录本身就是最高效的筛选器，状态语义也更清晰。
Karpathy 说人类放弃 wiki 是因为维护成本增长得比价值快。LLM 解决了这个问题——它不嫌烦，不会忘记交叉引用，一次操作可以触及十五个文件。但 LLM 解决不了的，是你往知识库里注入什么判断、什么经验、什么偏好。这部分只能你自己来。
目标不应该定在”存更多笔记”上，而是定在”沉淀更多只属于自己的认知”上。前者是囤积，后者是经营。区别在于，前者越做越重，后者会因为知识复利而越做越值钱。