簡介：?什么是低代碼/無代碼開發？業界對于低代碼/無代碼開發是否存在其他不同的理解？低代碼開發和無代碼開發之間的區別是什么？

作者 | 甄子
來源 | 阿里技術公眾號

一 概念

1 什么是低代碼/無代碼開發？業界對于低代碼/無代碼開發是否存在其他不同的理解？

行業里流行觀點，低代碼是更加易用的搭建系統，無代碼是圖形化和可視化編程。這種觀點把低代碼和無代碼開發分別置于 UI 和邏輯兩個環節，以工具屬性定義搭建和可視化編程要解決的問題。另一種觀點則是把低代碼/無代碼看作一個方法的兩個階段，就像對自動駕駛的 L0 ~ L5 共 6 個不同階段一樣，把我之前在《人機協同的編程方式》[1] 一文提出的人機協同編程的概念，劃分為低代碼/無代碼兩個階段。較之第一種我更加認同第二種觀點，不僅因為是我提出的，更因為第二種觀點是以軟件工程的統一視角定義、分析和解決問題，而第一種觀點只是局部和過程的優化而非顛覆性創新。

今天“人機協同的編程方式”把軟件工程從拼裝 UI 和編寫業務邏輯里解放出來，逐步向業務能力、基礎能力、底層能力等高技術含量工作過渡。更多內容參考《前端智能化：思維轉變之路》[2]。

2 低代碼開發和無代碼開發之間的區別是什么？

