"Vibe Coding"一個月後，我的項目變成了屎山——以及怎麼救

作者：AI智聞說

日期：2026年5月28日下午9:26

來源：WeChat 原文

✦整理版優先睇

速讀 5 個重點高亮

Vibe Coding一個月後項目變屎山，教你4步救返嚟

整理版摘要

作者係一個開發者，用咗純 Vibe Coding 方式開發一個 SaaS 項目一個月，最初覺得好爽，一日推到3-4個功能，但係去到第三個禮拜開始出現問題：改一個表單校驗，支付模塊報錯；加新頁面，首頁變慢。第四個禮拜佢頂唔順，發現自己完全睇唔明 AI 生成嘅代碼，因為從來冇審查過。佢指出呢個就係 Simon Willison 講嘅「認知債」——代碼行得鬱，但你完全唔知佢做緊咩。

作者總結咗 Vibe Coding 嘅根本問題：AI 冇全局視野，淨係顧當前 prompt；唔做 code review 等於放棄質量門禁；認知債會複利累積，最終失控。佢嘅結論係：Vibe Coding 產出代碼快，但產出認知係零，一個月後項目就會變成屎山。

之後佢分享咗一套4步急救法：先做全面診斷（用 Claude Code 跑審計），再幫要重構嘅模塊補測試，然後拆 God File，最後消滅 any 類型。日常仲要保持4個習慣，例如複述 AI 寫嘅 code、寫明「點解」喺 commit message、畫依賴圖、問 AI 點解揀呢個方案。最後佢定咗4條規則防止再變屎山，包括限制文件行數、每週體檢、寫清楚 CLAUDE.md 等。

Vibe Coding 一個月後必然產出「屎山」，因為認知債會指數級增長，代碼可跑但無人理解。
五個典型症狀：47個 any、God File 2000行、複製貼上式複用、零測試、依賴混亂如意粉。
四步急救：AI 審計診斷→為重構模塊補測試→按業務域拆文件→用 ESLint + AI 消滅 any。
日常四習慣：複述 AI code、commit 寫原因、畫3秒依賴圖、問 AI 點解揀呢個方案。
設定 CLAUDE.md 規範（如單文件≤300行、禁止 any、每週體檢）可預防屎山再生。

值得記低

Skill

每週代碼體檢 Skill

自動檢查 TypeScript strict 編譯、測試覆蓋率閾值（60%）、循環依賴、文件行數上限（300行），輸出報告供人手決定修唔修。

Prompt

AI 審計 Prompt

claude -p "分析呢個項目嘅代碼質量問題，按嚴重程度排序。關注：類型安全（any 使用）、文件大小、重複代碼、測試覆蓋、循環依賴、錯誤處理。輸出為 Markdown 報告。"

流程

拆 God File 嘅正確方式

唔係 Vibe Coding 式「幫我拆咗佢」，而係：先叫AI出 plan → 確認 → 睇 diff → 跑測試。

筆記

CLAUDE.md 範例規範

## 代碼規範 - 單文件不超過 300 行，超咗必須按職責拆分 - 唔準用 any，用 unknown + 類型守衞代替 - 新功能必須帶至少一個測試

整理重點

五個屎山典型症狀——中三個就係啦

作者一個月 Vibe Coding 後，發現項目出現以下五個問題。對照檢查，中三個以上就代表你嘅項目已經係屎山。

1 47 個 any：TypeScript 形同虛設，AI 為咗「行得鬱」成日 as any，等於放棄類型系統。
2 God File 2000行：AI 唔會主動拆文件，一個月後 api.ts 2100行，utils.ts 1800行，無人睇得明。
3 複製貼上式複用：4個幾乎一樣嘅表格組件，改通用行為要改4個地方，漏一個就 bug。
4 零測試：測試文件數量係0，改任何嘢都係盲改，炸咗都唔知邊度炸。
5 依賴關係亂成一團：組件直接 call API、工具函數循環依賴、狀態管理散落各處，畫出嚟係一碗意粉。

整理重點

點解純 Vibe Coding 必然產出屎山？三個根本原因

唔係 AI 寫得差，而係 Vibe Coding 呢種工作方式本身就有問題。三個原因逐個睇。

1 無架構約束：AI 走最短路徑完成當前 prompt，唔會諗新功能擺邊個模塊、有冇重複邏輯。每次對話獨立決策，無全局視角。
2 唔審查等於放棄質量門禁：Code Review 嘅意義係「俾代碼一個被質疑嘅機會」，Vibe Coding 直接跳過呢步。
3 認知債嘅複利效應：頭兩週耦合淺仲可以靠 AI 續寫，第三週 AI 都搞唔掂——因為佢無 project 全局架構理解，上下文得代碼無設計意圖。

