迅速迭代功能的 Heptabase 已成為我最愛用的知識管理工具

這張圖來自 Heptabase 的 官方 changelog 頁面，點進去可以看到每個版本大致上改了什麼東西。

---

Hi！

好久沒有寫 Heptabase 的文了，從上一篇 用 Heptabase 進行卡片寫作的心得 至今三個多月，已經過了超過 60 個版本號的更新（現在是 v0.160.0），這期間我曾一度停用 Heptabase 兩個月，一方面是覺得有些想要的功能還沒有，用起來不太順手，另一方面是當時忙於架設自己的部落格和 wiki 頁面。

但在 5 月底，我重新開始大量使用 Heptabase ，這次不僅只是單純回來逛逛玩玩，而是開始將自己的「第二大腦」從 Logseq 移出，全部都放到 Heptabase 上面。

這麼做的原因是，這幾個月來， Heptabase 推出了幾個對於知識管理來說相當重要的功能更新，同時也不斷地在提升整體的使用體驗。

我覺得目前的 Heptabase 已經不單純是個「有潛力的工具」，而是已經可以承載複雜知識管理任務的產品了。甚至可以說，它目前就是所有選擇裡面最符合我需求的、最棒的工具。

以下先從此時此刻的角度回頭看，過去幾個月更新了哪些重要的功能，以及我怎麼看待跟使用這些功能。因為版本實在是不少，我有簡單根據幾個不同的體驗領域來分類。（版本號後面的連結都會直接連到 Heptabase 的官方 changelog 頁面，上面會有簡單的附圖或影片，這邊就不重複貼了！）

而在回顧完不同版本的功能後，會再簡單講一下目前我怎麼用 Heptabase ，以及他在我自己知識管理系統上的定位。

透過 Zola 建立了新的「筆記與想法快照」子網站

生產力就是在對的時間進行對的活動

生產力就是在對的時間進行對的活動

例如，在需要找一份參考信件時能馬上找到。

例如，看到一個好想法時能迅速記在對的地方。

例如，精力充沛的時刻能夠花在重要又耗費精力的事情上。

如果生活中這樣的情境佔了大多數，那麼自己應該很少覺得自己在浪費時間，因為大多數的時間都在執行最適合的任務。

寫作的訣竅是對自己有興趣的領域真誠地寫下自己的想法

跟什麼都想寫一點比起來，針對自己有興趣的領域，更有機會產生有價值的想法。

例如，為什麼喜歡或不喜歡這個領域裡面的某件事？該怎樣做到或避開這個領域的某件事？這些都需要一定的時間去浸淫與理解，才會慢慢產生自己的想法。

而只要能真誠地將這些屬於自己的想法寫下來，這些想法不僅對自己有價值，也可能對其他人產生價值，因為總有跟自己類似興趣的人，可能曾有過類似的疑問或思考，而自己寫下來了，讓對方產生共鳴。

所以，針對自己有興趣的領域寫下想法，不僅比較簡單，也更有價值，如果寫作都專門挑這類型的想法去寫，就沒那麼困難了。

反向連結必須要提供充分的上下文語境

我認為，PKM 工具裡面的反向連結，必須要提供充分的上下文語境。倘若只是顯示「誰連到這則筆記」，是不夠的。

至少必須能夠展示該連結的前後文資訊、上下層級的摘要內容等，才是堪用的反向連結。

因為充分的上下文資訊，能夠讓未來的自己在看到該反向連結時，很快進入情境，理解「為什麼我當時記下這條？他的語境是什麼？」

這樣的理解有助於產生下一步行動，例如回頭編輯連結的源頭筆記，或者是產生更多的聯想，這些都必須要有充分的上下文資訊才能夠促成。

透過 Heptabase 製作閱讀筆記卡片

我會在 Heptabase 裡面針對已經透過「我的閱讀、畫線與註記工作流」初步處理過的文章，視重要程度，在 Heptabase 裡面開設文獻卡片，命名格式為「articles.文章名稱」

建立卡片後，透過 Keyboard Maestro 直接加入固定的 template 。內容包含三個區塊：

• metadata：包含作者、文章發布日、閱讀日
• 註解區：包含 Quotes, Highlights, Annotations，並 透過Heptabase進行漸進式總結
• 筆記區：包含使用 「我撰寫Literature-notes的方式」 這個方法撰寫的筆記
• References：包含文章連結、Link from（從哪些地方讀到連到這篇文）、Link to （連到哪些筆記）

在製作閱讀筆記卡片的時候，特別需要注意的是把自己的想法寫下來，形成一則一則的原子筆記。此時我會再把他們列在下方的 “Link to” 區塊，後續即可將這些想法擴寫成自己的 random thoughts 或 evergreen 筆記了。

透過這整個流程，我在「閱讀筆記卡片」裡面，會保有一篇文章的畫線紀錄、我的註解內容，也可以連結到基於這篇文章產生的不同想法，留給未來的自己參考的依據。

透過 Heptabase 進行漸進式總結

前一步驟：透過Heptabase製作閱讀筆記卡片

此一步驟： 在註解區，透過 Tiago Forte 提出的漸進式總結方法，註記相關資訊。

