1 Chapter 1 From Articles to Concepts: Why Blogs Need a Deeper Level of Organization

In the article series “Building a ‘Lightweight Knowledge Index’ for My Blog” (for related content, refer to:Building a “Lightweight Knowledge Index“ for My Blog“), I added quite a few features to the blog, such as the article series right-side menu on the homepage, the related categories right-side menu on the article page, series article cards, related articles, and so on. These features all continuously improve the reading experience on top of the existing blog, hoping to make it easier for readers to discover related content, and to prevent older but still valuable articles from being gradually buried over time.

However, as the blog continues to be updated, I have gradually realized that whether it is the traditional “homepage, categories, tags, search” of the blog, or the later added “series cards, related articles, right-side menus”, they are essentially still optimizing at the “article” level—the problem they solve is always how to help readers find more articles, only the entry points and display methods are different.

At this point, I began to think about a question I had never seriously considered before:Are articles really the most suitable organizational unit for blog content?

After careful consideration, I found that the answer might be no: an article is just a content carrier formed during a specific writing process, whereas what truly connects different articles is often not the articles themselves, but the concepts that repeatedly appear within them. The same concept may appear in multiple different articles, and a single article often contains multiple different concepts at the same time.

For example, content about Cloudflare on the blog might appear in different articles such as Tunnel configuration, CDN optimization, and WAF security protection. If browsing by article, visitors only see a few independent articles; but looking at the content itself, they actually revolve around some common concepts.

However, most organizational methods in blogs currently still remain at the article level. They can tell readers which articles are considered related, but they cannot further answer: why are these articles related? Are there some recurring core concepts between them?

Therefore, I began to think: if we want to discover those recurring core concepts that can connect different content from a large number of articles, how should these concepts be identified and maintained? Without a clear method, what we end up with might just be another constantly changing classification system, rather than a structure that can evolve over the long term.

At this moment, I recalled a concept I had seen before:Knowledge Graph—If we could stop simply displaying the content accumulated over the years in the blog as a list of articles, and instead extract the recurring key knowledge points to form an explorable knowledge space, it might be a more suitable way for long-term content accumulation.

For example, when visitors enter the blog, they don't necessarily have to start reading from a specific article. Instead, they can directly see the knowledge directions they are interested in: “Cloudflare,” “Home Data Center,” “AI,” “Sound and Music”... After choosing a knowledge direction, they can further explore related content and select articles suitable for in-depth reading based on their needs. Compared to categories, tags, and search in traditional blogs, this approach no longer focuses just on “what articles are there,” but on “the content structure behind these articles.”

Of course, this is just a rough idea. To truly achieve such a goal, many fundamental problems still need to be solved, such as: what content should be considered stable knowledge points? How to identify the same concepts across different articles? And how should connections be established between these knowledge points?

If we rely entirely on manual organization of this content, not only is efficiency hard to guarantee, but it is also difficult to maintain a unified standard in the long run. This is where AI offers a new possibility. Compared to manual analysis article by article, AI is more suitable for processing large amounts of text and can help us discover potential concepts and associations from the articles.

However, the fact that AI can understand article content does not mean it will automatically form a knowledge structure suitable for long-term maintenance. For example, an AI's summary of a single article can tell us “what an article is about,” but it cannot directly answer: should the same concepts in different articles be classified as the same knowledge point? What kind of connections should be established between these knowledge points?

Therefore, the problem that truly needs to be solved is not simply letting AI understand article content, but exploring a method that can identify common concepts from a large number of articles and further establish a long-term, stable content structure.

This also means that the way information is organized in blogs needs to move from “article indexing” to a more underlying content structure.

2 Redesigning Collaboration: Stopping AI from Being Responsible for Both “Creation” and “Evaluation” at the Same Time”

The end of the previous chapter mentioned that the way information is organized in blogs needs to move from “article indexing” to a more underlying content structure. So, what exactly should this “more underlying content structure” look like? To be honest, I didn't have the answer myself at the time.

I just had a vague feeling that what truly needed to be connected was no longer the articles, but certain content that repeatedly appeared in them. However, how exactly should this content be defined? What standards should it meet? And how should they be connected to each other? These questions were still very vague at the time.

