在數字化浪潮席卷而來的今天，低代碼平臺作為一種新興的開發工具，受到了廣泛關注。然而，正如任何新興技術一樣，低代碼平臺也面臨著諸多爭議。2021年《為什么我說低代碼是“行業毒瘤”？》一文便提出了對低代碼平臺的質疑，認為其預設使用人群局限、暗藏變革成本、并非長期發展風口，甚至質疑其為偽需求。

那篇文章是一篇采訪文章，大概率是媒體為博人眼球有意為之，才為文章取了一個這么大的標題。我從受訪者的回答中可以看出他說：“低代碼如果定位是幫助小白來入門行業，不是幫助從業者提升效能”的話，這樣是偽需求。因為當時低代碼普遍形態是以無代碼為主，當無法滿足需要時，通過特定方式將代碼以插件的形式注入平臺，作為低代碼平臺的內置邏輯，供設計器使用。然后就大肆宣傳低代碼要變革研發，能做復雜場景。

我認為如果這篇文章再嚴謹點，把“指望這樣定位的低代碼平臺，來做核心業務場景”的訴求，稱之為偽需求，我認為是對的。這也是許多研發人員反對低代碼的核心原因之一，主次搞反了，因為這種模式下研發人員變成了輔助角色，而軟件工程是一門需要技術能力的學科，讓沒有技術能力的人主導是違反常理的。對于軟件產品公司來說，產品需要迭代規劃，需要多人協作，需要工程化管理。

但是即使這種形態的低代碼或無代碼平臺，如果定位在企業輔助場景，也是有市場有空間的。它在當企業部門之間有協同需求，但沒有專業軟件支撐的場景，找外包開發有不劃算的場景，也是起到了補充作用。比如明道云、宜搭、得帆這類平臺，做輔助場景也非常好。人家也沒說非要做核心場景。這些平臺明確表明自己主要支持一些輔助場景，這種專注使得它們在簡單場景的優化體驗上做得相當出色。對于用戶來說，它們提供了一個清晰、直觀的選擇，使他們能夠快速地構建和部署應用程序，滿足日常工作的需求。這種明確的定位不僅降低了用戶的使用門檻，也提高了平臺的使用效率。但如果像某流一樣，一上來就要用無代碼顛覆，革研發的命，就有點那啥了，也就前面說的“主次搞反”。

市面上，還有一類低代碼平臺，特別奇怪，它的定位屬于不上不下的騎墻定位。以某易旗下的低代碼為例，該平臺定位在中等復雜度的業務上，但似乎并沒有很好地把握這一定位。在實際應用中，客戶可能會發現它既不像簡單的無代碼平臺那樣易于上手，也不像低代碼平臺那樣功能全面。這種定位上的飄忽不定使得用戶難以判斷到底能否滿足自己的需求，從而影響了平臺的推廣和使用。

悲觀的人正確，樂觀的人向前。如果文章就寫到這里就沒意思了。接下來介紹那本文的重點，也就是哪些號稱能做復雜場景的低代碼平臺，比如ClickPaaS、炎黃盈動、當然也包括我們數式Oinone。這類產品必然要在技術路徑選擇上要跟明道云、宜搭、得帆，這些類型平臺不一樣。接下來我為這類平臺發發聲，它們絕對不是偽需求，只是難度很大：

首先，我們要澄清一個誤解：低代碼平臺并非僅面向初級、入門人員。

實際上，隨著技術的不斷發展，低代碼平臺已經具備了高度的可配置性和擴展性，能夠滿足專業研發人員的復雜需求。同時，低代碼平臺也提供了豐富的API和集成能力，使得開發者能夠輕松地與其他系統進行集成，實現業務邏輯的快速構建。因此，低代碼平臺并非局限于初級人員，而是能夠覆蓋更廣泛的開發人群。

其次，關于低代碼平臺暗藏的變革成本問題，我們需要正視但不必過分擔憂。

任何新技術的引入都會帶來一定的變革成本，包括人員培訓、系統遷移等方面的投入。然而，這些成本并非低代碼平臺所獨有，而是所有新技術都需要面對的問題。關鍵在于我們如何平衡變革成本與潛在收益。通過合理的規劃和實施策略，我們可以將變革成本控制在可接受的范圍內，并充分利用低代碼平臺帶來的效率提升和業務創新。

再者，關于低代碼是否是長期發展風口的問題，就拿《為什么我說低代碼是“行業毒瘤”？》這篇文章中提到的“現在程序員缺口很大，大家都在 996，加班干活，所以我們需要一個提升效能的工具”，這個沒有錯，我在其他文章中也反復提到：“隨著企業數字化轉型，企業對研發人員的需求量大幅增加，同時對他們的要求也變得更加嚴格和高標準”。低代碼做解決這類問題痛點的核心手段，才會反復被提及。只是數字化時代的低代碼需要具備面對復雜場景的能力。用一個滑稽的話做總結：“因為市面上的低代碼是毒瘤，我們要自己做一個”。

