Telegram Bot 作為個人審稿工作流：把 AI 草稿關進審查閘道

解鎖條件

你需要先踩過這個坑才會懂這篇文章的價值：

AI 寫文章很快。快到你來不及審查。然後某天你打開部落格，看到一篇語氣正確、格式完整、但論點根本不是你想說的文章已經上架了。

那個瞬間的違和感，就是這套工作流存在的理由。

我有一個排程任務，每天早上 9 點會觸發一個 Claude Code 的 scheduled task，自動選題、生成草稿、git push 到 repo，然後——等待我的審查。

等待的媒介，就是 Telegram Bot。

這個問題值得先回答，因為選錯工具代表這個工作流注定廢棄。

Email 死了。不是字面上的死，是認知上的死。我的 Email 是一個「稍後再看」的墓地，任何要求即時反應的東西都不應該丟進去。

Slack 太重。Slack 是工作協作工具，開一個 Slack workspace 只為了自己審稿感覺像是在辦公室裡獨自開會。而且 Slack 的 Bot 設定相對複雜，有一堆 workspace 權限要處理。

Telegram 剛好。理由很具體：

這套設計的核心哲學是：審查必須發生在我已經在的地方，而不是要求我去一個新地方。

排程任務每天自動執行，產出三件事：

草稿狀態在 frontmatter 裡標記為 status: "draft"，這個欄位是整套工作流的狀態機核心。

標頭訊息長這樣：

📝 每日草稿審稿通知
日期：2026-04-01
Slug：008-telegram-bot-editorial-workflow

閱讀下方全文後回覆：
• approve 008 ✅ 核准上架
• revise 008 ✏️ 需要修改
• reject 008 ❌ 退稿

這個標頭的設計重點是：指令要夠短、夠好記、不需要查文件就能執行。我用最簡單的關鍵字 + 編號，讓未來可以接入 Bot 的自動解析邏輯。

這層完全是人工的，也刻意保持人工。

我讀草稿、判斷它是否符合我想說的話、決定要核准、退回修改，還是直接砍掉。這個決定不應該被自動化，因為品牌聲音是人格的延伸，不是規則集的輸出。

AI 可以模仿風格，但無法判斷「這個時間點我想說這件事嗎？」這個問題只有我能回答。

審查的時間成本大概是 5-10 分鐘。這是我願意接受的上限。如果審查需要花 30 分鐘，這套工作流就注定廢棄，因為代表 AI 生成的品質太差，需要大量改寫。

目前這層還是半手工的。當我回覆 approve 008，下一步是手動把檔案從 content/ai-drafts/ 移到 src/content/blog/，改 status: "published"，然後 push。

但這層是最適合再自動化的地方。未來計劃是讓 Telegram Bot 接收我的回覆，觸發一個 webhook，自動執行搬檔 + git 操作 + 觸發 Vercel 部署。

這就是為什麼指令格式很重要——它是給未來的 Bot 解析的協議，不只是給現在的我看的備忘。

Before（沒有這套工作流）：

AI 生成草稿 → 草稿存在某個資料夾 → 我忘了 → 兩週後發現一堆沒有審查的草稿 → 心理壓力累積 → 關掉自動化任務 → 部落格死掉

這個循環我親身經歷過。問題不是 AI 寫不好，而是沒有一個機制強迫我在正確的時間面對草稿。

After（有 Telegram 審稿工作流）：

AI 生成草稿 → Telegram 通知進來 → 我在有空的時候讀完 → 回覆一行指令 → 繼續過我的生活

關鍵差異是：通知送到了我已經在的地方，而且讀完草稿這個動作被設計成可以在手機上完成，不需要切換到桌機或打開特定工具。

我把這套工作流想成是在 AI 和發布之間插入一個人類閘道。

閘道的作用不是懷疑 AI 的能力，而是確保我對每一篇出去的文章都有主觀意識。這件事用工程語言說就是：每一個 commit 到 src/content/blog/ 的檔案，都必須經過我的審核簽章。

這個閘道設計得夠輕、夠快，才能長期維持。

目前這套工作流已經跑了一段時間，我的感受是：Telegram 通知本身就是一個很好的「每日儀式」提醒。它在說，今天有一篇草稿在等你，你要不要花五分鐘看一下？

大部分時候我會。

偶爾我不會。那篇草稿就繼續等，直到我願意看它。這也是可以接受的——工具不應該懲罰人類的不規律，它應該在你回來的時候，安靜地把工作遞給你。

我這套工作流背後有一個更大的信念：自動化的終點不是取代判斷，而是把判斷時刻設計得更好。

AI 處理生成、git 處理版本、Telegram 處理通知，這些工具各司其職。而我處理的那一層，是最不應該被自動化的——我想說什麼。

一旦搞清楚這個邊界，工具選擇就會變得很清晰。你不是在找最強的 AI，你是在找最清晰的工作流。