開啟率 20% 跳到 90%，我只是把文字早報接進了 podcast
我有個習慣，每天早上 OpenClaw 會跑一份早報，從 Hacker News 和幾個 RSS feed 抓我訂的主題，整理成 markdown 檔。
說老實話，開啟率大概 20%。
不是內容不好。是我根本沒時間在通勤前對著螢幕讀一大段文字——還沒出門就在看手機感覺很糟，到了公司又有別的事，那份早報就躺在 daily-digest 資料夾裡，隔天又有新的進來，上一份直接沒看完。
後來看到有人分享，把 OpenClaw 早報接 TTS+RSS，訂進 Apple Podcasts，通勤聽。我花了一個下午把流程跑通，核心步驟是：早報輸出 markdown → 接 TTS 轉 mp3 → 丟進靜態 RSS feed → 訂閱 URL。有現成的 MCP server 方案，也可以自己開個靜態主機解決，整個流程不複雜。
接上之後，開啟率大概 90%。
我有稍微記錄了一下前後差異：
- 接上之前：每週平均讀完 1-2 份，剩下的存著「之後再看」，幾乎沒有之後
- 接上之後：通勤 35 分鐘，每天幾乎消化完整份早報，遇到感興趣的點還會回去翻文字版
這個差異不是因為內容變好了。是消費場景對了。
我在 SRE 工作裡有個體感：監控告警如果沒人看，比沒有監控還糟，因為你以為有人在盯，其實沒有。AI 早報也是同一個問題——你設計的是「每天早上打開來讀」，但使用者根本沒有那個空檔，整個流程就是斷的。
語音輸出和文字輸出的根本差異，在於它不需要你挪出注意力空檔，它填進去的是你已經在做的事的縫隙。開車、通勤、做家事——這些時間原本沒辦法拿來讀東西，但可以拿來聽。所以聽覺輸出的留存不是因為「格式更好」，是因為它進入了一個文字完全沒辦法競爭的時段。
在公司內部我也試過類似的東西。以前的 incident report 是一份很完整的 Notion 頁面，三頁長，每個 incident 都有人說「之後要回來看」，後來沒有人回來看。後來改成一個 5 分鐘語音摘要傳進 Slack，聽完率直接翻。不是工程師懶，是工程師在修別的東西的時候，能接收新資訊的管道只有聽，沒有讀。
技術細節補充一下，以防有人想試：
我自己用的是 OpenClaw 內建 TTS，語音不算自然，但通勤聽不會去挑這個，內容才是重點。有人說換 ElevenLabs 的 natural voice 聽感差蠻多，不過會增加一點設定成本。早報如果只有文字摘要，一份大概 8-12 分鐘，剛好一段通勤能消化完。如果你的早報比較長，可以在 prompt 裡限制字數，或者只抓前幾則，不然聽到一半就到站了。
最後講一個我觀察到的事：接上 podcast 之後，因為每天都有在聽，早報裡提到的工具我真的有跑去試，這是以前很少發生的事。以前讀完就讀完了，印象很淡。聽的時候比較容易留下「等等這個要試試看」的念頭——不確定是音訊格式本身有什麼特別，還是純粹因為使用頻率拉高之後記憶就強化了。
但結果是，我對早報內容的轉化率比以前高，不只是開啟率，是真的有把資訊用起來。輸出格式不只影響你有沒有打開，它影響你後來有沒有做什麼。
作者：承翰