整理重點

4步急救——由「唔敢掂」救到「可維護」

作者用咗一星期，用呢4步將項目救返嚟。方法唔複雜，但需要紀律。

第一步：診斷——叫 AI 做一次全面體檢。用 Claude Code 跑審計，問題分紅黃綠三級，先修紅色（循環依賴、未處理 Promise 拒絕），再修黃色（any、God File），綠色（命名、註釋）唔急。

用 claude -p "分析呢個項目嘅代碼質量問題，按嚴重程度排序"

第二步：加測試——為準備重構嘅模塊寫測試。唔好一次過補曬成個項目，先揾你要改嘅部分。叫AI寫 vitest 單元測試，每個函數測正常路徑同錯誤路徑。先有測試先動刀。

先有測試，再動刀。改完之後跑一遍，全綠才算安全

第三步：拆 God File——按業務域拆細。2000行嘅 api.ts 拆成 auth、payment、user、product、order 等6個文件，加一個 index.ts 統一導出。拆嘅時候唔係 Vibe Coding，而係叫AI出 plan → 你 confirm → 睇 diff → 跑測試。

區別在於你有冇審查

第四步：還類型債——消滅 any。喺 ESLint 開 @typescript-eslint/no-explicit-any（error），跑一次 eslint 精確定位47個 any，叫AI逐個修。但修完要人手睇，避免 AI 用 Record<string, unknown> 偷懶。

整理重點

日常4個習慣，保持清醒用 AI

修屎山只係事後補救，真正重要係日常點樣唔再積累認知債。以下4個習慣，每個淨係花多2-3分鐘。

1 AI 寫完後，用自己嘅話複述一次：30秒諗「段 code 做咩？數據由邊度嚟、去邊度、中間做咩處理？」講唔清楚即係有認知債。
2 commit message 寫「點解」而唔係「做咗咩」：例如「Add form validation — 之前用戶唔填郵箱都可以 submit，搞到後端報500」。三個月後睇 git log 就明曬。
3 每做完一個模塊，畫一張3秒依賴圖：喺註釋或 README 寫句嘢如「用戶操作 → LoginForm → authApi.login() → 設置 token → 跳轉首頁」，三個月後即刻明數據流。
4 對 AI 方案問一句「點解係呢個方案」：例如 AI 用 zustand，問佢點解唔用 jotai，迫自己理解 trade-off，下次唔使「AI 話乜就乜」。

整理重點

設定規則防止再變屎山

修一次只係亡羊補牢，關鍵係以後唔好再犯。作者而家用呢4條規則。

1 AI 寫完必須 review：真係讀 diff，問自己「段邏輯我明唔明？點解揀呢個方案？有冇更簡單做法？」答唔到就唔好 merge。
2 單文件唔超過300行：超咗就拆，冇例外。喺 CLAUDE.md 寫死呢條規則，AI 都會跟。
3 每週跑一次「體檢」：用 Skill 檢查 TypeScript strict、測試覆蓋率（60%）、循環依賴、文件行數，出報告俾人決定修唔修。
4 CLAUDE.md / AGENTS.md 寫清楚架構：例如 src/api/ 按業務域拆分、src/components/ 每個組件一個 folder，AI 就唔會亂放 code。

CLAUDE.md 範例 markdown

## 代碼規範
- 單文件不超過 300 行，超咗必須按職責拆分
- 唔準用 any，用 unknown + 類型守衞代替
- 新功能必須帶至少一個測試

## 項目架構
- src/api/ — 後端接口調用，按業務域拆分
- src/components/ — UI 組件，每個組件一個文件夾
- src/hooks/ — 自定義 hooks
- src/stores/ — 狀態管理（zustand）
- src/types/ — TypeScript 類型定義
- src/utils/ — 純工具函數，無業務邏輯

寫咗架構之後，AI 就唔會再將所有嘢塞入一個文件。核心判斷標準：呢個項目嘅 code 將來仲需唔需要俾人（包括自己）理解同修改？需要 → 唔可以 Vibe，必須審查；唔需要 → 隨便 Vibe。

Vibe Coding 令你一日做到過去一個禮拜嘅 code 量。但一個月後你會發現：code 行到，但你唔敢掂。改一個掣嘅顏色，三個頁面炒曬。呢篇講我點樣將一座 AI 生成嘅屎山，一步步救返嚟。

