
简介《0 代码搭应用——宜搭开发手册》PDF 面向希望以低门槛方式推进企业信息化的业务人员、管理者与开发初学者围绕业务无系统支持、流程脱节、信息孤岛和开发运维成本高等常见痛点系统介绍阿里宜搭零代码平台的定位与能力。资源包共 1 个 PDF 文件大小约 22.76MB编排上从概念、优势到案例与教程逐层展开先说明什么是宜搭、能支撑哪些办公场景及产品优势再以杭州市一医院、老板电器、居然之家、海纳威等客户案例呈现落地场景随后给出核心要素、快速入门与进阶教程。手册还包含 T 恤尺码收集、设备报修、企业进销存、报表分析、定时消息通知、企业报销流程等搭建实践便于读者按目录对照理解从表单、流程到数据分析的实现思路。已有 6793 人学习适合用作零代码应用搭建的入门参考与案例查阅。1. 从一份 PDF 到能跑起来的第一张表单宜搭 0 代码环境到底该怎么装第一次把《0代码搭应用——宜搭开发手册》.pdf 拖进浏览器的时候我下意识去找 install.exe翻了半天才反应过来宜搭这套 0 代码搭应用的东西压根没有本地安装包真正要装的是账号、租户、浏览器以及那 108 页里藏着的配置逻辑。翻车基本都翻在这一步——有人把手册当科普从头读到尾读完还是不会建第一张表单也有人直接跳过前 19 页的核心要素冲进实践案例里拖控件字段类型选错、流程节点连错返工比重做还费劲。这份手册适合三类人业务侧想自己搭报名表、报修单的IT 侧要评估能不能接进现有系统的还有被1 小时搭完差旅报销这句话吸引来、想亲手验证真假的技术负责人。2. 环境准备账号、租户与浏览器三件套的版本选择2.1 三个前置条件缺一个后面全白干0 代码平台听起来什么都不用装但它对环境的要求换了个形式从软件版本换成了账号权限、租户归属和终端适配。这三样里任意一个不对后面拖出来的表单都是废的。我一般在上手前先把下面这张表过一遍比读十页目录管用。前置项最低要求建议值不满足的后果登录账号可登录企业办公账号组织内正式员工账号个人账号建的应用无法挂到组织下账号角色普通成员应用管理员或组织管理员无法新建应用、无法配权限租户/组织已归属到目标组织组织架构已同步完整部门字段、审批人取不到人浏览器Chromium 内核主流浏览器最新稳定版缩放 100%设计器拖拽错位、组件丢失终端PC 端设计PC 设计 移动端预览双端验证移动端字段错行、按钮点不到账号这一项值得多说两句。宜搭的注册入口走的是企业办公账号扫码登录手册第 108 页有注册入口和沟通群的说明。很多人图快拿一个临时账号先把应用搭出来等要交给业务同事用时才发现应用挂在个人空间里迁移过去权限要一条条重配。血泪经验是先确认组织再动手建应用顺序反了就是重来。2.2 账号与租户初始化把应用建在正确的组织下初始化这一步没什么技术含量但它是后面所有配置的地基。我的习惯是按下面这个顺序走每一步都留一个可回退的检查点。用企业办公账号扫码登录确认左上角显示的组织名称是目标组织不是个人空间。进组织管理确认部门树至少有两级成员列表里能搜到后面要当审批人的同事。确认自己的角色带应用创建权限没有的话找组织管理员开别自己硬试。建一个空应用命名为demo-验证环境专门用来试配置不往外发。这里最容易忽略的是第 2 步。部门字段和审批人选择器都是实时读组织架构的如果组织树是空的或者只有一级你在表单里加所属部门字段时会发现下拉是灰的流程节点里选审批人只能一个个手填人名。这两种情况在搭演示应用时都能凑合一旦上真实业务就是灾难。我自己会先写一份应用初始化配置当施工图格式随意目的是逼自己把命名、归属、角色这几件事在动手前想清楚{ appName: demo-验证环境, owner: 应用管理员账号, orgNode: 总部/信息化推进组, roles: [ {roleName: 填报人, scope: 全体成员, canCreate: true}, {roleName: 审批人, scope: 指定部门, canApprove: true}, {roleName: 查看人, scope: 指定成员, canView: true, canEdit: false} ], visibility: org_internal }这段 JSON 不是平台能直接导入的格式它只是我用来对齐认知的速记。orgNode决定应用挂在哪一层roles决定后面权限配置时有哪几个可选对象visibility决定谁能搜到这个应用。先把这三项定死等到第 4 章配权限时就不会出现临时加一个角色、回头所有节点都要改的连锁返工。提示验证环境别用中文名加空格导出配置、拼接口地址时容易出转义问题用短横线连起来的英文名最省事。2.3 浏览器与终端适配一次搭建双端适配不是自动的手册里反复强调一次搭建、双端适配这句话容易被理解成设计完 PC 版手机端自动就好看。实际不是。双端适配的机制是同一份表单定义在两种渲染模式下分别排布PC 端你排了三列移动端会自动折成一列但字段顺序、必填标记的位置、附件上传控件的宽度都需要单独看一眼。浏览器这块的坑更集中缩放到 125% 或 150% 时设计器的画布坐标和实际渲染会对不上拖进去的组件位置偏移。浏览器开了强制深色模式部分表单底色和字体颜色会互相吃掉预览一片灰。双核浏览器的兼容模式会退回旧内核设计器能打开但拖拽会卡死报错都不会给。我一般的做法是设计阶段固定一个浏览器窗口缩放 100%不装花哨的主题插件每搭完一个模块切到移动端预览跑一遍重点看三个地方——必填项红星的排列、日期和下拉控件在窄屏下的弹层、附件上传按钮是否被挤到折叠区里。这三处是返工率最高的地方。2.4 手册资源落地校验先确认你手里这份文件是完整的既然是拿 PDF 当安装介质那第一步得确认文件没坏。我遇到过下载中断导致后 20 页空白的情况翻到实践案例那一章直接是白页还以为是手册排版问题。常见做法是用命令行核一下页数和文件指纹# 查看 PDF 元信息重点看 Pages 是否与目录页码对得上正文到 108 页左右 pdfinfo 0代码搭应用——宜搭开发手册.pdf # 计算文件指纹方便多设备之间比对是不是同一份 md5sum 0代码搭应用——宜搭开发手册.pdf # macOS 下用md5 0代码搭应用——宜搭开发手册.pdf # 把关键章节单独抽出来做速查需要 poppler-utils pdftotext -f 19 -l 44 0代码搭应用——宜搭开发手册.pdf core-chapter.txtpdfinfo输出的 Pages 字段是最直接的完整性指标手册目录排到 108 页实际页数应该在 108 上下浮动如果只有 60 多页大概率是下载断了。pdftotext那一段是把第 19 到 44 页核心要素到进阶教程抽成纯文本好处是搭表单时可以在终端里grep字段名不用来回切窗口。参数-f是起始页-l是结束页两个都从 1 开始计数别搞混。注意抽出来的文本会丢掉表格和截图里的信息配置类内容还是要回原页面看文本只用来做关键词定位。3. 手册落地把 PDF 里 6 个实践案例拆成可复现的搭建路线3.1 从目录页反推顺序为什么第一个该做T 恤尺码收集手册第 45 页起的实践案例有六个T 恤尺码收集、设备报修、企业进销存、报表分析、定时消息通知、企业报销流程。很多人按兴趣挑上来就啃企业进销存结果卡在关联表单和数据联动上直接放弃。这六个案例其实是一条能力递进线。T 恤尺码收集练的是单表收集加汇总统计是最小闭环设备报修在单表之上加了流程节点和状态流转进销存开始涉及多表关联和库存扣减报表分析练的是把前面几张表的数据聚合定时消息通知是流程之外的时间触发企业报销流程则是把所有能力串起来的综合题。我建议的搭建顺序和手册排列一致不要跳。前两个案例走完你对字段类型、必填校验、流程节点的感觉就建立起来了后面三个才有意义。跳过前两个直接做综合题等价于没学走先学跑。3.2 六个案例对应六块能力别只当练习做把案例当练习题做一遍就完事是浪费这份手册。每个案例背后对应的是一类真实业务场景我按自己的理解做了张映射表搭的时候对照着看比逐个抄步骤效率高得多。案例练的核心能力对应真实场景建议耗时T 恤尺码收集单表收集 汇总统计报名登记、调查问卷、物资申领40 分钟设备报修流程审批 状态流转工单、故障上报、任务派发60 分钟企业进销存多表关联 数据联动库存管理、订单跟踪90 分钟报表分析数据聚合 图表展示经营看板、质量趋势60 分钟定时消息通知时间触发 消息推送到期提醒、日报推送40 分钟企业报销流程综合串联 权限分层费用审批、合同会签120 分钟手册里提到的几个真实落地场景也能印证这个映射某三甲医院用半个月做完合同与预算的内控升级走的就是流程审批 权限分层这条路某厨电制造企业把关键物料检验、内部质量、供应商质量三张表拆开搭用的是单表收集 报表分析的组合某家居连锁企业改造办公流程时把审批和财务、支付打通靠的是接口能力某箱包代工企业铺了上千个工位的生产执行系统本质是表单 流程 报表三件套的规模化。这四个案例的共同点是没有一个是靠写代码堆出来的全是配置。3.3 第一张表单的字段定义先写下来再拖控件真正动手时我建议先在文本里把字段写清楚再去设计器里拖。边拖边想字段类型十有八九要改三四轮。以 T 恤尺码收集为例我会先落一份这样的字段清单{ formName: T恤尺码收集, fields: [ {id: f_name, label: 姓名, type: text, required: true, unique: true}, {id: f_dept, label: 部门, type: department, required: true}, {id: f_size, label: 尺码, type: radio, options: [S,M,L,XL,XXL], required: true}, {id: f_qty, label: 数量, type: number, min: 1, max: 5, default: 1}, {id: f_remark, label: 备注, type: textarea, maxLength: 200} ], submitLimit: {perUser: 1, message: 每人限填一次如需修改请联系管理员} }几个参数值得单独说。unique: true加在姓名上配合submitLimit.perUser做双重限制前者防止同名重复提交后者防止同一账号反复刷。type: department是组织架构类型不是普通文本选对了后面报表才能按部门自动分组选错了就只能手工归类。min/max限定数量区间比只写一句请填 1 到 5靠谱得多。maxLength: 200是给备注兜底不设上限的话有人能贴一整篇文档进来导出 Excel 时单元格会炸。3.4 进阶教程那 20 页真正要读的只有三块第 24 页开始的进阶教程信息密度最高但没必要逐字读。我按踩坑频率筛出了三块必读第一块是页面设计。它讲的是怎么用自定义页面把多个表单的数据摆到一个看板上不是简单的拖表格。这块跳过你后面做任何首页门户都得重来。第二块是业务规则定义。也就是常说的联动、显隐、赋值。举个最小例子尺码选了 XXL 就自动把数量上限抬到 8其他尺码还是 5。这类规则在手册里叫业务规则实际配置入口在字段属性的联动设置里不在流程里第一次找很容易找错地方。第三块是数据收集与分析。这块讲的是表单数据怎么变成可筛选、可聚合的数据源。跳过它报表分析那个案例基本做不下去。提示进阶教程里的截图是旧版界面按钮位置和现在有出入但配置项的层级关系没变照着文字描述找对应菜单比照着截图找按钮快。4. 配置核心表单、流程、权限的三层参数体系4.1 表单层字段类型选错后面全是补丁表单是整个应用的地基字段类型选错了流程和报表都要跟着打补丁。最常见的三类误选一是把部门人员当普通文本填。文本存的是字符串报表分组时技术部和技术部 多个空格会被算成两个部门。用组织架构类型存的是唯一标识显示才走名称。二是把金额用数字类型但没设精度。默认两位小数看着够用遇到单价乘数量的计算就会出现 0.30000000000000004 这种浮点尾巴导出对账时特别难受。设成两位小数并开启四舍五入。三是把多选当单选用。有人为了省事把所有选项都塞进单选业务上一旦要选两项就得再加一个字段数据结构从此歪掉。下面这份字段配置是我常用的模板直接照着改标签就行{ field: f_amount, label: 报销金额, type: number, precision: 2, roundMode: half_up, min: 0, max: 100000, required: true, tip: 超过 5000 元需附发票扫描件 }precision控制小数位roundMode用half_up是财务口径的常规选择tip是给填报人看的说明比在表单顶部写一大段备注有效。max设上限不是为了防坏人是为了防止有人把 10000 打成 1000000导致后续汇总报表整个失真。4.2 流程层节点、审批人和空节点策略流程配置的难点不在拖节点在审批人为空时怎么办。默认行为是流程卡住但很多人根本不知道有这个设置等到上线后某个部门的负责人没配单据全堵在那里才发现问题。我自己配流程时会把节点定义先写出来{ processName: 设备报修流程, nodes: [ {key: start, type: start, title: 提交报修}, {key: n1, type: approval, title: 班组长确认, assignee: {type: role, value: 班组长}, emptyStrategy: toSuperior, timeout: {hours: 4, action: remind}}, {key: n2, type: approval, title: 设备科派工, assignee: {type: role, value: 设备科}, condition: urgency 高}, {key: n3, type: cc, title: 抄送财务}, {key: end, type: end} ] }assignee.type用role而不是写死人名人员变动时不用改流程。emptyStrategy设成toSuperior表示审批人空缺时自动上抛给上级这是最常见的兜底做法比设成自动通过安全得多——自动通过等于跳过了审批。timeout那段是超时提醒4 小时没处理发一次通知别设太短半小时一提醒会被当成骚扰。condition那行是条件分支只有紧急程度为高才走设备科普通报修班组长确认完就结束这条能省掉大量无效流转。注意条件分支的表达式里等号右边的值要和表单里选项的文本完全一致多一个空格条件就永远不成立而且不会报错属于典型的黑匣子问题。4.3 权限层表单权限、数据权限、字段权限是三件事权限这块最容易混淆因为三个名字都带权限作用范围完全不同。表单权限管的是能不能打开这张表、能不能提交。数据权限管的是打开之后能看到哪些行。字段权限管的是这一行里的哪些列能看、哪些列能改。举个具体场景报销流程里普通员工能提交自己的报销单表单权限但只能看到自己提交的记录数据权限并且金额和发票号只能看不能改字段权限。财务能看全部记录能改金额但改不了提交人。这三层要分别配只配第一层的话员工能翻到别人的报销金额这在任何组织里都是事故。角色表单权限数据权限字段权限填报人新建、编辑自己的仅本人数据金额只读、附件可上传直属主管查看、审批本部门数据全部只读财务查看、编辑全组织数据金额可编辑提交人只读审计仅查看全组织数据全部只读含操作日志配权限的顺序建议是先定角色再定数据范围最后收字段。反过来做字段权限配到一半发现角色划分不对前面全废。4.4 通知与集成消息提醒和接口联调的落地参数消息提醒这块手册里定时消息通知那个案例讲得最实用。三类提醒要分开配提交成功给填报人的即时回执、节点待办给审批人的实时推送、超时未处理的催办。前两类是流程自带的能力第三类要单独配定时任务。定时任务的参数就三个要调触发时间、触发频率、推送对象。触发时间别设在整点整点任务容易堆积频率按业务节奏设日报类的每天早上一次就够工单类的按小时。推送对象一定要选角色或条件筛选后的数据集别选全体成员否则一个报修提醒会推给全公司。集成这块手册里某家居连锁企业的案例讲得比较细审批节点提交时通过回调服务处理数据主数据从人事系统单向同步到宜搭同步逻辑是以源系统的编码为唯一标识存在则更新、不存在则新增。这套以源系统为主、单向同步的原则值得照搬双向同步看着方便一旦两边都能改冲突处理能让人崩溃。配置回调时我一般会先做一个最小验证回调地址先指向一个只打印请求体的调试端点看平台实际发过来的字段名和结构再对着改映射。跳过这步直接写业务逻辑十有八九是字段名对不上而且错误信息很少只能一行行猜。5. 排查0 代码搭建里最常见的 5 个翻车现场5.1 现象表单预览正常移动端一片错位现象是最迷惑人的一种PC 端设计器里排得整整齐齐切到移动端预览字段顺序乱了附件上传按钮跑到屏幕外日期控件点开是空白。原因通常是两个。一是用了多列布局移动端强制折成一列后原本左右并排的两个字段变成上下中间的间距和分隔线没有跟着适配。二是控件宽度写死了像素值PC 端够宽移动端就溢出。解决办法是放弃像素级的精细排版用栅格比例代替固定宽度字段尽量保持一行一个的设计思路把并排关系交给平台去折。附件和日期这类自带弹层的控件单独在小屏上点一遍确认弹层能完整显示再往下走。5.2 现象流程走到某个节点就停住没有任何报错现象是单据提交成功第一个审批人也处理了但流程不往下走页面上什么提示都没有日志里也查不到异常。原因是审批人解析失败。节点上配的是角色但这个角色在当前组织下没有任何成员或者配的是部门负责人而这个部门没设负责人。平台的默认行为是静默等待不报错。解决办法是给每个审批节点都显式设置审批人为空时的策略设成上抛给上级或者转交给指定管理员别用默认值。上线前拿几个边缘部门新建的、人员没配全的各提一单专门验这条路径。5.3 现象报表统计的数字和明细对不上现象是明细表里数出来 100 条报表里汇总显示 97 条差的 3 条怎么找都找不到。原因多半是数据权限过滤。报表统计默认走的是当前查看人的数据权限你用小范围账号看报表自然只统计到你能看到的那部分。另一个可能是提交时间跨了时区或跨了自然日边界按今天筛的时候把昨晚 23:50 提交的漏掉了。解决办法是先确认查看报表的账号数据权限范围用管理员账号再跑一遍对比。时间维度上把筛选条件从今天改成具体的起止时间戳避免自然日边界带来的歧义。5.4 现象多人同时提交编号重复或数据串行现象是给表单加了自动编号平时没问题一到集中填报比如全员收集尺码就出现两个一样的编号或者 A 提交的数据跑到 B 的记录里。原因是自动编号用了查当前最大号加一这种逻辑。并发提交时两个请求查到同一个最大号各自加一结果撞号。串行问题通常出在用了共享的临时变量存中间状态。解决办法是编号改用平台自带的序列号能力它内部做了并发控制。如果没有这个能力退而求其次用时间戳 用户标识后四位组合虽然不好看但不会撞。共享变量的问题只能靠改结构每次提交都重新取值别复用。5.5 现象接口联调一直超时抓包看不到请求现象是配了回调地址流程提交后对方系统没收到数据平台侧显示调用失败但错误信息只有一句请求超时。原因是回调地址配置在了内网平台的出口访问不到或者对方要求的是 HTTPS 而配置里写的是 HTTP被静默拒绝了。这两种情况在本地用工具测都是通的所以特别难查。解决办法是先把回调地址换成一个可以从公网访问的调试端点确认平台能发出来再逐步换回真实地址。真实地址必须走公网可达的域名协议和端口要和对方对齐。别在本地用 hosts 映射测测通了上线还是失败。6. 装完怎么验证用T 恤尺码收集跑一遍端到端冒烟测试环境装完、配置配完最后一步不是看着没问题就行而是走一遍端到端。我固定用 T 恤尺码收集这个案例做冒烟测试因为它足够小20 分钟能跑完但把表单、校验、权限、报表四条链路都覆盖到了。具体走法是这样的先用管理员账号建好表单用三个不同角色的账号各提一单——一个正常填写、一个故意漏填必填项、一个重复提交。然后切到报表页看汇总数字最后导出一次数据。验证项操作期望结果不通过说明必填校验只填姓名就提交提示部门/尺码未填不落库校验规则没生效唯一性同一账号提交两次第二次被拦截并提示提交限制没配数据权限用普通成员账号看列表只看到自己那条数据范围配宽了字段权限普通成员打开自己记录备注可改、姓名只读字段权限没分层报表统计管理员看汇总总数等于实际提交数数据权限或时间筛选有偏差导出导出 Excel列名、顺序与表单一致字段别名或排序有问题这六项里我最看重数据权限和报表统计这两条。前四项是功能对不对后两项是会不会出事。功能不对用户会来问你权限配宽了没人会告诉你等到某天有人在群里贴了一张截图才发现那时候数据已经流出去了。还有一个小习惯每配完一个模块把当前配置导出成一份快照存着文件名带上日期和版本号。0 代码平台改配置的成本极低低到你会不知不觉改坏一个跑了半个月的流程而且改的时候完全没有感觉。有快照至少能对比出是哪天动的哪一项这比任何日志都直接。从那以后我每次搭完应用不管多急都强制走一遍这六项冒烟再导一份快照。这两步加起来不到半小时但省下的返工时间是以天计的。希望帮到你。本文还有配套的精品资源点击获取