TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
Claude Code 排程更名 Scheduled tasks，先看清觸發與權限規則
Claude Code 的雲端排程功能已把 Routines 更名為 Scheduled tasks，名稱切換落在 2026 年 10 月底的最後幾個版本，官方文件自己列出舊名還留在網址、CLI 別名與 API 端點等五個地方；文件同時寫死自動執行的信任邊界，觸發不等於同意，API 傳入文字一律包上不可信標記，每小時限額與方案範圍也能事前對照。
用 AI 摘要這篇文章：
Claude Code 的雲端排程功能換名字了。官方文件現在稱它 Scheduled tasks，頁面開頭用一句話交代前身：scheduled tasks, formerly routines。這不是一篇重新宣傳，同一條文件網址、同一批設定，把 Routines 這個名字退到「曾用名」的位置，功能本身仍在 research preview 階段，官方明講行為、限額與 API 介面都還會變。
名稱切換的時間可以從官方 changelog對出來。10 月 27 日的 2.1.312 版條目還寫著「當你建立或編輯 routine 時」，10 月 30 日的 2.1.314 版已經改稱「Scheduled tasks 頁面」，兩版之間沒有 2.1.313。換句話說，更名在 10 月底的最後幾個版本落地，文件頁本身到 11 月 10 日晚間仍在更新。
對已在用的人，真正要緊的有三件事：舊名沒有清乾淨，官方自己列了一張「舊名還出現在哪」的清單，網址、指令與 API 端點都還是它；這份文件把自動執行的信任邊界寫得比一般聊天功能嚴，觸發不等於同意，API 傳進來的文字一律當成不可信資料；限額算得出來，每小時有明確上限，沒有超量計費。下面逐項拆開。
名字什麼時候換的，證據在 changelog 的用字裡
官方沒有發一篇「我們改名了」的公告。翻 changelog 從 10 月到 11 月的條目，看不到任何一條專門宣布更名，能對出時間的是各版本條目的用字切換：2.1.312（10 月 27 日）寫「當你建立或編輯一個在雲端執行的 routine」，2.1.314（10 月 30 日）寫「Scheduled tasks 頁面上的 Include completed 按鈕」。之後 11 月的 2.1.317、2.1.321 條目全部用新名，回不去了。
組織設定的開關名稱留下更直接的痕跡：Team 與 Enterprise 的管理員現在會看到「Scheduled tasks (Was Routines)」這個 toggle，名字本身就把新舊並列。文件頁的元資料也顯示最後更新時間是 2026 年 11 月 10 日 21 點 55 分（UTC），等於台北時間 11 月 11 日凌晨，前一天晚上還在改稿。
這裡要誠實標一個推論：官方文件沒有解釋更名動機。從產品結構看，Claude Code 目前有三種會排程的東西並存，雲端的 scheduled tasks、桌面版的 Desktop scheduled tasks、終端機裡的 /loop，舊名 Routines 涵蓋不了「雲端」這個執行位置，新名把範圍說得比較準。這是從文件結構推的，不是官方說法。
舊名 routines 還黏在五個地方
文件裡有一節標題就叫「Where the name routines still appears」，官方自己列出舊名還在的五個位置，每一處指的都是同一個功能：
- 應用程式介面：部分帳號的側欄與頁面標題仍寫 Routines，按鈕寫 New routine。文件教你遇到這種畫面時改走另一條完整表單流程，照樣能建任務。
- 網址：claude.ai/code/routines。建立與管理排程的入口就是這條，文件內文連來連去也都用它。
- 指令：/routines 是 /schedule 的別名，兩個都能用。
- API：這是最不該急著改的一段。觸發端點的路徑是 /fire，beta 標頭叫 experimental-cc-routine-2026-04-01，回應的型別欄位寫 routine_fire，傳入的文字包在 routine-fire-payload 標籤裡，平台文件頁的網址也是 routines-fire。
- 組織設定：Capabilities 分頁底下的「Scheduled tasks (Was Routines)」或就寫 Routines 的開關。
對整合者，beta 標頭那一串日期值得多看一眼。標頭名稱裡的 2026-04-01 是這個 API 版本的日期標記，可以確定這條 API 從 4 月起就掛著同一個標頭運作至今；官方的規則是破壞性變更會換上新的日期標頭，且最近兩個舊版並存一段時間讓你遷移。10 月底只換了行銷層的名字，端點與標頭原封不動，你的程式碼短期內不用動，但要把「換標頭」列為將來的維護項目。
三種觸發器，排程反而只是其中一種
一個 scheduled task 的本體是一份預存設定：一句提示、一或多個程式倉庫、一組連接器。裝好之後等觸發，觸發器有三種，還可以混搭：
Schedule 是時間型，可以每小時、每天、每週，也可以指定未來某一刻跑一次。幾個細節會影響實際體驗：整點的排程會晚個幾分鐘才開始，官方建議選 9:07 這種時間；自訂 cron 每小時最多一次，更密會被拒絕；五欄位的 cron 以 UTC 計算，要當地時間得加 CRON_TZ= 前綴；跑完一次的一次性任務會把自己關掉，頁面標成 Completed。
API 給任務一條專屬 HTTP 端點，POST 之後開一個新的工作階段並回傳網址，把它接進告警系統或部署管線都行。每個任務有自己專屬的 bearer token，只授權觸發那一顆任務，token 只顯示一次，砍掉重發立即生效。注意 API 觸發只能在網頁上設定，指令列管不到它的 token。
GitHub 事件型，支援 Pull request、Release、Issue 三類，可以細到 pull_request.opened 這種單一動作。前提是倉庫要裝 Claude GitHub App；超過每任務或每帳戶每小時上限的事件會被直接丟棄，不是排隊。PR 觸發還能設八種欄位的過濾條件，從作者、標題、目標分支到標籤，運算子包含等於、包含、開頭是、符合正則，正則比對的是整個欄位值，要匹配 hotfix 字樣得寫成前後加萬用字元的寫法。
混搭是正式用法。文件舉的例子是同一顆 PR 審查任務，每晚定時跑一次、讓部署腳本呼叫一次、再對每個新開的 PR 各跑一次。反過來也成立：一個任務可以完全沒有時間排程，只靠 API 或 GitHub 事件活著，名稱裡的 scheduled 只是跟著族譜走。
觸發不等於同意，API 傳入的文字一律包上不可信標記
這次文件寫得最清楚的部分，是自動執行的信任邊界，有兩道。
一道在提示本身。任務的提示是預先存好的，觸發器啟動時，工作階段收到的是這份預存提示，官方明講：觸發只證明這份提示先前由你帳號上的一個授權工作階段存好，它不是即時的使用者輸入，不能拿來當作執行過程中的批准或同意。執行中抓到的外部內容照一般規則處理。這一段等於把「你自己排的程式碼代理說可以，不代表你可以」寫進規格。
另一道在 API 傳入的文字。POST 時可以帶一個 text 欄位放告警內容或失敗 log，這個值不會被解析，送達時整包包進 routine-fire-payload 區塊，標記為不可信資料，除非任務自己的提示明說要用它。所以提示要寫成「調查 routine-fire-payload 區塊裡描述的告警」這種句子，任務才會把傳入的文字當一回事，否則它只是躺在旁邊的無害上下文。官方給的理由很實際：拿到 token 的任何人都能送 text，包裹機制讓外洩 token 換到的只是標好的不可信資料，而不是對你任務的直接指令。
工作階段跑在專案裡時有個例外行為：run 可以接續既有的 thread，不另開新 session，那時沿用 thread 當下的權限模式。TechMoon 先前談Claude Projects 重構時提過同源的設計，值得對照著讀。
auto mode 代你放行，兩種情況會停下來等人
雲端 run 啟動時預設進 auto mode，由一個分類器模型代替你允許或擋下原本要等你批准的動作。這不是全放行，有兩種情況 run 會停住等人回答：動作命中 ask 規則，以及被擋的次數累積到重複阻擋的門檻。一次擋下不會結束 run，門檻到了才會出現權限提示，掛在那裡等人。組織若關掉 auto mode、或任務選的模型不支援，run 就沿用出發時的權限模式。
發布成品也有對應規則。auto mode 底下，分類器放行的發布動作可以直接執行不必先問，新發布的 artifact 只有你自己看得到，要分享才會公開；但發布若命中 ask 規則，仍然會先問。Accept edits 模式另有七個條件湊齊才能不問直接重新發布既有頁面，包括頁面屬於你自己的組織、沒有公開分享、不覆蓋較新版本等，條件少一個就回復先問；這組條件只適用排程或 Run now 啟動的 run，API 與 GitHub 觸發的 run 一律先問。
把這兩段合起來看，無人值守的自動化實際上是「分類器加兩個剎車」，不是放生。設計任務時與其假設它全自動，不如想清楚哪些動作你願意讓分類器代答，哪些要寫成 ask 規則留下人工關卡。
限額算得出來，狀態欄卻不是驗收
用量方面，排程任務跟你自己開的互動工作階段抽同一桶訂閱額度，帳號的用量頁看得到消耗。另外每種啟動方式有獨立的每小時上限，整理如下：
| 啟動方式 | 上限 | 計算單位 | 超過時 |
|---|---|---|---|
| 排程啟動（含一次性） | 每小時 100 次 | 你的帳號 | 等到限額重置才跑 |
| Run now、API 觸發、一次性重跑 | 每小時 30 次 | 單一任務，三者共用 | 動作直接失敗 |
| Run now 與一次性重跑 | 每小時 100 次 | 你的帳號 | 同上 |
| API 觸發 | 每小時 100 次 | 你的帳號，與 Run now 分開計 | 同上 |
| GitHub 事件 | 官方另訂每任務與每帳戶每小時上限 | 事件 | 超量直接丟棄，不補跑 |
沒有任何一項提供超量計費。訂閱打到上限時，組織若開了 usage credits 可以照跑計費延伸，沒開就等用量視窗重置；訂閱暫停期間任務整批停住，恢復後要自己再打開。
帳號歸屬也影響團隊用法。任務屬於個人 claude.ai 帳號，不與隊友共享，run 消耗的是你自己的額度。對外的身分同樣以你為準：commit 與 PR 帶你的 GitHub 帳號，Slack 訊息與 Linear 工單走你連結的服務帳號。這代表排程任務的產出掛在你名下，責任線清楚，但團隊想共享一顆任務，現行機制做不到。
最後一個容易誤讀的地方是狀態欄。History 清單上的 Succeeded、Failed、Cancelled 只描述工作階段怎麼結束，不等於你提示裡交代的工作完成了。官方特別舉例：被擋的網路請求、連接器工具掛掉、Claude 沒做完的事，都會出現在執行紀錄裡，而不是那一列的狀態上。把綠燈當驗收，會漏掉假成功；真正的驗收動作是點開 run 讀 transcript。另外倉庫連線過期時任務會跳過執行，保留 72 小時的補線寬限，逾期任務自動關掉。
五月的倫敦工作坊，還是設計思路最好的入口
想看別人怎麼設計這類任務，官方在 Code with Claude 倫敦場的實作工作坊是現成教材。該場次在 2026 年 5 月 19 日舉行，講者 Maya Nielan 是 Anthropic 的 Member of Technical Staff，錄影隔天上架官方頻道，長度 22 分 3 秒。課程描述的一句話把用途講得很白：routine 讓 Claude Code 變成主動的隊友，在你打開筆電之前就讀完 repo 開好 PR。
工作坊把設計拆成三個決策：觸發、上下文、導引。對應到現行文件就是選哪種觸發器、給哪些倉庫與連接器、提示怎麼寫。文件的走向也是同一個順序：建立時不選權限模式，連接器預設全部帶上、要你自己刪到只剩任務需要的，初次執行的紀錄點開就能逐行檢查。需要提醒的是，錄影與課程頁都還在用 Routines 舊名，看教材時對照現行文件讀設定，名字的部分自動翻譯就好。
還沒定案的部分與下次回來看的時機
三件事目前沒有答案。research preview 的聲明表示行為、限額與 API 介面都可能再變，文件沒有給畢業時間表；舊名何時從網址與 API 端點完全退場，也沒有日期；至於各帳號什麼時候全面看到新介面，文件只說部分帳號仍是舊畫面。會影響判斷的回查點有兩個：官方換新的 beta 標頭日期時（API 整合者該動作了），以及 changelog 再出現排程相關的大改條目時。在那之前，兩個名字都認得，文件一條網址，夠用。
補充：相關背景
Anthropic 近期在 Claude Code 雲端功能上的動作不止這一件。Cowork 與對話合併時，交辦後合上筆電的雲端任務與週期排程就被推成預設工作模式；企業端的安全中心更新裡，登出帳號收不掉排程好的任務與 API 金鑰，被列為管理邊界之一。這次更名與文件整併，可以看作同一條線上把名稱與規則對齊的一步。
