前端生產方式：過去 10 年回顧和未來 10 年展望

前言

在寫這篇文章之前，我一直在思考該用什麼的方式能講清楚前端爲什麼要向智能化方向切換的理由，真的反覆思考很久，後來決定還是以我做前端的過去 10 年的所見所聞來做個解答吧，這樣讓大家也都更有些體感。

“我自己是一名從事了6年web前端開發的老程序員（我的微信：web-xxq），今年年初我花了一個月整理了一份最適合2019年自學的web前端全套培訓教程（視頻+源碼+筆記+項目實戰），從最基礎的HTML+CSS+JS到移動端HTML5以及各種框架和新技術都有整理，打包給每一位前端小夥伴，這裏是前端學習者聚集地，歡迎初學和進階中的小夥伴（所有前端教程關注我的微信公衆號：web前端學習圈，關注後回覆“2020”即可領取）。

起源

這段是我跟前端的結緣，想必很多人也跟我一樣，懵懵懂懂地就撞入了前端這個行業。

一腳入坑

 

我接觸前端，那還是 2010 年的時候，在那個時候最火的是 網絡三劍客 —— Adobe Dreamweaver、Adobe Flash、Adobe Fireworks。

這三款軟件都很熱門，第一款可以通過可視化編輯器拖拖拽拽、填填配配就可以搞定一張網頁，雖然上手起來概念衆多、也挺難用的，但至少是那個時代做網頁最牛逼的軟件了；

第二款是做 Flash 的，配備一門 ActionScript 的語言，當時網上下載了不少大牛做的很極客的 Flash 網站源碼，不過代碼讀起來很吃力；

第三款是做海報的（因爲海報圖比較大、比較長，切割起來比較耗費內存，這款軟件速度比較快）和 Gif 動畫的，但我用的少，大部分時間都用 Photoshop CS4 來搞定。

雖說這三款軟件最火，但真正讓我入坑前端（那個時候還沒有“前端”這個稱呼，有的就是“切圖仔”）的理由，是因爲我想當一位網頁設計師。

當時，想當一位網頁設計師的理由有二：

1. 軟件工程搞 Java、C++、C 真是挺枯燥無聊的，寫一段程序，還得編譯、部署，等上個兩三分鐘的，特別無語；而當初接觸 Web 頁面開發時（當時還是一位外教授課），發現網頁這東西很神奇，在一個 Text 文本編輯器裏敲上幾行代碼，改個擴展名，雙擊頁面就展示出來了，這種所見即所得的美的視覺衝擊力，當時讓我向這個方向上蠢蠢欲動，埋下了禍根😄。

2. 在教育網慶幸地就是可以翻牆看了不少國外的網站，當時最大的感受就是美觀、大氣、留白充足，而國內的網頁哪裏是網頁，UI 的設計簡直齪的不要不要的，沒什麼美感，全是一堆文字 和 框，外加一堆閃來閃去的 gif（比如那個 “New”）堆砌，尤其是教育網的官網，那醜的簡直不要不要的了。再加上當時的 QQ 空間很火，可以 DIY 自己的空間，但還是感覺不大氣，所以當時就想着自己做出一款比較高端大氣上檔次的網頁😄。

大學期間，雖然自己學設計做網頁這個想法被身邊同學嘲笑說這應該是專科同學纔去搞的東西，但的確還是堅持下來了。平時自己除了讀專業課程和完成課程實踐以外，就是在寢室、在圖書館、在選修課、實驗室裏抱着一堆影樓的 P 圖視頻寶典和一本影印版的厚厚的設計資料度過的。當時自學了 Photoshop ，也學會了設計中的三原色原理，並應用在班級日常校園種海報設計、照片美化等工作上，如今拿着單反拍個照 P 個圖的本領也都那個時候積累下來的。

再然後就是在校園裏找了個實驗室的項目，跟一夥人做一個外賣網站，自己擔任網頁的開發部分。老實說那個時候對方都不信任我能搞定網頁開發，畢竟我還是初級的小白。所以自己那個時候啃 W3C，在網上邊學邊做，雖然當時有個不錯的 jQuery 的框架，但自己還是純手工用 HTML4、CSS、Javascript 擼出了級聯地域菜單選擇器，而且 UI 也是自己設計的，頓時信心感爆棚，所以一發不可收拾的一個項目一個項目地走向了網頁開發或者叫切圖仔這個行業。

這大概就是我與前端埋下的不解之緣吧，算是一腳踏入了前端這個行業。

兩腳入坑

