2026/06/18
最近這一年，AI 工具已經慢慢變成我寫程式時很自然會打開的東西。
有時候它可以幫我補完一段邏輯，有時候可以協助整理型別、產生測試，甚至幫我快速看懂一段陌生的程式碼。坦白說，AI 確實讓開發速度快了很多。
但用久了之後，我反而更常提醒自己一件事：
寫得快，不代表系統會變好維護。
跑得起來，也不代表這段程式碼放在正確的位置。
前端工程師在 AI 時代，可能更需要守住一些基本的工程判斷。
前端專案最容易變亂的地方，通常不是畫面，而是資料流。
一開始可能只是很簡單地在 useEffect 裡取得資料：
1useEffect(() => {
2 fetchUser();
3 fetchOrders();
4 setDefaultFormValue();
5}, []);剛開始看起來沒什麼問題。
但需求一多，這個 useEffect 可能會慢慢塞進越來越多東西：API 呼叫、表單預設值、權限判斷、loading 狀態、錯誤處理，最後變成沒有人敢改的一段程式碼。
這種情況 AI 很容易幫我們「補得更完整」，但它不一定知道整個專案的資料流設計。
所以我現在會更在意這些問題：
key、derived state 或資料結構調整會更乾淨。資料流清楚，後面要維護、測試、重構都會比較安心。
AI 很會產生可以運作的元件，但元件能跑，不代表它適合長期留在專案裡。
我自己最怕看到的是一個元件同時處理太多事情：
這種元件短期很方便，因為東西都在同一個地方。
但過一陣子之後，它會變得很難測、很難拆，也很難放心修改。
我現在比較喜歡把責任切清楚：
BillingPage
├── BillingSummary
├── PaymentMethodList
├── AddPaymentMethodModal
├── usePaymentMethods
├── paymentMethodSchema
└── paymentMethodMapper
這樣拆不是為了看起來漂亮，而是讓每個檔案都有明確目的。
例如：
Page 負責組合整個流程。Component 負責畫面呈現。Hook 負責互動與狀態管理。Schema 負責資料驗證。Mapper 負責轉換資料格式。Service / DAL 負責封裝資料存取。當責任清楚，AI 產生的程式碼也比較容易被放到正確的位置。
Next.js App Router 讓前端可以處理更多接近 server side 的事情。
這很方便，但也代表工程師要更清楚哪些東西可以進 client，哪些東西應該留在 server。
例如：
1"use client";
2
3const user = await getCurrentUser();或是把不該暴露的 secret 放到前端邏輯裡：
1const secret = process.env.NEXT_PUBLIC_SECRET_KEY;這類錯誤不一定會馬上被發現，但它會讓專案邊界變得危險。
我通常會用這個方式判斷：
App Router 之後，前端工程師其實更需要理解產品的資料邊界。
因為一個看似小小的實作選擇，可能會影響安全性、效能，也會影響後續維護。
AI 產出的程式碼常常可以 demo，但產品不能只停在 demo。
尤其是登入、付款、權限、表單這類流程，只靠手動點一點很容易漏掉問題。
我會特別想保護這些地方：
例如付款方式管理，不應該只測「新增按鈕可以點」。
我更在意的是：
測試對我來說不是為了追求覆蓋率，而是讓自己敢改程式碼。
AI 可以幫忙產生測試，但工程師還是要決定哪些行為值得被保護。
AI 讓寫 code 變快，也讓不好的實作更快進入專案。
所以 Code Review 不能只看程式碼有沒有過 lint、型別有沒有通過、畫面有沒有跑起來。
我會更想看這些問題：
以前 review code 比較像是在看實作。
現在我覺得更像是在看一個工程決策是否合理。
AI 很適合協助重構，但重構最怕沒有目標。
如果只是覺得舊程式碼看起來很醜，就一次請 AI 大改整包，很容易把原本穩定的流程改壞。
我覺得比較好的重構方式，是先回答幾個問題：
重構不一定要一次做到最漂亮。
能讓系統每次變得更清楚一點、更安全一點，就已經很有價值。
有些程式碼看起來很厲害，但維護起來很痛。
太多抽象、太多泛型、太多共用邏輯，有時候會讓後面接手的人更難理解。
我現在更喜歡簡單、清楚、好追蹤的寫法。
我會更在意：
好的前端工程，很多時候不是寫出很炫的技巧，而是讓下一個人可以安全地理解、修改、擴充它。
我不排斥 AI，反而覺得它已經是很重要的開發工具。
只是當寫 code 變得越來越快，我們更需要知道哪些東西不能隨便交出去。
前端工程師在 AI 時代，仍然需要守住：
AI 可以幫我們加速很多事情。
但最後要對產品品質負責的，還是工程師自己。
