我對 Bike 有興趣的原因有幾個：

1. 他主打非常迅速且不佔用資源的 native mac app。
2. 主打所有文件都是 local 的。
3. 文件寫得蠻完整的 Bike Guide

這好像可以歸納出幾個我喜歡的元素

1. 迅速
2. 純文字
3. 文件完整
4. native app

思考一些關於 Evergreen notes 的命名原則：

是一個明確的「論點」，例如：

• 電子報可以直達收信者的小天地 （Ｘ）
• 電子報的優點是可以直達收信者的信箱 （Ｏ） 前者的描述比較像是一個客觀描述，後者則是主觀的論點。 換句話說，Evergreen notes 的命名必須是主觀的論點

內含價值判斷或比較，例如：

• 持續運動的好處（Ｘ）
• 持續運動比不運動好（Ｏ） 前者的描述比較是資料的收集與彙整，但後者是涉及一個明確的價值主張或高低比較。 （發現這一點似乎跟前一點有點像，暫且不額外開一則筆記。

random thought 就是可以斷在這種地方，不用管整段內容的結構或完整度，讚啦！

今天在推特上看到有人在分享 LYT conference 的東西，提到 "Compass framework" ，原本以為是以前看過的 LYT kit 裡面的東西，但後來作者之一 Vicky Zhao 分享了該篇文章 給我，是另一位作者 Fei-Ling Tseng 提出來的方法論，她稱這個方法叫做 The Compass of Zettelkasten Thinking。

具體的做法是，將一個 idea X 置於中央。

此時想像他的四個方向，都各有一個問題，這些問題有助於釐清這個 idea 。

• 北方（north）的問題是： Where does X come from?
  • what are its origin? what group/category does X belong to? what exists an order of magnitude higher? zoom out. what gave birth to X? what causes X
• 西方（west）的問題是： What is similar to X?
  • what other disciplines could X already exist in? what other disciplines could benefit from X? what are other ways to say/do X?
• 南方（south）的問題是： Where can X lead to?
  • what does X contribute to? what group/category could X be the headline of? what exists an order of magnitude lower? zoom in. what does X nurture?
• 東方（east）的問題是： What competes with X?
  • what is the opposite of X? what is X missing? its disadvantage? what could supercharge X?

我看到這個方法時，我直覺就想到，好像可以透過 Heptabase 來做這件事，透過視覺的方向關係可以很快給出東西南北的方向。

但這個方法有提到，每個 idea 產生的各個方向，都可以再產生更多 idea ，以及他們各自的東西南北（通常是東西南），所以感覺可能更適合用 Outliner 來進行。

不過接下來的問題是，我的羅盤四個方向會是哪些問題？

直覺的優點：

1. 以貼文的形式貼在 Twitter 上有助於觸及更多未訂閱的潛在讀者。
   • 這可能是因為，現在一般人比較不會轉信，比較會轉推。
2. 貼在 Twitter 上也有助於推送給既有的讀者。
   • 很多人未必會看完每則電子報，以我的經驗來說，訂閱的大多數電子報都沒時間看。

潛在的缺點：

1. Twitter 看過的人，可能就不會再從信箱看了，這可能會對整體開信率有負面影響。
   • 但這個缺點，我覺得無關緊要，因為有人願意點擊連結閱讀，也會在 Twitter 或 Substack 的某個範圍有正面影響。

小結論：優點大於缺點，且每次貼出連結後的一天內都能收到新的讀者，代表此方法應該算有效，可以繼續實施。

今天看到 Jakob Greenfeld 分享 應該是他創造的一個服務 Enrich my List ，覺得很有趣。

該服務的概念很簡單，你給他一份 email list ，他給你「這些人」的名字、Twitter 及 LinkedIn 帳號，以及對方的追蹤者數量等，讓使用者更了解自己既有的 email list 。

這服務的收費方式是「按 List 大小」計費，目前的計費標準如下圖：

我覺得這服務有趣的點在於，他解決了某種懶惰又真實存在的需求： 「我想知道誰追蹤我、誰訂閱我，但我沒力氣一個一個去肉搜」

那就交給機器人吧，另外，為這需求付點費也很合理吧。

之前剛開始寫的時候，曾經有規劃是把「中篇幅的短文、論述、文章摘要分享」放在電子報。

也曾在Pin 起來的 Roadmap 2022 中簡單描述過：