而要說真正接觸“前端”這 2 個字的時候，那還是在面試淘寶時面試官向我提起的。雖然當時還是聽不懂前端到底是幹嘛的，但一聽面試官說能跟設計師一起工作，而且未來想做設計師也可以內轉，我就沒有再半點猶豫，當時一天就搞定了所有面試流程，簽下了淘寶前端開發工程師的 Offer ，從此就兩腳都踏入了前端這個行業了😂。

 

 

回顧：前端發展的黃金 10 年（淺水區）

當你真正從校園出來，沉浸於工作之後，就會發現時間過得速度遠比你在學校裏快了不止一倍，每時每刻都覺得時間不夠用、業務完全做不完，感覺自己的時間都給了工作，我過去也在反思這個原因到底是什麼，後來也漸漸想明白，這種快本身與互聯網的發展相輔相成的，從 2G 到 3G，再到 4G，以及接下來的 5G、6G……，正因爲互聯網大潮的發展，以及我們這些推潮者的存在，我們的時間變快也就變得正常了。我知道很多人不理解，但在這個圈子裏的人都會理解或有同樣的聲音存在。就比如以前端發展的這 10 年爲例，你就會深有體會了。

以下就是詳細介紹前端發展的這黃金 10年，有興趣的讀者可以細讀，沒有興趣的可以通過這點概述繞過：前端在最初，僅僅是爲了完成一張網頁的開發，到後來，要能在同時完成 5 張、10 張甚至更多張頁面的開發，對前端的挑戰變大，所以前端作業內容從單純的網頁開發，拆分成模塊式開發，拆分到前後端分離，過渡到可視化搭建系統等等，職能範圍也從網頁開發逐漸過渡到後端開發、全棧開發，領域範圍也從網頁開發細分到 PC 端開發、移動端開發、遊戲/互動開發、Nodejs 開發、架構工程開發等，工程內容也從一段 jQuery 代碼就搞定的階段發展到前端也需要構建、打包、集成、測試、灰度等高度工程體系化的複雜程度。但生產力還以人肉爲主，互聯網前端行業還是勞動密集型作業方式。

階段一：刀耕與火種 & 野蠻生長

2010 年的前端，IE6 還盛行，jQuery 是老大，YUI 雖然也不差，但用的人畢竟沒有 jQuery 多。有個比較牛逼的工具叫 Firebug，這算是給前端的最大福利。這個時候的前端，在我看來應該還算刀耕火種階段，雖然有 Dreamweaver 這樣的網頁可視化編輯工具，但產生的無用代碼量真是挺多了，而且對接數據比較麻煩，維護成本也不低，在當時的網絡條件下，用它的人可能也不少，但我一直不用它。

階段二：模塊化開發 & 框架升級

2011 年，來到阿里實習之後，發現天貓（當時還叫淘寶商城）的頁面的確很高端、大氣，而且也的確跟設計師在一起工作（當時還叫 UED），很興奮。當時的前端規模不大（算上外包，15~20 人左右），YUI 在公司還比較盛行，KISSY 開始展露頭角，看到前人大牛寫的代碼有條有理、的確非常膜拜，所以基本那半年的實習生活裏大部分週末都泡在公司裏或者加班或者自己學習前人的東西。與此同時，公司內還有一款非常牛逼的產品叫 TMS ，可以通過模塊化以及模板化的思想，分分鐘就可以搭出一張頁面來，簡直牛逼的不要不要的，那個時候淘寶商城的雙 11（雖然很多人當時還把雙 11 當光棍節）活動頁面就是用這款大殺器搭建完成的。用模塊化搭建的思路來解決頁面批量生產的問題，這個思路在當時業界也算領先，而且這個思路一直延續到今天。所以如果阿里有個產品歷史博物館的話，TMS 絕對位列其中。

 

在 2011 ~ 2014 年之間的歷史階段裏，模塊化的思路佔爲主導。當時爲了進行 Assets 資源加載器的設計，就制定了模塊化的協議規範。當時比較流行的模塊化協議就是 AMD（RequireJS）、CMD（Seajs 爲代表）、KMD（Kissy 爲代表）。在淘寶、天貓，Kissy 應用的很火，YUI 退出歷史舞臺，所以 KMD 主導天下；在支付寶及外部社區，Seajs 應用的很火，所以 CMD 主導天下，玉伯大大的名氣和威望也在前端圈裏特別高；而 AMD 在國外比較流行，但漸漸也被後來出現的 CommonJS 規範削弱了氣勢。

 

