AI 時代的前端：哪些技能會被塗灰，哪三個不會

1. 怕被 AI 取代？先看這三個技能 0:00–0:26

主持人開場：如果你是害怕 AI 的前端工程師，有三個關鍵技能可以讓你免疫。Bogdan 直接點名第一個——system design，而且是前端的 system design，不必碰資料庫分片i或負載平衡。

推理因為讀者的焦慮是「整個職能會不會消失」，所以作者先把問題縮小成「哪三個技能值得投資」，並立刻點名第一個是 frontend system designi，同時劃掉範圍——不必碰 database sharding 或 load balancer。

• Cfrontend system design：模組怎麼切、狀態放哪、什麼該封裝成服務、元件間用什麼介面——不是 sharding 與 LB→ 畫地圖
• R判斷一項技能會不會被 AI 吃掉：成功條件能不能寫清楚——能就會被自動化，人只剩檢查→ 存＋回想

AI 補充開場就把後端 system design 排除，是這支影片的第一個關鍵決定。一般講 system design 指的是資料庫分片、快取、負載平衡；前端的 system design 問的是另一組問題：模組怎麼切、狀態放哪裡、哪些東西該被封裝成服務、元件之間用什麼介面溝通。這個區分讓後面所有論證都站在同一個層次上——他要比較的不是「AI 會不會寫 SQL」，而是「AI 會不會替你決定邊界」。

2. AI 給你漂亮介面，不給你邊界 0:26–1:36

現在的模型被大量優化在「prompt 進、介面出」，所以畫面很漂亮，但底下是一堆定義不清、互相纏繞的實體。能跑、沒錯誤，卻極貴又難維護。好的前端長得不一樣：清楚的邊界i、各司其職的服務、隱藏實作細節、對介面而不是對實作寫程式；邊界清楚時，用 AI agent 擴充同樣的功能會花掉明顯更少的 token。

推理因為要說明缺口，所以作者拿出兩張對照圖：一張是 AI 產出的樣子——一堆沒有定義清楚的實體互相箭頭連來連去；另一張是好的前端——Auth Client、Theme Service、Sign Up、Routing 各自是一個有介面接點的方塊。他接著補上一個很少人講的理由：邊界清楚不只是為了人好維護，也是為了讓 AI 便宜。

• Cclear boundaries：每個模組職責明確、內部不外流、只透過介面互動——對人好維護，對 AI 便宜→ 畫地圖
• Ctoken efficiency：完成同一項修改要餵給模型的 token 量；架構品質從長期指標變成每天結帳的成本→ 畫地圖
• A邊界不只是給人看的，也是給模型看的索引：agent 靠它知道該讀哪裡、不必讀完全世界→ 批判類比

AI 補充畫面上那三行字是這段的濃縮：Clear Boundaries、Programming to Interfacesi、Context Engineering & Token Efficiencyi。前兩項是傳統軟體工程的老話，第三項才是 AI 時代新增的：當每個模組對外只暴露介面，agent 要改一個功能時，需要被讀進 context 的程式碼就少，token 花得少、幻覺也少；反過來，纏成一團的 codebase 會逼 agent 讀進整片檔案才敢動手。也就是說，架構品質從「可維護性」這個長期指標，變成了一個每天都會被結帳的短期成本。順帶一提，字幕把模型名稱轉錄成「Oppo models」，從上下文與後面畫面上的模型標註看，指的是當時最新的旗艦模型，不是某個叫 Oppo 的產品。

3. 每加一個功能就重塑一次架構 1:36–2:43

用 LLM 寫程式的第二個問題：每實作一個新功能，它就為那個功能重新調整架構，因為模型被設計成「一個 prompt 展示最大成果」，代價是推翻你之前做的一切。好架構從不為單一功能量身訂做，而是所有功能折衷後的那條中線——更穩定、更好擴充、也更好解釋。因此和 AI 一起寫程式時，你要能避開 code smelli，並替除錯與測試設定對的基準。

推理因為模型被設計成用一個 prompt 展示最大成果，所以它每次都會把周圍改成最適合這個功能的樣子，代價是推翻你之前的決定。作者於是把架構畫成一張散點圖：橫軸是各種功能，縱軸是結果，好架構是穿過所有點的那條迴歸線，而不是精準通過某一個點的線。

• Coverfitting：AI 每加一個功能就把周圍改成最適合它的樣子——單一功能的最佳解對整個系統是過擬合→ 畫地圖
• A好架構是穿過所有功能點的迴歸線，不是精準通過某一點的線：對每個功能都不是最好，對全部都夠好→ 批判類比