寫在前面

一個月前我做咗個實驗：用純 Vibe Coding 嘅方式做一個 SaaS 項目。

所謂 Vibe Coding——唔睇生成嘅 code、唔做 code review、唔寫測試、描述需求就畀 AI 做，行到就得。Andrej Karpathy 2025 年 2 月喺 X 上提出呢個概念時原話係 "fully give in to the vibes, embrace exponentials, and forget that the code even exists"，我就真係 fully give in 咗。

頭兩個禮拜體驗極好：一日推到 3-4 個功能，UI 出得快，API 行得通，每日 git log 睇住一大串 commit 特別有成就感。

第三個禮拜開始出問題：改一個表單校驗邏輯，支付模塊無端報錯。加一個新頁面，首頁嘅數據請求慢咗。越改越炒，越炒越唔敢改。

第四個禮拜徹底放棄掙扎：我將個項目由頭到尾睇咗一次，發現自己甚至睇唔明自己項目嘅 code——因為根本唔係「我」嘅 code，係 AI 寫嘅，我從來冇審查過。

呢個就係 Simon Willison 講嘅認知債務：code 行到，但你唔明原理。技術債係 code 質量差將來要還，認知債係你連 code 做緊乜都唔知，還唔還、點還，無從入手。

下面講 5 個典型症狀點樣識別，同埋 4 步點樣救。

一、5 個典型症狀：你個項目可能已經係屎山

對照檢查，中 3 個以上就係屎山無疑：

症狀 1：成日 any，類型系統形同虛設

AI 寫 TypeScript 嘅時候，為咗令 code「行到」，最鍾意做嘅嘢就係 as any。佢唔會主動話你知「呢度類型推斷有問題」，佢只會用 any 繞過去。

我項目入面 global 搜咗一下：47 個 any。一個 TypeScript 項目，47 個 any，等於冇類型系統。

// AI 最鍾意寫嘅 code

const data = response.data as any;

const result = processData(data as any);

(window as any).config = config;

症狀 2：God File——單個檔案 2000 行

AI 唔會主動拆檔案。你叫佢「加一個功能」，佢就喺現有檔案度追加。你再叫佢「再加一個」，佢繼續追加。一個月落嚟，我嘅 api.ts 有 2100 行，utils.ts 有 1800 行。

冇人——包括三個月後嘅你自己——可以快速理解一個 2000 行檔案嘅全部邏輯。

症狀 3：複製貼上式複用

AI 處理「呢個功能同嗰個類似」嘅方法，唔係抽象同複用，而係複製一份改幾行。

我個項目入面有 4 個幾乎一模一樣嘅表格組件，分別只係列定義唔同。每次改表格嘅通用行為（例如加排序），就要改 4 個地方。漏咗一個就係 bug。

症狀 4：零測試

一個月寫咗幾十個功能，測試檔案數量：0。

唔係 AI 唔會寫測試——你叫佢寫佢就會寫。問題係 Vibe Coding 嘅核心心態就係「唔睇 code，行到就得」。寫測試代表你要理解 code 做緊乜，而呢樣正係你想逃避嘅嘢。

結果就係：改任何嘢都係盲改，你唔知會唔會炸，炸咗都唔知邊度炸。

症狀 5：依賴關係亂成一團

AI 唔做架構設計。佢寫 code 嘅邏輯係「目前用得」，唔係「長遠好維護」。

我個項目入面，組件直接 call API 唔經 service 層、工具函數互相引用形成循環依賴、狀態管理散落喺各個組件嘅 useState 入面冇集中管理。

畫一張依賴圖，就係一碗意粉。（用 madge --image graph.png src/ 行一次就知）

二、點解純 Vibe Coding 幾乎必然產出屎山

唔係 AI 寫嘅 code 差，係 Vibe Coding 呢種工作方式決定咗結果一定差。

三個根本原因：

1. 冇架構約束，AI 行最短路徑

AI 生成 code 時追求嘅係「當前呢個 prompt 嘅任務完成」。佢唔會返轉頭諗「呢個新功能應該放喺邊個模塊」、「呢段邏輯同之前嗰個係咪同一個抽象」。每次對話都係獨立決策，冇全局視角。

2. 唔審查 = 放棄質量閘門

軟件工程入面有一個基本共識：code 質量靠嘅唔係寫嗰陣有幾叻，而係審查嗰陣有幾嚴。Code Review 存在嘅意義唔係「睇你寫得啱唔啱」，而係「畀 code 一個被質疑嘅機會」。Vibe Coding 直接跳過咗呢一步。

