【深度】阿里宜搭产品调研报告

关键内容：低代码、PaaS、设计器 作者：小步 篇幅：全文约 10600字 阅读时长：约10分钟 提示：以下内容仅为个人分享，有兴趣交流的伙伴可在下方讨论区留言。

知识库首页

产品API：进阶全栈PM手册

提示：上方链接属于全手册首页，伙伴们打开后可以关注或收藏，用于日常工作查看，其中关注后，可以实时收到文档更新通知，希望对你有所帮助。

😅当前文档处于创作中。。。。。。

正文

在互联网下半场，ToB产品也逐渐成熟，主要表现为常见OA/ERP/CRM/WMS等等，但依旧有很多行业差异的独特性无法覆盖，因此定制化的需求场景不断出现，而很多规模较成熟的公司，或多或少已经出现重复开发情况，造成大量的开发资源浪费的情况，因此近年面向企业级应用的公司，都开始拥抱PaaS和SaaS生态，其中低代码开发的产品现象是当中一个选项。经过基本调研，目前基本可感知的如国外的Outsystems、西门子Mendix等传统公司，国内巨头阿里云的宜搭、腾讯云的LowCode平台，也都相继布局低代码领域。看样子，一场对开发工具的革新正在被业内推广和普及。

本文主要聚焦对宜搭平台进行产品分析，通过对该产品背景和现状调研，并结合一些可用的分析思路，试图挖掘什么才是更有效的低代码工具，以及新时代的开发工具应该是怎样的形态。以下内容结论和观点仅笔者个人表达，有不恰当之处，欢迎沟通。

一、产品信息（这是个什么产品）

1.产品形态

宜搭产品是一款用于开发移动端或Web端应用的开发工具，目前仅支持浏览器进行应用开发，暂无PC客户端，整体形态其实是PaaS化工具，工具产出的核心交付内容为SaaS产品，具备可视化拖拽，一键部署等特点。（下图为部分截图，具体功能分析会在第五部分说明）

（1）应用管理首页

（2）设计器页面

（3）应用页面

2.产品定位

由官网等相关资料可知，宜搭产品当前定位为人人都能使用的低代码应用搭建平台，未来期待成为全球最大的企业应用构建平台。

3. 产品目标

致力于让任何一个没有编码能力的人，能够轻松搭建应用（传统13天，宜搭2小时）

二、产品背景（成长的故事）

说明：此部分内容主要来源于搜索引擎获取的相关官方曝光资料，背景了解可以进一步知道产品诞生的原因和可能的影响点。

1.一些时间线

宜搭平台于2016年10月启动，通过2年时间承载了40家生态化公司，SaaS应用超2000个；于2019年3月份在阿里云正式对外发布；2020年12月，由钉钉宣布推出低代码应用开发平台“钉钉宜搭”，将面向超过1500万企业组织、3亿用户开放低代码、无代码开发的能力。标志着全面开放，正式接受市场验证。

2.三个搭建初期的故事

资源协同，初期采用共建方式搭建

在宜搭平台初期，为高效整合现有资源，项目组采用的是内部共建方式，主要与HR全球工单中心完成了页面设计能力及流程能力的建设，与GD业务中台完成了单据、数据分析及权限能力的建设

冷启动，种子用户的获取和吸引

很多B端产品，成长的前期，必须要有业务方才能够得到孵化或者说验证，因此有业务方是常规公司开发新B端产品必要的判断条件。这方面宜搭平台，便采用定向合作和场景切入两种方式，其中定向合作便是找一些B端集团公司，让产品有业务方支撑和验证，而场景切入则聚焦在一些春节活动排班、活动等轻量级易开发部署的内容。

商业化过程

据资料描述，宜搭平台于2017年9月接入钉钉开放平台，2018年6月产生商业付费场景，标志这商业化开始，而后便主要是通过钉钉开放平台现有生态客户进行商业化切入与推广。产品策略上，针对用户的调整主要对内人人都用；对外仅企业IT部门的人员可用，或需要借助ISV的接入；下图是宜搭生态体系的展望。

基本理解：通过上图可以感知宜搭平台预期的生态模式，其实需要大量借助阿里生态的能力，单从平台客户层，没有前期大量的B端企业客户能力的积累，是无法独立完成生态的构建，同时由于与钉钉全面集成，因此可以基本判断，客户主要还是打通钉钉覆盖的企业用户、部门，以及生态伙伴资源。