According to past habits, this is usually when ChatGPT comes into play. I would first propose a general direction, then let ChatGPT analyze the existing articles on the blog, and then, through a lot of back-and-forth discussion, continuously discover problems, add constraints, and adjust the structure. Finally, I would gradually deduce the vague idea of “the blog's more underlying content structure” into a set of methods for identifying long-term, stable content objects in the blog.

However, through the practice of many previous projects, I gradually discovered one thing:When the same AI is responsible for both generating and reviewing target content, it is easily influenced by the content it has just generated.

This phenomenon actually does not only exist in AI; the same is true for humans. For example, when programmers finish writing a piece of code and then immediately review it themselves, they tend to focus more on implementation details and ignore overall design issues. On the other hand, if someone else reviews it, because they were not involved in the initial implementation process, they are more likely to find hidden problems.

AI also has a similar situation: having just generated a solution, it is easy for it to continue patching along its already formed line of thought during the subsequent review process, rather than re-examining whether the initial design is reasonable. What is ultimately obtained is often just an increasingly polished first draft, rather than an evolutionary process that constantly approaches a more reasonable structure.

On the other hand, there is also a more practical problem. Since I have always been using the ChatGPT Free plan, when completing tasks that require reading a large amount of content and back-and-forth discussion, I quickly run out of usage limits for advanced models. Although I can still continue to complete tasks after switching to the basic model, as the reasoning ability changes, the efficiency and stability of the entire discussion process will also be affected to some extent.

Putting these reasons together made me start to think: to solve this blog content organization problem, is it possible to redesign the way humans and AI collaborate, instead of still letting a single model handle all the work?

Ultimately, I decided to split the entire process into three different roles.

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

        ↓

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

        ↓

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

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

│

├── Determine goals

├── Final decision-making

├── Freeze design boundariesBuilding a Self-Hosted Embedding Model with Ollama + Chatbox Knowledge Base in Practice└── Provide human judgment (e.g., "This doesn't feel quite right")

↓Building a “Lightweight Knowledge Index” for a Blog (Part 2): JSON Structure and Generation Script ImplementationChatGPT (Architecture Design + Review)

│

├── Derive overall structure

├── Maintain overall consistency

├── Control direction of evolution

As the discussion went deeper, the focus of our attention also changed. At the very beginning, we discussed: “How should we organize these articles?” Later, this question gradually evolved into another more fundamental question:In an article, what exactly is the minimum unit that is worth long-term maintenance?

3 Many Concepts Extracted, but Which Ones Are Truly Worth Keeping as Knowledge?

At the end of the previous chapter, a question was left:In an article, what exactly is the minimum unit that is worth long-term maintenance?

At first, the approach I thought of was very direct: let Qwen analyze the entire blog and extract those long-term stable, independently existing Concepts from the articles. However, the first results quickly exposed new problems. For example:

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

These contents all seemed to meet the initially set requirements: they had clear names, could be explained independently, and would not disappear as a certain article changed. However, when actually trying to use these Concepts for long-term maintenance, the first problem arose:The same concept may have different ways of expression. For example:

Docker
容器化
容器部署

Although these names are different, they actually describe the same core concept. Similarly, there are:

文本 Embedding
Embedding 技术
Embedding 模型

And:

SSL 证书
SSL 证书管理

If they are not unified, the same concept will be repeatedly recorded as multiple nodes due to different expressions. Therefore, the first problem to solve is:Keep only one stable name for the same knowledge concept.

In order to let Qwen understand what kind of content should become a Concept, I designed a set of analysis principles at that time:

⸻

分析原则

不要关注：

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

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

请关注：

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

⸻

概念要求

每一个 Concept 应满足：

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

例如：

Embedding  
Transformer  
RAG  
向量数据库  
Cloudflare Tunnel

而不要提取：

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

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

⸻

概念统一

请主动进行概念归一。

例如：

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

统一保留：

Embedding

再例如：

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

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

同时请列出：

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

⸻

Can be named independently

Can be learned independentlyCan have its own description

Can have multiple related articles

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

Following this goal, Qwen began to analyze the articles in the entire blog and tried to establish the first version of the Concept Dictionary (Blog Concept Dictionary). Below are some of the results:

• After the names were unified, it seemed that part of the problem had been solved. However, as I continued to observe this list, a deeper problem emerged:
• Even if all names have been unified, these Concepts still look discordant when put together.
• The reason is: although we solved "what it is called", we did not solve "what it actually is". For example:
• Cloudflare
• These contents may all appear in related articles, but they actually represent things of completely different natures:

