這份筆記是寫給那種已經感覺到壓力的前端工程師：每天看到 Cursor、Claude Code、Codex、Copilot 又進步了，心裡知道要跟上，但又不確定自己到底該補什麼。

先講結論。2026 下半年，不要把目標放在「不要被 AI 取代」。這個目標太空，也太容易讓人焦慮。比較實際的目標是：

讓自己變成會指揮 AI、檢查 AI、最後能把產品交出去的人。

前端工程師真正危險的地方，不是 React、CSS、切版這些東西一夕之間消失。危險的是只會等規格、照 UI 寫元件、需求有問題也不問、AI 生出來的 code 也看不出哪裡怪。

比較好的定位是：前端產品工程師 + AI 協作者。

也就是說，你還是寫前端，但你不只寫畫面。你要懂產品、懂使用者、懂品質，也要懂怎麼把 AI 放進自己的工作流。AI 出錯時，你接得住；AI 能加速時，你用得起來。

下半年先補這幾件事

1. 建一套自己的 AI coding 工作流

不要只停在「我會用 Cursor」或「我會叫 ChatGPT 幫我寫 code」。那不夠。

你至少要熟兩個工具，例如 Cursor + Claude Code，或 Codex + Copilot。重點不是工具名稱，而是你有沒有一套固定流程：

• 專案背景怎麼餵給 AI
• 任務怎麼拆
• 哪些事交給 AI 做
• 哪些地方一定自己 review
• 測試怎麼跑
• PR 前要檢查什麼
• AI 改壞東西時怎麼回復

可以開始建立幾個自己的檔案，例如 AGENTS.md、PR 檢查清單、常用 prompt、測試指令、設計規範。這些東西很無聊，但很有用。你會慢慢從「跟 AI 聊天」變成「管理一個會寫 code 的助手」。

2. 前端基本功還是要補，沒有捷徑

TypeScript、React / Next.js、CSS Grid / Flex、RWD、表單、狀態管理、效能、可讀性，這些東西沒有過時。

反而更重要。

因為 AI 可以幫你生 code，但它不會替你負責。你要看得出：

• 元件是不是切太碎或太肥
• state 是不是放錯地方
• RWD 是不是真的能用
• 表單錯誤狀態有沒有處理
• accessibility 有沒有明顯問題
• code 是不是只在 demo 情境看起來能跑

基本功穩，AI 是助理。基本功弱，AI 很容易變成風險來源。

3. 把測試和品質變成習慣

很多人用 AI 最大的問題，是產出變快了，但 review 變粗了。這件事很危險。

你可以固定要求 AI：

Make sure this project is testable.

但不要以為它生出測試就沒事。你還是要看測試到底測了什麼。是不是只測到 implementation detail？有沒有 loading state、error state、empty state？表單驗證有沒有測？核心使用者流程有沒有測？

未來會更缺那種能讓 AI 產出「可以維護的 code」的人，而不是只會讓 AI 多生幾百行的人。

4. 補產品和 PM 思維

前端工程師如果只把自己定義成「做畫面的人」，會越來越吃虧。

你要練的是：

• 需求不清楚時敢追問
• 能把模糊需求拆成幾個可交付版本
• 知道什麼先做、什麼可以晚點做
• 看得出 UI 背後的產品問題
• 能寫出人看得懂、AI 也看得懂的規格

這件事比多學一個框架更有用。框架會換，產品判斷比較不會。

5. 讓別人看得到你的能力

不要把所有能力都埋在公司專案裡。那很可惜，也很危險。

每週做一點公開輸出就好，不用搞得很盛大：

• 一篇踩坑筆記
• 一個 GitHub 小作品
• 一段 UI 重構前後比較
• 一篇 AI coding 工作流分享
• 一個 code review 案例
• 一個小工具

你不需要一開始就變成網紅。但你要留下痕跡。找工作、接案、合作，人家總要有東西可以看。

2026 下半年可以這樣安排

7 月：整理自己的 AI 開發流程

做一個範例 repo。不要太大，但要完整。

裡面放需求文件、AI prompt、測試、README、部署連結、開發流程說明。目標是讓別人看得出你不是用 AI 亂生 code，而是有流程、有檢查、有交付。

8 月：做一個 AI + 前端作品

不要再做 Todo App 了。除非你真的能把 Todo App 做到非常有產品感，否則它很難說服人。

可以做客服知識庫、履歷優化器、產品頁生成器、資料儀表板、AI 表單產生器、報價單產生器、小型 CRM。重點是要有真實情境。使用者是誰？他要解決什麼問題？這個工具幫他省了什麼時間？

9 月：補一點後端和部署

前端只懂畫面會越來越薄。

不用把自己變後端工程師，但至少要能做一個小產品：Next.js API、PostgreSQL、Auth、Vercel 或 Cloudflare、基本 logging、error tracking、環境變數管理。

你要能從畫面一路做到上線。這會讓你的職涯彈性大很多。

10 月：練 code review

拿 AI 產生的版本，自己重構一版，然後寫出差異。

不要只說「我改得比較乾淨」。要講清楚：哪裡可讀性變好？哪裡效能變好？哪裡比較安全？哪裡比較好測？哪裡未來比較好改？

這個練習很值得做。因為未來很多團隊不缺能生 code 的人，缺的是能看出 code 會不會害死專案的人。

11 月：重寫履歷和面試案例

履歷不要只寫「熟 React / TypeScript」。大家都這樣寫，沒什麼記憶點。

改寫成案例：

• 我怎麼用 AI 把某個流程變快
• 我怎麼發現 AI 產出的錯誤
• 我怎麼把模糊需求整理成可交付版本
• 我交付了什麼，省了多少時間，降低了什麼風險

如果要用 STAR，也可以。但不要寫得像模板。重點是讓面試官感覺你真的做過，不是把流行詞塞進履歷。

12 月：累積自己的數字資產

副業不一定是馬上接案。先累積能被重複使用的東西：

• 模板
• 元件庫
• 小工具
• 技術文章
• prompt 模板
• AI 工作流包
• 教學素材

這些東西短期看起來不一定賺錢，但會慢慢變成你的籌碼。至少，它會讓你比較不依賴單一公司、單一主管、單一職位。

焦慮的時候，回來看這幾點

Stack Overflow 2025 的調查裡，84% 開發者已經在用或準備用 AI。但同一份調查也顯示，真正高度信任 AI 輸出的人只有 3.1%。這很有意思。大家都在用，但大家也都知道不能全信。

所以市場需要的不是盲目相信 AI 的人，而是能審查、修正、負責的人。

State of JS 2024 提到的前端痛點也沒有消失：複雜度、效能、選擇過載、breaking changes、狀態管理、SSR、dependency 問題。AI 會產生更多 code，但它不會自動解決這些維護問題。

還有一點值得記住。2025 METR 的研究發現，在熟悉大型專案的資深工程師身上，AI 反而可能讓任務變慢 19%。原因很簡單：提示、等待、審查、清理，都要時間。

這不是叫你不用 AI。剛好相反。你要用，但要用得有判斷。

AI 是槓桿，不是替代大腦。

最後

2026 下半年，前端工程師不要只想著「我還會不會寫 React」。這題太小。

比較該問的是：

我能不能用 AI 更快做出一個可用的產品？
我能不能看出 AI 寫的 code 哪裡有問題？
我能不能把一個模糊需求整理到可以交付？
我能不能讓別人看見我的能力？

如果這幾題的答案慢慢變成「可以」，焦慮會少很多。不是因為市場變安全了，而是你手上的選擇變多了。