1 Why this blog exists

Actually, looking back at this blog now, I myself have an incredible feeling.

I have always considered myself a relatively lazy person. When it comes to website-building knowledge—like code, databases, and server configurations—I am basically completely clueless. Although I did mess around with quite a few things in the past due to work needs, such as Linux, Kubernetes, and OpenStack, those were mostly experiments and practices centered around a work environment. That is actually a completely different story from building and maintaining a personal website from scratch in the long run.

Of course, it's not that I had absolutely no interest in having my own website, but I have always known that starting a project from scratch is not the hard part; the real difficulty lies in continuously investing time and energy to maintain it afterward. Without a sufficiently clear reason, it is hard to keep doing something for the long haul.

The reason this blog came into existence in the first place is actually very simple: I realized that even though I had spent a lot of time researching things and successfully solving problems in the past, those experiences didn't really stick with me as time went on.

Often, when I encountered a similar need again, I only had a vague impression left in my mind. The specific implementation steps, key configurations, and my thought process at the time were hard to recall. Even worse, some of the reference articles I had bookmarked were no longer accessible years later, or had become impossible to find because the original site was shut down or the domain had changed.

Consequently, I had to search for information and figure out solutions all over again for problems I had already solved. After going through this cycle multiple times, I gradually realized that if these practical experiences only live in my memory or rely on volatile internet resources, they will eventually fade away. So I thought: since I will likely encounter these issues again, why not document the process?

At first, it was purely for my own future reference, like leaving a detailed memo for my future self. To my surprise, once I started writing, I found I had quite a lot to say. Many experiences that previously only existed in my head forced me to re-evaluate my logic when putting them into words, helping me understand *why* things worked, rather than just memorizing a few steps.

As I accumulated more and more notes, another idea struck me: since I've already organized all this stuff, why not just build a website and publish it? That way, I might even look like a total badass~~.

Of course, back then, I didn't even know what a personal blog really was, let alone WordPress. I had no idea how much goes on behind a website—from domains and servers to site structure, theme selection, plugins, code tweaks, and performance optimization. I had to figure everything out from scratch, researching as I went.

That period was a mix of pain and pleasure. I was dealing with things I had never touched before, learning and trial-and-erroring my way through. Fortunately, I survived the most grueling beginner phase. I went from knowing absolutely nothing about building websites to becoming a “semi-pro” who can independently maintain a personal site.

As the blog grew, I gradually realized that its purpose went beyond simply documenting steps. These scattered notes began to connect, showing me that documenting is not just about preserving the past, but also about constantly organizing and refining my own understanding.

Thus, what started as a personal log to “prevent forgetting” gradually evolved into a space for continuously documenting my learning, practice, and thinking.

And this is exactly why this blog has managed to keep going to this day.

2 The true direction of exploration for this blog

Many first-time visitors to this blog might wonder: why does this site cover Cloudflare, Docker, home data centers, and AI, alongside singing, vocal cognition, and even knowledge organization and cognitive methods? These topics seem to belong to completely different fields, making it hard to see any connection at first glance.

In fact, at the beginning, I didn't deliberately plan this content. Initially, I just recorded what I was tinkering with and learning at the time: researching whatever problems I encountered, and trying whatever I was interested in in life. As a result, the content of the blog also grew with my interests and practices, gradually taking the shape it has today.

But as the number of articles grew, I gradually realized that what truly attracted me was not actually any specific technology or hobby, but a common question that all these things pointed to:How an ordinary person can truly understand a complex system.

The ”complex system” mentioned here does not just refer to computer systems—it can be a home data center, a complete Cloudflare network architecture, how AI understands language, how the human body produces sound, or even a constantly growing knowledge organization system.

These things seem completely different on the surface, but once I started to delve deeper, I increasingly found that they all share a common trait: none of them can be truly mastered just by memorizing a few operational steps. Instead, they require a continuous understanding of why they were designed this way, how they work, and how their different components influence one another.

Because of this, when writing articles, I am usually not satisfied with just recording ”what to do in the end”—if it were just to get a copy-paste solution, there are already plenty of excellent articles on the internet to refer to. What I prefer to document is how a problem is understood step by step, and how a conclusion is derived. Even if the final solution changes with software updates, this process of understanding the problem is often far more valuable than those final few commands.

