找不到的資訊等於沒有擁有過

大家一定有曾經看過某些事情、知道自己曾經寫下來過，但怎麼樣都翻不到當初做的筆記的經驗。以私人知識庫為定位的筆記，如果需要花費太久的時間才翻得到自己想要查閱的資訊與知識，可說自己並沒有擁有過這樣的資訊，當然更難好好利用已經累積的知識。

我用「自己是不是最多九十秒內找到我要的筆記內容」，作為評斷自己建立的筆記搜索品質。好的筆記架構通常跟搜索品質也往往正相關，「九十秒」這個標準，也能讓自己覺察到哪些部份的筆記需要重新梳理。

下關鍵字搭配本機 Zim + grep + SSD 的搜索方式

好的筆記架構與日後搜索速度相關，不過「好的架構」標準比較多元，根據知識領域與個人思維等等因素有關。接下來我們僅聚焦在一般性的、作為基礎工作上的討論。

我使用的方式是 Zim (個人型 desktop wiki)、grep (GNU commandline tool for string searching)、與一顆 io 效能良好的 SSD (固態硬碟)。考量如下：

不需要時常保持網路連線有非常多好處，例如搜索速度馬上少掉了網路各種可能與大大小小的延遲、甚至是斷線失去服務。

如果在本機中能夠用純文字的方式保存，因為文字檔很小，數十萬字也不過幾 KB ，這在動輒 GB 的資訊世代裡簡直是彈指間就能傳輸完畢的資料量。如果失去解讀資料的服務，純文字的方式也對人類可讀較為友善。也就是說，備份與遷移的成本很低。比較不受外部服務變化所影響。

grep 實做上使用人類知識所及裡、最快的字串搜尋算法 (Boyer-Moore algorithm)，搭配 SSD 的讀寫效率以及免除連網需求的延遲性，三者加起來讓我對關鍵字搜尋到印出結果的過程可以少於一秒鐘 (不計入開終端機與打字時間的話)；這個速度大概很少網路服務能夠超越。

另外 grep 本身是 (GNU 基金會支持的) 開放原始碼工具；開源程式這個特性使得我不需要擔心有一天服務會消失，同時搜索算法也很透明，我不用懷疑因為不確定服務到底怎麼搜尋、所以是不是有些東西沒搜到。

因為搜索往往少於一秒鐘，所以其實 90 秒的時間我有 89 秒可以瀏覽搜索結果。如果找不到我要的東西，大概是關鍵字下錯，或是當初筆記架構的邏輯上就有些可以改善的空間，這個就是另外一個主題了；今天我們聚焦在討論基礎建設。

有同步筆記需求的朋友，因為這套解決方案本質是數個大小很小的純文字檔，所以可以單純地透過像是 Dropbox 或是版本控制的方式 (例如 git 搭配 gitlab) 來解決。

因為這個解決方案的強項是「純文字搜索」，所以適用情境是會有大量 log、文字筆記量的使用者。例如我本身作為軟體開發者 / IT 產業工作者，常常會有各種程式碼片段、 log 、以及各種指令需要記憶。

我也常常將跟朋友文字交談、或是網路上自己與他人的文字透過單純的 copy-paste 下來，直接當作筆記的一部分。這樣每次跟朋友談話的時候對方都會覺得你很認真打字跟對方分享，但其實是抱著我同時幫自己作筆記的用心態度在寫下每一個字 XD 。這樣一石二鳥的筆記術，不用嗎？

如果讀者不介意，也歡迎大家在下方或是來信分享自己在數位時代的筆記方式。很期待看到大家不一樣的思維和方法。

經讀者提示，這種筆記方式似乎跟 zettelkasten 這種筆記術，在設計思維上是很接近的。而 zettelkasten 有自己的愛好者網站讓更多喜歡 zettelkasten 有更多交流分享的機會。

很高興能夠收到這樣的讀者回饋，知道原來這世界上有一群人其實也跟我想得差不多，我要去那邊取暖 XDDD 我還以為我只是非主流的少數，原來只是我孤陋寡聞。

建立 Journal 後，如果日後有 grep 到相關的訊息，就可以考慮把相關資訊分門別類了。用實務需求決定要花多少時間與經歷給筆記分類、二次整理。