作者 | 千鳥

出品 |?CSDN云計算（ID：CSDNcloud）

2021年底，CSDN面向行業開發者和高校學生開發者，展開了關于“低代碼”的開發者調研活動。基于調研數據，CSDN提出了對低代碼發展趨勢的五大方向。在隨后舉行的 《CSDN?企業數字化之路——低代碼發展研討會》北京站上 CSDN 和行業大咖針對這五大方向展開深入研討，共同輸出以下對低代碼的洞察觀點。

• 觀點一：低代碼未來將會成為企業數字化的基礎設施；

• 觀點二：全民開發，人人都可以是開發者；

• 觀點三：低代碼會促進行業培養更多快速搭建數字化系統的技能型人才。

圖1 ?“低代碼”調查統計：認知度與了解意愿

圖2???低代碼使用人群畫像

特邀嘉賓主持人：

鄒欣（CSDN副總裁）

參會嘉賓：

寧偉? ?葡萄城? 產品市場總監

朱文靜? 新加坡AI2LABS中國區負責人

黃榮? 普元信息 北京研發中心資深顧問

湯爐鑫? 中興數字技術產品部 產品總監

曾靜良? 致遠互聯? 助理總裁

駱勤? ?騰訊云微搭低代碼技術產品專家

王瀟? ?道一云事業三部總監，大華北區負責人

喬勝? ?明源云 天際開放平臺解決方案總經理

李婷婷? ?輕流聯合創始人兼CTO

蔣童? ?上海泛微網絡科技股份有限公司咨詢總監

陳曉露?? 行云創新? 產品總監

蕾拉? ?釘釘高級運營專家

令九? ?釘釘技術專家

熊方恒?織信深圳市基石協作科技有限公司運營總監

李煥靜? ?泛微 北方大區市場總監

費騰、郭月寧、龍騰 ???社區低代碼KOL

圖3 ??鄒欣（嘉賓主持人）

圖4 ??研討會現場

“低代碼”平臺應該如何分類？

鄒欣：CSDN前期做了一個調查，結果是“22%的人已經開始使用“低代碼”，58%的人表示在一年內會去使用，70%的人群對于低代碼的定義是非常模糊，91%的決策者認為他們利用了低代碼之后效率提升50%以上”。這是一個全新領域，大家會從哪個角度分析和切入？

圖5 ??駱勤（騰訊微搭）

駱勤：個人認為分類可以有兩種：一種是從行業角度劃分，分行業通用低代碼平臺和特定垂直領域的低碼平臺；另一種可以按可視化程度劃分，實際上國內外逐漸把很多無碼平臺也納入了低代碼這個體系，所以又可以分低碼和零碼平臺。

對于騰訊微搭“低代碼”平臺主要有三個明顯特征：

（1）微搭構建在騰訊云開發基礎底座上，定制能力具備了從無碼、到低碼以及全碼三種開發模式，這是我們的擴展性優勢；

（2）快速直連騰訊生態，尤其針對小程序場景，可以直接跟微信生態鏈路綁定，比如用微搭搭建小程序通過私有鏈路，來打通視頻號、交易能力、支付能力等會非常順暢；

（3）擁抱開放生態。我們現在開放生態定位很清楚，核心會把企業連接能力做好，企業客戶能通過微搭“低代碼”平臺把內外部產品服務和數據進行打通。

費騰：我認為無論“低代碼”或是“零代碼”，可以按照橫向和縱向兩個方向去分，解決“功能性”和“領域性”的問題。

（1）“功能性”重點挖掘跨領域之間的共同特點，以功能為主形成一個個子系統進行復用；

（2）“領域性”則更加專注業務，不斷深耕聚集與業務相關的知識能力，提供更便捷的垂直業務系統。

除了橫向和縱向的大類外，還可以從產品功能定義去拆分，如大家所熟悉的“表單驅動”和“流程驅動”，還有“模型驅動”。

