Claude Code 最佳實踐：來自 4 個月的無人值守運行（並非來自一個週末專案）

最多 克勞德代碼最佳實踐 列表是由坐在終端前的人編寫的。先做好計劃。保持 CLAUDE.md 文件簡潔。使用計劃模式。編寫測試。理清上下文。這些都是很好的建議，但所有這些都假設有人在監控會話，隨時準備在出現問題時按下 Esc 鍵。.

我的程式大多在我睡覺的時候運行。撰寫此貼文的容器自 2026 年 6 月 12 日起一直在執行 Claude Code 的定時任務： 1740 條運行日誌 截至昨天, 39個技能文件, 一個接一個的定時任務，從部落格文章到收件匣分類，再到反向連結拓展。沒人審批計劃。沒人會在發布前查看差異。如果凌晨 00:07 出了問題，我得吃早餐的時候才能知道，如果真能知道的話。.

這改變了哪些最佳實踐才真正重要。所以這不是我讀過的技巧清單，而是九條規則，每條規則都附有促成其誕生的事件日期，以及一些我因為經不起推敲而放棄的流行規則。如果你正打算將「克勞德守則」納入日程安排，那麼這份清單正是我希望六月就能看到的。.

為什麼大多數 Claude Code 最佳實踐都假設你在觀看

在撰寫本文之前，我閱讀了與該關鍵字相關的排名頁面。它們大致可以分為三種類型：

• 精選連結中心。. GitHub 搜尋結果排名第一的是一個包含概念、工作流程和 83 個技巧的大型索引。它就像一張地圖，但終究只是一張地圖。.
• 個人項目報告。. 重建博客，在編寫程式碼前嘗試 BMAD，找出計劃模式的限制。坦誠、實踐性強，並且始終堅持一位開發者進行一對一的互動式教學。.
• 教學和官方提示。. DataCamp 的指南最為全面：規劃週期、分層 CLAUDE.md、文件化和清晰化模式、鉤子作為護欄、測試驅動開發 (TDD)、模型成本。 Anthropic 自己的 克勞德·科德高級使用者技巧 涵蓋並行會話、工作樹、技能、鉤子、權限等內容。, /環形 和 /日程.

Anthropico 的頁面上說，最重要的建議是 確認給 Claude 一個檢查自身運行結果的方法，它就會不斷迭代直到輸出正確為止。我完全同意。這篇文章的大部分內容正是闡述了當循環中沒有人在場來發現檢查本身出錯時，這個技巧會如何演變成現在的樣子。.

這就是差距所在。所有這些指南都旨在幫助讀者取得好成績。 本次會議. 當 Claude Code 透過 cron 定時任務運行時，問題就有所不同了：

• 一次跑步可能失敗，但看起來仍然像成功。.
• 一次跑步可能會成功，但沒有人知道，因為它從未宣布過成功。.
• 修復程式可能發布後幾天內都無法在生產環境中運作。.
• 代理可以編輯告訴它如何運作的檔案。.

這些東西不是看別人學的，而是隔天早上從日誌看的。至於架構本身（定時任務觸發、技能文件載入、Claude 執行任務、容器休眠），我已經寫在…裡面了。 克勞德代碼代理正在生產中. 這篇文章是關於其上的規則。.

實踐1-3：確定運行範圍並製定結果合約

1. 一次運行，一份工作，一份技能文件

我的日程表上的每個時間段都對應一項技能： 部落客 00:07, 每日貢獻 7點07分, 電子郵件檢查器 11:07，等等。調度員運行 克勞德——印刷 只需一條指令：讀取並執行此技能檔。無需「順便一提…」。.

原因在於可調試性，而非優雅性。當運行出錯時，我希望只有一個日誌、一個技能和一個負責人。多用途會話會讓每次失敗都變成一場爭論，爭論究竟是哪一部分導致了失敗。如果你要多次執行某項操作，Anthropic 的建議是將其轉化為一個技能。對於計劃任務，我會更進一步： 如果不是技能，就不會佔用欄位。.