最后，我想強調的是，低代碼平臺并非偽需求，而是企業數字化轉型過程中的重要工具。對于許多企業來說，快速構建和迭代應用程序是提升競爭力的關鍵。而低代碼平臺正是能夠滿足這一需求的工具之一。

19年出來創業時，我希望把低代碼帶進企業核心場景，推出低代碼加中臺理念，通過低代碼平臺把只是停留在理念層面的中臺概念固化到技術平臺中，甚至提出了沒有低代碼加持的中臺廠商都是在刷流氓，在收割大家的智商稅。

在我眼里中臺代表：核心業務場景、互聯網技術，低代碼是：新的工程化輸出。我們只是用低代碼的方式輸出，互聯網技術與業務的最佳實踐。 針對復雜場景的低代碼平臺，如果沒有把低代碼平臺作為核心的戰略定力，是做不出來的，國外的Mendix和Odoo分別做了6年和8年才嶄露頭角，在中國軟件公司太浮躁，能把一點做深做透的太少，市場規模是他們的第一追求。但軟件行業一定是厚積薄發的行業，但凡有點名頭的企業基本5年以上，數式Oinone堅信低代碼平臺會從輔助場景走向核心場景，堅信所有軟件公司都需要具備這樣的能力，我們專注低代碼平臺，把場景交給伙伴，恪守邊界，努力為行業帶來一點改變。

那企業或者軟件公司如何選型能支撐復雜場景的低代碼平臺呢？我總結了以下三點，供大家思考：

1. 確保咱們各類場景情況能被實現

a. 找自己場景中的一個特定頁面或字段交互，是低代碼平臺原本不支持的，去驗證低代碼平臺在交互層面沒有限制

b. 找自己場景中的一個特定邏輯，最好涉及對接第三方能力比如引入第三方開源組件，去驗證低代碼在邏輯層面沒有限制

c. 是否改變研發習慣，適應成本有多高？

2. 驗證咱們各位緯度效率有提升

a. 針對項目或產品研發過程中涉及的核心角色是否有提效

i. 后端研發是否提效，具體表現在哪些方面？難度降低還是效率提升？

ii. 前端研發是否提效，具體表現在哪些方面？難度降低還是效率提升？

iii. 跟外部系統集成是否提效？

iv. 跟業務無關的通用能力是否有足夠支撐？

v. 針對測試，質量是否提升？測試工作量或回歸量是否有提升？

vi. 驗證低代碼擴展能力，無需額外設計。任何研發人員寫的邏輯都具備高度擴展能力

b. 引入低代碼平臺，對研發流程有沒有改變，是否有提效

i. 后端研發、前端研發、測試之間協同效率是否有提升？

ii. 業務研發與通用能力研發之間協同效率是否有提升？

3. 證明低代碼平臺符合咱們公司未來發展的要求

a. 公司的行業特性如何跟低代碼平臺結合

i. 是否能遵循公司UI規范，涉及主題、布局、UI規范、logo等各種細節

ii. 行業組件擴充：能否基于低代碼擴充屬于自有的行業組件，在設計器中增加自有組件如頁面、圖表等

b. 促進銷售

i. 迅速完成業務需求的概念驗證（POC），以快速響應市場變化和客戶需求。

c. 公司產品化發展

i. 研發專注標品，研發擴展包實現個性化，能否做到實施客戶時不需要改標品？

ii. 研發專注標品 ，非研發無代碼個性化實施，能否做到實施客戶時不需要改標品？

iii. 標品升級帶來的新特性，是否可以無縫給到每個客戶？

最后推薦下自己的低代碼產品數式Oinone，我們強調的低無一體的技術路線，一定能給您耳目一新的感覺。

首先，數式Oinone屏蔽了互聯網架構帶來的復雜性。針對專業研發和公民研發提供不同的兩種方式：一種是面向公民研發的無代碼設計器，另一種面向專業研發的低代碼研發框架。數式Oinone都是以元數據為基礎，兩種方式都是在產生元數據，通過使用代碼來描述元數據，可以無縫地與代碼銜接，并在不改變研發習慣的情況下降低門檻、提高效率，并進行工程化管理。

低無一體不僅僅是指兩種模式的結合，還包括兩種模式的融合應用方式。具體來說，這種融合應用方式可以分為兩種情況：

1、當開發核心產品時，主要采用低代碼開發，無代碼設計器作為輔助。這種方式可以提高開發效率和代碼質量，同時保證產品的快速迭代和升級。

2、當需要滿足個性化或非產品支持的需求時，主要采用無代碼設計器，低代碼作為輔助。這種方式可以快速地滿足客戶需求，并且避免對產品的核心代碼產生影響。

簡單來說，低代碼模式適用于產品的迭代升級，而無代碼設計器則適用于滿足個性化和非產品支撐的額外需求。低代碼和無代碼模式在整個軟件生命周期中都有各自的價值，在不同場景下可以相互融合，發揮最大的優勢。

想進一步了解數式Oinone給軟件公司帶來怎樣的效率提升，請看：多層次深度對比，一文看清數式Oinone帶來的效率提升

想進一步了解筆者對中臺的思考，請看：淺談企業IT架構的十年困局