Blogblog-Club on 伊果的沒人看筆記本

生產力作為一種聖杯

Igouist (Igouist) — Thu, 30 Apr 2026 23:50:00 +0800

這篇是我的 2026 年 4 月份 BlogBlog 同樂會投稿，本月主題是「生產力」。如果你有自己的部落格，歡迎一起來參加！
如果你跟我一樣想看其他朋朋的文章看到爽，可以到這個月的回顧文：BlogBlog 同樂會回顧：「生產力」的 102 種面向，有各式各樣的優質文讓你三餐配飯、一次滿足。

警告：本篇文章的分類為「murmur」代表內文充滿主觀、偏見、碎碎念，以及一些應該寫到 Timeline 但不小心寫太長只好發成文章的東西，服用時請做好隔離作業，謝謝您的配合。

我其實對近年遊戲經常採用的一個設計有點不滿，就是「戰力指數」。

在一些傳統（？）的遊戲裡，一個角色或人物可能擁有許多屬性，像是力量、智力、敏捷、幸運。更進階的可能牽涉到技能或個性，像是口才、射箭、劍術、竊盜。

這些能力代表了不同的面向，在不同情境下有不同的作用，對不同職業或是不同角色也有不同效果，在某些遊戲裡，屬性之間的搭配還會帶來更多複雜的屬性，甚至會是劇情路線和特定操作的門檻。

所以，我們遊玩時就必須研究這些屬性帶來的效益，並規劃自己要分配的屬性和成長路線（也就是常說的配點）。例如盜賊可能依賴敏捷與幸運；法師可能需要魔力。又或是當我們想扮演一名聖騎士，就同時需要力量和信仰。想要在某個特定事件中勝出並拿到道具，需要優先讓體魄的屬性達到 20 點並具備某某特性……諸如此類，屬性是複雜的，也是迷人的。

但也許是因為這些數值實在太不直觀了，還變相拉高了遊戲的進入門檻，於是產生了一個更加親和且通用的衡量單位，那就是「戰力」。

戰力會將玩家角色或隊伍持有的屬性和各項數值進行計算，按照公式直接估出一個代表整體戰鬥能力的數值。有了這個戰力的數值，玩家只需要看一眼，就可以說「哦！我的角色大概有 8,000 戰力這麼強」「他的角色大概有 1 萬戰力這麼強」

……但這個八千「戰力」和一萬「戰力」，到底代表什麼呢？

戰力變成一個非常扁平化的指標，遮住了背後所有的邏輯，只留下一個簡單粗暴的數值，很方便，但也很模糊。

「生產力」也是這樣的。

生產力是什麼呢？

從各大字典（1,2,3）來看，生產力似乎是一個描述效率的指標，包括生產的成品數量、花費的時間和資源、生產的速度等等。也就是說，如果我們能用更少的時間、資源、成本，生產出更多東西，或創造更多價值，那就是提升生產力。

從上面的定義裡，我們就能隱約察覺一件事：這個詞適用的範圍非常廣泛，畢竟跟「投入和產出的效率」有關聯的東西到處都是。

在固定時間內完成更多任務，是生產力；降低投入的時間或人力，是生產力；提升產出的品質，是生產力；把產能集中在高價值的產出，是生產力。

但我們當然不會被這些字面上的意義限制住，畢竟生產力這個詞太過好用了，而且每個行業、每種成品，甚至每個人的生產方式和產出價值當然都不太一樣嘛，所以，凡是能影響製造、創作或任何生產過程的任何東西，我們都要叫做生產力。

我使用了一個更方便的軟體，我花更少的時間就能整理同樣多的資料了，我的生產力提高了；

我買了一枝更好寫的筆，我寫字更快了，我的生產力提高了；

我把椅子往後躺，這個姿勢很舒服，我的生產力提高了；

我家有一隻貓，我充滿動力，我的生產力提高了；

如此如此，這般這般，我的生產力提高了。

當然，任何跟生產力相關的，我們也都可以叫做生產力工具。

專案管理工具，是生產力工具；知識管理工具，是生產力工具；自動化軟體，是生產力工具；

老闆半夜叫你起床加班的通訊軟體，當然也是生產力工具。

所有東西都是生產力。

太幸福了。

「一項指標一旦變成了目標，它將不再是個好指標。」（古德哈特定律）

生產力作為一個極其抽象的概念，我們可以把它視為在金字塔的頂端。

當我們從頂端往下走一階，會遇到「任務管理」，用來管理我們所有的任務與執行時間。而經過「任務管理」繼續走，則會看見「時間管理」與「精力管理」，因為我們需要具備這些時間與身體能力，才有辦法提高完成任務的效率。沿著這條路一直走下去，我們可能還會遇到番茄鐘、行事曆規劃、任務優先度、睡眠規劃、精力曲線等等。

這時候如果我們往旁邊看，在別的岔路上，還會有自動化、知識管理、溝通協作等路徑，它們各自往下又有更多技巧和工具。

