AI 不會痛，所以沒有人重構：Vibe Coding 真正的天花板
上禮拜有個朋友傳訊息給我：「你可以幫我看一下專案嗎，這個 bug 我修三天了。」
他做的是一個接案用的預約系統。純 Vibe Coding，一行程式碼都沒有自己寫過。
兩個月前他還很興奮地跟我說，兩個禮拜就做出來了。有登入、有行事曆、有金流、有後台。他當時傳畫面給我看，老實說做得蠻好的，我還跟他說這樣很不錯。
結果第三個月，他卡住了。
——
三個月、四百多個 commit，刪除行數幾乎是 0
我請他把專案打開給我看。
handleBooking、handleBookingNew、handleBookingV2 三個並存，前面兩個沒人敢刪。
日期格式化有三份實作，分散在三個檔案裡，出來的格式還不太一樣。
到處都是 try/catch 跟 ?.，包到你看不出來原本的邏輯長什麼樣子。if (!data) return 這種防禦大概散在幾十個地方。
我問他這些 V2 是誰加的。
他說：「都是 AI 寫的吧？我也沒有看過程式碼。」
但真正讓我確定他撞牆的，不是這些。
是我打開 git log。
三個月、四百多個 commit，刪除行數幾乎是 0。整包專案從頭到尾只有 +，沒有 -。
——
沒有人痛，就沒有人重構
程式碼會爛，這件事在傳統開發裡也天天發生。
差別在，傳統開發有一個很土但有效的機制在擋：人類看到髒扣會不舒服。
家裡的垃圾之所以有人倒，不是因為誰特別勤勞，是因為放久了會臭，臭到有人受不了。技術債會被還也是同一個道理，很多時候不是誰特別有紀律，是有人被那股味道追到不行。
那段程式碼爛，下一個接手的人會痛。痛到受不了，他就會去重構。
但 Vibe Coding 把痛拿掉了。
AI 不會痛。你叫它在一坨爛程式碼上面再長一個功能，它不會抱怨，不會嘆氣，不會跟你說「這邊要先整理一下」。
它就是加。
而你根本不讀那些程式碼。
於是沒有人痛。沒有人痛，就沒有人重構。沒有人重構，那個 - 就不會出現。
——
極限不是行數，是你驗不驗得出來
我一開始也是這樣想的：純 Vibe Coding 到底能撐到幾行、幾個功能、幾個頁面？
後來我覺得這個問法是錯的。
同樣三萬行，一個後台管理系統可以一路 vibe 到底，一個對帳系統早就死了。
差別在你驗不驗得出來。
版面爆掉、按鈕沒反應、資料沒出來——你看一眼就知道。這種錯誤你當場就能驗收。
但權限少判一條、同一筆訂單被扣兩次、快取沒清、資料遷移掉了幾百筆——這些東西不會有畫面跳出來告訴你。
AI 一樣可以改到「看起來好了」。
問題是你已經沒有能力判斷，它到底是真的好了，還是這次剛好沒踩到。
也許有人會說，那我控制一下規模就好了嘛，寫到某個行數就收手。
但行數從來不是那條線。Vibe Coding 在原型階段爽到不行，是因為那個階段的驗證成本趨近於零；一旦專案開始碰到看不見的正確性，天花板就到了。我之前寫過一個人用 Vibe Coding 做到 95 分的字幕產品，那五分缺的也是同一種東西。
——
它不會壞掉，它會變貴
我覺得這件事最需要講清楚的地方在這裡：沒有人會收到一個「已達 Vibe Coding 上限」的錯誤訊息。
不會有一天專案跑不動。
實際發生的是，以前一個下午的功能，現在要三天。以前敢說「這段重寫一下」，現在不敢碰。
專案是慢慢失速，不是崩潰。所以大部分人都是回頭看的時候，才發現自己早就過線了。
那還能不能繼續靠 Vibe Coding 解？能。幾乎永遠都能，這才是麻煩的地方。
AI 讓症狀消失的能力接近無限。你說哪裡壞了，它就讓那裡不壞。
但它解掉的是那一次，不是全部沒事。
所以你會有一種很怪的體感：每一次都修好了，但永遠修不完。同一種 bug 換個位置又冒出來，你也說不出它們哪裡一樣，就是覺得很眼熟。
其實 AI 不會發現哪裡奇怪，它只會聽令於你繼續做。
——
那要怎麼做才撐得住？
講完問題，來講做法。這三件事我覺得順序不能換。
一、系統的核心，要放在檔案裡
整件事可以收斂成一個問題：這個系統的核心放在誰身上？
放在你腦袋裡，上限就是你記得住多少，大概幾週。放在這次對話裡，上限就是這個 session，關掉就沒了。
所以我一再推崇文件、文件、文件。
只有「給人類閱讀的文件」留得下來，有故事、有脈絡、有核心價值，去蕪存菁，不要有太多雜音。
規格要變成檔案，不是變成聊天記錄。
你跟 AI 講過的每一個決定，都會在關掉視窗的那一刻消失。下次它重新猜一遍，猜出來的不見得是同一套。
所以要有一份規格文件，講清楚這個系統有哪些角色、哪些狀態、什麼情況不能發生。每次改動完，順手叫 AI 同步回去。
這份檔案才是你真正的資產。程式碼是最不值錢的，現在最值錢的是你運轉起來的商業模式。
二、測試是把看不見的錯誤變成看得見
寫測試不是為了覆蓋率，是為了讓「壞掉」變成看得見。你也仍然需要一個現在會失敗的測試。
不要以為使用者會照你的預期走。上一頁、重新整理、直接關掉⋯⋯沒有測試，你根本管不到這些奇怪的行為。
Vibe Coding 的天花板是驗證能力，測試就是把不可見的正確性強制變成可見。
這件事本來就很適合交給 AI：你先描述「什麼情況算錯」，讓它寫出一個現在會失敗的測試，再叫它去改到通過。順序反過來，你就永遠只是在看畫面猜。
三、模組要切到你敢整包重寫
Vibe Coding 最強的地方是重生成，不是維護。
所以模組要切到一個程度：這塊爛掉了，你可以連同它的測試整包重寫，不會牽動別人。
判準很簡單——你敢不敢跟 AI 說「這個資料夾整個重做」。不敢，就是切得不夠開。這是我覺得最便宜、也最有效的一個習慣。
至於怎麼看有沒有在整理，你不用真的去讀程式碼，看 diff 的加減行數就夠了。專案只長不縮，代表沒有人在整理。等到累積到十萬行？三十萬行？一百萬行？你才會感覺到真的不對勁。
——
寫到這邊好像變成在勸大家回去寫測試、寫文件、做重構。
但我想講的其實是：這些事現在全部都可以叫 AI 做。
你可以叫它補測試、叫它設計邊界、叫它維護規格、叫它去刪自己上禮拜寫的垃圾。你依然一行程式碼都沒有自己寫。
所以會撞牆的，從來不是 Vibe Coding 這件事，是那種什麼都不留下的做法。
——
但我還是要講一段比較難聽的
我朋友算是運氣好的。
他那個系統還沒有真的收錢，使用者只有他自己跟兩個測試的人。他發現得夠早，重寫一個禮拜就結束了。
比第一次做久了三倍，但他現在敢改了。
「敢改」這兩個字，我覺得就是分水嶺。
真正麻煩的，是那些已經上線、已經在收錢、資料庫裡躺著幾千筆別人資料的專案。你可以承受動不動就改資料庫？動不動就掉幾百筆別人的資料？
因為你看不見的那些錯誤，第一個發現的人通常不是你，是使用者。
他發現的時候，通常已經是「我的錢被扣兩次」「我看到別人的訂單」「我的資料不見了」這種形式。
到那個時候你面對的不是 bug，是要不要退款、要不要公告、要不要通報個資外洩。
我知道講這些很掃興。我一直很鼓勵非工程背景的人玩玩 Vibe Coding，大家在上面得到的快樂是真的，我自己也很享受。
但快樂跟風險從來就不是同一件事。你在兩個禮拜做出一個系統的時候，省下來的不只是時間，還有那些原本會逼你想清楚的環節。功能做出來只是一句話，難的部分本來就不在那一句。
省下來的部分沒有消失，它只是被記在後面。
所以最後我想問的，不是你的專案有多大、有幾行、做了幾個功能。
是這個：如果今天有人跟你說「你們系統有個地方好像會多扣錢」，你有辦法在半天之內確認他到底是不是在唬爛你⋯⋯？