AI 補充這張迴歸線的圖是整支影片最好用的心智模型。單一功能的最佳解，對整個系統來說通常是過擬合i；穩定的架構是所有功能的折衷，對每個功能都不是最好，但對全部都夠好。這也解釋了為什麼 AI 產出的程式碼「當下看起來很合理」——它確實對那一個點做了最佳化。要對抗它，你需要的不是更會寫 prompt，而是能認出 code smell、並且事先替除錯與測試設好基準：這些基準就是你替那條線釘下的錨點。

4. design into code：受衝擊最大的那一塊 2:43–4:05

第二個技能是「把設計稿變成程式碼」——它受 AI 衝擊最深，現在多半只剩檢查 AI 的輸出。這件事以前佔前端工作的八成，如今幾乎消失，所以很多人以為前端沒了；但前端不是消失，是劇烈改變。主持人補充：以前團隊裡專門把版型貼成按鈕、改樣式的那種工作，本來就沒有累積性，現在五個人的活一個人配 AI 加 design systemi 就做完了。

推理因為要盤點技能，作者把 design into codei 拿出來當第一個被塗灰的格子：它的成功條件最明確——長得跟設計稿一樣就對了——所以 AI 做得好，人只剩檢查。他接著把結論拉回職涯：消失的是工作內容，不是職位。

• R白板上塗灰不是刪掉：灰色 = 仍要懂但不再是你的差異化；消失的是工作內容不是職位→ 存＋回想

AI 補充白板上的做法值得注意：他不是把格子刪掉，而是塗成灰色。灰色的意思是「仍然需要有人懂，但不再是你的差異化」。主持人補的那句「五個人的活變成一個人加 AI 加 design system」點出真正的變化是槓桿而不是消失——同一個人要能同時決定 design system 的規則、驅動 agent、再驗收產出。反過來說，如果一個人的履歷只由『照版型貼元件』組成，他和模型比的正好是模型最強的那一項。

5. 網站效能：被塗灰的技能 4:05–5:39

很多人說「做快的網站 AI 辦不到」，但只要目標明確——例如打到 Core Web Vitalsi——最新的模型做得相當好，甚至會提出架構層的建議，所以效能在白板上被塗成灰色。你仍然要懂瀏覽器與關鍵渲染路徑i，但那不再是競爭優勢；它的價值是併進 system design：讓你判斷這是設計問題還是最佳化問題。因為效能工作是 5% 診斷、90% 實作，而那 90% 正好是 AI 擅長的無聊活。

推理因為 Core Web Vitals 給了模型一個可量測的目標，所以作者說最新模型在這類任務上表現不錯，甚至會提出架構層建議，於是他當場把白板上的 Web Performance 塗成灰色。但他立刻補一個條件：你仍要懂，因為懂了才判斷得出這是設計問題還是最佳化問題。

• E效能工作：診斷佔 5%、實作佔 90%，被自動化的是那 90%——價值移到「報告出來前就說出這是架構問題」→ 存＋演練

AI 補充他給的比例是這段的重點：診斷佔 5%、實作佔 90%，而被自動化的正是那 90%。這代表效能知識的價值位置整個移動了——它從「你會不會壓縮圖片、會不會設快取」變成「你能不能在 Lighthousei 報告出來之前，就說出這個慢是架構造成的」。畫面上他把 Web Performance 從紅色改成灰色的那一刻，也順手示範了這張圖的讀法：彩色 = 你的差異化，灰色 = 你要懂但不再靠它勝出。

6. 自動化測試：規格給對，AI 就交得出來 5:39–7:01

測試是被自動化得最多的一塊，也被塗灰：只要你知道自己在做什麼、清楚需要的覆蓋率、懂一點測試金字塔i，你會快很多，Bogdan 說他現在做的東西測試覆蓋率i遠高於以前。面對「AI 寫的測試沒在測東西」的批評，他的回答是：你只需要給出測試的本質、指定要測什麼；那些無聊的苦工——造假資料、組裝元件——正好可以交出去。以前要十天的事現在是幾小時。

推理因為測試的判準同樣可以寫清楚——要測什麼、覆蓋率多少、測試金字塔怎麼分層——所以作者說只要你知道自己在做什麼，AI 會讓你快很多，他自己現在的專案覆蓋率比以前高。面對「AI 寫的測試在測空氣」的批評，他把責任放回規格：你要給出測試的本質，苦工才交出去。

• P把測試交給 AI 的前提是規格：指定要測什麼行為、覆蓋率、金字塔分層；驗收看它測行為還是測實作→ 練習
• RAI 在測試上的真正貢獻：把一件長年排不進時間的工作變得便宜到值得做，作者專案覆蓋率因此比以前高→ 存＋回想

