企业官网建设流程全解析

简介：《0 代码，搭应用——宜搭开发手册》PDF 面向希望以低门槛方式推进企业信息化的业务人员、管理者与开发入门者，围绕业务无系统支持、流程脱节、信息孤岛、开发运维成本高等常见痛点，系统介绍阿里巴巴宜搭平台的零代码搭建思路。全文以1个PDF文件呈现，压缩包约22.76MB，篇幅精炼，便于在电脑或移动端直接查阅。内容从宜搭的定位、核心能力与产品优势讲起，结合杭州市一医院内控升级、老板电器品质管理、居然之家OA改造、海纳威生产数字化等客户案例，说明平台在真实业务中的落地方式；教程部分覆盖核心要素、快速入门与进阶操作，并给出T恤尺码收集、设备报修、企业进销存、报表分析、定时消息通知、企业报销流程等实践案例，读者可据此理解表单、流程、数据收集与分析的配置逻辑，快速迁移到自身业务场景。目前已有6786人学习，适合作为零代码应用搭建的入门参考与案例手册。

1. 从「T 恤尺码收集」卡住的人，都漏了一步

第一次拿到《0 代码，搭应用——宜搭开发手册》这份 PDF，我不建议你从第一页顺着往下读。手册的编排是「简介 → 教程 → 案例」，很多人翻到「T 恤尺码收集」那一节，兴致上来想照着搭一遍，结果卡在第一步：账号没开通、组织没建、表单权限也没配，页面上能点的按钮比想象中少一半。0 代码，搭应用，宜搭开发手册，这三件事其实是拆开的：手册负责教你怎么搭，账号归属和权限环境得你自己先备好。装不好不会报错，但会出现「我能拖出表单，同事却打不开」「提交了流程，审批人收不到」这种问题，比报错更难查。这份手册适合三类人：想把线下 Excel 收集搬上来的业务同学、被临时派去做内部工具的开发、以及要给团队攒一套报修、报销、进销存小系统的运维。能不能翻完不重要，能不能跑通一条数据才是分水岭。

2. 装前把环境列清：宜搭账号、组织归属与浏览器三件套

2.1 这套环境没有安装包，但有三个前置条件

宜搭是云端平台，本地不需要装服务端组件、不需要建数据库、不需要开端口放行。手册「产品优势」那节写的「无需自己维护服务器和机房」，翻成运维语言就是：你交付的不是一台机器，而是一个组织归属加一个应用空间。所以这里的「安装」实际装三样东西——一个能登录的账号、一个数据有归属的组织、一套能正常拖拽的浏览器环境。

第二样最容易漏。个人身份登录进去建了应用，想把同事拉进来一起填，对方提示无权限；或者从另一个入口重新登录，之前建的表单全都不见了。原因是应用、表单、流程实例、附件这些对象都挂在组织空间下，个人空间和多个组织空间彼此隔离。装之前先把「用哪个组织」定死，后面所有角色、报表、集成都以这个归属为准，中途换组织等于重装一遍。

第三样是浏览器。零代码平台的交互密度比普通后台高，大量拖拽、面板吸附、实时预览，对渲染引擎和缩放比例都敏感。我用离屏缩放 90% 的显示器拖过一次复杂表单，字段总是落在错误的分栏里，查了半天以为是产品问题，把缩放调回 100% 立刻正常。这类玄学问题不值得花时间，把环境先归零。

2.2 开通与归属：五步把地基打完

下面这套顺序是我自己按过的，比先建应用再补权限省事得多。每一步都写了为什么这么排，别跳步。

1. 确认组织已有对应的账号体系和管理员身份。没有管理员权限，后面建应用、加成员、调数据权限都会被拦。不知道谁是管理员就先问，别自己另起一个组织。
2. 用管理员身份进入组织，找到应用搭建入口。宜搭的应用都创建在某个工作台或应用空间下，入口位置以你组织当前版本为准，别照着旧截图找。
3. 先建一个名为sandbox-测试的空白应用空间。这个名字后面有用——所有配置实验都在这里做，跑通了再迁到正式应用，避免把试验垃圾留在生产空间里。
4. 在组织里配三个角色：管理员、应用开发者、普通提交人。手册强调「权限独立设置」，落到操作上就是先有角色，再去挂人，顺序反了就得反复改。
5. 邀请一到两个协作者进来试。至少准备两个非管理员账号，一个用来验提交人视角，一个用来验审批人视角。自己一个人拿管理员账号从头点到尾，是最容易漏权限问题的验证方式。

提示：正式应用不要一开始就建在根目录下。先建分类目录，再往里放应用，后面应用数量上到十几个时，你的目录结构就是唯一的导航。

