1 第一章 从文章到概念：为什么博客需要更底层的组织方式

在“为博客构建‘轻量级知识索引’”这个系列的文章中(相关内容参考：为博客构建“轻量级知识索引“)，我为博客增加了不少功能，例如首页的文章系列右侧菜单、文章页的相关分类右侧菜单、系列文章卡片、相关文章等。这些功能都是在现有博客的基础上不断完善阅读体验，希望让读者能够更方便地发现相关内容，也让那些发布时间较早但依然有价值的文章，不会随着时间推移逐渐被埋没。

但是，随着博客持续更新，我慢慢发现，无论是博客传统的“首页、分类、标签、搜索”，还是后来增加的“系列卡片、相关文章、右侧菜单”，本质上都仍然是在“文章”这一层进行优化——它们解决的问题始终是如何帮助读者找到更多文章，只是入口和展示方式有所不同。

这时候，我开始思考一个以前从未认真想过的问题：文章，真的是博客内容最合适的组织单位吗？

仔细思考之后，我发现答案可能是否定的：一篇文章只是某一次写作过程中形成的内容载体，而真正能够把不同文章连接起来的，往往不是文章本身，而是其中反复出现的那些概念。同一个概念可能出现在多篇不同的文章中，而一篇文章也往往同时包含多个不同的概念。

例如，博客中关于 Cloudflare 的内容，可能分别出现在 Tunnel 配置、CDN 优化、WAF 安全防护等不同文章中。如果按照文章浏览，访客看到的只是几篇独立的文章；但从内容本身来看，它们实际上都围绕着一些共同的概念展开。

然而，目前博客中的大多数组织方式仍然停留在文章层面。它们可以告诉读者哪些文章被认为相关，却无法进一步回答：这些文章为什么相关？它们之间是否存在一些反复出现的核心概念？

因此，我开始思考：如果希望从大量文章中发现那些反复出现、能够连接不同内容的核心概念，那么这些概念应该如何被识别和维护？如果没有明确的方法，最终得到的可能只是另一套不断变化的分类体系，而不是一个能够长期演化的结构。

这时候，我想起了以前曾经看到过的一个概念：知识图谱（Knowledge Graph）——如果能够把博客中多年积累的内容，不再简单按照文章列表展示，而是提取其中反复出现的重要知识点，形成一个可以探索的知识空间，或许会是一种更适合长期内容积累的方式。

例如，访客进入博客后，不一定需要先从某篇文章开始阅读，而是可以直接看到自己感兴趣的知识方向：“Cloudflare”、“家庭数据中心”、“AI”、“声音与音乐”……选择某个知识方向之后，可以进一步探索相关内容，并根据自己的需求选择适合深入阅读的文章。相比传统博客中的分类、标签和搜索，这种方式关注的不再只是“有哪些文章”，而是“这些文章背后的内容结构”。

当然，这只是粗略的想法，要想真正实现这样的目标，还需要解决很多基础问题，例如：哪些内容应该被认为是稳定的知识点？不同文章中的相同概念如何判断？这些知识点之间又应该如何建立联系？

如果完全依靠人工整理这些内容，不仅效率难以保证，也很难长期保持统一标准。这时候，AI 提供了一种新的可能。相比人工逐篇分析，AI 更适合处理大量文本，并能够帮助我们从文章中发现潜在的概念和关联。

但是，AI 能够理解文章内容，并不意味着它会自动形成适合长期维护的知识结构。例如，AI 对单篇文章的总结可以告诉我们“一篇文章讲了什么”，却无法直接回答：不同文章中的相同概念是否应该归为同一个知识点？这些知识点之间应该建立怎样的联系？

因此，真正需要解决的问题，并不是简单地让 AI 理解文章内容，而是探索一种能够从大量文章中识别共同概念，并进一步建立长期稳定内容结构的方法。

这也意味着，博客的信息组织方式需要从“文章索引”走向一种更底层的内容结构。

2 重新设计协作方式：让 AI 不再同时负责“创造”和“评价”

上一章最后提到：博客的信息组织方式需要从“文章索引”走向一种更底层的内容结构，那么，这个“更底层的内容结构”到底应该是什么样子？说实话，当时我自己也没有答案。

