Cursor 除錯工具：修復循環為何會卡住

Cursor 除錯工具的流程為何會卡住

除錯是一個循環：觀察、提出假設、修改、再觀察。只靠你的檔案運作的 AI 代理程式做得到其中三步，唯獨無法觀察。每次你貼上堆疊追蹤、或描述畫面上看到的狀況，其實就是在手動補上它做不到的那一步；而整個循環的品質，就被你的描述能力給限制住了。

這就是為什麼第三輪通常比第一輪更糟：你累了，描述變短，而 AI 代理程式推理的對象，已經是摘要的摘要。

三種會誤導 AI 代理程式的描述

什麼才能讓循環閉合

把觀察這一步交給 AI 代理程式，而不是自己動手。也就是讓某個東西像真人一樣去操作已部署的應用程式，並把發生的狀況以證據的形式回報，而不是寫成一段文字敘述。

證據的形式比數量更重要：嘗試了什麼、應用程式實際做了什麼，以及兩者在哪裡出現落差。AI 代理程式可以直接依據這些行動。截圖和堆疊追蹤仍然需要人來解讀，那又把你拉回你原本想離開的那個循環。

安裝設定會把一套驗證技能裝進 Cursor 本身，讓它知道如何建立測試案例、執行測試並讀取結果，不必每次都由你說明一遍流程。

你也可以在 TestSprite 儀表板中完成同樣的操作。CLI 的其他所有功能，都記錄在 CLI 儲存庫。

能交出去的重現步驟，勝過一段描述

效益最高的習慣只有一個：別再描述 bug，開始重現它。寫下來的測試案例會說明要開哪一頁、要做什麼，以及之後應該成立的結果。三行這樣的內容，勝過三段解釋，因為它沒有模糊空間，而且可以重跑。

這也改變了你和 AI 代理程式的對話。輸入不再是「下拉選單壞了」，而是一次跑到第四步、發現選到錯誤選項的執行結果。沒有任何需要解讀的餘地。

在第一次嘗試修復之前就把測試案例寫好，而不是等到第三次之後。那個時候你還清楚記得自己做了什麼才觸發它，而這種記憶消失的速度比任何人想像的都快。

循環閉合的實際例子

舉個具體例子。有使用者回報，編輯已儲存的篩選條件時，有時候會被還原。你描述了狀況，AI 代理程式找出兩個狀態更新之間的競爭條件，並提出一個防護判斷。你套用之後試了一次，可以了，就繼續往下做。兩天後，同樣的回報又出現了。

出問題的不是那個修法，而是面對間歇性的 bug，手動試一次只是樣本數為一的驗證；而間歇性的 bug 在單次嘗試中通過的機率，和失敗的機率其實差不多。真正能收斂的循環長得不一樣：把操作步驟寫成測試案例，跑上好幾次，然後看失敗率。十次裡失敗四次，對 AI 代理程式來說，和「它壞了」是完全不同的指令，因為這排除了一整類確定性的成因，並直接指向時序問題。

第二個改變的地方，是修完之後。同一個測試案例再跑十次，失敗率不是歸零，就是沒有歸零。你手上握有的是證據，而不是印象；而且這個案例會留在測試套件裡，所以第三次回報永遠不會出現。

最該懷疑的那句話

在 AI 代理程式輔助的除錯裡，「我已經修好這個問題了」是代價最高的一句話。它和那項修改出自同一套推理，因此不帶任何獨立資訊。修復要算確認，必須是實際觀察到行為正確；而就定義而言，寫出這項修改的 AI 代理程式，不可能同時是確認它的那一方。

這不是在批評模型。如果有人寫了一段修補程式碼，什麼都沒執行就宣告它是正確的，在程式碼審查時也會得到同樣的回應。

讓這道檢查在對話結束後留下來

你為了重現 bug 而寫下的測試案例，修完之後比修的當下更有價值。把它留著，並在每次變更時執行，這樣同一個缺陷就不會在三週後悄悄回來。

• GitHub App 是你在 TestSprite 儀表板中設定的 webhook。它會監聽你現有流程本來就會產生的部署事件，因此你的儲存庫不需要做任何更動。

• GitHub Actions 則把這個步驟放進你自己的工作流程裡，並透過終端機完成設定。

在循環中加入驗證步驟後，會有什麼不同

TestSprite 補上了這個循環缺少的觀察環節。安裝設定會把一套驗證技能裝進 Cursor 本身，讓 AI 代理程式可以建立測試案例、對你已部署的應用程式執行，並直接讀取結果，不需要你居中轉述任何事情。

反映在實際除錯過程上的效果，就是同樣的回合不再一輪輪重複。AI 代理程式不再根據你對所見狀況的回憶來推理，而是握有一份記錄：嘗試了什麼、應用程式做了什麼，以及兩者在哪裡出現落差。它提出的修復，會由產生這項修復的推理以外的東西來確認——這是讓「我已經修好了」變成資訊的唯一方式。

重現步驟也會比這次對話活得更久。找出 bug 的那個測試案例會留在測試套件裡，並在每次變更時執行，所以同一個缺陷不可能在六週後悄悄回來。