Cloudflare is a service platform

Cloudflare Tunnel is a specific capability

Intranet penetration describes the problem that needs to be solved

Zero Trust is a security architecture concept

Home server is an application scenarioIf we save them all as Concepts at the same level, what we get is not a stable knowledge structure, but a reorganized list of keywords. For example:

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

If we do not distinguish these properties and simply unify the names and put them together, what we ultimately get is still just a larger collection of keywords, rather than a truly maintainable knowledge structure.

Therefore, in the next stage, instead of letting Qwen continue to add new Concepts, I tried to further determine the nature of the existing Concepts themselves:

Through Concept Typing, we tried to answer another question:

What exactly are these Concepts themselves?

Redis → Product

The biggest change in this stage was starting to shift from "identifying names" to "understanding the object itself." We no longer focused on whether a certain word frequently appeared in articles, but rather on what role it played in the knowledge system.

For example, although “Token” is an important concept in AI, it is more like a basic unit in the operation of language models; although “Knowledge Map” is an important design of the blog, it describes the way knowledge is organized, rather than the knowledge itself; although contents like "Multi-dialing" and "Port Mapping" have practical value, they are highly dependent on specific scenarios. These contents are not incorrectly extracted, but are simply not suitable as the same kind of long-term maintenance object.”

Through continuous adjustment and verification, I gradually discovered that what we really need to find is not keywords in articles, nor smarter tags, but a kind of content object that can exist for a long time—it should be able to exist independently; be able to appear repeatedly across different articles; not change its own identity due to changes in expression or application scenarios; and be able to become the foundation for establishing relationships with other knowledge.

4 Concepts Have Stabilized, So Why Can't the Knowledge System Be Built Yet?

For example, there are two articles: one introduces the configuration method of Cloudflare Tunnel; the other discusses how a home server exposes services through Cloudflare Tunnel. The two articles focus on different issues, but they ultimately point to the same object: Cloudflare Tunnel.

What really needs long-term maintenance here is not the "configuration method" or "deployment scheme" in a certain article, but the stably existing object "Cloudflare Tunnel".

Later, when researching this issue further, I discovered (actually, GPT suddenly brought it up~) that there is actually a field specifically studying this kind of problem: Knowledge Engineering. What Knowledge Engineering focuses on is how to transform scattered information into structured knowledge, and allow the objects, attributes, and relationships within this knowledge to be maintained over the long term.In this field, such content objects that can exist stably and maintain identity consistency across different expressions are called Entities. What an Entity focuses on is not “how many times this word appeared in the article”, but “whether the expressions in different articles point to the same stable object.”

When I had Qwen perform a self-check, this is how it described it:

Looking back later, this statement almost accurately described the dilemma we faced at the time. For example, in the Concept Dictionary, we already had stable objects like these:

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

Home Data Center

• Why did the home data center ultimately choose Cloudflare Tunnel?
• Why was public IP or port mapping not adopted?
• How did the thinking of "constraint engineering" affect the architectural design of the entire home data center?

These questions cannot be answered by the Concept Dictionary at all. Because what it records iswhat exists, but does not recordwhy they are connected together。

To move forward, we initially tried several very intuitive methods.

The first was to establish connections based on co-occurrence in the articles. For example, Cloudflare Tunnel and reverse proxy often appear in the same article, so we drew a line between them. Later, we found that this method was almost meaningless. Co-occurrence does not mean there is a stable knowledge connection.

The second was to use semantic similarity. Since Embeddings can calculate the distance between two objects, does a closer distance mean they should be connected? Practice proved that this also failed. Semantic similarity only shows that the content they discuss is close, but it cannot explain what this closeness actually means. Docker and Podman can be very similar, and Cloudflare Tunnel and Zero Trust can also be very similar, but this similarity does not explain what the relationship between them actually is.

The third was even simpler: just draw a line and label it ”Related”. However, this was abandoned almost immediately because ”related” can represent almost any relationship. And being able to represent any relationship means it expresses nothing at all.

At this point, we found that this Concept Dictionary was already very difficult to improve further. What was truly hindering the continued development of the entire knowledge system was no longer the objects themselves, but the lack of a long-term maintainable connection between these objects.

Taking the same example as before, if we just write:

Cloudflare Tunnel
↓
家庭数据中心