蕾拉：釘釘今年推出“低代碼”聚合平臺“釘釘搭”，作為“低代碼”聚合平臺，跟單一產品最核心區別在于“釘釘搭”是“低代碼”產品聚合場，更希望搭建“低代碼”生態型平臺，希望把國內國際比較有代表性的“低代碼”產品以及“低代碼”能力融合在這個平臺上，依托于云底座能力，為更多組織、有創意、有想象力、有動手能力的用戶做服務。

曾靜良：我這里有一個我們的客戶案例，他們在數字化轉型的過程中，希望能有更合適他們的大平臺助力，解決各類復雜的管理流程，最后我們把他們的經驗復用，形成一套“低代碼”平臺的分類邏輯：

（1）為OA類廠商提供的“低代碼”平臺。以審批流程應用為主，把制度規范、管理流程串起來；

（2）為財務、業財一體化、ERP客戶提供服務的平臺。直接為有需要的客戶提供一套垂直業務系統，直接完成無代碼式的數字化轉型；

（3）新型互聯網廠商的低代碼平臺，無傳統B端軟件背景的廠商。

圖6 ??曾靜良（致遠互聯）

千鳥：作為一名開發者，我更傾向把“低代碼”當做輔助開發的一個工具。比如在業務模型確定后，后端通過“低代碼”平臺能夠自動完成數據庫腳本生成、底層增刪改查基礎邏輯代碼生成、還有相關大量同質化的WebAPI代碼；前端通過“低代碼”平臺則直接將設計圖輸出為頁面文件。

這些“低代碼”產出的代碼，直接交付給稍微懂開發的程序員，稍作調整，即可直接編譯發布進入測試環節。因此從開發者角度看，“低代碼”的分類，是否可以參考程序員的分類，比如面向前端的、面向后端的、或面向數據庫、運維的、測試的等等。

如何評價“低代碼”產品的成熟度？

鄒欣：?AI從學科角度已經非常成熟了，已經成為標配了。但是從來沒有任何一個學科搞“低代碼”專業，職業培訓學校也都沒有，所以它作為一個學科是不成熟的，但在工程領域，又有許多使用“低代碼”的成熟應用，大家覺得應該如何評價“低代碼”產品的成熟度呢？

圖7???蔣童（泛微網絡）

蔣童：我站在客戶的角度談一下“低代碼”平臺成熟度應該有的幾個維度：

（1）平臺界面的友好度，是否簡潔方便，學習成本比較低；

（2）“低代碼”平臺到底可以快速構建什么場景。比如簡單應用、復雜應用、業務場景能不能百分之百覆蓋到；

（3）平臺的延展性、集成性。可不可以單獨使用，還可以跟第三方做集成，這個“低代碼”平臺能不能接入我的中臺；

（4）安全性、易用性、可維護性、穩定性、和各個系統的適配性；

（5）價格。因為“低代碼”不是一個系統，是幫助客戶構建數字化落地的共建。客戶的信息系統中，將來既有OA、ERP、財務等各種專業系統，同時手里還有“低代碼”平臺，可以按需快速構建各種輕量級或者中量級的產品。

寧偉：關于評價一個技術的成熟度，我是這樣看的：如果這個技術已經存在，面臨更新改善或者組合創新，那么就用傳統方式去評估；如果它是全新的、顛覆性的、革命性的，自然也就需要用新的方式去評估才合適。

所以在評估“低代碼”成熟度之前，第一件事情是應該確定“低代碼”究竟是革命性的還是組合性的。目前的低代碼產品可以分為兩個大類，一類是剛才提到的 “模型驅動”，“模型驅動”相比于原來的軟件開發技術應該是個組合性創新。這種低代碼平臺通常用于開發比較復雜的系統，所以我們對他們的成熟度要求會高一些，按照開發企業級軟件的標準進行評估。

國外Gartner有一個報告，在 “企業級低代碼”成熟度上定義了8個指標：（1）性能；（2）高可用性和高擴展性；（3）云服務API的集成能力；（4）災難恢復；（5）企業級安全；（6）SLA；（7）應用運行監控；（8）廠商級的技術支持與培訓。