我只是隐约感觉，真正需要建立联系的已经不是文章，而是文章中反复出现的某些内容。但是，这些内容究竟应该如何定义？应该满足什么标准？彼此之间又应该如何建立联系？这些问题当时都还十分模糊。

按照以往的习惯，这时候通常就是 ChatGPT 发挥作用的时候了。我会先提出一个大致方向，然后让ChatGPT分析博客已有的文章，再通过大量来回讨论，不断发现问题、补充约束、调整结构，最后逐渐把“博客更底层的内容结构”这个模糊的念头，推导成一套识别博客中长期稳定内容对象的方法。

不过，在之前不少项目的实践中，我逐渐发现了一件事情：当同一个 AI 同时负责生成和审查一个目标内容时，很容易受到自己刚刚生成内容的影响。

这种现象其实并不只存在于 AI，人也是一样。例如，程序员自己写完一段代码，再立刻自己 Review，往往更容易关注实现细节，而忽略整体设计上的问题；而换一个人来 Review，由于没有参与最初的实现过程，反而更容易发现隐藏的问题。

AI 也存在类似的情况：它刚刚生成了一套方案，在随后的审查过程中，很容易沿着自己已经形成的思路继续修补，而不是重新审视最初的设计是否合理。最终得到的，往往只是一个越来越完善的初版，而不是不断逼近更合理结构的演化过程。

另一方面，还有一个比较现实的问题。由于我一直使用的是 ChatGPT Free 套餐，在完成这种需要阅读大量内容且需要来回讨论的任务时，很快就会耗尽高级模型的使用额度。虽然切换到基础模型之后依然能够继续完成任务，但随着推理能力变化，整个讨论过程的效率和稳定性也会受到一定影响。

这些原因放在一起，让我开始思考：为了解决这个博客内容组织问题，是不是可以重新设计人与 AI 的协作方式，而不是仍然让一个模型承担所有工作？

最终，我决定把整个过程拆分成三个不同的角色。

我
│
├── 决定目标
├── 最终决策
├── 冻结设计边界
└── 提供人类判断（例如："这里的感觉不太对"）

        ↓

ChatGPT（架构设计 + Review）
│
├── 推导整体结构
├── 保持整体一致性
├── 控制演化方向
└── 审查每一次修改

        ↓

其他模型（本次是选择的 Qwen）（探索与实施）

│
├── 阅读本地知识库
├── 执行具体分析任务
├── 生成候选结构
├── 根据反馈持续迭代
└── 输出整理后的结果

这里最大的变化，并不是把 ChatGPT 换成了 Qwen，而是让两个模型承担了不同的职责。

ChatGPT 不再负责大量具体内容的分析或者生成，而是把更多精力放在整体架构、设计约束以及每一轮迭代的审查上；Qwen 则负责根据已经确定的规则，对具体内容进行分析、整理和修改。

与此同时，由于 Qwen 部署在本地的 Chatbox 中，并且可以直接访问提前建立好的包含所有博客文章的知识库，因此每次分析文档时，都能够快速读取相关内容，而不需要反复将大量文章重新发送给模型。这既减少了 Token 消耗，也让整个迭代过程更加流畅。

使用Chatbox搭建本地知识库的操作细节可以参考文章：使用Ollama自建嵌入模型 + Chatbox 知识库实战，其中的embedding模型请根据自己实际需求选取，比如，我现在用的是本地m4pro macmini上基于Ollama搭建的Qwen3-embedding:8b。

不过，相对于直接在知识库中导入所有博客文章，我现在其实更推荐先使用脚本(脚本内容可以参考文章：为博客构建“轻量级知识索引”（二）：JSON 结构与生成脚本的实现)从WordPress中以API形式将博客中所有文章导出成一个JSON文件，然后对该JSON文件进行格式清理并输出成一个md格式的文件，再导入到Chatbox的本地知识库，因为可以包含id、title、url的信息，这样和Qwen在讨论某一篇具体文章时更好定位。

我最终导入Chatbox知识库的文件是knowledge-corpus.md，其中文章的存放格式如下：