↓

Home Data Center

Then this line has almost no value. Because it only shows that two objects have appeared together, but cannot explain what the relationship between them actually is.

What is truly important is: why did I choose Cloudflare Tunnel?

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

In this process, what is truly worth maintaining is not the fact that "Cloudflare Tunnel is associated with home data centers," but the hidden structure within it:

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

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

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

↓

Problems Arising

↓ Relation。

Architectural Choice↓

5 As the Knowledge Structure Becomes More Complete, Why Do I Start Doubting It Instead?

Technical Implementation

↓

Final Application

Corresponding to specific knowledge objects, it is not a simple line, but multiple relationships with clear meanings:Lack of Public IP ──leads to──>Need for Intranet Service Exposure Solution Cloudflare Tunnel

──implements──>Reverse Proxy Capability

Home Data Center

──adopts──>

Cloudflare TunnelOnly by clarifying what each of these connections represents can the knowledge system express "why it is so," rather than just recording that "they once appeared together."

Only at this point did I realize that the Concept Dictionary I had been maintaining was actually just an increasingly complete dictionary. What the knowledge system truly needs to maintain is not the objects themselves, but those stable, clear connections between objects that can accurately express meaning.In Knowledge Engineering, these types of connections that have clear semantics and can accurately express the relationships between objects are called

It is no longer concerned with "what objects exist," but rather "what kind of relationships actually exist between these objects." My greatest feeling at the time was just one sentence:
If I had known this concept earlier, I could have avoided many detours.After the previous rounds of adjustments, the entire knowledge system has become more and more complete. Concepts have been unified and classified, and various relationships have been established between objects. According to the thinking at the time, as long as we continued to supplement these relationships, the knowledge system of this blog should gradually become complete. However, during a subsequent re-examination of the current knowledge structure, Qwen raised a question that I completely did not expect:

When I first saw this sentence, I was stunned. Clearly, the previous rounds had been progressing very smoothly, so why did such a question suddenly pop up? As I continued reading, I realized that it pointed out an extremely hidden problem in the entire project—"industry best practices" masquerading as underlying logic:

Qwen then raised a question that I could hardly refute:

If all the articles in the blog were deleted, leaving only these objects and the relationships between them, would this graph still hold true?The answer is:

Only when every connection can be traced back to actual article content does this knowledge network truly belong to the author themselves, rather than gradually turning into a generic technical encyclopedia applicable to anyone through repeated AI reasoning.

6 Defining the Foundational Structure of the Knowledge System—knowledge-schema.md

Once the concepts of Entity, Relation, and Evidence gradually become clear, the next question is: how to transform these understandings into a practical structure that can be maintained over the long term.

Because a knowledge system is not a one-time organization effort but needs to grow continuously alongside the blog, I first needed to define its foundational structure. To this end, I designed knowledge-schema.md, which is used to describe how the entire knowledge system should be organized. It does not simply define a few fields, but rather answers a more fundamental question:What parts should a long-term maintained knowledge system actually consist of?

The previous chapters have actually gradually clarified three core questions: what knowledge objects in the blog are worth preserving long-term; what stable connections exist between these objects; and how these connections can be traced back to specific article facts. These three questions correspond to Entity, Relation, and Evidence, respectively.

However, when these concepts are actually implemented in a long-term maintained system, merely knowing “what exists” and “how they connect” is not enough. It is also necessary to further clarify: how should this information be organized? How should responsibilities be divided among different types of information? How should it expand when new content is added in the future, rather than constantly being torn down and rebuilt?

Therefore,knowledge-schema.md Its role is not to define a few data fields, but to establish a stable skeleton for the entire knowledge system.

Ultimately, I defined a 5-layer structure for knowledge-schema.md:

From this structure, we can see thatknowledge-schema.md it actually defines the boundaries of responsibility between different types of information: Entity is responsible for preserving stable knowledge objects, Relation is responsible for describing connections with clear meanings between objects, and Evidence is responsible for recording the factual basis upon which these objects and relations are established. The three are independent yet cooperate with each other, together forming the core structure of the knowledge system.

After several rounds of practical validation, the responsibilities of these three core layers have basically stabilized, and are therefore marked as “frozen” in the schema. "Frozen" here does not mean that these contents will never change, but rather that their basic responsibilities have been determined, and subsequent extensions must prioritize adhering to existing boundaries rather than repeatedly modifying fundamental definitions.