接著上述所答，既然低代碼和無代碼屬于“人機協同編程”的兩個階段，低代碼就是階段一、無代碼則是階段二，分別對應“人機協作”和“人機協同”。協作和協同最大的區別就是：心有靈犀。不論低代碼還是無代碼，均有服務的對象：用戶。不論用戶是程序員還是非編程人員，均有統一目標：生成代碼。不論源碼開發、低代碼還是無代碼，都是在用不同的方式描述程序，有代碼、圖形、DSL……等?！叭藱C協作”的階段，這些描述有各種限制、約束，應用的業務場景亦狹窄?！叭藱C協同”的階段，則限制、約束減少，應用的業務場景亦寬廣?！靶挠徐`犀”就是指：通過 AI 對描述進行學習和理解，從而減少限制和約束，適應更多業務場景。因此，傳統低代碼/無代碼和“人機協同編程”生成代碼相比，最大的不同就是有心和無心，機器有心而平臺無心。

二 背景

1 低代碼/無代碼開發與軟件工程領域的一些經典思想、方法和技術，例如軟件復用與構件組裝、軟件產品線、DSL（領域特定語言）、可視化快速開發工具、可定制工作流，以及此前業界流行的中臺等概念，之間是什么關系？

從庫、框架、腳手架開始，軟件工程就踏上了追求效率的道路。在這個道路之上，低代碼、無代碼的開發方式算是宏愿。復用、組件化和模塊化、DSL、可視化、流程編排……都是在達成宏愿過程中的嘗試，要么在不同環節、要么以不同方式，但都還在軟件工程領域內思考。中臺概念更多是在業務視角下提出的，軟件工程和技術領域內類似的概念更多是叫：平臺。不論中臺還是平臺，就不僅是在過程中的嘗試，而是整體和系統的創新嘗試。我提出前端智能化的“人機協同編程”應該同屬于軟件工程和技術領域，在類似中臺的業務領域我提出“需求暨生產”的全新業務研發模式，則屬于業務領域。這些概念之間無非：左右、上下、新舊關系而已。

2 此外，低代碼/無代碼開發與DevOps、云計算與云原生架構之間又是什么樣的關系？

DevOps、云計算……都屬于基礎技術，基礎技術的變化勢必帶來上層應用層技術變化。沒有云計算的容器化、彈性縮擴容，做分布式系統是很困難的，尤其在 CI/CD、部署、運維、監控、調優……等環節更甚，什么南北分布、異地多活、平行擴展、高可用……都需要去關注。但是，云計算和DevOps等基礎技術的發展，內化并自動化解決了上述問題，大大降低了關注和使用成本，這就是心有靈犀，在這樣的基礎技術之上構建應用層技術，限制少、約束小還能適應各種復雜場景。

三 思想方法

1 支撐低代碼/無代碼開發的核心技術是什么？

我認為低代碼/無代碼開發的核心技術，過去是“復用”，今天是 AI 驅動的“人機協同編程”。過去的低代碼/無代碼開發多圍繞著提升研發效能入手，今天 AI 驅動的“人機協同編程”則是圍繞著提升交付效率入手。因此，低代碼/無代碼開發以“人機協同編程”為主要實現手段的話，AI 是其核心技術。

2 低代碼/無代碼開發的火熱是軟件開發技術上的重要變革和突破，還是經典軟件工程思想、方法和技術隨著技術和業務積累的不斷發展而煥發出的新生機？

計算機最初只在少數人掌握，如今，幾乎人人手持一臺微型計算機：智慧手機。當初為程序員和所謂“技術人員”的專利，而今，幾乎人人都會操作和使用計算機。然而，人們對計算機的操作是間接的，需要有專業的人士和企業提前編寫軟件，人們通過軟件使用計算機的各種功能。隨著計算機算力和功能的不斷發展，隨著社會的數字化和信息化，今天的人們越來越難以被提前定制好的軟件所滿足。低代碼/無代碼開發則賦予人們創造軟件的能力，進而幫助人們低成本、即時、高效的直接生產符合自己需求的軟件，進而操作眾多復雜的電子設備和數字世界建立聯結。我認為，這是不可逆的趨勢，也是低代碼/無代碼開發的大方向。

四 現狀進展

1 低代碼/無代碼開發已經發展到什么程度？

imgcook

• 2w 多用戶、6w 多模塊、 0 前端參與研發的雙十一等大促營銷活動、70% 阿里前端在使用
• 79.26% 無人工參與的線上代碼可用率、90.9% 的還原度、Icon 識別準確率 83%、組件識別 85%、布局還原度 92.1%、布局人工修改概率 75%
• 研發效率提升 68%

uicook

• 營銷活動和大促場景 ui 智能生成比例超過 90%
• 日常頻道導購業務 ui 智能生成覆蓋核心業務
• 純 ui 智能化和個性化帶來的業務價值提升超過 8%

bizcook

• 初步完成基于 NLP 的需求標注和理解系統
• 初步完成基于 NLP 的服務注冊和理解系統
• 初步完成基于 NLP 的膠水層業務邏輯代碼生成能力

reviewcook

• 針對資損防控自動化掃描、CV 和 AI 自動化識別資損風險和輿情問題
• 和測試同學共建的 UI 自動化測試、數據渲染和 Mock 驅動的業務自動化驗證
• 和工程團隊共建的 AI Codereview 基于對代碼的分析和理解，結合線上 Runtime 的識別和分析，自動化發現問題、定位問題，提升 Codereview 的效率和質量

datacook

• 社區化運營開源項目，合并 Denfo.js 同其作者共同設立 Datacook 項目，全鏈路、端到端解決 AI 領域數據采集、存儲、處理問題，尤其在海量數據、數據集組織、數據質量評估等深度學習和機器學習領域的能力比肩 HDF5、Pandas……等 Python 專業 LIbrary
• Google Tensorflow.js 團隊合作開發維護 TFData library ，作為 Datacook 的核心技術和基礎，共同構建數據集生態和數據集易用性

pipcook

• 開源了 pipcook[3] 純前端機器學習框架
• 利用 Boa 打通 Python 技術生態，原生支持 import Python 流行的包和庫，原生支持 Python 的數據類型和數據結構，方便跨語言共享數據和調用 API
• 利用 Pipcook Cloud 打通流行的云計算平臺，幫助前端智能化實現 CDML，形成數據和算法工程閉環，幫助開發者打造工業級可用的服務和在線、離線算法能力

2 有哪些成熟的低代碼/無代碼開發平臺？

3 低代碼/無代碼開發能夠在多大程度上改變當前的軟件開發方式？

隨著計算機算力和功能的不斷發展，隨著社會的數字化和信息化，今天的人們越來越難以被提前定制好的軟件所滿足。低代碼/無代碼開發則賦予人們創造軟件的能力，進而幫助人們低成本、即時、高效的直接生產符合自己需求的軟件，進而操作眾多復雜的電子設備和數字世界建立聯結。我認為，這是不可逆的趨勢，也是低代碼/無代碼開發的大方向。最終，軟件開發勢必從專業程序員手里轉向普羅大眾，成為今天操作計算機一樣的基本生存技能之一。因此，軟件開發方式將帶來本質變化，從完整的交付轉向局部交付、從業務整體交付轉向業務能力交付……

五 展望未來

1 低代碼/無代碼開發未來發展的方向是什么？

要我說，低代碼/無代碼開發未來發展的方向一定是：AI 驅動的“人機協同編程”，將完整開發一個軟件變成提供局部的軟件功能，類似 Apple 的“捷徑”一樣，由用戶決定這些局部軟件功能如何組裝成適合用戶的軟件并交付最終用戶。AI 驅動提供兩個方面的價值：

降低開發成本

以往開發軟件的時候，要有 PRD、交互稿、設計稿、設計文檔……等一系列需求規格說明，然后，根據這些需求規格利用技術和工程手段進行實現。然而，低代碼/無代碼開發交付的是局部功能和半成品，會被無法枚舉的目的和環境所使用，既然無法枚舉，就不能用 Swith……Case 的方式編寫代碼，否則會累死。

AI 的特點就是基于特征和環境進行預測，預測的基礎是對模式和本質的理解。就像 AI 識別一只貓，不管這個貓在什么環境、什么光照條件下，也不管這只貓是什么品種，AI 都能夠以超過人類的準確度識別。試想，作為一個程序員用程序判斷一只貓的開發成本何其高？

降低使用成本

今天的搭建體系，本質上是把編程過程用搭建的思想重構了一遍，工作的內容并沒有發生變化，成本從程序員轉嫁到運營、產品、設計師的身上。這還是其次，今天的搭建平臺都是技術視角出發，充斥著運營、產品、設計等非技術人員一臉懵逼的概念，花在答疑解惑和教他們如何在頁面上定制一個搜索框的時間，比自己和他們溝通后源碼實現的時間還要長，而且經常在擼代碼的時候被打斷……

基于 AI 的“人機協同編程”不需要透出任何技術概念，運營、產品、設計……等非技術人員也不改變其工作習慣，都用自己熟悉的工具和自己熟悉的概念描述自己的需求，AI 負責對這些需求進行識別和理解，再轉換成編程和技術工程領域的概念，進而生成代碼并交付，從而大幅度降低使用成本。

舉個例子：如果你英文寫作能力不好，你拿著朗道詞典一邊翻譯一邊拼湊單詞寫出來的英文文章質量高呢？還是用中文把文章寫好，再使用 Google 翻譯整篇轉換成英文的文章質量高？你自己試試就知道了。究其原因，你在自己熟悉的語言和概念領域內，才能夠把自己的意思表達清楚。

2 圍繞低代碼/無代碼開發存在哪些技術難題需要學術界和工業界共同探索？

最初在 D2 上提出并分享“前端智能化”這個概念的時候，我就提出：識別、理解、表達 這個核心過程。我始終認為，達成 AI 驅動的“人機協同編程”關鍵路徑就是：識別、理解、表達。因此，圍繞 AI 識別、 AI 理解、 AI 表達我們和國內外知名大學展開了廣泛的合作。

識別

• 需求的識別：通過 NLP 、知識圖譜、圖神經網絡、結構化機器學習……等 AI 技術，識別用戶需求、產品需求、設計需求、運營需求、營銷需求、研發需求、工程需求……等，識別出其中的概念和概念之間的關系
• 設計稿的識別：通過 CV、GAN、對象識別、語義分割……等 AI 技術，識別設計稿中的元素、元素之間的關系、設計語言、設計系統、設計意圖
• UI 的識別：通過用戶用腳投票的結果進行回歸，后驗的分析識別出 UI 對用戶行為的影響程度、影響效果、影響頻率、影響時間……等，并識別出 UI 的可變性和這些用戶行為影響之間的關系
• 計算機程序的識別：通過對代碼、AST ……等 Raw Data 分析，借助 NLP 技術識別計算機程序中，語言的表達能力、語言的結構、語言中的邏輯、語言和外部系統通過 API 的交互等
• 日志和數據的識別：通過對日志和數據進行 NLP、回歸、統計分析等方式，識別出程序的可用性、性能、易用性等指標情況，并識別出影響這些指標的日志和數據出自哪里，找出其間的關系

理解

• 橫向跨領域的理解：對識別出的概念進行降維，從而在底層更抽象的維度上找出不同領域之間概念的映射關系，從而實現用不同領域的概念進行類比，進而在某領域內理解其它領域的概念
• 縱向跨層次的理解：利用機器學習和深度學習的 AI 算法能力，放寬不同層次間概念的組成關系，對低層次概念實現跨層次的理解，進而形成更加豐富的技術、業務能力供給和使用機會
• 常識、通識的理解：以常識、通識構建的知識圖譜為基礎，將 AI 所面對的開放性問題領域化，將領域內的常識和通識當做理解的基礎，不是臆測和猜想，而是實實在在構建在理論基礎上的理解

表達

• 個性化：借助大數據和算法實現用戶和軟件功能間的匹配，利用 AI 的生成能力降低千人前面的研發成本，從而真正實現個性化的軟件服務能力，把軟件即服務推向極致
• 共情：利用端智能在用戶側部署算法模型，既可以解決用戶隱私保護的問題，又可以對用戶不斷變化的情緒、訴求、場景及時學習并及時做出響應，從而讓軟件從程序功能的角度急用戶之所急、想用戶之所想，與用戶共情、讓用戶共鳴。舉個例子：我用 iPhone 在進入地鐵站的時候，因為現在要檢查健康碼，每次進入地鐵站 iOS 都會給我推薦支付寶快捷方式，我不用自己去尋找支付寶打開展示健康碼，這就讓我感覺 iOS 很智能、很貼心，這就是共情。

六 后記

從提出前端智能化這個概念到現在已歷三年，最初，保持著“讓前端跟上 AI 發展的浪潮”的初心上路，到“解決一線研發問題”發布[4]，再到“給前端靠譜的機器學習框架”開源[3] ，這一路走來，幾乎日日夜不能寐。真正想從本質上顛覆現在的編程模式和研發模式談何容易？這個過程中，我們從一群純前端變成前端和 AI 的跨界程序員，開發方式從寫代碼到機器生成，周圍的人從作壁上觀到積極參與，正所謂：念念不忘，必有回響。低代碼/無代碼開發方興未艾，廣大技術、科研人員在這個方向上厲兵秣馬，沒有哪個方法是 Silverbullet ，也沒有哪個理論是絕對正確的，只要找到你心中所愛，堅持研究和實踐，終會讓所有人都能夠自定義軟件來操作日益復雜和強大的硬件設備，終能讓所有人更加便捷、直接、有效的接入數字世界，終于在本質上將軟件開發和軟件工程領域重新定義！共勉！

原文鏈接

本文為阿里云原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的从前端智能化看“低代码/无代码”的全部內容，希望文章能夠幫你解決所遇到的問題。

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