aPaaS 解決的究竟是什么問題？本篇文章里，作者從更為落地的視角，探討了 aPaaS 的解決方案、AI 對 aPaaS 的影響等方面，我們不妨來看一下。

兩年前，在寫《關于 aPaaS 的思考（上）》時，正在求職關口，本質輸出就是最好的思考方式，分享了我對下面 3 個問題的思考：

1. aPaaS 產品是什么
2. aPaaS 產品面向的用戶是誰？
3. aPaaS 產品面向的場景是什么？

這兩年里又一頭扎入「模型驅動」的 aPaaS 產品中，在宏觀商業(yè)模式模式的思考外，補充了很多更落地的視角。再次站在職業(yè)選擇的路口，補上《關于 aPaaS 的思考（下）》，也算是給自己的階段性小結。

一、aPaaS 解決的問題是什么

1. 面向企業(yè)

相比兩年前，對于這個問題，我的視角會有所不同。

零代碼的視角：從無序到有序，提高中小企業(yè)的經營效率

在做零代碼時，我們關注的是從無到有，是中小企業(yè)「管理思路」的工具化。我們判斷中小企業(yè)，由于缺少高性價比的數(shù)字化管理工具，會導致企業(yè)整體經營效率會比較低。

比如：百人以內的電商代運營團隊，每天花費大量人力用電子表格來進行庫存管理。

低代碼的視角：降低內部系統(tǒng)的成本

而在最近工作的兩年里，觀察市場上在投入 aPaaS 方向的企業(yè)，更多是中大型公司，而其核心的動機是「如何以更低的成本迭代各種內部系統(tǒng)」以滿足企業(yè)快速發(fā)展的訴求。

比如：A 公司內部已經有了 OA、人力、差旅等多個系統(tǒng)，但是系統(tǒng)數(shù)據(jù)不打通，希望搭建 aPaaS 層的工具，實現(xiàn)系統(tǒng)層的數(shù)據(jù)、流程互通。

B 公司存在大量業(yè)務線需要客服工具，于是中臺打造通用客服產品，但是發(fā)現(xiàn)業(yè)務支持時，存在大量個性化需求，迭代不過來，于是搭建 aPaaS 工具層，快速響應。

所以從企業(yè)視角，本質都是解決「企業(yè)應用」的問題，主要是看解決「中小企業(yè)的從無到有」，還是「大企業(yè)的從有到優(yōu)」，而這兩種思路，從商業(yè)化上，各自有其需要解決的問題，商業(yè)化尚待驗證：

專注解決「中小企業(yè)的從無到有」：這類客戶畫像是缺少 IT 能力的，要求產品上手門檻低，且會非常注重性價比，客單價也會低。這些要素決定了零代碼產品，本身產品上無法搭建復雜度過高的應用，商業(yè)上無法實現(xiàn)高客單價，需要通過「走量」來拉升商業(yè)空間。

那最大的難點是：「量」如何走起來？一定不是依賴廠商自身的服務能力，最好的預期是產品門檻足夠低，中小企業(yè)能在教學資料的輔導下，自己完成閉環(huán)，退而求其次就是建立生態(tài)。

專注解決「大企業(yè)的從有到優(yōu)」：這類客戶要么已有自研產品、要么已經采購 SaaS 系統(tǒng)，這些企業(yè)應用的復雜度一般較高，對于 aPaaS 產品的天花板要求也更高。

對于 aPaaS 來說，產品上的難點是底層如何抽象，既能實現(xiàn)提效又能保持能力的靈活性和天花板，商業(yè)上的難點是如何證明采用 aPaaS 的解決方案，可以給客戶省錢，能省多少錢 – aPaaS 是工具，客戶有訴求找過來，無法開箱即用，要證明這個價值，比如有人力投入進來，先把應用搭起來，那價值被證明前，客戶是肯定不愿意投人，廠商就需要自己解決這個問題，就會導致服務成本很高。

另外一個思路是，場景化的打造1-2個標桿產品，用于價值的證明，但是大企業(yè)的需求，又極個性化。所以產品 & 商業(yè)的這兩個難題，還是在摸索中前進。

2. 面向個人