從俯瞰的視角來看待這些關聯，其實會像一張網一樣，一層一層散出去。生產力比起某種單一的指標，更像是這整片區域的統稱。

如果我們只用「生產力」來進行溝通，實際上完全無法辨識討論的內容是指金字塔的哪一個層級、網上的哪一條區塊，焦點自然也就變得發散。

當有人說「我們要提升一下生產力」的時候，是想要降低成本，還是提高產量，或是要提高品質？

應該管理的到底是時間、精力、注意力、任務優先度，還是其他的什麼東西？

「現在人想要自我欺騙，最常用的一招就是隨時保持忙碌。」—— Daniel Putnam

當我們把所有生產力的概念都混在一起，就容易產生一些奇怪的迷思。

例如混淆產出數量和產出品質，誤以為只要數量夠多就是生產力的表現：

1982 年初，Lisa 軟體團隊正試著全力以赴，力求在接下來六個月內把軟體推出。某些主管認為，追蹤每位工程師每週撰寫的程式碼量，是個好主意。他們設計了一份表單，要求每位工程師每週五都必須提交，其中包括一欄填寫該週撰寫的程式碼行數。

Quickdraw 的作者、也是主要使用者介面設計師的 Bill Atkinson，是當時最重要的 Lisa 實作人員之一。他認為用程式碼行數來衡量軟體生產力很愚蠢。他覺得自己的目標是寫出盡可能精簡、快速的程式，而以程式碼行數作為指標，只會鼓勵人們寫出草率、臃腫、錯誤百出的程式碼。

Bill 最近正在優化 Quickdraw 的區域計算機制，並且徹底重寫了區域引擎，改用一個更簡單、更通用的演算法；經過一些調整後，讓區域運算的速度幾乎快了六倍。並且，這次重寫還省下了大約 2,000 行程式碼。

他正要替這項優化做最後收尾時，第一次到了要填寫管理表單的時候。當他看到程式碼行數那一欄時，想了一秒鐘，然後填上了：-2000。

（They stopped asking Bill to fill out the form - Isegoria）

又或者，追求所謂的生產力工具和流程，反而忘記了原本的目標。（這一項是我最有體悟的，因為我也曾花費九成時間去研究筆記軟體的流程和相關工具，卻完全沒有新增任何一則筆記。）

在大系統中，我們可能花很多時間思考系統本身的設計、優化管理方法，而忽略了真正對我們重要的事情，也就是系統「本來」想達到的目的。

追求完整的本能，再結合複雜的系統設計，最終可能導致我們的生產力「下降」，而非提升。

到頭來，我們花費了太多時間在維護、優化系統，而非利用它來提升我們的生活品質或工作效率。（為什麼你「不需要」所謂的人生管理系統 - Code and Me）

甚至是陷入某種陷阱：

以為自己在增進生產力，卻毫無產出。或是根本沒有目標，卻忙於浪費成本和工具。

生產力色情是指任何在你接觸之後，會讓你覺得自己很有生產力，但實際上你什麼也沒做的東西。

生產力色情的例子包括但不限於：閱讀一則頂級創業投資者發的「如何成為更好的新創公司創辦人」推文；看 YouTube 上的「你在健身房必須避免的 7 個錯誤」影片；瀏覽 Hacker News 上的「如何改善你寫出的程式碼」討論串

這些活動都會用一種很狡猾的方式，讓你覺得自己做了些有生產力的事。你會告訴自己：「我剛學到一些新東西。」雖然這沒錯，但你其實從頭到尾都沒有真正去做你原本打算做的事情。於是形成一個惡性循環：你把所有時間都花在想著要做事，而不是真的去做。隨著這個循環持續下去，你的生產力會趨近於零。（生產力色情（Productivity Porn））

諸如此類，還有更多隨處可見又極其相似的場景，例如：

該解決的是疲憊造成的精力管理問題，但誤以為是生產力不足，反而熬夜跑去研究看板任務；

要求團隊提升生產力，成員各自解讀，弄了行事曆、搞了同步會議，結果做事的時間變得更少；

不知道要做什麼產品，但一定要把 AI 工具的 Token 用完，只好隨便找個主題來做；

這類狀況數不勝數。每個人都想要提升生產力，但也都離具體的產出更遠。

我應該澄清一下：我並不是要反對生產力，更不是認為生產力工具跟提升生產力的這些技巧不值得追求。實際上，我很喜歡把時間花費在研究各種生產力工具和流程，這是日常娛樂的其中一環。

然而，生產力就像是遊戲的「戰力」一樣，最大的迷思就是：如果打不贏，鐵定是戰力不夠；如果沒有滿意的產出，那就是生產力不夠。彷彿只要有了生產力就能達成目標，達成目標的一切關鍵要素就在於生產力。

生產力作為一種聖杯、一種萬能的許願機器，乘載了所有提高效率、產生價值的願望。在這個祈求的過程中，模糊的概念也把每個實際的問題都壓縮、把每一個節點都扁平化了，進而帶來了前面提到的各種迷思。