更重要的是，这种分工带来了一个意想不到的效果。由于负责设计和负责执行的是两个不同的模型，ChatGPT 在 Review 时，不再需要面对自己刚刚生成的内容，而是像审查别人提交的方案一样，更容易从整体结构和一致性的角度发现问题。

整个过程开始越来越像软件开发中的团队协作：人负责确定目标和最终决策；ChatGPT 更像架构师和 Reviewer，负责提出方向、建立约束并审查演化过程；Qwen 则更像研究助理和实施者，负责基于已有规则分析内容、生成中间结果，并根据反馈不断调整。

这种协作方式让整个探索过程能够持续进行下去：由于问题拆解、结构设计、具体分析和结果审查被分散到不同环节，每完成一轮迭代，我都可以重新审视已有结构，发现新的问题，再继续增加新的约束。整个过程并不是不断完善第一版方案，而是在一次次验证和修正中逐渐逼近一个更加稳定的结构。

随着讨论不断深入，我们关注的问题也发生了变化。最开始，我们讨论的是：“应该如何整理这些文章？”后来，这个问题逐渐演化成了另一个更加基础的问题：文章中，到底什么才是那个值得长期维护的最小单位？

3 提取出了很多 Concept，但哪些才是真正值得保留的知识？

上一章最后留下了一个问题：文章中，到底什么才是那个值得长期维护的最小单位？

最开始，我想到的方式很直接：让 Qwen 分析整个博客，从文章中提取那些长期稳定、可以独立存在的 Concept，但第一次结果很快暴露出了新的问题。例如：

Docker
容器化
Cloudflare
Redis
Embedding
向量数据库

这些内容看起来都符合最初设定的要求：有明确名称，可以独立解释，也不会随着某篇文章变化而消失。但是，当真正尝试把这些 Concept 用于长期维护时，第一个问题出现了：同一个概念，可能存在不同表达方式。 例如：

Docker
容器化
容器部署

这些名称虽然不同，但实际上描述的是同一个核心概念。类似的还有：

文本 Embedding
Embedding 技术
Embedding 模型

以及：

SSL 证书
SSL 证书管理

如果不进行统一，同一个概念会因为表达方式不同，被重复记录成多个节点。因此，第一步需要解决的问题是：让同一个知识概念只保留一个稳定名称。

为了让 Qwen 理解什么样的内容应该成为 Concept，当时我设计了一套分析原则：

⸻

分析原则

不要关注：

- 文章标题
- 分类
- 发布时间
- 写作顺序
- 系列文章

这些都不是长期稳定的信息。

请关注：

- 长期存在的知识对象
- 知识之间的关系
- 可以独立学习的知识单元
- 可以作为知识地图节点的概念

⸻

概念要求

每一个 Concept 应满足：

1. 可以独立命名
2. 可以独立学习
3. 可以拥有自己的说明
4. 可以拥有多篇相关文章
5. 五年后名称仍然基本成立

例如：

Embedding  
Transformer  
RAG  
向量数据库  
Cloudflare Tunnel

而不要提取：

章节标题 
实践过程 
某次操作步骤  
经验总结

这些属于文章叙述结构或具体经历，而不是需要长期维护的知识对象。

⸻

概念统一

请主动进行概念归一。

例如：

Embedding  
不要同时出现：  
文本Embedding  
Embedding技术  
Embedding模型

统一保留：

Embedding

再例如：

系统思维  
不要同时出现：  
系统观  
系统思想  
系统分析

如果表达的是同一个核心概念，请统一名称。

同时请列出：

Concept：  
Embedding  
曾出现过：  
文本Embedding  
Embedding技术  
Embedding模型  
建议统一：  
Embedding

⸻

按照这个目标，Qwen 开始分析整个博客中的文章，并尝试建立第一版Concept Dictionary(博客概念词典)，以下是部分结果：

名称统一之后，看起来问题已经解决了一部分。但是继续观察这份列表时，又出现了一个更深层的问题：即使所有名称都已经统一，这些 Concept 放在一起依然不协调。

原因在于：我们虽然解决了“叫什么”，但没有解决“它到底是什么”。例如：

Cloudflare
Cloudflare Tunnel
内网穿透
Zero Trust
家庭服务器

这些内容都可能出现在相关文章中，但它们实际上代表完全不同性质的东西：