AI 補充這裡有個容易被略過的轉折：他承認過去大家其實都沒怎麼寫測試——不是不會，是永遠排不進時間。所以 AI 在測試上的真正貢獻不是取代誰，而是把一件長年被砍掉的工作變得便宜到值得做。這也給了一個具體的驗收方式：與其爭論 AI 寫的測試好不好，不如檢查它有沒有測到你指定的行為，而不是測到實作細節。

7. code quality 之一：寫死的 CSS 值 7:01–8:20

程式碼品質是 LLM 最不擅長、除非你明講的一塊。第一個典型的 code smell 是寫死、沒有規範的 CSS 值：你丟一張截圖叫它做介面，它一開始會用你的 design system，例如 Tailwind，但為了滿足這個 prompt 就開始寫死數值，例如 28px 的字級。問題有兩個：不能自適應（該用 remi 這種相對單位），以及跟應用程式其他地方不一致——而一致性正是 text-2xl、3xl 這些原子 class 存在的理由：使用者看到一致的介面，認知負荷i才低。

推理因為要證明 LLM 在品質上的失手是有規律的，所以作者直接秀出一段自己用最新模型產出的元件程式碼，並標上「#1 Code Smell：Hardcoded Non Relative CSS values」。畫面上被紅框圈起來的正是 sm:text-[28px]——在一行本來用 text-2xl 的 Tailwind class 裡，突然插進一個寫死的像素值。

• Ccode smell：不一定是錯但預示設計問題的徵兆；AI 的失手有規律，認得出才能對抗過擬合→ 畫地圖
• E最新模型產出：一行 text-2xl 的 Tailwind class 裡突然插進 sm:text-[28px]→ 存＋演練
• R一致性不是潔癖：使用者的大腦在一致的介面上耗費較少，能把注意力留給真正在變的東西→ 存＋回想
• P掃一個 AI 產出的元件找寫死值：任何 [Npx]、hex 色碼、magic number 都換成設計代號→ 練習

AI 補充這個例子的說服力來自它的具體：同一個 className 字串裡，前半是設計系統的語彙（text-2xl），後半是模型為了滿足這次 prompt 硬塞的數字（28px）。兩個後果他都講了——不能隨裝置縮放，以及和其他頁面不一致；但第二個後果他往下推了一層很值得記住的推論：一致性之所以重要，是因為使用者的大腦在一致的介面上耗費較少，能把注意力留給真正在變的東西。也就是說，這不是潔癖，是認知負荷的問題。順帶一提，這張截圖右下角標了它出自哪個模型，作者刻意讓你知道這不是舊模型的老毛病。

術語:hardcoded valueiatomic CSS classi

8. code quality 之二：內嵌元件與重複 8:20–9:27

第二個問題是巢狀/內嵌元件i：那個 text 元件每次 render 都被重新建立，本該搬出去、必要時 memo 化或獨立成檔案再寫單元測試，AI 卻直接內嵌宣告——不能重用，於是到處都是重複的程式碼。因為 AI 面對小問題就地解決。有人問「那就叫它掃過整個 codebase 再實作啊」，但那要吃掉大量 context、超出視窗、結果更差又更貴——於是你就回到前端工程的本題：把共用功能抽成跨模組的 library，開始談模組，然後你就需要一個前端工程師。

推理因為那個 text 元件被宣告在 Spotlight 函式體內，所以每次 render 都會重新建立、而且無法被別處重用，於是重複程式碼開始增生。作者接著回應最直覺的反駁——「叫 AI 掃過整個 codebase 再實作不就好了」——用 context windowi 的限制擋回去：讀得越多越貴、結果越差。

• E元件定義在另一個元件函式體內：每次 render 產生新元件型別→子樹卸載重建、狀態丟失，不只是整潔問題→ 存＋演練
• Ccontext window：模型這一次能看到的世界；擴大視野的成本超線性，所以「叫它掃完整個 codebase」不成立→ 畫地圖
• P把該被重用的東西在架構上做成顯而易見：抽成模組間共享的 library，agent 不必讀完全世界也找得到→ 練習

AI 補充這個反駁與回應是全片最結構性的一段，值得慢讀：AI 之所以會重複造輪子，不是因為它笨，而是因為它的視野被 context 限制在你這次給它的東西裡。而擴大視野的成本是超線性的。於是問題自然被推回工程設計——把共用功能抽成模組間共享的 library，讓「該被重用的東西」在架構上就顯而易見，agent 不需要讀完全世界也能找到它。這正好繞回第二段的邊界：邊界不只是給人看的，也是給模型看的索引。要補一句作者跳過的：在 React 裡把元件定義在另一個元件內部，除了不能重用，還會讓每次 render 產生新的元件型別，導致子樹被卸載重建、內部狀態丟失——這是效能與正確性兩個層面的問題，不只是整潔問題。