當時的前端藉助模塊化的思想和各路框架（YUI、jQuery、Kissy、……），來支撐着網頁頁面的生產，前端 Assets 資源已經不再跟服務端代碼捆綁在一起發佈了，但 doc 頁面還在服務端的 web 容器內，前後端的生產需要聯調、需要注意發佈順序。TMS 雖然好用，但還是在營銷活動（比如 618、雙 11）上優勢比較強，數據還是偏向靜態化的居多，在如頻道、搜索、交易等這種產品態的複雜主鏈路上還起不到快速生產的作用。不過慶幸的是，那個時候的營銷活動並沒有那麼密集，一年之內活動屈指可數，所以對前端的生產壓力還沒有那麼明顯。但痛苦在框架升級上，每年一次的 Kissy 升級，讓所有業務的前端痛心疾首。

階段三：瀏覽器加持 & 富體驗化

 

伴隨着瀏覽器大戰，瀏覽器內核技術在向前發展（有興趣地同學可以在網上自助看看瀏覽器的內核發展史，比如《全面瞭解瀏覽器（內核）發展史》），IE 逐漸跟不上 Firefox 、Safari 和 Chrome 的節奏。後起之秀 Chrome 非常關注 JavaScript 的引擎性能，覺得可以再提升 10 倍，所以自研一款高性能 JavaScript 引擎，名叫 V8，以 BSD 許可證開源，Chrome 在瀏覽器家族內的地位如日中天。給前端配套的 debug 工具鏈更加完善，通過控制檯可以完成代碼調試、性能檢測、資源檢測、網絡檢測、DOM 結構檢測等等諸多工作， Chrome 在前端的眼裏簡直可以說是一款瀏覽器走天下，IDE 什麼的完全通通不用。

因爲 Chrome 的加持，前端的研發效能有所提升，外加 HTML5 + CSS3 誕生和瀏覽器對它的爭先支持， Web 頁面的性能體驗也逐漸上了一個臺階，在網頁上可以做的技術嘗試也開始展露，如網頁特效/動畫、網頁遊戲。

階段四：前後端分離 & 工程完善

這個思想的提出當時是一位阿里的前端高 P，這種思想的誕生目的就是爲了解決前後端在 Web 容器上的過度耦合，導致前後端的研發效率相互制約，所以將這種耦合轉變成對數據的耦合，面向數據編程，將 Web 部分徹底交給前端，這樣前後端的研發效率會大有提升。

而這個思想的提出時機恰好是在 NodeJS 和 NPM 生態初步建立的階段，阿里藉助 NodeJS 做前後端的分離嘗試，在後端諸多質疑聲中，幹掉了 PHP、廢棄了 Java 的 Web 容器，一路拿下了前端在 Web 容器上的主動權。前端在 NodeJS 生態上，也開始有 express、koa、egg、begg 這樣的 Web 應用框架開源，也開始有了藉助 NodeJS 完成的工程腳手架套件（如 webpack ），同時也衍生了一個新的工種 NodeJS 開發工程師，基本阿里的所有 Java 中間件生態，在 NodeJS 生態上也有對應的一份了。

 

前後端分離，讓前端主導 Web 容器，帶來的直接益處就是前端可以從 Client 和 Server 兩端進行一體化的生產工程設計，讓前端的頁面加載性能達到極致化。當然，前端職能的拓寬，也給前端帶來了額外的工作負擔，所以如果沒有充分人力準備的部門，輕易不會嘗試負責 WebServer 端，畢竟運維需要成本。但慶幸的是，隨着 docker 容器化技術的發展和雲基礎設施運維能力的發展，從 IaaS 發展到 PaaS，再到 SaaS，服務端的運維成本大幅度降低，所以前端運維 WebServer 的成本就降低很多。

後話：如今發展到 FaaS 階段，基本就是 Serverless 化的，運維基本對上透明，上層更加感知不到。

當然，前後端分離並沒有對前端的研發效率上有太多的改觀，倒是在前端工程體系上更加完善和健全。以前的前端可以被叫頁面仔，但這個階段前端已經不再是了，因爲前端的工程體系（如 IDE、研發、構建、打包、集成、測試、灰度、生產服務等等）不比 Java 的差多少。

階段五：終端碎片化 & 技術洗禮

2013 年，移動端興起，阿里 All in Mobile，移動端瀏覽器的發展勢弱，趕不上 App 的用戶體驗，多年在 PC 時代沉澱下的技術產物發現在移動端弱網的環境下難以應對，Mobile First 技術戰略之下，很多基建又得從移動端開始重新設計。

比如：kissy 在移動端的 mini 版 kimi，但後來也因爲 kissy 在業務前端的口碑形象下滑的厲害，以及社區內有 RN（React Native）和 Vue 的興起，所以 kissy 的生態也在時代的車輪下漸漸消失。

