日前，低代碼廠商黑帕云宣布正式停止服務。

來源：互聯網

　　在新一輪低代碼熱潮中，黑帕云成為欣欣向榮的光景里第一家宣告退出的廠商。

　　這家成立于2019年的企業在去年7月宣布A輪融資，但之后不久就傳出了其要被字節跳動旗下飛書收購的消息。如今黑帕云的停服直接揭示了低代碼領域創業團隊求存不易的一面。即使資本青睞，外界看好，站在了風口，也拿到了融資，市場的考驗依舊殘酷。

　　這兩年的低代碼賽道熙熙攘攘，但對大多數入局的玩家來說，技術如何演進，商業模式如何突圍，依舊在求索之路上。

需求渴切

　　低代碼本身并不算新概念，因此在低代碼賽道升溫之余常有人質疑其“老瓶裝新酒”，有炒作之嫌。

       2000年 VPL（Visual Programming Language），即可視化編程語言，就已出現；2014年，國際知名市場調研企業  Forrester 正式提出“低代碼/零代碼”的概念，將其定義為無需編碼或通過少量代碼就可以快速生成應用程序的開發平臺；2018年，Gartner 提出  aPaaS 和 iPaaS 的概念；2019年開始，中國的低代碼市場進入小步快跑的增長期……

　　由此可見，關于可視化開發的嘗試早已開始，但它們都沒有對應用程序的創建方式產生重大影響。為何在沉寂了一段時間后，低代碼又來到了聚光燈下呢？其中的關鍵在于，隨著數字化浪潮的到來，出現了龐大的應用缺口。

　　近些年來，伴隨云計算、人工智能、物聯網、5G等技術的發展，越來越多的企業需要加速數字化轉型。加之疫情倒逼企業尋找高效轉型的方法，使用低代碼提升應用開發效率，通過更敏捷的交付來推動業務創新速度，成為了企業降本增效的選擇之一。

　　回顧一下2018年，彼時，低代碼賽道初露崢嶸：OutSystems成為估值逾10億美元的獨角獸，一時風頭無兩。隨后，西門子又宣布以6億歐元的價格收購低代碼應用開發平臺Mendix。幾乎在同一時期，AWS、Google、Microsoft、Oracle等巨頭也紛紛布局低代碼領域……

　　低代碼再度“火”起來后，中國市場的表現同樣值得矚目。Gartner有調研數據顯示，未來5年至少需要開發5億個新應用，才能滿足中國企業數字化轉型的需求。面向這一市場，低代碼無疑大有可為。據悉，在2018-2020年間，中國無/低代碼領域總體投融資事件共16起，在總融資規模上，國內無/低代碼平臺商共獲融資近15億人民幣，融資企業總估值近70億元。

　　在這一趨勢下，大廠的入局為低代碼領域的新玩法注入了更多想象。去年1月，伴隨釘釘6.0版本的發布，釘釘宣布全面開放底層能力和1300個API接口，同步提出了“低代碼革命”。發布會上，阿里云智能總裁張建鋒表示，基于云釘一體的“低代碼開發”，將成為新一代的軟件開發方式，并稱希望未來3年在釘釘上能長出1000萬個釘應用。資料顯示，截至2021年12月底，釘釘上的低代碼應用數已超過240萬。

前景未明

　　盡管用戶需求迫切，市場空間廣闊，資本青睞有加，但需要正視的是，中國低代碼企業大多處于起步階段，行業格局尚未明朗，不久的未來可能面臨整體洗牌。在此期間，低代碼相關技術和商業模式的不成熟會成為掣肘多數創業企業的關鍵因素。

在技術上，低代碼工具的優點一目了然。首先，低代碼平臺通過拖拽組件等形式，可以更好地應對敏態業務的開發需求，比之全代碼開發，能有效降低成本，縮短交付周期；再者，低代碼工具為業務人員參與應用開發提供了一種可行之法，有助于推動全民開發成為業務和

IT 協作的重要組成部分。

　　不過，低代碼工具的短板也同樣明顯。

　　第一，通用性和個性化之間的矛盾難以調和。要降低開發門檻，就要盡可能讓有限的封裝覆蓋更多的場景。但事實上，應用場景千差萬別，如果想做個性化改動可能會面臨增加試錯成本的風險。

　　第二，安全性。因為低代碼廠商提供的封裝代碼模塊是無法被開發者檢查測試的。當低代碼無法保證安全控制時，企業可能不得不采購第三方安全管理工具，反而增加運維成本。

　　在商業模式上，低代碼領域還有待探索。無論是走產品路線還是提供定制化服務，低代碼廠商的前景都面臨重重挑戰。

　　首先，現有可替代工具過多，且不少免費。如何讓用戶愿意了解并使用低代碼是首要問題，尤其是對于中小客戶，商業邏輯能否跑通并達成規模化效應還是個未知數。