Therefore, many articles in this blog are slightly more ”wordy” than typical tutorials. I often spend a lot of space explaining why a problem occurs, what common misunderstandings existed before, why different solutions differ, and why I ultimately chose the current implementation.

For readers who just want to quickly complete a configuration, this style of writing might seem a bit roundabout; but for those who want to truly understand the underlying principles, this content is often the most valuable part to keep in the long run.

As the blog's content has grown over the years, the areas I focus on have also expanded, but the underlying way of thinking has remained unchanged. Whether it is home data centers, Cloudflare, AI, WordPress, or vocal cognition, these seemingly disparate fields are, at their core, different angles of observing how things work. What I truly want to document is how an ordinary person, through long-term practice and reflection, gradually forms their own understanding and crystallizes it into their own knowledge system.

Because of this, this blog is less of a technical blog and more of a long-term journal documenting a continuous process of learning, practice, and understanding.

And I hope that when I look back at these articles years from now, I will see not just what problems I solved back then, but more importantly, how I made my way to where I am today, step by step.

3 The evolution of the blog

On the surface, the evolution of this blog seems very simple: constantly writing articles and accumulating content.

But on a deeper level, this blog has actually gone through successive shifts in cognition.

Phase 1: From solving problems to documenting experience

The original purpose of starting this blog was actually very simple: to avoid having to retrace my steps.

The earliest content I recorded mostly came from real-world problems I encountered—such as how to deploy a certain service, how to configure a specific environment, how a problem was ultimately solved, and the pitfalls encountered along the way.

At this stage, the blog was more like a public personal technical notebook. The focus was not on whether the articles were complete or structured, but on preserving the problem-solving process as much as possible.

For many technical issues, the real value lies not just in the final commands executed, but in the analysis, judgment, and trade-offs made during the process. If these are not documented, years later, even if I remember “I've done this before,” it will be difficult to reconstruct my original train of thought.

So at this stage, the blog solved a fundamental problem: how to ensure that past experiences could be easily retrieved by my future self.

Phase 2: From documenting experience to understanding underlying patterns

随着记录的内容越来越多，我逐渐发现，单纯保存操作过程其实还不够，因为很多问题虽然发生在不同领域，但背后往往存在相似的规律。

For example, content such as architecture design in home data centers, Cloudflare-related network optimization, WordPress system modification, and AI knowledge index construction superficially belong to completely different fields, but after in-depth study, I often find that they all involve some common problems: How to understand a complex system? How to find the key factors affecting the results? How to design a more reliable solution under limited resources?

As a result, I began to no longer be satisfied with recording “how to do it”, but hoped to further record “why do it this way”. This also made the articles in the blog gradually change from simple operation tutorials into complete summaries containing background, principles, design ideas, and practical experience.

The blog began to slowly change from a “problem-solving record” to an “understanding process record”.

Phase Three: From knowledge accumulation to knowledge structuring

After the blog content kept increasing, I encountered new problems. When I first started recording these contents, I focused on a very simple goal: to be able to quickly find the solution at that time when encountering similar problems again in the future. As long as these experiences could be repositioned through search, classification, etc., it was already enough for me at that time.

But as the accumulation kept increasing, I gradually found that,Being able to find a specific answer does not mean truly understanding a field. This is because a technical field is not composed of isolated problems, but rather contains multiple interconnected layers: foundational concepts, practical solutions, optimization processes, and evolving approaches as technology develops.

If content is simply organized by publication date, categories, or tags, although this knowledge is preserved, the original relationships between them are not reflected. Visitors might be able to find the answer to a specific question, but it is difficult for them to know where this answer fits within the entire field, or what they should learn next.

This made me realize that the problem the blog needed to solve was no longer just “how to save more content,” but “how to structure the content that has already been saved.”

So, I began trying to reorganize the knowledge system within the blog: using knowledge maps to display the overall framework of different fields; using series of articles to organize the development process of continuous topics; and using content structure prompts to allow individual articles to link back to a larger knowledge system, while gradually exploring how to enable visitors to understand and learn this content along a certain path.

