這個問題通常出現在第三週或第四週。第一週很爽，東西很快就出來了。第二週開始有人用，冒出一堆狀況。第三週你每修一個地方，就壞另一個地方，然後你開始懷疑：是不是該全部砍掉重做？

我的答案是：先不要急著做決定，先分清楚你在修的是哪一種問題。

大部分人的困境不是「不知道該不該重做」，是「不知道現在壞的到底是什麼」。

為什麼第一版一定會走到這裡

Vibe Coding 最容易讓人上癮的地方，是第一版的成就感來得太快。輸入需求，很快看到畫面、按鈕、流程，你會誤以為最困難的部分已經完成了。

但第一版處理的是你想像中的使用者。

第二版開始處理的才是真正的使用者。第一個人希望這樣做，第二個人偏偏希望相反。第三個人用了一種你沒想過的方式。第四個人把資料弄壞。第五個人要求匯入舊資料。

所以「越改越壞」不一定代表你做錯了。它可能只是代表真實使用者進來了，而你正在從 Demo 走向產品。這段路每個做系統的人都走過，包括我。

問題是你手上那份程式碼，撐不撐得過這段路。

判斷標準：你在修的是例外，還是地基

第一種情況：你修的都是「例外」。

某個瀏覽器顯示不對、某種資料組合出錯、某個人填了你沒想到的格式。這些問題彼此獨立，修一個不太會影響另一個。這種繼續修，這就是產品該做的事。

第二種情況：你修的是「地基」。

每次改 A 就壞 B，因為 A 跟 B 從一開始就綁在一起。資料結構跟你現在的需求對不上，所以每個新功能都要繞路。你自己已經看不懂為什麼某段程式在那裡，只知道刪掉會壞。

第二種，多半要重做。不是因為改不動，是因為你每多修一次，就多一層你看不懂的東西，之後更難重做。

一個很實際的檢查方法：叫 AI 說明「這個功能為什麼會影響那個功能」。如果它的解釋你聽得懂而且合理，是例外。如果它自己也說「因為它們共用了某個部分，建議重構」，就是地基。

還有第三種情況，很多人沒分出來：問題根本不在程式，在需求。

使用者要的跟你做的不一樣。你做了一個流程，他們用另一種方式在用。這時候不管修還是重做都沒用，因為你修的是一個沒人要的東西。先回去看使用者實際上怎麼用，把需求改掉，再決定程式怎麼辦。

重做之前，先確認兩件事

第一，你有沒有一個能退回去的版本。

我做任何修改之前，一定先把原檔備份下來、看過改了哪些地方、確認了才上線。這不是工程師的潔癖，是因為它讓「重做」變成一個可以冷靜做的決定，而不是一個絕望的決定。如果你連昨天能用的版本都拿不回來，那你面對的不是「要不要重做」，是「只能重做」。

第二，你有沒有一份「為什麼」的紀錄。

重做的時候，程式碼是最不值錢的東西。值錢的是這幾週你踩過的坑：哪些需求做了沒人用、使用者一定會卡在哪裡、哪種資料一定要先處理、哪個地方不能隨便改。

這些如果只在你腦子裡，重做的時候會再踩一次。所以在砍掉之前，先花一個小時把它們寫下來。這份東西才是你要帶去第二版的，不是程式碼。

重做的時候，改變的不是工具，是順序

很多人重做，只是換一個 AI 工具，然後用一樣的方式再來一次。結果第三週又回到同一個地方。

真正該改的是順序。第一版你是「想到什麼做什麼」，第二版應該是「先列出真實使用者這幾週丟給你的所有狀況，再決定架構」。你已經有了第一版沒有的東西：真實的問題清單。用它。

反問一下

你現在越改越壞的那個東西，如果明天重做，你能不能列出十件「這次一定要先處理」的事？

列得出來，重做會比第一次快很多。列不出來，就算重做，你做出來的還是同一個第一版。

如果你做到一半卡住，可以把狀況寫信給我。也歡迎訂閱我的電子報：https://iamlouis.ai/subscribe/edm