简介《0 代码搭应用——宜搭开发手册》面向希望以低门槛方式推进企业信息化的业务人员、管理者及刚接触应用搭建的开发者针对业务缺少系统支撑、流程脱节、信息孤岛和开发运维成本高等问题系统介绍阿里巴巴宜搭平台的能力与落地方法。压缩包仅含 1 个 PDF 文件大小约 22.76MB便于集中阅读与检索。已有 6790 人学习说明其在零代码应用搭建领域具有一定参考价值。手册从产品简介、核心优势与客户案例切入并给出核心要素、快速入门和进阶教程还配套“T 恤尺码收集”“设备报修”“企业进销存”“报表分析”“定时消息通知”“企业报销流程”等实践案例可帮助读者理解拖拽式页面、表单、流程配置及数据收集分析思路适合作为企业应用搭建的入门指南与案例参考。1. 一本 108 页的手册先看清楚它想解决谁的痛去年冬天帮一个做设备维保的团队梳理报修流程现场是这样的报修人在群里发一张照片加一句“三号机又漏油了”值班的人往共享表格里补一行月底再人工数。他们不是不想做系统是找外包问了一圈报价三万起、排期两个月。翻完《0 代码搭应用——宜搭开发手册》这份 PDF我的判断很直接它瞄准的就是这类“需求真实、预算有限、工期按天算”的场景。手册从产品定位讲到六个完整实践案例把表单、流程、报表三件事拆开讲业务口的同学可以照着搭技术同学可以用它判断哪些需求其实不必写一行代码。它不适合想搭高并发交易系统的人但对收集、审批、统计这三类活够用。2. 把目录读成一张地图108 页里真正要动的是哪 20 页拿到一份手册多数人的读法是第一页翻到最后一页然后在“快速入门”那里卡住。我的读法是先看目录结构判断它把哪几块讲成了体系、哪几块只是案例展示。这份手册的骨架非常清晰前三章是产品与场景铺垫中间两章是操作教程后面一大段是六个实践案例最后是注册入口。真正需要精读的是“核心要素 快速入门 进阶教程”这不到二十页再加上与你场景最像的那一两个案例。前面讲客户故事的部分可以快速扫过它的价值不在技术细节而在于帮你判断“我这个场景有没有人踩过同样的路”。2.1 三个核心要素决定了这个平台的能力边界手册里把平台能力归纳成三块页面设计、业务规则定义、数据收集与分析。这三句话听起来像宣传语但拆开看它就是任何一个业务系统的完整生命周期——数据从哪进来、进来之后按什么逻辑走、最后以什么形态出去。零代码平台能不能撑住你的场景也完全落在这三段上。页面设计对应的是“入口复杂度”。拖拽控件本身不难难的是这个入口要承接多少种人、多少种分支。一个只有内部员工填的单据和一个人人都能扫、还要按身份显示不同字段的入口工作量差好几倍。手册里“一次搭建双端适配”这句话落到实操上就是你在 PC 端拉的三列布局在手机窄屏上会不会挤成一条缝。业务规则定义对应的是“逻辑深度”。简单到什么程度算简单一个字段等于另外两个字段相乘这是最简单的公式。复杂到要走三级审批、不同金额走不同分支、审批通过后还要回写另一张表这已经接近多数零代码平台的舒适区边缘。手册里给的案例大多是后者也就是“能用配置表达清楚”的那一档这正是它的价值所在——它展示的是边界内的做法而不是无限吹。数据收集与分析对应的是“出口能力”。很多人搭完表单就停了觉得数据进去了就完事。实际上业务方第二天就会问上个月按部门统计一下、导出一份给财务、做个趋势图。手册把“报表分析”单独列成一个案例说明这一块在真实项目里占的比重并不低。你在设计表单的时候就应该同步想好后面要按哪个维度聚合否则字段设计一错报表就只能推倒重来。把这三要素记住后面看案例就不会只看到“哦这里点了个按钮”而是能看到“它为什么把这一列设成单选而不是文本”。2.2 六个实践案例其实是一条由浅入深的学习曲线手册后半段给了六个案例表面上是六个独立场景实际上是一条难度递增的路径。我把它们整理成下面这张表你按自己的熟练度挑一个对应的起点不要从中间插进去。案例核心考察点涉及模块建议阅读时机T 恤尺码收集字段设计与数据导出表单、数据管理第一次上手先跑通闭环设备报修流程分支与图片附件表单、流程、附件会建表单之后企业进销存主子表关联与数量金额计算表单、关联查询、公式需要处理一对多数据时报表分析聚合口径与图表选择报表、数据视图数据攒够一批之后定时消息通知定时触发与条件过滤定时任务、消息有催办类需求时企业报销流程多级审批与金额分支流程、条件、权限做正式流程前必读这张表里最容易被跳过的是第一个——T 恤尺码收集。很多人觉得它太简单直接跳去啃进销存结果在主子表关联那里卡三天。尺码收集这个案例的真正作用是让你把“建应用、建表单、填数据、看数据、导数据”这条链路完整走一遍建立对平台操作手感的基本认知。这条链路不通后面每一步都会加倍痛苦。第二个值得说一句的是“设备报修”。它和第一个案例的区别不在于字段多而在于引入了“状态”。报修单从提交到派单到维修完成状态在变而状态的每一次变化都意味着后面可能出现统计需求平均响应时长是多少、哪个片区的故障率最高。这就是为什么流程类应用在字段设计阶段就要把“时间戳”想清楚。2.3 什么场景该上零代码什么场景趁早换方案手册开篇列了企业信息化的几个典型痛点业务无系统支持、与系统流程脱节、信息孤岛、智能化程度低、开发运维成本高。这几条几乎每家公司都能对上号但“对得上号”不等于“该用零代码解决”。我一般会用下面几个问题筛一遍只要有一条命中我就会劝对方重新考虑技术路线。第一这个业务的数据量级是不是以百万行、千万行计并且需要做复杂的多表关联计算。零代码平台的报表能力在万级到十万级数据上表现正常再往上就要看平台的底层存储设计手册里提到分库分表和租户隔离说明它有能力扛但你自己的聚合口径如果写成全表扫描卡住的是你自己。第二这个业务是不是要求强事务一致性比如扣库存和生成订单必须同时成功或同时失败。表单和流程的本质是“记录一次操作”不是“执行一次事务”跨表写数据时出现的中间态需要你自己设计补偿逻辑。第三这个业务是不是有大量外部系统实时交互比如每次提交都要同步调用三个接口并保证顺序。零代码平台通常提供回调与数据服务能力但把它们串成一条可靠的调用链工作量并不比写代码少。反过来什么场景几乎闭着眼睛都能上收集类报名、问卷、登记、盘点、审批类报销、用章、采购申请、请假、台账类设备档案、合同台账、供应商名录、巡检类带照片和定位的打卡记录。这几类的共同特征是数据结构稳定、并发不高、流程节点清晰、统计维度固定。手册里六个案例全部落在这个范围内这也侧面说明了它的能力重心在哪。3. 把「T 恤尺码收集」跑通一次最小闭环的六个动作这是整份手册里最不起眼、但复现价值最高的一个案例。它的好处是十分钟能做完做完之后你对“字段、校验、视图、报表、发布、权限”这六个环节就有了肌肉记忆。后面所有复杂应用都是在这六个环节上加东西。我按自己的操作顺序重排了一遍比手册里的顺序更适合第一次上手的人。3.1 建应用与字段设计先定数据结构再拖控件大部分人打开编辑器第一件事是拖控件拖完发现字段类型选错了回头改改完发现关联的报表全废。正确的顺序是先在一张纸上把字段列出来标好类型和是否必填再进编辑器。尺码收集这个场景我列的字段是这样的字段名类型必填说明姓名成员/单行文本是用成员组件可直接带出部门部门单行文本/关联是若用成员组件可自动填充尺码单选是选项固定避免手填出“XL/加大/180”三种写法数量数字是限制 1 到 5防止误填备注多行文本否特殊体型说明提交时间系统字段自动用于后续按批次统计这张表里最关键的一个决策是“尺码用单选而不是文本”。手填文本看起来更自由但后面做统计的时候“XL”“xl”“加大码”会被算成三个不同类别报表直接失真。凡是后续要参与分组统计的字段一律做成单选或多选这是我在所有收集类项目里都坚持的一条。第二个决策是“数量做范围限制”。数字字段如果不设上下限有人填 999有人填 0.5导出之后你还得清洗一遍。范围限制在字段配置里就能设成本几乎为零。字段建完之后再看布局。PC 端一列放三到四个字段比较舒服手机端会自动折成一列所以字段名称不要太长超过八个字在手机上就会被截断。手册里反复强调的“一次搭建双端适配”落到实处就是这些细节。3.2 校验与提交规则把脏数据挡在入口字段类型只能挡住格式错误挡不住逻辑错误。比如有人选了尺码但数量填 0有人备注里写了“帮我多订两件”却没改数量。这类问题要在提交校验里处理。多数低代码平台的校验表达式写法大同小异下面用常见写法示意// 提交前校验数量必须为正整数且备注含多订时必须改数量 // 不同平台函数名可能不同核心是先判空再判逻辑 IF(ISEMPTY(数量) || 数量 1, 数量必须大于 0, ) IF(备注 包含 多订 数量 1, 备注提到多订请同步修改数量, )这段表达式的逻辑很直白第一条挡住空值和零第二条挡住“说了要加但没改数字”的情况。参数上要注意两点一是表达式返回空字符串代表校验通过返回非空字符串会把提示文案弹给填表人二是这类校验在提交时执行不会实时打断输入所以文案要写清楚让人知道回去改哪里。除了字段级校验还有一类是提交频率限制。收集类表单一旦发出去总会有人重复提交。手册里没有专门讲这个但常见做法是在表单设置里开启“同一成员限填一次”或者用成员字段做唯一性校验。这一步不做后面合并数据时会多出一倍工作量。还有一个小技巧值得说把“是否已确认”做成一个单选字段让填表人自己勾一下。看起来是多余动作实际上它把责任明确到了人后续对账时比你对时间戳有用得多。3.3 数据视图与报表从明细到可读的汇总数据进去之后默认看到的是一个长长的明细列表几十行还能看几百行就没法用了。这时候要做三件事筛选、分组、导出。筛选解决的是“看哪一批”。按提交时间筛出本周的按部门筛出某个片区的这是最基本的。分组解决的是“按什么看”尺码收集最常用的是按尺码分组计数看一眼就知道每个码要订多少件。导出解决的是“给别人看”业务方要的往往还是一个表格文件导出的字段顺序可以在视图里预先排好省得每次手动调整。报表这块有一个口径问题必须提前想清楚统计单位是“人”还是“件”。一个人可能订两件如果报表按记录条数统计出来的是人数如果按数量字段求和出来的是件数。这两个数字经常对不上业务方一看就质疑数据准确性。我的做法是在报表标题里直接写清楚单位比如“各尺码订购件数按数量求和”把口径写在明面上比事后解释省事。手册里“报表分析”那个独立案例讲得更细一些涉及明细表、汇总表和图表三种形态的选择。简单说明细表用于核对汇总表用于汇报图表用于趋势判断。三种都要有但不要指望一张表全包。3.4 发布与权限链接、二维码和“谁能看哪一行”表单建好之后要发出去。发布方式通常有两种一种是生成链接一种是生成二维码。二维码在收集类场景里几乎是标配贴在公告栏、发在群里扫一下就能填比让人找链接点进去的完成率高出一大截。真正容易出事的是权限。权限至少分三层谁能进这个应用、谁能提交数据、谁能看到别人提交的数据。第三层最容易被忽略。默认配置下很多平台会把数据权限设成“所有人可见”你发个尺码收集表出去结果全公司都能看到谁穿 XXL虽然不至于出大事但这种习惯带到报销、绩效这类表单上就是事故。我的配置习惯是填表人只能看自己提交的记录部门负责人能看本部门管理员看全部。这个设置在权限模块里是标准配置项花两分钟配好比事后补救便宜太多。手册里在居然之家那个案例中提到“权限独立设置”说的就是这一层只是案例篇幅有限没有展开实际配置时按上面三层去拆就行。4. 流程、业务规则与定时通知手册里最容易看漏的三块快速入门部分看完大部分人能搭出一个能填能看的表单然后就会卡在“怎么让它自动跑起来”这一步。手册的进阶教程和后面几个案例讲的其实都是这件事让数据自己流转、自己计算、自己提醒。这三块内容分散在不同案例里我把它归拢到一起按配置顺序讲。4.1 审批流的节点、条件分支与在途实例流程配置的界面通常是一条横线加几个方块看起来简单但节点类型的选择直接决定了后面好不好维护。常见的几类节点和它们的适用场景如下节点类型作用常见误用发起人节点定义谁可以发起、发起时填哪些字段把审批意见字段也放进来导致发起人自批审批节点单人/多人/或签/会签该用或签的地方用了会签一个人不点就卡住条件分支按字段值走不同路径条件里引用字段的显示名改个名字分支就失效抄送节点通知但不阻断流程把抄送当审批用导致没人真正负责结束节点回写状态、触发后续动作忘记在结束时更新业务状态字段条件分支是坑最多的地方。假设报销流程按金额分两条路一千以下主管批一千以上再加一级。表达式写成“金额 1000”看起来没问题。但如果这个金额字段是从子表单汇总出来的或者允许填负数做冲抵这个判断就会出问题。我一般会在条件前面加一道校验把金额限制为正数再让条件去判断两层保险。另一个必须提前想的是“在途实例”。流程一旦发布并有人发起你再改节点就会影响这些还没走完的单子。有的平台会把在途实例锁在旧版本上有的会直接报错。手册的案例里没有专门讲这个因为案例都是新搭的。真到了生产环境改流程之前先确认在途单据数量能等就等它们走完再改不能等就复制一个新流程出来老的留着让它自然结束。关于或签和会签的区别用一句大白话说或签是“你们几个谁点都算过”会签是“你们几个必须都点才算过”。部门负责人加分管领导这种场景如果是“任一领导同意即可”用或签如果是“两位都必须签字”用会签。选错了要么流程卡死要么该把关的没把关。4.2 业务规则公式字段、数据联动与提交后动作业务规则这块我习惯按触发时机分成三类分清楚之后再去找对应的配置项比在一个大菜单里翻要快。第一类是计算型也就是公式字段。进销存案例里的“金额 数量 × 单价”是最基础的。稍微复杂一点的是带条件的计算比如“数量超过 100 时单价打九折”。公式写起来不难难的是精度。金额字段一定要显式设置小数位数不设的话有的平台默认保留很多位导出到表格里一长串小数财务看一眼就退回。第二类是联动型也就是选了一个字段之后自动带出关联表里的其他信息。设备报修里选设备编号自动带出设备名称、所在车间、上次维保日期这就是联动。联动的关键是关联字段要建索引或者唯一约束否则选的时候下拉框要转半天。手册里进销存案例对这一块讲得比较细值得对着做一遍。第三类是动作型也就是提交或审批通过之后触发的动作更新另一张表的状态、发一条消息、调用一个外部接口。这类动作的执行顺序和失败处理是最容易被忽略的。举个例子报销审批通过后要回写“已付款”状态如果这个动作失败了单子显示的是审批通过但没付款两边对不上。稳妥的做法是把这类动作做成幂等的也就是重复执行结果一致并且留一个失败重试的入口。// 联动赋值示意选择设备编号后带出关联台账中的车间与维保日期 // 参数说明设备编号 为本表字段设备台账 为关联表单 设备名称 LOOKUP(设备台账, 设备编号 本表.设备编号, 设备名称) 所在车间 LOOKUP(设备台账, 设备编号 本表.设备编号, 所在车间) // 注意关联条件字段必须是唯一值否则返回第一条容易张冠李戴这段写法各家平台函数名不同但思路一致用唯一键去关联表里查一条记录把需要的列取回来。最后那句注释是血泪经验——关联字段不唯一的时候系统不会报错它只是默默返回第一条匹配记录然后你在几个月后发现某台设备的维保记录全挂在了另一台设备上。4.3 定时消息通知触发条件、去重与失败重试定时通知这个案例在手册里篇幅不大但它是所有流程类应用里需求最高频的一个。场景很朴素合同到期前七天提醒负责人、设备保养到期前一天通知维保人、报销单提交超过三天没审批催一下。配置一个定时任务本质上是回答三个问题什么时候跑、跑的时候捞哪些数据、捞到之后干什么。三个问题里最容易出错的是第二个。“捞哪些数据”写成一个过滤条件比如“到期日期 今天 7 天”。如果你只写这一条任务每天早上跑一次那么同一份合同在到期前第七天会被提醒一次这没问题。但如果任务配置成每小时跑一次这份合同当天就会被提醒二十四次。这就是去重问题。标准做法是加一个“已通知”标记字段任务执行时先过滤“已通知 否”执行完把标记回写成“是”。这样无论任务频率多高每条数据只会被提醒一次。如果业务需要多次提醒比如到期前七天一次、前一天再一次那就用两个标记字段或者用一个“提醒阶段”字段记录已经发到第几次。失败重试是第二个容易忽略的点。消息推送依赖外部通道偶尔会失败。失败之后如果任务把标记也回写了这条提醒就永远丢了。稳妥的做法是只在推送成功后再回写标记或者加一个“重试次数”字段失败三次才放弃。这个逻辑在配置界面里不一定有现成的可能需要用一个状态字段自己维护。还有一个细节定时任务的时间点不要都设成整点。多个任务挤在同一时刻执行容易出现排队延迟尤其是数据量大的时候。错开几分钟成本为零。4.4 报表分析案例的拆法先想清楚口径手册里的报表分析案例我建议倒着看——先看它最后出了哪几张图再往回推它用了哪些字段。这个过程能让你发现自己表单设计里缺了什么。常见的报表有三种。明细表用来核对特征是列多、行多、可导出。汇总表用来汇报特征是维度少、指标少、有合计行。图表用来判断趋势特征是有时间轴或者有分组对比。三种报表的数据源是同一份但口径可能不同明细表按记录数走汇总表按业务口径聚合图表按时间窗口切片。容易翻车的是跨表统计。比如要统计“每个部门的报修数量”报修表里如果只存了报修人没存部门那就得通过报修人关联到人员表再取部门。这个关联在报表里做性能通常不如在表单提交时就把部门冗余写进去。我的做法是能在提交时固化的维度字段一律固化成普通字段不要依赖报表时实时关联。数据量小的时候看不出差别上了几万行就是几十秒和几百毫秒的差距。5. 避坑清单五个翻车现场与从现象到配置项的排查顺序下面这五条都是我在照着类似手册做项目的过程中真实遇到过的。每一条我都按“现象、原因、解决”写因为排查的时候你手里只有现象能不能快速定位到配置项决定了你是花十分钟还是花一天。5.1 表单与数据层的三个坑坑一改了字段名流程走错分支。现象把“金额”这个字段的显示名改成了“报销金额”改完之后所有报销单都走了“一千以下”的分支明明填的是五千。原因条件分支里引用的是字段的标识而不是显示名改显示名本身不会破坏引用但如果当时建条件时用的是文本比较而不是字段引用或者平台在改名的同时重新生成了标识引用就断了。解决改字段名之前先在流程、报表、联动规则里搜一遍这个字段被引用了几处改完之后用一条测试数据把每个分支都跑一遍。我现在养成一个习惯字段的显示名可以随便改但标识一旦定下来就不再动。坑二关联下拉框打开要转十秒。现象设备报修表单里选设备编号下拉框点开要等很久设备多的时候直接超时。原因关联查询默认把整张台账表都拉下来做候选几千条数据在小程序端就是灾难。解决给关联字段加过滤条件只查“状态 在用”的设备如果还慢改成先输入关键字再查询的搜索式下拉而不是一次性加载全部。数据量特别大的时候按车间或区域先筛一层把候选集压到几百条以内。坑三汇总金额翻倍。现象报销汇总表里某个人的总金额是实际的两倍。原因主表和子表单是一对多关系主表一条记录对应子表多条明细报表直接对主表金额求和时如果关联方式写成了连接查询主表金额会被子表行数放大。解决先确认金额存在主表还是子表。存主表的统计时对主表去重后再求和存子表的直接对子表求和。这个坑在进销存和报销两个案例里都可能碰到建报表之前先画一张主表子表的关系图比事后对数省事。5.2 流程与集成层的两个坑坑四定时提醒把同一个人轰炸了二十遍。现象合同到期提醒上线第一天负责人收到二十多条一样的消息。原因定时任务设成了每小时执行过滤条件只写了“距到期 7 天”没有排除已通知的记录。解决加“通知状态”字段任务里先过滤未通知的推送成功后再回写状态。如果平台支持任务执行日志看一眼日志里的命中条数就能确认是不是这个原因。坑五审批改版之后在途单据全部卡住。现象调整了审批节点顺序之前提交还没审批完的单子打开就报错或者停在了一个不存在的节点上。原因流程定义变更后老的流程实例仍然按旧定义找节点新定义里那个节点已经没了。解决改流程之前先统计在途实例数量能等就走完再改不能等就复制一个新流程发布老流程保留到在途单据清零再下线。这个操作在多数平台上叫“流程版本”改之前花一分钟确认一下当前版本号比事后找回单据便宜得多。排查顺序上我的习惯是从内往外先看字段配置对不对再看表单规则再看流程条件最后才怀疑平台本身。九成以上的问题出在前三层而且前三层的排查不需要任何工具打开配置页面对一遍就能发现。6. 上线前的最后一道关自检清单与外部系统打通的边界手册讲案例的时候都是理想状态真到自己上线中间隔着一次完整的自检。我现在每个应用发布前都会走一遍下面这张表逐项打勾任何一项不确定就停下来查清楚不确定本身就是风险信号。检查项判断标准不确定时的动作字段类型参与统计的字段是否为单选/数字改成受控类型清洗历史数据必填与校验空值、边界值、异常输入是否被挡用一条假数据把每个校验触发一次数据权限填表人是否只能看自己的用普通账号登录实测一遍流程分支每个条件分支是否都有真实数据走过造一条边界数据走最短和最长路径定时任务是否会重复推送看执行日志的命中条数报表口径单位是人还是件、含不含作废手工算一遍和系统对一次移动端手机上字段是否被截断、按钮是否可点真机打开走完整流程导出导出字段顺序是否可直接交付导一份给业务方确认这张表里最容易被跳过的是“用普通账号实测”。管理员账号天然拥有全部权限用它测什么都通过一上线就出问题。老老实实找一个没配过权限的账号登进去点一遍五分钟能省掉一次事故。和已有系统打通这件事手册在居然之家那个案例里给了五种方式数据服务查询、审批回调、主数据同步、定时任务同步、手动同步。这五种不是随便列的它们对应不同的实时性要求。方式实时性适用场景代价数据服务查询实时表单里需要查外部系统的最新值每次打开表单都要调接口要控频率审批回调准实时审批通过后通知外部系统要做失败重试和幂等主数据同步分钟级人员、组织、岗位变更要定唯一标识和更新策略定时任务同步小时级批量对账、状态回写要有增量条件和断点续传手动同步人工触发运维补救、历史数据补录要有操作日志选型的原则很简单能用定时批量解决的不要用实时调用能用单向同步解决的不要做双向。主数据这类信息以一方为准单向推送比双向同步少一半的问题。同步的唯一标识一定要用外部系统的编码不要用名称名称会改编码不会。最后说一个我自己的习惯。每个应用上线前我会留一个“测试数据”标记字段自己造五到十条覆盖各种边界的数据跑一遍跑完删掉。这个动作看起来很笨但它拦下过至少三次流程分支写反的问题。从那以后我每次发布前都强制走一遍这张自检表和这一轮造数测试没有例外。希望这套流程能帮到你少走几个我走过的弯路。本文还有配套的精品资源点击获取
