Vibe Coding後遺症
是否有人用AI寫網站，後來根本無法維護？
有，而且這個現象常見到已經有專有名詞了——叫做 "vibe coding" 的後遺症，或業界戲稱的 "AI 技術債"（AI Technical Debt）。
一、 真實發生的狀況
我整理一下目前看到比較典型的「翻車案例」：
案例一：堆積式開發的崩潰 創業者用 AI 一路「再加一個功能」、「再改一下這裡」，三個月後網站有 200 個檔案，沒有人（包括 AI 自己）搞得清楚哪個函式被誰呼叫。要改一個按鈕顏色，AI 改完結果結帳功能壞掉。
案例二：資安地雷 AI 為了「讓功能可以動」，把 API key 寫死在前端、資料庫密碼放在 GitHub 公開 repo、沒做任何輸入驗證。等到被駭客掃到、信用卡資料外洩，才發現代誌大條。2024 年確實有幾個用 AI 快速做出來的 SaaS 產品，因為 Supabase 設定錯誤導致全部使用者資料外洩。
案例三：沒有人看得懂的程式碼AI 為了解決某個 bug，可能會寫出非常迂迴的解法（用了 5 層巢狀條件判斷處理一件簡單的事）。原本的開發者離開後，新來的工程師看了一個禮拜還在問：「這段到底想幹嘛？」最後決定整個砍掉重做。
案例四：依賴套件地獄 AI 很愛裝套件解決問題。一個簡單的網站可能裝了 80 個 npm 套件，其中有些已經停止維護、有些有資安漏洞、有些彼此衝突。要升級任何一個都會引發連鎖反應。
二、 為什麼會這樣
幾個根本原因：
AI 是「補完式」思考，不是「架構式」思考 你叫它做什麼它做什麼，但它不會主動跟你說「你這樣做未來會出事」。它優化的是「這次對話讓你滿意」，不是「三年後這個系統還能維護」。
沒有整體脈絡 AI 每次對話的記憶有限，改了 A 檔案可能不知道 B 檔案有相關邏輯，導致前後不一致。
使用者不知道自己不知道什麼 傳統工程師會在你提需求時告訴你：「這個之後會有效能問題」、「這個資料結構錯了」。AI 不會主動阻止你做蠢事，它會非常熱心地幫你把蠢事做好。
測試？什麼測試？ 很少人用 AI 寫程式時會請它同步寫測試。結果就是改一個地方不知道哪裡會壞。
三、 真實的後果
我看過分享出來的幾種結局：
- 整個砍掉重做：花了 3 個月用 AI 寫的東西，最後請工程師花 1 個月重寫，因為改比重寫還貴。
- 被綁架：找工程師接手，對方看了報價直接 ×3，因為要先花時間搞懂這坨程式碼。
- 永遠停在那個版本：不敢動它，因為一動就壞，但又有新需求做不了。
- 資安事故：被入侵、被勒索、客戶資料外洩，賠的錢遠超過當初省的。
- 永遠停在那個版本：不敢動它，因為一動就壞，但又有新需求做不了。
四、 怎麼避免
如果你還是想用 AI 開發，至少做到這幾件事：
架構先行：在寫任何程式碼前，先請 AI 幫你規劃整體架構、檔案結構、資料流，並把這份文件存下來，之後每次對話都附上。
版本控制是底線：用 Git，每個能動的版本都 commit。出事至少能回滾。
請 AI 同時寫測試：不要只要功能，要它同時寫單元測試。這樣之後改東西才知道有沒有壞別的。
資安基本盤：API key 放環境變數、不要 commit 到 git、資料庫加上 row level security、所有使用者輸入都要驗證。這些是最低門檻。
定期請 AI code review：每隔一段時間，把整個專案丟給 AI 請它找問題、找重複的程式碼、找潛在 bug。
留一條退路：在你還沒「太深」之前，找個工程師朋友看一下，至少確認方向沒有走歪。
五、 一個誠實的觀察
AI 寫程式現在的狀況，有點像是給了所有人一台挖土機，但沒給駕照課程。能做的事變多了，但闖禍的規模也變大了。
最危險的不是「不會寫程式的人用 AI」，而是「不會寫程式的人用 AI 做出了能動的東西」——因為「能動」會給人一種「我懂了」的錯覺，於是繼續往前堆，直到整個塌掉。
Vibe Coding後遺症
是否有人用AI寫網站，後來根本無法維護？
有，而且這個現象常見到已經有專有名詞了——叫做 "vibe coding" 的後遺症，或業界戲稱的 "AI 技術債"（AI Technical Debt）。
一、 真實發生的狀況
我整理一下目前看到比較典型的「翻車案例」：
案例一：堆積式開發的崩潰 創業者用 AI 一路「再加一個功能」、「再改一下這裡」，三個月後網站有 200 個檔案，沒有人（包括 AI 自己）搞得清楚哪個函式被誰呼叫。要改一個按鈕顏色，AI 改完結果結帳功能壞掉。
案例二：資安地雷 AI 為了「讓功能可以動」，把 API key 寫死在前端、資料庫密碼放在 GitHub 公開 repo、沒做任何輸入驗證。等到被駭客掃到、信用卡資料外洩，才發現代誌大條。2024 年確實有幾個用 AI 快速做出來的 SaaS 產品，因為 Supabase 設定錯誤導致全部使用者資料外洩。
案例三：沒有人看得懂的程式碼AI 為了解決某個 bug，可能會寫出非常迂迴的解法（用了 5 層巢狀條件判斷處理一件簡單的事）。原本的開發者離開後，新來的工程師看了一個禮拜還在問：「這段到底想幹嘛？」最後決定整個砍掉重做。
案例四：依賴套件地獄 AI 很愛裝套件解決問題。一個簡單的網站可能裝了 80 個 npm 套件，其中有些已經停止維護、有些有資安漏洞、有些彼此衝突。要升級任何一個都會引發連鎖反應。
二、 為什麼會這樣
幾個根本原因：
AI 是「補完式」思考，不是「架構式」思考 你叫它做什麼它做什麼，但它不會主動跟你說「你這樣做未來會出事」。它優化的是「這次對話讓你滿意」，不是「三年後這個系統還能維護」。
沒有整體脈絡 AI 每次對話的記憶有限，改了 A 檔案可能不知道 B 檔案有相關邏輯，導致前後不一致。
使用者不知道自己不知道什麼 傳統工程師會在你提需求時告訴你：「這個之後會有效能問題」、「這個資料結構錯了」。AI 不會主動阻止你做蠢事，它會非常熱心地幫你把蠢事做好。
測試？什麼測試？ 很少人用 AI 寫程式時會請它同步寫測試。結果就是改一個地方不知道哪裡會壞。
三、 真實的後果
我看過分享出來的幾種結局：
- 整個砍掉重做：花了 3 個月用 AI 寫的東西，最後請工程師花 1 個月重寫，因為改比重寫還貴。
- 被綁架：找工程師接手，對方看了報價直接 ×3，因為要先花時間搞懂這坨程式碼。
- 永遠停在那個版本：不敢動它，因為一動就壞，但又有新需求做不了。
- 資安事故：被入侵、被勒索、客戶資料外洩，賠的錢遠超過當初省的。
- 永遠停在那個版本：不敢動它，因為一動就壞，但又有新需求做不了。
四、 怎麼避免
如果你還是想用 AI 開發，至少做到這幾件事：
架構先行：在寫任何程式碼前，先請 AI 幫你規劃整體架構、檔案結構、資料流，並把這份文件存下來，之後每次對話都附上。
版本控制是底線：用 Git，每個能動的版本都 commit。出事至少能回滾。
請 AI 同時寫測試：不要只要功能，要它同時寫單元測試。這樣之後改東西才知道有沒有壞別的。
資安基本盤：API key 放環境變數、不要 commit 到 git、資料庫加上 row level security、所有使用者輸入都要驗證。這些是最低門檻。
定期請 AI code review：每隔一段時間，把整個專案丟給 AI 請它找問題、找重複的程式碼、找潛在 bug。
留一條退路：在你還沒「太深」之前，找個工程師朋友看一下，至少確認方向沒有走歪。
五、 一個誠實的觀察
AI 寫程式現在的狀況，有點像是給了所有人一台挖土機，但沒給駕照課程。能做的事變多了，但闖禍的規模也變大了。
最危險的不是「不會寫程式的人用 AI」，而是「不會寫程式的人用 AI 做出了能動的東西」——因為「能動」會給人一種「我懂了」的錯覺，於是繼續往前堆，直到整個塌掉。