而對于另外一種類型，也就是面向業務人員使用的“表單驅動”低代碼產品來講，需要先關注它提供的新價值是否達到預期，即幫助前臺、銷售等沒有IT技能的人，做一些日常工作中用到的簡單應用，這個時候我們不應該用傳統的企業級應用開發的標準去套用。否則，我們不但是“殺雞用牛刀”，而且還在做壓制創新的事情，行業不應該往這個方向發展。所以，我認為對于不同類型的“低代碼”平臺產品應該有不同成熟度的判斷方式。

喬勝：在評價“低代碼”平臺這個新生事物時，不能僅站在技術某些細節去評價是否成熟，因為大家走的路線都不一樣，但是在不同領域形成合力。

我認為應該從3個層次來考慮“低代碼”平臺的價值：

（1）應用價值。是否能夠很方便在上面構建復雜應用，解決客戶或者行業、或者某個領域的需求；

（2）社會屬性價值。“低代碼”平臺是個革命性的工具，它的目的是為了解放程序員的勞動生產力，通過這個平臺到底為哪些行業解放生產力？解放了多少生產力？

（3）生態屬性。在現在的企業架構環境里，往往憑一個IT團隊，一個開發平臺往往很難解決所有的問題，我們希望通過一個或者少數平臺為企業做更多事情，比如最簡單的：這個平臺能夠提供多少開箱即用的應用、組件和方案，能夠引入多少業界先進的技術并將它們場景化落地，能夠為企業帶來多少技術資源。

湯爐鑫：個人認為，目前國內把“低代碼”的范圍放大了，我認為“低代碼”成熟度應該圍繞以下三點考慮：

（1）面向從業者。不懂編程的業務人員，能夠根據需求，快速搭建能夠很快解決業務問題的產品；

（2）面向業務分析師。能夠通過做業務建模后，基于少量腳本類代碼或者規則生產出需要的應用；

（3）面向開發者。有可視化的能力，來解決研發生產力的模式。

朱文靜：我們對成熟度的理解有以下幾點：

（1）用戶的滿足度。比如AI平臺，可以通過平臺實現功能全面性評價AI平臺的成熟度。

（2）穩定性。比如做數據的平臺，平臺的穩定性則非常重要。

（3）高并發性。比如平臺是否支持一家用戶有1000多人同時進行數據標注，應該怎樣處理這些高并發問題，這也是“低代碼”平臺發展過程中要處理的事情。

（4）安全性。所有平臺都離不開數據安全的問題。

（5）運行速度。比如AI平臺，線上提供GPU數據訓練時，時間周期的長短對于用戶去使用的感覺也是非常重要的。

（6）服務能力。在過程中是否有技術支持、有培訓、有無代碼開放平臺去服務客戶。

（7）性價比。一個成熟的平臺，應該能夠幫助客戶大大的解決開發的門檻、成本和周期，并且面向不同人群提供不同的可性的價格指標。

黃榮：我們評估“低代碼”產品的成熟度，是跟對象有關系的，不能拿評價杯子的標準去評價一個桌子。所以“低代碼”成熟度涉及到應用全生命周期各個環節。這是一個綜合性的東西，包括在開發上的便利性、運營性能、安全性等等一系列指標都是需要去考慮的。

“低代碼”開發和傳統開發的相同和不同是什么？

圖8 ???千鳥（社區KOL開發者）

千鳥：怎樣快速組織一個全棧能力的開發團隊，我覺得應該是“低代碼”與傳統開發最大的區別。記得讀研時，導師當時留了一個話題對我至今影響深刻。他說市面上有很多公開的API，能否直接調用公開服務做一套我們自己的應用？當時研究課題領域是WebService和標準化接口，現在移動應用如微信小程序、APP開發的最底層核心都需要調WebAPI，所以從底層開發來看，“低代碼”能否有一種能力，讓開發者更好生成或者解決底層邏輯的處理。一套完整系統的研發，在設計、研發、測試各個環節中有很多工作要做，小型研發團隊的精力有限，“低代碼”應該在傳統開發之上，讓開發人員更專注系統的架構和邏輯，盡可能降低代碼編寫的生產成本。