• Cloudflare 是一个服务平台
• Cloudflare Tunnel 是一种具体能力
• 内网穿透描述的是需要解决的问题
• Zero Trust 是一种安全架构理念
• 家庭服务器则是一种应用场景

如果把它们全部作为同一级别的 Concept 保存，那么得到的并不是一个稳定的知识结构，而是一份重新整理过的关键词列表。

这个过程让我逐渐发现：知识并不是一个扁平列表。同样被称为“概念”的内容，实际上可能来自完全不同的层面：有些是被发现的规律，有些是人为设计的方法，有些是具体实现工具，还有些是帮助人理解问题的思维方式。

如果不区分这些性质，只是简单统一名称并放在一起，那么最终得到的仍然只是一个规模更大的关键词集合，而不是一个真正可维护的知识结构。

因此，下一阶段我没有让 Qwen 继续增加新的 Concept，而是尝试进一步判断已有 Concept 本身的性质：

通过 Concept Typing(概念分类)，我们尝试回答另一个问题：这些 Concept 本身到底是什么？ 例如：

Redis        → Product（产品）
反向代理      → Technology（技术模式）
泛音         → Theory（理论）
约束工程      → Thinking（思想方法）

这个阶段最大的变化，是开始从“识别名称”转向“理解对象本身”。我们不再关注某个词是否经常出现在文章中，而是关注它在知识体系中承担什么角色。

例如：“Token”虽然是 AI 中的重要概念，但它更像语言模型运行过程中的基础单位；“知识地图”虽然是博客的重要设计，但它描述的是知识组织方式，而不是知识本身；“多拨”、“端口映射”等内容虽然具有实践价值，但高度依赖具体场景。这些内容都不是错误提取，而是不适合作为同一种长期维护对象。

经过不断调整和验证，我逐渐发现：我们真正需要寻找的，并不是文章中的关键词，也不是更智能的标签，而是一种能够长期存在的内容对象——它应该能够独立存在；能够跨越不同文章重复出现；不会因为表达方式或应用场景变化而改变自身身份；并且能够成为其他知识建立关系的基础。

例如，有两篇文章，一篇介绍 Cloudflare Tunnel 的配置方法；另一篇讨论家庭服务器如何通过 Cloudflare Tunnel 暴露服务。两篇文章关注的问题不同，但它们最终指向的是同一个对象：Cloudflare Tunnel。

这里真正需要长期维护的，并不是某篇文章中的“配置方法”或者“部署方案”，而是 “Cloudflare Tunnel” 这个稳定存在的对象。

后来在进一步研究这个问题时，我才发现(其实是GPT忽然提出来的～)，原来还有一个专门研究这类问题的领域：知识工程（Knowledge Engineering）。知识工程关注的，就是如何把零散的信息转化为结构化的知识，并让这些知识中的对象、属性和关系能够被长期维护。

而在这个领域中，这类能够稳定存在、跨越不同表达方式保持身份一致的内容对象，被称为 Entity（实体）。Entity 关注的不是：“这个词在文章中出现了多少次”，而是：“不同文章中的表达，是否指向同一个稳定对象。”

搞了半天，我研究的东西别人几十年前就总结出来了～。

4 Concept 已经稳定了，为什么知识体系还是建不起来？

第三章最后，我们终于找到了一种真正值得长期维护的对象。当时我以为，只要不断完善这份 Concept Dictionary，整个知识体系也就完成了。

事实上，接下来很长一段时间，我们做的也正是这件事情：不断补充遗漏的 Concept，修正名称，调整分类，重新定义哪些内容应该保留、哪些内容应该删除。随着迭代不断进行，这份 Concept Dictionary 越来越完整，也越来越稳定。

但就在这时，一个新的问题出现了。它已经能够回答“博客里有哪些知识对象”，却依然回答不了“这个博客到底在讲什么”。

在让Qwen自查的时候， 它是这样形容的：

后来回头再看，这段话几乎准确描述了当时遇到的困境。例如，在 Concept Dictionary 中，我们已经拥有了这样一些稳定的对象：

Cloudflare Tunnel
家庭数据中心
约束工程

它们都是真实存在、长期稳定的内容对象。但是，仅仅拥有这些对象，并不能回答下面这些问题：

