两年前，在写《关于 aPaaS 的思考（上）》时，正在求职关口，本质输出就是最好的思考方式，分享了我对下面 3 个问题的思考：

aPaaS 产品是什么

aPaaS 产品面向的用户是谁？

aPaaS 产品面向的场景是什么？

这两年里又一头扎入「模型驱动」的 aPaaS 产品中，在宏观商业模式模式的思考外，补充了很多更落地的视角。再次站在职业选择的路口，补上《关于 aPaaS 的思考（下）》，也算是给自己的阶段性小结。

一、aPaaS 解决的问题是什么

1. 面向企业

相比两年前，对于这个问题，我的视角会有所不同。

零代码的视角：从无序到有序，提高中小企业的经营效率

在做零代码时，我们关注的是从无到有，是中小企业「管理思路」的工具化。我们判断中小企业，由于缺少高性价比的数字化管理工具，会导致企业整体经营效率会比较低。

比如：百人以内的电商代运营团队，每天花费大量人力用电子表格来进行库存管理。

低代码的视角：降低内部系统的成本

而在最近工作的两年里，观察市场上在投入 aPaaS 方向的企业，更多是中大型公司，而其核心的动机是「如何以更低的成本迭代各种内部系统」以满足企业快速发展的诉求。

比如：A 公司内部已经有了 OA、人力、差旅等多个系统，但是系统数据不打通，希望搭建 aPaaS 层的工具，实现系统层的数据、流程互通。

B 公司存在大量业务线需要客服工具，于是中台打造通用客服产品，但是发现业务支持时，存在大量个性化需求，迭代不过来，于是搭建 aPaaS 工具层，快速响应。

所以从企业视角，本质都是解决「企业应用」的问题，主要是看解决「中小企业的从无到有」，还是「大企业的从有到优」，而这两种思路，从商业化上，各自有其需要解决的问题，商业化尚待验证：

专注解决「中小企业的从无到有」：这类客户画像是缺少 IT 能力的，要求产品上手门槛低，且会非常注重性价比，客单价也会低。这些要素决定了零代码产品，本身产品上无法搭建复杂度过高的应用，商业上无法实现高客单价，需要通过「走量」来拉升商业空间。

那最大的难点是：「量」如何走起来？一定不是依赖厂商自身的服务能力，最好的预期是产品门槛足够低，中小企业能在教学资料的辅导下，自己完成闭环，退而求其次就是建立生态。

专注解决「大企业的从有到优」：这类客户要么已有自研产品、要么已经采购 SaaS 系统，这些企业应用的复杂度一般较高，对于 aPaaS 产品的天花板要求也更高。

对于 aPaaS 来说，产品上的难点是底层如何抽象，既能实现提效又能保持能力的灵活性和天花板，商业上的难点是如何证明采用 aPaaS 的解决方案，可以给客户省钱，能省多少钱 – aPaaS 是工具，客户有诉求找过来，无法开箱即用，要证明这个价值，比如有人力投入进来，先把应用搭起来，那价值被证明前，客户是肯定不愿意投人，厂商就需要自己解决这个问题，就会导致服务成本很高。

另外一个思路是，场景化的打造 1-2 个标杆产品，用于价值的证明，但是大企业的需求，又极个性化。所以产品 & 商业的这两个难题，还是在摸索中前进。

2. 面向个人

本质上，aPaaS 是搭建应用的工具，对于个人用户而言，如果有一定的抽象能力，也是可以用 aPaaS 解决很多个人场景的问题。比如：

搭建个人网站

搭建个性化的记账工具

还有一个小例子，有一次我希望找一个 PDF 分割的工具，网上找了几个都要付费，最后用 Power Automate 的桌面流，几分钟解决了。当然，Power Automate 的桌面流能做到的事情还有很多很多。

其实，我最开始对 aPaaS 产生兴趣，也是因为 Ta 让我这样一个学文科、完全没有代码经验的同学，能够按照我的个人意愿，搭建个人知识管理的应用。

总结起来，其实对于个人而言，aPaaS 是一个极其灵活、且门槛相比写代码更低的工具，能帮个人去快速实现一些小的需求。

但是市面上，面向个人的 aPaaS 产品很少，几乎没有，除了微软 Power Platform 的全家桶套装，我基本没接触到其他面向个人用户，也能使用的 aPaaS 产品（也许是我见识少…

这个从商业上，也可以理解：

首先从用户规模上，aPaaS 仅提供工具，不提供实际解决需求的产品，对于用户而言，无法解决动力问题，为什么我不去直接找一个解决我问题的产品，而是要研究这个工具来搭建，而且这个学习成本还不低。所以面向 C 端，aPaaS 本身就是无法规模化的产品，很难从流量的道路挣钱。

其次从工具的视角，去订阅，也许是一个思路。但是作为工具，aPaaS 面向的场景有没有那么明确，是需要用户自己去发现需求，再去解决，不像是 Photoshop 这类的工具产品，场景很纵深（虽然在国内也不一定赚到钱）。

所以面向个人，有价值，但是商业上可以想象的空间不多。下面聊到的部分，会以企业场景为主。

二、aPaaS 的解决方案是什么

由于 aPaaS 本质是「应用开发」工具，那 aPaaS 产品本身就是从「全代码」-「无代码」中间的平衡。

但是在产品设计上，其实二者的抽象思路还是有很大的区别：

零代码是从业务层往下抽象，基于企业应用的通用属性，抽象对应的产品功能。

低代码是从技术层往上抽象，基于代码开放的路径和工具进行封装，实现产品功能。

1. 零代码的抽象

简单的业务系统，业务层基本可以抽象为四个通用的部分：数据收集、流转、存储、分析。对应零代码的主要功能模块如上：

表单

流程

数据存储

数据加工和 BI

同时，为了更大程度，降低用户的使用成本，表单：数据表在结构关系上，基本是 1:1 绑定，部分产品流程：表单：数据表也是 1:1:1 绑定。在搭建表单时，就完成了数据表的搭建，同时可以基于表单搭建对应的数据流程。此类架构，默认帮用户完成了前端和数据的绑定关系，极大降低用户的搭建成本，但也降低了灵活性。如果业务希望搭建个性化的前端界面或者是有灵活的数据关系，可能就没办法实现。