The Last Note System

Or rather, a personal knowledge management system.

Motivation

Humans, books, LLMs, and search engines cannot guarantee simple, error-free answers. When you find yourself repeatedly searching for something you've already found once before, you realize you should record confirmed valid information to save your future self time.
This is the most direct motivation for taking notes. If your motivation is anything other than this, even "everyone else is doing it, so I will too," then you probably don't need it at all.
When you think you need something you don't actually need, someone will take advantage of the vulnerability. Don't let productivity peddlers take advantage.
Only when you have a legitimate motivation for taking notes, and the quantity of notes begins to grow to the point where a methodology is needed to organize them, does a note system have a reason to exist. Creating demand where there is none will only lead to unnecessary trouble.

Why Wiki is not suitable as a personal knowledge management system

People try to use wikis as knowledge management tools likely because they've seen the power of crowdsourced encyclopedias like Wikipedia. However, personal knowledge management differs greatly from public encyclopedia compilation, making this path dependence quite ineffective.
Most of the time, people use Wikipedia as readers, not authors. Even when people use Wikipedia as authors, they only write a few articles, not all articles within a domain, and certainly not with the goal of maintaining the entire Wikipedia. When an individual uses a wiki as a knowledge management tool, it's easy to underestimate the difficulty of maintaining it and overestimate their ability to do so.
In fact, Wikipedia is only truly successful in a few languages. Many Wikipedia articles are just translations of English articles and quickly fall behind their original versions. If maintaining knowledge after translating it from one language to another is so challenging, then creating an ideal encyclopedia requires immense effort.
The result of trying to use a wiki as a knowledge management tool is one of two outcomes:
  • Failure, concluding that this path is unfeasible.
  • Pretending to have a maintainable personal knowledge base, but not actually having one.

The Myth of Zettelkasten

If you haven't heard of Zettelkasten, you've avoided some detours. If you have heard of Zettelkasten, I probably learned about it earlier than you. When I had already written my own toolchain for the Zettelkasten method, the term had not yet been introduced to the Chinese world. And before the productivity peddlers pushing this method sprouted like mushrooms, I had already abandoned it.
People want a personal knowledge management solution that isn't cumbersome to operate and appears effective. The rediscovery of Zettelkasten happened to meet this demand, and the hype from productivity peddlers further created the illusion of productivity improvement for users.
When you look for reasons to support Zettelkasten, you'll find its inventor, Niklas Luhmann, and others who used this system and achieved success. Productivity peddlers tout the effects of Zettelkasten as if the achievements of Niklas Luhmann and others were entirely attributable to this note system.
It's not difficult to refute this narrative:
  • In the era when Zettelkasten users achieved success, information was not as overwhelming as it is today.
  • Before the information age, methods for organizing notes were very limited, and people had few choices. Zettelkasten was one such method, and independently inventing something similar was not very difficult.
  • Is it possible that people achieved success not because they used Zettelkasten, but because they had the ability? Those who used Zettelkasten but left no achievements are not recorded; this is an example of survivorship bias. Conversely, you'll realize how absurd this is: how many successful people never used Zettelkasten?
The most overestimated part of the entire Zettelkasten system is its most formalized aspects: small card-shaped notes and the network of links connecting them. Interestingly, these most overestimated parts are universally used to represent the Zettelkasten method because formalized things are easier to commercialize.
A formalized Zettelkasten is an atomized version of a Wiki, and it is also a personal knowledge management system that is even less maintainable. Due to its flat structure, its drawbacks become apparent when the number of notes reaches a certain scale.
For example, because you don't know where the boundary of a note's content should be, universal redundant content is scattered across multiple notes, thereby reducing the system's usability. Redundant content does not decrease just because links are established between notes; when a note has too many links, the system can become difficult to maintain because changes might trigger a cascade.
By using Zettelkasten, the cost you pay to quell chaos in the note system will far exceed the benefits you gain from it. You will get a beautiful network topology map of your notes, but this topology map, like other types of data visualization, is useless except for fostering the illusion of productivity.

Maintainable Note System

A note system is not planned; it grows. Only when your note system grows organically will it have enough resilience to cope with change and adapt to your needs, rather than the other way around.
To develop a note system, a maintainable note system is needed as a foundation for development. What does "maintainable" mean?

Retrievable

A maintainable note system is retrievable, and retrieval should be convenient.

Text Only