因此，當我們真的需要提升「生產力」的時候，我們反而更應該放下「生產力」這個鬼魅，去還原它真實的樣貌。

去培養動力、規劃時間；去學習、去運動；去磨練技能，去寫作。看看別人是如何組織知識的，動手試試要怎麼讓東西運作起來。

讓所謂的生產力下降一階，變成更具體一點點的各個領域；再下降一階，變成能夠實際運用的工具和技能。只有先讓抽象化為具體，我們才能知道該走的下一步是什麼。

我並不是反對生產力，而是反對使用過於抽象的「生產力」涵蓋一切討論。生產力應該要被降維成更具體一點的各個領域，才能帶來實際的幫助。

這樣一來，反而才是最有「生產力」的做法也不一定。

感謝 Aimer 對此文章的初稿提供建議 :)

鴛鴦鍋就是要分成涮肉區和煮湯區才符合單一職責吧？

Igouist (Igouist) — Sat, 28 Feb 2026 21:00:00 +0800

這篇是我的 2026 年 2 月份 BlogBlog 同樂會投稿，本月主題是「只有我這樣嗎？」。如果你有自己的部落格，歡迎一起來參加！

如果你跟我一樣想看其他朋朋的文章看到爽，可以到：「只有我這樣嗎？」──2026 年 2 月 BlogBlog 同樂會回顧底下的「已經投稿的作者清單」，有各式各樣的優質文讓你三餐配飯、一次滿足。

參加了「只有我這樣嗎？」的投稿之後，發現原來真的不只我這樣！
感謝 Shuo-jen 的這篇〈火鍋界的「微積分大戰」〉
在追求鴛鴦鍋最佳實踐的路上，我們都不孤單，歡迎更多朋友加入我們！

看到這個月 BlogBlog 同樂會的主題「只有我這樣嗎？」的當下，文章主題就已經確定了。

畢竟曾經在現實生活問過一圈，完全沒有遇到過同樣做法的朋友，當時的想法就真的是「哇，不會只有我們這樣吧？」如此如此，正好寫文一篇，順便推廣推廣。

雖然很想直奔主題，但就像系統設計常說的「脫離問題脈絡、直接討論解決方案，就是耍流氓」，所以讓我們從一些背景脈絡開始聊聊吧。

首先，標題的鴛鴦鍋有一個重要的前提：吃到飽。

認識我的朋友都知道我是一個無肉不歡的人，凡是聚餐必定要大口吃肉、只要進食就一定要大口吃肉，反正就是要大口吃肉。因此我和吃到飽餐廳的關係，就像斷頭台的刀刃和路易十六的脖子，是一場命運般的奔赴：我不是正在吃到飽餐廳，就是正在前往吃到飽餐廳的路上。

而在數以百計的吃到飽餐廳種類中，火鍋又是金字塔的頂端，在煮沸的高湯涮上幾秒鐘，就有熱騰騰香噴噴的肉可以品嘗，從「肉量／每秒」為單位的進食效率來看，可以說是沒有比火鍋更方便的了。連續涮上幾片肉，裹上一些蔥蒜醬料，咬下的瞬間，肉汁和奶香味充盈鼻腔，恍惚間彷彿回到遠古時代的高原上跟野人祖先們一起撕咬獵物，這種感覺實在令人欲罷不能。

為了追求這份歡愉，我踏過了小蒙牛、新馬辣、向辣等戰場，用脂肪累積著戰士的勳章。但是，在這條偉大的火鍋征途上，仍然有一片巨大的陰影，那就是湯。

經常吃吃到飽火鍋的人都知道：只要涮的肉多了，煮到後面湯上面都有一層油，而且浮沫四溢、雜質四散，通常煮到這個程度，這鍋湯也就廢了。

原本該是火鍋主角之一的湯，就這樣淪為了龍套中的龍套，只為了把肉燙熟而服務。尤其像大學生聚餐這種眾菜拱肉的場合，更是連給旁邊火鍋料提鞋兒也不配，什麼湯頭帶來的濃厚、甘甜、溫暖和高普林，根本沒人在乎。散場的時候，也就只留下一灘陰暗扭曲的雜質鍋，跟離職前輩留下來的程式碼一樣，可以說是悲劇中的悲劇，實在令人唏噓。

但如果、如果我們既要又要－－既想大口吃肉，又想大口喝湯，該怎麼辦呢？

某天，我那聰明的女友靈機一動，想出了這套計畫（註：她非常強調要在文章中註明她是發想人。這很合理，畢竟是可以匹敵諾貝爾火鍋獎的殊榮）

在提供鴛鴦鍋的吃到飽火鍋店裡，服務生會請你們選擇兩個湯底——但這其實是一個陷阱。

我們要做的就是：兩邊都選擇同一個湯底。

補充：店員可能會露出疑惑的表情，不要管他，貴在堅持。