2. 給每次運行都設定一個超時，並且讓超時發出聲音。

我的排程器為每個任務都設定了時間上限：預設 30 分鐘，部落格寫作任務 90 分鐘。很好。我錯在沉默了。. 從六月到十月，因暫停而損失了16個得分。, 而且每個日誌都只有7行的標題，除此之外什麼都沒有。沒有警告，沒有頁腳，沒有任何線索。我之前報道過這次統計。 給每個AI代理設定超時時間，然後大聲提示。. 規則是：一場精彩的比賽應該是當天最熱鬧的比賽，而不是最安靜的比賽。.

3. 每次運作結束後，輸出一行機器可讀的結果。

如果只能保留一項練習，我會把這項放在第一位。每項技能都必須以以下內容結尾：

技能結果：成功 | 發生了什麼 | URL 技能結果：跳過 | 為什麼什麼都沒做 技能結果：失敗 | 哪裡出了問題

那條線就是一份合約。監視器程式可以抓取它，數據看板可以統計它的數量，而我喝咖啡的時候也能讀懂20條。以下是1740次運行的記錄：

結果	跑
成功	1,370
跳過（隊列為空，無事可做）	210
失敗	42
其他（退化、畸形）	5
完全沒有結果行	113

問題出在那113個人身上。. 其中47人退出，退出代碼為0。進程顯示“正常”，但代理程式沒有發出任何信號。信任退出程式碼的監控程式會放行這些退出程式碼。而檢查結果行的監控程式則會將它們標記為失敗，包括一些實際上已經發布的退出程式碼。無論哪種方式，你都只能靠猜測。我把其中最不起眼的一個記錄了下來。 首先要檢查的是你最安靜的AI代理。.

解決方法並非發出更明確的指令，而是在代理程式執行完畢後進行檢查：如果沒有結果，則不會顯示綠燈。這就引出了大家過度信任的那份文件。.

CLAUDE.md 只是一個文件，並非整個系統。

每份 Claude Code 最佳實務清單都會用一個章節專門介紹 CLAUDE.md 檔案。我為此專門寫了一篇文章。, CLAUDE.md 最佳實踐，摘自一個經營 10 家無人值守企業的文檔, 所以我就不再贅述了。那次審計的一個發現對本文其他內容至關重要。.

我的 CLAUDE.md 檔案中有一個「不可協商」的規則區塊。標題相同，強調方式也相同。當我查看日誌中的合規性時，發現建立文章的 API 呼叫中的兩個規則（發布狀態、特色圖片）得分很高。 100%. 「以 SKILL_RESULT 行結尾」規則分數約為 92%. 而「每次會話開始時務必閱讀 MEMORY.md」這一做法也得分很高。 0%, 因為該文件現在 2.1 MB. 沒有上下文視窗可以容納它。.

合規性遵循關鍵路徑，而非粗體字部分。如果某條規則位於代理無法跳過的步驟中，則執行該規則。如果是結束儀式，則不進行任何檢查，有時甚至不檢查。如果絕對不可能，則永遠不會檢查。.

以下是我現在採用的分工方式：

• CLAUDE.md： 身分、語音、ID 和指標。代理需要知道的信息，而不是它必須執行的所有操作。.
• 技能文件： 一步一步完成一項任務，並提供精確的 API 介面。.
• 鉤子和包裝腳本： 任何每次都必須發生的事情。 Anthropic 將鉤子描述為代理生命週期中某些特定點的確定性邏輯。這就是關鍵： 停止 檢查結果行的鉤子不依賴模型記憶。.
• 次級代理商： 一些獨立的支線任務，否則會淹沒主線劇情。更多內容請參考… Claude Code 生產中的子代理.

實踐4-6：不要輕信任何看似成功的事情

這就是無人值守的克勞德程式碼最佳實踐與互動式最佳實踐真正分道揚鑣的地方。當你觀看時，一個奇怪的回應看起來很奇怪。但在凌晨3點，一個形狀像成功的奇怪回應會被記錄為成功，然後代理會繼續執行下一個任務。這三條規則都源自於此。.