2.3 浏览器、终端与网络：拖拽挑环境，移动端挑布局

浏览器上我一般固定用 Chrome 或 Edge 的较新版本，缩放保持 100%，关掉自动翻译和广告拦截插件。翻译插件会改写页面文本节点，表单字段的标签可能被翻掉；广告拦截有时会把预览弹层当广告处理掉，表现是「点了预览没反应」。网络侧只要求能稳定访问平台域名，弱网环境下拖拽会明显掉帧，看起来像卡死，其实是在等资源加载。

终端方面，手册里「一次搭建双端适配」这句话是要验证的，不是自动成立的。PC 端配好的表单，在手机上可能因为字段太多、栅格列数太宽而挤成一列，或者必填标记被挤到换行。所以环境清单里必须包含一台真机，模拟器不算数——折叠屏、小屏安卓、平板横屏这三种最容易翻车。

2.4 环境对照表：装之前逐项打钩

表里最后一行是我吃过亏之后加的。早期图省事直接在正式应用里改字段，改到一半被业务催着上线，结果那半天里所有新提交的数据字段都是残缺的，后面清数据比重新配一遍还久。测试空间这个习惯，一次养成，长期省事。

3. 按手册跑通第一条数据：核心要素与快速入门

3.1 核心要素拆成三件可操作的事

手册把宜搭的能力归成页面设计、业务规则定义、数据收集与分析三块。刚上手容易把它们当成三个并列的功能模块，实际是有先后依赖的一条链：表单负责把数据收进来，业务规则决定数据怎么流转和谁能看，页面和报表再把结果摆出来。顺序错了会返工，先做页面再补表单，字段一改页面就得重排。

对应到具体操作，三件事分别是：建表单（字段、类型、校验）、配流程（节点、审批人、条件分支）、做视图（列表、报表、门户页）。手册的「快速入门」和「进阶教程」两节就是按这个顺序铺的，先跑通一条数据再回头补样式，比一上来就把页面做漂亮要快得多。

选哪个案例开始也有讲究。手册里六个实践案例，「T 恤尺码收集」最轻，只有一个表单加一个简单流程，适合第一次验证环境；「设备报修」多了一个状态流转和一条通知，适合验证流程引擎；「企业进销存」和「报表分析」涉及多表关联和汇总，建议放到权限和集成配完之后再碰。上来直接做进销存，八成会在字段关联那步卡住。

3.2 从空白应用到第一条数据：尺码收集怎么落地

在sandbox-测试空间里新建应用，先只加一个表单，字段控制在五个以内。下面是这个收集表单的核心字段配置示意，用 JSON 描述结构，实际是在可视化界面上逐项配出来的，不是贴代码。

{ "formName": "T恤尺码收集", "fields": [ { "id": "employeeName", "label": "姓名", "type": "text", "required": true, "defaultFrom": "currentUser" }, { "id": "size", "label": "尺码", "type": "select", "required": true, "options": ["S", "M", "L", "XL", "XXL"] }, { "id": "mobile", "label": "手机号", "type": "text", "required": true, "rule": "^1[3-9]\\d{9}$" } ] }

这份结构里几个参数值得说清楚。id是字段的唯一键，流程条件、报表维度、后面的集成回调全靠它引用，一旦上线就不要改，改了历史数据就对不上；要改标签就改label，那只是显示名。defaultFrom: currentUser表示姓名默认取当前登录人，省掉手填，也顺带解决了「同名不同人」和「填错工号」的问题。rule是正则，手机号这类固定格式的字段在提交时拦掉，比事后清洗数据便宜太多。options里的选项顺序就是用户看到的顺序，尺码这种有时序含义的列表别乱排。

配完先自己提交一条，确认列表里能看到。这一步通了，说明账号、组织、表单三件套都正常，可以往下加流程。列表视图里建议顺手把「提交人」和「提交时间」加进去，后面排查数据来源时一眼就能定位。

3.3 校验与联动：哪些字段值得花时间配规则

字段配完不等于表单能用。校验规则配多了用户嫌烦，配少了脏数据进库，取舍点在于这个字段后面会不会被用来做判断。会进流程条件的、会进报表分组的、会推给下游系统的字段，一定要卡死；纯备注类字段就别加校验。

联动规则是另一个常被忽略的点。比如「设备报修」表单里选了设备类型，故障现象的下拉项应该跟着变，否则用户选到不相关的组合，维修人员到场才发现带错工具。联动的配置成本不高，但要在表单设计阶段就规划好字段依赖关系，等表单上线再补，已有的历史数据不会自动重算，会出现新旧两套逻辑并存的情况。

3.4 流程节点：审批人从哪来，卡在哪一步

