大多數(shù)同學目前對 AI 應用的認識只有文生圖、對話、駕駛等領(lǐng)域，但 AI 應用的場景遠遠不止它們。
和頭部的明星 AI 產(chǎn)品、模型相比，細分市場的 AI 應用就非常沒有存在感了。比如使用 AI 進行財務(wù)的審核、飲料配方的調(diào)節(jié)、工程安全的模擬等等，它可以幫助企業(yè)節(jié)約大量的人力完成工作。
概括起來，就是一些可以通過計算機完成的（也不止）重復性勞動或標準化流程，都可以引入 AI 的技術(shù)進行降本增效。
那在 UI 設(shè)計領(lǐng)域中，這些重復性和標準化的工作內(nèi)容有嘛？
有，但是并不會像外行或者新手想象的那么多。AI 難以覆蓋的場景我們過去的分享探討過，等等也會做進一步的說明，而這里我們先要探討的，就是能用 AI 實現(xiàn)的 B 端設(shè)計場景，具體有哪些。
我們都知道市面上現(xiàn)在有很多開源的 B 端前端框架，各個大廠前赴后繼地對它們進行更新和完善，里面包含了非常豐富的組件庫。
這些組件庫不不止是 UI 的組件，也包含了前端的對應代碼，前端工程師可以快速調(diào)用這些代碼組件而不用自己去重新寫一遍樣式和交互。
原則上，使用現(xiàn)成的組件開發(fā)就可以快速完成整套項目的前端內(nèi)容，這可以給前端工程師節(jié)省大量時間。所以即使項目中有完整的設(shè)計稿，前端在開發(fā)過程中也會偷懶直接略過，直接套用框架內(nèi)的組件實現(xiàn)。
這和設(shè)計師直接套用素材完成運營圖設(shè)計一樣，明明有現(xiàn)成的素材在那里，為什么要浪費一大堆時間自己重新畫一遍還是用 3D 建模渲染？同理，要是組件足夠豐富，滿足項目的需要，設(shè)計師也可以直接復用官方的組件素材，不用自己設(shè)計。
組件化思維的運用，就是項目工作標準化和重復性的根源，不僅應用在設(shè)計領(lǐng)域，對于前、后端開發(fā)來說同理。
基于這種思路，催生出了一種新的 SaaS 模式 —— 低代碼 Low-Code 服務(wù)。
即通過少量的代碼，或者干脆不用代碼，僅通過可視的工具和組件實現(xiàn)軟件的開發(fā)，并完成相應的配置和部署的工具。
這概念咋一看不就是建站工具？比如有贊、微店之類的，用戶可以在里面直接創(chuàng)建并配置店鋪，然后以網(wǎng)頁、H5 或小程序的形式發(fā)布。
但這只是最初級的應用，傳統(tǒng)的建站工具屬于幫你預制好了主要的參數(shù)和功能，用戶只能在這個范圍內(nèi)做少量的自定義編輯和設(shè)置。但進階的 Low-Code，會賦予用戶更大的編輯范圍和自由度，讓用戶通過可視化的界面創(chuàng)建自己想要的產(chǎn)品和功能。
這類產(chǎn)品已經(jīng)衍生出一個規(guī)模不小的市場，因為有大量的中小企業(yè)不想投入太多的精力和成本進數(shù)字化平臺的搭建上，
并希望能快速創(chuàng)建不同的管理工具來匹配企業(yè)日新月異的發(fā)展需要
。
這里要劃重點，對于一部分企業(yè)來說，經(jīng)營模式和業(yè)務(wù)流程是持續(xù)迭代的，如果使用傳統(tǒng)的開發(fā)模式那么很難跟上這種迭代。
以連鎖餐飲品牌舉例，前期只在一個城市經(jīng)營，和后期擴張到全省或全國，采購流程和供應鏈管理必然會持續(xù)進行調(diào)整，提交一個采購工單所需填寫的字段就會發(fā)生變化，同理展示的表格、詳情頁也要跟著調(diào)整。
這類變化往往并沒有修改界面的視覺、交互、組件，僅僅是增加和減少字段數(shù)據(jù)，而用傳統(tǒng)的收集需求再輸出進行開發(fā)的模式效率非常低，所以它們就成為 Low-Code 的最佳應用場景。業(yè)務(wù)方自己配置、修改直接上線，省掉產(chǎn)品經(jīng)理、設(shè)計師、程序員中間耗差時……
并且對于很多企業(yè)來說，只需要應用一些非常基礎(chǔ)的功能服務(wù)和頁面類型。比如我經(jīng)常提到的 B 端管理系統(tǒng)的四個核心頁面類型：
Low-Code 就是把常規(guī)需求標準化，并運用組件化的框架，讓用戶通過簡單的填寫和編輯就能生成出想要的頁面和功能。
既然需求不復雜，功能、組件、頁面、代碼都可以標準化，那不用 AI 降本增效還有王法嘛？
所以，使用 AI 生成 B 端頁面（不是設(shè)計稿）的工具已經(jīng)在大廠內(nèi)部開始應用了，開發(fā)專屬大模型，再把做好的組件喂給模型，用戶只要在相應的表單內(nèi)填入需求，就可以快速生成出落地的頁面。
并且各家大廠內(nèi)部的 B 端組件庫，可遠遠不止對外分享的這些開源框架里包含的數(shù)量，還有很多特殊的業(yè)務(wù)組件，可以讓模型得到更好的訓練和產(chǎn)出，比普通 Low-Code 模式更簡單高效，大幅度提升企業(yè)內(nèi)部B端產(chǎn)品的落地和運用效率。
從已經(jīng)了解到的信息中，有一部分業(yè)務(wù)部門已經(jīng)開始進入實踐環(huán)節(jié)了。且隨著技術(shù)的迭代，這種工具必然會越來越強大，功能越來越豐富。
所以，了解完這個趨勢，設(shè)計師和前端工程師迎來大結(jié)局了？要被AI技術(shù)清洗了？現(xiàn)在該捧起《從0到1學習炒粉》學習了嘛？
前面做了不少鋪墊，就是為了強調(diào)，適用于 Low-Code 和 AI 生成的 B 端產(chǎn)品，是有前提條件的，包含下面這些要素：
-
-
-
需要經(jīng)常變動調(diào)整的業(yè)務(wù)需求
-
而這里面最關(guān)鍵的東西，就是標準化。必須要知道在今天的 AI 的應用發(fā)展中，要生成出符合實際工作需要的結(jié)果，絕對不是靠輸入信息以后它自己 “蒙” 出來的。為了讓結(jié)果盡可能準確，那么喂給模型的數(shù)據(jù)也就要越多且越有針對性。
理論上面向 B 端的 AI 工具，只要不斷提供給他新的組件、頁面，就能拓展它可以實現(xiàn)的范圍。但不管你怎么訓練它，都要滿足標準化的前提。
而標準化，恰恰就是國內(nèi) B 端業(yè)務(wù)的命門……
我們都知道國內(nèi) SaaS 行業(yè)現(xiàn)在發(fā)展非常的混亂，雖然在不同的細分領(lǐng)域有自己的獨角獸，比如財務(wù)領(lǐng)域的金蝶，OA 領(lǐng)域的釘釘，ERP 領(lǐng)域的用友等等。
但是這些公司就發(fā)展狀況良好利潤豐厚了？24年一季度的 SaaS 頭部公司業(yè)績非常蕭條，比如網(wǎng)上找到的統(tǒng)計，和國外 SaaS 頭部公司的估值和利潤形成鮮明的對比：
為什么國內(nèi) SaaS 市場那么慘淡？說到底就是在國內(nèi) B 端領(lǐng)域很難實現(xiàn)真正的標準化，而不是國內(nèi) B 端市場規(guī)模太小。
比如釘釘、飛書這樣的 OA 軟件已經(jīng)很成熟了，但它們的實際普及程度一點都不高，而中大型企業(yè)又有各種考量，現(xiàn)成的不用就熱衷于開發(fā)一套自己的系統(tǒng)，簡稱定制化。這就倒逼 SaaS 工具為了滿足更多的企業(yè)需求，拼命疊加功能，使得這些 SaaS 工具一個比一個臃腫。
而我們前面提到的 AI 生成，想要普及同樣需要面對這種困境，因為模型不管怎么做，它都是基于特定標準化下的產(chǎn)物，它可以滿足其中一部分需求，但難以滿足其它需求。尤其是國內(nèi) B 端定制化需求中，混亂、抽象、聯(lián)系復雜的問題非常突出。
換句話說，國內(nèi) B 端市場的大多數(shù)系統(tǒng)，是非標準化的，需要產(chǎn)品團隊在面對這些非標準的需求下做出創(chuàng)新和適配，就必須要考慮很多抽象的因素，領(lǐng)導、背景、體驗、交互、周期、難度等等。這個過程不可能由業(yè)務(wù)方自己完成，且最終導出的設(shè)計結(jié)果，往往會和常規(guī)方案有很大的差異。
按常規(guī)邏輯考慮的話，那有多少組件我們整理多少組件，早晚有一天不得窮盡設(shè)計師思考范圍的邊界？
且不說獲得不同商業(yè)項目的業(yè)務(wù)組件有多困難，如果組件之間沒有更底層的思路去規(guī)范它們的設(shè)計和交互，那么硬湊到一起的項目是非常割裂的，而 AI 在短時間內(nèi)沒辦法做到真正理解交互的邏輯并根據(jù)使用場景做理性的推理。
所以基于一套團隊產(chǎn)出的組件必然是有限的，它們或許可以滿足自己項目，但不可能滿足市面上所有項目的使用需求。
還有一個很關(guān)鍵的疑問，就是很多人會想，一個項目中的特殊組件往往只是少數(shù)，我們用 AI 工具生成多數(shù)頁面，少數(shù)進行定制和獨立開發(fā)不就行了？
這思路在邏輯上很合理，但實踐起來的問題非常多。舉個例子比如設(shè)計稿直接生成網(wǎng)頁這種技術(shù)，從20年前我剛了解到網(wǎng)頁設(shè)計那天說到現(xiàn)在了，這個實現(xiàn)邏輯理應不需要 AI 的參與都能做到，中間也問世了不少產(chǎn)品和工具，但沒有一個做成了，反而網(wǎng)頁前端工程師都成為一個獨立熱門職業(yè)了（以前是 UI 寫）。
原因就是作為商業(yè)項目來說，團隊需要 “可控性”，機器生成代碼雖然容易，但是如果要修改里面的東西怎么辦？實際情況就是前端對這些外部代碼深惡痛絕，因為改起來太麻煩，而越大的項目改起來難度也越高。而且這個版本的一部分你改了，下個版本工具再生成的代碼要不要兼容你前面寫的東西？
所以現(xiàn)在即使有設(shè)計稿直接生成代碼的工具前端也寧愿自己寫，但當他們用到第三方框架的時候，能不動框架里面的東西就不動。想要理解這個感受，只要拿這些框架的組件素材用它們的組件、自動布局形式做完一個項目，你們就會產(chǎn)生 —— 還不如自己重做一遍的想法。
所以生成工具，要不然能一次性完整滿足所有需求，要不然就會因為兩三成的缺口形成致命的瓶頸。當然，還有遠比這些復雜的進一步因素，我就不在這里展開。
標準化無法在定制化的面前獲得優(yōu)勢，這是國內(nèi) B 端行業(yè)面臨的直接困局，當然這里有壞的影響也有好的影響。
壞的影響，就是頭部 SaaS 企業(yè)沒辦法得到快速的發(fā)展，推高整個 B 端軟件業(yè)的收入水平和吸引力，AI 生成頁面這些技術(shù)適用范圍小，沒辦法真惠及全體，行業(yè)處于反復造輪子但根本沒辦法停下來。
好的影響，則是頭部的 SaaS 企業(yè)發(fā)展不起來，市占率就低，它們就沒辦像 C 端市場一樣形成非常顯著的馬太效應，形成事實的壟斷。大家重復造輪子，那么提供的就業(yè)崗位才多，才能讓我國的炒粉行業(yè)沒有那么卷，競爭沒有那么激烈（？？？）……
如果你關(guān)注過 B 端市場足夠多年，你就會明白任何企圖用一種標準、方法論直接平鋪整個行業(yè)的做法，注定是徒勞的，而無序、野蠻、熵增才是不變的主旋律。
但 AI 的作用短時間內(nèi)完全發(fā)揮不了嗎？也不是。除了前面提到的一些簡單的項目之外，還有一個非常大的可能，就是中小模型的開發(fā)會變得越來越容易，而基于項目自研的界面 AI 生成工具很有可能會普及起來。雖然它們不能隨心所欲生成任何需求的樣式，但可以完全根據(jù)業(yè)務(wù)方的實際需要進行定制，去服務(wù)小范圍的群體。
這不代表項目里面就不需要設(shè)計師，符合這套項目的標準依舊需要設(shè)計師去制定，也需要設(shè)計師持續(xù)輸出特殊的頁面和組件。
所以，未來很長一段時間內(nèi) AI 和 B 端 UI 設(shè)計師之間會是互補的關(guān)系，而不是替代關(guān)系。這也會對崗位要求形成進一步的影響，所以下面是我對 B 端 UI 設(shè)計師所需技能的建議：
-
進一步提升交互能力，尤其是基于業(yè)務(wù)認知輸出交互方案的抽象思維能力
-
進一步鞏固項目設(shè)計規(guī)范的創(chuàng)建能力，深入了解規(guī)范的應用和落地流程
-
進一步提升全局性設(shè)計思維，能提煉核心價值觀并在項目中進行應用
-
進一步了解編程開發(fā)邏輯，能更好的配合前后端完成項目的輸出提高效率
這些能力的掌握是 B 端 UI 設(shè)計師應對未來市場變化的核心競爭力，也是 AI 在短時間內(nèi)絕對無法替代的東西。
不管是作為已經(jīng)入行的，還是準備入行的 B 端設(shè)計新人，都不用對 AI 技術(shù)在 B 端的影響太過擔心，自怨自艾，因為
如果 B 端項目的設(shè)計都那么簡單的話，那么從前端框架普及的那一天起，B 端 UI 設(shè)計師就可以集體下崗，而不用等到 AI 應用的那天
。
換個表述方式，祝大家不會菜到那么輕易就被 AI 給取代了……
作者：酸梅干超人鏈接：https://www.zcool.com.cn/article/ZMTYzNzg4MA==.html來源：站酷著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處。
