过去几年里，我陆续撰写了多篇关于个人思考方法与认知模式的文章。当时参考了 Karpathy 的 LLM-Wiki 理念，尝试将这些内容提炼成一个结构化的个人知识管理系统。最初的版本在“萃取”环节确实表现不错——卡片、概念、方法论各自独立成文。然而，当它真正去回答新问题或创作新文章时，问题便暴露无遗：知识看似结构化，但 AI 拿到手后依然无法“组装”出完整的解决方案。

AI 能够复述我说过的话，却无法面对一个全新场景，将我的观点重新编排成一套量身定制的方案。这让我认识到，知识萃取仅仅是第一步，真正的挑战在于将知识转化为一套可被调用、可自由组装、并能自我迭代的认知操作系统。以下记录的是本轮重构的完整思路与实践。这既是阶段性的复盘总结，也希望对正在搭建个人知识体系的朋友有所启发。

一、起点回顾：第一版LLM-Wiki解决了什么，又遗留了什么

第一版的 LLM-Wiki 存放在 wiki/ 目录下，其核心结构借鉴了 Karpathy 的思路，主要完成了三项工作：为每篇原始文章生成知识卡片（cards 目录，共147篇）；抽象出领域内的关键概念（concepts 目录，共715个条目）；整理出针对不同问题的方法论（method 目录，共43个方法）。这一版最大的价值在于，将分散于500多篇原始文章中的隐性知识显性化了。当我回看时，无需再逐篇翻阅，可以直接从概念入口反向追溯原文。

不过，尝试将这个知识库喂给 AI，并让其基于这套素材回答新问题时，几个根本性的局限很快便显现出来。

第一，概念与实体未能有效区分。concepts 目录中既包含“第一性原理”这类思维方法，也包含“Cursor”、“腾讯 ima 知识库”这类工具产品，还有“马斯克”、“亚里士多德”这样的人物。它们在本质上是不同的——方法属于“做事流程”，实体则是“被使用的对象”。混为一谈，导致 AI 无法清晰辨别哪些是可调用的“动词”，哪些是可引用的“名词”。

第二，方法描述缺乏可执行规范。原先对每个方法的描述偏向于“是什么”，而非“怎么用”。一个完整的方法应当像一段流程：具备输入、处理步骤、输出以及过程中使用的工具。但在原版本中，这些维度通常散落在叙述中，AI 难以机械地按图索骥去执行。

第三，实体之间缺少层级结构。例如“AI 编程工具”与“Cursor”，在原版本中是两个平级的条目，但事实上前者是后者的父类。缺少父子层级，AI 在进行归类、检索和推理时，就缺乏一条自然的语义路径。

第四，也是最关键的——缺乏面向问题的组装机制。method 目录虽然定义了“如何进行深度思考”、“如何快速切入新领域”等场景化方法，但每个 method 内部仍是叙述性文字，未明确告知 AI：面对该场景，应按何种顺序、调用哪些概念、使用哪些工具，以及组装时的关键约束是什么。

简而言之，原版 wiki 是一座结构精良的“图书馆”，但并非能自动响应需求的“工厂”。

二、重构思路：从知识图谱到认知闭环操作系统

意识到这些问题后，我做出的第一个关键决策是：不在原 wiki/ 目录上小修小补，而是新建一个 wiki1/ 目录进行重构。原版的萃取成果作为事实依据保留下来，新版本只存储“结构、关系、组装规则”这类元信息，并通过 source: 字段反向指向原文。这样既保护了原有积累，也保证了新版本足够轻量，便于 AI 加载和理解。

重构的总体思路可浓缩为一句话：从静态知识图谱，升级为场景驱动的认知闭环操作系统。

整套知识库被重新拆分为三层架构，中间以一条 IPO 闭环贯穿。

最上层是场景层。这一层只关心“我要解决什么问题”。每个场景都对应一个真实的“How 类”问句——如何进行深度思考、如何快速切入新领域、如何复盘总结。场景层的核心字段并非知识本身，而是组装规则：面对这个场景，应分几个阶段处理，每个阶段调用哪些底层概念和实体，以及组装时遵循何种逻辑约束。

中间层是概念层。概念即“方法”，是动作。我进一步将概念拆分为两类：原子概念（meta-concepts）与组合概念（compose-concepts）。原子概念是不可拆分的最小方法单元，例如归纳、演绎、抽象、MECE 法则；组合概念则由若干原子概念串联而成，如深度思考、系统思考、批判性思考。这种拆分策略对应了软件工程中的“原子函数”与“组合函数”关系，是任何可复用系统的基础。

最下层是实体层。实体即“人事物”，是名词。工具、技术、产品、框架、模型、人物、组织——所有方法执行过程中需调用的“对象”，都收纳于此。实体允许最多三层父子结构，以反映现实中的分类关系。

