AI 衝擊前端生態？其實沒你想的那麼容易被取代

序

這幾年 AI 技術突飛猛進，尤其在前端開發領域，各種打著「設計圖一鍵變網頁」的工具如雨後春筍般出現，例如 Bolt、Locofy、Lovable 等平台。不少老闆或 PM 看了之後眼睛一亮，彷彿找到了加速專案進度的萬靈丹，甚至開始質疑：「AI 就可以做了我為什麼還需要前端工程師？」

這樣的期待我完全可以理解，畢竟誰不想又快又便宜把東西做出來？但從實務的角度來看，這些工具的實際效益，與它們宣稱的願景還有不小差距。

AI 工具 ≠ 自動完美產出，更像高級外包切版

我曾親自試用幾款這類工具，把設計圖輸入進去後，確實能在幾分鐘內產出可用的 HTML/CSS/JS 程式碼，乍看會覺得「Damn~ 這好像真的有點東西」。但當我要接手進行後續開發時，問題就出現了。

首先，AI 的邏輯與我自己處理畫面與資料狀態的方式往往不同。例如，它可能為了快速呈現畫面，用了大量 inline style 或繁雜的 class 結構，或者在元件拆分、狀態管理上的處理和我的慣例完全背道而馳。當我要去理解、調整或除錯這些程式碼時，反而花了更多時間重構與對齊思維。

這個過程，說白了就像接手一份從外包切版廠商那邊拿來的程式碼。除非先說好這份結果交出去之後永遠不再改動，又或者後續交由同一位且知曉所有 context 的 AI agent 來維護，不然最終還是會回到你自己或你團隊手上。這時候你會發現，理解 AI 產生的邏輯、預測它可能帶來的副作用，所耗費的心力，並不會比自己從頭開發來得輕鬆。

最常用的情境：當你知道怎麼做，只是好累不想重複做

儘管如此，我並不否定 AI 工具的價值。反而在某些特定情境下，它的幫助非常實際。

舉例來說，前端開發中最常見的任務之一就是表單：input 欄位、驗證、事件綁定、錯誤訊息顯示、送出邏輯 ... 每個都不難，但堆起來就是一個「我知道怎麼做，但真的不想重複寫」的典型案例。

這時候 AI 就很好用了。我可以描述需求、貼上設計稿或資料結構，AI 就能給我一份基本的骨架，我再來進行微調、套上自己的邏輯或元件系統，效率明顯提升。尤其在開發 MVP 階段，要快速搭出可運作的 demo 或 prototype，有 AI 介入真的省了不少力氣。

J.A.R.V.I.S.

最近遇到一個頗具代表性的案例，也讓我更具體體會到 AI 在開發流程中的輔助價值。

我們專案裡用了 vxe-table 這個表格套件，是幾年前為了實現大量資料操作與 virtual scroll 效能而引入的。當時希望讓使用者可以像操作 Excel 一樣，快速瀏覽與輸入資料。雖然功能簡化不少，但在效能與互動設計上，已經能夠符合我們的需求。

結果最近公司在做全面弱掃時，掃到的其中一個風險就是出在 vxe-table 上。它踩中了 Prototype Pollution 的漏洞，查了一下 issue tracker 和 Snyk，發現官方還沒有釋出修補，也沒有明確的處理時程。眼看審核時程告急，等官方已經來不及了，只能自己設法解決。

一開始的直覺反應是：「那就換掉吧。」於是我看到了 ag-grid —— 功能非常完整，也支援 virtual scroll，看起來是個不錯的替代方案。但實際翻了檔案後發現，要導入這套件幾乎等同於重寫整個表格模組。資料格式要轉換、事件邏輯要重綁，連 UI 行為都得重做，測試成本也不小。在目前的開發時程與驗收壓力下，這個選項現實上不可行。

這時我想到一個折衷方案：以前曾經看過一個叫做 patch-package 的套件，一直不解到底什麼時候需要用到他，想說「有問題的東西維護者一定會修吧！晚點更新版號就好啦～」，殊不知現在被跨時空的搧了一巴掌。

於是我找了平常在用的 Claude，一步步針對 vxe-table 的原始碼進行分析，確認哪個邏輯導致污染、該怎麼安全地修改，修改後是否會影響原有功能。我們來回調整好幾次，最終成功寫出一個能在部署時自動套用的 patch，順利修補了漏洞，同時保留現有功能不變，讓版本通過安全性審查。

這段經歷讓我深刻體會到：AI 不會幫你做決定，但能在你理解問題本質與脈絡的前提下，大幅加速解法的產出。這次如果沒有 AI，我還是能處理這個問題，但勢必得自己花更多時間翻 code、查資料、驗證實作；有了 AI，等於有了屬於我的賈維斯，能跟他討論問題並來回驗證 (當然也少不了一些謾罵 😅)，在關鍵時刻提供了很實用的支援。

結語

從目前的使用經驗來看，我認為 AI 不會馬上取代前端工程師，尤其在畫面邏輯、使用者體驗、維護性與團隊溝通這些需要人判斷的層面，AI 還遠遠追不上 (嗎？)。但它確實正在改變我們開發的方式，尤其在初期產出、繁瑣作業、跨領域搜尋這些任務上，它讓我們變得更有效率。

所以與其擔心被 AI 取代，不如思考要怎麼用好這些工具，讓它們變成我們的神兵利器，而不是風險來源。也許某些開發流程會因此被簡化，某些技能會變得不再稀缺，但真正理解使用者、做出好產品的人，永遠還是不可或缺的。