• 第一層：先將 Glasp 裏面有畫線的區段都貼上來。
• 第二層：把覺得寫得好的地方用成粗體顯示
• 第三層：特別喜歡的句子用成 highlights
• 第四層：寫下自己的想法

這些都能在 Heptabase 的編輯器裡面很輕鬆地處理。

聯想羅盤

Version: 1.0

簡介：聯想羅盤是我參考 5/17 介紹的 The Compass of Zettelkasten Thinking 建立的小小 workflow ，透過 Heptabase 的視覺化筆記來實現，使用方式是把需要的卡片放在正中央，此時就開始根據聯想羅盤的東西南北四個方位開始思考新的想法。

• 中間：放置想法本身
• 北方：這個想法從哪兒來？
  • 為何會冒出這個想法？
  • 這個想法可能屬於哪個卡片盒、分類
  • 他的上位概念可能是什麼？
• 西方：跟這個想法相似的有什麼？
  • 別人是否提過類似的概念或想法？
  • 我自己是否提過類似的概念或想法？
• 東方：跟這個想法競爭、衝突的有什麼？
  • 別人是否提過衝突的想法？
  • 我自己是否曾有過不同的想法？
  • 有哪些想法可以補充這個想法，讓他更好？
  • 這個想法缺了哪些東西？
• 南方：這個想法可以往哪裡去？
  • 這個想法可能可以延伸什麼下一步行動？
  • 這個想法的下位概念可能是什麼？

由下而上建立關聯性的關鍵字索引比單純建立雙向連結更有價值

我的理解上，正確使用卡片盒筆記法（Zettelkasten）的六個關鍵步驟 | 閱讀前哨站裡面提到的關鍵字索引 （Keyword Index），是某種必須持續維護的東西。

維護的重點在於「由下而上」建構內容。意思是逐步建立關鍵字、擴張不同關鍵字，持續加入卡片，幫卡片們建立連結。

那怎樣算是「由上而下」呢？舉例來說，如果我今天直接建立了一個 [[Zettelkasten]] 的關鍵字索引，然後開始搜集各種定義、名詞解釋等等，這就是比較屬於「由上而下」的建構方式。

但由下而上更注重於持續地、有意識地去跟過去的自己對話。

我認為，這種方式比單純透過雙向連結來期待「未來的自己能察覺到筆記與筆記之間的關聯」是更好的作法。

產品的功能不是越多越好

從 Wordle 的例子來看，我覺得產品的功能不是越多越好。

Wordle 的核心功能很單純，一天猜一個字，猜完可以用單純的 emoji + 文字進行分享，這個分享有著足夠有意義的資訊卻又不會爆雷，而分享完之後你就不能玩了，只能等待下一天。

Wordle 捨棄了複雜的通關、等級、不同玩法的可能性，專注於把核心的功能（玩法）做好，配合好的分享機制設定，讓成癮用戶時常有動力分享，讓未成癮用戶能時常看到分享，進而被勾起遊玩的慾望。

我覺得這種在產品設計上的克制，值得效仿。

打字速度快的好處是想法能更快從腦中卸載成為想法快照

打字速度快的好處是，想法能更快從腦中卸載，成為一個固著的「想法快照」。

很多時候我們的靈感跟想法會出現在打字的過程中，因為大腦必須思考接下來要打什麼，就會自動運轉起來，此時若打字打得快，自己心裡想的事情跟靈感就能夠更快產出，不會被卡住。

Brian Lovin 認為¹，打字打得快是有複利效應的，從輸出的角度來看，打更快代表更容易形成草稿，也更容易編輯成可以輸出的文字，而輸出頻率增加就更容易收到回饋，此時自己的想法就會更完善，也會產生更多靈感，從而形成一個正面的循環。

Output: 用鍵盤打字逐漸成為稀有技能？ - by P.J. Wu 吳秉儒 - Pin起來電子報

^[1] Typing fast is a high-leverage skill ↩︎

專案文件應該寫清楚需求與限制

一份好的專案文件，應該要清楚列出這個專案需要什麼資源，以及有哪些限制。

這樣做的用意，是讓讀文件的人能夠跟提出文件的人，站在同樣的角度評估與思考。

假設這個需求沒那麼重要、或者做不到，就能提出來討論。 假設這個限制，有其他方式可以繞過，就能提出來討論。

把需求與限制釐清，再透過良好的審視與討論流程， 就能讓大家好好地討論，進而有效率地往下推進專案。

透過 Curius 在閱讀文章時畫線與註記 （已於 2022.06.25 歸檔）

（本則 Workflow 已有更新版：我的閱讀、畫線與註記工作流）

我的資訊處理第一步驟是：閱讀、畫線、註記

目前只要透過瀏覽器閱讀的文章，我都會在上面透過 Curius 畫線，有些特別有感的段落也會直接註記在上面，包含我自己的換句話說、我自己的疑惑、或者是靈感。

而讀完一篇文章後，我會透過 Curius 的 tags 功能，把文章分成「單純讀就好」、「待做筆記」、「做完筆記」這幾類。