並且在最初的點餐中，集中火力在煮湯的底料：番茄、南瓜、玉米等，確保兩邊都各有一份（畢竟肉還是要有點湯味才好吃），份量因人而異。

接著，請選定一邊作為涮肉專區，另一邊則為煮湯專區。

所謂「同樣的條件、不同的經歷，就是不同的人生」我們將在火鍋實踐這一點。顧名思義，涮肉專區將專門用來涮肉，以確保參與者每分每秒都有美味的肉可以享用。

而煮湯專區的壓力就更大了，我們需要大量加入蛤蠣、扇貝等能讓湯頭鮮甜的海鮮，並且看情況運用白菜、香菇等工具來進行調整，偶而也要加入一兩片肉來增添風味。

只要遵守這個簡單的原則：「讓涮肉的歸涮肉、讓煮湯的歸煮湯」在一段時間的熬煮後，我們就能一邊攝取足夠的肉品，一邊享用由海鮮和蔬菜煮好的湯，並在這趟肉和湯的火鍋之旅中，找到兩者之間的平衡。

而在這趟旅程的結束、吃飽喝足的時候，回頭看看同一組湯頭所煮成的兩鍋湯，那又是另一番體悟了。

讓我們回顧這個方案在系統設計層面上的取捨：首先，全面涮肉之所以會毀壞湯底，是因為涮肉的副作用太大，而食材處理區域之間又太過耦合，以至於相互影響。這是典型的技術債，是因為模組拆分不當所造成的。

因此，我們會先想到的做法就是進行隔離。但要如何隔離呢？在民明書坊的《鴛鴦鍋設計模式》提到過：常見的方案是使用「辣」與「不辣」來進行劃分。但經過測試，這並不能解決我們的問題。

幸好，單一職責原則教過我們：「每個類別應該只對一個角色／業務場景負責」我們要找到的就是場景之間的區別；而吃肉吃到飽，跟喝火鍋湯喝到中風，明顯是不同的需求場景，所以我們應該將處理肉和處理湯的模組進行隔離。

經過我們火鍋架構師團隊的一番重構，現在湯頭已經比程式碼還清晰，這篇文章的字數也水得差不多了。那麼，以上就是同時懷著「只有我這樣嗎？」和「哈！只有我這樣吧！」心情所釋出的獨門吃到飽煮鍋秘方，祝各位吃鍋順利，大吉大利！

從紙筆到電子白板，我的 Heptabase 使用場景

Igouist (Igouist) — Sat, 31 Jan 2026 23:00:00 +0800

這篇是我的 2026 年 1 月份 BlogBlog 同樂會投稿，本月主題是「推坑」。如果你有自己的部落格，歡迎一起來參加！

如果你跟我一樣想看其他朋朋的推坑文看到爽，可以到：「推坑」──2026 年 1 月 BlogBlog 同樂會回顧，有各式各樣的推坑文讓你三餐配飯、一次滿足。

本月主題是「推坑」，原本想不太到要推坑什麼，但看到 PJ 留言「問就是推坑 Heptabase」後，心想：「對呀，我每天都在用 Heptabase，不如就推坑一篇吧！」

按照慣例，推坑開始之前還是要介紹一下什麼是 Heptabase。

這邊直接引用官方 Wiki 和教學影片，基本上看了影片就能馬上知道這軟體是做什麼用的：

Heptabase 是一個專門幫助你學習和研究複雜主題、對事物建立深度理解的視覺化筆記軟體。

雖然說要寫一篇來推坑，但關於 Heptabase 的介紹和教學已經一抓一大把了。

例如官方 Wiki 上就有足夠的使用案例和說明：

或是 Alan 分享的使用流程（當初就是因為這篇文章和裡面那部四小時的示範影片才入坑的）：

The Best Way to Acquire Knowledge from Readings | by 詹雨安 Alan Chan

當然還有更多介紹文，丟幾篇我個人喜歡的：

如果看見這篇文章的人，是想學習使用 Heptabase，那麼上面的資訊已經相當充足了。

那麼，所謂的「推坑文」到底需要什麼呢？果然還是需要推坑者使用的場景和心得吧。

綜上所述，接下來的篇幅就用來介紹我覺得好用的幾個地方了。以下全是個人經驗和主觀意見，充滿大量五星好評吹捧，想到什麼寫什麼。

如果看完發現沒什麼幫助，還請看在前面丟了一堆（別人的）資源的份上原諒我，阿彌陀佛。

從紙筆到電子白板

「喔，你是說你在腦中思考，然後記錄在紙上。」
󠀠『不是。這不是紀錄，這只是過程。你必須在紙上思考，這就是那張紙。』

在開始介紹使用場景之前，要先介紹一下我習慣的筆記方式。從小時候（？）還在學校念書做筆記開始，我就喜歡拿一張白紙，用簡單的文字和箭頭來整理腦子的想法，從第一個字詞開始，逐步地把東西倒出來，邊寫邊嘗試排列出一個方便好記的脈絡。