再比如：上文提到的 TMS 系統，因爲它對移動端的不適應，導致它在時代的車輪下漸漸消失，被新的產品替代，支撐住移動端的網頁搭建。

 

隨着 3G、4G 的發展和 iOS 和 Android 手機在市場的普及量大增，PC 業務主戰場也逐漸過渡到移動端。前端的思維模式由 PC 轉向了移動端，並向 App 的用戶體驗看齊。移動端的 HTML5 協議支持不完善，前端的生產配套不全，Android 的屏幕碎片化，所以那個時候的前端開發移動端頁面適配的痛苦要遠遠超過 PC 時代。

階段六：數據化驅動 & 框架之爭

 

不過，慶幸地是有 Angular、React、Vue、RN （React Native） 這樣的 MVVM 框架出現，讓前端接受了數據驅動思想的洗禮之外，還藉助 RN 完成了移動端的體驗升級，包括後來的 Weex、Flutter。

在這個階段，前端開始有了終端的底層架構組，開始構思前端頁面在移動終端上的加載性能和用戶體驗表現。前端在移動端的研發上在 Web 和 Weex 容器上來回遷移和猶豫，增加了技術選擇的負擔，而且相互間無法複用。

所以爲了解決多端複用的問題，Weex 又藉助生態上的 Vue 框架，打通 webview 和 weex 兩端，夢想着一套代碼跑天下。但現實中就是打臉的，兩種終端容器能力不對齊，相互制約，一套代碼寫得瞻前顧後。這個時候的前端，被終端技術折磨的苦不堪言。

但好在 Web 在移動端的發展越來越強，同時藉助客戶端的一些能力加持（如 hybird、cache、prefetch 等），web 頁面的體驗強到可以與 App 分庭抗禮。所以經歷過煎熬的四五年時間，如今 web 的聲音已經在移動端占主導地位。對應的移動端框架也確定下來。

同時，2016 年，小程序的概念開始提出到上線，一種輕 App 的開放解決方案開始在國內掀起浪潮，微信、支付寶、百度等一堆互聯網大廠（包括如小米、華爲等的手機硬件廠商）在這個大潮之下分食。所以一種小程序的新 DSL 誕生在前端眼前，前端要兼顧 web 及各個廠商之間的 小程序 DSL，痛苦又翻倍增加。有痛苦就有人解痛，像 WePY 、 mpvue 、Taro 等小程序框架如雨後春筍，相繼出現（《小程序第三方框架對比 ( wepy / mpvue / taro )》）。

除了移動端，在 PC 的 C 端和中後臺業務上，分別該用什麼樣的技術方案呢？要不要用 MVVM 框架呢？用React（包括 Preact）、Vue、Angular 具體哪個框架呢？

在經歷過多方聲音的反反覆覆多年的爭吵下，最終總算確定了中後臺全部採用 React ，PC 的 C 端採用跟移動端一樣的同構方案。雖經歷過幾年的痛苦折磨期，但框架之爭總算平靜下來，前端的目光開始關注更上層的東西組件化物料（如 AntD、Fussion、ICE 中後臺物料等）的建設以及前端行業領域的細分。

階段七：領域細分 & 可視化搭建

經歷過上述的爭鳴和冷靜之後，前端的行業領域開始更加細分，領域上層建設和深度建設也更在緊鑼密鼓的進行着，除了上面提到的 NodeJS 領域方向以外，還有以下這樣的垂直方向。

小前臺

面向的是消費者端的 Web 與 輕 App 業務場景，在這個場景下，經歷過多年營銷活動的沉澱，面向運營、商家或 KOL 的頁面的可視化搭建系統也非常成熟。所以營銷活動基本靠這樣的系統支撐。

中後臺

 

面向的是企業 ERP、CRM 、OA 等業務場景，如供應鏈系統，在這個場景下，藉助 AntD、Fusion、ICE 中後臺物料，形成可視化的中後臺搭建解決方案，爲業務的前端、開發或產品角色提供一站式中後臺生產解決方案。採用搭建，目的肯定是爲了業務生產的提效。

數據可視化

 

面向的是企業的數據 BI 分析和可視化呈現場景，如 雙 11 的阿里和商家的企業級數據實時大屏。在這個場景下，藉助 echart、highcharts、 AntV 等數據可視化圖表物料，形成一套數據可視化搭建系統，爲業務的前端、開發或產品角色提供一站式數據可視化圖表生產解決方案。採用搭建，目的肯定也是爲了業務生產的提效。

互動內容

AR、VR、3D、網遊、短視頻、直播（WebRTC）等新技術在 web 上的衍生和普及，更多富導購的交互形式層出不窮，所以這個方向就是在面向未來的用戶富交互體驗做投資建設。