而贯穿这三层的 IPO 闭环——输入（Input）、处理（Process）、输出（Output）——是让整套系统从“描述性知识”转变为“可执行规范”的关键。每个原子概念都被建模为一段流程：它需要何种输入、内部经过哪些步骤、产出什么结果、过程中使用了哪些实体作为工具。

这三层架构加上 IPO 闭环，使 AI 首次具备了“按场景调用方法、按方法调用工具、按工具产出结果”的端到端组装能力。

三、概念层重构：原子方法与组合方法的双层架构

概念层是本次重构投入精力最多的部分，因为它直接决定了 AI 组装时的“颗粒度”是否合适。

最终在 wiki1/ 中沉淀了 212 个原子概念和 232 个组合概念。区分两者的标准非常明确：原子概念必须拥有完整的 IPO 四元组，且不依赖其他概念组装；组合概念则必须包含至少两步分解，每一步都引用一个 meta 概念。

以“深度思考”这个组合概念为例。它本身并非一个原子动作——你无法直接“开始深度思考”。它实际上由“问题定义→第一性原理拆解→SBR 模型推演→因果链分析→结论复盘”这一连串原子动作组合而成。在 compose-concepts.yaml 中，通过 decomposition 字段串联这些步骤，每一步都明确指向一个 meta 概念，并说明“为何在此步骤需要它”。

而“第一性原理”作为一个原子概念，在 meta-concepts.yaml 中被建模为完整流程：输入是“待分析的复杂问题”；处理步骤包括“识别表面现象→剥离类比假设→追问底层不可再分要素→重新基于第一原理推导”；输出是“基于底层逻辑的解决方案”；过程中可能调用的工具实体包括 SBR 模型、归纳-演绎闭环等。

这种“原子-组合”双层设计带来的最大优势是复用性。同一个原子概念可被多个组合概念引用，同一组合概念又会被多个场景引用。未来新增场景时，绝大多数情况下只需重新编排已有概念，无需从零定义新方法。这意味着，知识库的边际扩展成本将随着积累不断降低——这是任何可持续生长体系都必备的特性。

四、实体层重构：把“人事物”从概念中独立出来

实体层的重构核心是做减法——将原本混在 concepts 中的“人事物”全部抽离，独立成 5 个 yaml 文件。分类依据是历史文章本身的四大主题：事物认知（87 个实体）、问题解决（44 个）、知识库与知识管理（33 个）、学习实践复盘（44 个），以及一个其他（54 个）兜底人物、底层技术和组织。

实体内部支持最多三层的父子结构。例如“AI 编程工具”是一个 level 1 实体，“Cursor”、“GitHub Copilot”、“Cline”是其 level 2 子实体，Cursor 下还可挂载具体的 Composer、Tab 补全等 level 3 子实体。三层是刻意设计的上限——超过三层意味着分类粒度过细，易使 AI 在导航时产生歧义。

实体间的语义关系被限制为 4 种最小集合：is_a（父子归属）、uses（使用）、depends_on（依赖）、related_to（一般关联）。最小集的好处在于判定逻辑足够清晰——AI 无需在“组合”、“涉及”、“涵盖”、“影响”等几十种关系间纠结，只需按“是否归属→是否调用→是否依赖→兜底关联”四步判断即可。实践证明，这 4 种关系已能覆盖绝大多数语义场景，而清晰可枚举的关系类型正是 AI 友好性的核心。

实体层独立出来的最大价值，是实现了方法与工具的解耦。未来出现新的 AI 编程工具——比如 Cursor 的某个竞品——只需在 entity-knowledge.yaml 中挂载一个新实体节点，所有调用“AI 编程”这一概念的场景都能自动受益，无需逐一修改概念定义。这正是软件工程中“中台”思想在知识体系上的复刻。

五、场景层：问题驱动的组装规则，让AI从理解走向执行

场景层是本次重构中最具突破性的设计。

传统的知识库——无论是 Notion、Obsidian 还是各类 AI 知识库产品——本质上以知识为中心：用户输入问题，系统检索最相关的几条知识返回。这种模式天花板较低，因为它假设“知识本身就是答案”，而实际上真正有价值的答案往往是若干知识的特定组合。

wiki1/ 的场景层彻底翻转了这个假设。目前沉淀了 43 个场景，每个都对应一个真实的工作问题。每个场景的 yaml 条目包含四个核心字段：trigger（触发条件）、goal（目标）、composition（分阶段组装规则）、related_scenarios（相邻场景）。

其中 composition 是最关键的字段。以“如何基于知识库进行文章写作”为例，其 composition 被拆分为七个 phase：输入解析→Method 匹配→问题分解→框架冻结→原文深挖→结构化写作→自检输出。每个 phase 下明确写出：此阶段使用哪些概念（concept://）、哪些实体（entity://），以及关键组装规则（rule）。

