前幾年大家還在爭論，AI 到底能不能寫程式。現在這題差不多結束了。它不只會寫，還寫得很快。快到很多前端工程師開始有點不舒服，因為以前最值錢的那段能力，忽然沒那麼稀缺了。

從 Karpathy 把 Vibe Coding 這個詞拋出來，到台灣這邊高見龍老師開始談工程師的生存指南，熱度會一路燒上來，其實不難理解。不是因為大家突然喜歡幫開發流程取新名詞，而是很多人都碰到同一個現實：切版、串 API、補表單、拆 component，AI 都能在很短時間內生出一版。真正慢下來的地方，反而變成另一件事，你到底想做什麼？邊界畫在哪裡？哪裡可以先快，哪裡絕對不能亂？

我自己的感覺很直接。程式碼變便宜之後，工程師的工作比較不像打字比賽，比較像現場指揮。

程式碼變便宜，判斷變貴

以前我們會把「寫得快、寫得穩」當成很核心的競爭力。現在這件事沒有消失，只是排序往後退了。

因為當需求夠清楚時，AI 很容易在幾分鐘內吐出一大段看起來能跑的結果。你要它生一個會員頁，它可以把欄位、驗證、狀態管理甚至 loading state 一起補上。表面上像是產能翻倍，實際上，真正稀缺的東西換成了規格、取捨和收斂能力。

同樣是做一個註冊流程，AI 可以很快把畫面拼起來，但它不會替你決定哪些欄位該延後載入、哪個錯誤訊息值得被看懂、哪個資料流半年後最容易炸。更不會替你扛產品風險。這些判斷，最後還是得回到人身上。

所以 2026 年還在前端一線的人，價值越來越不像「我能多快寫完」，而是「我能不能把混亂的需求整理成穩定的系統」。

為什麼 CLAUDE.md 這類檔案突然變重要

這波工具變化裡，我覺得最值得注意的，不是哪一家模型又贏了 benchmark，而是大家開始重新看待「專案記憶」這件事。

像 CLAUDE.md、AGENTS.md，甚至 llms.txt，本質上都在做同一件事：把這個專案怎麼思考、哪些規則不能踩、做到什麼程度才算完成，先寫清楚。你可以把它理解成寫給 AI 協作者看的開發守則。

例如一個前端專案的協作記憶，最少可以長這樣：

# CLAUDE.md

- Use Next.js App Router and TanStack Query.
- Do not fetch data directly inside UI components.
- Every async page must define loading, error, and empty states.
- Forms use Zod and react-hook-form.
- Done means: lint passes, tests pass, mobile layout is checked.

這種檔案看起來很普通，可是真的有用。因為它把「團隊默契」從口頭抱怨變成可被代理讀懂的約束。少了這一層，AI 每次都只能用猜的；猜得多了，專案就開始漂。

而且這種治理不只管程式碼，連 demo 素材和文件也該一起管。現在很多 side project 會直接用 Gemini 生幾張示意圖丟進 PRD、簡報或測試頁。我自己通常會把這類處理也放進工作流，例如需要把正式展示用的圖片整理乾淨時，就先用 Gemini Watermark Cleaner 處理，再放進文件或展示頁。這樣可以避免臨時素材悄悄混進正式輸出，最後連你自己都分不清哪些是草稿、哪些是可交付版本。

真正會拖垮團隊的，是控制債

現在很多人談技術債，但我覺得 AI 時代更麻煩的是控制債。

控制債不是某一段程式碼寫得醜，而是整個專案慢慢失去可預測性。今天 AI 幫你補一個功能，明天順手改一個元件，後天又接一段新的資料流。每次看起來都不大，畫面也能跑，可是命名開始漂、資料邊界越來越糊、狀態散得到處都是。等你真的要重構時，整個 repo 像一台能發動、但沒人敢上高速公路的拼裝車。

這就是很多團隊一開始覺得 AI 很神，三個月後卻開始怕它的原因。前面省下的時間，後面會用維護成本加倍收回去。

如果你只把 Vibe Coding 當成產能加速器，沒有同時補上 review、測試和架構約束，那最後通常不是更快，而是更亂。這不是模型的錯，是你把控制權交出去之後，沒把驗收權拿回來。

前端工程師正在變成體驗編排者

這件事不代表前端工程師會被取代。剛好相反，角色其實變得更清楚了。

AI 很會補程式碼，卻不太會替產品負責。它可以生成 component，卻不會替你決定整體互動是不是一致；它可以把 API 接起來，卻不會幫你衡量首屏速度、錯誤狀態和商業目標怎麼取捨。這些事，還是得有人做。

所以我越來越認同一個說法：前端工程師正在往「體驗編排者」靠近。你要能定義畫面與資料怎麼配合，知道哪些地方適合交給 AI，哪些地方必須由人親自收斂。你還得會選生態。像 TanStack、Next.js 這種邊界清楚、慣例完整的方案，在 AI 協作時代反而更有優勢，因為它們直接縮小了代理亂跑的空間。

說穿了，未來更值錢的能力不是「我能寫多少行程式碼」，而是「我能不能把需求、工具、資料流和體驗標準排成一套穩定的系統」。

如果你已經在用 Vibe Coding，先把這四件事做起來

1. 先寫規格，再叫 AI 動手。需求、限制、完成條件越清楚，返工越少。
2. 幫專案準備固定記憶。不一定非得叫 CLAUDE.md，但一定要有一份所有代理都讀得懂的協作說明。
3. 優先選邊界清楚的技術棧。慣例越完整，AI 出錯的空間越小，review 成本也越低。
4. 保留人工驗收權。速度不是問題，失控才是。每一段 AI 產出的程式碼，都要回到你定的標準下檢查。

結語

程式碼不再是瓶頸，聽起來像壞消息，其實不完全是。它只是把一件早就存在的事講得更誠實一點：工程師的價值，本來就不只在手速。

2026 年還能拉開差距的人，多半不是最會追新工具的人，而是最會定義問題、安排工作流、守住品質邊界的人。AI 會讓寫程式這件事更便宜，但它不會幫你決定什麼叫一個值得維護的前端專案。

那一段，還是人的工作。也是現在最貴的部分。