During this stage, the focus of the blog gradually shifted from “recording knowledge” to “organizing knowledge.” The blog also began to evolve from a simple collection of articles into a structured knowledge system.

Phase Four: From Structuring Knowledge to Exploring Knowledge Connections

Once the knowledge structure was gradually refined, I discovered another new problem. Even with organizational methods like categories, series, and knowledge maps, there were still many connections between contents that could not be expressed, because traditional information organization methods essentially rely on humans to define relationships in advance.

For example, an article about Cloudflare's network architecture, an article about AI Embedding, and an article about vocal resonance mechanisms would likely belong to completely different fields under traditional classification methods.

But if analyzed deeply, one might find that they are all discussing similar underlying questions: how to understand key variables in complex systems, how to establish more efficient ways of transmitting information, and how to improve final results by adjusting underlying mechanisms. These connections cannot be captured by simple categories and tags.

Therefore, I started trying to use AI-related technologies to further process the blog content, such as using Summaries to extract core information from articles, using Embeddings to convert articles into semantic representations where relationships can be calculated, building semantic indexes to establish new connections between articles, and exploring topic spaces to gradually reveal hidden connections between different fields.

At this stage, the blog was no longer just exploring “how to organize existing knowledge,” but further contemplating: how to discover relationships between knowledge that had previously gone unnoticed?

Now: A Continuously Evolving Personal Knowledge System

Looking back, the development process of this blog is actually the process of how my own understanding of knowledge has changed. So today's blog is no longer just an article publishing platform, nor is it just a set of personal technical notes. It is more like a constantly growing personal knowledge system: articles preserve specific practices, summaries extract the underlying patterns, knowledge maps organize the structure of fields, and AI semantic technology helps explore the hidden connections between different contents.

In the future, as content continues to accumulate, this system will also continue to evolve. Because what is truly valuable is not just how many articles are saved, but rather, through long-term practice, allowing this knowledge to continuously generate new understandings, new connections, and new possibilities.

4 The qualities I hope my articles possess

As the blog continued to develop, I slowly realized that what was truly changing was not just the content and structure of the blog, but also my own way of writing.

It was precisely through this continuous process of writing and practicing that I gradually formed several writing principles that I still adhere to today. These principles were not thought out from the very beginning, but were slowly shaped through repeated practice, writing, and the constant refinement of my understanding.

First of all, I hope that the practical content in the blog is all truly verified by myself.

Most of the articles in the blog involving deployment, configuration, and various practical experiences come from my own actual tinkering. Some solutions are even run in my own environment for a long time before being organized and published as articles. Doing this is not to prove anything, but because this blog itself is also written for my future self. If I haven't actually practiced it myself, then a few years from now, when I look back at this content, it won't have any reference value either.

Of course, software versions update and environments change, so many articles will be continuously supplemented and revised along with new practices. I do not strive to “write once and be forever correct,” but rather hope it can truly record my understanding and practice at different stages.

Secondly, I prefer to explain “why” rather than just “how.”

Many technical articles directly provide the final configuration, which of course can quickly solve the problem, but I always feel that what is truly easy to forget are often those specific operational steps, while what can truly stay with us for the long term is understanding the reasons behind these steps.

Therefore, in many articles, I spend a lot of space explaining why a technology emerged, what problems it solved, and how it gradually evolved into its current state. Sometimes, to explain a principle, I will even first introduce a lot of background knowledge that seems unrelated to the topic.

Writing this way is not to increase the length of the article, but rather to hope that once readers truly understand the underlying logic, even if software versions change in the future, they can rely on their own understanding to find new solutions, instead of mechanically following a tutorial step-by-step.

In addition, I also hope this blog can truly record my own process of understanding, rather than deliberately packaging myself as a “know-it-all.”

After many articles are published, I continue to modify, supplement, and even overturn some of my previous understandings. As I gain more practical experience, my understanding of the same problem constantly changes; I believe these changes themselves are a highly valuable part of the knowledge accumulation process.

Therefore, many articles here are not the final answer to a problem, but rather a continuously updated learning record. It records not only the final conclusion reached, but also how I arrived at that conclusion step by step.

