今天筆者要來介紹的，就是 Vibe Coding 常見、也容易被忽略的問題：Duplicate Code，也就是重複程式碼。 。因為 Vibe Coding 的優點是快，缺點也是快，快到你還沒發現架構歪掉，程式已經長成一大包了~

傳統 Waterfall 是先把輪胎、底盤、引擎全部設計完，再慢慢組成一台車；Agile 則是一段一段迭代，最後逐步做出可以上路的車。至於 Vibe Coding 呢？一開始就能讓車子跑起來，結果功能一路加、一路貼，最後車子變成「零件都在，但不知道煞車在哪的狀態……😅

🧨 為什麼 Vibe Coding 特別容易產生重複程式碼？
傳統開發通常會先做規格、設計架構，再進入實作；在 Vibe Coding 時，往往是先丟幾句 Prompt，讓 AI 先把成品生出來。 這招在練手、做 POC、趕 Demo 時真的很香，沒想到當開始追加功能，問題就慢慢浮出水面。

⚠️ 快速產出之後，重複程式碼可能一路累積，Vibe Coding 的三個隱形成本
Prompt 越快，重複邏輯越容易出現：AI 為了完成當下需求，可能直接在另一個檔案再產生一份相似程式。
維護成本增加：同一個規則散落在多個地方，未來修改時要改好幾次。
Token 消耗增加：AI 每次讀取更多重複程式碼，Context 變大，Token 也跟著燃燒。

🎈Copy paste 很快，但後續維護會越來越痛苦
筆者以前寫程式也常常偷懶，看到兩段邏輯很像，就先 Copy、Paste，再改幾個變數名稱。當下覺得自己效率很高，結果過了一個月，連自己都分不清楚「這段到底該留還是該刪」。 這就是典型的技術債，前面欠一點，後面利息比信用卡還兇啊。

🛒 實作情境：訂單、庫存、退貨與 Email
這次筆者準備的是微軟提供電商程式，包含訂單處理、庫存查詢與更新、退貨流程、Email 通知，以及 Audit Log。 這些功能看起來各自獨立，但實務上常常會共用一大堆流程：驗證 ID、檢查庫存、更新狀態、寄信、寫紀錄。

先來看 Email 這一段。筆者當時就是很典型地把寄送訂單通知的程式複製一份，再改成退貨通知，像是 Email template、Subject、Transaction ID 等欄位。 功能是可以動啦，但兩段程式其實做的是同一件事：準備內容、格式化主旨、寄出 Email、留下紀錄。

這些流程在訂單通知與退貨通知中高度相似，差異只是傳入的類型與 ID，因此很適合抽成共用方法。

🔍 讓 AI 幫忙掃描 Duplicate Code
確認問題之後，筆者就叫 AI 來幫忙掃描。這裡的重點不是直接跟 AI 說「幫我重構全部」，而是先讓它分析、列出重複位置、說明建議，再進行修改。 這樣比較不會一個按鈕下去，整個專案被 AI 改到親媽都不認得。

AI 開始找出驗證流程與其他重複邏輯
果然，AI 找出了不少重複點，例如 Order ID 與 Return ID 的驗證方法，雖然名稱不同，但裡面都有空值檢查、安全性驗證、長度驗證與 Prefix 驗證。 另外，Email 寄送流程也被偵測出來，Inventory 與 Audit Log 同樣存在類似的重複邏輯。

在專案中建立 /refactor，Refactor的提示詞如下

🚀 使用自訂 Prompt 啟動 Duplicate Code 掃描AI 重構結果：程式變小，維護也比較輕鬆
這次筆者讓模型專注處理「重複程式碼」這一件事，結果居然還不錯。 原本以為 AI 會大刀闊斧亂改，結果它有先找出重複的位置，再集中整理共用邏輯，沒有把整個專案改成一鍋粥。

更多實作請參考完整版影片

📌 今日結論
為什麼這是 Vibe Coding 的必學技能？筆者認為，AI Coding 真正的關鍵不是叫 AI 幫我多寫幾千行程式，而是要讓 AI 協助我維持程式品質。 Vibe Coding 很適合快速驗證想法，但如果每次只追求「先做出來」，卻不處理架構與重複邏輯，最後就會從小菜一碟一路升級成魔王關。

🌟 重構一次，至少有三個好處
程式碼變小：減少重複後，專案結構更簡潔。
AI 更容易維護：未來 AI 需要讀取的內容變少，理解上下文也更容易。
節省 Token：少讀一堆重複程式，就是少燒一點 Token，雖然廠商可能不會主動提醒你這件事啦。

所以筆者的建議很簡單：每完成一個功能，就讓 AI 掃一次；每完成一個 Module，就做一次小型 Refactoring。 不必等到程式大到像義大利麵才開始整理，那時候通常已經不是重構，是考古。

Vibe Coding 要跑得快，重構就要跟得上；程式抽得好，Token 少不了，維護也沒煩惱啊~