Trae 除錯工具的循環會卡在哪裡
只看原始碼除錯的 agent 能讀、能推理、能修改，卻無法觀察。觀察這件事是由你提供的：憑著印象、用文字描述，而這個管道很窄。它只帶進你注意到的部分，漏掉你認為無關的部分，而關鍵往往就在後者。
當 agent 把你的描述所能支撐的假設都試完，停滯就出現了。再多跑幾輪也沒有用，因為輸入的資訊並沒有變好。
這三種錯誤最容易卡住
時序
畫面在資料回來之前就先渲染了，或是請求在元件已經消失之後才完成。
從 diff 完全看不出來，親眼看它跑一次卻一目了然。
殘留狀態
第一次操作沒問題，第二次就失敗，因為有東西沒有被重設。
每次都從全新狀態開始的重現流程，永遠看不到它。
環境不一致
程式碼是對的，問題出在環境：少了某個變數、快取過期、資料不一樣。
agent 一直在修一段根本沒壞的程式碼。
補上觀察這個步驟
與其由你描述看到了什麼，不如讓某個東西實際去操作已部署的應用程式，再回報發生了什麼事。這樣 agent 拿到的就是紀錄，而不是回憶：嘗試了哪些操作、應用程式做了什麼、兩者在哪裡出現落差。
完成設定後，agent 就具備這項能力，可以自己產生並讀取證據，不必等你轉述。
終端機
npm install -g @testsprite/testsprite-cli
testsprite setup
如果你不想在本機安裝任何東西，TestSprite 儀表板也提供同樣的設定。CLI 其餘的功能都收錄在 CLI 儲存庫。
兩個能打破停滯的問題
從乾淨的狀態開始，它還會失敗嗎？ 如果會，那是邏輯問題。如果只有第二次才失敗，那就是殘留狀態，而目前為止所有針對程式碼的假設都打錯了方向。
換一個環境，它還會失敗嗎？ 如果同一個版本在兩個地方表現不同，就別再改程式碼了。兩個環境之間的差異本身就是問題所在。
這兩個問題都很容易得到答案，而且只要答案出乎意料，整場除錯的方向就會跟著轉變。
修好之後，把重現流程留下來
你為了看見問題而建立的案例，正是防止它復發的檢查。每次改動都跑一次，而不是隨著對話一起刪掉。
觸發時機比執行機制更重要。把它掛在部署事件上，每次改動都會被檢查，不需要任何人特別做決定； GitHub App 可以從儀表板做到這件事，而 GitHub Actions 步驟則是在你的工作流程裡完成同樣的事。
為什麼 agent 一直提出類似的修法？
因為輸入沒有改變。沒有新的觀察，它只能換個說法，在同一個假設空間裡反覆打轉。
我應該貼上更多日誌嗎？
更多訊號會有幫助，而日誌記錄的是程式碼做了什麼決定，不是使用者實際經歷了什麼。實際對真實應用程式跑一次，才能補上日誌留下的空缺。
這是 Trae 才有的問題嗎？
不是。任何只看原始碼除錯的 agent 都有同樣的盲點。工作流程不同，但缺少的那一步完全一樣。
如果我沒辦法穩定重現呢？
那麼「時好時壞」本身就是發現。把同一個案例跑上幾次再互相比較。每四次失敗一次的流程屬於時序或狀態問題，這就把搜尋範圍縮小了不少。
修正需要另外驗證嗎？
需要。由同一套推理提出、又由同一套推理確認的修正，沒有任何獨立證據。必須有東西實際去觀察修正後的行為。