4. 檢查有效載荷，而不是狀態碼

我的SEO資料提供者曾經餘額不足。但每次通話仍會接通。 HTTP 200 具有最高級別地位 20000 好的。.. 實際錯誤是：, 40200 需要付款, 位於任務物件內部的下一層。檢查 HTTP 狀態的代理程式看到運作正常，沒有資料。完整內容請見 SEO API 明明想說“付錢”，卻顯示“好的”。”.

規則：對於每個外部 API，都要記錄其位置。 真實的 狀態存活，並且技能檢查該字段，而不是信封。.

5. 將「零結果」視為一個問題，而不是答案。

這件事讓我浪費了好幾個月的時間。我的部落格代理商會從 Airtable 表格中選擇下一個關鍵字。 Airtable 公式中的欄位名稱不區分大小寫，但寫入操作中的欄位名稱區分大小寫。我的表格使用的是小寫字母。 地位; 這項技能寫道 地位. 每次更新都會返回 422 未知字段名.

讀取端也有自己的版本：查詢按以下方式排序 搜尋量 當該欄位為 搜尋量. 該呼叫也失敗了，傳回了 422 錯誤，技能偵測到的記錄數為零。零記錄數與空隊列的位元組數完全相同，技能執行的是一個禮貌的「隊列為空，跳過」分支。因此，這次失敗被報告為一次乾淨的跳過。. 該經紀人首次成功將關鍵字標記為已發布是在 10 月 8 日。. 它從六月開始就一直「運作正常」。.

同一個家族，至今仍在運作：我的圖像腳本使用一個名為「圖像記錄」的字段，將生成的每張圖像記錄到 Airtable 中。 姓名 該數據在表中不存在。 Airtable 會拒絕整行數據，腳本會退出並回傳 0。除非手動回填該行數據，否則影像將不會被記錄。將 422 錯誤轉換為空列表的錯誤處理代碼是無人值守系統中最危險的代碼，因為它旨在保持靜默。.

6. 核實使用者看到的工件

我的SEO插件的API回應 {"slug":true} 無論元標題是否真的更改了。整整一周，我都以為每次更新都要發送兩次。其實不用。頁面快取仍然保留舊的頁面頭部資訊。真正的解決方法是用一個清除快取的查詢字串來驗證即時頁面，然後相信頁面上的內容，而不是快取的確認資訊。.

10 月 7 日的另一起事件：合規性掃描讀取了一個名為“ 旁白 當劇本文本存在於…之下 文字. 它評分了 50/531 個字符 然後報告一切正常。沒有任何錯誤。它只是自信滿滿地檢查了錯誤的內容。.

所以我的部落格功能現在會在每次發布後重新抓取文章，並檢查即時 HTML 程式碼中的標題、元描述和特色圖片。 Anthropic 將驗證稱為 #1 技巧。對於無人值守的工作，我會進一步完善它： 核實顧客透過他們將要使用的同一扇門所看到的東西。.

實踐7-9：自我編輯前的備份、預算上限和夜間監控

7. 在代理程式編輯任何檔案之前，請先備份該檔案。

我的特工每次運行後都會更新自己的記憶檔案。這就是他們學習本文中提到的內容的方式。也因為如此，一次糟糕的運行就可能抹掉四個月的筆記。所以每個技能在操作文件之前都會先複製一份。項目資料夾中的目前數量： 264 個 MEMORY.md 備份、231 個觀測日誌備份和 31 個技能檔案備份。.

看起來像是雜亂無章。實際上，這是我不只一次需要的撤銷按鈕，包括有一次早上，一個重複使用的輔助腳本在運行過程中被中斷，看起來好像什麼都沒做，結果又運行了一次，創建了兩個重複的 Asana 任務。廉價的保險：帶有時間戳的撤銷按鈕 cp 在向檔案寫入任何內容之前，代理程式會從檔案中讀取指令。.