• 为什么家庭数据中心最终选择了 Cloudflare Tunnel？
• 为什么没有采用公网 IP 或端口映射？
• 「约束工程」这种思维，又是如何影响整个家庭数据中心架构设计的？

这些问题，Concept Dictionary 全部回答不了。因为它记录的是有什么，却没有记录它们为什么会联系在一起。

为了继续推进，我们最开始尝试过几种非常直觉的方法。

第一种，是根据文章中的共同出现情况建立联系。例如，Cloudflare Tunnel 和反向代理经常出现在同一篇文章里，于是就在它们之间画一条线。后来发现，这种方法几乎没有意义。一起出现，并不代表存在稳定的知识联系。

第二种，是利用语义相似度。既然 Embedding 可以计算两个对象之间的距离，那么距离越近，是不是就可以认为它们应该连接起来？实践证明，同样不行。语义相似只能说明它们讨论的内容比较接近，却无法说明这种接近究竟意味着什么。Docker 与 Podman 可以很相似，Cloudflare Tunnel 与 Zero Trust 也可能很相似，但这种相似，并不能说明它们之间到底是什么关系。

第三种更简单。直接画一条线，标记为”Related”。不过后来几乎第一时间就被放弃了，因为”相关”几乎可以表示任何关系。而能够表示任何关系，也就意味着什么都没有表达。

这时我们发现，这份 Concept Dictionary 已经很难再继续完善了，真正阻碍整个知识体系继续发展的，不再是对象本身，而是这些对象之间缺少一种能够长期维护的联系。

还是刚才那个例子，如果只是写：

Cloudflare Tunnel
↓
家庭数据中心

那么这条线几乎没有任何价值。因为它只能说明两个对象同时出现过，却无法说明它们之间到底是什么关系。

真正重要的是：我为什么会选择 Cloudflare Tunnel？

而只有回顾整个家庭数据中心系列文章后才会发现，这并不是一次简单的软件选型，而是在公网 IP、网络环境、维护成本等各种现实约束下，逐渐演化出来的一套解决方案。

在这个过程中，真正值得维护的，并不是“Cloudflare Tunnel 和家庭数据中心有关联”这个事实，而是其中隐藏的结构：

网络限制
   ↓
产生的问题
   ↓
架构选择
   ↓
技术实现
   ↓
最终应用

对应到具体知识对象中，它并不是一条简单的连线，而是多个具有明确含义的关系：

公网 IP 缺失
    ──导致──>
需要内网服务暴露方案

Cloudflare Tunnel
    ──实现──>
反向代理能力

家庭数据中心
    ──采用──>
Cloudflare Tunnel

只有明确这些连接分别代表什么，知识体系才能表达“为什么会这样”，而不仅仅记录“它们曾经一起出现过”。

直到这里，我才醒悟，之前维护的 Concept Dictionary，其实只是一份越来越完善的词典。而知识体系真正需要维护的，并不是对象本身，而是对象之间那些稳定、清晰、能够准确表达含义的连接。

在知识工程（Knowledge Engineering）中，这类具有明确语义、能够准确表达对象之间联系的连接，被称为 Relation（关系）。

它关注的已经不再是”有哪些对象”，而是”这些对象之间到底存在怎样的联系”。我当时最大的感受只有一句话：如果早点知道这个概念，之前又能少走不少弯路。

5 当知识结构越来越完整时，我为什么反而开始怀疑它？

经过前面几轮调整之后，整个知识体系已经越来越完整，Concept 已经完成了统一和分类，对象之间也建立起了各种联系。按照当时的想法，只要继续补充这些关系，这个博客的知识体系应该就可以逐渐完善了。

然而，在后续一次重新审视当前知识结构的过程中，Qwen 提出了一个让我完全没有想到的问题：

第一次看到这句话时，我愣了一下。明明前面几轮都进展得很顺利，为什么突然会冒出这样一个问题？后来继续往下看，我才意识到，它指出的是整个项目中一个极其隐蔽的问题——”行业最佳实践”伪装成底层逻辑：