當時我發覺：如果只是在腦中想過，還是很容易忘；如果是單純閱讀課本或抄寫定義，那更不可能記得，只有像這種圖像式的關聯，才能稍微把記憶留得久一點，即使忘記了，也能藉由筆記上的圖樣更快地喚醒當初的印象。

▲ 跟同事討論分層架構時的筆記，這已經是少數字跡正常的紙筆紀錄了，還請包涵

過程之中也經過了幾次嘗試，有時候先把大框架畫出來、有時候先用第一張紙做條列，第二張紙才做整理、有時候就只是先寫上一個關鍵字，然後想到什麼寫什麼，但都還是遵循在紙上寫字畫箭頭的基本方向。現在回頭看，那也許就是我建構思考框架的過程。我喜歡將資料倒到一個平面上，然後像積木般地擺弄它們、畫上箭頭、用方框分群……試著從中找出關聯。

後來，我認識了 DIKW 模型（具體來說是下面這張圖）才明白：我其實是在學習從資料整理出知識的方法。而且，大多數人也是這樣形成新知識的，只是我的慣用工具是紙和筆。

▲ DIKW 模型：從資料到智慧的漸進關係，資料被整理出脈絡成為資訊，資訊被理解並內化成為知識，而將知識應用在判斷與行動上就成為智慧。有興趣的朋友可以參照這篇：知識是如何形成的？

隨著摸電腦的時數越來越多，漸漸地也開始放下紙跟筆，踏入了筆記軟體這個大坑。

然而沒多久就遇到了一個問題：整理太痛苦了。就像那句經典的「寫作之難，在於把網狀的思考，用樹狀的結構，轉換成線性的文字」，當時大多筆記軟體基本上就是一頁文字檔，和我原本的思考方式產生了很大的撕裂感，也導致製作筆記的摩擦力飆升。

很多時候，我仍然需要先使用外部工具（通常是一張紙）梳理完之後，再降維成一束文字塞到筆記軟體裡。我甚至發現，比起筆記軟體，Whimsical 或 Miro 這種數位白板用起來反而更順手。

後來又輾轉嘗試了多個筆記軟體，例如 Obsidian（我至今還是很喜歡那個視覺化的關聯圖跟豐富的擴充套件生態）、Notion（資料庫頁面的標籤可以下拉選單很方便，現在還是有用來管理我的書櫃）等等，也嘗試過在筆記內嵌 Drawio 的圖、用擴充套件來加入 Mermaid，但都沒能達到想像中的效果。

直到有一天，發現了一個主打白板的軟體：Heptabase。

這就是我尋找已久的筆記方式。

白板的真實本質是它是一張巨大的、無邊界的桌子。無論你是否自認為是視覺型思考者，每個人都需要一張桌子。桌子的大小決定你能同時看到多少資訊，進而影響你思考能延伸多遠。（The Best Way to Use AI for Learning - Yu An Chan）

▲ 搬家後的第一個白板：把物件導向跟依賴注入的筆記整理過去

我們可以在白板上自由地加上筆記、拉出線條，把筆記分群上色，實際上就這麼簡單。

但在快樂蜜月期（剛接觸筆記軟體都會有的一段時期，會瘋狂地加入筆記和試用各種功能，特徵是會看著自己的筆記呵呵笑）時，我還發現了更多白板帶來的優點：

第一項就是能用的空間變大了。原本受限於紙張大小的我，寫個字都很彆扭，不得已只能用抽象攏統的字代替。但現在一個節點是一則筆記，可以自由地完善這則筆記，我能用的空間和深度都大了許多，可以說是舒適無比。

第二個則是：在這個整合、梳理資料的過程中，我們很容易發現自己的疏漏。兩則筆記似乎應該要有關聯，但感覺線拉得很牽強？中間很可能少了一個關鍵觀念；把筆記分群之後感覺有一區特別稀疏？那就是補強的時候了。這種感覺很接近撰寫部落格文章時那種邊寫邊學的狀態，就是文章寫到一半才發現需要調查更多資訊，最終被迫在過程中學習到更多東西，這也算是一種輸出式學習了吧。

最後一個則是成就感。畢竟我是一個還算虛榮（？）的人，基本上就是會看著自己的作品沾沾自喜的類型（例如遊戲白金獎盃，或是自己覺得設計得很漂亮的程式架構）。白板本身就要求我們盤點自己的知識點、不斷整合資訊，整理出明確可見的關聯、在過程中擴張知識邊界。不斷重複以上步驟，在一波忘我的忙碌之後，發現白板已經隱隱約約有了一些知識的輪廓，對我這樣的人來說，沒有什麼比這個更令人愉悅了吧。

諸如此類，如果濃縮成一句心得的話，那就是：白板，真棒呀。（真是詞窮的表現）

補充：Heptabase 在九月上線了 Heptabase Gallery，裡面已經有許多朋朋分享的白板，可以上去逛逛其他人是怎麼使用白板，或是說，是怎麼思考、理解、梳理某個問題的。我一直對別人怎麼做這些事很有興趣，畫廊跟白板的 Publish 功能給了一個很棒的場景。