……

還有更多的垂直領域，在此不再細說。

回看這10 年，是互聯網發展和終端發展最快的 10 年，也是前端發展最快的 10 年，更是前端程序員掉頭髮、白頭髮最快的 10 年。因爲沒有哪個技術領域，可以層出不窮地出現新輪子、可以反覆不斷的推翻升級升級推翻，但慶幸的是，經歷過百家爭鳴之後的前端行業在各個領域內的建設深度也愈發地趨漸成熟。與此同時，大家也會發現，這些複雜的建設也都是圍繞着能解決業務問題和能提升自身生產效率的角度出發的。

 

 

展望：前端發展的未來 10 年（深水區）

解決業務問題不說，那麼前端爲什麼要關注生產效率問題呢？

因爲這直接與阿里的業務體量相關，阿里每一年的業務體量都是相比去年翻番的（比如出海、下沉、創新業務……），所以如果生產力效率跟不上業務的發展節奏，那麼在市場競爭上就不佔優勢，以 2019 年三四線下沉市場高度競對的場景爲例，如果前端撐不住業務發展的節奏，還是慢慢悠悠地搞生產，那麼企業就很難佔據市場了。

所以，每個前端身上揹負的都是業務體量的成倍增加，如何能快速支撐住業務發展以及如何幫助業務突圍和增長（2017 年手機出貨量觸頂下滑，移動端的自然用戶增長紅利達到頂峯，可以從《用戶流量紅利消退的下半場，淘寶如何保持高速增長？》便可感知到）是我們每時每刻都在思考的問題。

前端已到瓶頸！

我們知道，即便工程化能力已經成熟，但還是解決不了的問題就是“生產效率”的問題，試想：

假設 1 箇中等水平的前端產出一張功能齊全的頁面需要 1 周時間，1 個牛逼的前端可能只需 2 天時間；而即便都僱傭牛逼的前端，1 個前端單打獨鬥一週之內最多也就 4 張頁面產出，如果僅是生產 10 張頁面，那麼僱傭 1~2 個牛逼的前端一週之內就搞定了，但如果是生產 100 張、1000 張頁面呢？這個時候僱傭多少前端比較合適呢？高端人才的緊俏和招人成本的控制，都會導致廠內的前端的業務壓力倍增。

解鈴還須繫鈴人，所以業內開始不斷地涌現 hardcode 向 lowcode 方向轉變的提效熱潮。不說外界，單以阿里爲例，面向中後臺、C 端、數據可視化方向的 lowcode 平臺就層出不窮，雖說上手複雜度很高（畢竟解決問題的複雜度擺在那裏，就像 Photoshop 一樣），但也都在趨於成熟。

可這樣就高枕無憂了嘛？其實並沒有，因爲業務的迭代速度太快了，即便有這些平臺存在了，依然還是解決不了業務上的燃眉之急、前端效率問題依然是業內的瓶頸。

以我帶的團隊爲例，我們服務的每一條線下的業務量和複雜度都是居高不下（每條線承接的是千萬級流量，所以業務複雜度自然會高），除了日常產品迭代，每月至少有 1~2 次的營銷活動同時進行，即便用了上述的 lowcode 產品，但還是解不了業務方頻繁上訴要人的困局，甚至排期、砍需求這種傳統小伎倆如今也對業務方沒有藥效了。

怎麼辦？一人難敵四手，更何況是一堆數都數不過來的手了。

前端如何突圍？

要講清楚這一塊，我們換個視角看看。衆所周知，市場是有清濁、淘汰機制的，任何一個行業都不是一成不變的，只要有先進的出現，那麼就勢必會將落伍的清理淘汰掉，而這個過程自變量僅是時間。

就像電商互聯網興起的那一刻，有多少實體從業者會意識到自己的飯碗會跟不上時代？就像移動端來臨的那一刻，有多少公司及個人還在沉淫在 PC 的時代產物上，再後知後覺地意識到落後時已經被競爭者甩了好幾條街了。

就像當 iOS、Android App 生態剛開始興起階段，不斷地有客戶端的人才在向市場輸入，而今當 App 在市場飽和、用戶分配在終端上安裝的 App 數量有限，以及移動端 Web 和輕 App 技術的飛速發展等客觀因素衝擊下，客戶端的從業者發現保住自己的飯碗越發的困難了。

就像 AI、區塊鏈興起，有一大批的算法從業者和新技術的創業公司輸出到市場，而經過市場競爭的洗滌下，又發現算法人才飽和過剩、創業公司也死了一大片。

