AI 時代，前端工程師該守住什麼？

AI 工具越來越強，從補完程式碼、產生元件，到協助重構、撰寫測試，前端工程師的工作方式已經明顯改變。

但我越使用 AI，越覺得前端工程師真正該守住的，不是「我能不能比 AI 更快寫出程式碼」，而是：

我是否知道這段程式碼該不該存在？
它應該放在哪裡？
它會不會破壞資料流、權限邊界與長期維護性？

AI 可以幫我們寫 code，但它不會替產品承擔後果。
所以在 AI 時代，前端工程師更需要守住幾個基本原則。

一、守住資料流，不要讓畫面變成黑盒子

前端最容易失控的地方，不是 UI 長得醜，而是資料流開始變得混亂。

例如：

1useEffect(() => {
2  fetchUser();
3  fetchOrders();
4  syncUrlState();
5  setDefaultFormValue();
6}, []);

一開始看起來只是「初始化資料」，但久了之後，這個元件會變成一個黑盒子。

你很難回答：

• 這個資料從哪裡來？
• 什麼時候會重新取得？
• 哪個狀態是 server state？
• 哪個狀態是 local UI state？
• 這段 useEffect 被改掉會不會影響其他流程？

AI 很擅長補上看似合理的程式碼，但如果工程師沒有先定義資料流，AI 只會把混亂寫得更快。

我認為前端工程師要守住的第一件事，就是清楚區分：

當資料流清楚，AI 才是加速器。
當資料流混亂，AI 只是幫你更快製造技術債。

二、守住 Component 的責任邊界

AI 很容易產出「可以跑」但不好維護的元件。

例如一個元件同時做：

• 取得資料
• 處理權限
• 驗證表單
• 顯示 Modal
• 控制 loading
• 處理錯誤訊息
• 轉換 API response
• 觸發 toast
• 導頁

這種元件短期看起來很方便，但長期會很痛。

因為它不是一個元件，而是一個小型系統。

我自己的原則是：

元件超過一定複雜度時，不只是拆檔案，而是要拆責任。

例如：

1BillingPage
2├── BillingSummary
3├── PaymentMethodList
4├── AddPaymentMethodModal
5├── usePaymentMethods
6├── paymentMethodSchema
7└── paymentMethodMapper

這樣拆的目的不是為了「看起來很乾淨」，而是讓每個地方都有明確責任：

AI 可以幫你寫元件，但工程師要判斷這個元件是不是已經承擔太多責任。

這是 AI 很難替你守住的地方。

三、守住 Server / Client 邊界

在 Next.js App Router 裡，Server Component、Client Component、Server Action、Route Handler 的分工很重要。

但 AI 很常為了讓功能「先跑起來」，把東西塞進 client component。

例如：

1"use client";
2
3const user = await getCurrentUser();

或是把不該出現在瀏覽器的邏輯放進前端：

1const secret = process.env.SECRET_KEY;

這種錯誤不一定馬上爆炸，但會破壞安全邊界。

我會用這個方式思考：

前端工程師不只是寫畫面的人。

尤其在 App Router 之後，前端工程師其實更接近「產品邊界設計者」。
哪些資料能進 client、哪些邏輯必須留在 server，這些判斷會直接影響安全性與維護性。

四、守住驗證，而不是只相信畫面能跑

AI 產出的程式碼常常可以 demo，但不一定可靠。

所以我認為 AI 時代更需要測試，不是更不需要測試。

尤其是這幾種流程：

例如付款方式管理，就不應該只測「按鈕可以點」。

更重要的是：

• 未登入不能進入頁面
• 新增卡片時欄位必須驗證
• 設為預設付款方式後狀態正確
• 刪除付款方式後列表更新
• API 錯誤時不應該造成錯誤狀態殘留

測試不是為了追求覆蓋率好看，而是為了建立工程信心。

AI 可以幫我們寫測試，但工程師要定義什麼行為值得被保護。

五、守住 Code Review 的判斷力

AI 讓寫 code 變快，但也讓錯誤進入專案的速度變快。

以前工程師可能是一行一行慢慢寫出技術債。
現在可能是一次 prompt 直接產生一整包技術債。

所以 Code Review 不能只看：

• 有沒有跑起來
• UI 有沒有符合畫面
• TypeScript 有沒有過
• ESLint 有沒有綠

還要看：

AI 時代的 Code Review，不只是 review code。
更像是在 review 決策。

六、守住「不要盲目重構」的原則

AI 很容易讓人產生一種錯覺：

反正 AI 可以改很快，那就整包重構。

但重構不是把程式碼改得比較新，而是讓系統變得更安全、更清楚、更容易維護。

如果沒有測試、沒有資料流理解、沒有明確目標，重構很可能只是把舊問題換成新問題。

好的重構應該要能回答：

• 我現在要解決什麼問題？
• 這次改動的範圍是什麼？
• 有沒有測試保護主要流程？
• 如果出問題，能不能 rollback？
• 有沒有比大改更小的做法？

AI 可以加速重構，但不能取代工程判斷。

七、守住「可維護」比「看起來很厲害」重要

有些程式碼看起來很高級，但很難維護。

例如過度抽象、過度泛型、過度封裝，短期看起來很漂亮，長期卻讓人不敢改。

我現在更在意的是：

好的前端工程，不是寫出最聰明的 code。
而是讓下一個人可以安全地理解、修改、擴充它。

結語：AI 可以幫忙寫程式，但工程師要負責判斷

我不覺得前端工程師會因為 AI 就不重要。

相反地，當寫 code 變得更便宜，工程判斷會變得更重要。

因為未來真正有價值的能力，可能不是「我能不能寫出這段程式碼」，而是：

• 我知道這段程式碼該不該寫
• 我知道它應該放在哪裡
• 我知道它會不會破壞系統邊界
• 我知道怎麼驗證它是安全的
• 我知道怎麼讓團隊未來可以維護它

AI 時代的前端工程師，不只是使用工具的人。

更應該是守住產品品質、系統邊界與工程判斷的人。