資料來源的好幫手：Readwise 與它的家族

在前面一頓對白板的無情吹捧之後，我們還是要面對現實：
如果我們要把知識點放到白板，我們必須要先有知識點（對，我知道有點廢話）

也就是說，我們需要先確認兩件事：

來源有哪些？我們去哪裡閱讀新的資訊？
我們要如何把這些資訊丟到我們的筆記軟體？

我目前閱讀的管道主要來自三個：RSS 訂閱、KOBO 電子書，以及社群媒體

RSS 用來訂閱我感興趣的網站
KOBO 是通勤路上的好夥伴
社群媒體用來打發碎片化時間

友善附註：RSS，是一種自古以來就存在（？）的訂閱方式。主要是將網站裡文章的標題和簡介等資訊整理成 XML 的文字格式（例如本站的 RSS 頁面），使訂閱服務只需要去各個網站抓取輕便的文字檔就能夠得知網站是否更新、現在有哪些文章等資訊，非常方便。

更重要的是，藉由自己選擇要訂閱的網站，就能讓我們自己決定資訊來源，在噪音多到爆炸的網路上可說是一片淨土。有興趣的朋友可以閱讀：

RSS：一份由你設計的報紙 | Tian-Yan’s Blog

你需要用 RSS，不要再拖了 | Wiwi.Blog

當我們提到「如何把這些內容丟到 Heptabase」，就必須提另一個常一起玩的好夥伴：Readwise

Readwise 是用來玩資料串串樂的，我們可以從 Kobo、Twitter、Medium 等軟體把閱讀時的劃線重點 Import 到 Readwise，再從 Readwise 把這些劃線重點 Export 到 Heptabase、Notion、Obsidian，基本上就跟《瘟疫公司》裡的鳥禽類作用一樣：從Ａ國家帶著病毒飛越大海散佈給Ｂ國家，帶來知識與希望。

題外話：我常覺得 Readwise 的 Twitter 同步做法很有趣，你需要把想收藏的推文用訊息發給 @readwise 這個帳號，它就會同步到你的 Readwise 上。每次按「透過聊天發送」都有一種「欸你先幫我把這東西拿回家」的錯覺

常被同時提到的還有 Readwise Reader，顧名思義是個閱讀工具，用來管理並閱讀 RSS 訂閱內容。並且在 Readwise Reader 劃的重點也會自動同步到 Readwise，進而同步到我們設定好的 Export 軟體，例如 Heptabase，直接做到一條龍。

我原本用來管理 RSS 訂閱的是 Feedly（還寫了一篇 Feedly —— 用 RSS 訂閱來主動篩選資訊吧），但在接觸 Readwise Reader 的強大整合就毅然決然跳槽了。

除了 RSS 訂閱內容作為出發點的這條路線以外，Readwise 也提供了瀏覽器擴充套件 Readwise Highlighter，可以直接在網頁上劃線，並將網頁內容同步到 Readwise Reader。如果閱讀到不錯的網頁，例如偶然發現的超讚部落格文章，就可以直接用 Highlighter 劃線並收藏。

我們從 Readwise Highlighter 和 Readwise Reader 收藏的劃線，最終會從 Readwise 同步到 Heptabase，並集中在 Heptabase 的 Highlight 頁面，後續就可以在我們的白板上取用，也能在每則 Highlight 底下繼續加上筆記、關聯其他筆記。

最重要的是：我們能在 Heptabase 用搜尋找到 Highlight，這個搜尋功能多次幫助了腦子只剩下一堆碎片的我成功找回當初看到的某篇文章，幫助很大，必須額外花一句話來稱讚。

▲ Highlight 頁面，可以看見從各個地方同步來的劃線筆記

聊完 Readwise 之後，另一個把資料丟進 Heptabase 的常用工具是官方的瀏覽器擴充套件 Heptabase Web Clipper，它會將網頁全文摘取到 Heptabase 中並建立一張卡片，還會標上來源連結。但由於我的外部資料主要集中在 Highlight 了，並且很難區分 Web Clipper 建立的卡片和我自己建立的卡片，對很喜歡在文章中加入一大堆外部連結的我來說有點困擾，因此使用的次數相對較少，只有在我打算留存全文、綁架人家的文章回家拆成卡片的時候才會使用。

現在我們已經簡短認識了 Readwise 家族，以及 Heptabase 自己推出的 Web，是跟上面的資訊來源（RSS、KOBO、社群）進行連連看的時候了。目前我的蒐集管道如下：

RSS 訂閱 → Readwise Reader（劃線）→ Readwise → Heptabase
文章閱讀 → Readwise Reader（劃線）→ Readwise → Heptabase
文章閱讀（如果想存全文） → Heptabase Web Clipper → Heptabase
KOBO → Readwise → Heptabase
Twitter → Readwise → Heptabase
Facebook → 分享連結到 Readwise Reader → Readwise → Heptabase
電子報 → 用 Readwise Reader 信箱訂閱 → Readwise → Heptabase