本質上，aPaaS 是搭建應用的工具，對于個人用戶而言，如果有一定的抽象能力，也是可以用 aPaaS 解決很多個人場景的問題。比如：

• 搭建個人網站
• 搭建個性化的記賬工具

還有一個小例子，有一次我希望找一個 PDF 分割的工具，網上找了幾個都要付費，最后用 Power Automate 的桌面流，幾分鐘解決了。當然，Power Automate 的桌面流能做到的事情還有很多很多。

其實，我最開始對 aPaaS 產生興趣，也是因為 Ta 讓我這樣一個學文科、完全沒有代碼經驗的同學，能夠按照我的個人意愿，搭建個人知識管理的應用。

總結起來，其實對于個人而言，aPaaS 是一個極其靈活、且門檻相比寫代碼更低的工具，能幫個人去快速實現(xiàn)一些小的需求。

但是市面上，面向個人的 aPaaS 產品很少，幾乎沒有，除了微軟 Power Platform 的全家桶套裝，我基本沒接觸到其他面向個人用戶，也能使用的 aPaaS 產品（也許是我見識少…

這個從商業(yè)上，也可以理解：

首先從用戶規(guī)模上，aPaaS 僅提供工具，不提供實際解決需求的產品，對于用戶而言，無法解決動力問題，為什么我不去直接找一個解決我問題的產品，而是要研究這個工具來搭建，而且這個學習成本還不低。所以面向 C 端，aPaaS 本身就是無法規(guī)?；漠a品，很難從流量的道路掙錢。

其次從工具的視角，去訂閱，也許是一個思路。但是作為工具，aPaaS 面向的場景有沒有那么明確，是需要用戶自己去發(fā)現(xiàn)需求，再去解決，不像是 Photoshop 這類的工具產品，場景很縱深（雖然在國內也不一定賺到錢）。

所以面向個人，有價值，但是商業(yè)上可以想象的空間不多。??下面聊到的部分，會以企業(yè)場景為主。

二、aPaaS 的解決方案是什么

由于 aPaaS 本質是「應用開發(fā)」工具，那 aPaaS 產品本身就是從「全代碼」-「無代碼」中間的平衡。

但是在產品設計上，其實二者的抽象思路還是有很大的區(qū)別：

零代碼是從業(yè)務層往下抽象，基于企業(yè)應用的通用屬性，抽象對應的產品功能。

低代碼是從技術層往上抽象，基于代碼開放的路徑和工具進行封裝，實現(xiàn)產品功能。

1. 零代碼的抽象

簡單的業(yè)務系統(tǒng)，業(yè)務層基本可以抽象為四個通用的部分：數(shù)據(jù)收集、流轉、存儲、分析。對應零代碼的主要功能模塊如上：

• 表單
• 流程
• 數(shù)據(jù)存儲
• 數(shù)據(jù)加工和 BI

同時，為了更大程度，降低用戶的使用成本，表單：數(shù)據(jù)表在結構關系上，基本是 1:1 綁定，部分產品流程：表單：數(shù)據(jù)表也是1:1:1綁定。在搭建表單時，就完成了數(shù)據(jù)表的搭建，同時可以基于表單搭建對應的數(shù)據(jù)流程。此類架構，默認幫用戶完成了前端和數(shù)據(jù)的綁定關系，極大降低用戶的搭建成本，但也降低了靈活性。如果業(yè)務希望搭建個性化的前端界面或者是有靈活的數(shù)據(jù)關系，可能就沒辦法實現(xiàn)。

這里再次 call back 到上文提到的零代碼產品在商業(yè)上的難點，很多零代碼產品無法解決量的問題，到千萬量級基本就會遇到營收的瓶頸。部分產品此時選擇的路徑，可能是朝著低代碼轉型，強化其二開能力，提高客單價，個人認為，這不一定是好的思路，架構上的轉向是很難的，要么另起新產品，要么還是可以考慮下零代碼在產品力上，如何更好滿足中小企業(yè)訴求，同時又能開箱即用，同時在渠道上，看如何能更好找到中小企業(yè)的客戶。

2. 低代碼的抽象

從開發(fā)一個 APP 的研發(fā)工程來進行抽象，得到對應的產品能力：