3. 認知債嘅複利效應

頭兩個禮拜你唔明 code 但仲可以靠 AI 繼續寫——因為新功能同舊 code 嘅耦合仲未咁深。但耦合係會累積嘅。到第三個禮拜，AI 都搞唔掂——唔係因為上下文裝唔落 code，而係因為佢缺乏對項目全局架構嘅理解。上下文入面有 code，但冇設計意圖。嗰陣只有「明呢個項目」嘅人先可以做正確決策——但「明」嗰個人從來冇出現過。

一句話總結：Vibe Coding 產出 code 嘅速度好快，但產出認知嘅速度係零。一個月後 code 跑喺前面，認知遠遠落喺後面，項目就失控喇。

三、4 步救返嚟

我用咗一個禮拜時間將項目由「唔敢掂」救到「可維護」。方法唔複雜，但需要紀律。

第 1 步：診斷——先搞清楚爛喺邊

唔好急着重構。先做一次全面體檢。

我用嘅方法：叫 Claude Code 行一次 code 審計。

claude -p "分析呢個項目嘅 code 質量問題，按嚴重程度排序。

關注：類型安全（any 使用）、檔案大小、重複 code、測試覆蓋、

循環依賴、錯誤處理。輸出為 Markdown 報告。"

5 分鐘出一份報告，將問題分咗三類：

嚴重程度	問題	數量
🔴 高	循環依賴、未處理嘅 Promise 拒絕	8 處
🟡 中	any 類型、God File、重複 code	47 處
🟢 低	命名唔規範、註釋缺失	30+ 處

先修紅色，再修黃色，綠色唔使急。

第 2 步：加測試——畀你一張安全網

重構最怕嘅唔係「改錯」，而係「改錯咗都唔知」。測試就係嗰張網。

但你冇辦法一次性成個項目補測試——咁要一個月。策略係：淨係幫你之後要重構嘅模塊寫測試。

claude -p "幫 src/api.ts 嘅所有導出函數寫單元測試。

用 vitest，每個函數至少測正常路徑同一個錯誤路徑。

唔好 mock 太多嘢，盡量測真實邏輯。"

先有測試，再鬱手。改完之後行一次，全部綠曬先叫安全。

第 3 步：拆檔案——God File 大卸八塊

2000 行嘅 api.ts，按業務域拆成 6 個檔案：

src/api/

├── auth.ts        （認證相關）

├── payment.ts     （支付相關）

├── user.ts        （用戶相關）

├── product.ts     （商品相關）

├── order.ts       （訂單相關）

└── index.ts （統一導出）

呢一步我都用 Claude Code 做，但唔係 Vibe Coding 嘅方式。分別在於：

Vibe Coding：「幫我拆咗 api.ts」→ 唔睇結果

正確方式：「幫我將 api.ts 按業務域拆分，先話我知你打算點拆，我確認咗先鬱手」→ 睇 plan → 確認 → 睇 diff → 行測試

同樣係畀 AI 做嘢，分別在於你有冇審查。

第 4 步：還類型債——消滅 any

47 個 any，一個一個消滅太慢。我嘅策略：

喺 ESLint 配置啓用 @typescript-eslint/no-explicit-any 規則，設為 error

跑一遍 eslint src/ --ext .ts,.tsx，直接報 47 個錯誤，每一個都精確定位到行

叫 Claude Code 逐個修復：

claude -p "修復所有 @typescript-eslint/no-explicit-any 報錯。

對每個 any，根據實際使用場景推斷正確類型。

如果確實無法推斷，用 unknown + 類型守衞代替 any。"

呢一步 AI 真係好擅長——推斷類型係佢嘅強項。但修完之後你一定要人手過一次：有啲 AI 會偷懶用 Record<string, unknown> 糊弄，實際上應該定義具體嘅 interface。

四、日常點樣一邊用 AI 一邊保持清醒

修屎山係事後補救。真正重要嘅係：點樣喺享受 AI 效率嘅同時，唔累積認知債？

4 個日常習慣，每個只係多花 2-3 分鐘：

習慣 1：AI 寫完之後，用自己嘅話複述一次

AI 提交咗一段 code，唔好急住 approve。花 30 秒喺腦入面過一次：「呢段 code 做咗啲乜？數據由邊度嚟、去邊度、中間經過咗啲咩處理？」