電子報是一直以來都想嘗試的發送形式，對我來說，非即時的、一對一的電子信件這種東西，一直都很吸引人。

但今天若問自己這個問題，我的回答比較會像是：

1. 電子報的固定形式有助於產出內容
2. 持續寫電子報有助於經營個人品牌
3. 電子報的優點是可以直達收信者的信箱

我再一次覺得，我自己可能不需要「Literature notes」這種類型的筆記。

一部分是因為，我過去就曾對 Literature notes 的產製流程感到困擾，即使用最快的速度整理，每篇文章可能也要 20-30 分鐘來整理 notes ，但這樣做的意義卻似乎沒很大，不如直接寫成我的想法，然後適度引用就好。

另一部分是，今天花了不少時間在看 Andy Matuschak 的 notes，覺得更理解他提出的 Evergreen notes 概念，覺得這整套好像是更適合我的作法，而在這裡面似乎不太需要「Literature notes」這個分類。

我覺得可能的原因有：

1. 既然打定主意要讓自己的知識庫公開，那直接透過 Dendron 紀錄更直接一些。
2. 目前為止 Dendron 的層級化體系好像讓我對自己紀錄的內容更有掌握一些。
3. 我已經足夠熟悉各種不同工具以及方法論，所以慢慢地可以透過不同工具都能達到類似的效果，此時關鍵的差別就在於我更喜歡 Dendron 的 publish 方式，所以這個優點決定了一切。

今天在看「個人 wiki」相關的資料，看著看著就看到 wiki 的介紹，也聯想了不少事情。

發現「wiki」這東西雖然隨著我求學的過程成長發展，但我以前從來沒有「真正」去了解這是什麼。

所以高中＆大學時，即使老師說「wiki上的資料很多錯誤」，我也沒有去探究「為什麼」。

但印象中，也沒有老師嘗試跟我們說明「為什麼 wiki 上的資料很多錯誤」，只有叫我們不准抄 wiki 。

我後來覺得，這樣的指示也不是最好的，最好的做法是，明確讓學生知道 Wiki 上面的資料是怎麼來的，並且教學生該如何判斷上面的資料是否可信。

「不能抄 wiki 」是合理的要求，但更好的做法是說明「該怎麼透過好找的 wiki ，去找到更多更有價值的資料，進而寫出自己的東西」。

先姑且不論太抽象層面的概念，單純就日常生活的情境來回答這問題好了。

對我來說，信任好像就像是展開自己的柔軟面（但也脆弱）給對方，這樣做的優點是有機會也獲得對方的柔軟，但缺點是可能被對方傷害，所以信任只能逐步建構與累積，也會視對方的具體表現（例如是拿刀相向還是展現友好）來決定是否展現自己的柔軟。

因此，信任「通常」無法一蹴可幾。但換個角度想，能夠快速建構信任的人或事物（或 "protocol" ）就很有價值了吧。

以之前寫論文的經驗來說，問題意識是貫穿整個寫論文過程的重要元素。 以之前寫影片腳本的經驗來說，問題意識是引起觀眾觀看動機、維繫觀看動機的重要元素。

我似乎感覺到每日這樣練習問 why ，雖然有時會卡住，但好像真的有機會慢慢進步。

例如，我自己以前只會嘗試理解「什麼是演算法穩定幣」，但不會特別去問「為何會有演算法穩定幣」，而透過這個簡短的研究跟理解過程（大約花20-30分鐘讀幾篇文章＆自己嘗試找答案），似乎好像就知道了一些以前不知道的事。或者也多了未來產生思考連結的契機，例如，未來再有主打演算法穩定幣的專案出現時，我可能就會好奇他們的目標、動機、願景是什麼。

希望未來有機會連回此則 note 。

之前沒有特別思考過這個問題，但現在值得問問看。

有種說法是，與美元資產綁定的穩定幣更有可能被監管，而 algo-based 則有機會跳脫這樣的框架，成為一種「crypto-native」的資產。這樣的資產會更適合 De-Fi 的願景。

看起來是基於某種去中心化的情懷，但它真正比 asset-based stablecoin 好的地方在哪呢？

有個比較合理的說法是「成本低」，換句話說是進入門檻較低。

我自己的幾個猜想：（這些猜想都還未被我自己驗證或研究）