　　其次，應用不夠豐富，生態難以構建。低代碼目前來說仍屬于小眾的企服產品，如果沒有大應用生態做支撐，就其本身來說很難存活。釘釘的平臺型低代碼模式之所以卓有成效，并不是因為差異化，也不是細分賽道做得更出色，而是釘釘作為一款協作辦公平臺，本身協同密度足夠大，可以高效地基于其龐大的底座構建應用生態。

　　其三，大廠入局后的連鎖效應。2020年前后，一眾大廠開始入局低代碼，阿里推出“釘釘搭”，騰訊也推出了“微搭”，為這一賽道也帶來了變數。彼時，黑帕云在2021年底選擇被收購時，就有業內人士猜測，這可能是其創始人在權衡利弊后的選擇，在商業化方面小團隊依靠自身發展，不如借助大廠的資源和生態優勢進一步孵化。

　　尚未成熟的技術和商業模式讓低代碼市場前景未明，但也讓其呈現了一種野蠻生長的活力。等賽道趨于飽和，市場大浪淘沙之后，低代碼本身如何進化，將成為行業共同的命題。

來自開發者的聲音

　　隨著越來越多的企業入局，低代碼頻頻成為輿論關注的焦點，“全民開發”“非開發人員也能搭建應用”逐漸植入大眾印象。但事實真的如此嗎？并不盡然。51CTO技術社群中各行業開發者們就此表達了自己的觀點。

爭議1：低代碼到底面向的是誰？

　　【coeus】感覺低代碼不是給開發用的。可視化編程、低代碼、零代碼要實現的不就是“不需要開發插手人人可用”嗎？所以一個大眾化的產品就要簡單、無腦、定制化低。開發用的類似低代碼的東西，大家都歸納到組件、工具、模塊中了，都不認為是低代碼產品。

　　【邊城浪子】低代碼主要是兩種服務模式：面向業務人員和面向專業人員（開發人員），阿里、騰訊已經開源的低代碼平臺就是面向開發者。

　　【張業貴】低代碼不是面向開發者，而是面向有一定軟件使用經驗的業務人員，所以對于開發者沒有效率。如果非要說低代碼是給開發者用的，而且是匹配的業務場景，那肯定是高效的，畢竟大部分業務邏輯都封裝了，大部分工作都自動化了，這有點像腳手架的感覺。但是強耦合或者強數據相關的業務下，基本還是廢的，不如搞代碼工具或者代碼模板。

爭議2：低代碼適宜哪些應用場景？

　　【老黃】低代碼應該是解決復雜場景的，如果是簡單的那種，沒什么必要。

　　【Kevin】個人認為，低代碼解決的是（標準化）通用場景，和復雜度成弱關聯性。

　　【十七念】低代碼感覺比較適合標準化流程的，比如問卷、事項申報這種，還有對界面交互沒啥太大期待的。

　　【紫竹】低代碼意味著定制化，這兩者成正比關系，定制化越高，代碼越固化，可以改動的內容越少，參數化就越高，也就是所謂的低代碼；而普適性和定制化成反比關系，代碼想適應更多的場景，就要解決更多的問題，就要枚舉更多的特例，增加開發量，實際上就不滿足定制化。這個矛盾無法解決。

　　【飛狐】分行業，分需求，低代碼也是因地制宜。我認為，基于產品化的話局限性比較大，如果這個產品化的低代碼適用行業廣，可做成產品，稍微修改就可以，基于流程的話效率是提高了，但前期投入成本比較高，是否需要就看擴展性了。

爭議3：對開發者來說，低代碼真的有用嗎？

　　【looffy】：說實話，懂的人不愿用（搞不定復雜業務），不懂的人玩不轉（還是需要有點編程邏輯思路的）。

　　【Signx】實現原型倒是很快，對于不復雜的業務還是有用的，比如某些小廠實現信息化，原來采用手工的方式轉換成電子化的。

　　【Timo】（低代碼）還在發展，遠遠沒有成熟。成熟的一個標志就是普適性的低代碼平臺以及做垂直領域的低代碼平臺各司其職。作為開發人員，低代碼平臺可以作為日常管理的工具，對提升開發效率有用。但具體有什么用就見仁見智了，比如剛畢業的小孩兒讓用低代碼提升效率……還不如去看源碼更實在一點。

尾聲    

　　固然低代碼的局限還很多，但相較傳統軟件開發成本高、周期長的特點，低代碼在特定場景下的確有不容忽視的優勢。產品未來如何發展才能持續滿足市場需求？疊加功能，還是維持簡潔的設計？開放更多接口，引導更多開發者參與？抑或進一步細分場景進行差異化設計？無論選擇哪個方向，都需要小心試錯，及時調整。“全民開發”的未來是否會到來，何時到來還不得而知，但對于低代碼廠商而言，傾聽用戶聲音，扎實做好產品，乘風而起之日總會到來。