This separation is extremely important because if all information is mixed together, as content continues to increase, the knowledge system can easily degenerate back into another form of tag collection: what words are in the articles; which words often appear together; what content looks similar—which is precisely the problem the previous chapters have been trying to solve.

In addition to the first three foundational layers,knowledge-schema.md two higher-level directions are also reserved.

The first is the Knowledge Edge Layer. It focuses not on the knowledge objects themselves, but on how different pieces of knowledge form reading paths. For example, a foundational concept article might become prerequisite knowledge for another practical article, and an early solution might evolve into part of a subsequent architecture.

The second is Topic Space. It focuses on how to observe the thematic structure of the entire knowledge system from a higher level as knowledge objects continuously accumulate.

However, both of these directions are built upon the stability of the first three layers. This is because only by first clarifying what objects exist, how they connect, and whether these relationships have a factual basis, can subsequent knowledge navigation and topic discovery have a reliable foundation.

Looking back,knowledge-schema.md it was not a technical specification designed from the very beginning, but rather a structural summary that gradually took shape after the previous rounds of practice. What it ultimately solidified was not just a few fields, but a set of basic principles for maintaining a knowledge system over the long term: what should be preserved; how different information should divide labor; how new knowledge enters the system; and how existing structures continue to evolve.

If the previous chapters were exploring:how to discover a person's knowledge system from a large number of articles, then this chapter addresses:how to enable this knowledge system to exist long-term and continue to grow over time.

Note: Readers who are interested in theknowledge-schema.mdfull version can save the file locally via the following link to view it (requires reading software that supports the .md format):knowledge-schema.md。

7 Afterword: An Unexpected Harvest from AI Collaboration

Looking back at the entire process, what surprised me most was not the final creation of knowledge-schema.md, but how a problem initially aimed merely at improving the blog content discovery experience eventually evolved into an exploration of personal knowledge structure.

What is even more interesting is that this process did not start with a predetermined methodology, but rather gradually approached the existing ideas of a mature field through the continuous resolution of practical problems. Concepts like Entity, Relation, and Evidence were not theoretical frameworks introduced from the very beginning, but natural answers that emerged when facing specific questions such as “what is worth preserving,” “how is knowledge connected,” and “how do these connections prove their sources.”

This is also the most valuable aspect of this exploration: it made me realize that many methods in professional fields do not necessarily have to start with theoretical learning. Sometimes, a real-world problem is complex enough that as one continuously tries to solve it, they may gradually move toward a methodology already summarized by a certain field.

And this practice has once again validated some of my previous thoughts on ”using AI for cognitive collaboration”: the value of AI is not just to replace a specific step, but to become an extension of human capabilities in complex cognitive tasks (for related content, refer to:Creative Reconstruction in the AI Era: From Information Processing to Cognitive Collaboration)。

But this extension does not simply rely on stronger model capabilities, but rather on redesigning the way humans and AI collaborate, allowing different roles to undertake different types of cognitive work. AI is not a system that can construct knowledge completely autonomously, but a cognitive capability amplifier that needs to be guided, constrained, and organized.

The value of this division of labor is not just adding an execution model, but allowing different cognitive steps in complex tasks to be processed separately. In the past, a single AI often had to handle both direction judgment and detailed execution simultaneously, easily exhausting its reasoning capacity in massive content organization and repeated revisions. Under this collaborative model, Qwen can focus on specific content processing, ChatGPT can maintain higher-level structural review, and humans are responsible for providing real-world experience and final judgment, creating a clearer division of labor among steps that were originally mixed together, such as problem analysis, solution design, specific execution, and result evaluation.

On the surface, this exploration was about building a better content index for the blog, but in reality, it was also an attempt at how AI can assist humans in completing complex cognitive work. It showed me that the future value of AI may not just be replacing a specific step, but helping individuals complete problem analysis, structural design, and knowledge organization—tasks that usually required a professional team in the past—through collaboration among different roles.

And knowledge management happens to be a scenario perfectly suited for this collaborative approach. Personally accumulated knowledge over the long term is not a simple accumulation of information, but a continuous process of understanding, judgment, and correction. AI can help us organize information, discover connections, and establish structures, but what is truly worth preserving in the long run remains the way of understanding, the process of judgment, and the cognitive path formed by a person in practice.