術語:memoizationicode duplicationi

9. 兩端都要：高層架構 + 鑽到細節 9:27–10:20

怕被 AI 取代的話要做兩件事：談得了 system design，也能鑽到很低的層次去查清楚 codebase 是由什麼組成的。這同時是面試的解答——很多人被說「聽起來不夠資深」，就是因為只有其中一端。能同時掌握高層 system design 與瀏覽器、React 或 JavaScript 本身的細節，面試會過，工作產出會更高，也比別人更不需要擔心就業市場。重複性的前端工作會變少，但其他前端工作會變多。

推理因為前面已經證明 AI 在中間層（照規格產出）最強，所以作者的結論是往兩端走：一端是 system design，另一端是鑽進 codebase、瀏覽器、框架的細節。他順手指出這正是資深面試在測的東西——很多人被評為「聽起來不夠資深」，就是因為只有其中一端。

• R技能光譜：上端是架構取捨、下端是執行細節、中間是規格轉程式碼；AI 吃中間且越吃越寬，人往兩端走→ 存＋回想

AI 補充把技能光譜想成一條線會比較清楚：最上面是架構取捨，最下面是執行細節，中間是把規格轉成程式碼。AI 現在吃掉的是中間那段，而且會越吃越寬。只有上端的人講得出漂亮的架構卻驗收不了產出；只有下端的人能挑出 28px 卻說不出模組該怎麼切。作者說這兩端合起來會讓你在面試與市場上都更安全，理由是一樣的：面試官問的正是那些沒有標準答案、需要你解釋取捨的問題。

10. 放著不管的代價：8.9% 重複、153 個死檔案 10:20–10:59

他們拿自家系統做靜態分析i：9% 的程式碼完全重複——不是功能相似，是一模一樣——加上 153 個沒有被用到的檔案。這對管理 context 極糟，也會讓 AI 給出更差的結果。放任 agent 無人看管、不檢查程式碼品質，你會得到一個外表符合期待、底下卻是技術債i大山的應用；想改一點點，整個就可能垮掉。

推理因為抽象的 code smell 說服力有限，所以作者秀出自家系統的掃描結果：Dead Codei 區塊 153 個未使用檔案、220 個未使用匯出，總計 413 個問題；Duplication 區塊 9,760 行重複、重複率 8.9%。他強調那是靜態分析，代表這些片段一模一樣，不是功能相似而已。

• Ctechnical debt：外表能跑、分數不差，債仍在底下堆——dead code 污染 context、duplication 污染改動成本→ 畫地圖
• E作者自家掃描：153 個未使用檔案、220 個未使用匯出、9,760 行重複（8.9%）；可維護性 89.7 卻標 good→ 存＋演練

AI 補充這份報告值得注意的是它的分類方式：dead code 與 duplication 是兩種不同的病。死程式碼是「沒人用卻還在」，它污染的是 context——你和 agent 都要花力氣分辨哪些檔案還算數；重複是「同一件事被寫了很多遍」，它污染的是改動成本。畫面下方還有一項健康度指標顯示 4,780 個函式裡有 367 個超過複雜度門檻，平均可維護性 89.7 分被標成 good——也就是說，整體分數好看，問題卻集中在特定幾百個地方。這正好呼應作者的主張：外表能跑、分數不差，技術債仍然在底下堆著。

11. 無障礙：定義清楚，所以大多能自動化 10:59–12:07

無障礙不會消失，但它定義得很清楚，所以能交代給 agent：優先用語意 HTML；真的必須用一堆 div 時，用 ariai 標出角色；再確認 tab index 的順序和畫面上的順序一致——主要就這些。而且它是非功能需求i，商業上會被推著「做完就好」。以前要辦兩週的無障礙衝刺，現在做平台、做全公司 design system 的人先把它做對，AI 就從那裡學，你只要輕量檢查。

推理因為無障礙的規則定義得很清楚，所以作者說可以直接指示 agent：優先用語意 HTML；真的得用一堆 div 時用 aria 標出角色；再確認 tab 順序和畫面順序一致。他同時點出它是非功能需求，商業上總被推著趕快做完，所以自動化的誘因特別大。

