規則這篇應該叫做“數字技術名詞解釋—低代碼”，但之前的名詞解釋篇都是一兩天草就，這篇磨蹭了半個多月，七七八八寫了過萬字，于是做一把標題黨。

低代碼這個概念今年極火，爭議也極大。有些人力捧，覺得以后“人人都是程序員”，， 又有不少人嗤之以鼻，如有ERP老兵譏諷《低代碼，不要以比“中臺”還快的速度臭大街》，有ThoughtWorks中國某徐姓CTO怒斥《“行業毒瘤”低代碼》，還有很多認為低代碼是新瓶裝舊酒，早已有之，或者無非就是個高級外包。可惜的是，無論支持還是鄙夷，各路專家寫文都是“草就”，至今也沒一篇三觀正且詳實的。阿朱的幾篇三觀是正，但行文也過于簡明，可能懂的自然懂，不懂的還是不懂。

本文希望對這個當前動蕩不安的領域做一點“不草就”的綜合說明，想說清楚七大問題：低代碼和無代碼（也稱零代碼）是什么關系、怎么判斷一個低代碼平臺是否專業、國內是否有專業的低代碼平臺、低代碼是不是新瓶裝舊酒、低代碼真的搞不定專業的企業應用嗎、低代碼不適合開發哪些應用、低代碼并非銀彈。

鑒于這個領域現在實在太亂，希望大家能多轉發一下，讓更多的人正確理解低代碼。

01低代碼和無代碼是兩回事

第一步得把低代碼和無代碼分清楚，因為這倆差異巨大，但現在業界經常混為一談，導致很多很多問題，比如雙方爭論但指的不是同一個事情，廠商的口徑亂，行業報告的結果不能看。

低代碼專指低代碼應用開發平臺（LCAP），是一個被業界廣泛認可的概念，頭部的分析機構如Forrester和Gartner都已經發布了多年低代碼開發平臺的報告。如下圖所示，大家可以看到這兩家的報告入選的產品都很接近，特別是頭部的六家簡直是一模一樣。這說明低代碼應用開發平臺已經是一個比較成熟的市場。

相反，分析機構對無代碼的態度就很微妙了。雖然也有一些分析機構也提無代碼開發平臺的概念，如G2（當然更不用說目前混亂的國內分析機構），但Forrester和Gartner從未發布過無代碼開發平臺的報告。Forrester和Gartner倒也不是說無代碼是個偽概念，他們的共識是無代碼這個詞只是一個營銷用語，主要用來突出一個工具無需編程基礎，消除業務用戶的恐懼。

‘No-code’ is a marketing term, implying the tool is for non-professional developers. — By Gartner