• 這樣的系統初期建構成本比資產支撐型的穩定幣低廉。（低成本類型的創新）
• 這樣的類型感覺更容易主張去中心化，因此可能被認為更有機會脫逸監管（但真的有人這樣主張嗎？為什麼？）
• 因為系統較複雜，就多了利用資訊落差牟利的機會。

嘗試把這問題丟到 Twitter 發問，不知會否有人提出有意思的答案。

今天最大的幣圈新聞應該就是 Luna 以及其穩定幣 UST 的崩潰了

有個說法是這是一場精心策劃的狙擊，如 8400万美元撬动400亿金融帝国，UST崩盘始末 - 律动BlockBeats 。

也有人認為這種崩潰本來就是預料之中遲早會發生的事情，因為 Terra/Luna 系統以高額利率誘使人進場的模式很像是龐氏騙局。

但也有一種說法是，許多東西都是 Ponzi ，只是倒了還是沒倒的區別而已。

對於這類的說法我比較沒感覺，我好像更喜歡那種「明確指出哪些是 Ponzi ，為什麼？；哪些不是 Ponzi ，為什麼？」的論述方式。

2022.06.01 Wednesday 看到的 DeFi 穩定幣的過去與未來：寫在 Terra UST 崩盤後 有提到， Terra UST 的弱點與失誤在於：

1. 雙幣設計本來就較難防守，卻又直接使用內生變數「鑄幣稅代幣」LUNA 作為主要支撐，容易觸發死亡螺旋。

2. 沒有足夠的應用場景；UST 180 億美元的發行量中，有 110 億美元存放於 Anchor 中孳息，如此過度集中且價值無法當下實現的應用場景，加速 UST 使用者於危機時做出拋售的決策，且市場沒有任何接盤買進的誘因。

3. 30 億美元的 BTC 儲備，無法有效保護 180 億美元的 UST 發行量（僅 17%）。

4. 雖然 Terra 後來另外增加了 BTC 作為其儲備，但這並不是一個最佳的選擇。Terra 應該選擇抵禦力更強大的 USDC、USDT 等作為第一道防線。就如同任何央行的第一道防線，都會是外匯存底，而不是黃金儲備。

5. 被大戶砸盤的 UST 剛剛開始脫鉤時，發行商在流動性操作上太過生疏輕率，錯失護盤的黃金時機，UST 與 Luna 都在一週內全數崩盤，加起來超過 500 億美元市值憑空蒸發。

專案能否如期交付，取決於我們自己能否準時製作完成，以及客戶能否如期回覆、而回覆的內容是否可控。

但客戶一但拖延交付，就會讓整個專案的進度延宕，甚至影響其他專案的進度，也會造成產能的空轉。

但客戶為什麼會晚回覆？

我想到的可能原因有：

1. 客戶就是這樣拖延的個性。
2. 客戶有更重要的事情要處理，因此延宕了委託我們做的事情的回覆。
3. 我們給的東西太多，工作時程內處理不完回覆。
4. 我們給的東西太糟，有太多點必須回覆，所以無法如期回覆。

那麼，對於這樣的狀況，可以怎麼做較好？

目前會嘗試的做法是：

1. 逾期後，再詢問客戶，是否有已經確定的部分？而沒確定的部分，是否有需要直接約會議討論？
2. 跟客戶提到若遲不回覆，可能會延宕後續的專案進展。
3. 單純提醒一下，請對方要記得回覆。

這三種做法目的不一，視客戶類型與性格而定。 第一種是有更明確的推動意圖，通常會用在對時程或品質有明確要求的客戶。 第二種對我來說比較像是轉移談判的主客優勢，藉由這樣的留底，讓客戶未來必須要接受我們的時程規劃與安排。 第三種是那些比較沒有明確時間目標的客戶，那就是單純提醒一下，讓對方重新將「回覆」這件事情的優先序提高。

不過，這些做法有解決客戶「為什麼會晚回覆」的本質原因嗎？有沒有更好的做法呢？

這好像是個很常見到的質疑：

使用那麼多生產力工具，真的比較有生產力嗎？

我的回答是：有的。

甚至即使是「亂嘗試各種生產力工具」，對我來講都是很有生產力的事，因為透過這過程也可以釐清自己喜歡什麼、對什麼感到興奮、對什麼感到好奇，以及對哪些工具無感。這些想法累積起來就有機會提煉出一些更有價值的想法。