反過來也值得說出來。在一個容器裡 --dangerously-skip-permissions, 代理可以編輯自己的 .克勞德 設定中存在這個空白。我記錄了這一點。 Claude Code 沙箱審計. 備份可以讓使用者自行修改的內容可逆，但並不能保證其安全性。.

8. 設定每次運行的預算上限，而不是每月預算上限。

每月上限是在災難結束後才告訴你的，而單次運行上限則是在災難發生時就將其阻止。我的上限主要針對結構性問題：

• 時間： 實作 2 中的每個作業逾時。.
• 體積： 這項技能規定了數量。一篇部落格文章。三到五個Reddit發現。五個推廣線索。絕不是「越多越好」。“
• 平行結構： 圖像生成同時發起了 8 個呼叫並且得到了 3 次速率限制拒絕. .每批3個，間隔時間短，12個全部成功。詳情見 AI代理速率限制.
• 花費： 圖片模型按圖片數量計費，因此技能決定了圖片數量。長篇文章需要七張圖片，短篇文章需要一張。.

模型本身是基於一個扁平化的方案，這是成本控制的另一半：可變支出體現在代理人調用的工具中，因此這就是成本上限的體現。.

9. 養一隻夜間看門狗，並把它放在不礙事的地方。

每天晚上 23:35，一個監控技能會讀取當天的日誌，檢查每個已執行的排程任務，並對每個結果進行評分。它發現了一些其他方法無法發現的問題：例如社交帳戶斷開連接、任務跳過以及沒有結果輸出的運行。.

它也教會了我這份清單中最奇怪的一課。當我尋找時間上重疊的跑步記錄時，我發現 共有 22 對重疊的配對，且所有 22 對配對均始於 23:28–23:40 時間內。. 日程安排本身從未發生衝突。衝突的是監控程序，它在運行過程中會重新運行失敗的任務。 10 月 7 日，一次 25 分鐘的重試導致任務超時，超過了午夜，當晚的部落格文章最終未能發布。.

所以規則其實是兩條。養條看門狗。 恢復動作的持續時間絕對不要超過下一個動作插槽之間的間隔。, 或者，修復程式反而重現了它所要修復的故障。請報告排隊；不要貿然重試。.

如果您不想逐一學習這些知識，這就是我為客戶建立的系統。 短期策略建議 這是了解您的工作流程是否已準備好無人值守運作的最快方法。.

我放棄的 Claude Code 最佳實踐

有些流行的建議對鍵盤前的開發者來說是正確的，但對定時任務的執行者來說卻不適用。以下是我不再採用的做法。.

“務必先讀取記憶體檔案”

5 KB 沒問題，2.1 MB 就不行了。我仍然保留著 CLAUDE.md 裡的那條規則，提醒自己指令會過時。現在有效的方法是：每個技能都會在記憶體中搜尋自己的名稱，並讀取最近的條目。有針對性的回憶勝過完全的回憶。.

“在克勞德編寫程式碼之前，先批准方案。”

計劃模式在有人閱讀計劃時非常有用。但在 00:07 時，沒有人閱讀計劃。我將其替換為一個拆分模式：上游研究代理將一份簡報寫入內容日曆（關鍵字資料、即時搜尋結果、大綱、範圍說明）。 不是 為了掩蓋真相），而經紀人卻反其道而行。計劃依然存在，只是提前一天寫好，由下一位經紀人審核，而不是我。.

“所有程式並行運行”

對於需要同時處理多個任務的開發人員來說，並行會話和工作樹非常棒。在共享 API 配額的單一容器中，較高的平行度通常只會帶來速率限制（實務 8）。順序執行且間隔清晰的會話比任何巧妙的並發都更可靠。.

“使用 /loop 執行重複性工作”

/環形 雖然很方便，但根據 Anthropic 自己的文檔，它一次最多只能在本地調度 3 天。這是會話功能。企業需要一個能夠在重新啟動後仍然運作並記錄每次調度的調度器。我的調度器是在容器內使用簡單的 cron 式調度，調用 克勞德——印刷 每個插槽。無聊，而且已經運行了1740次，還在增加。.