The requirement for retrievability forces notes to use text as the primary data, as this is the only data that can be accurately retrieved.
This means that if your notes are handwritten, or if they contain a large number of charts, media, or even interactive content, you will find it difficult to form a note system because retrieval is inconvenient. There are indeed some methods to make non-text data retrievable, but no matter how optimized these methods are, they ultimately only reach the starting line of text.
Plain Text
Your notes should preferably be plain text, not rich text.
The main advantage of plain text is that your note system will not be locked into a specific text editor, which will significantly make the note system more robust.
Furthermore, processing notes programmatically will be more convenient because text is a universal data type. For example, you can directly use ripgrep as the search engine for your note system.
Treat Notes as Writing
Note-taking software like Evernote cultivates a habit of relying on copy-pasting through browser plugins, but this scrapbook-style note-taking method is completely unsuitable for a retrievable note system. These features, which facilitate hoarding information, are partly designed to create the illusion of increased productivity for users, making users who previously didn't take notes believe they should use note-taking software. In reality, most of the hoarded information is often lost at sea, never to be seen again.
You should not hoard anything into your note system that has not been digested by your brain. Acts of verbatim copying, such as transcribing, should be considered pollution of the note system.
To make notes optimally retrievable, you should treat them as a form of writing:
  • Because you understand the knowledge, the knowledge you record is tailor-made for you and will only truly be useful when you forget it.
  • Because this is your writing, and writing is the output of intermediate results of thinking, this output conforms to your personal language habits, allowing you to retrieve this knowledge in the future.
In a few cases, there may be exceptions. For example, if you find a perfect piece of content, incredibly good, such that any form of adaptation would diminish its value, then it's worth entering it into your notes verbatim.
You can still have a scrapbook for archiving materials for future reference and citation; its format doesn't matter, just don't confuse it with your note system.

Readable

A maintainable note system is readable, and reading it should be effortless.
Clearly, how readable your notes are depends largely on how good your writing skills are. Those who are not confident in their writing need not worry; note writing doesn't require you to be a great writer. In fact, meeting a few points can greatly improve text readability.

Concise

If I had more time, I would have written a shorter letter. — Blaise Pascal
Conciseness is a common principle in English writing, but it obviously applies beyond English.
Your note writing should be brief and to the point. This makes your notes take less time to read and easier to edit.
Initially, you can aim for absolute conciseness—mechanically finding and deleting unnecessary components in sentences, such as removing all rhetoric, eliminating all repetition, etc. As your note system develops, you will understand your aesthetic comfort zone for note text readability, discerning how to be concise more wisely, and thus truly mastering this writing principle.

Include Context

Anyone who takes notes must have had this experience: not understanding what they wrote down. This is because when reading notes, one has already detached from the context in which the notes were recorded.
To make notes understandable in the future, it's necessary to consciously integrate essential contextual information during writing. Good notes are those that remain understandable even after leaving a field for several years and returning to it.
If you are not familiar enough with note writing, you will find it difficult to control how much context needs to be retained for your future self to understand. It's okay; you don't need to succeed on the first try. Since your note system is evolving, you can record as much context as possible when taking notes, and then edit it the next time you retrieve that content. Your future self will be clearer about which contexts are redundant than your past self who first wrote the note.

Judicious Formatting

