Vibe testing 實際上拿掉了什麼
它拿掉的是轉譯這一步。一般情況下，你心裡很清楚想要什麼行為，接著花一小時把它變成選擇器、等待與斷言，而這些大多是在應付框架，不是在處理你的產品。改成描述行為、由 agent 負責轉譯，等於保留了有意義的部分，捨棄了沒有意義的部分。
第二個被拿掉的是維護成本。以意圖表達的步驟撐得過改版，寫死的選擇器則不行，因為按鈕搬了位置，意圖依然成立。
用描述定義的檢查會在哪裡出錯
模糊到不可能失敗
「檢查儀表板能正常運作」不可能失敗，因為它沒有主張任何具體的事。
指明可觀察的對象：哪一個數字、哪一列、哪一種狀態。
對動作做斷言
「點擊儲存」是一個步驟，不是一項檢查。執行一次可以把它做完，卻什麼也沒證明。
說清楚事後什麼應該成立，而且要是重新整理後仍然能確認的事。
主體不明確
「使用者看得到自己的訂單」沒有交代是哪一位使用者，而權限相關的錯誤正好就藏在這裡。
指明是誰的訂單，並檢查其他人看不到這些訂單。
區分真正有效的檢查與裝飾用檢查的唯一習慣
刻意把功能弄壞，確認檢查真的會亮紅燈。這只要花一分鐘，而且這是唯一能證明這項檢查真的連著什麼的證據。
這件事在這裡比在手寫測試上更重要，因為用描述定義的檢查有更大的空間被寬鬆解讀。一次跑完卻從未碰到任何斷言的執行不算通過，而唯一能發現自己手上就有這種檢查的辦法，就是試著讓它失敗。
開始使用
安裝設定會把這項能力裝進 coding agent，讓你在寫程式碼的同一個地方描述並執行檢查。
這些都不需要用到終端機。在 TestSprite 儀表板建立專案，用白話描述檢查，再指向你的應用程式就行了。團隊裡的開發者若偏好命令列，也可以用同樣的方式操作，相關內容收錄在 CLI 儲存庫。
先描述什麼
你會拿來展示的流程。 這條流程一旦壞掉，你會在眾人面前才發現，所以它應該最先被涵蓋。
任何牽涉到金流或權限的部分。 出錯時代價最高，而且兩者都是無聲失敗。
上一次壞掉的東西。 凡是曾經害你踩坑的地方，都值得留一項長期檢查，而且你已經很清楚該怎麼描述它。
寫出經得起考驗的檢查描述
一項檢查究竟是在保護你，還是只是替 pipeline 做裝飾，差別幾乎都出在它是怎麼被描述的，而這個模式是學得會的。
好的描述有三個部分：起始狀態、一個動作，以及事後某個重新整理後仍可確認的可觀察結果。「以一位已登入、且沒有任何已儲存篩選條件的使用者身分，建立一個名為 Recent 的篩選條件，重新整理，確認它出現在側邊欄。」這段描述的每個環節都可能失敗，而失敗會告訴你問題出在哪裡。
拿它跟「檢查篩選功能可以用」比較看看。意圖相同，但沒有起始狀態、沒有具體動作，也沒有可觀察的結果。agent 接到這種要求，會做一些看起來合理的事然後回報成功，而你什麼也沒學到。差別全在於第一種寫法多花的那十五秒。
接著，別再每次都決定什麼時候要跑
無論是用描述的還是用寫的，只要一項檢查要等人來啟動，忙碌的那一週就會被跳過。
從儀表板連接儲存庫，執行就會從你本來就會產生的部署開始；或者，你也可以改為在自己的工作流程中加入一個步驟。
TestSprite 如何處理用描述定義的檢查
你說出什麼應該成立，TestSprite 負責想出該怎麼檢查，並對你已部署的應用程式執行。那個從來就不是重點的轉譯步驟，就此消失。
有兩項特性讓結果耐得住變動。步驟是以意圖的形式儲存，而不是以 DOM 中的路徑，所以改版把按鈕搬走也不會弄壞檢查。另外，結果會以描述的形式回傳：嘗試了什麼、發生了什麼、兩者在哪裡出現落差，而這正是讓 coding agent 能直接針對失敗採取行動、不必先由人來解讀的原因。
調整同樣停留在白話層次。如果一項檢查太寬鬆，用一句話講出來就好，不必去改程式碼，而這正是用描述定義檢查值得採用的全部理由。
Vibe testing 夠可靠，能用在真正的產品上嗎？
就流程的行為面覆蓋而言，可以，前提是每項檢查都指明了具體的東西，而且你已經確認過它真的會失敗。至於精確順序或元件層級的斷言，手寫測試仍然是比較合適的工具。
這跟錄製點擊流程有什麼不同？
錄製記下的是一條路徑，路徑一變就壞了。用描述定義的檢查記下的是意圖，變更之後依然成立，維護成本的差異大半來自這一點。
如果 agent 對我的描述有不同的解讀怎麼辦？
在信任這項檢查之前，先把產生出來的步驟讀過一次。解讀上的錯誤在這個階段一目了然，等到後來變成一份通過的結果，就難找得多。
我可以調整一項檢查，而不必整個重寫嗎？
可以。用白話調整就好，方式跟你當初描述它時一樣。
這會取代單元測試嗎？
不會。單元測試更快，也更擅長處理邏輯。這套做法涵蓋的是它們看不到的那一層：組裝起來的產品行為是否正確。