最後一個筆記系統
或者說個人知識管理系統。
動機
人類、書籍、LLM、搜尋引擎都不能保證帶給你簡單無誤的答案。當你重複尋找以前找到過一遍的東西時,你意識到應該把確認有效的資訊記下來,節省未來自己的時間。
這是筆記最直接的動機。如果你的動機是這以外的東西,甚至是「大家都在這麼做,所以我也這麼做」,那麼你可能根本不需要它。
當你以為自己需要實際並不需要的東西時,就會有人趁虛而入。不要讓生產力販子趁虛而入。
當你有了做筆記的正當動機,筆記的數量開始增長,以至於開始需要一個方法論來整理筆記時,筆記系統才有理由存在。沒有需求卻刻意製造需求,只會徒增煩惱而已。
為什麼 Wiki 不適合作為個人知識管理系統
人們之所以會嘗試把 Wiki 作為知識管理工具,很可能是因為從 Wikipedia 上看到了眾包百科全書的強大力量。但是,個人的知識管理與公共百科全書的編撰有很大差別,使這種路徑依賴變得相當無效。
絕大多數時候,人們都是在以讀者身份使用 Wikipedia,而非作者。即使人們在以作者身份使用 Wikipedia,也只是在編寫幾個條目而不是領域內的所有條目,更不會以維護整個 Wikipedia 為目標。當個人將 Wiki 作為知識管理工具時,很容易低估維護它的難度,高估個人維護它的能力。
實際上,Wikipedia 也只在幾個語言上比較成功。很多語言的 Wikipedia 條目都只是英語條目的翻譯,並且很快就會落後於其原始版本。如果將知識從一種語言翻譯到另一種語言後繼續維護都是如此艱難,那麼創造理想的百科全書則需要付出極大努力。
嘗試把 Wiki 作為知識管理工具的結果無外乎兩種:
- 失敗,認定這條路走不通。
- 假裝自己有一個能維護的個人知識庫,但實際上沒有。
Zettelkasten 的神話
如果你沒聽說過 Zettelkasten,那麼你少走了一些彎路。如果你聽說過 Zettelkasten,那麼我可能了解得比你早。當我已經為 Zettelkasten 方法編寫了自己的工具鏈的時候,這個詞都還沒有被引進中文世界。而在兜售該方法的生產力販子們還沒有像雨後春筍般出現的時候,我就已經放棄了它。
人們希望有一個操作起來不繁瑣,且看似有效的個人知識管理方案。Zettelkasten 的重新發現恰好切中這一需求,生產力販子的推波助瀾為使用者進一步製造取得生產力進步的幻覺。
當你尋找支持 Zettelkasten 的理由時,你會找到它的發明者 Niklas Luhmann 以及其他使用此系統並取得成就的人。生產力販子吹噓 Zettelkasten 的效果就好像 Niklas Luhmann 等人的成就全部歸功於這套筆記系統一樣。
要推翻這套敘事並不困難:
- 在 Zettelkasten 的使用者取得成就的年代,資訊不像現代這麼膨脹。
- 資訊化時代之前,整理筆記的方法非常有限,人們的選擇餘地不多。Zettelkasten 是其中一種方法,獨立發明出類似的東西也並不很困難。
- 有沒有可能人們取得成就不是因為他們使用了 Zettelkasten,而是因為他們有能力?使用 Zettelkasten 而沒有留下成就的人不會被記錄,這是倖存者偏差的一個例子。反過來看,你就會意識到這有多荒謬:有多少取得成就的人不曾使用 Zettelkasten?
整個 Zettelkasten 系統裡最被高估的部分是它最形式化的部分:小卡片形式的筆記,以及由連結組成的筆記網路。有趣的是,這些最被高估的部分被普遍用來代表 Zettelkasten 方法,因為形式化的東西更容易作為商品販賣。
遭到形式化的 Zettelkasten 是原子化版本的 Wiki,也是一個更缺乏可維護性的個人知識管理系統。由於採用了扁平結構,當筆記數量達到一定規模時,其弊病就暴露出來。
例如,由於你不知道一篇筆記記錄內容的邊界應該在哪,導致普遍的冗餘內容分散在多篇筆記裡,從而降低系統的可用性。冗餘內容不會因為筆記之間建立起連結就變少,當一篇筆記的連結數量過多時,系統可能因為會牽一髮而動全身而變得難以維護。
透過使用 Zettelkasten,你平息筆記系統中的混亂所付出的成本將遠大於你從筆記系統中獲得的收益。你會得到一張漂亮的筆記網路拓撲圖,但這拓撲圖就跟其他類型的資料視覺化一樣,除了助長生產力幻覺外毫無用處。
可維護的筆記系統
筆記系統不是規劃出來的,而是生長出來的。只有當你的筆記系統是生長出來的,它才有足夠的韌性應對變化,適應你的需求,而不是反過來。
要發展筆記系統,需要有一個可維護的筆記系統作為發展的基礎。什麼是可維護?
可檢索
一個可維護的筆記系統是可檢索的,並且檢索起來應該很方便。
唯獨文本
對可檢索性的要求使得筆記強制使用文本作為主要的資料,因為這是唯一能準確檢索的資料。
這意味著如果你的筆記是手寫的,或者筆記大量包含圖表、媒體甚至可互動內容,那麼你將很難形成筆記系統,因為檢索不方便。的確有一些方法讓文本以外的資料變得可檢索,但再怎麼最佳化方法,最後也不過是到達文本的起跑線罷了。
純文本
你的筆記最好是純文本,而不是富文本。
純文本的主要優勢是你的筆記系統不會被鎖定在特定的文本編輯器上,這將明顯讓筆記系統更健壯。
此外,透過程式處理筆記會更方便,因為文本是一種通用資料類型。例如你可以直接用 ripgrep 作為筆記系統的搜尋引擎。
將筆記視為寫作
Evernote 等筆記軟體透過瀏覽器外掛程式為用戶培養依賴複製貼上的筆記習慣,這種剪貼簿式的筆記方法完全不適用於可檢索的筆記系統。這些便於囤積資訊的功能一定程度上是為了讓用戶產生生產力提升的錯覺,讓原本不做筆記的用戶開始相信自己應該使用筆記軟體,實際上被囤積的資訊多半是石沉大海,再也沒有看過。
你不應該往筆記系統裡囤積任何沒經過大腦消化的東西。摘抄等原樣照搬內容的行為需要被視作對筆記系統的污染。
為了讓筆記達到最佳的可檢索性,你應該把筆記視為一種寫作:
- 因為你理解了知識,所以記下的知識是為你量身定做,當你忘記時才會真正有用。
- 因為這是你的寫作,而寫作是思考過程中間結果的輸出,這種輸出符合你個人的語言習慣,所以你才能在未來檢索到這段知識。
少數情況下,可能有例外。比如你發現一段完美的內容,好得難以置信,以至於任何形式的改編都會降低它的價值,這才值得原樣將它輸入筆記。
你仍然可以有用來歸檔資料供日後查找、引用的剪貼簿,它是什麼形式都無所謂,只是不要把它和筆記系統混為一談。
可閱讀
一個可維護的筆記系統是可閱讀的,並且閱讀起來應該很輕鬆。
顯然,你的筆記有多可讀,很大程度上取決於你的寫作本領有多好。對寫作沒有自信的人也不必擔心,筆記寫作也不需要你成為一個多好的作家。實際上,滿足幾點就可以大大提升文本的可讀性。
簡潔
如果我有更多時間,我會寫一封更短的信。—— Blaise Pascal
簡潔(Concision)是一項常見的英語寫作原則,但它顯然不僅適用於英語。
你的筆記寫作應該簡明扼要,切入重點。這讓你的筆記花費更少的閱讀時間,並且編輯起來更容易。
最開始,你可以追求絕對簡潔——機械地尋找和刪除句子中不必要的成分,比如把修辭全幹掉,移除所有重複等。隨著筆記系統的發展,你會明白自己對筆記文本可讀性的審美舒適區,明白怎麼簡潔才更明智,從而真正掌握這條寫作原則。
包含上下文
做筆記的人應該有過這樣的經歷:看不懂自己記下來的東西。這是因為當閱讀筆記的時候,已經脫離了記錄筆記時的背景。
為了讓筆記能在未來可以被讀懂,需要在寫作時有意識地融入必要的上下文資訊。好的筆記是那種在離開這一領域幾年後,回來依然能讀懂的筆記。
如果你對筆記寫作不夠熟悉,你會很難控制到底需要保留多少上下文才能讓未來的自己讀懂。沒關係,你根本不需要一次成功。由於你的筆記系統是發展的,你大可以在筆記時盡可能多地記錄上下文,然後在下次檢索到這部分內容時再編輯它。未來的你比首次記下筆記時的你更清楚哪些上下文是多餘的。
明智的排版
你可以在文本層面做平面設計。
一致的風格
不僅程式語言程式碼需要維持一致的編碼風格,標記語言也需要。即使你不使用標記語言,而是用富文本,你也需要維持一致的風格。
除了維持一致外,你還需要意識到一些風格明顯優於其他風格。以 Markdown 這種方言眾多的輕量標記語言為例:
Level 1==Level 2--### Level 3This is a [hyperlink](https://en.wikipedia.org/wiki/Hyperlink).# Level 1## Level 2### Level 3This is a [hyperlink].[hyperlink]: https://en.wikipedia.org/wiki/Hyperlink儘管渲染結果相同,但第二種源文件要顯著優於第一種源文件。
手動換行
Markdown 等標記語言需要兩個換行符才會產生新的段落,不是每個人都知道該怎麼利用標記語言的這種特性。
你不應該這樣寫:
多年以後,面對行刑隊,奧里雷亞諾·布恩迪亞上校將會回想起父親帶他去見識冰塊的那個遙遠的下午。那時的馬孔多是一個二十戶人家的村落,泥巴和蘆葦蓋成的屋子沿河岸排開,湍急的河水清澈見底,河床裡卵石潔白光滑宛如史前巨蛋。世界新生伊始,許多事物還沒有名字,提到的時候尚需用手指指點點。而是應該這樣寫:
多年以後,面對行刑隊,
奧里雷亞諾·布恩迪亞上校將會回想起父親帶他去見識冰塊的那個遙遠的下午。
那時的馬孔多是一個二十戶人家的村落,泥巴和蘆葦蓋成的屋子沿河岸排開,
湍急的河水清澈見底,河床裡卵石潔白光滑宛如史前巨蛋。
世界新生伊始,許多事物還沒有名字,提到的時候尚需用手指指點點。或者這樣寫:
多年以後,面對行刑隊,
奧里雷亞諾·布恩迪亞上校將會回想起
父親帶他去見識冰塊的那個遙遠的下午。
那時的馬孔多是一個二十戶人家的村落,
泥巴和蘆葦蓋成的屋子沿河岸排開,
湍急的河水清澈見底,
河床裡卵石潔白光滑宛如史前巨蛋。
世界新生伊始,
許多事物還沒有名字,
提到的時候尚需用手指指點點。一個合格的渲染器對於上述三種源文本風格,其渲染結果在視覺上應該完全相同。
相比第一種源文本風格,後兩種源文本風格具有這些優點:
- 文本結構更清晰。
- 對 Vim 等文本編輯器更友好。
- 對 diff 等文本差異工具更友好。
即使你不使用具有這種特性的文本標記語言,或者渲染器行為不正確,採用後兩種源文本風格仍然有優勢,因為它們本質上就比傳統的緊湊排版要易讀。
這種手動換行的做法非常古老,被大量寫作者使用,在歷史上有多個名字。它曾被稱作 Ventilated Prose,後來有人叫它 Semantic Linefeeds。在我寫這篇文章的時候,發現了一個專門介紹它的網站,稱其為 Semantic Line Breaks。
良好的層次結構
筆記需要有良好的樹形層次結構,能將筆記按內容分類,具有適當的標題,讓相關性高的主題距離更近。這種分類不必多嚴謹,但應該足夠實用,且修改阻力應該盡可能小。你很可能無法一次就獲得良好的層次結構,沒關係,層次結構將透過對筆記系統的維護逐步獲得改進。
理想情況下,你使用的標記語言和文本編輯器都應該給樹形層次結構的維護提供足夠的方便。例如標記語言應該允許樹具有無限的深度,但像 Markdown 這些主要以 HTML 為渲染目標的標記語言只支援 6 個深度,因為 HTML 級別最小的標題標籤是 h6。例如文本編輯器應該支援大綱視圖和以樹中節點為單位的移動/深度增減,但大多數文本編輯器也就只支援到節點的展開/摺疊罷了。這導致你若想要在純文本上獲得完美的樹形層次結構編輯支援,基本只有 Emacs 的 Org-Mode 這一條路可以走,這使得很多人都不能體驗擁有良好樹形層次結構筆記時的好處。
層次結構的意義
「如果一個內容同時屬於多個主題怎麼辦?」這是組織樹形層次結構時相當常見的問題,不回答這個問題就無法繼續發展筆記系統。
如果你的筆記系統是可檢索的,這個問題會變得非常不重要,以至於你可以不解決它。為什麼?因為你並不真正透過層次結構導航來定位筆記內容,而是透過檢索關鍵字來定位筆記內容。因此,一個內容可以同時歸屬於兩個主題,這是完全可以接受的——把它放在任一主題的節點下都不會損害筆記系統的可用性。如果你夠幸運,在筆記發展到一定程度時,相關內容可能會自行演化出它的位置,問題便迎刃而解。
如果你將這種基於檢索的解決方案與其他解決方案對比,會發現它優於其他所有解決方案——建立標籤系統、建立超連結或將內容分散為多份,本質上都在加重筆記系統的維護負擔,而基於檢索的解決方案什麼負擔也沒有增加,這使得這種筆記系統的維護成本顯著更低。
儘管筆記系統依賴檢索關鍵字來定位筆記內容,但積極維護層次結構仍然很有意義:
- 使你在維護筆記時能夠覺察主題之間的分界線,從而防止內容跑偏,提升筆記的可讀性。
- 層次結構能夠提供一個更高的視角來觀察主題之間的關係,有助於系統性地梳理知識。
筆記不是文章
需要指出,指望一個筆記系統變成一個產出文章的工具,這件事本身是不現實的,是對筆記系統的錯誤期望。
文章與筆記在組織結構和文本風格上,有著巨大的不同:
- 如果你用文章的結構和風格做筆記,那麼筆記的可用性就會大幅下降。
- 如果你用筆記的結構和風格寫文章,那麼文章的流暢性就會大幅下降。
這決定了不可能只是單純做著筆記,然後在筆記突破某個臨界點後就突然收穫一篇文章。
至於指望靠拼貼的方式,將筆記拼成一篇文章……就好像搭積木似的——最好還是斷了這個念想,除非你對文章的要求真的如此之低——迄今為止,最接近這一目標的做法是把你的筆記交給 LLM,讓它給你糊弄出一篇不堪卒讀的玩意兒。