大多數自動化工具的下場都一樣。有人設計了很聰明的東西,在聊天視窗裡跑一次,闔上筆電去吃晚餐,然後整件事就消失了。腳本從來不是弱點——筆電才是。筆電必須保持開機、插電、喚醒,工作才能繼續進行——但筆電的設計初衷恰恰相反。
Mac mini 沒有這個問題。基本款大約台幣 18,000 元起,耗電比一盞檯燈還少,安靜到幾乎沒有聲音,而且它的工作說明只有一條:保持開機。這個特質正是它成為人們默默把 Claude 工作流程託付給它的機器。
本文將介紹三個這樣的工作流程——一個自動分類的收件匣、一個在夜間自動審查的 Pull Request、以及一個會給你簡報而非只是會議標題的行事曆——全都跑在擺在家裡某處的 mini 上,做著沒人需要記得去啟動的工作。

為什麼不直接用 Claude 聊天視窗來做?
你已經可以把電子郵件貼到 Claude 裡,請它草擬回覆。你也可以貼上 diff 要求審查。本文沒有任何內容需要聊天視窗不具備的功能。
改變的是誰按下「執行」鍵。
在聊天視窗中,你每次都是觸發者。你打開分頁、貼上內容、閱讀答案、複製到別處。一旦你停止這些動作,流程就停了。這是一個只有在你手上時才會動的工具。
在 mini 上,觸發者是一個時鐘、一個 webhook、或是一個新檔案落在某個資料夾裡。Claude 執行工作,根據你事先寫好的規則檢查自己的輸出,然後送出或重試——完全不需要任何人打開筆電。這就是「我使用的模型」與「正在運行的系統」之間的全部差異。
桌上到底放了什麼
三個層次,沒有一個是特別的:
機器。 一台 Mac mini,執行 launchd 任務(macOS 上比 cron 更好用的表兄弟),在排程時間或檔案變動時觸發 Python 腳本。任何小型、永遠開機的 PC 都能做到同樣的事——只是 mini 剛好安靜、運行成本低、而且小到可以藏在螢幕後面。
儲存。 單純的資料夾和 Markdown 檔案,加上工作流程直接接觸的東西——透過 IMAP 連線的收件匣、本地端複製的 GitHub 倉庫、同步到 .ics 訂閱的行事曆。沒有任何東西存在別人的應用程式裡。如果 mini 明天消失,它產生的每一個檔案依然可以在任何電腦上正常開啟。
推理引擎。 Claude,透過 API 呼叫。Sonnet 處理任何需要真正判斷的事情——決定一個 Pull Request 是否安全可以合併、草擬聽起來像你的回覆。Haiku 處理便宜、大量的事——分類、標記、是/否檢查。把工作這樣拆分,是 monthly bill 能維持在低於一杯咖啡訂閱費用的主要原因。
現在來看實際的工作流程。
例行工作一:收件匣在你查看之前已經清空雜訊
大多數收件匣裡並不是充滿困難的決定。它們充滿了根本不需要你處理的東西——電子報、日曆確認、供應商問了一個你已經回答過五十次的問題。困難的不是回答它們,而是每一個都偷走你二十秒的注意力,甚至在你決定怎麼處理之前。
1執行時間: 每 15 分鐘一次,工作日2監看: 主要收件匣的新郵件34步驟:5 1. 拉取同一郵件串的最後 10 封郵件以取得上下文6 2. Claude 分類新郵件:7 - 例行(確認信、電子報、自動回覆)8 - 需要回覆(真正的問題、請求)9 - 需要人為判斷(金錢、衝突、任何模糊情況)10 3. 例行 -> 自動封存,記錄在每日摘要中11 需要回覆 -> Claude 以我的語氣草擬回覆,儲存到草稿,12 未經我開啟絕不寄出13 需要人為判斷 -> 保持原樣、標記,不嘗試草擬1415檢查: 分類必須包含一行理由。如果 Claude 無法產出引用實際郵件內容的理由,16 該項目預設落入「需要人為判斷」。17停止: 批次中的每封郵件都已分類,或任何一封郵件重試 3 次後18 直接標記給我處理
這裡重要的規則是後備方案。任何 Claude 無法自信分類的內容不會被猜測——它會像平常一樣落在你手上。這個工作流程並不是要取代那 10% 困難情況的判斷力。它只是要阻止那 90% 簡單情況偷走你的注意力。
例行工作二:Pull Request 在你醒來前就完成了第一輪審查
程式碼審查有一個奇怪的失敗模式:最重要的審查——也就是晚上 11 點送進來的 PR——最有可能在半睡半醒中匆匆完成,或者更糟的是,帶著「我明天再看」的念頭被合併,然後再也沒有下文。
1執行時間: 每次新的 Pull Request 時,透過 GitHub webhook 觸發23步驟:4 1. 拉取 diff 和關聯的 issue(如果有的話)5 2. Claude 根據固定評分表進行審查:6 - 是否符合關聯 issue 的實際範圍?7 - 是否有任何變更影響到認證、付款或遷移?(標記,不判斷)8 - 變更行數的測試覆蓋率——有或沒有?9 - 命名和結構是否與檔案其他部分一致?10 3. 評論直接貼在 PR 上,每個評分項目給 1-5 分,11 並明確指出最弱的兩個點1213檢查: 只有引用具體行號的評論才會被貼出。14 沒有行號參考的評論會被丟棄並重試——15 模糊的反饋不值得送出。16停止: 評論已貼出,或經過 2 次重試後 PR 保持原樣,17 並附註自動審查無法完成
這裡沒有任何東西會自動合併。它只是一個永遠不會疲倦的第二雙眼睛,在你真正開始審查之前就先出現在 PR 上。根據固定評分表打分數,是讓它保持實用的關鍵——一個被要求「自由審查這段程式碼」的模型傾向於要嘛讚美一切,要嘛隨機挑剔。一個被要求針對四個固定問題評分的模型,每次都會產出相同類型的反饋,這正是讓它在早上 8 點值得閱讀的原因。

