最近我注意到一件事。
當自動化系統跑起來之後，我開始很常坐在那裡，等自己。
不是等機器，機器都跑完了。是等我什麼時候會去打開那個資料夾、打開那個草稿、決定這篇可不可以上架。
這個「等」，很安靜，但它一直在那裡。
後來我把審稿這件事，搬進了 Telegram。結果發現那個等，大部分消失了。
在你本來就會停的地方出現
我最一開始以為是 Telegram 有什麼特別的功能，但仔細想了一下，不是的。
是因為它出現在我本來就存在的注意力空間裡。
我每天都在看 Telegram。甜點詢問、備料清單的確認、偶爾跟朋友的訊息，都在那裡。那個 App 已經是我的一部分日常了，不需要我特別記得要去打開它。
所以當草稿直接傳過來的時候，它不是要我「切換到另一個地方」——它就在我已經停的地方，等著被看見。
這個差異，小到我一開始沒有意識到它的重要性。
後來我才明白：自動化流程最後一步之所以常常卡住，原因通常不是技術沒做好，而是切換成本太高了。
後台為什麼沒用
在這之前，我試過幾種方式管理草稿。
Notion 的資料庫，欄位設計得很漂亮，status 從 draft 到 published，看起來很有系統感。但每次要審稿，我需要：打開瀏覽器、切換到 Notion、找到那個資料庫、點開那篇文章。
中間有四到五個動作，每個動作都很小，但加起來就足以讓我說「等一下再看」。
等一下，就變成了下週。
也試過寄信到 Gmail，讓自己收到草稿通知。結果草稿就靜靜地躺在收件匣裡，跟其他幾百封信放在一起，某種程度上消失了。
每個方法的問題都一樣：它讓我需要刻意記得「要去那裡」。
Telegram 把這個過程壓縮成零。訊息跳出來，我就在那裡。
審稿流程實際上是怎麼跑的
現在的設計很單純。
每天早上，一個排程任務自動執行，Claude 根據主題池選定當天主題，生成一篇一千多字的草稿，存成 markdown，然後用 Bot 傳給我。
先傳一個標頭訊息：日期、slug、分類、字數、操作說明。
等一秒，再傳草稿全文。如果太長就分段。
我看完，回覆其中一個指令：
approve NNN-slug核准，下一步是手動排進發布流程revise NNN-slug需要修改，說明哪裡偏了reject NNN-slug退稿，這篇重來
指令回覆之後，Bot 接住，執行對應動作。
整個流程的設計前提，是讓「決定」發生在我最輕鬆的時候——早上看訊息本來就是我的習慣，審稿自然夾在其中，不需要多一個儀式。
我最近在想的一件事
自動化流程最難的部分，不是技術。
是設計「人在哪裡介入」。
很多人把自動化理解成「人不用管了」。但我自己的體驗是，完全不介入的流程反而讓我失去控制感，不確定系統在幹嘛，也不確定輸出的東西是不是我想要的。
更好的版本是：讓機器處理所有可預測的事，然後在需要判斷的節點，用最低摩擦的方式通知人，讓人真的去做那個決定。
Telegram 就是那個「最低摩擦的通知介面」。
我不用打開後台，不用進資料夾，不用切換工具。草稿來找我，我在那裡看，決定，繼續去備料。
這篇文章本身，也是用這個流程生成的。
它在某個早晨出現在我的 Telegram 裡。我看了看，覺得還行，按了核准。
如果你也有某個自動化流程，但老是卡在最後一步，也許問題不是流程本身。
是通知放在哪裡的問題。
找到那個你本來就會停留的地方，把決定放進去。流程才算真的跑完。