我記得上一次登入 blog 後台是什麼時候嗎？
想了一下，是三個禮拜前。那次是因為要確認一篇文章的 slug 有沒有衝突，進去改了一個字，然後登出。
在那之後，所有的審稿都是在 Telegram 上做的。AI 生草稿、git push、把整篇文章傳到我手機上，我讀完，回覆 approve 或 revise，工作就完成了。後台就像一個不常開的抽屜，放在那裡，偶爾需要的時候再打開。
一開始我沒有特別注意這件事。後來有一天在店裡備料，突然想到：這不是跟甜點店的外場一樣嗎？
外場不進廚房，菜一樣端得出來
月島有一條隱形的線，劃在廚房門口。
外場的工作是讀懂客人的狀態，把菜端對時間，在客人需要之前就補好水。廚房的工作是把東西做好。兩邊各司其職，才不會互相踩線。
外場不需要知道千層夾了幾層奶油，也不需要懂焦糖化的溫度控制。他只需要知道一件事：這塊蛋糕，應不應該現在送出去？
這個判斷，本來就不需要走進廚房才能做。
我的 Telegram 審稿流程也是這樣運作的。
每天早上，系統自動生草稿，push 到 git，然後把整篇文章傳到我的手機上。我讀，我感覺，我決定。不需要登入任何後台，不需要看任何設定，不需要搞清楚那篇文章是怎麼被 AI 寫出來的。
我只需要知道：這篇，應不應該發出去。
介面決定你的思維模式
用後台審稿和用手機訊息審稿，感覺完全不同。
登入後台，你進入的是「管理員模式」。你會開始注意標題格式對不對、分類有沒有選好、圖片有沒有上傳。這些都是重要的事，但它們全部都不是「這篇文章好不好讀」的核心問題。
用手機訊息讀一篇文章，你是在「讀者模式」。你只能看文字，只能感受，只能做一個決定：這個我想繼續讀嗎？讀完之後有沒有某一句話讓我停下來想了一下？
這兩種模式會做出完全不同品質的判斷。
管理員模式容易讓你在細節裡打轉——改一個詞，調一下標題，換一張圖，然後在「應該怎麼更好」的問題裡繞圈。讀者模式逼你回到最根本的問題：這篇值不值得一個人的時間？
我把 Telegram 當外場，是因為它強迫我用讀者的眼睛做決定，而不是用管理員的眼睛找問題。
限制本身就是設計
很多人覺得只用手機做內容決策是一種將就。後台不打開是因為懶，不是因為有什麼深思熟慮的理由。
但我越來越覺得，有些時候，限制才是設計出來的保護。
如果我隨時可以進後台，我會隨時改文章。改個詞、調個格式、換個標題——每次改動都會讓我從「這篇我有感覺」變成「這篇技術上正確」。最後發出去的可能是一篇很工整、但沒有呼吸感的文章。
Telegram 的限制很明確：你只能看，你只能回覆。你可以說「第三段改一下語氣」，但你沒辦法直接進去把那段字改掉。
這個邊界讓審稿這件事變得純粹。讀完，有感覺，說可以。或者讀完，某個地方卡住，說改這裡。不多、不複雜。
甜點店的外場也有這樣的邊界。外場的工作不是改菜，是判斷。進廚房改菜是廚師的事，但讀懂客人的狀態、決定出菜時機，是外場的事。這條邊界清楚，兩邊才都做得好。
也許「不進去」才是真正的掌控
一人公司最容易掉進的陷阱，不是沒有系統，而是太容易進系統。
所有設定都在眼前，所有東西都可以改，所以你一直在改，一直在優化，一直在調整那個影響輸出 1% 的地方。但真正重要的決定——這篇值不值得讀者的時間，這個月的內容方向對不對——反而沒有人好好坐下來想過。
進後台太容易，反而讓「決策」這件事變得模糊了。你覺得自己在管理，其實你在維護。
外場不進廚房，不是因為他們不關心菜好不好。是因為他們知道，自己的位置決定了自己能做哪種判斷。
Telegram 審稿也是同一個道理。我不進後台，不是因為我不想管。是因為我發現，站在那個距離，我反而看得比較清楚。
三個禮拜了，blog 還是在更新。
外場每天傳菜，廚房每天備料。
菜還是端得出去。
常見問題
只用手機審稿，不會遺漏格式細節嗎？ 老實說會。slug、metadata、圖片路徑這些東西，手機上看不出問題。但我把這類驗證交給 git hook 和 schema 去擋，不靠眼睛。眼睛負責讀文章，系統負責驗格式——分開做，才不會互相干擾。
文章需要大改的時候，Telegram 夠用嗎？ 夠。做法是在 Telegram 裡說清楚要改哪裡，下一次自動化流程跑的時候就會帶著這個反饋重新生草稿。不用進去手動改，系統重跑一次。這個流程當然需要你的反饋說得夠具體——「語氣太正式」比「感覺怪」有用。
這個流程的前提是什麼？ 你得相信你的系統。相信 AI 生出來的草稿大方向是可用的，相信 git 不會無聲出錯，相信格式驗證是可靠的。如果你對任何一個環節不信任，外場就根本拿不到菜，也端不出去。信任是這個流程成立的基礎，不是副產品。