(https://appian.com/resources/resource-center/analyst-reports/gartner-quick-answer-low-code-vs-no-code-dev-tools.html)

Businesspeople hankering to deliver their own apps love the “no-code” message. Thus, “no-code” has become a marker for products aimed at empowering business users. However, customers report that even powerful low-code platforms in some cases can’t produce apps without any coding. So what does this mean for the “no-code” promise? — By Forrester

(https://go.forrester.com/blogs/watch-your-language-low-code-and-no-code-are-not-the-same/)

無代碼這個詞通常用來形容一些細分領域的開發工具，最常見的是應用搭建平臺（國外一般叫App Builder之類），如國外的Appy Pie、國內的宜搭、簡道云等，還可以用來形容Airtable / AppSheet / Treelab這類在線表單工具或輕流這類的工作流工具。這幾類工具差別巨大，如下圖所示，還有人將無代碼和低代碼的江湖分成十二個“門派”，由此可見無代碼是一個相當寬泛的概念。

但無代碼的“通用”開發平臺，目前看并不存在，據我看將來也不會存在。因為開發軟件必然要編寫邏輯，就必然要寫代碼，除非哪一天人工智能能做到自動寫代碼。

我覺得低代碼和無代碼的關系有點類似于關系數據庫和NoSQL。關系數據庫專指一種特定的數據庫，即便多家廠商的產品實現可能千差萬別，但至少提供的功能很相似，都高度遵循SQL標準。低代碼開發平臺雖然今天的標準化程度還沒關系數據庫這么高，但無論是Gartner還是Forrester都已經開始給出比較清晰的篩選標準，如要支持通用場景（如UI、邏輯和數據三層都要有）、要滿足專業開發需求等，隨著行業發展標準化程度肯定會進一步提高。NoSQL則只要不是SQL都算，不管你是KV、wide-column、文檔還是圖，都可以叫NoSQL。NoSQL這個詞熱了有幾年，但現在不太講了，因為市場格局開始清晰之后，大家就不會關注過于寬泛的NoSQL，而是根據需要關注具體的類型。我個人認為無代碼這個詞將來也一樣會慢慢淡出，雖然現在十二個門派很是熱鬧，但不出幾年真正有影響力的門派肯定也不多，這時大家也就不關注無代碼而是直接找具體的產品了。

本文后續只專注討論面向通用應用開發的低代碼。低代碼不是一個想吸引業務用戶的用語，業務人員見了“代碼”兩個字就嚇跑了，再低也沒用，如果業務人員寫不了100行代碼的話，那10行也一樣寫不了。低代碼平臺主要面向專業開發，這點已經是頭部分析機構的共識，雖然Forrester之前走過彎路，曾經也發布過面向業務人員的低代碼開發平臺報告，但近兩年已經不再發布了，只保留面向專業開發者的低代碼報告。用戶數據也說明這一點，21CTO在《低代碼開發可不低，用戶仍需要與IT技術部門聯手》一文中提到據某統計“只有6%的低代碼開發是由業務人員完成的”，OutSystems的數據是69%的用戶是專業開發，宜創科技CEO宜博也曾說低代碼面臨“懂技術的看不上，懂業務的學不會”的尷尬。

所以無代碼和低代碼完全不同，無代碼面向業務人員，低代碼面向開發人員；無代碼泛指多種開發細分領域應用的工具，低代碼特指一種通用開發工具；無代碼不被國際頭部分析機構認可，低代碼被廣泛認可。

現在國內很多行業專家和分析機構經常把兩者混為一談，這對技術的價值衡量、甲方的技術規劃和選型都造成很大混亂，我迫切希望大家能夠把低代碼和無代碼區分開，集中研究具備通用能力的低代碼平臺。

02專業的低代碼長啥樣

現在市場上魚龍混雜號稱“低代碼”的產品很多，怎么才能快速區分是不是“專業”？很簡單，找一個最專業的產品來對標。

哪個產品才是最專業的？我們可以先看為什么低代碼這兩三年才熱起來？不是因為Salesforce這樣的SaaS廠商，也不是Appian這類BPMS廠商，這輪低代碼熱其實主要是因為OutSystems。OutSystems雖然也早在2001年就成立，但之前一直“猥瑣發育”，2018年D融資了$3.6億，才突然引爆市場。無論Forrester還是Gartner都把OutSystems列入領導者象限，阿朱說他最推崇的低代碼平臺就四個，OutSystems也是其中之一。所以，OutSystems就是專業低代碼平臺的代表。

對比OutSystems和很多國內所謂的低代碼平臺，我找出了六項區分度最高的判斷標準：模型驅動、可視化開發、表達式語言、軟件工程、開放集成和腳本語言。

（1）模型驅動

“模型驅動”可能是最明顯的區分標志，因為剛好有一個也很流行的概念叫“表單驅動”。很多人搞不清楚這兩個概念，但其實這兩類產品挺好區分。

首先可以看用戶手冊，這樣不用安裝試用也能看出差別。使用模型驅動的平臺比如OutSystems、Mendix的手冊會有很大一章講怎么做數據建模和處理，包括怎么定義實體、實體間關系、主鍵、唯一性、索引、數據怎么訪問、篩選、分組、統計等等，還提供SQL或類似擴展。使用表單驅動的產品則往往手冊第一章就是說明怎么定義各種表單，都是各種和界面相關的控件，比如單選多選下拉框、文本日期數字等。

其次可以看界面。下圖是分別是模型驅動的OutSystems和某表單驅動產品的相關操作界面，大家看是不是很不一樣。

（模型驅動，OutSystems）

（表單驅動）

（2）可視化開發

可視化開發不是拖拉拽做個界面（這只能叫可視化設計），而是有完整的可視化編程語言系統，能夠編寫業務處理邏輯。看OutSystems這類產品的文檔，你會發現很多編程語言的基本構造都有，比如順序 / 分支 / 循環 / continue / break、輸入輸出參數、局部變量 / 全局變量、struct和list、異常等。雖然這些東西都是拖拉拽完成，看上去沒有密密麻麻的一行行代碼來嚇人，但也足以嚇退業務人員。一下幾張圖都來自于OutSystems，大家可以感受一下。

（左：邏輯開發工具箱，注意有If、Switch、For Each流程控制；右：一個比較簡單的邏輯）

（怎么拋出和處理異常）

（3）表達式語言

表達式語言有些類似Excel里的公式，有表達式語言才可以做一些比較復雜的計算。下圖是OutSystems的表達式編輯器，大家可以看到有各種操作符，還有很多內置函數，比如數學函數、字符串處理函數等。

OutSystems這個例子看起來還比較簡單，但表達式語言也可以很復雜。微軟是搞語言的行家，下圖是個微軟Power Fx的例子，這個表達式是要提取一個句子最后一個單詞的表達式，也挺復雜吧（說實話我看了好大一陣子才看懂）。

表達式語言也有更平易近人的設計，比如我們輕舟就是用類似Scratch的積木塊設計。兩種設計功能上是等價的，積木塊設計更容易上手，Power Fx這樣的設計寫復雜表達式更方便。

（4）軟件工程

專業的低代碼平臺需要提供測試、debug、版本控制等軟件工程支持。開發軟件都會出bug（低代碼平臺基本消除了語法層面的bug，但對語義層面的bug一樣無能為力），需求也總是會變。所以測試、debug、版本控制這些支持也是必不可少的。OutSystems為什么做的最好，我覺得跟它完善的debug支持是分不開的。下圖是OutSystems的debug界面，看起來和專業IDE有的一拼。

（5）開放集成

理論上，有了模型驅動等上述四大功能，開發一個不是太復雜的獨立應用就夠了，但典型的企業軟件都是相互依賴和集成的，所以平臺還需要具備能夠調用外部API和開放API給別人的能力。平臺如果沒有這兩方面的功能，開發出來的應用相互之間都沒法連通和集成，全是技術債。我們看國外關于低代碼的文章，經常會看到一個詞叫Shadow IT，說的就是這個問題。大家都胡亂的開發各種應用，還都集成不起來，將是一場大災難。

（6）腳本語言

腳本語言就是用JavaScripts、Python、Java等做擴展，這些其實就是正兒八經的專業編程語言了，但低代碼平臺會把工程復雜性都封裝好，讓開發者不需要配置部署環境，隨手就可以寫代碼，寫完一鍵發布馬上可以運行。

其實上述標準和Gartner是很一致的。Gartner在魔力象限報告里說：

An LCAP is characterized by its use of model-driven or visual development paradigms supported by expression languages and possibly scripting…

里面模型驅動、可視化開發、表達式語言、腳本語言都提到了。

小結一下，判斷是不是"專業”低代碼，可以重點看模型驅動、可視化開發、表達式語言、軟件工程、開放集成和腳本語言等六個方面。

03國內有專業的低代碼平臺嗎

國內看似已經有很多低代碼平臺，道一云之前做個一個系列測評，T研究、海比等也都出過分析報告，但只要我們對照上述標準就不難看出，雖然低代碼輿論很是喧囂，但迄今為止應該說國內還很少有專業的低代碼平臺。

比如阿里今年一直鼓吹的宜搭，宣稱是“低代碼”應用搭建平臺，但其實是一個“表單驅動”的“無代碼”平臺。阿里其實是打了個擦邊球，說宜搭是“搭建”平臺，沒說是“開發”平臺，你要說他過度宣傳也算不上。但“搭建”和“開發”二字之差，差距可大了，“搭建”的意思是基于一些成熟模塊組裝應用，一旦遇到既有模塊不夠用的時候就歇菜。

國內很多分析報告提及的產品大部分我都瞄過，但看一圈下來，個人認為也就ClickPaaS可能還夠得上（我也不確定，因為ClickPaaS不開放用戶手冊，沒深入研究），畢竟它有模型驅動和開放集成，其他的門檻都夠不上。

這么混亂的狀態讓我們的CIO們可怎么辦呢，這再次說明如果缺乏有效的標準篩選真正專業的低代碼平臺，勢必低代碼和無代碼一鍋粥，結果大家都被搞得稀里糊涂。

04低代碼真的是新瓶裝舊酒嗎

關于低代碼還有一種流行的觀點是新瓶裝舊酒，說二十年多年前的Delphi、PowerBuiler（后稱PB）早就是低代碼，但早就被時代淘汰了，今天的低代碼也沒戲。說這些話的大概率還是前輩。

要講清楚這些問題得稍微digg一點歷史，當年的Delphi和PB可是神一般的存在，因為相比同時代的其他技術（比如詰屈聱牙的MFC）來說易用性好太多，這倆不知道做了不知道多少企業信息化應用。隨手翻看一本《Delphi開發典型模塊大全》，里面盡是板材排料、進銷存、文檔管理、批發零售、房地產信息管理等案例。

這倆后來被時代淘汰，主要是因為時代變了，沒跟上。互聯網時代來了后，軟件架構很快就從桌面端的C / S變成Web端的B / S，再后來是移動App。Web應用和App對前后端的要求比桌面應用都要高很多，因為大家做網頁或App都是要勾引用戶主動來訪問啊，不像桌面端的企業應用就算不好用你為了工作也得用。互聯網的這個二十年，技術棧發展的越來越復雜，新的低代碼技術只能一直慢慢醞釀。

但經過OutSystems等廠商經過十多年的積累，今天的低代碼技術已經遠勝當年的Delphi和PB。今天的低代碼要“低”的多，當年的Delph、PB等如果按今天的標準，連入門的資格都沒有。

我們就以當年最流行的Delphi為例，Delphi雖然號稱“可視化編程語言”，但也就是實現了界面的可視化開發和數據庫的ORM，所有的邏輯都是要用代碼寫的，包括怎么把數據顯示在表格也都要寫代碼。我們說的六大標準里，頭兩位的模型驅動、可視化開發這些都沒有。PB也就比Delphi稍好一點，它核心的DataWindow可以無需代碼做出增刪改查，算是邁入模型驅動的門檻，但它不支持實體關系，模型驅動能力并不完整。同時PowerBuilder也沒有可視化的邏輯開發，按今天的標準也只能在門檻徘徊。

貼兩張老圖讓大家感受一下當年炸子雞—Delphi。

（Delphi的主界面，實現了用戶界面的可視化設計）

（Delphi的邏輯實現界面，得寫代碼）

士別三日當刮目相看，何況十多年。今天的低代碼并不是新瓶裝舊酒，而是新瓶新酒，里外都是新的。說新瓶是因為低代碼這個概念是新的，說新酒是因為今日的OutSystems等專業低代碼產品的能力已經遠超二十年前PC時代的Delphi和PB。

我想說低代碼是新瓶裝舊酒的人啊，看到特斯拉也會說新瓶裝舊酒，不還是汽車嗎，看到iPhone也會說新瓶裝舊酒，不就是個手機嗎，我就打打電話，發發短信。這些人啊，可能也不因為別的，可能就是因為年紀太大了。

關于低代碼從DOS時代至今的發展脈絡，阿朱在《低代碼都快爛大街了，還有人在為低代碼吵架》一文有詳細介紹，感興趣的可以看看。

05低代碼能開發復雜的企業應用嗎

目前業界很多人認為低代碼搞不定復雜的企業應用。如ERP老兵果總在《低代碼，不要以比“中臺”還快的速度臭大街》一文中認為低代碼只適合用來做“簡單的工作流和表單流轉的應用”或“大型應用軟件的功能延伸的開發”，認為“不適合開發復雜邏輯的核心業務”。然而果總并沒有說為什么。“技術領導力”在《如何用低代碼搞垮一家公司？》一文中認為低代碼只適合“創新探索類”、“生命周期短的”等應用。同樣，也沒有給出依據。類似的言論還很多，但都有一個共性，就是只說低代碼不行，不解釋，而且很多時候還把話說的那個斬釘截鐵。

很多人還真的把自己當回事啊。

企業應用聽起來高大上，但其實幾十年東西了，能有多復雜呢？界面不用很時尚，不用扛百萬并發，也沒智能推薦啥的高級算法，其實從軟件開發角度看企業應用是比較簡單的。企業應用的復雜主要是領域模型和業務流程比較復雜，但從前文我們可以看到，低代碼平臺在建模和邏輯方面的能力都是比較全面的，再通過腳本語言、開放集成等擴展機制，對于不方便低代碼實現的地方，可以和專業代碼開發協作實現。所以用低代碼開發復雜應用，本質上沒問題。

這也不是我一個人的觀點，明道云CEO任向暉寫過一篇《APaaS搞不定復雜的應用，是這樣嗎？》，把企業應用的復雜性分解為數據、權限、流程、算法、集成、報表等六個維度，然后逐一給出解決方案。這才是實事求是的態度。我覺得任總的分析已經比較充分，我也不再展開說了。我相信任何人但凡不帶偏見，深入分析的，都會發現企業應用并沒有什么復雜性是低代碼一定搞不定的。

而且用低代碼平臺開發這類應用，還有不少獨特優勢，如開發人員上手快（我們的經驗是個把月就能用的很溜了），開發效率高，便于業務人員和開發之間的溝通（因為邏輯大多是可視化的），不容易形成孤島（因為專業的低代碼平臺默認就會根據模型生成API）。OutSystems在其網站上特意強調：

OutSystems is well-equipped to build ERP and similar large, complex systems with the desired performance and scalability.

OutSystems也有一些這方面的案例，做供應鏈、CRM、ERP的都有。OutSystems成立于2001年，那時候不開發企業應用開發什么呢？

但可能很多人會說，OutSystems作為廠商當然這么宣揚，但目前用低代碼開發復雜企業應用確實不多啊。沒錯，但我認為這只是時間問題。

首先，低代碼技術達到成熟狀態的時間并不長，即便是OutSystems。OutSystems雖然都成立20年了，但低代碼表面看似簡單，其實是一個相當復雜的技術體系，背后涉及核心的編程語言層面的設計，比如DSL、類型系統、泛型等等，還有怎么diff、debug、undo，都不容易。另外低代碼平臺還需要不斷追趕這20年變化極大的技術環境。20年前是C / S、.Net，后來流行B / S、Java，再后來又得搞App，操作系統從Windows變成Linux，現在又面臨從SOA到微服務的轉型。OutSystems的主任工程師Tiago Sim?es曾介紹過20年來OutSystems的發展（https://medium.com/outsystems-engineering/whats-not-new-in-outsystems-a-product-timeline-c781acd400cb#），可以看到OutSystems一邊一直到補功能，直到2014年的9.0版本支持數據聚合處理才算比較完整，另一邊一直在努力追趕技術趨勢，直到2016年的10.0版本一口氣推出Client-Side Logic、Local Storage、異步、Reactive等功能才算對移動App有較好的支持。這玩意是不做不知道，一做嚇一跳，我們是做了輕舟低代碼才知道這個東西很難。

更重要的可能是非技術因素。大部分企業對CRM、ERP的定制需求還沒那么高，相比用低代碼從頭開發來說，采用Saleforce、這樣的套裝軟件實施，再做一些二次開發是更合適的選擇。這也解釋了為什么Saleforce、ServiceNow這樣的SaaS巨頭都有自己的低代碼平臺，而西門子會收購Mendix。另外ERP這樣的企業軟件實施強依賴咨詢經驗，這不是低代碼能解決的，而業界有經驗的咨詢顧問顯然更熟悉這樣的產品，也沒有意愿改變。專業程序員對低代碼抵觸也非常大，好不容易練就一身武藝，用了低代碼好像都沒用了？業界越是宣傳用低代碼開發快多少倍，開發團隊可能越抵觸。

總之，業界流行說低代碼不能做CRM、ERP這類復雜的企業應用，這一說法很多人講，但都沒有根據。從技術原理出發，低代碼最適合做的恰恰就是企業應用。目前用低代碼做復雜企業級應用的case還不是很多，是因為低代碼技術也就剛成熟不久、定制需求還不夠強（套裝軟件能滿足）或者行業不愿做，并不能說明它做不了。

06低代碼不適合開發哪些類型的應用

很多專家啊，不但錯誤的認為低代碼搞不定復雜企業應用，還在低代碼適合哪些類型的應用上也說錯了。

低代碼真正不太擅長的，是那些有各種特殊要求的應用，比如：

對算法和復雜數據結構要求比較高的：我想不會有人想到用低代碼平臺去刷LeetCode題、打ACM比賽的吧。這里有個細微的地方是要區分是業務邏輯比較復雜還是算法邏輯比較復雜，業務邏輯復雜對低代碼來說不是問題，算法邏輯復雜才是問題。那啥叫業務邏輯復雜呢，就是業務人員總之是說的清楚，或者是能理解的；啥叫算法邏輯復雜呢，就是業務人員只能給個目標，具體怎么實現是不管的，就算解釋也是一臉悶逼的聽不懂的。

對界面要求特別高的：比如游戲或抖音、云音樂這樣的社交娛樂型的應用。目前主流的低代碼平臺都不擅長做酷炫的界面（也有一些特定類型的低代碼平臺如App Onboard是面向游戲開發的，不在本文討論范圍之內）。

頭部互聯網級應用：頭部互聯網應用用戶量巨大，為了優化性能有很多很多trick，前后臺技術架構非常復雜，低代碼平臺的實現是比較標準的數據庫 / 邏輯 / 界面三層架構，無法滿足性能需求。注意這不是說所有互聯網應用都不合適，只是指那些用戶量特大的頭部應用。

分析和智能化應用：分析類應用自然應該用更專業的BI工具，智能化應用也應該用更專業的機器學習平臺等工具。

系統軟件、科學計算等其他專業性很強的應用。這個不多說了，估計也沒誰想用低代碼來做，但多說一句，雖然這些系統的內核肯定不適合低代碼開發，但界面可是很適合，我們輕舟低代碼產品正是脫胎于云計算平臺的界面開發。

現在大家應該可以發現很多業界流行的觀點說低代碼適合這個那個的其實也都是錯的，比如：

說低代碼適合“簡單的工作流和表單流轉的應用”：事實上專業的低代碼并不見得特別適合這類應用，比如Gartner就說OutSystems這方面的支持還不太好。其實最適合這類應用的反而是那些“表單驅動”的產品，這些產品并非專業的低代碼平臺。專業的低代碼平臺搞這些也不是完全不行，但屬于大炮打蚊子，性價比不高。

說低代碼適合“生命周期短的應用”：事實上如果你用OutSystems這樣“最專業”的低代碼平臺去做營銷活動頁這樣“生命周期短的應用”，你肯定會欲哭無淚。為什么？因為營銷活動頁對界面的要求很高哎。

說低代碼適合“創新型應用”：有篇文章按Gartner的方法把應用分成基礎設施型（如 ERP）、差異化型（如 CRM）和創新型應用，說前兩類應用低代碼就別碰了，都是傳統IT的菜，低代碼就搞搞創新型應用，這個說法也不對。互聯網App算典型的創新型應用吧，上面已經說過這個低代碼搞不定。

07低代碼不是銀彈，不要過度神化

上面我們說低代碼很適合開發典型的企業應用，優點明顯，如開發人員上手快、開發效率高、增進溝通和集成等，但也不要認為低代碼是銀彈，用了什么問題都解決了。原因主要有以下三個方面。

1）開發工具只能解決軟件研發的部分問題。作為開發工具，低代碼可以加快在需求比較明確時的軟件交付，也可以在大方向比較明確但具體需求不明時加快軟件的迭代更新。但企業應用和企業的經營管理方式、業務方向、業務流程、組織架構密切相關，和人密切相關，這些方面如果有問題，軟件都不知道怎么做，這都不是開發工具所能解決，該請咨詢還是得請咨詢。低代碼就像特種兵，單兵作戰能力是強，但如果將帥不行，戰略戰術拉垮，也打不了勝戰。

2）低代碼能提升多少開發效率缺乏權威數據，不要有太高預期。業界有很多對低代碼開發效率的宣傳，最多的是說什么提升10倍啦，這些一看就是胡扯。一些廠商和分析機構會發布提效數據，看似效果特別好，但因為前面說的無代碼和低代碼沒分清問題，這些數據不可信。比如阿里“宜搭”的數據說平均將應用開發成本從17.5人天提高到3.5人天，提效500%，但前面說過“宜搭”是無代碼工具。無代碼工具因為都是面向特定類型的應用高度優化的，提效明顯很正常的，但不通用。專業的低代碼廠商如OutSystems、Mendix，反而不敢宣傳提效多少倍，所以一個廠商宣傳的效果越好，就越不可能是專業的低代碼平臺。從我們的經驗看，用低代碼做一些小系統確實挺快，但上了規模后還能是不是有數倍提升，我覺得也不大可能。根據我們的初步經驗，我們覺得提升1到2倍是一個比較合理的預期。

3）行業典型的項目制限制了低代碼的價值。低代碼平臺因為可視化、效率高，最適合業務和開發密切溝通合作，快速迭代。但當前甲乙方之間典型的項目制要求雙方提前簽訂詳細的合同和SOW，這就把本來可以敏捷開發的生生打回到瀑布模式，這樣低代碼快速迭代的價值就很難體現。項目制存在太久，不是一時半會改的了的。

08小結

最后做個小結：

無代碼和低代碼不是一個層次的概念。低代碼是以OutSystems、Mendix等產品為代表，主要面向專業開發的通用應用開發平臺；無代碼則是一個營銷用語，用于形容很多種面向業務人員的工具，如應用搭建、在線表單、工作流等。不存在無代碼的通用應用開發平臺。無代碼這個概念過于寬泛，未來很可能會慢慢淡出市場。

要判斷一個低代碼平臺是否專業，可以重點看模型驅動、可視化開發、表達式語言、軟件工程、開放集成和腳本語言等六個方面。對照這些標準，不難看出迄今為止應該說國內還很少有專業的低代碼平臺，雖然輿論甚是喧囂。

業界關于低代碼適用場景的觀點大多數都是錯的。比如業界很多人講低代碼搞不定復雜的企業級應用，但都毫無根據。從技術原理出發，低代碼其實最適合做的就是企業應用，即便是CRM、ERP這樣復雜的應用；業界認為低代碼適合做“簡單的工作流和表單流轉的應用”、“生命周期短的應用”、“創新型應用”等觀點也都是錯的，這些應用很多恰恰不適合低代碼。

低代碼不適合做的應用是對算法、界面、性能、分析和智能化等專業性要求高的應用。

低代碼對企業應用開發價值明顯，但也不是銀彈，不要過度神化。

對甲方來說，我認為CIO們應該從試點應用做起，通常來說要求自己的團隊用低代碼的阻力會很大，但可以要求乙方用低代碼，降報價。對乙方，我覺得短期很難賣平臺，最好是和甲方談個人力外包模式，避免項目制的僵化。業界說低代碼是“高級外包”倒也沒說錯，雖然我覺得既然用的是低代碼應該叫“低級外包”更合適。

最后的最后，我再次呼吁分析機構能夠區分低代碼和無代碼，聚焦分析面向通用應用開發的低代碼開發平臺，促進這個行業的認知統一，產品的標準化，這樣才能夠推動行業發展。

無代碼將死，低代碼長存！