如何設置 Claude 循環：讓工作在你休息時能持續運行

絕大多數人用 Claude 都係一次入一個提示。

你輸入，佢回答，你睇，然後你再輸入。

當你熄咗電腦或者閂咗 notebook 嗰一刻，呢啲嘢就全部停曬。

而整 Claude Code 嗰個人好耐之前已經唔係咁樣做嘢。

佢自己親口話今年冇寫過一行 code，大部分工作都係透過手機完成，仲有成千個 Agent 喺佢瞓覺嗰陣通宵運行。

幫佢實現呢一切嘅唔係咩秘密模型，而係循環（Loops）。

循環就係按計劃運行嘅 Claude

呢度講嘅計劃其實就係「條件」。同你聽過嘅 if...else 或者 while 循環一樣，佢哋都要滿足某個條件先會觸發或者退出。

單一個提示運行一次就完。但循環唔會，佢會自動運行，一次又一次，唔使你每次都開佢。

呢個機制本身其實好簡單～

你叫 Claude 用 cron 嚟調度任務，同佢講重複嘅頻率：例如每分鐘、每 30 分鐘、定係每晚。

就係咁，冇乜所謂嘅框架、編排層。最簡單有效嘅方案，亦係佢有效嘅原因。

一旦任務可以自動重複執行，Claude 就唔再只係一個 chat 視窗，而係變成一個可以跟住自己嘅時間表自動出現嘅執行者。

關鍵在於將時間間隔同任務匹配。

快速變化嘅嘢就用緊湊嘅循環，而緩慢嘅嘢就可以每晚執行一次。

例如監控 CI 嘅循環可能每隔幾分鐘就要行一次；而總結當日工作嘅循環就夜晚行一次就得，第二朝會有一份報告準備好畀你。

真正嘅威力在於同時運行多個循環

一個循環好有用，但如果有一堆並行運行嘅循環存在，咁就完全係另一回事。

啲高手都係同時設定幾個循環，每個循環各自負責一攤。例如：

◆ 設定一個循環審查員自動提取未合併嘅 PR 並修復失敗嘅 CI；
◆ 另一個循環保持測試組件健康並修補唔穩定嘅測試；
◆ 仲有一個循環就從所有資訊流提取反饋並每隔 30 分鐘做一次聚類分析。

佢哋都唔使你參與，佢哋會並排運行，跟住各自嘅時間間隔，而你可以去做其他嘢或者乜都唔做都得。

呢個就係一個人點樣做到一個團隊嘅工作量。

唔係睇你打得有幾快，而係透過數十個循環全天候為你做嘢。

喺呢個過程入面，思維上嘅轉變我覺得先至係最難嘅部分。

你唔可以潛意識再諗「接下來我應該入咩提示」，而係要開始有意識咁諗「由而家開始，咩嘢工作應該俾佢自動運行」。

任何你做過兩次以上嘅嘢、任何你不斷手動檢查嘅嘢、任何喺凌晨可能會出問題嘅嘢，呢啲就係應該等你建立嘅循環。

熄咗電腦，工作仍然繼續

本地運行循環嘅問題好明顯，就係熄咗電腦之後佢哋就會停。

解決方案係用例行程序（Routines）。

同樣嘅思路可以搬去 server，你只要設定一次任務，佢就會按計劃、經 webhook 或者 API 調用運行，唔理你部機有冇開。

而家用循環，以前需要人手啟動嘅工作會自動發生。Agent 會定時醒嚟完成工作，而當你返到電腦前面，你就可以睇到結果。

呢個就係 Anthropic 嗰班效率團隊可以快速交貨嘅秘密。

佢哋嘅 Agent 會喺各種會議期間、喺所有人都瞓着咗嗰陣，依然通宵達旦咁做嘢。

瓶頸從來都唔係模型本身

如果將呢一切整合埋一齊，可以話 chat 視窗就消失咗。

因為你已經預先設定好規則，你唔需要再手動開 Claude，而係開始運行一個自動運行嘅系統。

循環負責定時同重複性嘅工作。

例行程序會喺你離開嘅時候保持佢哋繼續運行，你只需要決定咩嘢循環應該存在就得。