在旁人眼中，我可能是那種一直在變換工具的人，一下 DEVONthink, Obsidian, Workflowy, Logseq, Heptabase, Dendron ... 好像每隔一兩個月，就會把自己的系統大改一番，跑到別的地方去。

但我覺得這些轉換是漸進的，也是一個嘗試找出自己對於工具最在意的重點的必經過程。

從這條產品線可以看到，有幾個元素是我特別重視的：

1. markdown based
2. local first （workflowy 跟 heptabase 沒有，但我信任他們）
3. backlinks

邊打邊發現，這些想法沒有回應到原本的問題。

嘗試重新回答一次：

1. 因為我對不同工具的差異點，以及他們嘗試提出的解決方案很感興趣。
2. 每次讓我想嘗試的工具，都有在某一方面解決我之前無法被解決的需求。

換句話說，只要我有需求尚未被滿足，那就存在著換新工具的可能性。

那我還有哪些需求呢？

層級化的優點可以參考 Dendron 創辦人 Kevin S Lin 在A Hierarchical Tool for Thought裡面的這段文字：

1. You can create, find, update, search, and remove information by looking up their hierarchies.
2. You can remember your hierarchies with schemas, custom metadata to describe and enforce the shape of your hierarchies.
3. You can transform your hierarchies, either a single note or an entire hierarchy at a time.
4. You can combine hierarchies with other constructs like tags, backlinks, and note references.
5. You can capture chronological as well as ad-hoc information using Dendron's builtin hierarchies
6. You can visualize your hierarchies through hierarchical graph views
7. You can share any subset of your hierarchy as a published site.
8. You can move your notes and their hierarchy to any other tool.

但層級化架構的問題在：一個筆記不一定只出現在一個地方，因此過早思考他的「層級」與「位置」可能會讓使用者感到阻力。

對於這種是否選擇層級化的兩難，我覺得透過「Daily Journal/notes」這種固定的格式來紀錄是個好方法。

從整個筆記庫的架構來看，Daily Journal 本身就是一個僵固的類別，層級與位置不需要動腦就可以產生。

但以個別筆記來說，Journal 裡的內容仍可以擁有彈性，並且可以透過 tags, backlinks 以及 embed notes （在 Dendron 裡面叫做 note references）來達成交互參照以及讓同一筆記出現在不同地方的需求。

• 對知道我不知道的事情的人，例如在嘗試新工具或學習新技術時，詢問有分享過經驗或想法的人，因為我覺得向他們學習更有效率。（但這些比較屬於 How 的問題）
• 針對我在意的事情向人提問，通常會在這件事的發展與我預期不符時發生（超出預期時會問怎麼辦到的，低於預期時會問「為什麼會這樣」）
• 但問「為什麼會這樣」容易有責罵感，可能需要換個方式問，例如：「是發生了什麼意料之外的狀況嗎？」

• 今天一整天都在嘗試使用 Dendron 建構我的 wiki site，詳細的步驟之後再來分享，中間遇到了好幾次障礙，差點想放棄。
• 在這邊簡單描述一下整件事的概念，其實跟之前在部落格寫的 Pin 起來改版了！從 Wordpress 搬家到 Zola！ Zola 部署概念很像。
• 在 Dendron 資料的根目錄裡面，配置好 Netlify.toml 以及依照官網教學文件建立的 dendron-publish-site.sh 文件後，就可以在 Netlify 裡面直接抓取整個 repository ，並且進行自動部署。
• 換句話說，未來的自動部署也不一定要透過桌面版的 Dendron 進行，只要 repository 有變動， Netlify 就會自動部署差異的內容。
• 這點跟 Zola 的部署方式很像，差異可能在客製化程度以及部署的時間，但兩者類似的流程讓我可以用類似的工具來經營，覺得這是很棒的事。

• 今天在透過 Dendron 的官方文件學習 publish 功能時，走了不少彎路，一直卡在一個 bug 裡面，後來我幾乎是逐步驟測試，才發現出現問題的步驟是什麼。
• 想起之前在學習透過 Zola 部署網站時，也發現文件上的內容看起來已經有點過時了。
• 我還沒有維護過面向客戶的技術文件，所以不確定這件事的本質原因可能會是什麼。表層的原因可能是資源不足，或者覺得這件事沒那麼重要，但流程上是否有改善的空間？現行的工具有沒有適合拿來處理這個問題的？
• 希望以後的自己有能力回答這些問題。