最近在技術(shù)社區(qū)刷到 Yuchen Jin 關(guān)于 AGI 的那番討論說實話第一反應(yīng)是松了口氣。大家都在喊 AI 要接管一切的時候有人站出來說該做的活一樣都跑不掉這話聽著就踏實。他的觀點其實不復(fù)雜AGI 很強但它到來之后前端頁面還是得有人去調(diào)樣式幻燈片還是得親自排版稅表到點還是得自己填。很多人把這句話理解成AI 不行我覺得恰恰相反——正是因為 AI 變得足夠強一個人能借助它完成的事情邊界大大擴展了那些真正需要親自動手的環(huán)節(jié)反而成了決定產(chǎn)出質(zhì)量的關(guān)鍵。作為一個常年泡在前端領(lǐng)域、經(jīng)歷過各種框架更迭和工具革命的從業(yè)者我對這個判斷特別有共鳴。尤其最近幾年AI 編程助手已經(jīng)深度嵌入了日常工作流但你會發(fā)現(xiàn)一個很有意思的現(xiàn)象能用好 AI 的人往往是那些原本基本功就扎實的人。AI 可以幫你生成一百行代碼但你得知道哪一百行是對的AI 能幫你排出一版幻燈片但你可能得自己理清楚邏輯主線之后才知道讓它怎么排。這篇文章我想從 Yuchen Jin 這句話出發(fā)結(jié)合我自己在真實項目里摸爬滾打的經(jīng)驗聊聊 AGI 時代里前端這個行當?shù)恼鎸嵦幘骋约澳切┻€得自己做的事到底教會了我們什么。1. AGI 再強會做和能判斷終究是兩碼事先說一個最扎心的事實很多人對 AGI 的期待是我不用學了它什么都會。但實際操作中你會發(fā)現(xiàn)當 AI 給出的結(jié)果你不具備判斷力的時候局面反而更糟糕。就像標題里說的報稅這種事AI 完全可以幫你算出應(yīng)該填多少、怎么抵扣最優(yōu)但問題在于——稅表上的數(shù)字最終簽字的是你數(shù)據(jù)填錯了責任也是你的。這時候如果你連基本的稅收邏輯都不懂AI 給你一個看起來專業(yè)的結(jié)果你敢直接提交嗎1.1 判斷力才是 AI 時代的稀缺品我在團隊里帶過不少新人也面試過幾百個前端候選人一個很明顯的趨勢是隨著 AI 工具越來越順手候選人寫代碼的速度確實變快了但代碼的質(zhì)量和穩(wěn)定性并沒有同步提升。因為代碼生成之后要跑起來、要維護、要處理邊界情況這些環(huán)節(jié)沒法靠提示詞解決你得靠對人腦對系統(tǒng)運行機制的理解去定位問題。比如前陣子我們項目遇到一個性能問題一個數(shù)據(jù)列表在渲染時偶發(fā)卡頓肉眼看著不規(guī)律很難復(fù)現(xiàn)。當時的排查路徑是先懷疑數(shù)據(jù)結(jié)構(gòu)又懷疑網(wǎng)絡(luò)請求折騰一圈之后發(fā)現(xiàn)是某個 JSON 字符串化相關(guān)的操作在數(shù)據(jù)量大時觸發(fā)了嚴重的性能瓶頸。這個問題的根源涉及運行時內(nèi)存分配、瀏覽器垃圾回收機制、大數(shù)據(jù)量下的渲染策略等等如果你對這些底層原理沒有概念你會連排查方向都找不到。AI 此時能幫你優(yōu)化某一段具體代碼但該懷疑哪里、往哪個方向查這個決策過程真的只能靠自己的技術(shù)積累。1.2 前端業(yè)務(wù)的不可言說部分再往深了說前端這個工種本身就有大量不可言說的成分。需求文檔里寫著按鈕要更醒目一點你覺得把字體加大加粗就行但產(chǎn)品經(jīng)理的真實意圖可能是想把按鈕放在一個視覺錨點上讓它形成用戶的操作習慣。這種只可意會的需求AI 是讀不出來的。它沒法在評審會上替你跟產(chǎn)品經(jīng)理來回掰扯也沒法感知這個交互在這個業(yè)務(wù)場景下用戶會覺得順手還是別扭。AI 能解決的是怎么實現(xiàn)的問題而前端工作中真正值錢的部分是該實現(xiàn)什么和這么做合不合適。所以每當看到熱搜里反復(fù)出現(xiàn)前端八股文前端面試題 2026這類關(guān)鍵詞時我反而覺得這是一件好事。它說明行業(yè)依然在用一套相對嚴格的標準篩選人而不是靠會不會用 AI 工具來定勝負。八股文背后考察的計算機基礎(chǔ)、網(wǎng)絡(luò)原理、數(shù)據(jù)結(jié)構(gòu)本質(zhì)上都是在訓練一個人的系統(tǒng)判斷力。2. AI 能寫代碼了前端工程師的價值反而更重了有個觀點最近挺流行AGI 都來了初級前端的活肯定要被替代。這個說法有一定道理但替代的其實是代碼翻譯這個環(huán)節(jié)——把設(shè)計稿變成 HTML/CSS、把接口文檔變成邏輯調(diào)用。這些工作 AI 確實干得不錯。但整個前端交付鏈條里翻譯只是最末端的一環(huán)前面還有需求梳理、信息架構(gòu)、交互設(shè)計、技術(shù)選型、性能預(yù)算、異常兜底后面還有監(jiān)控反饋、迭代優(yōu)化、技術(shù)債治理。這些環(huán)節(jié)不僅沒被替代反而因為 AI 拉高了單個環(huán)節(jié)的效率倒逼從業(yè)者把精力放在更上游的思考上。2.1 一個真實的開發(fā)場景AI 生成代碼之后的爛攤子拿我們最近做的一個后臺管理系統(tǒng)舉例吧。有同事圖省事直接把一個包含復(fù)雜表單校驗和數(shù)據(jù)聯(lián)動邏輯的需求丟給 AI 生成表面上代碼能跑點兩下好像也沒啥問題。但等到了聯(lián)調(diào)階段問題開始集中爆發(fā)表單校驗的時序不對、某些極端輸入沒處理、接口異常時沒有統(tǒng)一攔截、部分瀏覽器版本直接報錯。最終這些代碼還是要人工重寫。AI 生成的代碼就像一份看著沒病的體檢報告但你要真想讓它穩(wěn)定運行在生產(chǎn)環(huán)境還是得靠工程師逐行審查邊界、理解業(yè)務(wù)。這個案例給我的觸動挺大的。它說明了一個道理AI 降低了某些操作的下限但絲毫沒有降低交付標準的下限。你總不能跟用戶說這個頁面在有網(wǎng)絡(luò)問題時可能會白屏因為 AI 沒考慮到對吧所以實際工作中我反而越來越強調(diào) team 里成員的代碼審查能力——你能不能在 AI 給出的方案基礎(chǔ)上補全異常分支、識別潛在風險、調(diào)整更合理的結(jié)構(gòu)。這種能力說實話 AI 很難學走因為它來自對真實業(yè)務(wù)場景的理解和大量實戰(zhàn)經(jīng)驗的沉淀。2.2 能寫到寫好之間隔著一條經(jīng)驗河具體到前端開發(fā)的技能點比如 JSON.stringify 的性能優(yōu)化。很多剛?cè)腴T的朋友知道這個方法能把對象轉(zhuǎn)成字符串但不知道在數(shù)據(jù)量上去之后它會變成性能瓶頸。我之前在優(yōu)化一個實時大盤頁面時數(shù)據(jù)源每秒鐘推送幾十條更新其中有一個字段是嵌套了三層的對象序列化和反序列化的開銷直接讓頁面掉幀。如果當時只是盲目上 Worker 處理大文件上傳、或者用 otherside 的花哨技術(shù)都解決不了問題——關(guān)鍵就是定位到了這個序列化點然后通過數(shù)據(jù)扁平化、增量更新和緩存策略把單次更新的耗時從幾十毫秒降到了個位數(shù)。這種定位問題的過程AI 可以輔助你排查但它沒有辦法替你做決定的。你會發(fā)現(xiàn)熱詞里signalR 前端應(yīng)該怎么獲取數(shù)據(jù)前端 websocket 怎么用這類搜索量一直都很大背后其實都是同一個訴求在面對真實、復(fù)雜的實時數(shù)據(jù)場景時工程師需要自己判斷該選什么方案、怎么做數(shù)據(jù)流設(shè)計。AI 能給你標準的連接代碼但用 SignalR 還是 WebSocket、重連策略怎么設(shè)計、消息格式怎么定、前端的狀態(tài)怎么同步這些決策必須由了解業(yè)務(wù)痛點和系統(tǒng)瓶頸的人來做。2.3 前端面試也在變化AI 考不出來的是解決問題的過程2026 年的前端面試題明顯變得更有意思了區(qū)別于前幾年那種純粹死記硬背的題現(xiàn)在面試官更傾向給一個線上頁面卡頓請你判斷可能原因這類開放式問題。這種題沒有標準答案考察的就是排查鏈路是否清晰、有沒有自己的調(diào)試方法論。相比之下記憶某個 API 的參數(shù)列表反而是最不重要的——因為這類知識 AI 隨時可以告訴你面試官真正想確認的是你這個人值不值得培養(yǎng)遇到問題時的第一反應(yīng)是打開百度搜一下還是從內(nèi)存、網(wǎng)絡(luò)、渲染路徑幾個維度逐一排除。我在帶人時也明顯感覺到給新人一個問題清單讓他們用 AI 輔助排查具體的線上 bug他們能很快給出結(jié)論但如果追問一句為什么你會優(yōu)先檢查這個環(huán)節(jié)很多人的思路就開始亂了。這種從知道怎么做到知道為什么這么做之間的差距就是資深前端和初級前端的分水嶺。而這份差距AI 暫時彌補不了。3. 幻燈片和報稅背后的共同邏輯結(jié)構(gòu)化思維無法外包文章標題里提到的幻燈片和報稅看起來和前端八竿子打不著但琢磨久了你會發(fā)現(xiàn)它們折射出的其實是同一個能力——結(jié)構(gòu)化思維。做幻燈片不是把文字往幻燈片里一扔就完事而是要在有限的空間里組織信息層級讓聽眾順著你的思路走報稅也不是照著表格亂填而是要理解各種收入類型、扣除項、以及政策的適用范圍本質(zhì)上是把復(fù)雜的規(guī)則梳理成一套適用于自己情況的映射關(guān)系。這種邏輯梳理和抽象的能力才是最核心的人類技能。3.1 不會做幻燈片的人給 AI 一百個提示詞也沒用我見過太多人聲稱用 AI 做幻燈片很快但你問他做出來的東西為什么長這樣、邏輯主線是什么、每一頁之間的遞進關(guān)系是什么他完全答不上來。因為他只是在套一個模板往里填內(nèi)容內(nèi)容之間的邏輯聯(lián)系是斷裂的。AI 可以根據(jù)你的關(guān)鍵詞生成一頁頁花哨的排版但它不知道這頁三年規(guī)劃里最重要的轉(zhuǎn)折點是你想強調(diào)的AI 基建成本下降還是團隊重心轉(zhuǎn)向業(yè)務(wù)側(cè)。這種對表達重心的判斷來源于你對自己工作和目標的深度理解這個理解不能外包。3.2 報稅背后的合規(guī)意識本質(zhì)上也是一種前端思維報稅這個例子有點專業(yè)但其實很容易理解。你打開稅務(wù)系統(tǒng)會發(fā)現(xiàn)它同樣是一套巨大的信息輸入和狀態(tài)管理界面你得保證自己提交的數(shù)據(jù)和實際情況一致得了解不同收入類別對應(yīng)的稅率計算方式。如果只看 AI 輸出的一串數(shù)字你可能永遠無法理解為什么我的年終獎要單獨計稅為什么這筆稿費收入扣的稅和工資不一樣。這些細節(jié)恰恰決定了你能不能合理合法地優(yōu)化稅務(wù)成本。這跟前端開發(fā)里的狀態(tài)管理特別像。頁面下拉框選了一個值后續(xù)展示的字段要聯(lián)動變化某些操作必須有權(quán)限才能執(zhí)行這些本質(zhì)上都是狀態(tài)驅(qū)動的界面邏輯。一個優(yōu)秀的前端工程師本質(zhì)上就是一個狀態(tài)管理大師他懂得如何讓系統(tǒng)的每個狀態(tài)都符合預(yù)期、符合業(yè)務(wù)規(guī)則并且處理好各種狀態(tài)間的轉(zhuǎn)換和邊界。報稅算下來無非是把自己的財務(wù)狀態(tài)映射到一套國家規(guī)定的狀態(tài)機里一表填錯后續(xù)全亂。3.3 底層能力遷移把復(fù)雜系統(tǒng)拆成可執(zhí)行步驟不管是寫代碼、做幻燈片還是報稅底層都離不開把復(fù)雜系統(tǒng)拆解成小步驟的能力。前端開發(fā)里一個大型后臺項目要拆成模塊、組件、狀態(tài)、接口層做幻燈片時要把一個宏大的主題拆成章節(jié)、頁面、要點報稅時要按收入的類別、時間、來源去分門別類。這套拆解能力才是 AGI 怎么發(fā)展都難以完全替代的核心素養(yǎng)。AI 可以把一個已拆好的問題執(zhí)行得很好但它不擅長幫你定義這個問題該拆成哪些維度。這也是為什么許多公司招聘資深前端時越來越看重候選人有沒有業(yè)務(wù)理解能力。你不光要知道 React 的生命周期或者 Vue 的響應(yīng)式原理你還要能聽懂業(yè)務(wù)方講的一個模糊的訴求然后把它拆成清晰的技術(shù)方案再逐步落地。AI 時代從模糊需求到清晰方案之間的鴻溝依然需要人來跨越。4. 當 AI 成了標配2026 年的前端該拼什么既然 AI 無法避免地進入每個開發(fā)者的日常與其焦慮AI 會不會替代前端不如思考AI 時代的資深前端應(yīng)該具備哪些不可替代的競爭力。我結(jié)合自己帶團隊和做技術(shù)服務(wù)的經(jīng)驗分享幾個我認為越來越重要的方向。4.1 代碼審查能力被嚴重低估AI 生成的代碼最大問題不是跑不通而是表面能跑但經(jīng)不起推敲。我接手過不少 AI 生成的項目代碼常見的毛病包括把不該暴露的接口寫進前端邏輯、錯誤處理泛濫但沒針對性、狀態(tài)更新方式不統(tǒng)一導(dǎo)致競態(tài)、組件粒度混亂增加維護成本。這些問題不像語法錯誤那樣一眼可見需要有經(jīng)驗的工程師在多一次的評審中識別出來。所以我特別建議有上進心的前端開發(fā)者在日常工作中刻意練習代碼審查——不光是看自己 team 的代碼也可以去翻翻知名的開源項目思考別人為什么會用這種寫法優(yōu)點在哪風險在哪。這種能力積累到一定程度你看一眼 AI 生成代碼的結(jié)構(gòu)就能大概判斷出它有沒有走偏。這種直覺不是天生的全靠常年和真實代碼打交道的經(jīng)驗堆出來。4.2 調(diào)試能力AI 時代的偵探學前面提到過內(nèi)存泄漏排查和大批量序列化性能瓶頸這些都是調(diào)試問題的典型場景。我把調(diào)試能力叫作偵探學因為它本質(zhì)上是一個歸納、假設(shè)、驗證的過程觀察現(xiàn)象、收集數(shù)據(jù)、形成假設(shè)、設(shè)計實驗、確定根因。AI 可以幫你分析一段代碼的復(fù)雜度但沒法幫你判斷用戶反饋頁面卡頓是網(wǎng)絡(luò)慢、渲染慢、還是內(nèi)存泄漏這種開放問題。開放問題的解決路徑不唯一也沒有萬能藥需要你基于系統(tǒng)架構(gòu)和用戶反饋去搭建一個合理的排查框架。對于想提升調(diào)試能力的朋友我的建議是不要只盯著自己寫的頁面多去處理一些別人寫的爛代碼和年代久遠的歷史項目。那些代碼里充斥著各種詭異的使用方式和未文檔化的外部依賴調(diào)試它們才能真正鍛煉出從蛛絲馬跡里找到根源的能力。4.3 全鏈路性能優(yōu)化從 JSON.stringify 到 Worker 上傳標題提到前端、幻燈片和報稅還得自己做我猜很多人會忽略前端這兩個字其實包含了一個非常龐大的知識體系。就拿性能和交互體驗來說真實項目里的復(fù)雜度遠超教科書。前面講到的 JSON.stringify 性能優(yōu)化只是冰山一角。再比如大文件上傳傳統(tǒng)方案是直接塞進 FormData 一把梭但到了幾 GB 的文件這條路就堵死了。現(xiàn)在標準的做法是采用分片上傳加 Web Worker 做后臺計算避免阻塞 UI 線程同時還要處理網(wǎng)絡(luò)中斷后的斷點續(xù)傳、服務(wù)端的即時校驗、以及并發(fā)上傳的分片調(diào)度。這些步驟AI 可以給你提供每一段的代碼樣板但整個方案的技術(shù)選型、架構(gòu)設(shè)計和兼容性考量還是得靠人來做。我記得有次做視頻資產(chǎn)管理系統(tǒng)用戶要上傳幾十個 G 的拍攝素材前端如果處理不好頁面直接崩潰。當時我先是評估了主線程的性能影響決定引入 Web Worker 來處理文件的讀取、分片和哈希計算然后又設(shè)計了并發(fā)數(shù)為 3 的上傳隊列避免網(wǎng)絡(luò)擁塞再通過服務(wù)端的秒傳校驗讓用戶重復(fù)上傳時幾乎不用等待。這一整套鏈路下來AI 只是幫我們把一些常用的工具函數(shù)寫好了核心的架構(gòu)設(shè)計、異常處理、以及和產(chǎn)品經(jīng)理對需求的調(diào)整都是靠團隊內(nèi)部的討論定下來的。你說這些經(jīng)驗值錢嗎非常值錢。4.4 學會當 AI 的老板而不是同事最后聊一個比較抽象但很重要的能力——如何支配 AI。大部分人的默認做法是直接拋一個任務(wù)給 AI幫我寫一個登錄頁AI 吐出來一個能用但平庸的結(jié)果。更好的姿勢是把 AI 當成一個執(zhí)行者而你更像一個產(chǎn)品經(jīng)理兼技術(shù)負責人你先拆好需求結(jié)構(gòu)、定好技術(shù)邊界、列清楚約束條件再讓 AI 按你的框架去生成細節(jié)代碼。比如幫我實現(xiàn)一個基于 React 的表單驗證組件字段包含用戶名和郵箱驗證規(guī)則包括必填和格式校驗錯誤提示要內(nèi)聯(lián)展示且提交按鈕在驗證失敗時不可點擊。請先輸出組件結(jié)構(gòu)再輸出核心邏輯。你會發(fā)現(xiàn)當你把邊界畫得越清晰AI 生成的結(jié)果就越貼近你的預(yù)期。如果生成得不對你還能基于自己對狀態(tài)管理的理解去糾正它。這種能力本質(zhì)上還是來自扎實的前端基本功。5. 我的日常工作流AI 負責初稿我負責定稿最后結(jié)合個人實操分享一些我在項目里實際沉淀下來的工作方法。我覺得這是對AGI 到來后生活依舊最直接的一種回應(yīng)——AI 當然會全面滲透到我的日常但我自己的認知框架和工作習慣反而變得更加重要了。5.1 用 AI 輔助需求分析和方案設(shè)計我現(xiàn)在接到一個前端需求第一件事不是打開編輯器而是先在文檔工具里把需求拆解成幾個核心問題這個功能的目標用戶是誰使用路徑是什么核心指標是什么在這些問題沒有清晰答案之前我不會讓 AI 寫任何代碼而是讓它作為外腦幫我把可能的技術(shù)方案列出來甚至讓 AI 扮演產(chǎn)品經(jīng)理來挑毛病。在這個過程中AI 最大的價值不是給我答案而是通過對話幫我把腦海中模糊的想法逐漸具象化。但怎么判斷 AI 給的方案是不是最優(yōu)框架搭得合不合理依然靠自己的經(jīng)驗。5.2 代碼實現(xiàn)階段AI 給了我更多時間做 Code Review寫代碼的環(huán)節(jié)AI 確實幫我節(jié)省了大量敲鍵盤的時間。過去實現(xiàn)一個完整的 CRUD 頁面可能需要寫很多重復(fù)的表格、表單和彈窗代碼現(xiàn)在我可以直接讓 AI 按我的要求生成頁面骨架再手動調(diào)整交互細節(jié)。省下來的時間我會用來做什么第一做更細致的代碼審查把潛在的性能隱患和狀態(tài)管理缺陷扼殺在代碼提交之前第二和產(chǎn)品、后端同學深入溝通提前識別接口定義和數(shù)據(jù)結(jié)構(gòu)的坑第三寫自動化測試把核心業(yè)務(wù)路徑的穩(wěn)定性兜住。我舉一個具體的例子。前陣子接了一個報表中心的需求涉及大量的動態(tài)列、多選篩選、排序、分頁和導(dǎo)出。這種項目如果全人工敲至少要一周多但借助 AI 生成基礎(chǔ)組件和頁面我兩天就把第一版搭了出來。剩下的時間全部花在和業(yè)務(wù)方確認數(shù)據(jù)口徑、調(diào)整篩選邏輯、以及把導(dǎo)出功能在大數(shù)據(jù)量場景下做性能驗證上。最終交付時頁面的穩(wěn)定性和可擴展性都遠超以往這就是合理地把 AI 當成效率杠桿帶來的成效。5.3 但責任和兜底依然只能自己承擔分享這么多我想強調(diào)的是AI 可以接管執(zhí)行但它無法接管責任。頁面線上出了 bug用戶不會說這是 AI 寫的有問題他只會覺得你們團隊的工程質(zhì)量不過關(guān)。報稅填錯了稅務(wù)部門也不會因為是 AI 幫我報的就網(wǎng)開一面。做幻燈片邏輯混亂聽眾也不會因為這頁是 AI 生成的就更容易理解。一切交付最終指向的還是你這個人——你的專業(yè)判斷、你的經(jīng)驗沉淀、你的責任意識。前端行業(yè)恰恰是最能體會到這種責任的地方你寫下的每一行代碼都要對真實的用戶行為負責你做的每一個交互決策都會影響千萬次點擊背后的使用感受。AGI 的到來讓工具的邊界拓寬了但沒有改變你要對自己產(chǎn)出的東西負責這個底層事實。5.4 給前端開發(fā)者的一條實在建議如果你現(xiàn)在正處于職業(yè)早期或者正在為 2026 年的面試做準備我把多年的經(jīng)驗濃縮成一句話把 AI 當成你的加速器但永遠不要當成你的外掛大腦。多花時間鉆研底層原理親手解決幾個棘手的線上問題踏踏實實把幾個復(fù)雜功能做深做透這些笨功夫在任何時代都值錢。面試官和項目負責人看重的從來不是你會多少工具而是你面對未知問題時能不能扛得住、拆得開、解決得掉。回到 Yuchen Jin 那句話AGI 到來后生活依舊——這句話聽起來像是一種樂觀的躺平但在我看來它其實是對人類自身能力的一種重要肯定。技術(shù)再怎么演進前端工程師、內(nèi)容創(chuàng)作者、每一個普通個體所具備的判斷力、責任心和創(chuàng)造力依然是我們在這個世界上立足的根本。別焦慮 AGI 會帶走什么先把手頭該做的事一件一件做好。寫前端也好做幻燈片也好報稅也好每一件自己親手做完的事最后都會長成你身上別人搶不走的那部分能力。