Vibe Coding 的隱形地雷：為什麼你的專案越改越亂？談架構約定與 Git 的重要性

管
管管
4 分鐘閱讀 ·
AI 應用
Git 版本控制

用 AI 寫程式很爽，一個指令就能生出一堆功能。但 vibe 了幾個禮拜後，你發現：

  • 檔案越來越多，找不到東西在哪
  • 改了 A 功能，B 功能莫名其妙壞掉
  • 想回到「昨天還能跑」的版本，但已經回不去了
  • AI 也搞不清楚專案結構，越幫越亂

這不是 AI 的問題，是你沒有跟 AI「約定好規則」。

🏗️ 問題一：檔案結構亂七八糟

常見慘況

my-project/
├── app.js
├── app2.js
├── app-backup.js
├── test.js
├── utils.js
├── helpers.js
├── stuff.js
├── main.js
├── index.js
└── 到底哪個才是入口？？？

解法：一開始就約定結構

在專案開始時，請 AI 幫你建立標準結構：

請幫我建立一個 Vue 3 專案，使用以下結構：

src/
├── components/    # 可重用元件
├── views/         # 頁面
├── composables/   # 組合式函數
├── utils/         # 工具函數
├── assets/        # 靜態資源
├── stores/        # 狀態管理
└── App.vue

之後新增任何檔案，都要遵守這個結構。

然後在每次請 AI 加功能時提醒它：

請遵守現有的檔案結構，把新元件放到 components/ 資料夾

🔗 問題二：改 A 壞 B

為什麼會這樣？

因為程式碼之間的「耦合」太緊。你以為改的是獨立功能，其實牽一髮動全身。

常見原因：

  • 全域變數到處用
  • 一個函數做太多事
  • 複製貼上的重複程式碼
  • 沒有清楚的模組邊界

解法：請 AI 遵守模組化原則

請幫我重構這段程式碼，遵守以下原則：

1. 單一職責：一個函數只做一件事
2. 不要用全域變數，用參數傳遞
3. 相關功能放在同一個模組
4. 模組之間透過明確的介面溝通
5. 如果某段邏輯用超過兩次，抽成共用函數放到 utils/

加功能前先問影響範圍

我想加一個「自動儲存」功能。
在動手之前，請先告訴我：
1. 需要修改哪些檔案？
2. 可能影響哪些現有功能？
3. 有沒有更安全的實作方式？

⏪ 問題三：回不去了

最痛的情況

「昨天明明還能跑，今天改了一些東西就壞了，但我忘記改了什麼...」

沒有版本控制，就像沒有存檔點的遊戲。死了就要從頭來。

解法：用 Git，現在就開始

Git 不難，你只需要會這幾個指令：

# 1. 初始化（只做一次）
git init

# 2. 每次改完一個功能，存檔
git add .
git commit -m "完成登入功能"

# 3. 搞砸了，回到上一個版本
git checkout .

# 4. 回到更早的版本
git log --oneline          # 看歷史
git checkout abc1234       # 回到特定版本

養成習慣：小步快跑

不要等做完整個功能才 commit，而是：

  • ✅ 加了一個按鈕 → commit
  • ✅ 按鈕可以點了 → commit
  • ✅ 點了會送 API → commit
  • ✅ API 回傳正確顯示 → commit

這樣壞掉時，你最多只會損失 10 分鐘的進度，而不是一整天。

請 AI 幫你寫 commit 訊息

我剛剛加了用戶登入功能，包括：
- 登入表單元件
- API 呼叫
- 錯誤處理
- 登入後跳轉

請幫我寫一個清楚的 git commit 訊息

📋 建立專案的 RULES.md

最有效的方法：在專案根目錄建一個 RULES.md，把所有約定寫下來。

每次跟 AI 對話時，請它先讀這個檔案：

請先讀取 RULES.md，然後按照裡面的規範幫我加功能

RULES.md 範本

# 專案開發規範

## 檔案結構
- 元件放 src/components/
- 頁面放 src/views/
- 工具函數放 src/utils/
- 新檔案命名用 kebab-case（例：user-profile.vue）

## 程式碼風格
- 使用 TypeScript
- 函數名稱用 camelCase
- 常數用 UPPER_SNAKE_CASE
- 每個函數都要有註解說明用途

## Git 規範
- commit 訊息用中文
- 格式：[類型] 描述（例：[feat] 新增登入功能）
- 類型：feat/fix/refactor/docs/style

## 禁止事項
- 不要用 var，用 const 或 let
- 不要用全域變數
- 不要在元件裡直接呼叫 API，要透過 composables

🔄 定期請 AI 做程式碼審查

每隔幾天，請 AI 幫你檢查專案：

請檢查這個專案的程式碼品質：

1. 有沒有重複的程式碼可以抽成共用？
2. 有沒有過長的函數需要拆分？
3. 檔案結構是否合理？
4. 有沒有潛在的 bug 或效能問題？
5. 命名是否清楚一致？

請列出問題並建議如何改善

💡 核心觀念

Vibe Coding 的自由度很高，但自由需要紀律來保護。

  1. 先約定，再動工 — 結構、命名、風格都要先講好
  2. 小步快跑 — 頻繁 commit，每個存檔點都是保險
  3. 模組化思維 — 改 A 不應該影響 B
  4. 讓 AI 知道規則 — RULES.md 是你跟 AI 的共同語言

結語

專案變亂不是一天造成的，是每一次「先這樣，之後再整理」累積出來的。

但整理也不用一次到位，從現在開始：

  1. 建一個 RULES.md
  2. 執行 git init
  3. 每次改完就 commit

三個動作，讓你的 Vibe Coding 之路走得更遠。

記住：程式碼是給未來的自己看的。對未來的自己好一點。