• 數(shù)據(jù)庫服務 – 數(shù)據(jù)表搭建器
• 前端服務 – 頁面搭建器（封裝好的一方組件、自定義組件）
• 后端服務 – 流程搭建器
• 底層：FaaS 服務，支持二開
• 測試運維：多環(huán)境、多分支
• 打包發(fā)布：發(fā)布管理

各模塊之間相關獨立，無耦合，可以通過調用和綁定來實現(xiàn)特定邏輯，比如頁面需要展示指定數(shù)據(jù)，需要頁面去主動查詢獲取指定數(shù)據(jù)并且綁定在頁面組件。

優(yōu)點是，產品極其靈活+個性化，能搭建千人千面的應用，問題是配置成本極高。而到具體功能設計中，每個產品的封裝程度各不相同，比如一些模型驅動的產品，為減少配置成本，會通過一些配置，默認幫用戶進行數(shù)據(jù)的綁定，而另一些產品則會更傾向于減少封裝邏輯，足夠原子化，操作權交給用戶。

三、誰在做低代碼？

1. 企業(yè)內部的技術平臺

抽象的中臺的 SaaS 產品支持各業(yè)務線，但是發(fā)現(xiàn)業(yè)務線的定制化需求多，導致產品迭代成本越來越高。于是希望借助 aPaaS 產品來沉淀底層配置化能力，實現(xiàn)對業(yè)務支持的提效。

支持企業(yè)內部應用開發(fā)的技術部門：企業(yè)快速發(fā)展，存在大量內部系統(tǒng)的需求，不希望借助外部 SaaS 產品，還是以自研為主，同時作為成本部門，又希望能以較低的成本支持內部系統(tǒng)的落地。于是希望搭建企業(yè)內部的 aPaaS 工具，借助 aPaaS 工具，完成內部系統(tǒng)的快速搭建。

2. 商業(yè)化的 SaaS 產品

已有 SaaS 標品，在支持客戶時需要響應大量個性化訴求，但做定制化開發(fā)，投入產出比低，于是在標品的基礎上，沉淀 aPaaS 工具層，基于 aPaaS 工具層，在標品上拓展個性化開發(fā)的訴求。

3. 商業(yè)化的 aPaaS 產品

本身無 SaaS 標品，僅提供 aPaaS 的工具能力，在產品運營層，提供各場景和行業(yè)的解決方案，切入客戶場景。需要考慮在和 SaaS 產品競爭時，自身的核心優(yōu)勢是什么，相比在垂直領域深耕的 SaaS 產品，可能是缺乏行業(yè) Know how 的。

四、AI 對 aPaaS 的影響是什么？

對零代碼的沖擊，應該很小。零代碼面向的是中小客，本身缺少 IT 能力，當前 AI 也無法直接搭建一個數(shù)字化應用，只能在片段化的場景提效。

對低代碼產品，可能會有些沖擊，AI 和 aPaaS 都定位是面向有 IT 能力的企業(yè)，提升開發(fā)效率的工具。AI 在代碼寫作能力上，已經有很好的應用了，能實現(xiàn)提效的目標，且從實際用戶-程序員的接受度上，使用 AI 來幫我寫片段化的代碼 vs 學習一個可能其他公司都不會用的 aPaaS 工具來實現(xiàn)業(yè)務需求，當然前者對自身的成長更有幫助。

不過二者也并不是互斥的，AI + 全代碼開發(fā) vs AI + 低代碼開發(fā)，可能后者還是效率會更高，所以 aPaaS 產品如何在搭建側更好融入 AI 的能力，也是未來一個機會。比如 Zapier 已經支持 AI 去幫忙搭建流程的節(jié)點、實現(xiàn)數(shù)據(jù)的轉化等，還有些產品支持 AI 直接生成頁面，同時用戶可以手動對頁面進行微調。

除了 AI + 低代碼外，很多公司在探索 Native AI 的應用，這其中也融合很多低代碼的能力，比如工作流的搭建、數(shù)據(jù)庫的管理、API 的管理等

總結起來，AI 對零代碼的場景，基本無沖擊，AI 能部分解決低代碼解決的問題，如果低代碼產品能很好融合 AI 的能力也可能是更大的機會。同時 Native AI 應用的探索，也需要借鑒低代碼產品的能力和產品思路