前端智能化的將來 10 年，越早入行越吃香！

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

起源

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

一腳入坑

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

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

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

第三款是作海報的（由於海報圖比較大、比較長，切割起來比較耗費內存，這塊軟件速度比較快）和 Gif 動畫的，但我用的少，大部分時間都用 Photoshop CS4 來搞定。雖然說這三款軟件最火，但真正讓我入坑前端（那個時候尚未「前端」這個稱呼，有的就是「切圖仔」）的理由，是由於我想當一位網頁設計師。

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

軟件工程搞 Java、C++、C 真是挺枯燥無聊的，寫一段程序，還得編譯、部署，等上個兩三分鐘的，特別無語；而當初接觸 Web 頁面開發時（當時仍是一位外教授課），發現網頁這東西很神奇，在一個 Text 文本編輯器裏敲上幾行代碼，改個擴展名，雙擊頁面就展現出來了，這種所見即所得的美的視覺衝擊力，當時讓我向這個方向上蠢蠢欲動，埋下了禍根。當時的 QQ 空間很火，這塊 DIY 本身的空間，但仍是感受不大氣，因此當時就想着本身作出一款比較高端大氣上檔次的網頁。大學期間，雖然本身學設計作網頁這個想法被身邊同窗嘲笑說這應該是專科同窗纔去搞的東西，但的確仍是堅持下來了。平時本身除了讀專業課程和完成課程實踐之外，就是在寢室、在圖書館、在選修課、實驗室裏抱着一堆影樓的 P 圖視頻寶典和一本影印版的厚厚的設計資料度過的。當時自學了 Photoshop ，也學會了設計中的三原色原理，並應用在班級平常校園種海報設計、照片美化等工做上，現在拿着單反拍個照 P 個圖的本領也都那個時候積累下來的。

再而後就是在校園裏找了個實驗室的項目，跟一夥人作一個外賣網站，本身擔任網頁的開發部分。老實說那個時候對方都不信任我能搞定網頁開發，畢竟我仍是初級的小白。因此本身那個時候啃 W3C，在網上邊學邊作，雖然當時有個不錯的 jQuery 的框架，但本身仍是純手工用 HTML四、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 雖然好用，但仍是在營銷活動（好比 61八、雙 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 的能力呢？

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

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

若是前端看到上面需求時，他的思惟慣式通常是這樣的：首先，要有一張畫布，上面有小鳥、管道這兩種對象（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 種思惟模式有了一個切身的體感，若是還有不太理解的，也能夠看 甄子 老師的《前端智能化—思惟轉X變之路》文章，這更是對這個思惟差別作了更深刻的介紹。

從新審視求解

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

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

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

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

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

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

E=MC2

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

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

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

智能化的 10 年