例行工作三:會議附帶簡報到來,而不只是標題
行事曆邀請告訴你時間和地點。它幾乎從來不告訴你走進會議前真正需要記得什麼——和那個人的上一封郵件串、上次會議的未決事項、有人會問的那個數字。
1執行時間: 每個有 2 位以上與會者的行事曆事件前 45 分鐘23步驟:4 1. 拉取最後的郵件串,以及任何與與會者姓名或事件標題5 關聯的共享文件6 2. Claude 撰寫一頁簡報:7 - 上次同意了什麼(如果有人)8 - 一個值得提出的未決問題9 - 上次交流中提到的任何數字或日期10 3. 在事件前 30 分鐘以推播通知送達1112檢查: 簡報必須引用實際的先前郵件或文件。13 找不到之前的上下文 -> 通知顯示「找不到歷史記錄」,14 而非捏造的摘要。15停止: 已發送,或如果與會者都是新人則完全跳過
最後一個檢查值得特別留意。當 Claude 找不到真實上下文時,它可以輕易地憑空寫出一個聽起來合理的簡報——而一個聽起來合理的假簡報比完全沒有簡報更糟,因為你會相信它。強迫它誠實地說「找不到任何內容」,這正是讓那些有簡報到來的會議值得閱讀的原因。

上述所有工作流程依賴的兩條規則
把具體細節拿掉,每一個例行工作都建立在同樣的兩個護欄上。
一個可檢查的規則,而不是模糊的感覺。「分類這封郵件」是模糊的感覺。「分類這封郵件,如果你無法引用證明該標籤的句子,就預設為安全類別」是一條規則。差別在於 Claude 是根據具體標準來評分自己的作品,還是只是產出一個聽起來完成了的東西。
一個真正的停止條件。 上述每個例行工作都有重試次數的硬上限,以及當它無法乾淨完成工作時定義好的後備方案。沒有這個條件,一封格式錯誤的郵件或一個 diff 有問題的 PR 就會開心地一整晚都在重試迴圈中消耗 API 呼叫,而帳單會比 bug 報告先出現。
把這兩件事做對,具體任務是什麼幾乎不重要——收件匣、程式碼、行事曆、或任何其他東西。
先用手動方式感受一下,再來建立自動化
這些都不需要一開始就碰終端機。你可以在一般的 Claude 對話中執行同樣的架構,看看它是否真的對你有用,然後再自動化:
1你將逐步完成這個任務,在每個階段檢查自己的輸出,2然後再宣告完成。34任務:5[你想要處理的事情]67通過規則:8- 執行工作。9- 根據以下條件檢查:[具體、可檢查的條件]10- 如果未通過檢查,說明哪裡有問題,並只重做那部分。11- 如果通過檢查,說「完成」並停止。12- 永遠不要問我釐清問題——做出最合理的假設,13 用一行說明它,然後繼續。1415開始。
這就是整個機制的縮影。沒有 mini、沒有 webhook、沒有排程——只有 Claude 根據規則檢查自己的作品,而不是在產出第一個看起來合理的草稿後就停下來。如果你在手動模式下對同一類任務執行三到四次,並且持續回頭用它,那就是訊號——值得把它放到一台不需要你記得去啟動的機器上。
避免在凌晨 2 點崩潰的順序
沒有人是從寫 cron 任務開始而可靠運行這些的。真正經得起考驗的順序是:
- 在聊天視窗中手動執行,直到輸出穩定正確。
- 把那個精確的提示轉成腳本——邏輯不做任何變更。
- 在加入任何其他東西之前,先加入檢查和重試次數限制。
- 然後才把它連接到排程或 webhook。
直接跳到第四步,你會用最痛苦的方式學到「沒有停止條件」的代價——通常是在一個充滿重複的 PR 評論的早晨,或是寄件備份匣裡躺著一百個完全相同的草稿。
這實際上為你買到了什麼
這些都不會讓 Claude 變得更聰明。它製造的是「你使用的東西」和「無論你是否注意都在運作的東西」之間的差別。mini 不是有趣的部分——它只是讓工作流程擁有一台永遠不需要重新啟動的機器,最便宜、最安靜的方式。
從本文中的手動版本開始。如果你發現自己用手動方式執行了好幾次,那就是值得把它放到一台你上床睡覺後還會繼續開著的機器上的那個。