整体的构建思路，我们可以按供需关系理解，首先宜搭平台即PaaS平台，本质上属于供给侧的工具改革。在PaaS平台部分，可以看见PaaS平台期望构建的是一站式支持开发、调试、部署交付方式的平台，且内部可以形成市场交易。同时在PaaS平台和SaaS平台的双边市场交易中，PaaS承担SaaS方的供给侧，SaaS承担需求方的同时，也承担供给侧市场，为需求侧也就是平台用户提供能力服务。其中生态伙伴则是原始能力、技术、资源的提供方。从整体循环来看，各大模块直接其实是自产自销的过程，宜搭平台在当中主要作为核心生产工具。

3.背景小结

通过以上背景了解，我们基本上可以得出一个结论：要构建一个低代码开发平台，需要至少1~3年的孵化周期和积累，其中核心B端资源是支持平台构建的基础，同时从公司维度，连接围绕平台建设相关的内部沉淀资源，是一个必要的选择。

三、产品现状

1.基本数据分析

经过对宜搭官方文档和产品内容的整理，有以下数据维度可以简单评估宜搭的客户使用情况

（1）从帮助文档获得的数据

说明：

• 关注量：关注量只能说明持续关注宜搭的兴趣者相对较少，用以辅助对比的就是【语雀】本身是一款文档工具，它官方帮助中心关注量为24k。文档同样是面向人人的工具产品，当然需求频率和场景不同，但可以做一定的衡量点。因此主观判断若对此工具或者期待深度使用感兴趣的开发者，则会持续关注最新动态。
• 快速入门访问量：快速入门基本上是所有了解新工具的人大概率必会查看的内容，因此从语雀和官网文档可知，若浏览量17564不做任何去重或者无效计数，将其定义为独立用户访问数，转化率为50%（实际上并不会），则开发者为8000+，理论上，目前应该有8000+独立应用被创造，若开发者代表的是独立的B端用户，那么就代表8000+企业。但从背景资料当中，我们知道面向1500万企业组织，这数字确实还在孵化期。

（2）从应用模板中心获得的数据

说明：
应用模板是来源于产品工作台，可以用来快速创造应用的模板，数量代表有多少客户采用模板创建应用。通过以上数据可以感知，【疫情防控】占比最高高达40%，其他部分就很薄弱，因此从领域来说，全行业覆盖的策略长期是可行的，但是短期不做行业领域细分切入，没办法带来平台的发展。而且零散的小应用并不属于一个企业基本的应用规模，那么宜搭平台产出的内容就有点儿大材小用。所以从工具当前呈现的结果，面向人人都能使用平台，其中“人人”并不是独立的个体户，必须是有一定规模的企业主才能有高质量的产出。

2.竞争环境

竞争是市场客观存在的情况，单从低代码维度出发的产品公司，大概率数量级不少，但要在业界产生影响力的，可能还是需要关注巨头当下对低代码的布局，就宜搭本身生态而言，同类巨头中，能够感知腾讯云推出了Lowcode平台（目前在公测中），百度、字节暂无发现浮出水面的平台，同时早前我还了解到，阿里内部其实还有一个叫云凤蝶的产品，也是低代码模式。此外，国外Outsystems，是我目前有所关注的，也是我见过最复杂的低代码工具。

当然，除了头部的玩家，其他只要通过搜索引擎基本上可以发现明道云、轻流、氚云、白码、简道云等低代码平台。而这些玩家之间，核心讲的故事都是趋同的，实现的路径方式可能会大同小异。但无疑这是一个蓝海细分领域，大中小玩家都可以参与，但要带来生态发展比拼的是背后的生态伙伴。这样的竞争环境，各取所长是当下的基本状态。

3.存在的挑战

低代码领域的挑战，通过对PaaS和SaaS领域的从业经历提炼，基本可以感知的挑战如下：

竞争要求

通过基本了解低代码平台产出的SaaS产品大多属于简单应用系统，因此如何与存在更专业垂直的服务的SaaS产品竞争，低代码的输出内容竞争力有待挖掘

设计要求

B端行业特点，差异化较大且广，因此标准化的业务场景如何精准设计对设计者提出了较大的抽象要求，客观上通用的抽象又必须建立在不同行业的业务沉淀，因此领域需要做聚焦。

技术要求