• P無障礙交給 agent 的三條指令：優先語意 HTML→不得已才 aria 標角色→確認 tab 順序與畫面一致→ 練習
• R無障礙是 non-functional requirement，商業上總被推著趕快做完，所以自動化誘因特別大；品質要內建在來源→ 存＋回想

AI 補充他描述的順序其實就是可及性的優先級：能用原生語意元素就別自己造。用 button 而不是加了 onClick 的 div，鍵盤操作、焦點、螢幕閱讀器的角色都免費拿到；aria 是補救，不是首選——標錯角色比不標更糟。他提到的第三點最容易被忽略：tab 順序取決於 DOM 順序，而 CSS 可以把視覺順序改掉，於是畫面上明明在上面的按鈕，鍵盤卻最後才走到。他說以前要辦兩週的無障礙衝刺，現在由做 design system 的人先做對、AI 從那裡學——這是把品質內建到來源，而不是事後補救。

術語:semantic HTMLitab orderi

12. state 與資料：收斂成 essential state 12:07–13:44

最後一個技能是狀態與資料：看著一個介面就能判斷用什麼資料結構去模擬它，把一切收斂成必要狀態i。用 AI 的話，local statei 會到處都是而且大量冗餘，因為元件是各自孤立生出來的；沒有溝通、不懂架構，同一份後端資料會在兩個地方各取一次，變成兩個請求。設計過的應用裡狀態是有秩序的：不要多餘狀態、不要衍生狀態i，愈小愈好。他用畢卡索的公牛比喻——從細節滿滿畫到最簡的線條——再加上單一寫入原則：每份資料在系統裡只存一次。

推理因為元件是被孤立地生出來的，所以用 AI 的專案會到處都是 local state，同一份後端資料在兩個地方各取一次、變成兩個請求。作者主張的能力是：看著一個介面就判斷得出用什麼資料結構模擬它，把狀態收斂到最小——不要多餘狀態、不要衍生狀態——並用畢卡索畫公牛的系列版畫當比喻，最後配上單一真相來源i原則。

• Cessential state：不能再少的那組資料，其他畫面上的東西都能從它算出來；AI 孤立生元件會到處長 local state→ 畫地圖
• A畢卡索《公牛》系列：從寫實一步步簡化到幾條線仍認得出——essential state 是找出不能再少的那組線→ 批判類比
• P對每個 state 問「能不能由別的 state 推導」，能就刪掉改成計算；同一份後端資料只取一次→ 練習

AI 補充畫面上那張圖是畢卡索的《公牛》石版畫系列：從細節完整的寫實公牛，一步步簡化到只剩幾條線仍然認得出是公牛。這裡要說的不是「越少越好」，而是「找出不能再少的那組線」——essential state 的意思正是：其他所有畫面上的東西，都能從它算出來。實務上的檢查很簡單：對每一個 state，問它能不能由別的 state 推導出來；能，就刪掉它、改成計算。旁邊那句 Single Source of Truth 是同一件事的另一面：同一份資料在系統裡只存一次，兩份就一定會有不同步的那一天。字幕把 bull 誤寫成 ball，看畫面就知道是公牛，不是球。

13. 從哪裡開始：看你的產品環境 13:44–15:15

主持人問：三個技能都知道了，該從哪開始？答案取決於你在做的系統——有微前端、有規模的，投資 system design；只負責功能、不掌管大塊系統的，就往細節走：狀態、資料、程式碼品質。做法是每次和 agent 做完事就打開 pull requesti，做真正的 code reviewi，不是 AI review，而是親眼看機器產出的程式碼。他用工廠烤蛋糕比喻：唯一知道好不好吃的方法就是自己去嘗一口。

推理因為起點取決於你能影響的範圍，所以作者的建議是照系統型態分流：碰得到微前端與規模的人投資 system design；只負責功能的人往細節走——狀態、資料、程式碼品質。做法很具體：每次和 agent 做完事，打開 pull request 做真正的 code review，親眼看機器產出的程式碼。

• A工廠烤蛋糕：產量暴增時你不可能每個都吃，但必須真的抽樣嘗過——每次 agent 做完就開 PR 真的 review→ 批判類比

AI 補充那個工廠烤蛋糕的比喻其實是在回答一個很現實的問題：在 AI 產出量暴增的情況下，人要把有限的注意力放哪裡？他的答案是放在輸出的抽樣檢查上——你不可能讀完每一行，但你必須真的嘗過。把這件事接回整支影片：第二段的邊界、第七與第八段的 code smell、第十段的靜態分析，全部都是為了讓這個抽樣檢查變得可行——邊界讓你知道該看哪裡，氣味讓你知道要看什麼，掃描工具讓你知道漏了多少。