湯爐鑫：我認為“低代碼”本質是定義一套自己的語言體系，解決如何快速編排，建立自己的生態，讓相關的程序員或業務員在它上面做更多搭建和賦能。利用“低代碼”開發，同樣會經歷需求分析到上線發布的整套過程，中間會有高級語言做支撐，研發模式沒有發生變化，發生變化的是對組件化的要求更高了，同時語言層面有更高級語言去組織。

寧偉：基于中臺來實現前后端分離，把后端的能力進行抽象、重組，前端編排進行快速開發，是現在企業級應用開發的大方向。我們客戶中，大部分是軟件公司或者大企業IT團隊，他們是從純代碼開發的模式轉型到到低代碼，從他們給我們的反饋上看，在轉型過程中，低代碼開發團隊仍然要和寫代碼的團隊緊密配合，才能充分利用之前開發好的數據中臺，和現有的IT資產無縫集成。那么這個結合點是什么，WebAPI可能是一個非常好的實踐。這里不但需要低代碼平臺去對接用代碼寫的WebAPI，消費中臺提供的數據；還需要用低代碼構建出WebAPI，給純代碼寫的其他模塊，比如市場端的小程序，倉儲端的WMS等調用，為他們提供數據和能力，這就是我們說的雙向集成。

雙向集成是每個“低代碼”平臺廠商一定要發力去解決的事情，但我們要怎么通過自動化方式，去分析對方系統，動態建立數據模型，搭建一個WebAPI并很方便的進行調試，還需要投入更多時間和精力去研究。

費騰：傳統編碼，程序=算法+數據結構，算法和數據結構都需要開發者去思考，使用“低代碼”平臺，許多算法和數據部分都被割裂了，或者說邏輯太過松散，不夠內聚，對于開發者來說有種“黑盒”的不安全感，我認為現階段它還不適合開發核心業務。我們的“低代碼”平臺不僅只是一個“平臺”，它本身也可以作為插件或者工具，用到核心系統中里作為部分特定領域的更好實現，這樣會讓開發人員的意愿度、參與度更好一點。若想作為一個全局的核心平臺，還是需要仔細調研和決策的。

湯爐鑫 ：我是做 toB 業務的，很多業務復雜度非常高，所以我們在推動這個層面時也遇到很多挑戰，開發人員從技能提升和未來的發展，都覺得如果用類似“低代碼”中基于模型、基于表單的方式去發展核心業務，這個不太可靠。所以我們把現有的“低代碼”拆開了，“低代碼”最好的核心是讓業務不斷做抽象，它改變原來設計系統的模式，設計任何一個系統，首先圍繞“低代碼”的思想去設計，這對復雜系統的擴展性一定會有幫助。

駱勤：我認為“低代碼”是一種抽象維度更高的計算機語言，所以它作為一個語言是會進化的。剛有朋友提到“低代碼”不適合核心業務，我覺得應該辨證的看這個事情。至于普通開發的區別前面大家討論很多，早期傳統開發需要寫很多代碼、走很多構建流程，而在“低代碼”平臺下，許多工作都做到了可視化，這種區別很像是當年DOS系統與Windows系統的區別。未來的開發工作可以從鍵盤遷移到鼠標，這也是我們需要去做的事情。

鄒欣：剛才幾位老師講的核心點是跟“低代碼”這個“低”有關系，是不是用“低代碼”開發，所有的東西就低了？讓開發者感覺遠離他的核心業務？舉個例子，我們入行用C++寫代碼，開發者可以按需管理內存，后來Java，C#有獨立的內存管理機制，解放開發者管理內存的問題，有些人因此就會覺得在開發語言上略顯low，但是java，c#也同樣強大。“低代碼”是把復雜性隱藏起來以后，更關注業務邏輯，但是很多開發者會不會想，我是一個手藝人，我想寫code，把這個code寫得越靠近機器越高大上，覺得寫業務邏輯low。在“低代碼”開發認知上的不同，我想也應該能算做是有別于傳統開發的一個部分。

聊聊你的“低代碼”產品中開發者最喜歡的3個功能？