低代码本质上就是将代码开发的全流程，通过图形组件化的方式转义串联，让用户可以脱离代码开发的限制，而完成应用开发。因此从整个开发流程上看，至少一个便捷的可视化操作工具，前端框架的选择和搭建便是第一层难点，紧接着便是背后将涉及到大量的数据与权限的管控，流程和业务通用适配，对后端开发提出较强的建模能力要求。同时，在业界PaaS化的产品，一定面临着大量的差异系统的整合和集成，因此对最终产出的SaaS应用，集成后若出现规模化使用，性能将会是后续将面临的问题。

收费模式

宜搭一共采取了两种收费模式：按版本规格收费和按年收费，基本上符合平台化的定价策略

收费模式分析
一个产品的收费模式，属于产品商业化关键一环，市面上大多B端产品，会采用年服务费+增值服务收费方式进行商业化处理，其中如开放平台多以API服务/SDK使用量、额度来做差异收费。

宜搭作为平台产品，它的收费差异依托于核心业务是以表单功能和数据存储为主，因此定价设计主要聚焦在数据量和容量上，同时也提供了扩容收费服务，因此，我们可以通过简单计算标准版VS尊享版数量级关系，来分析背后收费模式设计的逻辑。

通过以上标准版与尊享版数据对比，我们可以看到差异定价关键的控制变量为【数据量】，同样是30人，差异2000元，除功能维度上尊享版相比标准版拥有更多定制化高级内容以外，数据量多1倍。那么，定价策略的设计者是如何思考的呢?。

首先，从产品本身能够提供的能力出发，定价要产生差异，肯定会从现有能力上做区分，且功能差异必须能区分不同的典型客户，因此标准版和尊享版核心在聚焦高级定制功能模块做了差异。基本思路可以理解为，存在定制需求的公司，从业务上大概率相较于通用模板要复杂，而在投入开发后，随着业务发展需求，客户为实现业务开发，自然会选择进行付费完成开发工作，这是功能性差异定价常规的定义方法，比较容易理解。

其次，我们知道数据存储本身肯定是不值钱的，但数据量成为关键的核心原因，肯定逃不掉宜搭平台目前的核心业务是以表单设计为驱动的，从表单维度，能够产生数据变化，对客户产生边界收费的，只能从表单内容本身和表单投放后被提交的数量上进行策略。因此数据量和容量的指标数据便以此而产生。

最后，为了增加持续性的付费，同步设计了资源扩容年服务方式，版本差异收费主要是对搭建临时应用服务的客户进行收费，这一类客户的付费生命周期就只有一次，而扩容服务费用则是针对需要持续性投入的客户，那么此模式就是与SaaS的续费模式有相似的方式。

4.宜搭首席技术官的分享

说明：此部分为官网阿里云社区专栏文章，里面内容已经有较深度的提炼，下文仅做部分排版修改，用做分析参考。
原文链接：https://developer.aliyun.com/article/711991?spm=a2c6h.12873581.0.0.16f35c74Q9XJRB&groupCode=yida

（1）关于产品架构的分享

产品架构解读

应用使用者 宜搭提供了对内和对外两个版本，内部版包括了正式、外包和生态化公司员工，外部版包括了钉钉和第三方企业用户。再细分一下，宜搭平台的用户被划分为两类：应用管理员和应用访问者。应用管理员即是搭建应用的用户，而应用访问者指的是搭建完成的应用的最终使用者。

输出端 目前宜搭未提供自己的APP端，使用阿里内外以及钉钉来承载，此外也有自己的H5页面。

宜搭平台 分为两态，即管理态和运行态。管理态仅支持PC访问，提供给应用管理员来创建编辑发布应用；运行态支持PC以及移动端访问，提供给应用访问者即真正的业务用户。

基础依赖 宜搭平台提供一站式的解决方案，集成了框架、中间件、等诸多基础服务。

（2）关于产品核心特征分享

特征总结为5点：低门槛、一站式、泛业务、高定制、高集成。

核心特征解读