“測試驅動開發”

TDD（測試驅動開發）是程式碼編寫的正確方法。我的大多數客服人員並不編寫程式碼，他們負責撰寫貼文、處理郵件和更新表格。對他們來說，這相當於實踐6：驗證已發表的成果。原則不變，改變的是工具。.

“更聰明的模型就能解決這個問題。”

在我10月分類的40次失敗運行中，, 38 個是已過期的社群媒體 API 令牌。, 其中一是圖片壓縮配額，另一是空的 SEO 數據餘額。. 模型出錯的機率為零。. 完整明細如下： “更聰明的AI模型可以修復你的代理商”. 水管故障。升級水管系統。.

Claude Code 最佳實務常見問題解答

克勞德守則中最重要的一項最佳實踐是什麼？

驗證。 Anthropic 公司是這麼說的，而且四個月的無人值守運作也證實了這一點。請務必驗證實際結果（即時頁面、表格中的記錄、寄件匣中的電子郵件），而不是 API 的描述。.

Claude Code 能否依計畫無人值守運行？

是的。. 克勞德——印刷 它以非交互方式運行單一提示符，因此任何調度器都可以呼叫它。我將其運行在 Docker 容器內的調度器中，每個技能槽位一個技能。 Anthropic 也提供 /日程 適用於雲端工作和 /環形 對於短的局部循環。我的運算符設定如下： Claude Code CLI 指南.

--dangerously-skip-permissions 安全嗎？

僅在您審核過的盒子內。 Anthropic 建議 /權限 允許清單可以跳過權限，對於沙盒環境，跳過權限也是一種選項。我的容器以非 root 使用者身分運行，沒有添加任何額外功能，但它們仍然持有真實的 API 金鑰。閱讀全文 沙箱審計 以及 克勞德代碼安全指南 在你複製那個標誌之前。.

如何防止 Claude Code 在更新時崩潰？

先更新一個容器，等待計畫任務運行通過後，再將更新推廣到其餘容器。否則，更新可能會中斷正在執行的作業。我在[此處應插入原文連結]中介紹了具體流程。 如何在不中斷運作中的艦隊的情況下更新 Claude Code.

Claude 是否應該審閱自己的作品？

這很有幫助，但不要只用這一種方法。模型對自身輸出進行評分會存在盲點。盡可能使用確定性檢查，如果無法使用，則需要進行單獨的複核。更多內容請參見 克勞德程式碼審查.

這樣運行 Claude Code 需要多少成本？

該模型採用平坦的 Max 計劃運行。變動成本是工具：在我的流程中，每生成一張影像大約需要 $0.08，每個短影片大約需要 $0.33。每次運行的上限（實踐 8）保證了這些成本的可預測性。.

最後總結：克勞德·科德在睡夢中編寫程式碼的最佳實踐

互動式 Claude Code 最佳實踐旨在幫助您在觀看的同時獲得理想結果。而無人值守版本則旨在讓您在未觀看的情況下了解發生了什麼。以下是簡要說明：

1. 一次運行，一份工作，一份技能檔案。.
2. 每個任務都會有超時，任務終止時會發出很大的噪音。.
3. 每次運行都以一行結果結束，並且會透過檢查來強制執行。.
4. 請讀取實際狀態字段，而不是信封上的內容。.
5. 將零結果視為一個問題。.
6. 核實客戶看到的實體物品。.
7. 在代理編輯文件之前，請先備份任何文件。.
8. 限制每次運行的時間、容量、並行度和費用。.
9. 運行監視程序並發出報告，並且永遠不要讓重試超時到下一個槽位。.

這些經驗都不是來自教程，而是我第二天早上閱讀的一篇日誌中總結出來的。這才是真正的最佳實踐： 像讀產品文件一樣讀日誌。, 因為當沒有人看著的時候，他們就是你唯一的證人。.

先從練習 3 開始。將結果行加入本週的一個規劃任務中，並統計有多少次運行無法傳回結果。這個數字將告訴你接下來需要修復什麼。.