鄒欣：先拋磚引玉，這是一個買家秀，我們以前做了一個“智能表單識別”，后來很多人覺得API太難用，我們用Python把API的場景寫出來，訓練模型后，把模型填到程序中，它就成功了，有點像“填空式開發”，很多人覺得很好，能夠更快速的落地。現有的“低代碼”平臺中，用戶最喜歡的功能是什么呢？

蔣童：我們的客戶認為產品有三個比較吸引的地方：

（1）云應用商店。里面現在有1000多種應用場景，客戶也可以通過“低代碼”開發平臺可以把他們自己的應用場景上傳，所有用戶都可以通過云商店構建不同場景的應用。

（2）表單引擎。不需要懂計算機語言、不需要懂系統語言，只需導入要常用的Excel就可以構建。

（3）可視化編輯的流程引擎。通過鼠標拖拉拽，以搭積木的方式就可以快速構建各種應用場景。

寧偉：我們葡萄城最近也舉辦了一個研討會，會前針對軟件公司類型的客戶做了份問卷調查，最受歡迎的三個功能：

（1）可視化構建WebAPI的能力。我們的活字格產品，以可視化方式，提供用戶參數變量、條件判斷、事務處理、訪問權限的配置，以可視化方式構建自己的API。

（2）抹平現有數據庫差異的數據訪問能力。企業有很多不同數據庫，有些軟件用MySQL，有些用SQLServer，我們提供的一套機制，幫助他們完成在不用數據庫中的查詢、寫入、事務控制等，所有這些東西都不需要寫一行SQL，我們幫它做了數據庫翻譯工作。

（3）響應式布局的能力。類似WPF平臺grid的那套方式，用“所見即所得”的方式，同時支持絕對布局和流式布局。

李婷婷：輕流是無代碼開發平臺，面對終端業務人員更多，客戶最喜歡的是三個方面：

（1）Q系列機器人。專注表單驅動、流程驅動，它是串連人的能力。我們Q系列機器人定位是系統自動化，未來還會引入AI的方式，在信息化之上智能化；

（2）“低代碼”和無代碼平臺。提供“開箱即用”的能力，比如一些場景模板如報銷領域或工業巡檢領域，先加載一套模板，在此基礎上根據自己的需求做變更、優化和調整；

（3）開放集成的連接能力。很難有一個企業可以解決所有信息化訴求，這就帶來所有企業都需要多套系統完成信息化過程，那就需要這些信息系統之間可以協作和溝通，輕流有一部分能力是專門去做系統集成API方面的無代碼化。

喬勝：我們平臺是業務開發的“低代碼”平臺，在不久前，我們對所有開發者進行過一次調研，大家認為喜歡的功能包括：

（1）可視化開發中的沙盒測試環境。在零代碼開發中不需要切換到專門的開發環境進行打包測試，總體節省前端開發50%以上的時間；

（2）一體化自動化的DevOps云體系。全程接管了研發協同過程，除了在項目開發環境初始化時，開發者對CI/CD操作基本無感，而是將更多的精力投入到復雜業務邏輯實現中；

（3）平臺中提供了一系列的標準應用模板,實踐了基于應用級模板的開放性，極大地節省了項目交付的工作量。

朱文靜：我們在產品誕生就基于公司內部團隊在AI應用開發時候的痛點去開發的，因此AI應用開發者在做AI開發時，只要看到Slick的界面，就可以清晰地從業務邏輯去開發AI產品。

對開發者來說最喜歡的幾個功能是：

（1）模型的Pipeline，幾個AI模型疊加，可以把各種不同模型的功能組合在一起，比一個個模型的開發會效率提高非常多。

（2）AI模型開發插件，包括數據預處理，自動標注等等功能，這對AI開發來講可以以無代碼的方式進行使用。

（3）AI模型的下載。用戶在我們平臺開發完成的AI模型，我們支持H5預覽，或者API、SDK等方式部署，支持直接外部調用開發，同時也允許用戶把模型下載下來，獨立應用在其他業務場景當中。

