除錯工具的分類，以及各自的前提
單步除錯器與狀態檢視器
暫停執行，檢視當下的狀態。
前提是你能隨時觸發那個失敗。
日誌與追蹤
事後回頭看發生了什麼事，包括在正式環境中。
前提是你事先記錄了對的東西。
效能分析器
找出時間或記憶體花在哪裡。
前提是問題出在資源這一層。
每一種工具都假設你已經走到失敗發生的那一刻，而真正耗掉數小時的，正是這個假設。
被略過的那一步
穩定的重現方式是除錯過程中價值最高的產物，卻也最常付之闕如。沒有它，你只能用猜的；有了它，其他每一種工具立刻就能發揮作用。
重現方式之所以可靠，是因為它被寫成一連串帶有預期結果的步驟，而不是留在某個人的腦袋裡。寫下來之後，它可以重新執行、可以交給別人，也可以在修好之後繼續保留。
為什麼搭配 AI 程式代理時，這一點更加重要
當負責修復的是代理，含糊的描述帶來的傷害遠大於交給人處理。人可以從一張截圖推敲你的意思；代理需要你明確寫出操作順序，以及實際結果與預期的差異，少了這些，它會很有自信地修錯地方。
該依什麼順序下手
面對一個當下無法解釋的錯誤，有一套順序會比照著你的第一個假設走更快收斂，原因多半在於：你的第一個假設通常指向程式碼，而答案往往不在那裡。
在完全乾淨的狀態下還會發生嗎？如果不會，問題出在殘留的狀態，程式碼並不是你以為的那樣有錯。
在另一個環境裡還會發生嗎？如果不會，錯誤就在兩個環境的差異裡，你可以不用再盯著程式碼差異看了。
每次都會發生嗎？如果不是，問題出在時序或並行處理，這就排除了你正打算驗證的大多數確定性解釋。
三個問題，幾分鐘，每個答案都能排除一整類成因。除錯所花的時間，大多用在探索某一類成因，而這三個問題中的任何一個，本來都能立刻把它排除。
修好之後，把重現方式留下來
你為了看見這個錯誤而建立的案例，就是阻止它捲土重來的檢查。多數團隊會連同分支一起刪掉它，於是同一個缺陷半年後再度出現，卻沒有人認得它。
終端機
npm install -g @testsprite/testsprite-cli
testsprite setup
如果你不想在本機安裝任何東西，同樣的設定也可以在 TestSprite 儀表板中完成。CLI 的其餘功能都收錄在 CLI 儲存庫。
GitHub App 是你在 TestSprite 儀表板中設定的 webhook。它會監聽你的流程原本就會產生的部署事件，因此你的儲存庫不需要任何改動。
GitHub Actions 則把這一步放進你自己的工作流程裡，並從終端機完成設定。
TestSprite 如何補上缺少的那一步
它把重現方式變成一份實際的產物。你描述操作順序，以及結束時應該成立的條件，它就會對你已部署的應用程式執行，並回報實際發生了什麼。這正是其他每一種除錯工具都假設你早已具備的那一步。
安裝設定會把驗證技能裝進你的 AI 程式代理，讓它自己產生並讀取這些證據，而不必等你轉述。遇到時有時無的錯誤，重複執行同一個案例會得到一個發生比率，這比再多提一個假設更快縮小成因範圍。
而且這份重現方式會在修復之後繼續存在。它留在專案裡，每次變更都會執行，因此在分支合併、對話早已消失之後，同一個缺陷也無法悄悄回來。
最被低估的除錯工具是什麼？
一份寫下來的重現步驟。它只花你五分鐘，卻能讓其他所有工具真正發揮作用。
時有時無的問題該怎麼除錯？
把同一組步驟跑上幾次，記錄失敗比率。四次失敗一次通常是時序或殘留狀態造成的，範圍會因此大幅縮小。
只看日誌夠嗎？
日誌告訴你程式碼做了什麼判斷，而不是使用者實際經歷了什麼。許多缺陷就住在這兩者的落差裡。
代理可以幫我除錯嗎？
它可以提出可能的成因與修法，但除非有東西賦予它這個能力，否則它無法觀察執行中的應用程式，而這正是多數環境缺少的那一步。
遇到新的錯誤，第一件事該做什麼？
重現它，並把操作順序寫下來。之後的每一步都會更快，包括向別人求助。