Antithesis 除錯教學：讓 AI 回到失敗現場，重播、查原因再驗證修正
Antithesis 除錯如何交給 AI？從可失敗的正確條件、執行編號與時間點開始，利用官方技能、Snouty CLI 與 API 回到問題現場。附可改的除錯提示詞、假設紀錄與驗收流程，分清楚重播找到原因、修改程式，以及重新測試通過的不同證據。
Antithesis 除錯的特色，是保留測試中的執行過程，讓你或 AI 回到問題發生的時間點，檢查當時的狀態，再用證據判斷該修哪裡。
這對偶爾才出現的錯誤特別有價值。例如服務平常都正常，卻在節點暫停、網路延遲與重新選舉同時發生時讀到舊資料，單看程式碼不一定容易發現。
Antithesis 在十月十五日宣布，時間旅行除錯能力可透過程式介面與命令列使用，讓代理直接調查失敗執行，減少人手在除錯器與代理之間搬運資料。
但它需要已接入 Antithesis 的系統、測試與對應版本，不是貼上一段提示詞，就能重播任意網站的歷史。官方公告也指定 Release 64 作為這次功能的可用前提。
本文依二〇二六年十月二十三日核對的官方資料，提供實作順序與本站自寫的提示詞，沒有虛構實際執行紀錄，也不把示範案例當成所有系統都能得到相同結果。
若你的困難是無法再次遇見同一個錯誤，這類工具值得研究。若只是固定輸入就能穩定失敗的小函式，先用一般測試與偵錯工具，通常更容易開始。
Antithesis 除錯適合哪一種失敗？
它最有用的情境，是錯誤依賴一連串難以重現的執行條件，而不是只看單一輸入就能解釋。
官方公告以分散式系統的讀寫問題說明，測試環境可以保留精確重播，讓調查者回到失敗時刻，檢查節點與資料狀態。分散式系統，就是多個服務或節點一起工作、需要互相協調的系統。
為什麼再跑一次沒有錯，仍然不夠？
因為競爭條件常和執行順序有關。同樣的程式，兩個請求先後不同，可能一輪正常、一輪錯誤，重新執行沒有再次碰到，不能證明問題消失。
例如你要驗證寫入完成後不會立刻讀到更舊的值，正常情境可能一直通過。但如果主節點暫停後又恢復，其他節點已選出新主節點，舊節點仍認為自己能回答，就可能違反原本的要求。
這種情況需要看當時誰先做什麼、各節點認為狀態如何，才能提出修正。時間旅行的價值是固定調查起點，讓不同假設都回到同一個失敗現場比較。
工具能替代你定義正確行為嗎？
不能。它能保留與探索執行狀態，但什麼算正確，仍需要你的系統規格與測試條件。沒有這層定義，代理可能只是在追逐看起來可疑的訊息。
先把問題寫成一句可以被推翻的要求，例如「成功回覆寫入後，後續讀取不得回傳更早版本」。這句才是調查與修正共同指向的目標。
先把正確行為寫成可失敗的條件
開始前先準備系統在測試環境中的啟動方式、負載與正確性條件，因為除錯器需要一個真正會產生失敗證據的執行。
官方技能文件把建置、測試與除錯放在相關工作流程中，讓代理依任務取得指引。若團隊還沒有接入平台，應先完成環境與測試，而不是跳到調查提示詞。
第一個條件要多小？
選一項會改變使用者結果的保證即可。例如同一筆付款只應處理一次、已確認的資料不應倒退，或某項操作失敗後不應留下半完成狀態。
把範圍縮小有助於辨認原因。若一開始只說「系統不能出錯」，代理會遇到大量日誌與警告，卻不知道哪個對業務結果最重要。
接著準備會觸發行為的工作負載，也就是測試會持續做的事情。它可以包含建立資料、更新與讀取，再用條件檢查結果，讓錯誤有機會被看見。
失敗訊息要帶什麼？
保留事件時間、受影響的識別碼、預期結果與實際結果。若只寫一行「測試失敗」，回到現場仍不知道該查哪個節點或哪筆資料。
可以先讓代理檢查現有失敗訊息是否足夠定位，再補最少必要資訊。不要把整個資料庫與所有憑證一口氣倒進日誌，調查需要的是相關狀態，不是無差別收集。
下面是教學用的條件設計，實際名稱與欄位要配合你的系統。它們是示範驗收要求，不代表本文已經用平台測過。
| 條件 | 需要觀察的狀態 | 可能的失敗證據 |
|---|---|---|
| 重複請求不重複執行 | 請求編號與處理次數 | 同一編號產生兩次結果 |
| 已確認資料不倒退 | 寫入版本與讀取版本 | 讀到較早版本 |
| 失敗不留半套資料 | 相關資料的完成狀態 | 主記錄完成、附屬記錄缺失 |
表格讓代理能從業務要求對應到系統狀態。後面提出修正時，也必須回來說明它解決哪個失敗條件。
用執行編號與時間點鎖定失敗現場
調查時先固定同一個執行編號與失敗時間，再看相關狀態。因為「最新一次測試」會持續改變，使用明確識別資訊才容易讓別人重查。
官方說明，程式化的時間旅行除錯接受執行中的測試編號、要進入的時間點，以及要執行的命令或腳本。回傳的是該分支上的輸出，而不是普通正式機器上的任意操作。
第一個調查動作應該做什麼？
先確認條件真的違反，再擷取相關節點的狀態與事件順序。這能避免代理看到一個警告，就直接把它當成根因。
例如讀到舊值時，先查讀取發生在哪個節點、節點認為誰是主節點，以及它保存的版本。這些證據會決定你接下來該查資料同步、主節點判斷還是讀取路徑。
每次只提出一個可驗證的假設，再設計能區分它的檢查。若兩種原因都可能造成舊值，就不要只找支持其中一個的訊息，也要問什麼結果會推翻它。
回到不同時間點能看出什麼？
可以先看失敗前狀態，再比較關鍵事件後的變化。因為故障常是多個狀態累積，單看失敗後畫面，可能只看到結果，看不到哪一步開始偏離。
調查紀錄應寫下時間點、執行的檢查、觀察與下一個問題。這樣即使代理中斷，另一位工程師也能沿著證據接續，而不是重新猜一次。
對無法支持的假設也留下排除理由，避免後面又花同樣時間重查。有效的除錯報告不一定很長，但應能說明為何從多個可能原因縮到這一個。
用官方技能、命令列或程式介面查證假設
官方提供的 antithesis-debug 技能，是讓代理學會如何使用除錯能力的入口。技能不是另一個測試平台，實際操作仍需要有效的環境、工具與權限。
你也可以使用 Snouty CLI，也就是在終端機操作平台的命令列工具，或透過 API，也就是程式能呼叫的服務介面。選擇方式應配合團隊已經使用的工具。
需要直接背完整指令嗎？
不必把容易變動的參數寫死在長提示詞。先讓代理閱讀官方 Snouty 文件，確認當前版本與必要參數，再顯示準備執行的目標。
公告列出的入口包含 snouty runs exec 與 /command，但不同驗證方式與環境設定仍需依官方文件。本文不補造未核對的完整命令，避免讀者直接執行不存在的參數。
官方也提到可以先搜尋失敗事件，再跳入調查，讓兩個步驟接起來。這表示你可以從明確違反條件的紀錄開始，不必讓代理對整份日誌漫無目的地閱讀。
時間分支裡修改檔案，等於修好專案嗎？
不等於。除錯分支的用途是調查或測試假設，即使在裡面修改檔案、重啟節點，也不會自動變成專案正式修正。
根因確認後，仍應在受版本控制的程式碼中做最小修改，再建立新的測試執行。把這兩個位置分清楚，報告才不會把「試過一個想法」寫成「修正已交付」。
可改的 Antithesis 除錯提示詞與證據交付
以下是本站自寫的調查提示詞。它假設環境已完成接入，並由你提供失敗執行資訊，不是任意程式都能直接使用的安裝指令。
請調查我提供的Antithesis失敗執行，先不要修改正式環境。
目標條件：成功確認寫入後，後續讀取不能回傳更早版本。
輸入：執行編號、失敗時間、相關事件與目前程式版本。
先讀官方antithesis-debug與Snouty文件，確認工具版本可用。
固定執行編號與時間點，檢查失敗是否符合目標條件。
提出一個假設，再列出能支持或推翻它的查詢。
保留每次檢查的時間點、命令目的、輸出位置與結論。
找到根因後，先交證據與最小修正提案。
把除錯分支的實驗，和專案中的程式修改分開記錄。
完成修改後另開測試，不以一次沒有重現當成全面通過。
無法確認根因時，說明已排除什麼與仍缺哪個證據。
第一份報告先要能回答「錯誤何時開始、哪個狀態不符合要求、哪個觀察排除了其他原因」。若只能看到一段合理故事，就要求補回對應輸出。
怎麼判斷報告是證據還是推測？
報告可以分成觀察、解釋與下一步。觀察例如某節點回報的版本，解釋則是代理認為版本為何落後，兩者不要寫成同一句無法拆解的結論。
如果修改提案是「增加重試」，請它說明重試如何修復已確認的失敗條件。若只是讓問題比較難出現，沒有改變錯誤的狀態轉換，仍需要進一步驗證。
對重要修正，要求另一位審查者依相同時間點與資料重查關鍵推導。因為重播的優點是能共享同一個現場，不應最後只剩代理口頭保證。
一個被排除的假設，也應留下證據
假設代理先懷疑資料沒有同步，卻在失敗時間點看到新版本已經存在於回覆節點。這個觀察不能證明所有同步都正確，但能排除這次錯誤只是資料尚未到達的簡單解釋。
接著才把焦點移到讀取路徑如何選版本，會比直接改同步重試更有方向。把排除範圍寫清楚，也能防止報告把局部觀察誇大成整套系統都沒有問題。
修正後另開測試，別把一次通過當成結案
驗證修正需要新的執行，因為舊的失敗現場只證明原本錯誤如何發生。新的程式能否在相關條件下維持正確，必須另外取得證據。
先回測原本的失敗類型，再檢查相鄰行為。比如修正主節點判斷後，也要看正常寫入與讀取是否仍可完成，避免把舊值問題改成永遠無法回覆。
一份可交接結果要包含什麼？
保留原始失敗執行、根因說明、修改版本、新的測試編號與結果。這些資料串在一起，審查者才知道測到的是哪份修正，而不是另一個版本。
沒有再次出現同一錯誤，也應寫出測試涵蓋的條件與時間。因為任何測試都有範圍，不能把有限次通過擴成所有生產情境都安全。
若新一輪出現不同失敗，先判斷是否由修改引入，再開另一筆調查。把每個問題維持清楚身分，會比在同一份報告裡不斷加入新猜測更容易收斂。
還沒找到原因時，怎麼交付進度？
列出已驗證的觀察、已排除的假設與下一個需要的資料即可。例如尚缺節點恢復前的狀態，就明確要求那個時間點的證據，而不是重跑所有檢查。
也要保留工具無法使用或版本不符的情況。環境限制和根因未明是不同阻礙，分開寫，團隊才能知道應先修工具，還是繼續查程式。
這類工作方法和一般程式審查可以搭配，但各自回答不同問題。審查協助理解修改是否合理，執行證據則用來確認行為，兩者都需要明確範圍。
延伸閱讀：Claude 寫了九成程式，誰來審？Claude Code 團隊公開分層審查流程
延伸閱讀：Claude Code Review 正式開放：Team、Enterprise 的 Quick、Standard、Deep 怎麼選？
常見問題 FAQ
Antithesis 除錯能重播任何正式網站嗎？
不能。需要系統已在 Antithesis 環境中執行並保留相關測試資料，公告指定的功能也有版本前提。
安裝技能後就一定能找到根因嗎？
不會。技能提供操作指引，仍需要可用工具、正確條件與足夠狀態資料，複雜問題也可能需要人工協助。
為什麼不直接讓 AI 讀整份日誌？
可以協助查線索，但大量日誌不一定包含關鍵狀態。回到明確的執行與時間點，更容易提出能被證據支持或推翻的假設。
新測試通過就可以自動部署嗎？
測試通過是證據之一，部署仍取決於團隊原有流程、審查與授權。本文的教學交付止於可檢查的修正與測試結果。
把修正接回能重查的執行證據
先選一個難重現、但正確行為明確的問題，固定失敗執行與時間點，讓代理逐步檢查假設。找到原因後再修改、另開測試，最後交付能讓他人重查的資料。歡迎訂閱 AI 郵報，持續取得 AI 開發工作流程的實用教學。
