一句話總結

大家會為了已經完稿的書付更多錢嗎？

本月亮點

• Refactoring English 創下銷售次高的月份。
• 我分析銷售數據，想看看大家是不是更願意購買已經完稿的書，而不是接近完稿的草稿。
• 我完成了書籍回饋工具。
• 我正在嘗試用新工具來追蹤時間。

目標評分

每個月月初，我都會訂下想完成的事。以下是這個月的達成狀況：

至少投入五小時優化 Refactoring English 網站

• 結果：花了約三小時優化網站
• 成績：B-

網站有稍微改進，但還需要更多打磨。

為 Refactoring English 網站吸引 3 萬名不重複讀者

• 結果：吸引了 1.75 萬名不重複讀者。
• 成績：B-

我把關於設計文件的章節改寫成一篇免費節錄。這篇文章在 Lobsters 和 Reddit 上反應不錯，但在 Hacker News 上就沒什麼迴響。

設計文件那一章獲得這麼正面的回應，讓我有點意外。平常跟開發者聊到設計文件，大家的主要反應都是討厭設計文件、討厭跟它有關的一切。我這篇貼文底下的留言倒是出乎意料地支持設計文件本身，也肯定了我提出的建議。

完成讀者回饋工具

• 結果：工具已經上線運作。
• 成績：A

我一度卡在那場大規模 AI 封鎖，但後來我更認真思考如何把大功能拆小，也不再那麼執著於程式碼品質，才總算突破。在這種情況下，先完成比追求完美更重要。

Refactoring English 數據一覽

六月是自最初群眾募資上線以來，書籍收入最高的月份。訪客增加是因為我那篇關於設計文件的節錄。

最後 8% 到底差多少？

過去幾個月，Refactoring English 網站在搶先體驗期間一直把這本書標示為接近完稿。我很好奇，從一本接近完稿的書變成完全完稿，對銷售會有什麼影響，所以我看了每週的銷售數據：

把書標示為完稿，對每週銷售似乎沒有明顯影響，但如果看日平均呢？

好吧，標示為完稿之後，確實有小幅的成長。

我也很好奇，是不是特別是美國的讀者，在我完稿後購買的比例變高了。每次有人買書我都會收到 email 通知，感覺上付美國定價的客戶變多了，但我沒有仔細量化過。我去查了資料，看看是不是真的如此：

有趣的是，完成這本書對使用區域定價的客戶銷售完全沒有影響，但以美元付款的客戶，在完稿後的三週內購買率多了 20%。

我沒有把發表最新節錄之後的銷售算進來，因為那顯然會讓數字變動很大，所以我把它當成獨立的類別來看：

但這樣還是有點失真，因為美國人本來就占我讀者的大多數。如果把收入用訪客人數來標準化，會怎麼樣呢？

喔，結果整個反過來了。把數字用訪客數標準化之後，故事就翻轉了。現在反而是美國人對完稿與未完稿的書購買率差不多。反而是美國以外的讀者，在完稿的書上每位訪客多花了約 20%。

我還不太確定該怎麼運用這個資訊，不過至少滿足了我的好奇心。

讀者開始在書籍 App 裡留下實用的回饋

我以前也請讀者針對這本書給回饋，有些讀者給了很熱情的回應，但那終究是少數。我覺得如果做一個網頁版的回饋 App，讓讀者在閱讀時可以直接留下筆記，應該會很有趣也很有幫助。這看起來像是一、兩週就能搞定的東西。結果，短短的……兩個月後，我終於把它上線了！

我的回饋工具才上線幾天，但似乎真的有鼓勵更多讀者提供回饋。有一位讀者剛讀完整本書，還特別提到回饋 App 是他體驗中最喜歡的部分之一，這讓人很開心。

時隔 15 年，再次使用時間追蹤工具

大概每年一次，我都會問自己：我的時間都去哪了？每當我專注在一個專案上，卻發現進度不如預期時，這個問題就會浮現。過去幾年我也問過自己好幾次：

• 2022
• 2023
• 2025

這次我想：「或許該用個時間追蹤工具看看。」

大約 15 年前，我試過一個叫 RescueTime 的時間追蹤工具。我覺得不太有用，但還是想說試個幾週看看。後來我才意識到，我竟然讓一家來路不明的公司收集我螢幕上出現的每個視窗資料，就立刻把 RescueTime 移除了。

我心裡還在想，要是有 RescueTime 的開源版就好了，突然想到：「等等，搞不好真的有。」還真的有。它叫 ActivityWatch。它是開源而且以隱私為優先的工具。它會記錄你所有的視窗和瀏覽活動，但所有資料都留在你自己的電腦上。

問題是，ActivityWatch 比 RescueTime 陽春得多。我完全看不懂時間軸到底想呈現什麼：

照理說你要設定規則，讓 ActivityWatch 幫你分類活動，但我也覺得那個介面很難用：

我差點就要放棄 ActivityWatch 了，後來又想：「嗯，資料收集的部分應該是正常的。如果我自己用 vibe coding 做一個前端呢？」

所以，我就做了，而且還蠻簡單的。我先從命令列工具開始，之後打算擴充成網頁 App。

要使用我自製的 ActivityWatch 前端，我會建立一個設定檔，根據應用程式名稱、視窗標題和／或網址來分類活動：

- name: Book/Feedback Site
  rules:
    - url: "*refactoring-english-feedback*"
    - window_title: "*refactoring-english-feedback*"

- name: Book/Website
  rules:
    - url: "*refactoring-english-landing*"
    - window_title: "*refactoring-english-landing*"

- name: Book/Writing
  rules:
    - app: Zathura
    - app: Code
      window_title: "*refactoring-english*"
    - app: firefox
      window_title: "mtlynch/refactoring-english *"

然後輸出結果會像這樣：

$ go run ./cmd/app --config data/config.yaml
...
Book               1h34m   19.7%
  Feedback Site      48m   10.0%
  Writing            46m    9.7%

目前為止，資料還蠻有意思的，但最大的挑戰是很難自動把所有活動都分類好。舉例來說，我可以為瀏覽 Wikipedia 新增一個分類，但我到底是為了寫書在做正經研究？還是只是不小心掉進兔子洞，突然開始看起被自己發明害死的發明家列表？

總結

完成了什麼？

• 完成了 Refactoring English 回饋工具。
• 修正了 Refactoring English 電子書，為了一致性和 EPUB 相容性。
• 為 Little Moments 做了一支示範影片。
  • 我對裡面搞笑的照片還蠻得意的。

學到的事

• 顧客其實沒有我想像中那麼在意一本 100% 完稿的書和一本接近完稿的書之間的差別。
  • 讀者確實會以較高的比例購買完稿的書，但如果把網站訪客人數也考慮進去，影響其實很小。

下個月的目標

• 向 5 個 Podcast 毛遂自薦，聊聊 Refactoring English。
• 為 Refactoring English 網站吸引 3 萬名不重複讀者。
• 結束搶先體驗，正式發布這本書的 1.0 版。