You can do graphic design at the text level.
Consistent Style
Not only do programming language codes need to maintain a consistent coding style, so do markup languages. Even if you don't use a markup language but rich text, you need to maintain a consistent style.
Besides maintaining consistency, you also need to realize that some styles are clearly superior to others. Taking Markdown, a lightweight markup language with many dialects, as an example:
Level 1
==
Level 2
--
### Level 3
This is a [hyperlink](https://en.wikipedia.org/wiki/Hyperlink).

# Level 1
## Level 2
### Level 3
This is a [hyperlink].
[hyperlink]: https://en.wikipedia.org/wiki/Hyperlink
Although the rendering result is the same, the second source file is significantly better than the first.
Manual Line Breaks
Markup languages like Markdown require two line breaks to create a new paragraph. Not everyone knows how to utilize this feature of markup languages.
You should not write like this:
多年以后,面对行刑队,奥里雷亚诺·布恩迪亚上校将会回想起父亲带他去见识冰块的那个遥远的下午。那时的马孔多是一个二十户人家的村落,泥巴和芦苇盖成的屋子沿河岸排开,湍急的河水清澈见底,河床里卵石洁白光滑宛如史前巨蛋。世界新生伊始,许多事物还没有名字,提到的时候尚需用手指指点点。
Instead, you should write like this:
多年以后,面对行刑队,
奥里雷亚诺·布恩迪亚上校将会回想起父亲带他去见识冰块的那个遥远的下午。
那时的马孔多是一个二十户人家的村落,泥巴和芦苇盖成的屋子沿河岸排开,
湍急的河水清澈见底,河床里卵石洁白光滑宛如史前巨蛋。
世界新生伊始,许多事物还没有名字,提到的时候尚需用手指指点点。
Or like this:
多年以后,面对行刑队,
奥里雷亚诺·布恩迪亚上校将会回想起
父亲带他去见识冰块的那个遥远的下午。
那时的马孔多是一个二十户人家的村落,
泥巴和芦苇盖成的屋子沿河岸排开,
湍急的河水清澈见底,
河床里卵石洁白光滑宛如史前巨蛋。
世界新生伊始,
许多事物还没有名字,
提到的时候尚需用手指指点点。
A competent renderer should produce visually identical rendering results for the three source text styles above.
Compared to the first source text style, the latter two have these advantages:
  • Clearer text structure.
  • More friendly to text editors like Vim.
  • More friendly to text difference tools like diff.
Even if you don't use a text markup language with this characteristic, or if the renderer behaves incorrectly, adopting the latter two source text styles still has advantages because they are inherently easier to read than traditional compact formatting.
This practice of manual line breaking is very old, used by many writers, and has had several names throughout history. It was once called Ventilated Prose, later some called it Semantic Linefeeds. As I write this article, I found a website dedicated to it, calling it Semantic Line Breaks.
Good Hierarchical Structure
Notes need a good tree-like hierarchical structure that categorizes notes by content, with appropriate headings, bringing highly relevant topics closer together. This categorization doesn't need to be overly strict, but it should be practical enough, and the resistance to modification should be as minimal as possible. You will likely not achieve a good hierarchical structure on the first try; that's fine, the hierarchical structure will gradually improve through the maintenance of the note system.
Ideally, both the markup language and text editor you use should provide sufficient convenience for maintaining a tree-like hierarchical structure. For example, markup languages should allow trees to have infinite depth, but markup languages like Markdown, which primarily target HTML for rendering, only support 6 levels of depth, because HTML's smallest heading tag is h6. For example, text editors should support outline views and moving/indenting nodes within the tree, but most text editors only support expanding/collapsing nodes. This means that if you want perfect tree-like hierarchical editing support on plain text, you essentially only have Emacs' Org-Mode as an option, which prevents many people from experiencing the benefits of having notes with a good hierarchical structure.
The Significance of Hierarchical Structure
"What if a piece of content belongs to multiple topics simultaneously?"This is a very common question when organizing a tree-like hierarchical structure, and without answering it, the note system cannot continue to develop.
If your note system is retrievable, this question becomes very unimportant, to the point where you don't need to solve it. Why? Because you don't truly navigate through the hierarchical structure to locate note content, but rather by retrieving keywords. Therefore, it's perfectly acceptable for a piece of content to belong to two topics simultaneously—placing it under either topic's node will not harm the note system's usability. If you're lucky, as your notes develop to a certain extent, related content may naturally evolve into its appropriate place, and the problem will resolve itself.
If you compare this retrieval-based solution with other solutions, you'll find it superior to all others—creating a tag system, creating hyperlinks, or dispersing content into multiple copies essentially adds to the maintenance burden of the note system, whereas the retrieval-based solution adds no burden at all, which makes the maintenance cost of such a note system significantly lower.
Even though the note system relies on retrieving keywords to locate note content, actively maintaining the hierarchical structure is still very meaningful:
  • It allows you to perceive the boundaries between topics when maintaining notes, thereby preventing content from straying and improving note readability.
  • The hierarchical structure can provide a higher perspective to observe the relationships between topics, aiding in systematically organizing knowledge.

Notes are not Articles

It must be pointed out that expecting a note system to become a tool for producing articles is unrealistic in itself; it's an incorrect expectation for a note system.
Articles and notes have huge differences in organizational structure and text style:
  • If you use the structure and style of an article for notes, the usability of the notes will decrease significantly.
  • If you use the structure and style of notes to write an article, the fluidity of the article will decrease significantly.
This determines that it's impossible to simply take notes and then suddenly harvest an article once the notes reach a certain critical point.
As for hoping to piece together notes into an article, like building with blocks—it's best to abandon this idea, unless your standards for an article are truly that low—so far, the closest approach to this goal is to feed your notes to an LLM and let it churn out an unreadable mess for you.