每天晚上或週末比較有空的時間，就挑那些「待做筆記」的文，在 Heptabase 上面進行漸進式總結。

我撰寫 Literature notes 的方式

我撰寫文獻筆記的方式，可以參考正確使用卡片盒筆記法（Zettelkasten）的六個關鍵步驟這篇好文的寫法，重點是把自己有感的段落，用自己的話條列式記下。（記得，不要照抄，也不要複製貼上）

這邊的關鍵在於「自己的共鳴」跟「自己的話」，一開始會不太習慣，但慢慢練習就會越來越熟悉。

因為這件事相對花時間與精力，所以在前段閱讀時就要控管好，找出真正想寫文獻筆記的好文去寫就好，其他可以看過、隨意寫一些註記或閃念筆記（fleet notes）就好。

另一個訣竅是，不要怕竄改作者的意思，總之用自己的話寫就對了，反正 Literature notes 沒有要輸出用，輸出時的嚴謹性可以輸出時再控管處理。

當我寫完 Literature notes 時，會趁著記憶猶新，從剛剛寫完的筆記裡面，挑一兩個疑問或論點出來發展成自己的 Evergreen notes。

透過 Raycast 檢索 Raindrop 的書籤

隨著我寫的東西變多，交互引用的次數也變多，若每次都要點開網站瀏覽就有點沒效率，因此我把我寫過的電子報以及 blog post 都存到 Raindrop.io 裡面，並且透過 Raycast 的 extension 來取用。

比方說我只要打 rl ，再輸入我想要的關鍵字，就可以搜到我 PO 過的文章了。

（但目前只能搜尋標題而已，看起來還無法進行全文搜尋。）

工作流程的標準化有助於提高效率

我認為，工作流程的標準化有助於提高效率，原因是：

• 標準化後，可以提高對工作的熟悉度，進而讓人進入某種「自動化」的節奏，這能讓個人提高效率。
• 標準化後，也更容易橫向比較，例如，專案 A 的步驟 2 跟專案 B 的步驟 2 差別在哪裡，為何前者比後者少花了五個小時完成？這樣的比較有助於找出提高效率的機會，進而讓工作流程達到最佳化，這能讓團隊提高效率。
• 標準化後，更好紀錄單位工時，這讓每個流程的成本以及預估時程都更容易計算，進而可以做出更精準的專案排程與成本規劃，這能提高公司整體資源運用的效率。

如何透過 Logseq publish 在 Netlify 上建立個人 wiki？

今天想來分享一下，如何將自己的 Logseq graph 透過內建的 publish / export 功能，直接發布到網站上，藉此建立一個「個人 Wiki」頁面，或者也可以稱它為 Digital Garden。

如果一切順利，完成品就會是一個類似這樣的東西：

https://logseq.pinchlime.com

點開來以後會很像自己 Logseq graph 的樣子，可以有超連結、可以建立頁面、可以設定雙向連結，也可以看到 graph view 。

這個頁面是 4 月底到 5 月初我自己的小小嘗試，透過這個嘗試我發現建立「個人 Wiki」有非常多優點，但 Logseq 還有一些不足的地方，因此後來我又找到了 Dendron 這個工具來建立我自己的個人 wiki。（2022.12.25 後記：已關閉）

但 Dendron 更小眾一些，使用起來門檻也比 Logseq 高一些，如果你對 Logseq 有興趣，或者本來就已經是 Logseq 的使用者，也對建立一個個人 wiki 頁面有興趣的話，相信這篇簡單的教學應該還是可以提供一些幫助！

電子報的優點是可以直達收信者的信箱

一則內容，如果在社群平台上面寫，內容會是屬於該社群平台的，讀者單純消費，若喜歡可能會存到稍後閱讀或其他 PKM 工具。但未來若想回來找，也很難再找到。

如果在部落格寫，內容會是屬於自己的，但讀者一樣看過就離開，通常不會存起來。未來若想回來找，必須記得作者或文章的關鍵字。

如果透過電子報寫，發出後是直達收信者的個人信箱，即使讀者迅速看過，不特別儲存到什麼地方，內容還是會靜靜地待在信箱。未來若想回來找，因為目的地明確，就更容易找到。

若能直達收信者的信箱，就更容易佔有收信者的注意力。

Evergreen notes 的命名必須是主觀的論點

Evergreen Notes 的命名必須是主觀的論點。

這樣做的優點是：

1. 未來自己或他人要閱讀時，可以節省查閱跟重新理解的時間。 例如，假設命名是：「Evergreen notes 的命名方式」，就會不知道可能會連到怎樣的內容。

2. 當格式是主觀的論點，就更好遵循 Andy Matuschak 提出的「atomic¹」以及「concept-oriented²」這兩個原則。

3. 當格式是主觀的論點，也比較好聯想明確的子論據。

2022.05.29 補充：Evergreen notes 的句型必須是「肯定句」，而非「疑問句」。疑問句則會放在 Daily WHW 或 Random Thoughts 裡面。

^[1] Evergreen notes should be atomic ↩︎

^[2] Evergreen notes should be concept-oriented ↩︎

部落格新增了 Footnotes 註腳的功能