低门槛 由于是应用开发的平台，目前开发平台最直接的方式就是写代码。但是我们需要意识到，由代码构建的系统就是对客观运行的业务系统规律的一种描述方式，这种方式并不是唯一的，只不过目前受制于生产力或者说技术工具亦或是技术手段，才导致目前编码几乎是唯一的开发平台的有效方式，也就是形成这样的链路：业务需求 —> 开发编码 —> 应用系统。如果我们可以把中间的开发编码环节替换掉，变成更容易使用的门槛更低的方式，即：业务需求 —> 开发平台 —> 应用系统，门槛的降低将支撑起更多的用户，此外操作的简化将带来效率的提升与错误率的降低。因此，宜搭平台自创建开始，就是定位给无编码基础的用户，希望可以附能于非开发岗位的业务同学，帮助他们去实现自己的业务系统。这里的用户特制使用宜搭平台进行开发的用户，而宜搭平台开发的系统面对的用户是不会变的，就是业务同学。

实现思路：更新认知模式、丰富可视化、设计简洁、提供快捷操作

一站式 承接用户定位，要求平台必须提供一站式的能力，包括研发流程支撑、开发环境支撑、运行环境支撑、监控运维支撑等等。研发流程支撑，传统的为：提交需求—>确定产品方案—>评审—>开发—>测试—>验收—>上线，横跨多人甚至多个团队部门，往往还需要立项来管理，研发上也需要考虑设计、安全、适配性等等问题，使用宜搭平台之后，这些工作均可以交给一个人来完成，效率大大提高。开发环境支撑，传统的JAVA WEB项目，需要自己使用框架编写代码，并申请数据库、应用服务器、缓存、消息队列、文件存储等等来进行支撑，成本较高，并且使用这种方式编写的代码无法跨系统复用。运行环境支撑，传统的需要运行在自己的服务器上，而使用宜搭平台之后，由平台提供，背后对用户完全不可知，并且后续也提供了丰富的升级可能。监控运维支撑，传统的方式，业务数据需要自己埋点监控，而由宜搭平台提供之后，全部交由平台管理，在平台统一查看。

实现思路：自动化，将与业务不相关的内容以自动化方式处理；多租户，支持应用服务与应用数据，逻辑和物理隔离
泛业务 由于不指定支撑的业务领域，因此要求平台的模型更加的抽象。抽象始于“特殊”归于“一般”，要求宜搭去收集大量的场景，提炼出背后的一般规律，精炼出模型和逻辑。宜搭在初始阶段，调研了行政、财务、法务、IT、资产等等业务，决定使用页面、逻辑、数据这三块作为底层的核心模型。经过2000多个应用的实践打磨，基本证明了这条路的可行性。

实现思路：通用模型抽象，支撑多业务场景；分层思想，搭建出领域模型层、数据层提供更强的业务能力支撑

高定制 由于需要支撑各个领域的业务，并且即使是相同领域的相同业务场景，其需求受到时间地点人员等等制约，也可能是不一样的。如何设计一个高定制的研发平台，其实就是在可变性和封装之间获取一个平衡，封装程度越高，用户使用成本越低，但是其响应变化的能力越差，以国外产品infor为例，其将沉淀了数十年的业务领域封装为领域模型，开放出来的仅仅是预先设置好的数据属性字段配置以及业务逻辑扩展点，假设这个业务领域发生了变革，那么影响是致命的。而如果放弃了领域模型的封装，那么可变性必然会提高，但是用户的使用成本将大大上升，并且无法实现业务模型的复用。为了响应用户更灵活的需求，宜搭在设计上选择了后者，并且已经想到了针对这个问题的解决方案，就是分层，下文会展开描述。

实现思路：提供逻辑编排、扩展点和执行插件用于响应定制领域业务需求

高集成 企业软件架构设计阶段里面，有一个重要的考虑环节就是架构迁移规划。假设宜搭平台已经足够成熟，成为了企业应用搭建中台之后，老的系统迁移到新的系统架构也是需要时间的，如何一步一步安全平滑稳定的迁移，中间的过渡方案是什么，都是需要考虑的问题，更何况宜搭平台还处在产品的创新摸索阶段。在DT时代，要求我们在数据和应用层面打通，提供一体化的体验，实现各个系统间的连接，因此就需要强大的开放和集成能力。开放指的是平台提供标准，供其他系统调用，而集成指的是平台调用其他各个系统，这里面就需要用到依赖倒置的思想，将需要集成的其他系统的服务规范起来。
实现思路：主要进行接口开放和接口集成，其中接口集成会支撑执行插件层和数据层

（3）关于技术架构分享

技术架构解读

说明：此部分由于作者并未做详细说明，我这边仅从产品维度的个人解读，可能存在不合理地方，欢迎指出