所以要看一個行業的未來發展怎樣，就看這個行業的人才目前和未來在市場上被密集需要的地方在哪、規則最混濁或混亂的地方在哪。如果說這個行業的規則出奇地清晰、人才的供給又出奇的冷靜，那麼基本上來說，這個行業在市場的發展已經達到平衡狀態，而能打破這種平衡重新建立平衡的也肯定是另外的行業的發展滲入。

所以迴歸到我們所處的前端行業，如今前端人才被需要的肯定是在互聯網公司，尤其是大廠，因爲業務發展需要，且被需要的很密集（勞動密集型產業），而且這個行業恰巧也是發展規則相對混亂的。爲何混亂呢？一方面是因終端多元化趨勢嚴重，比如智能穿戴設備和 IOT 智能家居、智慧醫療、智能建築等新興產業的市場衝擊，另一方面是因業務的發展形態、發展規模、發展距離（國內到國外）等因素的影響，都導致着過去的終端的技術規則無法適應到新興終端領域內，所以規則在變、技術在變、框架在變、從業者的領域也在變。

所以從這個角度看前端的職能領域只會越來越寬，人才的需求量只會越來越大，供給的能力要求只會越來越高。可以說這是市場對前端這個行業利好的信號，但同樣也是對前端這個行業壓力提醒的信號，如果在這個市場內的前端不能很好的解決市場壓力問題，一旦有新興技術手段形成的新生產力出現，那麼前端的這個香餑餑的行業飯碗也就不保了。市場就是這樣冷靜殘酷的，當市場出清淘汰一個行業的時候或許連一聲招呼都不會打，沒有爲什麼，這是發展的必須。

如今我們看清形勢，再反觀我們的生產力手段，可以說還是人肉勞動密集型的，就算招再牛逼的人才進來，如還是以這種的生產手段生產，那麼早晚都會被淘汰，不管有多資深，哪怕是專家、研究員。所以前端發展到這個檔口下，看似成熟，實則危機四伏。

我們需要反思，更需要一種全景視角的突破和自我革命。與其讓別人革我們的命，那麼真不如我們自己革自己命。所以接下來前端的發展勢必會面臨着一個最習以爲常卻又最爲關鍵的挑戰 —— 前端生產效率該如何翻倍的提升？

歷史的經驗告訴我們，一個行業的生產供給能力翻倍，那麼一定跟這個行業的工藝手段脫不了關係。比如傳統製造業製造一款鞋子、織一塊布，都是人手工的，當這種供給達到瓶頸之後，就開始出現機械化來輔助人來生產，機械化達到一定程度就是自動化，自動化就可以完全脫離人工進行生產。

同樣的道理，前端目前的生產工藝還是人肉的，即便有一定的程度的 lowcode 產品手段來輔助前端釋放生產壓力，但還是解決不了供不應求的問題，所以沒有別的辦法，只有一條路就是去人肉，改成完全自動化的生產手段，只有讓供給能力遠遠超越需求的市場增長指數，那麼才能徹底解決供不應求的問題。

那麼，前端該如何將生產手段提升到自動化階段呢？

首先，我們能想到的生產手段上肯定不能重度依賴人，那麼剩下的也僅有機器，對於我們而言，肯定就是計算機了。

其次，我們要想的問題是該如何用計算機來解決我們所面臨的生產問題，想到第一步不難，而最難的恰巧就是這一步。該怎麼解呢（how）？

調研發現，市面上就 2 種形態的解決思路，一種就是堆人的 hardcode 方式，包括傳統的組件化生態，也都停留在這個階段上；再有一種解法是 lowcode 的方式，或者輔助自己或者輔助其他角色來做生產（換一句話來說就是生產關係轉移到其他角色身上），這種方式在特定領域內能一定程度上提效，但一旦領域拓寬或稍有移植，就會面臨着不適應，用它工作量反而比 hardcode 增加很多。目前我們就在第 2 階段，但生產效率問題還是非常突出。所以我選擇的解法是 nocode，雖然這個詞也不是我新創的，但這個詞的涵義足以表達我對生產力供給能力提升下一個階段的看法。而能幫助前端實現 nocode 解法的技術，一定就是 AI（準確來說是機器學習）。Why？

互聯網的發展就是帶來了海量的數據，依靠人腦已經無法去分析清楚一個行業的特徵了，至少我們都是凡人大衆，那種類似愛因斯坦的天才畢竟還是少見，不可能哪個行業都要等着愛因斯坦出現才能找到解決方案。所以凡人大腦做不到的事情我們就交給計算機來做，如今的 雲計算髮展和 AI 發展，已經降低了我們應用 AI 來解決我們問題的門檻，所以入行 AI 也是遲早的事，不可能每天都蒙着眼睛裝看不到，而且也一定程度上得承認 AI 比我們更聰明，所以逃避不了的事實我們乾脆一些接受好了。AI 就是爲海量數據和複雜問題而生的。

