從前端智慧化看“低程式碼無程式碼”

一 概念

1 什麼是低程式碼/無程式碼開發？業界對於低程式碼/無程式碼開發是否存在其他不同的理解？

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

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

2 低程式碼開發和無程式碼開發之間的區別是什麼？

接著上述所答，既然低程式碼和無程式碼屬於“人機協同程式設計”的兩個階段，低程式碼就是階段一、無程式碼則是階段二，分別對應“人機協作”和“人機協同”。協作和協同最大的區別就是：心有靈犀。不論低程式碼還是無程式碼，均有服務的物件：使用者。不論使用者是程式設計師還是非程式設計人員，均有統一目標：生成程式碼。不論原始碼開發、低程式碼還是無程式碼，都是在用不同的方式描述程式，有程式碼、圖形、DSL……等。“人機協作”的階段，這些描述有各種限制、約束，應用的業務場景亦狹窄。“人機協同”的階段，則限制、約束減少，應用的業務場景亦寬廣。“心有靈犀”就是指：透過 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 ，也沒有哪個理論是絕對正確的，只要找到你心中所愛，堅持研究和實踐，終會讓所有人都能夠自定義軟體來操作日益複雜和強大的硬體裝置，終能讓所有人更加便捷、直接、有效的接入數字世界，終於在本質上將軟體開發和軟體工程領域重新定義！共勉！

相關連結

［1］https：//juejin。cn/post/6844904116708196365［2］https：//juejin。cn/post/6844904104448393223［3］https：//github。com/alibaba/pipcook［4］http：//imgcook。com

作者 | 甄子