王瀟：我們提供各種門戶，道一云是企業微信最大的一家第三方，我們的客戶非常喜歡的幾個“低代碼”場景：

（1）業務型數據中臺。比如使用我們提供的平臺，直接替代CMOA、客服、后端的管理等非常核心的業務。

（2）靈活的擴展性。我們的客戶企業，每年都在發展、在變化，業務調整和組織架構變化每年一次，這寫變化都能通過我們的“低代碼”平臺很好的切換，不會因為業務調整造成線上服務的延遲。

講講“低代碼”平臺業務最有效的產品，殺手锏級的應用？

圖9 ??寧偉（葡萄城）

寧偉：葡萄城活字格“低代碼”平臺目前應用比較廣，產品最有應用前景的領域有兩個分類：

（1）工業互聯網落地。工業互聯網時代大量傳感器產生了海量的數據和基于這些數據的分析結果，需要有大量的協同管理和數據需要處理，用原來的開發，不僅成本高，而且時間也較慢，利用“低代碼”實現數據和現有管理系統、現有管理流程之間的對接，則可以很方便完成這些工業互聯網軟件的應用落地。

（2）在企業ERP系統上的應用。很多企業上ERP，都是20年前的事情，企業內部有OA系統、ERP系統、行業軟件，而且現有的數據是打不通的，通過“低代碼”重構一個全新的數字化平臺。這個平臺對接ERP等系統，并且支持更低成本的擴展應用開發，可以很方便解決舊版系統和現在的業務無法兼容導致的許多問題，充分發揮原有IT資產的價值。

朱文靜：我們最有優勢的一個業務場景是本身企業對于自己的AI模型有非常強迭代需求的場景。傳統企業利用AI方式進行模型迭代的話，由于會面對數據處理工具不規范，模型管理和部署運維繁雜等問題，它的周期和成本非常高，所以在這個過程中使用我們Slick平臺可以更快進行模型迭代和遷移學習。比如一些智能硬件的檢測，人肉眼是沒有辦法看見的東西，這完全可以使用我們的平臺，打造出的檢測模型，迭代部分就可以變成非常輕量級的工作。

李婷婷：關于“低代碼”、無代碼在實際應用場景的這個問題，我們有一個制造業客戶十幾個工廠都在用，每個工廠成立興趣小組，每個小組是來自人事、行政、生產、車間等各個部門的人，他們定期學習這個工具，然后頭腦風暴有哪些場景可以信息化、流程化、規則化，是一種“全民開發”的概念。

我們認為輕流無代碼平臺更擅長做：

（1）長尾需求和知識產權管理。這種受眾小、低頻的場景是更適合用“低代碼”、無代碼去快速開發的。

（2）一些快速變化的新的業務。疫情前后，商業模式在變更、應用模式在變更，在快速發展變化過程中，尤其一些新業務啟動時，要求非常快速投入市場，需要有很快的信息系統支撐，有了“低代碼”、無代碼，更多新業務就可以通過這個平臺快速響應，并且在過程中可以隨時調整和優化。

駱勤：其實“低代碼”也很適合做一些簡單、很普惠的事情，比如今年的河南大雨時，應急團隊用2個小時就完成了一個互助應用的開發，效果也很好，這在平時很難做到，低代碼很適合這種應急場景。

鄒欣：“低代碼”通過四兩撥千斤的方式，在許多應用場景是真正解決了用戶痛點。對我們的啟示：我們無需考慮“低代碼”解決的是何種問題，即便很少有人用的功能，如果這個功能解決好，相信“低代碼”以后的機會也是特別大的。

2022年初，CSDN就接力展開了關于“低代碼”開發者應用體驗的第二季調研活動。隨后即將在廣州、杭州、成都、西安、武漢組織研討會，您可以閱讀原文參與調研，期待您的參與！

閱讀原文：CSDNhttps://marketing.csdn.net/questions/Q2112311644034199411?utm_source=lowcodeyuanwenyun

總結

以上是生活随笔為你收集整理的CSDN企业数字化之路 ——「低代码」发展研讨会北京站现场实录大放送的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。