技术架构分为四层：展示层、开放层、服务层、数据层，其实基本可以理解为界面设计、业务逻辑处理、数据存储，其中开放层属于能力对接，增加扩展性。其他三部分简单理解如下

展示层：主要指负责界面维度元素的编排和管理，可以理解为涉及到界面维度元素的内容支撑的内容便服务于这层，如页面的设计布局以及渲染，便与架构组件、设计引擎和渲染引擎强相关，Native移动端和H5都是建立在核心引擎下，完成内容搭建。

服务层：主要负责业务数据输入与输出中间的逻辑管理和处理，负责承接展示层的数据输入，以及通过一定处理后完成输出至展示层，而需要计算或持久化的部分则提供给数据层。服务层对上提供业务支撑，对下承担数据资源的管理。

数据层：主要负责数据的存储、查询、分析等，这部分结合核心业务相对比较好理解，本质就是围绕海量数据的处理机制的支撑。

四、产品解构

说明：产品解构主要围绕拆解产品实际功能设计和场景应用，并从中挖掘产品真实的核心用户和核心价值，以及对未来可能发展方向思考

1.产品业务架构

业务架构说明

通过对产品整体的梳理，宜搭整体平台主要分为六大块：官网、开发者平台、PaaS平台、IaaS平台、内部支撑系统、生态协作系统。其中官网和开发者平台是面向客户即对外用户可见的内容，其余部分属于根据对业务理解进行的结构梳理，可能与实际产品形态存在偏差，仅做分析使用。

（1）开发者平台——消费者

根据上文分享，此部分属于宜搭平台的管理态，主要为面向用户（开发者）的应用开发工具，用户主要承担PaaS层提供能力的消费者身份。开发者通过平台提供的设计器，可完成web/移动端应用开发。其中应用由多个页面组成，每个页面根据类型，可通过对应设计器完成内容开发，目前主要表现为普通表单、流程表单和数据报表的设计。

设计器可以支撑完成应用的数据和业务逻辑编排，其中模板和组件作为核心消耗品是快速开发的前提，应用设置提供了应用用户管理员部分功能，并且与钉钉体系打通，可完成与钉钉联动，此部分主要为PaaS平台与钉钉开放平台完成系统打通的结果。

同时，开发者平台提供一键发布上线功能，因此开发者可不用考虑运维部署问题，此部分工作转移到PaaS层的运维监控部分，有平台方提供基础服务支撑。

（2）官网

官网一部分承担产品推广作用，另一部分作为开发者平台核心入口。其中模板中心和帮助中心内容相对丰富，其他部分不具备内容，但预估后续将会衍生应用市场。

（3）PaaS平台——生产者

PaaS平台部分为笔者通过开发者平台结构反推演出来的内容，实际内容肯定比当前业务架构复杂。

PaaS层主要承担中间协调者和开发者平台生产者的身份，完成两大部分的功能：SaaS层（开发者平台）应用和数据服务支撑和管理，IaaS层的资源调度和业务部署等。即在开发者平台可以使用的资源以及生产出的应用原材料，都将由PaaS层提供管理服务。

此外，PaaS平台，还将提供开发者平台中存在很多服务引擎的支撑，常规的PaaS平台还会对外提供API接口或者能力服务。宜搭开发者平台则是内部完成能力的集成的结果，并完成产品化包装。因此，对应的组件和模板，都会配套对应管理模块完成治理。流程和报表相关内容，则需要基本业务编排能力，即对应的规则引擎、流程引擎等。

最重要的一点，PaaS部分负责与钉钉开放平台形成能力交换，后续能力会更丰富。

（4）IaaS平台
此部分已经属于比较成熟的阿里云服务，包含计算、存储、网络、安全等。不做描述

（5）内部支撑系统
此部分属于针对宜搭开发者平台，团队内部其它协作系统，主要包含了日常运营管理、数据治理、安全、客服、内容、风控等，此部分不同公司内容不同，但对于平台级别的公司，这部分内容的架构设计，将极大程度影响开发者平台的发展，属于内部系统效率的体现

（6）生态协同系统
此部分与宜搭出身有关，所以可以理解涉及到阿里内部生态的钉钉开放平台和阿里云通用也是核心支撑。

业务架构小结