Finally, I increasingly hope that these articles will become more valuable over time, rather than quickly becoming obsolete. Technology develops rapidly, and many specific configuration methods may be completely different in a few years. However, the reasons that truly drive technological development, the evolutionary relationships between different solutions, and the mindset formed when solving problems often endure much longer.

Therefore, when writing articles over the past year, I have begun to focus more and more on these aspects. I hope that even if a certain command changes or a piece of software is updated in the future, readers can still understand why the technology developed into what it is today through the article, and rely on this understanding to continue exploring new things.

This also why I hope to keep this blog going in the long run—it records not only what I have done, but more importantly, why I understand things the way I do.

5 My cognitive approach

If the previous sections explained why this blog exists, what it focuses on, and the characteristics I hope the articles will ultimately present, then there is a deeper question: why did these articles gradually develop into their current style?

The answer actually lies in the habits I have developed over a long time when facing problems. These habits were not deliberately designed from the start, but were gradually formed through continuous practice, learning, and reflection. As I have spent more time blogging, I have gradually realized that what truly interests me is not just the solution to a specific problem, but the underlying reasons, patterns, and the evolutionary process behind these problems.

I am used to understanding “why” first, rather than just remembering “how.”

Many technical problems ultimately manifest as specific operations: executing a few commands, modifying some configurations, deploying a service, or choosing a particular solution. These steps are, of course, very important because they help resolve the issue.

But for me, simply memorizing a few operational steps does not mean truly mastering the problem. As software versions and technical roadmaps change, methods that were once effective may gradually become obsolete. Without understanding the underlying reasons, it is easy to fall back into the cycle of constantly searching for answers.

So when writing articles, I usually try to dig deeper: Why did this problem occur? What limitations did this solution address? Why did new solutions emerge later?

Often, what is truly valuable is not those final lines of configuration, but knowing why it should be done this way after understanding the entire process.

I am used to understanding things through their evolutionary process

I increasingly feel that much knowledge does not exist in isolation; a technology, a tool, or a solution we see today is often the result of the continuous accumulation of certain past problems. For example, the development of Web technology, from early static pages to dynamic websites, and then to frontend-backend separation, server-side components, and various new rendering modes, is in essence not a simple replacement of technology, but rather a continuous process of solving problems encountered in the previous stage. Similar situations also exist in fields such as network architecture, storage technology, and artificial intelligence.

If we only focus on the final answer, it is easy to understand knowledge as a pile of scattered conclusions; but if we put it back into the process of development, we can see why it appeared and where it might continue to develop in the future.

Therefore, when writing articles, I usually pay more attention to the developmental logic behind a technology or concept, rather than just introducing what it is now.

I am used to looking for common structures between different fields

As I come into contact with more and more fields, I gradually find that behind many seemingly completely different problems, there actually exist some similar patterns. For example, knowledge organization in blogs, semantic vectors in AI, data transmission in networks, and architectural design in software systems superficially belong to different fields, but after in-depth analysis, they often involve similar problems: How is information organized? How is complexity reduced? How are connections established between different objects? How does a system continuously evolve as its scale grows?

It is also because of this that I later began to try building knowledge maps, learning paths, semantic indexes, and topic spaces. These attempts are not simply to add some features to the blog, but rather to explore a better way to allow originally scattered information to form a clearer structure.

I am used to letting practice drive understanding, rather than staying at theoretical learning

Many of my articles are not planned around a certain topic in advance and then compiled after systematic learning. More often, they stem from problems encountered in practice: generating a need → trying to solve it → encountering difficulties → searching for information → actual verification → summarizing experience.

This approach has a characteristic: it forces oneself to face various details in real environments. Many problems may look very simple if they only remain at the theoretical level; but once practice actually begins, one will find that there are a large number of hidden problems, and these problems are often the true entry point to understanding a technology.

So what this blog records is not simply the process of learning a certain knowledge point, but rather the process of continuously building understanding in real practice.

Looking back, these cognitive styles have actually influenced the development direction of this blog, because for a long-term personal blog, what can truly continue to generate value is perhaps not a specific answer, but rather the method that can still help oneself and others understand new problems in a constantly changing environment.