流程配错的典型表现不是报错，是「提交成功但没人处理」。节点上配审批人时，来源有几种常见选法：指定成员、按角色、按主管层级、取表单里的某个人员字段。手册的报销流程案例用的是按主管层级，好处是组织架构调整后流程自动跟着走；设备报修这类更适合按角色或指定维修组，因为报修不认汇报关系。

条件分支也是同理。条件表达式里引用的字段 id 必须和表单严格一致，大小写和空格都算不同字段。我见过一次分支条件写了amount > 1000，但表单字段实际配的是必填文本，值进来是字符串"1200"，比较结果不符合预期，流程全部走了低额分支。数字类字段在表单层就定成数字类型，比在流程里做类型转换靠谱。

配完流程别急着发正式通知，先用测试账号走一遍最短路径：提交 → 审批通过 → 结束，确认每个节点的处理人都对得上。再走一遍驳回路径，确认驳回后能重新提交并且历史记录保留。这两条路径都通了，流程才算装好。

4. 进阶配置：权限、定时通知与系统集成

4.1 权限独立设置：角色、数据、字段三层要分开看

手册把「权限独立设置」列为产品特性，实际配置时它是三层东西，混在一起想就会乱。第一层是功能权限：谁能进这个应用、谁能新建表单、谁能看报表。第二层是数据权限：同一条报修单，提交人只能看自己的，维修组能看本组的，管理员能看全部。第三层是字段权限：一张报销单，财务能看金额和卡号，部门主管只看事由和金额，卡号那几列对他隐藏。

这三层的配置顺序是从外到内：先定谁能进，再定能看到哪些行，最后定能看到哪些列。反过来配，会出现「字段权限配好了但整个应用进不去」的无效劳动。数据权限里有个容易被忽略的细节——「本人」和「本部门」是两种不同的过滤条件，前者看提交人字段，后者看组织架构。组织架构调整频繁的公司，用「本人 + 指定角色」比用部门过滤稳定得多。

字段权限还有个好用的组合：敏感字段设成只读或隐藏，但保留在导出和接口返回里。这样前端界面上看不到，后台统计和下游系统仍然拿得到完整数据。前提是你要清楚哪些下游在用这个字段，别一不小心把关联的集成打断。

4.2 定时消息通知：时间、对象、模板三件事

手册里的「定时消息通知」案例看起来简单，配起来出问题最多。它本质是一个定时任务，由三个要素决定成败：什么时候跑、跑给谁、发什么内容。这三个要素任何一个配错，表现都是「到点了但没收到消息」，而且不会报错。

接收对象这一项最容易踩。用角色下发看着优雅，但角色里没配人时任务照跑，消息发给了零个人，日志上一切正常。我的做法是定时任务上线前，先在测试环境把接收对象临时改成自己，确认内容和时间都对，再切回角色。另外模板变量一定要用字段 id 而不是标签，标签是可以随时改的显示名。

4.3 集成打通：回调服务与主数据同步的写法

手册里讲 OA 改造那个案例时提到几种集成方式：接口查询、审批节点回调、主数据同步、定时同步、手动同步。落到实际代码，最常写的是节点提交时的回调处理。下面是一段处理骨架，重点在幂等和过滤，不在具体下游地址。

// 审批节点提交时的回调处理骨架，字段名按你的表单实际配置改 function onNodeSubmit(event) { // 1. 只在终审通过时往下游推，中间节点直接跳过 if (event.nodeName !== '财务终审' || event.result !== 'agree') { return { code: 200, msg: 'skip' }; } const { formData } = event; // 2. 组包，字段 id 必须和表单里配置的完全一致 const payload = { billNo: formData.billNo, amount: Number(formData.amount) || 0, // 兜底成 0，避免 NaN 进下游 applicant: formData.employeeName, submittedAt: new Date().toISOString() }; // 3. 用单据号做幂等键，回调重试不会重复入账 if (cache.has(payload.billNo)) { return { code: 200, msg: 'duplicated' }; } callDownstreamApi(payload); // 换成你自己的下游接口 cache.set(payload.billNo, 1, 24 * 60 * 60); // 覆盖回调重试窗口 return { code: 200, msg: 'ok' }; }

这段代码里有三处是血泪经验。第一处是节点过滤，只在终审节点推数据，否则中间每过一个节点就推一次，下游系统里同一张单会出现三四条记录。第二处是Number()兜底，表单里的金额如果配成文本，空值会变成NaN，序列化后下游解析直接失败。第三处是幂等键，回调机制在网络抖动时会重试，没有去重键就等于没有防护，重复付款这类事故都是这么来的。缓存过期时间设 24 小时，是为了覆盖回调的重试窗口，具体以平台的重试策略为准，宁可设长一点。