而家重要嘅技能已經唔係寫出一條完美嘅提示，而係你要發現你工作入面邊啲部分再唔需要你親自參與。

唔好唔記得，你畀錢買嘅 Pro 或者 Max 套餐，買嘅係一整隊 Agent 艦隊，唔好淨係當佢係一個 chat 視窗。

由一個循環開始，而唔係十個

做任何嘢都係一樣，先易後難，前期要盡量專注、要聚焦。

但好多人會犯同一個錯誤，就係想喺第一日或者第一次就起好曬成個循環系統。

十個循環、一個儀錶板、所有功能。

但到咗週末就會出現各種崩潰，因為你已經分唔清邊個循環做緊咩。

所以建議你先由一個開始，揀目前最令你煩惱嘅重複性任務。例如你每個朝早習慣性檢查嘅嘢，就將呢項工作變成一個循環試下。

等佢運行幾日，然後你觀察佢做咗啲咩、邊度做得太過、邊度漏咗。

一旦你信任咗自己起好嘅第一個循環，第二個循環嘅建立時間就會大大縮短，可能只需要 5-10 分鐘就搞掂。

當你去到第五個嘅時候，你就完全唔使再考慮機制，只係諗任務本身就得。

系統之所以可以成長，就係因為每個循環都贏得咗佢嘅位置，而唔係因為你預先規劃咗一個龐大嘅架構。

一個比較好嘅第一個循環有三個特性：

◆ 佢有明確嘅運行時間表
◆ 佢有一個唔會被誤解嘅任務
◆ 佢嘅輸出係你幾秒鐘就可以睇完嘅內容

例如 CI 監控器、PR 變更工具、每日摘要等，佢哋有自己的邊界而且容易驗證。

而失敗嘅循環就係比較模糊嗰啲。例如「改善 codebase」就唔係一個循環，而係一個願望。

「揾出超過 50 行嘅函數並為每個函數創建一個 issue」先至係一個循環。

任務越明確，你就越可以信任佢冇你喺度嘅情況下自動運行。

俾人參與循環，但唔係每個循環都需要

好似 Anthropic 內部嗰班開發人員，好多人會俾 Agent 通宵運行，睇落好似好魯莽，但佢哋唔會俾 Agent 一張空白支票。

每個循環一定會有佢自己嘅範圍，而當就嚟超越已設定好嘅邊界嗰陣，呢啲風險步驟仍然會等人類確認。

設定好嘅循環 PR 審查員可以自動改同修復 CI，但當合併到主分支之後仍然會通知人類。

遷移循環都係，自動開 100 個 pull request 係佢嘅範圍同邊界，但喺準備開第 101 個之前，仍然要人類批准第 1 個。

所以，Agent 可以完成大量工作，而人類就需要保留自己嘅判斷力。

呢個就係可以持久運行嘅設定同冇設定之間嘅分別。

循環嘅目標唔係要人類 0 參與，而係盡可能幫人類從 95% 無聊嘅工作中解放出嚟，將全部注意力放喺真正有風險嘅 5% 上。

如果喺循環嘅指令入面設定過一次邊界，佢哋就會喺之後每次運行都遵守。呢個就係用循環嘅技巧，冇咁多花巧，亦冇咁複雜。

唔係守護工作，係守護規則，而規則係需要你經過深思熟慮一條條寫出嚟嘅。

一個星期後會發生咩變化

第一日寫循環嘅時候，可能會覺得係額外負擔。

因為你要靜落嚟認真諗，要寫時間表，要將任務描述清楚，仲要好似睇盤咁睇住循環會唔會出錯，從而優化指令。

好似比直接叫 Agent 完成任務仲要慢，我第一次用嘅時候就係呢種感覺～

但你用咗之後持續觀察幾日，到咗週末可能情況就會反轉。

你唔再需要人手開 Claude 嚟一問一答，而係開始直接檢查佢已經自動完成並畀咗你嘅結果。

chat 視窗徹底變成狀態面板，而唔係工作區。

呢個就係 Boris 所指嘅真正轉變。

唔係模型變得更加聰明，而係工作由你手中轉移咗去時間表度。

交貨最多嘅人唔係打字最快嘅人。

