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