6 Author background and personal exploration

1 Technical experience and growth path

I have been working in IT-related fields for over twenty years, and my professional experience mainly revolves around network infrastructure, enterprise IT systems, technical solutions, and project implementation.

During the early stage (2002 – 2006), I worked at a large IT system integration enterprise, mainly responsible for network infrastructure construction. During this period, I worked with network products from multiple vendors such as Cisco, Juniper, Huawei, and H3C, accumulating a wealth of practical experience in network protocols, infrastructure, and actual operating environments, ranging from small and medium-sized network construction and device deployment to the planning and maintenance of more complex network environments.

Subsequently (2007 – 2011), I entered the leading domestic IT product general distribution system and began to come into contact with more vendor systems and enterprise customer scenarios. At this stage, my work gradually expanded from pure technical implementation to technical solution design, pre-sales technical communication, project delivery, and solution implementation, requiring me to understand and apply technology from multiple perspectives such as customer needs, product capabilities, technical architecture, and business scenarios. The experience during this stage also made me begin to gradually shift from “how to implement technology” to “why design technical solutions this way”.

After that (2012 – 2022), I joined an American application delivery vendor, mainly responsible for sales engineer-related work. During this stage, I stood more from the perspective of a technology product provider and solution designer, participating in enterprise-level technical exchanges, architecture analysis, and project support work. Long-term exposure to the actual needs of customers of different scales also made me further realize that technology is not an isolated tool, but a system closely integrated with business goals, application scenarios, and industry development.

These experiences at different stages have also constantly changed my understanding of technology: from initially focusing on device configuration, network connectivity, and specific implementation, to later focusing on enterprise needs, overall solutions, and the design concepts behind technology, my focus has gradually expanded from single technology implementation to the level of system architecture and technological evolution.

I gradually realized that technology is not just a set of tools or operating methods, but needs to be understood in combination with actual scenarios, changing needs, and industry development. What is truly worth paying attention to is not just how to use a certain technology, but why it appeared, what problems it solved, and why it continues to evolve with environmental changes.

In recent years, I have extended my years of IT practical experience to personal technical infrastructure construction, carrying out continuous exploration around home data centers, Cloudflare multi-node architecture, personal blog systems, knowledge management, and information organization methods in the AI era. In the process of these long-term practices, I tried to extend the technical experience and thinking methods accumulated in the past beyond work, and gradually settled them into my own technical system.

Therefore, for me, maintaining this blog is not to show how much technology I have mastered, but to record those practice-proven problem-solving processes, technical reflections, and long-term accumulated understanding. It is both convenient for future review and hopefully helpful to those who encounter similar problems.

2 Long-term interests beyond technology

In addition to technology, I also have two long-term interests that I persist in.

First, collecting, organizing, and managing film and television content.

This process seems like simple collecting, but in fact, it also requires long-term accumulation, continuous maintenance, and constant optimization of organization methods. From discovering new content, to establishing a classification system, to still being able to quickly find the resources needed years later, this process actually has many similarities with maintaining a blog.

Second, singing.

At first, it was just because I liked music, but with continuous practice and learning, I gradually discovered that the voice itself is also a system worth long-term exploration. From physical state and vocalization methods to auditory feedback and training methods, every link has its own laws behind it. This also made me realize more deeply that many things that seemingly rely on experience or talent on the surface can actually gradually build up one's own understanding through continuous practice and constant comprehension.

Technology, music, knowledge organization, and even some reflections on cognition and life written down later, seem to belong to completely different fields, but there is actually a common point behind them:Constantly exploring the laws of how things work, and trying to organize and settle these understandings.

Therefore, what this blog ultimately looks like is not a website that simply records technical articles, but a place that records my long-term learning, practice, and thinking process. Here, there is both technology and music; there is both knowledge organization and some exploration of cognition and life. Together, they form a part of my continuous recognition and understanding of the world.

7 Contact information

If you have any questions or suggestions about the content in the blog, or wish to exchange ideas on certain technology or knowledge-related topics, you can contact me through the following ways.

Email:

[email protected]

My Telegram Group:https://t.me/tangwudiblog