佢哋係喺其他人仲停留喺 chat 視窗嗰陣就已經運行循環嘅人。

既然睇到呢度，如果覺得唔錯，順手幫手㩒個「讚」、「睇」、「轉發」三連；如果想第一時間收到推送，都可以幫我加個星標★，非常多謝！

絕大多數人使用 Claude 都是一次輸入一條提示。

你輸入，它回答，你查看，然後你再次輸入。

當你關上電腦或者合上筆記本的那一刻，這一切也就都停止了。

而構建 Claude Code 的那個人在很久以前就不再這樣工作了。

他自己親口說今年沒有寫過一行代碼，大部分工作都是通過手機完成的，並且有數千個 Agent 在他睡覺時通宵運行。

能幫他實現這一切的不是啥秘密模型，而是循環（Loops）。

循環就是按計劃運行的 Claude

這裏所說的計劃其實就是「條件」。就跟你聽說過的 if...else 或者 while 循環是一樣的，它們都需要滿足某個條件才能觸發或者退出。

單條提示運行一次就結束了。而循環不會，它會自主運行，一次又一次，不需要你每次都啓動它。

這個機制本身其實很簡單~

你讓 Claude 使用 cron 來調度任務，並告訴它重複的頻率：比如是每分鐘、每 30 分鐘、還是每天晚上。

就是這樣，沒有什麼所謂的框架、編排層。最簡單有效的方案，也是它能奏效的原因。

一旦任務能夠自主重複執行，Claude 就不再只是一個聊天窗口，而是變成了一個可以按照自己的時間表自動出現的執行者了。

關鍵在於將時間間隔與任務藥匹配。

快速變化的事情就使用緊湊的循環，而緩慢的事情則可以讓它每晚執行一次。

比如監控 CI 的循環可能每幾分鐘就要運行一次；而總結當日工作的循環則在夜間運行一次就可以了，第二天早上會有一份報告為你準備好。

真正的威力在於同時運行多個循環

一個循環很有用，但如果有一堆並行運行的循環存在，那就完全是另一回事兒了。

牛皮人士都是同時配置幾個循環，每個循環各負責一攤兒。比如：

◆ 設定一個循環審查員自動提取未合併的 PR 並修復失敗的 CI；
◆ 另一個循環保持測試組件的健康並修補不穩定的測試；
◆ 還有一個循環則從所有信息流中提取反饋並每隔 30 分鐘進行一次聚類分析。

它們都不需要你來參與，它們會並排運行，按照各自的時間間隔，而你可以去做其他事情或者啥都不做也行。

這就是一個人如何完成一個團隊工作量的方式。

不是看你能否更快地輸入指令，而是通過讓數十個循環全天候的在為你工作。

在這個過程當中，思維上的轉變我認為才是最難的部分。

你不能潛意識的再思考「接下來我該輸入啥提示」，而是要開始有意識的思考「從現在開始，什麼樣的工作應該讓其自主運行」。

任何你做過兩次以上的事情、任何你一直在手動檢查的事情、任何在凌晨可能會出問題的事情，這些才是應該等待你被創建的循環。

關閉電腦，工作仍在繼續

本地運行循環的問題顯而易見，那就是關上電腦後它們也就停止了。

解決方案是使用例行程序（Routines）。

同樣的思路可以遷移到服務器上，你只需配置一次任務，它就會按照計劃、通過 webhook 或者 API 調用運行，無論你的機器是否開機。

現在利用循環，那些過去需要人為啓動的工作會自動發生。Agent 會定點兒甦醒來完成它的工作，而當你回到電腦前時，你就能看到結果了。

這就是 Anthropic 那幫效率團隊能夠快速交付產品的秘密。

他們的 Agent 會在各種會議期間，在所有人都睡着的時候，依然在通宵達旦的幹活兒。

瓶頸從來都不是模型本身

如果把這一切整合起來，可以說聊天窗口也就消失了。

因為你已經提前設好了規則，你不需要在手動運行 Claude，而是開始運行一個自我運行的系統。

循環負責定時且重複性的工作。

例行程序會在你離開時保持它們繼續運行，你只需要決定什麼樣的循環應該存在就行了。