講唔清楚 → 就係認知債喺度累積。嗰陣問 AI：「用一句話解釋呢段 code 嘅核心邏輯」，然後判斷佢嘅解釋同你嘅理解係咪一致。

檢驗標準：如果聽日呢段 code 報錯，你能唔能夠喺 30 秒內定位到呢個檔案？

習慣 2：commit message 寫「點解」，唔止係「做咗啲乜」

AI 生成嘅 commit message 通常係：「Add form validation to login page」。

你要補上嘅係：「Add form validation — 之前用戶唔填郵箱都可以提交，搞到後端報 500」。

「做咗啲乜」三個月後你睇 git log 都係睇唔明上文下理。「點解」先係你未來理解呢個項目嘅線索。

習慣 3：每做完一個模塊，畫一張 3 秒依賴圖

唔需要正式嘅架構圖。喺註釋或者項目 README 入面畫一個簡單嘅：

用戶操作 → LoginForm → authApi.login() → 設置 token → 跳轉首頁

一行文字，但三個月後你返嚟睇，即刻知道登入模塊嘅數據流係點行。冇呢行，你要由頭讀 code 先搞得清。

習慣 4：對 AI 方案問一句「點解係呢個方案」

AI 畀你用 zustand 做狀態管理？問佢：「點解揀 zustand 唔揀 jotai？呢個場景下兩者有咩分別？」

唔係為咗質疑佢嘅選擇，而係為咗令你理解決策背後嘅 trade-off。下次遇到類似場景，你就可以自己判斷——而唔係又一次「AI 話乜就係乜」。

四個習慣嘅共同目標：令你嘅認知追得上 code 嘅增長速度。code 可以畀 AI 寫，但理解一定要係你自己嘅。

五、修完之後：防止再變屎山

修一次係亡羊補牢，關鍵係以後唔好再犯。

我而家嘅規則：

規則 1：AI 寫完一定要 review

唔係形式主義咁睇一眼。係真係讀 diff，問自己：

呢段邏輯我明唔明？

佢點解揀呢個方案而唔係嗰個？

有冇更簡單嘅做法？

如果你答唔到呢三個問題，呢段 code 就唔應該 merge。

規則 2：單一檔案唔超過 300 行

超咗就拆。冇例外。喺 CLAUDE.md 入面寫死呢條規則，AI 都會遵守。

## 代碼規範

- 單一檔案唔超過 300 行，超咗必須按職責拆分

- 唔準用 any，用 unknown + 類型守衞代替

- 新功能一定要帶至少一個測試

規則 3：每個禮拜行一次「體檢」

我寫咗個 Skill，每個星期五自動行一次 code 質量檢查：

TypeScript strict 編譯係咪通過

測試覆蓋率係咪低過門檻（我 set 咗 60%）

係咪有新嘅循環依賴

係咪有檔案超過 300 行

出報告，唔會自動修。人睇咗先決定修唔修。

規則 4：CLAUDE.md / AGENTS.md 寫清楚架構

畀 AI 知道「呢個項目嘅模塊劃分係點」。唔寫嘅話，AI 每次都要估應該將 code 放邊度。

## 項目架構

- src/api/ — 後端接口調用，按業務域拆分

- src/components/ — UI 組件，每個組件一個資料夾

- src/hooks/ — 自定義 hooks

- src/stores/ — 狀態管理（zustand）

- src/types/ — TypeScript 類型定義

- src/utils/ — 純工具函數，冇業務邏輯

寫咗呢段之後，AI 就唔會再將所有嘢塞入一個檔案。

六、Vibe Coding 唔係唔用得，係有邊界

寫到呢度唔係話 Vibe Coding 一無是處。佢有佢嘅位置：

場景	能唔能夠 Vibe	原因
一次性腳本	✅ 可以	用完就掉，唔需要維護
快速驗證想法（3 日內掉咗）	✅ 可以	重點係驗證，唔係 code 質量
個人工具/玩具項目	⚠️ 睇情況	如果以後仲要改，唔得
要長期維護嘅項目	❌ 絕對唔得	認知債會指數級增長
團隊協作項目	❌ 絕對唔得	其他人更加睇唔明你嘅 AI code

核心判斷標準：呢個項目嘅 code，以後仲需唔需要畀人（包括你自己）理解同修改？

需要 → 唔可以 Vibe，一定要審查。唔需要 → 隨便 Vibe。

寫在最後

Vibe Coding 嘅誘惑在於：佢令你覺得自己喺度「高效產出」。但高效產出嘅係 code，唔係價值。code 只有喺可理解、可修改、可信賴嘅前提下先係資產——否則就係負債。