思維方式轉變

那麼前端究竟該怎樣加持 AI 的能力呢？

這個問題對純前端從業者來說很難，對算法從業者來說也很難，但對既懂前端又會算法的從業者來說就不難了。爲了講清楚這個問題，那麼我首先來講解下這兩者解題思維的慣性差異是什麼，幫助大家先從思想上進行轉變，這樣大家也就更易接受一些。

我們以一個具體的案例爲例：當你的產品經理讓你做一款類似下圖這樣過障的小遊戲，管道洞口高度固定，且是勻速向左移動的，小鳥只會上下，同時受重力影響會跳動，你如何讓這隻小鳥自己會躲避障礙成功過關呢？

demo 地址：xviniette.github.io/FlappyLearn…

 

 

如果前端看到上面需求時，他的思維慣式一般是這樣的：首先，要有一張畫布，上面有小鳥、管道這兩種對象（Object），小鳥對象中有 x、y、width、height、alive 等屬性，x、y 代表它的水平和垂直位移，width、height 代表小鳥自身寬高，alive 代表小鳥的生死；管道對象中至少有 x、y、width、height、speed 5 個屬性，x、y 代表管道的水平和垂直座標位置，width、height 代表管道的寬高，speed 代表的是管道向左的移動速度。其次，要根據管道的移動速度給小鳥建立一個雷達預警機制，通過輪詢的方式不斷地探測正前方是否有障礙物，一旦有了就不斷地在垂直方向上上下位移來做避障。最後，依次類推的方式達到終點。

如果算法看到上面需求時，他的思維慣式一般這樣的：首先，需要找一款模型，拿 network 爲例，可以利用遺傳算法來解決上面的問題，具體就是通過 50 代小鳥不斷地嘗試碰撞，將每一代失敗的小鳥的基因記錄下來，然後遺傳給下一代，形成遺傳記憶，這樣小鳥就不會以失敗的方式過障，以此類推，直到沒有失敗的小鳥出現，那麼成功的基因就訓練完畢，這樣的一代小鳥就可以完全過障了。

大家可以看到，前端的給的解題思路的代碼裏是有具體交代小鳥應該怎樣判斷過障的；而看算法解題思路的代碼裏其實並沒有具體教小鳥過障的代碼邏輯，有的只是將一些特徵和反饋抽取傳遞給到 network，而真正的過障判斷過程是模型去做的。而這就是這兩種思路的關鍵差別，準確說是 程序員 和 AI 算法工程師的思維慣式差別，程序員的腦海裏有着“我能用代碼定義世界”的思維，而 AI 算法工程師腦海裏有着“我該用什麼樣的數據訓練模式讓模型自己儘快掌握對錯”的思維。前者是一種由自己來解問題的主觀視角，所以寫的代碼純粹是翻譯給計算機要怎麼去解這個問題；後者是一種由機器來替我解決問題的客觀視角，所以寫的代碼純粹是怎樣把問題拋給計算機，並告知輸入及結果對錯，至於計算機是怎麼解決這個問題的過程和規律算法工程師都不關心，只關心結果。

看到這裏，想必大家對 2 種思維模式有了一個切身的體感，如果還有不太理解的，也可以看 甄子 老師的《前端智能化—思維轉變之路》文章，這更是對這個思維差異做了更深入的介紹。

重新審視求解

那麼既然知道了 2 者的差異，我們就可以將前端領域內遇到的生產效率問題以最新的視角重新進行審視了。

前端，裏面的關鍵字是“端”，所謂的“前”就是交代離用戶最近的地方。所以用戶接觸到的終端（包括各種異形屏的、沒屏幕的僅有傳感器的終端等等）上面所呈現的任何人機交互內容（可視覺傳達、聽覺傳達、肢體傳達、甚至可能嗅覺傳達等等）都可以認爲是前端職責範圍內的工作。面對這種形式多樣的終端，要想快速產出人機交互的內容，我們用 AI 該怎麼做呢？

鑑於話題有點大，我們還是聚焦在 Web 頁面上（其他的以此類推），如何藉助 AI 實現高效地生產呢？

