這兩個月，我彷彿經歷了一場深海救援。
接手了一個稍微複雜的專案救援任務，原本預期是常規的除錯與優化，但當我打開 Codebase 的那一刻，我意識到事情沒那麼簡單。前一位工程師留下的，不是單純的 Bug，而是一座由 GenAI 快速堆砌、卻缺乏地基的摩天大樓。
這段日子的可以用一句話總結：用 GenAI 寫 Code 很快樂，那種「Vibe Coding」的流暢感令人著迷；但若缺乏判斷力，這份快樂背後的代價，非常昂貴。這代價不只是燒掉的預算，還有那逝去的半年開發時間。
速度的假象：拼湊感的來源
在前一位工程師的代碼中，我看到了大量的 GPT 痕跡。平心而論，這本身沒有問題。在這個時代，不使用 AI 輔助開發才是跟自己過不去。
問題在於「照單全收」。
我可以想像當時的開發場景：需求來了，丟給 AI，Code 出來了，貼上去，跑過了，收工。這種開發模式帶來的速度感是驚人的，前期的進度條跑得飛快。然而，當我深入修補時，發現整個架構充滿了嚴重的「拼湊感」。
AI 給出的建議通常是針對「當下這個函式」或「當下這個功能」的最佳解，但它往往缺乏對「整體系統邊界」與「長期維護性」的考量。當這些碎片化的「局部最佳解」被硬生生地拼在一起，卻沒有經過人類工程師的過濾與調整，整個系統就像是一個外表光鮮亮麗，但內部管線亂接、結構搖搖欲墜的樣品屋。
核心技能的缺失：實作順序與喊停的勇氣
我們常誤以為軟體開發就是「把功能寫出來」（Implementation），這也是 AI 最擅長的部分。但真正區分新手與資深工程師的，從來不是語法記憶，而是隱藏在代碼背後的決策過程：
- 實作順序的決策 (Sequence of Implementation)：先做什麼？後做什麼？哪個模組應該先被抽象化？這決定了依賴關係是否健康。
- 適時喊停的決策 (Decision to Stop)：知道何時該停下來重構，知道這條路走下去會是死胡同。
這是一種關於風險控制、需求管理與架構平衡的技術。這是一種依賴長期實戰經驗所訓練出來的「直覺」。
遺憾的是，目前的 AI 很難反向推敲出這些決策。它會盡力滿足你的 Prompt，即使你的要求會導致未來的架構崩壞，它也會順從地給出一段能跑的 Code。如果你沒有能力判斷「這段 Code 放這裡對不對」，那麼 AI 的順從，就是最甜蜜的毒藥。
工具越強，濾網就要越細
我自己也是重度 AI 使用者，手邊用的是最兇猛的 Opus 4.5 和 Sonnet 4.5。必須承認，它們能幫我完成 80% 的通用功能。
但剩下的那 20% 呢？
那 20% 往往是業主最富有創意的商業邏輯，是那些非標準化的、需要層層拆解的複雜需求。這時候，最困難的不是「如何實作」（How），而是「決策順序」（When & What）。
如果沒有紮實的基礎知識，你就無法形成有效的「濾網」。
- AI 給的這段 Code 是最佳解，還是僅僅能跑？
- 這個 Pattern 雖然現在好用，三個月後會不會變成巨大的技術債？
- 這裡的邏輯是否符合我們特定的商業規則？
當你無法分辨這些差異，你就很容易被 AI 帶進溝裡。
商業開發不能靠感覺
現在很流行一個詞叫「Vibe Coding」（靠感覺寫 Code），這聽起來很酷，我也承認這很適合用來做玩具、做 Side Project 或是進行技術研究。
但如果要交付的是商業產品，我們就不能只靠「感覺」，必須靠「專業」。
我這兩個月的收尾工作，說穿了，就是在幫這個專案補上遲來的「濾網」，把那些鬆散的 AI 建議，重新用邏輯與架構串聯起來。
未來的工程師，價值或許不再於你親手敲了多少行程式碼，而在於你是否具備足夠的鑑別力與判斷力。你是那個指揮 AI 艦隊的指揮官，還是被 AI 牽著鼻子走的乘客？