我用咗一個月 Vibe 出一座屎山，又用咗一個禮拜救返嚟。如果一開始就花 10% 嘅時間審查 AI 嘅產出，呢個禮拜完全可以慳返。

用 AI 寫 code 冇問題。但 Vibe 嘅係心態，唔係流程。流程上一定要清醒。

Vibe Coding 讓你一天能寫出過去一週的代碼量。但一個月後你會發現：代碼能跑，你不敢碰。改一個按鈕顏色，三個頁面崩了。這篇講我怎麼把一座 AI 生成的屎山，一步步救回來。

寫在前面

一個月前我做了個實驗：用純 Vibe Coding 的方式做一個 SaaS 項目。

所謂 Vibe Coding——不看生成的代碼、不做 code review、不寫測試、描述需求就讓 AI 幹，能跑就行。Andrej Karpathy 2025 年 2 月在 X 上提出這個概念時原話是"fully give in to the vibes, embrace exponentials, and forget that the code even exists"，我就真的 fully give in 了。

前兩週體驗極好：一天能推進 3-4 個功能，UI 出得快，API 跑得通，每天 git log 看着一大串 commit 特有成就感。

第三週開始出問題：改一個表單校驗邏輯，支付模塊莫名報錯。加一個新頁面，首頁的數據請求變慢了。越改越崩，越崩越不敢改。

第四周徹底放棄掙扎：我把項目從頭到尾讀了一遍，發現自己甚至看不懂自己項目的代碼——因為根本不是"我的"代碼，是 AI 寫的，我從來沒審查過。

這就是 Simon Willison 說的認知債務：代碼能跑，但你不懂原理。技術債是代碼質量差將來要還，認知債是你連代碼在幹什麼都不知道，還不還、怎麼還，無從下手。

下面講 5 個典型症狀怎麼識別，以及 4 步怎麼救。

一、5 個典型症狀：你的項目可能已經是屎山了

對照檢查，中 3 個以上就是屎山無疑：

症狀 1：全是 any，類型系統形同虛設

AI 寫 TypeScript 的時候，為了讓代碼"能跑"，最喜歡做的事就是 as any。它不會主動告訴你"這裏類型推斷有問題"，它只會用 any 繞過去。

我項目裏全局搜了一下：47 個 any。一個 TypeScript 項目，47 個 any，等於沒有類型系統。

// AI 最愛寫的代碼

const data = response.data as any;

const result = processData(data as any);

(window as any).config = config;

症狀 2：God File——單個文件 2000 行

AI 不會主動拆文件。你讓它"加一個功能"，它就往現有文件裏追加。你再讓它"再加一個"，它繼續追加。一個月下來，我的 api.ts 有 2100 行，utils.ts 有 1800 行。

沒有人——包括三個月後的你自己——能快速理解一個 2000 行文件的全部邏輯。

症狀 3：複製粘貼式複用

AI 處理"這個功能和那個類似"的方式，不是抽象和複用，而是複製一份改幾行。

我的項目裏有 4 個幾乎一模一樣的表格組件，區別只是列定義不同。每次改表格的通用行為（比如加排序），要改 4 個地方。漏了一個就是 bug。

症狀 4：零測試

一個月寫了幾十個功能，測試文件數量：0。

不是 AI 不會寫測試——你讓它寫它就寫。問題是 Vibe Coding 的核心心態就是"不看代碼，能跑就行"。寫測試意味着你要理解代碼在幹什麼，而這正是你在逃避的事。

結果就是：改任何東西都是盲改，你不知道會不會炸，炸了也不知道哪裏炸的。

症狀 5：依賴關係亂成一團

AI 不做架構設計。它寫代碼的邏輯是"當前能用"，不是"長遠好維護"。

我的項目裏，組件直接調 API 不走 service 層、工具函數互相引用形成循環依賴、狀態管理散落在各個組件的 useState 裏沒有集中管理。

畫一張依賴圖，就是一碗意麪。（用 madge --image graph.png src/ 跑一下就知道了）

二、為什麼純 Vibe Coding 幾乎必然產出屎山

不是 AI 寫的代碼差，是 Vibe Coding 這種工作方式決定了結果一定差。

三個根本原因：

1. 沒有架構約束，AI 走最短路徑

AI 生成代碼時追求的是"當前這個 prompt 的任務完成"。它不會回頭想"這個新功能應該放在哪個模塊"、"這段邏輯和之前那個是不是同一個抽象"。每次對話都是獨立決策，沒有全局視角。