現在重要的技能已經不是寫出一條完美的提示，而是你要能發現你工作中的哪些部分再也不需要你親自參與了。

別忘了，你花錢買的 Pro 或者 Max 套餐，購買的是一整支 Agent 艦隊，可別只把它當成一個聊天窗口。

從一個循環開始，而不是十個

做任何事情都是一樣的，先易後難，前期要儘量專注、要聚焦。

可很多人都會犯同樣的錯誤，都想視圖在第一天或者第一次就構建整個循環系統。

十個循環、一個儀表板、所有功能。

然而到週末可能就會出現各種崩潰現象，因為你已經分不清哪個循環在做什麼了。

所以建議你先從一個開始，選擇當下最讓你煩惱的重複性任務。比如你每天早上習慣性檢查的事情，那就把這一項工作先變成一個循環試試。

讓它運行幾天，然後你觀察它到底做了什麼，哪裏做得過頭兒了，哪裏被遺漏了。

一旦你信任了你搭建好的第一個循環，第二個循環的建立時間就會大大縮短，可能也就需要 5-10 分鐘就好了。

當你到達第五個時，你就完全不用再考慮機制，只思考任務本身就行了。

系統之所以能成長，就是因為每個循環都贏得了它的位置，而不是因為你預先規劃了一個龐大的架構。

一個比較好的第一個循環有三個特性：

◆ 它有明確的運行時間表
◆ 它有一個不會被誤解的任務
◆ 它的輸出是你幾秒鐘就能瀏覽到的內容

比如 CI 監控器、PR 變更工具、每日摘要等等，它們有自己的邊界且易於驗證。

而失敗的循環則是那些比較模糊的。比如「改進代碼庫」就不是一個循環，而是一個願望。

「找出超過 50 行的函數併為每個函數創建一個 issue」這才是一個循環。

任務越明確，你就越能信任它在沒有你的情況下能夠獨立自主運行。

讓人蔘與循環，但不是每個循環都需要

像 Anthropic 內部那幫開發人員，很多人都會讓 Agent 通宵運行，這看起來好像很魯莽，但他們不會給 Agent 一張空白支票。

每個循環一定都會有它自己的範圍，而當即將超越他們已設定好的邊界時，這種風險步驟仍然會等待人類的確認。

設定好的循環 PR 審查員可以自主變更和修復 CI，但當合併到主分支後依然會通知人類。

遷移循環也是，自動打開 100 個拉取請求是它的範圍與邊界，但在準備打開第 101 個之前，依然需要人類去批准那第 1 個。

所以，Agent 可以完成大量工作，而人類是需要保留自己的判斷力。

這就是能持久運行的設置與沒有進行設置之間的區別。

循環的目標不是要讓人類 0 參與，而是儘可能的幫助人類從 95% 無聊的工作中解脱出來，將全部注意力放在那真正有風險的 5% 上。

如果在循環的指令中設置過一次邊界，它們就會在之後的每次運行中都會遵守。這就是使用循環的技巧，沒那麼多花花腸子，也沒那麼複雜。

不是在守護工作，是在守護規則，而規則是需要你經過深思熟慮一條條寫出來的。

一週後會發生什麼變化

第一天寫循環的時候，可能你會感覺到像是額外的負擔。

因為你得靜下心來認真思考，得寫時間表，得把任務描述清楚，並且跟盯盤似的還要看着循環可能會出錯，從而優化指令。

似乎比直接讓 Agent 完成任務還要慢，我第一次使用的時候就是這種感覺~

但你用後並持續觀察了幾天，到了週末可能情況就會出現反轉。

你不再需要人為的打開 Claude 來一問一答了，而是開始直接檢查它已經自動完成並交付給你的結果。

聊天窗口徹底變成了狀態面板，而不是工作區。

這就是 Boris 所指出的真正轉變。

不是模型變得更聰明瞭，而是工作從你的手中轉移到了時間表上。

交付最多的人不是打字更快的人。

他們是在其他人還停留在聊天窗口時就已經在運行循環的人。

既然看到這兒了，如果覺得還不錯，幫忙隨手點個「贊」、「在看」、「轉發」三連；如果想第一時間收到推送，也可給我加個星標★，非常感謝！