企业官网建设流程全解析

简介：《0 代码，搭应用——宜搭开发手册》PDF 面向希望以低门槛方式推进企业信息化的业务人员、管理者与开发初学者，围绕业务无系统支持、流程脱节、信息孤岛和开发运维成本高等常见痛点，系统介绍阿里宜搭零代码平台的定位与能力。资源包共 1 个 PDF 文件，大小约 22.76MB，编排上从概念、优势到案例与教程逐层展开：先说明什么是宜搭、能支撑哪些办公场景及产品优势，再以杭州市一医院、老板电器、居然之家、海纳威等客户案例呈现落地场景，随后给出核心要素、快速入门与进阶教程。手册还包含 T 恤尺码收集、设备报修、企业进销存、报表分析、定时消息通知、企业报销流程等搭建实践，便于读者按目录对照理解从表单、流程到数据分析的实现思路。已有 6793 人学习，适合用作零代码应用搭建的入门参考与案例查阅。

1. 从一份 PDF 到能跑起来的第一张表单：宜搭 0 代码环境到底该怎么装

第一次把《0代码，搭应用——宜搭开发手册》.pdf 拖进浏览器的时候，我下意识去找 install.exe，翻了半天才反应过来：宜搭这套 0 代码搭应用的东西压根没有本地安装包，真正要"装"的是账号、租户、浏览器，以及那 108 页里藏着的配置逻辑。翻车基本都翻在这一步——有人把手册当科普从头读到尾，读完还是不会建第一张表单；也有人直接跳过前 19 页的核心要素，冲进实践案例里拖控件，字段类型选错、流程节点连错，返工比重做还费劲。这份手册适合三类人：业务侧想自己搭报名表、报修单的，IT 侧要评估能不能接进现有系统的，还有被"1 小时搭完差旅报销"这句话吸引来、想亲手验证真假的技术负责人。

2. 环境准备：账号、租户与浏览器三件套的版本选择

2.1 三个前置条件，缺一个后面全白干

0 代码平台听起来什么都不用装，但它对"环境"的要求换了个形式：从软件版本换成了账号权限、租户归属和终端适配。这三样里任意一个不对，后面拖出来的表单都是废的。我一般在上手前先把下面这张表过一遍，比读十页目录管用。

账号这一项值得多说两句。宜搭的注册入口走的是企业办公账号扫码登录，手册第 108 页有注册入口和沟通群的说明。很多人图快，拿一个临时账号先把应用搭出来，等要交给业务同事用时才发现应用挂在个人空间里，迁移过去权限要一条条重配。血泪经验是：先确认组织，再动手建应用，顺序反了就是重来。

2.2 账号与租户初始化：把应用建在正确的组织下

初始化这一步没什么技术含量，但它是后面所有配置的地基。我的习惯是按下面这个顺序走，每一步都留一个可回退的检查点。

1. 用企业办公账号扫码登录，确认左上角显示的组织名称是目标组织，不是个人空间。
2. 进组织管理，确认部门树至少有两级，成员列表里能搜到后面要当审批人的同事。
3. 确认自己的角色带"应用创建"权限，没有的话找组织管理员开，别自己硬试。
4. 建一个空应用，命名为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.txt

pdfinfo输出的 Pages 字段是最直接的完整性指标，手册目录排到 108 页，实际页数应该在 108 上下浮动，如果只有 60 多页，大概率是下载断了。pdftotext那一段是把第 19 到 44 页（核心要素到进阶教程）抽成纯文本，好处是搭表单时可以在终端里grep字段名，不用来回切窗口。参数-f是起始页，-l是结束页，两个都从 1 开始计数，别搞混。

注意：抽出来的文本会丢掉表格和截图里的信息，配置类内容还是要回原页面看，文本只用来做关键词定位。

3. 手册落地：把 PDF 里 6 个实践案例拆成可复现的搭建路线

3.1 从目录页反推顺序：为什么第一个该做"T 恤尺码收集"

手册第 45 页起的实践案例有六个：T 恤尺码收集、设备报修、企业进销存、报表分析、定时消息通知、企业报销流程。很多人按兴趣挑，上来就啃"企业进销存"，结果卡在关联表单和数据联动上，直接放弃。

这六个案例其实是一条能力递进线。T 恤尺码收集练的是单表收集加汇总统计，是最小闭环；设备报修在单表之上加了流程节点和状态流转；进销存开始涉及多表关联和库存扣减；报表分析练的是把前面几张表的数据聚合；定时消息通知是流程之外的时间触发；企业报销流程则是把所有能力串起来的综合题。

我建议的搭建顺序和手册排列一致，不要跳。前两个案例走完，你对字段类型、必填校验、流程节点的感觉就建立起来了，后面三个才有意义。跳过前两个直接做综合题，等价于没学走先学跑。

3.2 六个案例对应六块能力，别只当练习做

把案例当"练习题"做一遍就完事，是浪费这份手册。每个案例背后对应的是一类真实业务场景，我按自己的理解做了张映射表，搭的时候对照着看，比逐个抄步骤效率高得多。

手册里提到的几个真实落地场景也能印证这个映射：某三甲医院用半个月做完合同与预算的内控升级，走的就是"流程审批 + 权限分层"这条路；某厨电制造企业把关键物料检验、内部质量、供应商质量三张表拆开搭，用的是"单表收集 + 报表分析"的组合；某家居连锁企业改造办公流程时，把审批和财务、支付打通，靠的是接口能力；某箱包代工企业铺了上千个工位的生产执行系统，本质是"表单 + 流程 + 报表"三件套的规模化。这四个案例的共同点是：没有一个是靠写代码堆出来的，全是配置。

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 分钟能跑完，但把表单、校验、权限、报表四条链路都覆盖到了。

具体走法是这样的：先用管理员账号建好表单，用三个不同角色的账号各提一单——一个正常填写、一个故意漏填必填项、一个重复提交。然后切到报表页看汇总数字，最后导出一次数据。

这六项里，我最看重"数据权限"和"报表统计"这两条。前四项是功能对不对，后两项是会不会出事。功能不对用户会来问你，权限配宽了没人会告诉你，等到某天有人在群里贴了一张截图才发现，那时候数据已经流出去了。

还有一个小习惯：每配完一个模块，把当前配置导出成一份快照存着，文件名带上日期和版本号。0 代码平台改配置的成本极低，低到你会不知不觉改坏一个跑了半个月的流程，而且改的时候完全没有感觉。有快照至少能对比出是哪天动的哪一项，这比任何日志都直接。

从那以后我每次搭完应用，不管多急，都强制走一遍这六项冒烟，再导一份快照。这两步加起来不到半小时，但省下的返工时间是以天计的。希望帮到你。

本文还有配套的精品资源，点击获取