Vibe Code 救援完整 SOP
把 AI 寫的爛 code 變成可維護產品
90% 的 vibe code 都救得回來,前提是你照這個 SOP 做。重寫要 8 週的工程量,照做能在 3 週內穩定。本文含真實 NT$45,000 案例剖析、7 步驟 Vibe Code 救援 SOP、實際 code before/after 範例,以及「什麼時候該重寫不該救」的判斷標準。
為什麼你需要 Vibe Code 救援
如果你符合任何一條,這篇就是寫給你的:
- 你用 Claude Code / Cursor / Copilot 寫完了 MVP,但心裡知道半年後會爆
- 你接手了某個前同事用 AI 寫的服務,打開 repo 第一句話是「靠這什麼東西」
- 你是 startup CTO,團隊用 AI 衝產品速度衝太快,技術債堆成山
- 你是 PM,工程師說「AI 寫的不能維護」,你不知道是真話還是藉口
這篇會給你的不是哲學,是可立刻操作的 Vibe Code 救援 SOP。
什麼是 Vibe Coding?為什麼會變成需要救援的災難
Vibe Coding 是 2025 年 Andrej Karpathy 提出的詞,指:
「完全憑感覺寫 code,不看細節、不讀 AI 生的內容、不確認邏輯,只看『跑得起來嗎』就 ship。」
問題不在於用 AI,而在於這 3 件事:
01 沒人讀 AI 生的內容
我看過最誇張的案例:某 startup 工程師用 Cursor 寫了 800 行 controller,從頭到尾沒讀過一次。3 個月後 production bug 爆掉,他打開檔案說「我什麼時候寫了這段?」答案是:從來沒寫過。AI 寫的。但他貼了。
02 沒有「為什麼」的紀錄
AI 寫 code 不會說明設計決策。你今天用 useReducer 不用 useState,3 個月後完全沒紀錄為什麼。新接手的人重寫成 useState,某個邊界條件爆掉,你才想起來「啊對,因為要處理 async race condition」。但已經太晚。
03 沒測試的安全網
Vibe code 最大問題不是寫得爛,是沒測試保護。改一個地方不知道會破壞什麼。維護成本 5 個月後爆漲。
你的 Vibe Code 救得回嗎?3 個診斷
不是所有 vibe code 都該救。我自己接 Vibe Code 救援案前會做這 3 個診斷:
01 看最近 30 個 git commit
git log --oneline -30看 commit message 的品質:
| commit message 樣態 | 救援機率 | 含意 |
|---|---|---|
feat(auth): add OTP login 規格清楚 | 90% | 寫的人有紀律,只是用 AI 加速 |
fix、update、修一下 | 60% | 混亂但還有救 |
final、final2、final_real | 30% | 已經放棄、需要全面重寫 |
| 全部都是「Initial commit」 | 10% | 連 git 都沒用,重寫吧 |
02 問三個問題
- 這個專案開發了多久? < 2 個月:救援可行 / 2-6 個月:要花更多力氣 / > 6 個月:通常重寫更便宜
- 現在還有人在改嗎? 有:先冷凍 1 週再救援 / 沒:直接進救援流程
- 上線了嗎? 有+有用戶:謹慎救援不能停機 / 有+沒用戶:可大膽 refactor / 沒:直接重構
03 跑一次完整 build
rm -rf node_modules
npm install
npm run build
npm run test # 如果有測試的話如果這 4 行指令都跑得過,恭喜,救援成功率 80%+。如果任何一行卡住,先處理「能跑」這件事。
完整 7 步驟 Vibe Code 救援 SOP
這是我用 5 年累積的方法論,救過超過 3 個專案(公開可講的):
SOP 01 建立安全網(不要動 code,先存證據)
# 1. 建立救援分支
git checkout -b rescue/initial-state
# 2. 把整個 repo 打 tag 凍結
git tag rescue-baseline-$(date +%Y%m%d)
# 3. 跑一次完整 build + screenshot 所有畫面
# 4. 備份環境變數
cp .env .env.backup
# 5. 用 Postman / cURL 跑所有 API、存回應為 JSONSOP 02 讀懂 AI 寫了什麼(最痛但最重要)
從 main.ts / index.js / App.tsx 開始追,逐行讀。讀的時候做 3 件事:不懂的加 // TODO、重複的 logic 加 // DUPLICATED、可疑邊界條件加 // BOUNDARY。3 天讀完整個 repo,這一步省下你 50% 的後續時間。
SOP 03 補上邊界條件的測試
不用 100% 覆蓋率,只測「會壞的地方」 ── 把 SOP 02 標 BOUNDARY 的地方全部包進測試。目標是把那些「AI 沒想到的情境」全部測起來。3-5 天工作量。
SOP 04 抽出 magic number、magic string
// BEFORE (vibe code)
if (order.total > 1000) { shippingFee = 0; }
// AFTER (refactored)
const FREE_SHIPPING_THRESHOLD = 1000;
if (order.total > FREE_SHIPPING_THRESHOLD) { shippingFee = 0; }好處:未來改規則只改 1 個地方、別人讀 code 看得懂、測試可以塞 mock 值。
SOP 05 拆分過大的函數(>50 行就拆)
AI 最愛寫 200 行的函數。把一個 80 行的 checkoutOrder 拆成 getOrderOrThrow、calculateFees、sendConfirmationEmail、updateInventory 等獨立可測的小函數。拆完每個都獨立可測,Bug 修復速度 ×3。
SOP 06 寫 README + ADR
README 給 6 個月後接手的人:快速啟動、主要功能、技術棧。ADR(Architecture Decision Record)紀錄「為什麼這樣決定」── 情境、決策、原因、代價、考慮過的替代方案。每個重大決策寫 1 份,3 個月後別人問為什麼,你不用再回憶。
SOP 07 設定 CI/CD + 監控
# .github/workflows/ci.yml
name: CI
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: '20' }
- run: npm ci
- run: npm run lint
- run: npm run test
- run: npm run build監控用 Sentry / LogRocket / DataDog 任選,Error rate > 1% 就警報。有了 CI + 監控 = 救援後不會悄悄爛掉。
真實案例:NT$45,000 Vibe Code 救援實錄
某電商 startup「A 公司」(化名)2025 年底用 AI 衝產品,2 人團隊用 Cursor + Claude 一週做完 MVP、3 個月上線。第 4 個月:後端工程師離職、Production bug 每週 2-3 次、新功能加 1 個破 2 個。剩下的工程師找我:「救得回嗎?」
診斷:git log 全是 fix、update、final ── 沒有規格化 commit,但至少還有 git history。結論:60% 救援機率,要花 3 週。
報價:3 週(90 小時),NT$45,000 訂金 + NT$45,000 尾款。交付:50% 邊界條件測試、README + 8 份 ADR、CI/CD、監控、30 天免費售後。老闆覺得便宜(vs 重寫估 8 週、~NT$30 萬),當天打訂金。
3 週後的成果:
| 指標 | 救援前 | 救援後 |
|---|---|---|
| Bug 頻率 | 每週 2-3 次 | 每月 1-2 次(-80%) |
| 新功能交付 | 2 週/個 | 3 天/個(+5x) |
| 工程師 onboarding | 3 個月 | 1 週 |
| 團隊士氣 | 焦慮 | 終於可以好好做事 |
老闆 30 天後說:「早知道一上線就請你做這套,省的我們瞎搞 6 個月。」
Vibe Code 救援最容易踩的 5 個坑
- 坑 1:想「順便重寫」。救援 ≠ 重寫。每次順便重寫 = 多 5 個 bug、多 3 天、客戶覺得你拖時間。改最少、讓它穩定。
- 坑 2:沒先談「不救」的範圍。報價單要寫「本次只包含 X/Y/Z 模組,其他另計」,否則客戶會「順便這個也救一下吧」。
- 坑 3:偷偷加自己的偏好。用「跟客戶 codebase 一致的風格」,即使覺得 AI 寫的爛,也要寫成跟它一樣但有測試保護。
- 坑 4:沒包含「教育時間」。沒教客戶,專案 6 個月後又回到 vibe code。報價包含 2-3 場 1-on-1 教學。
- 坑 5:沒留售後保固。包含 30 天免費售後(每週 1 次 1-on-1),客戶安心、你也省事。
什麼時候該重寫,不該救援?
老實說,不是所有 vibe code 都該救。下面 5 種情況我會建議直接重寫:
- 沒有 git history(只有 final.zip)
- 連能跑都做不到(環境裝不起來、build 失敗)
- 核心架構選錯(選了完全不適用的 framework)
- 嚴重 security issue(hardcoded API key 灑滿全 repo)
- 業務邏輯本身有錯(救完還是錯的)
救援完成後的長期維護建議
- 每週寫 1 個新測試(累積 1 年就 50+ 個)
- 每月寫 1 個 ADR(紀錄重大決策)
- 每季度 refactor 1 個老檔案(防止重新爛掉)
- AI 寫的 code 一律 review 才能 merge(最重要!)
- 新人 onboarding 用救援後的 README + ADR(30 天上手)
Vibe Code 救援 常見問題 FAQ
Vibe Code 救援是什麼?
把用 AI 憑感覺快速生成、但缺乏測試、文件與架構的程式碼,透過系統化工程流程轉變為穩定、可維護、可交接的軟體。核心是不重寫、用最小改動讓它穩定。
Vibe Code 救得回來嗎?
約 90% 救得回來。看最近 30 個 git commit 品質、開發時間、能否完整 build 來判斷。沒 git history、build 失敗、架構選錯、嚴重資安漏洞則建議重寫。
Vibe Code 救援要花多久、多少錢?
中等混亂專案約 3 週(90 小時)可救援穩定。Mentry 提供 30 分鐘救援諮詢 NT$1,500,完整救援專案 NT$30,000 起,含 7 步驟 SOP 與 30 天免費售後。
什麼時候該重寫,不該救援?
沒 git history、連跑都跑不起來、核心架構選錯、有嚴重資安問題、或業務邏輯本身有錯時建議重寫。原則:救援時間若超過重寫時間的 50%,就該重寫。
你的 Vibe Code 救得回來嗎?
如果你的專案用 AI 寫到一半、上線後開始爆,先別急著重寫。30 分鐘救援諮詢 NT$1,500,我先幫你判斷救不救得了、該救還是該重寫。完整救援專案 NT$30,000 起,含 7 步驟 SOP + 30 天免費售後。