大概去年四月的時候我開始接觸第二大腦的知識,學習如何建立搜集知識的流程以及打造個人知識庫。
其間摸索了很多 solution 像是 Feedly,Readwise,Obsidian,Notion,但是實際上在設計流程的時候一直覺得不順手。
我花了很多時間去刷 RSS feed,結果發現資訊很片面 (fragment),我把所有想學的東西都丟到 Readwise,然後就沒有然後了。
因為資訊太多讀不完到頭來第二大腦反而造成負擔,於是在今年四月的時候決定先暫時放棄統整一切知識庫,先求有再求好,不要太過有野心導致什麼都做不好。

(起初建立第二大腦所列出來的代辦項目)
重新審視流程和執行上的痛點
我丟了一堆資訊進去第二大腦,第一大腦卻來不及消化
我起初在建立系統時太有野心,每一筆知識都想要留存。
放了一大堆知識,來不及消化舊的知識前就繼續放新的知識進去。
加上平常工作就很燒腦,光是吸收公司內部的資訊就花掉 80% 的時間,所以為了維持閱讀的習慣,我只能捨棄休閒。
然後期間火上加油的是我為了更有效率,我開始仰賴 AI 來縮短消化資訊的過程。 可是因為學習其實是把那些值得回憶的共鳴點上色,找出規律然後把點連成線。

(資訊轉變成為知識的過程示意圖)
而我還沒等知識沈澱,就繼續去加上更多的點點。
最後就是被各種零碎的資訊覆蓋,完全找不到轉換把資訊轉換成知識的路徑。
惡性循環下,舊的讀不完,新知識又跟不上,整個被焦慮反噬
這也是我最大的敗因,沒有考慮到每個環節所需要投資的時間,錯估自己可以直接套用這個系統到生活中。
沒有評估到各個平台的生態系不相容
我第二個錯誤是沒有想到整合各個系統需要花費大量的時間去理解和適應。
第二大腦有一個環節是 Organize information,通常就是分類和上標籤。
我一開一頭栽進去這個概念時馬上訂閱了 Readwise。
但是 Readwise 只負責 Capture 和 Take note ,Readwise 本身不適合作為 source of truth 因為他沒有 folder taxonomy 和 backlink functionality,所以要把 Readwise 當成 index 系統不夠強。
導致我必須要在更適合的軟體上(Notion) 做分類的動作。
我一開始並沒有意識到這件事情的嚴重性,我在 Readwise 上了一次標籤,然後又要去 Notion 整理一次標籤確保兩邊資訊同步,大幅的增加了不必要的流程。
還有像是 Notion 並不是打造來撰寫文章的,我卻試著在 Notion 上面設計 Express 的環境 (寫文發文的 Kanban),所以我又必須要在 Word 打好文章然後確保同步到 Notion 上好為了符合我的 agile 模式。
或者是自己 80% 的時間花在消化公司內部資訊,但是內部系統的文章不能和外部系統放在一起 (有些資訊可以流通,有些高度機密),久而久之可以提取知識的配置方法就大幅受限。
簡單來說我忽略了來回切換不同系統所需要花的精力,以至於被這些簡單的 admin 壓垮
-
導入解決辦法,選擇更精實的操作模式
我後來根據最大的阻礙,囫圇吞棗的心態和軟體之間的生態系想出解決辦法。
學會判別哪些資訊我需要哪些我不需要
就像 zero inbox 的技巧一樣,消化資訊的第一步是決定哪些訊息重要。
所以我在 Organize 訊息的階段會再省思一次這個資訊值不值得我放到永久記憶的區塊,如果不值得我就會直接封存。
如果是個重要資訊,而且我已經找到連結點,那麼我就會把他放到下一個流程的步驟,把他打成文章,或是變成文章的 reference。
這樣一來我就不會覺得每一個新知識我都一定要消化,我可以讓第一大腦慢慢去找這個訊息和其他永久記憶的相關性,等到真的需要時再像哈利波特的記憶池一樣,搜尋關鍵字或是 metadata label 把他找出來應用。

(我打造了一個 source of truth,存放所有想要學的知識)
如果不能建立龐大的生態系,那便先從小的環境開始設計
為了解決問題 2 (系統相容問題),我不再執著於要一次學會串接所有系統的方法。
我果斷退訂了 Readwise 因為我最大的阻礙是我沒有時間做 Capture 和 Take note 的動作。
我不需要快速的紀錄這些筆記,自然就不需要 Readwise。
工作以外保留最低限度的第二大腦,Capture 上使用最精簡的方式,丟到 Notion 然後做筆記。
Notion 的知識庫做為 Organize 的用途,維持上標籤和歸檔的習慣。
因為所有筆記都已經在 Notion 中,所以Distill 就不用再跳回去其他軟體。
最後 Express 的敏捷看板模式還是留著,放在 Notion 上面,撰文只在 Google doc 執行,降低同步的需求。

最後我找到最適合自己的方法
Capture 用這些軟體 Kindle,Newsletter,YouTube,Social media 抓住資訊然後通通丟進 Notion 的大知識庫檔案夾。
筆記的話是看到想要記得的地方會上 highlight 然後請 AI 提供問題 (這樣 Distill 時可以加深記憶)。
Organize 用 Notion,幫知識庫內的文章上標籤,決定需要或不需要,以及知識的應用場景。
Distill 也是在 Notion 上處理,回答之前筆記提出的問題加深記憶。
然後如果覺得有必要轉換成長期記憶,就會去 Content creation 的看板開啟文章丟到撰文流程內,撰寫文章時 backlink 零碎資訊作為 reference。
Express 的話還是習慣在 Google doc 上面撰寫,Notion 的 formatting 用起來還是卡卡的 (但是正在習慣)。
比較麻煩的是寫文章同時要把 reference 開著,這樣 paraphrase 比較方便。
後記
我試了那麼久才知道原來 Notion 這麼強大,大概可以 cover 80% 的工作流程。
而且如果把這個概念導入團隊協作,產出文章的速度應該會快很多。
害我都想報名 Raymond Ho 的實體課了 🤣
Heptabase 適合卡片盒筆記法,感覺方法比較適合用來寫長文或論文,論文也是大量閱讀然後把資訊濃縮成段落。
但是我沒有讀過卡片盒筆記一書也沒有用過 Heptabase 所以就留給有經驗的人分享。
結論是新手適合直接從 Notion 開始,建議去看 Ali Abdaal 的影片,摸索一下需要哪幾個檔案夾和怎麼設計工作流程。
Comments