2. 不審查 = 放棄質量門禁

軟件工程裏有一個基本共識：代碼質量靠的不是寫的時候有多厲害，而是審查的時候有多嚴格。Code Review 存在的意義不是"看你寫得對不對"，而是"給代碼一個被質疑的機會"。Vibe Coding 直接跳過了這一步。

3. 認知債的複利效應

前兩週你不懂代碼但還能靠 AI 接着寫——因為新功能和舊代碼的耦合還不深。但耦合是會累積的。到第三週，AI 也搞不定了——不是因為上下文裝不下代碼，而是因為它缺乏對項目全局架構的理解。上下文裏有代碼，但沒有設計意圖。這時候只有"懂這個項目"的人才能做出正確決策——但"懂"的那個人從來沒出現過。

一句話總結：Vibe Coding 產出代碼的速度很快，但產出認知的速度為零。一個月後代碼跑在前面，認知遠遠落在後面，項目就失控了。

三、4 步救回來

我花了一週時間把項目從"不敢碰"救到"可維護"。方法不復雜，但需要紀律。

第 1 步：診斷——先搞清楚爛在哪

別急着重構。先做一次全面體檢。

我用的方法：讓 Claude Code 跑一遍代碼審計。

claude -p "分析這個項目的代碼質量問題，按嚴重程度排序。

關注：類型安全（any 使用）、文件大小、重複代碼、測試覆蓋、

循環依賴、錯誤處理。輸出為 Markdown 報告。"

5 分鐘出來一份報告，把問題分成了三類：

嚴重程度	問題	數量
🔴 高	循環依賴、未處理的 Promise 拒絕	8 處
🟡 中	any 類型、God File、重複代碼	47 處
🟢 低	命名不規範、註釋缺失	30+ 處

先修紅色，再修黃色，綠色不着急。

第 2 步：加測試——給你一張安全網

重構最怕的不是"改錯了"，而是"改錯了不知道"。測試就是那張網。

但你沒法一次性給整個項目補測試——那要一個月。策略是：只給你接下來要重構的模塊寫測試。

claude -p "給 src/api.ts 裏的所有導出函數寫單元測試。

用 vitest，每個函數至少測正常路徑和一個錯誤路徑。

不要 mock 太多東西，儘量測真實邏輯。"

先有測試，再動刀。改完之後跑一遍，全綠才算安全。

第 3 步：拆文件——God File 大卸八塊

2000 行的 api.ts，按業務域拆成 6 個文件：

src/api/

├── auth.ts        (認證相關)

├── payment.ts     (支付相關)

├── user.ts        (用戶相關)

├── product.ts     (商品相關)

├── order.ts       (訂單相關)

└── index.ts (統一導出)

這一步我也用 Claude Code 做，但不是 Vibe Coding 的方式。區別在於：

Vibe Coding："幫我把 api.ts 拆了" → 不看結果

正確方式："幫我把 api.ts 按業務域拆分，先告訴我你打算怎麼拆，我確認後再動手" → 看 plan → 確認 → 看 diff → 跑測試

同樣是讓 AI 幹活，區別在於你有沒有審查。

第 4 步：還類型債——消滅 any

47 個 any，一個個消滅太慢。我的策略：

在 ESLint 配置裏啓用 @typescript-eslint/no-explicit-any 規則，設為 error

跑一遍 eslint src/ --ext .ts,.tsx，直接報 47 個錯誤，每一個都精確定位到行

讓 Claude Code 逐個修復：

claude -p "修復所有 @typescript-eslint/no-explicit-any 報錯。

對每個 any，根據實際使用場景推斷正確類型。

如果確實無法推斷，用 unknown + 類型守衞代替 any。"

這一步 AI 真的很擅長——推斷類型是它的強項。但修完之後你必須人工過一遍：有些 AI 會偷懶用 Record<string, unknown> 糊弄，實際上應該定義具體的接口。

四、日常怎麼一邊用 AI 一邊保持清醒

修屎山是事後補救。真正重要的是：怎麼在享受 AI 效率的同時，不積累認知債？

4 個日常習慣，每個只多花 2-3 分鐘：

習慣 1：AI 寫完後，用自己的話複述一遍

AI 提交了一段代碼，別急着 approve。花 30 秒在腦子裏過一遍："這段代碼做了什麼？數據從哪來、到哪去、中間經過了什麼處理？"