通过业务架构可以通过俯瞰视角来查看宜搭平台协作系统之间的关系状态，以目前来看，宜搭背后承载的技术沉淀虽然很丰富，但目前暴露在开发者平台上的工具能力还属于冰山一角，从平台搭建维度来看，主体应该依旧围绕以开发者为中心的平台工具建设，因此，辅助开发者建设更完善的产品应用，以及寻找应用更多落地需求方，通过钉钉引入搭建开发者生态，是后续会出现的内容。

2.产品功能结构

功能结构说明

功能结构主要针对开发者平台产品详细功能内容调研，即包含哪些功能点，具备哪些可配置内容，以及涉及哪些元素的盘点。由结构图可知，平台主要由主页和设计器两大部分组成，其中设计器是内容最丰富部分，简要说明如下：

（1）配置层级结构

（2）设计器类型

由功能可知，平台核心在于两大类型的设计器：

表单设计器
主要围绕表单页面搭建的元素提供组件和配置项，表单一般包含提交/编辑页面、和列表页面，同时在加入审核流，即流程表单属于表单功能的升级，整体都属于比较单一的页面框架，因此此部分将两者共用同一个设计器，但内容存在差异，主要在流程由审核人，以及流转过程。另外，还存在一个最丰富的表单即为门户类型页面，它的特点是支持更多的布局排版，更多是内容的展示，但区别于报表。

报表设计器
主要围绕数据分析图表类的页面，报表则设计大量的数据统计和可视化展示的需求，因此数据源的配置和图表样式，是核心内容。

另外两大设计器都涉及到容器的概念，容器即可以理解为资源元素的收纳空间，支持独立的逻辑编排，属于云原生的概念，所有组件元素都是在容器中完成资源管理。

（3）编码能力

设计器在基础组件的编辑功能上，提供了属性、样式、高级三大板块的编辑，可视化拖拽功能，降低了门槛，但依旧存在定制化的特性，因此在设计器维度，同步提供了JS、样式编码、数据编码的入口，数据源提供了API获取能力。

部分截图

3.产品体验评估

（1）界面交互方面

作为面向人人都可以开发应用的开发者工具，界面交互的核心，一定是围绕着简洁且开发流程清晰可见、门槛低的方式搭建，因此，编辑器首页设计对建立用户认知模型有很大的关系。

这部分重点对涉及到核心开发流程的界面布局和交互点做对比分析，只对差异点较明显部分做分析，更多内容可自行体验。

宜搭平台 VS 阿里云IoT Studio

说明：阿里云IoT Studio属于同样定位为可视化应用开发的产品，下方通过对比首页和编辑器布局逻辑，可以基本提炼两款产品对开发者视角的感受和差异。

宜搭平台
入口：应用详情

入口：页面编辑——进入主编辑页面

阿里云IoT Studio
入口：应用编辑

**

视角体验（此部分偏主观）

宜搭平台：色调清新，符合钉钉的色系，同时偏年轻化
阿里studio：符合阿里云风格，技术项比较强，相对传统风格

交互体验

宜搭详情首页，有明显引导性，以创建某个类型表单为出发点，然后是以页面为独立单元进行编辑态的进入，但存在以下比较明显体验较差的点：

• 无法在设计中直观全局感受整个应用的形态，预览仅页面，看应用全貌则必须应用级别预览才能看
• 页面编辑/预览/返回，会打开很多标签页，很容易出现设计方向丢失的状态
• 外部链接类型页面，直接就是当前应用丢失，无法返回。

基本流程逻辑图

对比阿里studio：首页虽然无明显的引导创建项目，但默认创建一个空白页面，且整体以应用为单位，画布主页直接渲染了应用发布后的应用形态，更直观。

分析原因：架构差异，宜搭设计器针对不同页面类型不同，因此编辑逻辑产生了以单页面为维度的编辑状态。其他部分，组件拖拽和编辑层级关系都相对比较清晰，都属于体验维度能够接受理解的，核心体验感受：宜搭页面设计有一定的连贯性，但对整体应用开发内容管理缺连贯性的感受，碎片化的感受比较强烈。

以上便是交互维度，最直观体验反馈差异点的分析，其他内容，暂不做分析。

（2）功能实现方面

作为工具，功能实现的点有很多，以下仅指出体验后个人感觉缺失比较明显的部分：

• 最重要的一点：应用缺失版本发布概念，意味着应用处于动态更新状态，这对市场上正常的应用服务来说，是致命的。作为开发者，肯定也不希望自己还在开发的内容，由于保存则直接完成发布更新的状态，因此，应用发布部分，建议打造如开发上线发版形式的流程。有版本记录，有版本号