藉由這些路線，就可以把各處蒐集來的資訊集中到 Heptabase，成為後續筆記的養份。

延伸閱讀，順便丟一些 Readwise 介紹文章給有興趣的朋友：

Readwise Reader 付費訂閱三年評價，AI 快時代的「慢閱讀」

全方位閱讀軟體 Readwise Reader ── 文章匯入篇 - 好奇先生

Readwise + Heptabase 使用案例分享：讀文章、做筆記原來那麼簡單

關於閱讀與學習的工作流：Readwise Reader + Obsidian - 賴澤霖 - Medium

我所在意的筆記軟體功能：雙向鏈結、日誌、搜尋

前面聊完白板跟資料來源這兩個我最在意的重點，剩下的篇幅就用來聊聊一些我喜歡的功能吧。

首先一定要提的就是雙向鏈結，我最早是在 Roam Research 接觸到雙鏈這個概念的（現在似乎已經成為大多筆記的標配？），實際用了一段時間之後的確再也離不開了，因此第一段功能介紹就留給雙鏈。

雙向鏈結指的是「我在Ａ筆記提到Ｂ筆記，那麼我在Ｂ筆記也能看到Ａ筆記提到了Ｂ筆記」，其中

「Ａ筆記提到Ｂ筆記」是我們常見的正向鏈結
「Ｂ筆記也能看到Ａ筆記提到了Ｂ筆記」就是反向鏈結（Backlinks）

……用說的有點饒口，其實就是以前無名小站的「誰來我家」功能，只是對象換成了筆記，哪則筆記來我家。

利用反向鏈結，就可以從Ｂ筆記發現Ａ筆記的內容。尤其像我這種寫個文章都要插一堆超連結的人，可能撰寫Ａ筆記的時候，剛好覺得這和Ｂ筆記有關聯，就會順手標記上去。過了很久很久以後，當我瀏覽到Ｂ筆記，就能馬上掌握Ｂ和Ａ的關聯，這時候都會有一種賺到了的感覺。

如果以上的ＡＢ優酪乳大亂鬥看得有點亂，讓我們來看幾個簡單的例子：

以我在整理物件導向相關的筆記為例：我在單一職責原則、依賴反轉原則…等筆記都會提到跟介面的關係。那麼，我下次到介面的筆記時，就可以藉由反向連結，直接看到各個原則是怎麼應用介面的：

除了發現筆記間的關聯，並且能以某則筆記為主角看看其他筆記提到的內容以外，在日常工作上其實也有妙處。

我習慣在每天先到 Journal 頁面（類似每日筆記的地方）列好當天的任務，有進度的時候也會在 Journal 頁面關聯任務筆記，並放上相關的討論和紀錄（通常是隨手打個一兩句）

如此一來，當我有需要（？）的時候，就能在任務卡片的反向鏈結迅速確認每天的任務狀況和相關紀錄，還原專案的歷程及脈絡，意外地相當方便。

既然前面提到了 Journal，第二個就來聊聊我很需要的部份：日誌

我並不是喜歡在筆記軟體中頻繁切換畫面的人，那很容易打斷心流。因此，我更偏好大部份的工作都在少數幾個頁面中完成，像是白板能夠在畫布上完成知識點的拆分和梳理，就完全滿足這個需求。

但許多日常工作和臨時想法是無法當場花時間進行組織和整理的，我從 Roam Research 到 Obsidian 都已經習慣「開一個 Daily Note 來當作每日快速筆記」的做法。幸好，Heptabase 的每日筆記（Journal）非常好用，搭配側欄也不容易打斷心流，基本上成為了我日常工作的重心。

因此，我在使用 Heptabase 的時候，核心頁面就是這兩個：

當我正在研究一個主題、整理一組筆記，我的主要頁面是白板
當我每天執行工作、確認待辦項目、快速蒐集想法時，我的主要頁面是日誌

以今天（對，身為一個拖延症重度患者，這篇文章是壓線到最後一天寫的）的日誌頁面為例：

可以看見我習慣把日誌頁面分成三個部分：本日行程、待辦項目、每日紀錄。

每天我打開 Heptabase，就是先到日誌整理好當天行程、決定待辦項目、把相關的紀錄放到底下（像是某某專案決定怎麼實作、發現一個適合寫作的好點子、跟朋友聊到一個值得紀錄的概念，或只是想到什麼寫什麼）。每則紀錄都關聯到對應的筆記條目，後續就可以像前面雙向鏈結提到的，在各個筆記頁面用反向鏈結確認每天留下的紀錄。

同樣地，也可以使用關聯的方式，確保某天會需要的資訊自動出現在某天的日誌：