一種思路是，首先，聚焦在網頁上能呈現的內容形態看看到底有哪幾種（空間軸上的語言），比如文字、圖片、視頻（視頻可以理解爲圖片的逐幀動畫，加上音頻）、音頻；然後，我們再看下網頁上什麼樣的內容是經常變化的（時間軸上無序狀態），什麼樣的內容是通過交互方式產生變化的（時間軸上的有序狀態）。最後，我們的生產策略是，優先考慮將一組時間軸上的訓練數據餵給一個模型讓它識別出時間軸上的變化內容，然後再借助 CV 或 NLP 模型針對變化的內容進行實體識別（實體識別可能具體到一系列的模型存在，比如細化到商品圖識別模型），再然後藉助另外的 CV 或 NLP 模型來識別時間軸上不變的內容（往往這部分內容就是頁面佈局和容器框架），再通過一系列實體識別模型來做頁面結構代碼上的映射（高維空間向量餘弦值相等）。理論上來說，如有大量的訓練樣本數據，那麼模型針對時間軸上的有序狀態（即事件響應）也是可以慢慢自己學習出規律出來的。

上面這種思路是純算法的思路，其中沒有藉助前端的任何思維模式來影響，但具體效果怎樣和實施難度上有多大呢，目前還不好說，至少我們自己也還沒開始這種嘗試。

也許上面思維未來是對的，但今天來說，前端還沒有準備好，還在一步步進行思維上的轉變和迭代，這的確是需要一個過程。而且機器學習也不是萬能的，它受模型的制約因素很大，而模型往往也是一種算力的象徵。我們可以把機器學習比作是一個擁有高複雜度並行密集計算能力（高維空間上的矩陣計算）的統計學計算器，而模型就是這款計算器的內核。也許它能在背後計算出

 

這樣的宇宙規律，但至少也是進行了深度計算的，而這種深度的計算需要的就是海量的樣本。而樣本就是這款計算器內核塑造成型的靈魂，但這種海量樣本的製造工作也絕非是一朝一夕依靠一個軟件工程出身的技術人員搞得定的。樣本本身就是數據，所以一定要有存量的數據纔會有往深度學習方向上發展的可能性。否則人肉製造的樣本，要不質量太差（不夠客觀）、要麼就是量的規模不夠。當然，也可以先把計算器搭起來，至於樣本可以隨着時間進行積累，這樣的辦法也不是不可以，就是等待的時日可能比較長，沒法立竿見影收到奇效。

所以，針對商業行爲來說，我們至少得有 2 套方案，一套是長遠的（如上的方案）的準備，一套是短期眼前的方案。如果做短期的，就藉助規則系統 + 機器學習的混合方式來做方案。但不管哪種，樣本問題都是要解的。2 套方案也是 2 種選擇，也許你還有第 3 種選擇，都是選擇，所以多與少沒有什麼差別，只是看能在選擇之後投入多少和堅持多久。這種投入就涉及到知識和技能的儲備了，所以前端想解決問題，還是得儘快上手機器學習。至於具體怎麼上手在此就不做過多介紹了，網上的課程有很多，也可以看西瓜書上手，但關鍵是動手。可以先從 CV 領域入手，NLP 工程對個人來說單機部署有點難，得藉助雲（比如谷歌的 TPU 平臺）。

 

 

長遠來看，前端 + AI 的這種前端智能化方向肯定是持續存在的，前端也會因爲 AI 能力的加入，會產生諸多不一樣的生產力變化。這種變化可能是階段性的，也可能是終極的，總之生產力會慢慢向計算機身上過渡，前端做的工作是驅動這一切的更深層工作。這個方向沒有退路，也繞不過去（專家系統不可能無敵），所以要解的問題直到徹底解決爲止。

智能化的 10 年

 

最後，我還是帶着大家一起展望一下前端智能化的未來 10 年（以如今的互聯網發展節奏看，或許下面的 5 年內就達到也是有可能的）：

• 2~3 年內，前端智能化從業者數量翻倍，AI 在前端領域內或多或少有一些產品形態上的應用，終端開始浮現各種前端機器學習框架，用戶產品在智能化體驗方面的設計也有對應的傾斜，社區上也開始浮現出各種前端智能化的工程框架、訓練框架和 AI 平臺；

• 3~5 年內，前端智能化從業者數量繼續增長，傳統前端已經被淘汰，前端領域內智能化在特定領域內小有成績，可以解決特定領域內的一些業務或人力生產效率問題，終端智能體驗會趨漸成熟，給用戶帶來的沉浸式體驗增強，線上線下無屏化無差異體驗趨近相同，社區上開始開源一些前端的智能化產品；

• 5~10年內，前端智能化從業市場已趨近飽和，端智能體驗設計者應該在市場上比較吃香（如沉浸式人機對抗遊戲等），nocode 問題應該能徹底解決，但同時帶來其他的消費訴求，可能會引入新的領域難題。

結語

如今危機四伏，未來無限可期，所以大家還是要未雨綢繆，提前做好準備。