Qwen 随后提出了一个让我几乎无法反驳的问题：如果把博客里的所有文章全部删掉，只保留这些对象和它们之间的关系，这张图是不是依然成立？ 答案是：依然成立。 而这意味着，这张网络描述的很可能是整个技术世界，而非这个博客。

这个时候，我意识到，前面建立起来的那些关系，真正的问题并不是它们是否正确。事实上，Qwen 给出的很多关系，从技术角度来看都没有问题。真正的问题在于：这些关系到底是谁建立的？

如果这些关系来自博客文章本身，那么它描述的是这个博客长期实践过程中形成的认知。但如果这些关系只是 Qwen 根据自己的知识自动补全出来，那么它描述的，其实只是整个行业普遍接受的技术常识。

这两者最大的区别在于：前者属于这个博客，而后者属于整个技术世界。例如，Qwen 很容易根据自己的知识推导出一套标准的技术路线。可是真正回到文章环境之后就会发现，很多时候我真正关注的并不是行业里的标准方案，而是在特定约束条件下，为什么最终会选择另一条完全不同的路线。

也就是说，文章真正保存下来的，并不仅仅是最后的结论，还有形成这个结论的整个思考过程。

直到此时，我才最终明白，我们真正需要维护的，已经不只是对象之间有没有关系。更重要的是：这些关系，到底有没有真实来自文章本身。

于是，从这一轮开始，我们讨论的问题也发生了变化。以前一直在问：两个对象之间有没有关系？
后来开始不断追问：凭什么建立这条关系？ 如果回答不了这个问题，那么这条关系即使技术上完全正确，也不能算作这个博客自己的知识。

只有能够重新回到具体文章，找到我当时为什么建立这条联系，这张知识网络才真正属于这个博客，而不会随着 Qwen 不断推理，慢慢演变成一张谁都适用的技术百科。

知识工程里早就考虑过这个问题。除了对象（Entity）和对象之间的关系（Relation）之外，很多知识工程实践都会进一步关注知识来源和依据(Evidence)。

Evidence 的作用，并不是证明这条关系在理论上是否正确，而是回答另一个更重要的问题：为什么可以建立这条关系？

只有当每一条连接都能够追溯到真实的文章内容时，这张知识网络才真正属于作者本人，而不会在 AI 一次又一次的推理过程中，逐渐变成一张谁都适用的技术百科。

6 定义知识体系的基础结构——knowledge-schema.md

当 Entity、Relation 和 Evidence 这些概念逐渐明确之后，下一个问题就是：如何把这些理解转化为一个可以长期维护的实际结构。

因为知识体系并不是一次性的整理结果，而是需要随着博客持续增长，所以我需要先定义它的基础结构。为此，我设计了 knowledge-schema.md，用于描述整个知识体系应该如何组织。它并不是简单规定几个字段，而是在回答一个更基础的问题：一个长期维护的知识体系，到底应该由哪些部分组成？

前面的几章其实已经逐渐明确了三个最核心的问题：博客中有哪些值得长期保存的知识对象；这些对象之间存在什么样的稳定联系；这些联系如何能够回溯到具体文章事实。这三个问题分别对应了 Entity、Relation 和 Evidence。

但是，当这些概念真正落地到一个长期维护的系统时，仅仅知道“有什么”和“如何关联”还不够，还需要进一步明确：这些信息应该如何组织？不同类型的信息之间应该如何划分职责？未来新的内容加入之后，应该如何扩展，而不是不断推翻重建？

因此，knowledge-schema.md 的作用，并不是定义某几个数据字段，而是为整个知识体系建立一个稳定的骨架。

最终，我为knowledge-schema.md定义了5层结构：

从这份结构可以看到，knowledge-schema.md 实际上规定的是不同信息之间的职责边界：Entity 负责保存稳定的知识对象，Relation 负责描述对象之间具有明确含义的连接，Evidence 负责记录这些对象和关系建立的事实依据。三者各自独立，又相互配合，共同构成知识体系的核心结构。

经过前面几轮实践验证，这三个核心层的职责已经基本稳定，因此在 schema 中标记为“已冻结”。这里的冻结并不是表示这些内容永远不会变化，而是表示它们的基本职责已经确定，后续扩展需要优先遵循已有边界，而不是反复修改基础定义。