• 无页面中弹窗页面功能，一方面意味着，所有调整页面将打开新页面，同时没有二次确认，也就是无法做防止误操作相关功能点。

• 数据管理页面，缺失对数据进行二次编辑的页面；同时可以联想到的内容，即针对内容是否支持二次编辑，也就没有对应配置功能。

• 数据详情页面，页面名为新增用户，基本上属于不太理解的页面展示布局，还存在评论功能

通过整体体验，仅从功能实现维度，当前可实现的应用开发，可以说复杂度较低，仅聚焦核心表单设计部分，列表管理的基本增删改查，通过当前编辑器设计还缺失一些必要功能流程。但若快速实现一个记录功能的应用系统，目前可视化可以得出较快的状态，更多功能的迭代开发，只能看后续的发展。

最理想的状态是，普通开发者可以通过这个平台，打造出一款付费SaaS并能售卖给客户，那么开发者才算完成真正的应用开发。

4.核心分析

核心用户及场景

产品定位是人人都能使用的低代码应用搭建平台，但通过实际操作下来，前期的核心用户只有是企业用户且具备一定规模：中小型企业
核心用户：企业开发者中有一定开发能力用户
核心场景：仅人事、财务、行政、销售、采购、协同领域中，工作人员用于做简单表单、简单数据统计的小应用，便于在钉钉或PC端上使用。

核心切入点

目前来看，产品功能基本上符合描述中，以表单场景作为低代码应用开发的核心切入点，门槛较低，但从真正的应用系统来看，它还属于开发人员伙伴说hello world级别的系统应用，可能只对尝鲜的学生有吸引力，商业市场，还需要慢慢打磨。

基于此：需考虑背后对应的公司行业领域市场的要求，如果以此为竞争壁垒的公司，大概率是自建系统，便不属于核心用户

五、总结：以终为始，产品底层逻辑思考——3~5年后的样子

客观来说，基于上面大量现状内容拆解，目前的宜搭平台设计器对于有一定开发经验的人来说上手门槛很低，但从一个产品维度，并没有达到笔者预期的效果。就目前而言，作为个体开发者来说，价值场景并不明显，一个helloworld的应用，如果用作内容教学不存在问题，但要用B端商业场景，确实缺失很多内容。

但无可否认的是趋势是不可逆的，我们需要用发展的眼光来看，给与事物需要沉淀的时间。因此接下来我将结合对低代码未来发展趋势的判断，以及个人对一个理想中低代码平台或零代码应用创作的平台应该具备的形态，做沙盘推演挖掘，依旧是试图通过第一性原理的来进行思考和讨论，若有不足，欢迎交流。

命题1：尝试思考一下低代码开发工具到底要解决什么问题，以及可能有哪些理想的模式状态。

以需求出发

低代码或零代码的愿景是为了打破应用开发者必须掌握计算机语言的客观现实，希望能够通过低门槛的可视化工具让不懂代码编程的人能够按照需求完成应用开发。

“被创造出来的大众需求”

首先，如果我们只关注愿景容易造成默认大众都存在这样的需求，但通过基本的调研了解，需求另一个核心来源于市场现状的诉求，即大量的应用开发其实是在重复造轮子，特别是对于大体量或相对成熟的互联网公司目前更多应用场景需求来源于对同类应用产生的定制需求，内容上实现的东西在某些通用领域大同小异，但因为行业垂直细分的差异，所以便有了不断造轮子的场景，而这部分从公司维度出发，就是资源的浪费，此时更期待一个工具能够让运营人员、业务方可以自行组装，而不是全部由开发人员重新编码实现，这是客观存在的现实。

基于此，我们可以理解为需求原点可能来源于中大型公司级别发展到一定状态后的内部需求，并不是大众的需求；另一方面，当工具创造出来后，从平台公司维度出发，总会期待更多的价值输出，因此产品化的思路，会进一步放大需求可能覆盖的面积，同时结合不断接触到的存在应用需求的客户，让客户的工作人员自行完成开发，可以进一步实现资源高效使用。

从应用未来的样子本身出发

站在开发者视角

站在业务视角

站在生态视角

行业SaaS海量能力，PaaS化。

宜搭做连接器

要做什么

如何做

未来的样子

GTM

校园场景
社群场景
医疗场景

SaaS应用市场

未完待续。。。。。。

相关说明

帮助与反馈