作者 | 甄子
概念
什麼是低代碼/無代碼開發？業界對于低代碼/無代碼開發是否存在其他不同的了解？
行業裡流行觀點，低代碼是更加易用的搭建系統，無代碼是圖形化和可視化程式設計。這種觀點把低代碼和無代碼開發分别置于 UI 和邏輯兩個環節，以工具屬性定義搭建和可視化程式設計要解決的問題。另一種觀點則是把低代碼/無代碼看作一個方法的兩個階段，就像對自動駕駛的 L0 ~ L5 共 6 個不同階段一樣，把我之前在：
https://juejin.cn/post/6844904116708196365《人機協同的程式設計方式》 一文提出的人機協同程式設計的概念，劃分為低代碼/無代碼兩個階段。較之第一種我更加認同第二種觀點，不僅因為是我提出的，更因為第二種觀點是以軟體工程的統一視角定義、分析和解決問題，而第一種觀點隻是局部和過程的優化而非颠覆性創新。
如馬雲先生在香港對年輕人傳授創業經驗時講到的，蒸汽機和電力解放了人類的體力，人工智能和機器學習解放了人類的腦力。馬雲先生在評價蒸汽機和電力帶來的失業問題時講到，人類在科技進步下從繁重的體力勞動中解放出來，逐漸向腦力勞動過渡，這是人類社會的進步。今天“人機協同的程式設計方式”把軟體工程從拼裝 UI 和編寫業務邏輯裡解放出來，逐漸向業務能力、基礎能力、底層能力等高技術含量工作過渡。更多内容參考：
https://juejin.cn/post/6844904104448393223《前端智能化：思維轉變之路》
低代碼開發和無代碼開發之間的差別是什麼？
接着上述所答，既然低代碼和無代碼屬于“人機協同程式設計”的兩個階段，低代碼就是階段一、無代碼則是階段二，分别對應“人機協作”和“人機協同”。協作和協同最大的差別就是：心有靈犀。不論低代碼還是無代碼，均有服務的對象：使用者。不論使用者是程式員還是非程式設計人員，均有統一目标：生成代碼。不論源碼開發、低代碼還是無代碼，都是在用不同的方式描述程式，有代碼、圖形、DSL……等。“人機協作”的階段，這些描述有各種限制、限制，應用的業務場景亦狹窄。“人機協同”的階段，則限制、限制減少，應用的業務場景亦寬廣。“心有靈犀”就是指：通過 AI 對描述進行學習和了解，進而減少限制和限制，适應更多業務場景。是以，傳統低代碼/無代碼和“人機協同程式設計”生成代碼相比，最大的不同就是有心和無心，機器有心而平台無心。
背景
低代碼/無代碼開發與軟體工程領域的一些經典思想、方法和技術，例如軟體複用與構件組裝、軟體産品線、DSL（領域特定語言）、可視化快速開發工具、可定制工作流，以及此前業界流行的中台等概念，之間是什麼關系？
從庫、架構、腳手架開始，軟體工程就踏上了追求效率的道路。在這個道路之上，低代碼、無代碼的開發方式算是宏願。複用、元件化和子產品化、DSL、可視化、流程編排……都是在達成宏願過程中的嘗試，要麼在不同環節、要麼以不同方式，但都還在軟體工程領域内思考。中台概念更多是在業務視角下提出的，軟體工程和技術領域内類似的概念更多是叫：平台。不論中台還是平台，就不僅是在過程中的嘗試，而是整體和系統的創新嘗試。我提出前端智能化的“人機協同程式設計”應該同屬于軟體工程和技術領域，在類似中台的業務領域我提出“需求暨生産”的全新業務研發模式，則屬于業務領域。這些概念之間無非：左右、上下、新舊關系而已。
此外，低代碼/無代碼開發與DevOps、雲計算與雲原生架構之間又是什麼樣的關系？
DevOps、雲計算……都屬于基礎技術，基礎技術的變化勢必帶來上層應用層技術變化。沒有雲計算的容器化、彈性縮擴容，做分布式系統是很困難的，尤其在 CI/CD、部署、運維、監控、調優……等環節更甚，什麼南北分布、異地多活、平行擴充、高可用……都需要去關注。但是，雲計算和DevOps等基礎技術的發展，内化并自動化解決了上述問題，大大降低了關注和使用成本，這就是心有靈犀，在這樣的基礎技術之上建構應用層技術，限制少、限制小還能适應各種複雜場景。
思想方法
支撐低代碼/無代碼開發的核心技術是什麼？
我認為低代碼/無代碼開發的核心技術，過去是“複用”，今天是 AI 驅動的“人機協同程式設計”。過去的低代碼/無代碼開發多圍繞着提升研發效能入手，今天 AI 驅動的“人機協同程式設計”則是圍繞着提升傳遞效率入手。是以，低代碼/無代碼開發以“人機協同程式設計”為主要實作手段的話，AI 是其核心技術。
低代碼/無代碼開發的火熱是軟體開發技術上的重要變革和突破，還是經典軟體工程思想、方法和技術随着技術和業務積累的不斷發展而煥發出的新生機？
計算機最初隻在少數人掌握，如今，幾乎人人手持一台微型計算機：智慧手機。當初為程式員和所謂“技術人員”的專利，而今，幾乎人人都會操作和使用計算機。然而，人們對計算機的操作是間接的，需要有專業的人士和企業提前編寫軟體，人們通過軟體使用計算機的各種功能。随着計算機算力和功能的不斷發展，随着社會的數字化和資訊化，今天的人們越來越難以被提前定制好的軟體所滿足。低代碼/無代碼開發則賦予人們創造軟體的能力，進而幫助人們低成本、即時、高效的直接生産符合自己需求的軟體，進而操作衆多複雜的電子裝置和數字世界建立聯結。我認為，這是不可逆的趨勢，也是低代碼/無代碼開發的大方向。
現狀進展
低代碼/無代碼開發已經發展到什麼程度？
- 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
- 開源了 https://github.com/alibaba/pipcook 純前端機器學習架構
- 利用 Boa 打通 Python 技術生态，原生支援 import Python 流行的包和庫，原生支援 Python 的資料類型和資料結構，友善跨語言共享資料和調用 API
- 利用 Pipcook Cloud 打通流行的雲計算平台，幫助前端智能化實作 CDML，形成資料和算法工程閉環，幫助開發者打造工業級可用的服務和線上、離線算法能力
有哪些成熟的低代碼/無代碼開發平台？
低代碼/無代碼開發能夠在多大程度上改變目前的軟體開發方式？
随着計算機算力和功能的不斷發展，随着社會的數字化和資訊化，今天的人們越來越難以被提前定制好的軟體所滿足。低代碼/無代碼開發則賦予人們創造軟體的能力，進而幫助人們低成本、即時、高效的直接生産符合自己需求的軟體，進而操作衆多複雜的電子裝置和數字世界建立聯結。我認為，這是不可逆的趨勢，也是低代碼/無代碼開發的大方向。最終，軟體開發勢必從專業程式員手裡轉向普羅大衆，成為今天操作計算機一樣的基本生存技能之一。是以，軟體開發方式将帶來本質變化，從完整的傳遞轉向局部傳遞、從業務整體傳遞轉向業務能力傳遞……。
展望未來
低代碼/無代碼開發未來發展的方向是什麼？
要我說，低代碼/無代碼開發未來發展的方向一定是：AI 驅動的“人機協同程式設計”，将完整開發一個軟體變成提供局部的軟體功能，類似 Apple 的“捷徑”一樣，由使用者決定這些局部軟體功能如何組裝成适合使用者的軟體并傳遞最終使用者。AI 驅動提供兩個方面的價值：
- 降低開發成本
以往開發軟體的時候，要有 PRD、互動稿、設計稿、設計文檔……等一系列需求規格說明，然後，根據這些需求規格利用技術和工程手段進行實作。然而，低代碼/無代碼開發傳遞的是局部功能和半成品，會被無法枚舉的目的和環境所使用，既然無法枚舉，就不能用 Swith……Case 的方式編寫代碼，否則會累死。
AI 的特點就是基于特征和環境進行預測，預測的基礎是對模式和本質的了解。就像 AI 識别一隻貓，不管這個貓在什麼環境、什麼光照條件下，也不管這隻貓是什麼品種，AI 都能夠以超過人類的準确度識别。試想，作為一個程式員用程式判斷一隻貓的開發成本何其高？
- 降低使用成本
今天的搭建體系，本質上是把程式設計過程用搭建的思想重構了一遍，工作的内容并沒有發生變化，成本從程式員轉嫁到營運、産品、設計師的身上。這還是其次，今天的搭建平台都是技術視角出發，充斥着營運、産品、設計等非技術人員一臉懵逼的概念，花在答疑解惑和教他們如何在頁面上定制一個搜尋框的時間，比自己和他們溝通後源碼實作的時間還要長，而且經常在撸代碼的時候被打斷……
基于 AI 的“人機協同程式設計”不需要透出任何技術概念，營運、産品、設計……等非技術人員也不改變其工作習慣，都用自己熟悉的工具和自己熟悉的概念描述自己的需求，AI 負責對這些需求進行識别和了解，再轉換成程式設計和技術工程領域的概念，進而生成代碼并傳遞，進而大幅度降低使用成本。
舉個例子：如果你英文寫作能力不好，你拿着朗道詞典一邊翻譯一邊拼湊單詞寫出來的英文文章品質高呢？還是用中文把文章寫好，再使用 Google 翻譯整篇轉換成英文的文章品質高？你自己試試就知道了。究其原因，你在自己熟悉的語言和概念領域内，才能夠把自己的意思表達清楚。
圍繞低代碼/無代碼開發存在哪些技術難題需要學術界和工業界共同探索？
最初在 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 發展的浪潮”的初心上路，到“解決一線研發問題”釋出
http://imgcook.com，再到“給前端靠譜的機器學習架構”開源
http://github.com/alibaba/pipcook，這一路走來，幾乎日日夜不能寐。真正想從本質上颠覆現在的程式設計模式和研發模式談何容易？這個過程中，我們從一群純前端變成前端和 AI 的跨界程式員，開發方式從寫代碼到機器生成，周圍的人從作壁上觀到積極參與，正所謂：念念不忘，必有回響。低代碼/無代碼開發方興未艾，廣大技術、科研人員在這個方向上厲兵秣馬，沒有哪個方法是 Silverbullet ，也沒有哪個理論是絕對正确的，隻要找到你心中所愛，堅持研究和實踐，終會讓所有人都能夠自定義軟體來操作日益複雜和強大的硬體裝置，終能讓所有人更加便捷、直接、有效的接入數字世界，終于在本質上将軟體開發和軟體工程領域重新定義！共勉！