这种分离非常重要，因为如果所有信息混合在一起，随着内容不断增加，知识体系最终很容易重新退化成另一种形式的标签集合：文章有哪些词；哪些词经常一起出现；哪些内容看起来相似——而这正是前面几章不断尝试解决的问题。

除了前三个基础层之外，knowledge-schema.md 中还预留了两个更高层的方向。

第一个是 Knowledge Edge Layer。它关注的不是知识对象本身，而是不同知识之间如何形成阅读路径。例如，一篇基础概念文章可能成为另一篇实践文章的前置知识，一个早期方案可能演化成后续架构的一部分。

第二个是 Topic Space。它关注的是当知识对象不断积累之后，如何从更高的层面观察整个知识体系的主题结构。

不过，这两个方向都建立在前三层稳定之后。因为只有先明确有哪些对象、对象之间如何连接，以及这些关系是否有依据，后续的知识导航和主题发现才具有可靠基础。

回头看，knowledge-schema.md 并不是一开始设计出来的一份技术规范，而是在前面几轮实践之后逐渐形成的结构总结。它最终固定下来的，并不是某几个字段，而是一套长期维护知识体系的基本原则：什么应该被保存；不同信息之间如何分工；新的知识如何进入系统；已有结构如何持续演化。

如果说前面的几章是在探索：如何从大量文章中发现一个人的知识体系，那么这一章解决的就是：如何让这个知识体系能够长期存在，并随着时间继续成长。

注：对knowledge-schema.md完整版内容感兴趣的朋友可以通过以下链接将文件另存到本地查看(需要支持md格式的阅读软件)：knowledge-schema.md。

7 后话：一次 AI 协作带来的意外收获

回看整个过程，最让我意外的并不是最终形成了 knowledge-schema.md，而是一个最初只是为了改善博客内容发现体验的问题，最后竟然演化成了一次关于个人知识结构的探索。

更有意思的是，这个过程并不是从某个既定方法开始，而是在不断解决实际问题的过程中，逐渐逼近一个成熟领域已有的思想。Entity、Relation、Evidence 这些概念，并不是一开始就被引入的理论框架，而是在面对“什么值得保存”、“知识之间如何连接”、“这些连接如何证明来源”等具体问题时自然出现的答案。

这也是这次探索最有价值的地方：它让我意识到，专业领域中的很多方法，并不一定只能从理论学习开始。有时候，一个真实的问题足够复杂，当人不断尝试解决它时，也可能逐渐走向已经被某个领域总结过的方法论。

而这次实践也再次验证了之前我关于”使用AI 进行认知协作”方面的一些思考：AI 的价值并不只是替代某个具体环节，而是在复杂认知任务中成为人的能力延伸(相关内容参考：AI时代的创作重构：从信息处理到认知协作)。

但这种延伸并不是简单依靠更强的模型能力，而是通过重新设计人与 AI 的协作方式，让不同角色承担不同类型的认知工作。AI 不是可以完全自主完成知识构建的系统，而是一种需要被引导、约束和组织的认知能力放大器。

这种分工的价值，并不只是增加了一个执行模型，而是让复杂任务中的不同认知环节可以被分别处理。在过去，一个 AI 往往需要同时完成方向判断和细节执行，容易在大量内容整理和反复修改中消耗推理能力。而在这种协作模式下，Qwen 可以专注于具体内容处理，ChatGPT 可以保持更高层次的结构审查，而人则负责提供真实经验和最终判断，使问题分析、方案设计、具体执行和结果评价这些原本混杂在一起的环节形成更清晰的分工。

这次探索表面上是在为博客构建一个更好的内容索引，但实际上也是一次关于 AI 如何协助人完成复杂认知工作的尝试。它让我看到，未来 AI 的价值可能不仅仅是替代某个具体环节，而是通过不同角色之间的协作，帮助个人完成过去通常需要专业团队才能完成的问题分析、结构设计和知识整理。

而知识管理，恰好是这种协作方式非常适合的场景。个人长期积累的知识，并不是简单的信息堆积，而是一个不断理解、判断和修正的过程。AI 可以帮助我们整理信息、发现关联并建立结构，但真正值得长期保存的，仍然是一个人在实践中形成的理解方式、判断过程以及认知路径。