主数据同步是另一类活。手册里提到的做法是以人事系统为主数据源做单向同步，人员、岗位、组织架构按编码做唯一标识，存在则更新、不存在则新增。这个逻辑听起来简单，坑在于「删除」怎么处理——源系统里删掉的人，目标系统里是保留还是标记失效，必须提前定，否则会出现已离职人员还能收到审批消息。我一般会在同步任务里加一个软删字段，源端不存在时置为失效而不是物理删除，历史单据还能正常显示提交人。

4.4 什么时候别硬上零代码

手册列的优势都在讲适用面，反过来也得知道边界。表单字段超过一百个、需要复杂事务和多表强一致、对响应延迟有硬要求的场景，硬用零代码拼出来的东西维护成本会反超传统开发。判断标准不复杂：如果你发现自己开始用一堆联动和公式去模拟数据库约束，那就该停下来重新评估。零代码的强项是把两三周的开发压缩到一两个小时，不是把任何需求都压缩。

5. 避坑与排查：五条装完才发现的坑

5.1 账号与权限类：看不见的问题最难查

坑一：同事点开链接提示无权限访问。现象是你这边一切正常，对方打开同一个地址被拦在门外。原因通常是应用发布范围没包含他，或者他在组织里的角色没挂上对应应用的访问权限，还有一种情况是他登录的是另一个组织空间。解决顺序是先确认他登录的组织名称，再查应用的可访问范围，最后查角色。三步里最容易错的是第一步，两个组织名字很像时，对方自己也分不清。

坑二：拖拽好的表单在手机上错位。现象是 PC 端三列布局，手机上挤成一列，必填星号掉到下一行，或者按钮被挤出屏幕。原因是表单的栅格按 PC 宽度设计，小屏下没做自适应折叠。解决办法是在表单设计里按字段重要性重排顺序，把必填和关键字段放前面，宽字段设成全宽，再用真机确认一遍。模拟器看不出折叠屏和横屏的问题。

坑三：审批流程卡在某个节点不动。现象是流程实例停在「待处理」，但审批人说没收到。原因可能是审批人来源配成了某个角色而角色下没人，也可能是审批人就是提交人本人导致节点自动跳过，还可能是条件分支把这条数据路由到了一个不存在的路径。排查顺序是看流程实例的节点日志，确认当前节点和候选人，再对回配置。这类问题看日志比猜快十倍。

5.2 数据与集成类：跑得通不代表跑得对

坑四：定时消息通知到点没发。现象是过了设定时间，接收人一条消息没收到，任务记录显示执行成功。原因通常是数据范围筛出来是空集——条件里多写了一个「且」或者状态值写错，一条数据都没匹配上，任务照常执行但无内容可发。另一种是模板变量引用错了字段 id，内容渲染成空。解决办法是先在测试环境把接收对象改成自己，把数据范围放宽到全量，确认能收到，再逐步收紧条件。

坑五：集成同步后出现重复人员和脏数据。现象是主数据同步跑了几轮，同一批人多出好几条记录。原因是唯一标识没对齐——源系统用工号，目标系统按姓名匹配，同名就重。还有一种是没有幂等控制，定时任务重叠执行时同一批数据被处理两次。解决办法是把唯一标识统一成源系统的编码，同步逻辑改成「按编码存在则更新、不存在则新增」，同时给任务加执行锁，上一轮没跑完不允许下一轮启动。历史脏数据要单独写一次清洗，别指望同步任务自己修好。

6. 装完怎么验证：用「设备报修」走一遍完整闭环

环境装没装好，不看能不能拖出表单，看能不能让一条数据从头走到尾。我用来验收的场景固定是「设备报修」，因为它同时覆盖表单提交、流程流转、状态变更、消息通知、权限隔离五件事，比只做尺码收集更能暴露问题。验收按下面这张表逐项走，每项都要用不同的账号验，别拿管理员一个号从头点到尾。

跑这张表的时候有两个细节要盯。一是切换账号后先退出再登录，用同一个浏览器窗口直接切号，缓存里的会话可能让你误判权限。二是报表数字对不上的时候，先看报表的数据范围是不是带了「本人」过滤，管理员视角看到的是全量，普通用户看到的是他自己那部分，这不是 bug，是权限在起作用。

这套验收流程我后来固定成了习惯：任何新应用上线前，都拿「设备报修」这个模板走一遍完整闭环，参数换成实际业务的字段，流程照走。它花不了二十分钟，但能挡住绝大多数「看着能用、实际一碰就碎」的问题。手册里的六个实践案例，真正值得反复练的也就这一两个，剩下的等闭环跑顺了再挑着做。希望这套顺序能帮你少卡几个晚上。

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