第三章：義大利麵條程式碼大掃除：讓 AI 幫你重構與拆分 React 元件
在 Vibe Coding 的過程中，我們常常為了求快，不斷請 AI 把新功能塞進同一個檔案裡。漸漸地，你的 page.tsx 可能會膨脹到 800 行甚至 1500 行以上。這時候，AI 開始變得越來越笨，甚至改了 A 壞了 B。
這種亂七八糟、互相牽連的程式碼，我們稱為「義大利麵條程式碼 (Spaghetti Code)」。本章將教你如何指揮 AI，安全地幫你進行「程式碼重構 (Refactoring)」與「元件拆分」。
為什麼檔案太大會讓 AI 變笨？
- Context Window 浪費：每次對話，AI 都需要閱讀整個檔案。1500 行的檔案會消耗大量 Token，導致 AI「忘記」你最初的需求。
- 修改風險極高：一個檔案裡塞滿了 Header, Sidebar, Main Content, Footer。請 AI 改 Footer 的時候，它可能不小心動到了 Header 的狀態 (State)。
- 人類看不懂：Vibe Coding 不代表人類不用看 Code。當檔案大到你無法掌握時，你就失去了對專案的控制權。
重構的黃金法則：單一職責原則 (SRP)
在請 AI 拆分元件前，你必須先在腦海中建立「單一職責」的概念。 一個 React 元件應該只負責「一件事情」。
例如，一個 PricingPage 不應該同時負責：
- 取得資料庫的價格方案
- 渲染方案卡片的 UI
- 處理結帳按鈕的 Stripe API 邏輯
- 渲染常見問題 (FAQ) 手風琴
它應該被拆分成：
PricingPage(只負責組合)PricingCard(只負責渲染卡片 UI)CheckoutButton(只負責金流邏輯)FaqSection(只負責 FAQ 邏輯)
實戰：如何詠唱「拆分元件」的 Prompt
請不要直接對 AI 說：「幫我把這個檔案拆小一點」。這太模糊了，AI 可能會拆出讓你匪夷所思的結構。
請使用以下這個重構專用 Prompt 模板：
[任務目標] 目前的
src/app/pricing/page.tsx檔案太長了，我希望進行重構與元件拆分，以提升可維護性。[拆分規劃] 請幫我將程式碼拆分成以下三個檔案：
src/components/pricing/PricingCard.tsx：負責渲染單一方案卡片的 UI，需要接收tier(方案資料) 作為 Props。src/components/pricing/FaqSection.tsx：負責渲染底部的常見問題，並包含手風琴的開關狀態 (useState)。src/app/pricing/page.tsx：保持為主頁面，負責引入上述兩個元件，並保留資料夾取的邏輯。[執行要求]
- 請一步一步來，先提供
PricingCard.tsx的完整程式碼。- 確保 TypeScript 的 Interface / Type 定義正確匯出並共用。
- 確保原有的 Tailwind 樣式與動畫完全不變。
拆分過程中的地雷防範
當 AI 開始給你拆分後的程式碼時，請注意以下幾點：
1. Props 的傳遞 (Prop Drilling)
當你把元件拆出去後，原本在主頁面裡的變數（例如 const [isLoading, setIsLoading] = useState(false)），子元件會拿不到。AI 應該要透過 Props 把這些變數傳進去。如果 AI 漏掉了，請提醒它：「記得把 isLoading 作為 prop 傳給 PricingCard」。
2. 絕對路徑 vs 相對路徑
拆分到 src/components/ 後，原本檔案裡的 import 路徑可能會錯。
檢查 AI 寫的 import：
✅ import { AlertCircle } from "lucide-react";
✅ import { cn } from "@/lib/utils";
❌ import { cn } from "../../lib/utils"; (在 Next.js 中，盡量使用 @/ 絕對路徑)
3. 一次只做一件事
絕大規則：千萬不要在「重構」的同時「新增功能」！ 如果你想把按鈕拆出去，順便加上 Loading 旋轉動畫，請分兩步做。 第一步：拆分。測試會不會動。 第二步：加動畫。 這能確保你隨時可以 Git Commit 退回安全點。
定期大掃除的好處
只要你養成習慣，當一個檔案超過 300 行時，就請 AI 幫你做一次「元件拆分」。你會發現：
- AI 寫程式的速度變快了（因為 Token 變少了）。
- Bug 變少了（因為狀態被隔離在各自的元件中）。
- 你自己看 Code 的心情變好了。
這就是 Vibe Coding 能夠走得長遠、維護大型商業專案的終極秘訣！