这种设计的精妙之处在于，将“专家经验”显性化为可执行的流程。AI 无需“理解我”才能写出像我的文章，只需严格按照场景的组装规则调用底层概念和实体，产出的结果就会天然符合方法论框架。这是一个从“理解驱动”到“组装驱动”的范式转变——前者依赖大模型本身的智能，后者依赖结构化规则的精度，后者更稳定、更可控、更可迭代。

更进一步，场景之间通过 related_scenarios 形成网状关联。当主场景未能完全覆盖用户问题时，AI 可沿相邻场景跳转检索，或将多个相近场景的 composition 组合使用。这使得整个场景层具备了类似生物组织的弹性。

六、自我迭代：让知识库在使用中持续生长

如果 wiki1/ 只是一个静态元模型，它仍只是一座更精致的图书馆。让它成为“操作系统”的最后一块拼图，是自我迭代机制。

我为这套系统配套撰写了一份 profile.md，作为 AI 的操作规程，定义了 7 步标准写作流水线：问题解析→场景匹配→概念组装→实体调取→原文深挖→结构化写作→yaml 反向校验。前 6 步是常规的检索组装动作，第 7 步才是这套系统的真正灵魂。

每次 AI 完成一篇文章后，必须强制执行一次反向检视：本次写作过程中，是否出现 yaml 中找不到的新场景？是否用到 yaml 中未定义的新概念？是否提及 yaml 中没有的新实体？发现了哪些新关系应补充进现有条目？是否存在死链——即引用了一个不存在的 id？所有发现都以 yaml 条目骨架的形式返回，由我决定是否合入主库。

这个机制使 wiki1/ 首次具备在使用中生长的能力。每一次回答新问题，都是对知识库的一次压力测试；每一次写作完成，都可能带来新的场景、概念或实体。一段时间后，知识库会从“我手动定义的样子”，逐渐演化为“被真实使用场景塑造的样子”——后者才是真正贴近实际需求的知识体系。

其背后的哲学并不复杂：任何可持续生长的系统，都必须包含一个反馈闭环。学习-实践-复盘是个体成长的闭环，PDCA 是组织管理的闭环，而场景-组装-校验则是知识库自身演化的闭环。

七、从知识库到认知操作系统：一些更深的启发

本轮重构完成后，有几个深刻的感受值得分享。这既是对自己的提醒，也希望对正在做个人知识管理的朋友有所启发。

第一，知识管理的终点不是知识图谱，而是认知组装能力。绝大多数人——包括过去的我——投入大量时间在“输入”和“整理”上，但真正决定知识价值的，是“调用”和“组装”。如果知识库无法在面对新问题时快速给出针对性组装方案，其价值便停留在“资料库”层级，远未达到“经验库”和“模式库”。

第二，结构化的本质是“颗粒度选择”。方法拆得太粗，AI 难以复用；拆得太细，又会陷入细节地狱。原子-组合的双层设计、实体的三层结构、关系的最小集——这些设计选择背后源于同一个判断：在足够精细以保证可执行性与足够抽象以保证可复用性之间，找到最优平衡点。这个平衡点并非一次性找到，而是在反复使用中不断校准的。

第三，AI 时代的个人核心竞争力，正在从“知识掌握”转向“知识结构化能力”。当 AI 可以快速获取任何公开知识时，你能为 AI 提供怎样的“私有结构化输入”，便成为差异化关键。将这套 wiki1/ 喂给 AI，本质上是将多年方法论积累，变成 AI 可调用的扩展插件。这才是个体在 AI 时代真正能构建的护城河——不是与 AI 比谁知道得多，而是将自己的隐性经验显性化、结构化、可调用化，让 AI 成为自身思维方式的放大器。

第四，真正的知识体系必须是活的。它必须能感知新问题、识别自身盲区、在反馈中生长。一个只增不减、只存不用的知识库，本质上与被遗忘的硬盘没有区别。

结语

回顾整个过程，从 raw 目录的原始文章，到 wiki/ 目录的知识萃取，再到 wiki1/ 目录的认知闭环——这三层迭代，本质上对应的正是“资料库 → 知识库 → 模式库”的演进路径。每一次迭代，知识的可用性都向前推进一大步：从“我能看”到“我能查”，再到“AI 能调用、能组装、能自我迭代”。

这套系统目前远谈不上完美。43 个场景显然未覆盖所有问题域，212 个原子概念也存在颗粒度不一致之处，实体间的关系网络还将随使用不断密化。但不必为这些不完美焦虑——正因为预留了 yaml 反向校验这条自我迭代通道，这套系统无需“被完成”，只需被使用。每一次使用，都是一次成长。

记录本轮重构，并非为了展示一个“最终答案”，而是想分享一种做事方式：面对再复杂的体系，只要找到正确的元模型、定义清晰的接口、保留自我迭代的反馈闭环，它就会自己长大。这也正是我想表达的核心信念——真正强大的不是知识本身，而是承载知识的那套结构。