Lovable 程式碼錯誤：如何檢查一個你沒有親手寫的應用程式

先從一個誠實的前提開始

如果你看不懂程式碼，就沒辦法審查程式碼，而這件事不必覺得愧疚。替代方案不是審查，而是檢查行為。反正你的使用者本來就是這樣用的，而且這種做法能抓到一整類光靠閱讀會漏掉的問題。

生成出來的應用程式，出問題的順序其實很好預測。先檢查這幾項。

看起來存檔了，其實沒有	表單顯示成功訊息，重新整理後那筆資料卻不見了。在相信任何一次儲存之前，一定要先重新載入頁面。
空狀態與錯誤狀態	一切順利的那條路徑做出來了，也示範過了。沒有任何結果、請求失敗的情況往往沒有。試試看完全沒有資料的狀況，以及故意輸入錯誤的內容。
第二個使用者	在建立應用程式的那個帳號底下，一切都正常。換成別人，最先壞掉的就是權限、資料歸屬和可見性。在拿給任何人看之前，先用第二個帳號登入試一次。

週末專案用手動檢查沒問題，但只要你持續下指令，手動就撐不住了。每一道新指令都可能悄悄毀掉昨天還正常的東西，而手動檢查每做一次就會少做一點。

你要的是把這些檢查寫下來、自動執行，而且是用白話描述，而不是寫成測試程式碼。設定好之後，這項能力就交到 agent 手上，讓檢查與開發同時進行。

這一切在 TestSprite 儀表板裡也都做得到；如果終端機不是你工作的地方，這通常是比較好的路線。CLI 的細節請見 CLI 儲存庫。

東西出錯時，直覺反應就是說「這壞掉了」。這句話能給 agent 的資訊非常少，換回來的往往是一個修到旁邊某個東西的改動。

三句話的效果好得多，而且每一句都不需要技術用語。你依序做了什麼。你預期會發生什麼。實際發生的又是什麼。「我填好表單按下儲存，我預期會在清單裡看到新項目，但清單一直是空的，直到我重新載入」就是一份真正好的問題回報，而且直接指向缺陷本身。

同樣這三句話，也就是你要留下來的那項檢查。寫下來一次，之後每一次改動都能重跑一遍，同一個問題才不會再跑回來。

有一套順序比到處亂點更快找到問題，而且大約只要十分鐘。

先從登出狀態開始，以全新使用者的身分註冊，因為這條路徑是你自己用得最少的一條。接著把你的應用程式存在的意義那件事從頭做到尾，而且在相信任何結果之前先重新載入頁面。然後再故意做錯一次：必填欄位留空、該填數字的地方填文字、上傳一個離譜的東西。最後刪掉一筆資料，確認它是真的消失了，而不只是被藏起來。

這四件事每件只花一兩分鐘，而且各自對應到生成應用程式最容易失敗的一類問題。按照這個順序做很重要，因為註冊一旦壞了，後面所有東西都測不了，而人們常常花上一小時去弄一個根本沒人進得去的功能。

在應用程式真正走進現實之前，讓這些檢查在每次改動時自動執行，而不是等你想起來才跑。有兩種做法：

從儀表板連接儲存庫，測試就會從你原本就會產生的部署開始執行；或者，改在你自己的工作流程裡加上一個步驟。

你用白話描述什麼情況才算正確，點擊的工作交給 TestSprite。不用測試程式碼、不用框架、也不用終端機：在儀表板裡建立一個專案，指向你的應用程式，然後說明能正常運作的版本長什麼樣子。

本頁提到的那四類問題，正是它涵蓋的範圍。它會以新帳號註冊、建立一筆資料再重新載入確認有存下來、送出無效的內容看應用程式會不會說出來，並以第二個使用者的身分跑同一段流程，抓出你自己的登入狀態裡內建的那些權限假設。

在你持續下指令的過程中，真正關鍵的是這些檢查會一直留著。每一次改動都會對照先前所有正常運作的東西做驗證，這正是終結「修好一個、又默默弄壞另一個」那個循環的方法。

不需要。這些檢查用白話描述，並透過應用程式的介面執行，就跟真人使用的方式一樣。

通常是權限或資料歸屬的問題。建立應用程式的那個帳號握有新帳號沒有的資料與存取權。以第二個使用者的身分測試，馬上就會讓這件事浮現。

兩者都要，而且後者更重要。在你下最新那道指令之前就已經存在的檢查，才能告訴你那道指令有沒有弄壞什麼。

那就是該讓檢查持續執行、而不是等到最後才跑的訊號。每一次改動，都會對照先前所有正常運作的東西做驗證。

不是。只要是快速生成出來的東西，不管是什麼做出來的，都會出現同樣的失敗。Lovable 的使用者只是因為更早出貨，所以更早遇到。

簡短版

大多數 Lovable 程式碼錯誤就是：儲存後沒有真的留下來、缺少空狀態，以及只有建立它的那個帳號才能用的東西。先檢查這三項，再在分享應用程式之前把檢查自動化。