假設約好了下禮拜四要跟家人出門吃飯，就可以直接關聯下週四的日誌並打上「吃飯」，等到下週四的時候這則「吃飯」就會出現在日誌頁面底下的反向鏈結
假設某個專案預定在禮拜一完成Ａ任務、禮拜二完成Ｂ任務，我習慣將專案預計需要進行的步驟先全部列好，這時候就可以直接在專案筆記將Ａ任務的日期標為禮拜一，在禮拜一的日誌底下反向鏈結就會提到這個任務

備註：在上面的例子，如果是用待辦項目（Todo list）標記了某個日期的話，該日期的 Journal 右上角 todos 也會出現這則待辦（這真的是我最喜歡的更新之一，對我這種到處放待辦事項的人來說根本是德政）

搭配側邊攔直接開始相關的筆記頁面（例如整理專案資訊的筆記，又或者今天會用到的知識點筆記），可以做到在日誌畫面就處理完大部份的工作，說不定我停留在日誌頁面的時間還比白板長也不一定呢。

藉由白板跟雙向鏈結，就能盡可能保留筆記之間的關聯和脈絡，做出網狀般的知識庫。而搭配日誌、同步外部資料、擷取網頁，就能讓外部的資料有一個入口，提供知識庫源源不絕的燃料。當我打算列出一些我會在意的功能時，首先想到的就是這些，這可能也代表了這些功能對我的不可或缺。

當然，我還有許多在意的地方，例如搜尋。因為我記性不是很好，除了已經動手到白板的筆記以外，有些零散的筆記、隨手畫的線、從優質文章摘取下來的片段，平常都是散落在我的卡片庫裡的，頂多標了個標籤作為提醒。因此，我在使用筆記軟體時，其實是十分依賴搜尋功能的。Heptabase 的搜尋目前體感還蠻快的，而且可以同時搜尋到筆記內容和劃線重點，已滿足我的需求。

又或者看板，因為我的筆記軟體大多同時承載知識管理和專案管理的工作，對我來說，工作上的專案勢必會應用到先前累積的知識，兩者是無法分離的。而在 Heptabase 中，可以藉由標籤來將同性質的筆記列在一組標籤資料庫（Tag Database）裡，再加上一組專案進度的屬性，就能用看板（Kanban）的方式進行管理，這點也相當足夠。

諸如此類的部份就不展開細講了。~~主要是因為寫到這邊已經快晚上十點，感覺要來不及寫完了~~

小結

從大學寫筆記開始，一路用了 Evernote、Roam Research、Obsidian，最後半定居在 Hetpabase。最主要的因素還是前面提到的幾個場景（白板、雙鏈、日誌）都有符合我的需求。尤其是白板。既契合了我學習和思考的模式，又能保留更多的脈絡。

當我們看見一幅白板，甚至能大略知道這個人是怎麼理解這個主題的，又是怎麼拆解、怎麼組裝這些知識的（當然，這個「人」也包括六個月前的自己），白板保留了一部份思路，進而讓我們能窺見這個過程。

要打造一個脈絡化的知識網路，第二件事情是要確保所有知識和想法背後的思考脈絡都能被完整保存和追蹤。當你看到一個想法時，你必須能回憶起這個想法是怎麼產生的、又在哪些場景下被使用。

人類創造出的所有知識和想法，都是先有輸入，才有輸出。「追蹤思考脈絡」其實就是在幫助我們暸解什麼樣的輸入造成了什麼樣的輸出。也因此，我們必需打通生命週期中的「收集」、「思考」、「創作」這三個環節。（04 - The Knowledge Lifecycle）

甚至在看別人分享他們如何使用 Heptabase 整理筆記、自己也實際使用 Heptabase 整理筆記之後，會有種感覺：也許我們真的能藉由這種方式來學習如何掌握知識，最終讓自己變得更好。

A good thinking tool shouldn’t just hand users answers to their questions, but also guide and enable them to discover and articulate more complex questions.

一個好的思考工具不應該只是給用戶提供問題的答案，還應該引導並使他們能夠發現和表達更複雜的問題。（Linux’s stream）

決定 Heptabase 做為推坑主題之後，我一直在想：所謂的「推坑」到底是什麼呢？

尤其開始動手寫之前，我的想像一直被侷限在「推銷」，也就是「哇！這個東西有多麼多麼好」，或是是「你為什麼該用這個東西」。但是越寫越覺得，這好像不是我想要表達的方向。

看了幾篇推坑文，又回頭想想才發現：我是一個看到別人吃好吃的東西就會想吃、看到別人玩好玩的遊戲就會想玩的人。所以，能夠推坑我的東西，其實都有一個共通的特點：他們自己用得很開心。

只有對方分享自己的快樂，才會讓我想要嘗試。我甚至會想：也許最尊重對方的推坑方式，就是過好自己的生活也不一定。

所以，我最後決定用這樣的方式呈現：用我個人的使用場景來記錄這篇推坑。

如果你讀到這裡，然後你使用筆記的場景，跟我也有那麼一點類似，那麼我會推薦你：試試看 Heptabase 吧！