解鎖條件
上一篇文章的最後留了一個未完成的項目：
approve 按鈕真正觸發
/api/approve
不是沒做，是 webhook 通了、Bot 回應了，但從「收到 approve 訊號」到「草稿搬進 src/content/blog/、觸發 git push 上線」這段，還缺一條真正的橋。
AI 能寫草稿。系統能把草稿存進 content/ai-drafts/。但如果核准流程要開電腦、手動 commit，那就不叫自動化，叫「用 AI 多了一個步驟」。
這一步非打通不可。
設計原則：為什麼不全自動
在開始之前，先解決一個問題：為什麼不讓 AI 寫完就直接上線？
因為 AI 會犯一種特定的錯——它很少「捏造事實」，但它很擅長「補上聽起來合理但我沒說過的過渡句」。
一人公司的部落格是對外的臉。一篇語氣跑掉或細節錯位的文章，修正成本比省掉的審稿時間貴。
所以這個系統的設計原則是：AI 負責草稿，人負責最終決定。核准流程存在，但摩擦力要低到手機拿起來兩秒就能完成。
副本攻略
整條鏈分三段：
段一：/api/approve——執行引擎
這是 Next.js 裡的一個 API Route，它做兩件事：
- 身份驗證：收到請求時比對
APPROVE_SECRET，防止任意觸發。 - Promote + Push：把
content/ai-drafts/[slug].md的內容複製到src/content/blog/[slug].md，更新 frontmatter 裡的status: "published"，然後呼叫git add → git commit → git push。
Push 到 GitHub 後，Vercel 偵測到新 commit，自動 build + deploy。
關鍵細節：伺服器要能跑 git 指令。Mac Mini 上的 n8n 自架環境天生有這個條件，但如果部署在 Vercel Serverless Function，就需要另外處理 git 操作（改用 GitHub API 寫入檔案並 commit）。這個版本先用 Mac Mini 本機跑，不依賴 Serverless。
段二：n8n Workflow——中間層
n8n 在這裡扮演「翻譯官」：把 Telegram 的人類語言（按下按鈕、輸入指令）翻譯成 API 呼叫。
Workflow 邏輯：
Telegram Bot 收到 /approve [slug]
→ 確認 slug 是否存在於 ai-drafts/
→ 呼叫 /api/approve，附上 slug + secret
→ 等待 API 回應
→ 回傳成功 or 失敗訊息給 Telegram失敗的情況也要處理：slug 不存在、secret 錯誤、git push 失敗。每一種失敗都要有明確的錯誤訊息，不能讓 Bot 沉默消失。
段三：Telegram Bot——操作介面
操作介面故意設計得很薄。
當 AI 生成新草稿時，n8n 自動發送審稿通知到 Telegram，格式如下：
📝 新草稿待審
標題：Telegram 一鍵核准：讓 AI 草稿真正上線的最後一哩路
描述：部落格的自動化架構建好了，但 approve 流程還差一步...
字數：約 1400 字
操作：
✅ /approve 005-telegram-approve-publish-flow
✏️ /revise 005-telegram-approve-publish-flow [修改備註]
❌ /reject 005-telegram-approve-publish-flow三個指令，對應三種決定。Approve 上線，Revise 留存加備註等修改，Reject 刪除。
手機上收到通知，看標題和摘要，決定，發一行指令，完成。
流程走一遍
從頭到尾：
- AI 在 Cowork 生成草稿，存入
content/ai-drafts/005-slug.md - n8n 偵測到新檔案，發 Telegram 審稿通知
- 我在手機上看預覽，傳
/approve 005-slug - n8n 呼叫
/api/approve?slug=005-slug&secret=xxx - API Route 讀檔、更新 status、git push
- Vercel 收到 push，自動 build + deploy
- 文章上線，n8n 回傳 Telegram：「✅ 已上線：[文章連結]」
整個流程裡，我做了一件事：傳一行文字。
人在迴路裡的意義
這個設計有一個更深的理由，不只是防止 AI 出錯。
把「核准」這個動作保留給人，是在強迫一件事：每篇文章上線前，都有人讀過它至少一遍。
AI 的速度是資產，但速度快到沒有人看就上線，那個部落格就不再是人的表達——它只是一台內容機器。
兩秒的審稿動作，是系統效率和人的判斷之間的界線。這條線值得守。
Before / After
Before：草稿在 ai-drafts/ 裡躺著，要上線得開電腦、手動 commit、等 Vercel。通常就放著沒發。
After：手機收到通知，看 30 秒，傳一行，60 秒後文章上線。
下一步
- Revise 流程完整化：
/revise指令要能把修改備註寫入草稿的 frontmatter，下次 AI 讀到時知道要調什麼方向。 - 電子報串接：上線成功後，n8n 呼叫 Resend API，自動通知訂閱者。
- 多草稿管理：當
ai-drafts/裡累積超過三篇待審，自動發提醒，避免草稿堆積腐爛。
系統不會自己長成熟。每次補一個節點，每次打通一條路。這篇是第五步。