上線前空跑測試場景指的是：第一次要讓一個排程任務正式運作前，先讓它照完整邏輯跑一次，但把所有會產生真實後果的動作（發信、寫入資料庫）換成只記錄不執行，藉此在不冒真實風險的情況下，先看一遍「如果現在正式執行，會發生什麼事」。這跟「讀過邏輯覺得沒問題」不是同一件事——讀邏輯是靠人腦推演每一種可能情況，容易漏掉沒想到的組合；空跑測試是讓系統實際跑一次給你看具體結果，用眼睛核對而不是用想像推演，這是排程任務上線前該有的驗證標準，比手動操作的驗證標準更高，因為排程任務一旦上線就沒有你可以介入喊停的空檔。
這件事會被需要，是因為排程任務錯誤的代價結構跟手動操作完全不同。手動寫一封信，你在按下送出前的最後一秒都還能反悔；排程任務一旦設定好正式啟用，執行的那一刻沒有人在旁邊確認每一步是不是真的沒問題，錯誤如果存在，會直接變成真實後果——信真的寄出去了、資料真的寫進去了，沒有補救的空檔。人在設計邏輯時，很自然只會想到「正常情況該怎麼跑」，容易漏掉邊界情況（例如業績成長超過某個門檻的特殊處理），這種漏洞在讀程式碼或讀邏輯描述時很難被發現，因為讀的時候大腦傾向照著預期的路徑走，不會主動去想「如果資料長得不一樣會怎樣」。空跑測試存在的理由，就是強迫用實際資料去驗證，把「應該沒問題」的假設換成「確實看過會發生什麼」的驗證。
操作分三步。第一步，把發信、寫入資料庫等有副作用的動作明確改成記錄模式：發信改成產出收件人、主旨、內文全文但不送出；寫入改成列出欄位跟數值但不寫入。第二步，準備測試資料時，刻意包含會觸發特殊分支的情況，不能只用「一切正常」的資料，例如故意放一筆業績成長超過 50% 的數字，確認特殊標註邏輯真的被觸發。第三步，逐項核對空跑測試產出的清單：收件人是否正確、主旨的日期欄位是否正確帶入、數字是否來自正確的資料來源，清單愈具體愈好核對，模糊的「將發送郵件」這種訊息無法用來驗證任何東西。三步都做完、清單核對無誤後，才正式啟用排程任務。
你花了一個下午，把每週一早上彙整上週業績、寄給五個部門主管的流程設定成排程任務，邏輯看起來沒問題，按下「啟用」，等下週一早上驗收成果。這個做法最大的風險不是邏輯真的有錯——是如果邏輯真的有錯，你要等到週一早上信件已經寄出去之後才會發現，而那個時候，五封錯誤的信已經躺在五個主管的信箱裡了。
排程任務跟你自己手動操作最大的差異，是手動操作出錯，你在按下最後一步之前還能反悔；排程任務一旦正式跑起來，中間沒有你可以介入喊停的空檔。這代表排程任務上線前的驗證標準，必須比手動操作更高——不能只是「我讀過邏輯，感覺沒問題」，要能實際看到「如果現在跑，會發生什麼事」。這正是空跑測試（dry run）要解決的問題：讓整套邏輯照正常流程跑一次，但把所有真正會產生後果的動作（發信、寫入資料庫）換成「記錄下來、不實際執行」，最後給你一份清單，列出這次如果是正式執行，具體會發生什麼。
第一步，明確要求 Claude 在這次測試裡，把發信動作改成「產出這封信的收件人、主旨、內文全文，但不要真的送出」，把寫入資料庫的動作改成「列出這次會寫入的欄位跟數值，但不要真的寫入」。第二步，不要只用「一切都很正常」的資料測，要故意用會觸發特殊情況的資料去測——如果流程裡有「業績成長超過 50% 要額外標註」的邏輯，測試資料裡就要真的放一筆超過 50% 的數字，確認這條分支邏輯真的被觸發、輸出結果符合預期。第三步，仔細看空跑測試給你的清單，不是掃過去覺得「看起來沒問題」就結束，是逐項核對：收件人是不是正確的五個信箱、主旨欄位有沒有正確帶入日期、業績數字是不是真的來自對的資料來源。這份清單愈具體，你愈能在正式上線前抓到問題——如果清單只寫「將發送週報郵件」，這種模糊的訊息量根本不足以讓你核對任何東西。
空跑測試驗證的是「這套邏輯本身寫得對不對」，驗證不了「正式上線後，資料來源會不會偶爾出狀況」——測試時用的資料通常是乾淨、齊全的，但正式上線後，可能某週業績資料因為系統維護晚了兩小時才更新，這種情況空跑測試在設計當下不會知道，需要搭配前面提過的 trigger condition（觸發條件）跟 retry policy（重試策略）一起處理。空跑測試負責的是上線前的邏輯驗證，這兩個機制負責的是上線後遇到真實世界不可預期狀況時該怎麼辦，三者是不同時間點的風險控制，缺一不可。
沒有做空跑測試，直接讓排程任務上線，等於把「這套邏輯有沒有問題」的驗證，外包給「等出錯了自然會有人跟我說」——代價是問題被發現的時候，已經有實際的信件寄出去、實際的資料被寫入，你要花的不是修正邏輯的時間，是額外收拾殘局、跟每個受影響的人道歉解釋的時間。花五分鐘跑一次空跑測試，看一遍具體會發生什麼事，這五分鐘换來的是把「上線後才發現問題」的風險，提前攔在「上線前就看到問題」的階段，這筆帳在任何規模的排程任務上都划算。