說不清楚 → 就是認知債在積累。這時候問 AI："用一句話解釋這段代碼的核心邏輯"，然後判斷它的解釋和你的理解是否一致。

檢驗標準：如果明天這段代碼報錯，你能不能在 30 秒內定位到這個文件？

習慣 2：commit message 寫"為什麼"，不只是"做了什麼"

AI 生成的 commit message 通常是："Add form validation to login page"。

你要補上的是："Add form validation — 之前用戶不填郵箱也能提交，導致後端報 500"。

"做了什麼"三個月後你看 git log 還是看不懂上下文。"為什麼"才是你未來理解這個項目的線索。

習慣 3：每做完一個模塊，畫一張 3 秒依賴圖

不需要正式的架構圖。在註釋裏或者項目 README 裏畫一個簡單的：

用戶操作 → LoginForm → authApi.login() → 設置 token → 跳轉首頁

一行文字，但三個月後你回來看，立刻知道登錄模塊的數據流是怎麼走的。沒有這行，你得從頭讀代碼才能搞清楚。

習慣 4：對 AI 方案問一句"為什麼是這個方案"

AI 給你用了 zustand 做狀態管理？問它："為什麼選 zustand 不選 jotai？這個場景下兩者有什麼區別？"

不是為了質疑它的選擇，而是為了讓你理解決策背後的 trade-off。下次遇到類似場景，你就能自己判斷——而不是又一次"AI 說啥就是啥"。

四個習慣的共同目標：讓你的認知跟上代碼的增長速度。代碼可以讓 AI 寫，但理解必須是你自己的。

五、修完之後：防止再變屎山

修一次是亡羊補牢，關鍵是以後別再犯。

我現在的規則：

規則 1：AI 寫完必須 review

不是形式主義地掃一眼。是真的讀 diff，問自己：

這段邏輯我理解嗎？

它為什麼選了這個方案而不是那個？

有沒有更簡單的做法？

如果你回答不了這三個問題，這段代碼就不該合。

規則 2：單文件不超過 300 行

超了就拆。沒有例外。在 CLAUDE.md 裏寫死這條規則，AI 也會遵守。

## 代碼規範

- 單文件不超過 300 行，超了必須按職責拆分

- 不允許使用 any，用 unknown + 類型守衞代替

- 新功能必須帶至少一個測試

規則 3：每週跑一次"體檢"

我寫了個 Skill，每週五自動跑一遍代碼質量檢查：

TypeScript strict 編譯是否通過

測試覆蓋率是否低於閾值（我設的 60%）

是否有新增的循環依賴

是否有文件超過 300 行

出報告，不自動修。人看了再決定修不修。

規則 4：CLAUDE.md / AGENTS.md 寫清楚架構

讓 AI 知道"這個項目的模塊劃分是什麼"。不寫的話，AI 每次都在瞎猜該把代碼放哪。

## 項目架構

- src/api/ — 後端接口調用，按業務域拆分

- src/components/ — UI 組件，每個組件一個文件夾

- src/hooks/ — 自定義 hooks

- src/stores/ — 狀態管理（zustand）

- src/types/ — TypeScript 類型定義

- src/utils/ — 純工具函數，無業務邏輯

寫了這段之後，AI 就不會再把所有東西塞進一個文件了。

六、Vibe Coding 不是不能用，是有邊界

寫到這裏不是說 Vibe Coding 一無是處。它有它的位置：

場景	能不能 Vibe	原因
一次性腳本	✅ 可以	跑完就扔，不需要維護
快速驗證想法（3天內扔掉）	✅ 可以	重點是驗證，不是代碼質量
個人工具/玩具項目	⚠️ 看情況	如果以後還要改，不行
要長期維護的項目	❌ 絕對不行	認知債會指數級增長
團隊協作項目	❌ 絕對不行	別人更看不懂你的 AI 代碼

核心判斷標準：這個項目的代碼，以後還需要被人（包括你自己）理解和修改嗎？

需要 → 不能 Vibe，必須審查。不需要 → 隨便 Vibe。

寫在最後

Vibe Coding 的誘惑在於：它讓你覺得自己在"高效產出"。但高效產出的是代碼，不是價值。代碼只有在可理解、可修改、可信賴的前提下才是資產——否則就是負債。

我花了一個月 Vibe 出一座屎山，又花了一週把它救回來。如果一開始就花 10% 的時間審查 AI 的產出，這一週完全可以省掉。

用 AI 寫代碼沒問題。但 Vibe 的是心態，不是流程。流程上必須清醒。