企业官网建设流程全解析

简介：《0代码，搭应用——宜搭开发手册》面向企业信息化负责人、业务人员及零基础开发者，针对业务缺少系统支撑、流程与系统脱节、信息孤岛、开发运维成本高等痛点，系统介绍阿里巴巴宜搭这一零代码应用搭建平台的能力边界与落地方法。全书从产品定位、核心优势与客户案例切入，结合杭州市一医院内控升级、老板电器品质管理、居然之家OA改造等场景，说明零代码在真实业务中的价值；教程部分覆盖核心要素、快速入门与进阶操作，并通过T恤尺码收集、设备报修、企业进销存、报表分析、定时消息通知、企业报销流程等实践，演示表单、流程与数据看板的搭建思路。资源包为1个PDF文件，约22.76MB，结构清晰，便于按章节查阅。目前已有6786人学习，适合希望以较低门槛推进企业应用搭建与数字化转型的读者参考。

1. 从一份收了一周的 T 恤尺码表说起：0 代码搭应用到底是什么

有个做行政的朋友跟我吐槽，说统计部门团建的 T 恤，微信群接龙发了三遍，收上来的 Excel 有五种格式：有人写 XL，有人写 X-L，还有人只填了身高体重让她自己猜。表交上去，还是有三个人尺码错了，重做一次又是一周。

这就是「0 代码搭应用」要解决的场景。宜搭是一套 0 代码的应用搭建平台，你不用写一行代码，靠拖拽和配置，就能把「发链接、填表、自动汇总、走审批」这一整套搬到线上。这份《0 代码，搭应用——宜搭开发手册》讲的就是这件事，从核心要素、快速入门，到六个实践案例，是给零基础的人准备的入门材料。

适合谁？天天被表格、接龙、审批单折磨，但一看见代码就头大的人。

2. 先看清路：0 代码和「写代码」到底差在哪一步

很多人第一次听到「0 代码」，第一反应是「听着像忽悠」。这个怀疑很正常，我当初也是这么想的——真有这么神，那还要开发岗干什么？

所以这一章不急着动手，先把两件事说清楚：它和传统开发到底差在哪里，以及你学会之后能搭出什么样的东西。路看清楚了，后面动手才不会觉得自己在瞎折腾。

2.1 同一个报销流程：一边 2 到 3 周，一边 1 小时

手册里有一句话特别能说明问题：以差旅报销流程为例，用传统开发模式完成同类的应用，大约需要 2 到 3 周，用宜搭配置只要 1 小时。

传统开发那 2 到 3 周，时间其实没花在写代码上。流程是这样的：业务部门提需求，产品经理整理成文档，开发排期，写完自测，提交测试，改 bug，上线，用两周发现不对，再改一轮。中间每一环都要开会、对齐、确认，真正敲键盘的时间可能只占一小部分，剩下全耗在「我想要的」和「你做出来的」之间的来回拉扯上。

0 代码把这条链路砍掉了大半。提需求的人自己上手拖拽，脑子里的表单长什么样，屏幕上就长什么样，改需求不用发邮件，当场拖两下就行。手册里有句话讲得挺到位：把原本开发过程中需要多人协同完成的工作，交给业务同学自主完成，大幅降低沟通成本，提升交付质量。

但这里必须给你泼一盆冷水，免得学完失望：0 代码不是万能的。它擅长的是「表单 + 流程 + 数据统计」这一类管理场景，遇到复杂算法、超高并发、需要深度定制的系统，该写代码还是得写代码。入门阶段你完全不用管这些，先把眼前那一亩三分地管明白就行。

2.2 企业信息化里那五个老问题，翻译成大白话就是身边的事

手册开篇列了企业在信息化过程中常遇到的五个问题，看起来像给老板看的报告，其实每一条你都在自己工位上见过。

业务无系统支持，说的是大量工作靠邮件和线下 Excel 收集数据、协调进度。翻译一下：你手上那份「最终版-最终版-真的最终版.xlsx」，就是这句话的活体标本。

与系统流程脱节，说的是系统里跑的流程跟实际工作流程对不上，不能全面准确地反映真实情况，而且系统改一次特别慢。翻译一下：系统里写着三步审批，实际工作中因为某位领导常年出差，真实流程变成了「先微信问一句」。系统越改越慢，大家越用越少，最后变成摆设。

信息孤岛，说的是各系统之间不关联、不兼容，数据来回切换效率低。翻译一下：员工入职，HR 系统录一遍，考勤系统录一遍，报销系统再录一遍，中间还有人漏录。重复录入这件事，几乎每个公司都有一批人在做。

智能化程度低，说的是没有数据，或者有数据但质量差。翻译一下：老板问「上个季度哪个环节最耗时」，你翻遍文件夹发现根本没记录，只能凭感觉编一个。

开发、运维成本高，这个最直白——养一个开发团队、租一批服务器、每年维护，对中小企业来说是笔不小的开销。

这五个问题摆在一起，你会发现它们其实指向同一个根源：想要系统，但做系统太贵太慢。宜搭这类平台切的就是这个中间地带——用租赁的方式、可视化的方式，把「做个系统」的成本压到普通人能承受的范围。手册里提到，这套平台在该厂商内部经过两年多孵化，承载了集团及近 40 家生态化公司的协同办公，基于平台搭建的有效应用超过 2000 个。这个量级说明它不是玩具，但也别因此觉得它跟你没关系——那 2000 个应用里，绝大多数都是很朴素的表单和审批。

2.3 学完你能搭出什么：9 类场景和一些真实的样子

先给你一个具体的能力预期。手册里列的应用场景包括：信息发布、知识管理、门户整合、数据管理、流程审批、移动办公。落到具体事情上，就是报名登记、调查问卷、财务管理、人力资源管理、行政管理、资产管理、客户管理、工作流转、任务审批。

你不用全部记住，抓住一条就行：凡是「有人填、有人批、最后要汇总」的事，它都能接。你回想一下自己一周的工作，符合这个描述的至少有四五件。

再说几个手册里的真实案例，我把公司名隐去了，你感受一下规模感就行：

某三甲医院用半个月做完了内控管理升级，覆盖经济合同管理、预算、采购、审批、执行，横跨院办、设备、信息、总务、采购中心、财务多个部门。以前审批靠线下纸质，没有统一标准，事后也不好查；搬到线上之后，合同信息电子化登记存档，审批流程线上走，还能做供应商管理和合同预警。半个月，对一套传统开发来说可能还在需求评审阶段。

某厨电制造企业拿它补「大系统之间的缝」。公司里 ERP、CRM、OA 这些大系统都有，但系统与系统之间覆盖不到的地方成了管理上的薄弱环节。用了之后，代码零基础的业务人员也能自己搭，做关键物料质量控制、内部质量管理、供应商质量管理——各片区检验员把当班检查情况填进表单，计划、生产和品质人员看图表就能发现质量波动。

某箱包代工厂的案例最能说明「自定义」的价值。它做生产执行系统，包含生产指令、生产派工、生产汇报、质检汇报、生产报表，覆盖 1000 多个生产工站、30 多个质检站点，让超过百人的管理人员实时在线协作，整体生产效率提升了 15%。这类企业的生产管理千行千面，买标准化软件总有一半不合身，自己组织开发又太贵，中间这条路刚好合适。

还有两个特性值得单独拎出来说。一是一次搭建双端适配，你在电脑上搭好，手机上就能直接用，不用再做一套 App。二是权限独立设置和定制消息提醒推送，谁能看、谁能改、什么时候提醒谁，都能单独配。这两点是后面几章动手时会反复用到的。

2.4 开始之前，你只需要准备三样东西

听到这里如果你有点心动，别急着打开电脑。先清点一下装备，其实就三样：

第一，一台能上网的电脑和一个浏览器，再加一部手机。手机不是可选项，因为双端适配这件事，你必须自己拿手机填一遍才知道效果。

第二，一个账号。手册最后有注册入口和沟通群的说明，按里面的路径注册就行，入门阶段用免费额度完全够折腾。

第三，也是最重要的一样：一个你自己的、小到不能再小的真实需求。不要想「我要搭一套公司管理系统」，那是三个月后的事。就想「我要收一次部门聚餐的口味选择」「我要统计一下办公用品的领用」，越小越好，小到你今天下午就能搭完。

手册的目录顺序其实已经给好了学习路径：核心要素、快速入门、进阶教程、实践案例。我的建议是按这个顺序走，别跳。很多人一上来翻到「企业进销存」那个案例，看完觉得太难就放弃了，其实前面的东西根本没打底。

我第一次学的时候也犯过这个毛病，直接照着最复杂的案例抄，抄到一半发现连「这个字段为什么要设成必填」都想不明白。退回去重新看核心要素那十几页，反而快得多。

3. 第一个应用开跑：30 分钟搭出「T 恤尺码收集」

准备工作做完，我们正式开始动手。这个例子的目标很朴素：把第 1 章里那个让行政朋友抓狂的 T 恤统计，变成一个点开链接就能填、填完自动汇总的小应用。

3.1 三个词先搞懂：表单、流程、数据

手册里说，平台集合了页面设计、业务规则定义、数据收集与分析三大核心能力。这三个词听着抽象，用生活化的说法翻译一下：

表单就是一张纸。你把要问的问题印在纸上，别人照着填。区别是线上的纸能规定「这格必须填」「这格只能选不能自己写」。

流程就是这张纸在几个人手里传。谁先填、填完给谁看、谁点头才算数、谁只是知情不用签字，这些都是流程要定义的事。

数据就是最后汇总出来的那张统计表。一百个人填完，你不用一张张翻，系统已经帮你算好了每个尺码各要几件。

绝大多数应用，都是这三样东西的组合。你现在要搭的这个 T 恤统计，只用到第一样和第三样，流程放到下一章再加。入门阶段一次只学一个东西，别贪多。

3.2 动手：把「T 恤尺码」拆成 5 个字段

搭表单之前，先拿张纸写清楚你要问什么。这一步在纸上花五分钟，能在后面省半小时。

拆字段有一个最基本的原则：一个字段只放一件事。「姓名和部门」不要合成一格，不然你以后想按部门统计，就得手工拆分字符串，那才是真的痛苦。

还有一个细节值得注意，尺码为什么用「单选」而不是「单行文本」？因为你那位行政朋友踩过的坑就在这儿——文本框什么都能填，XL、X-L、加大码、180 都行；单选只能从那几个选项里挑，从源头上就把数据口径统一了。能限制的地方一定限制住，这是搭应用最重要的一条经验。

3.3 五步把它搭出来

打开平台，跟着下面五步走：

第一步，新建应用。在应用列表里新建一个，名字就叫「团建 T 恤统计」。应用是容器，一个应用里可以放多个表单，以后这个部门的所有统计都可以往里塞。

第二步，新建普通表单，进入页面设计界面。你会看到三个区域：左边是控件区，中间是画布，右边是属性面板。整套操作就在这三块地方转。

第三步，把控件拖到画布上。从左边依次拖入单行文本、下拉单选、单选、数字、多行文本，顺序跟你纸上写的一致。拖完在画布上看起来就是一张竖着的表，跟纸质表格的观感差不多。

第四步，逐个点中控件，在右边的属性面板里改。要做三件事：把标题改成「姓名」「部门」这样的人话；把「必填」的开关打开；把选项填进去（部门填四个，尺码填五个）。数量那个控件顺手把默认值设成 1，大部分人只需要一件，省得他们再点一下。

第五步，保存，然后发布。发布之后系统会给你一个填写链接和一个二维码。到这一步，能填的表就已经存在了。

这里有个新手常犯的毛病：发布的时候图快，权限那一栏直接选了「所有人可见」。你现在搭的是内部统计表，先选指定范围，具体谁能填后面再调。这个坑我们在第 5 章还会专门讲。

3.4 拖拽背后长什么样：看懂这段结构，你就知道名字不能乱起

你在界面上拖来拖去，平台在背后其实是把每个字段记成了一条结构化数据。长这样：

{ "formName": "团建T恤统计", // 应用里显示的表单名 "fields": [ { "label": "姓名", // 用户看到的标题 "key": "employee_name", // 数据里真正的字段标识，建好别改 "type": "text", // 控件类型：单行文本 "required": true // 是否必填 }, { "label": "尺码", "key": "size", "type": "radio", // 控件类型：单选 "required": true, "options": ["S", "M", "L", "XL", "XXL"] // 选项写死在这里，改选项等于改数据口径 } ] }

这不是要你手写代码，只是让你看一眼「拖拽」这层皮下面是什么。看懂这五个键，你就明白了几件后面会救命的事：

label是给人看的，你随时可以改成「姓名」「名字」「员工姓名」，改了不影响任何数据，因为系统认的不是它。

key是给系统看的，是这条数据在库里真正的名字。报表按哪个字段分组、流程按哪个字段判断、接口按哪个字段取数，全靠它。一旦有了真实数据，key 就绝对不能再改，改完之后老数据在新结构里找不到对应位置，报表会变成一片空白。这是新手最容易吃的一次哑巴亏，症状诡异，排查起来像玄学。

type决定这个字段能存什么样的值。文本改数字、单选改多选，都可能让历史数据读不出来。想改类型，最稳的办法是新建一个字段，把老数据导出来重新灌一遍。

required和options属于「规则」，改起来相对安全，但也要想清楚。比如你把尺码里的 XXL 删了，之前填过 XXL 的人，数据还在，只是选项里再也显示不出来。

3.5 发布之后：让数据自己汇总

链接发出去，同事在手机上点开就能填，这就是「一次搭建双端适配」的意思——你只在电脑上搭了一次，手机端是自动适配的，不用另外做。

填进来的数据去哪儿看？表单后面有一个数据管理页，所有提交记录都躺在里面，可以按条件筛选，也可以导成表格。这时候你打开那个页面，会第一次感受到那种「不用再催人交表」的轻松。

再往前走一步：在应用里建一个简单的图表，横轴选「尺码」，纵轴选「记录数」，一个按尺码分组的统计图就出来了。这就是手册里「报表分析」实践案例的最小版本，原理完全一样，只是那个案例的维度和指标更复杂一些。

发布之前，一定自己先填三条测试数据。三条就够，但它能帮你发现一堆问题：选项是不是漏了、必填是不是设错了、手机上排版是不是挤在一起。这个习惯看起来笨，能省掉你在群里被二十个人追问的尴尬。

4. 让表单会走路：加一道审批，把「填表」变成「流程」

上一章的应用是「只收不批」，填完就完事。但真实工作里，大部分事情填完之后还得有人点头：报销要批、请假要批、设备坏了要报修、报修完要有人接单。

这一章我们换个场景，做「设备报修」，把流程这条腿接上。

4.1 流程到底是什么：一张报修单要经过几双手

用最土的话说，流程就是回答四个问题：谁提交、谁审批、谁执行、办完通知谁。

对应到平台里的词，是这么几个：

节点，流程上的一个环节。一个节点就是一次「交到某人手上」。

审批人，这个环节谁说了算。可以指定具体的人，也可以按「部门主管」这种关系去取，后者更省事——人员调动的时候你不用挨个改流程。

条件，什么情况下走哪条路。比如加急的报修跳过主管，直接到维修组。

抄送，通知谁，但不需要他点头。这个功能特别容易被滥用，后面第 5 章会讲。

设计流程最容易犯的错，是一上来就在设计器里连线。我的建议是先在纸上画：拿一张 A4 纸，从左上角画个圈写「申请人提交」，箭头指向下一个圈写「主管审批」，再指向「维修组处理」，最后指向「完成」。画完你自己念一遍，念得通再动手配。在纸上改一版三十秒，在设计器里改一版半小时。

4.2 动手：给「设备报修」加四步

先把表单做出来，字段包括：设备编号（单行文本，必填）、故障描述（多行文本，必填）、紧急程度（单选：一般、紧急，必填）、现场照片（图片上传，选填）、报修人（成员控件，自动带出当前用户）。

然后在表单的设置里打开流程设计，按下面这张表连线：

配置的时候有三件事必须逐节点确认，漏一件流程就会瘸：

一是表单字段权限。同一个表单，在不同节点上，不同的人能看到的字段是不一样的。发起节点所有字段可填；审批节点主管只能看不能改（改了就成了他替报修人写故障描述，责任分不清）；处理节点维修组能填「维修记录」，但改不了「故障描述」。这个设置在节点属性里逐项勾选，别嫌麻烦。

二是审批人的取法。能选「部门主管」就不要选具体某个人。选具体的人，等他离职或者调岗，这条流程就断了，而且断的时候往往没人知道，单子就那么卡在那儿。

三是驳回之后往哪走。默认通常是退回发起人重填，也可以配置成退回上一节点。想清楚你要哪种，不然会出现「主管驳回，单子直接消失」的错觉。

4.3 条件分支：加急的单子跳过主管直接到维修组

设备炸了还在等主管点同意，这事儿说不过去。所以我们要加一条条件分支。

在「发起」节点后面拉出两条线：一条条件写「紧急程度 等于 紧急」，直连「处理」节点；另一条作为默认路径，走「审批」节点。

配条件的时候有两个高频翻车点，先说在前面：

大于和大于等于别搞混。这在金额类审批里是重灾区，比如「金额大于 500 找经理」，那 500 块整到底找不找？你自己得先想清楚，配完拿 500、500.01、499.99 三个数各测一遍，别信自己的眼睛。

条件之间会不会打架。如果两条线的条件同时成立，系统只能走一条，走哪条取决于优先级，这时候出来的结果经常出人意料。稳妥的做法是让条件互斥，实在互斥不了，就把默认路径留好，保证任何情况都有路可走。

4.4 消息提醒和权限：流程走了，得有人知道

流程配完，最容易忽略的是「通知」。单子到了某人手上，如果他不打开系统，就等于没到。手册里提到的「定制消息提醒推送」就是解决这个的：待办到达提醒、超时未处理提醒、流程结束通知，都能单独配。

我的建议是至少配两条：待办到达时提醒一次，超过 24 小时没处理再催一次。再多的提醒就是骚扰，人会自动忽略，反而把真正紧急的那条埋了。

权限这块，宜搭支持权限独立设置，粒度可以细到「谁能看这个应用」「谁能填这张表」「谁能看全部数据还是只能看自己提交的」。设备报修这个场景，普通员工只能看自己报的单，维修组能看全部，主管能看本部门。这些都在应用和表单的权限设置里分开配，不要图省事一刀切。

手册里那个家居零售企业的案例，把这件事做到了另一个层次：他们通过平台开放的接口能力，把审批流程和财务系统、支付系统打通，日常报销、对外付款、资金上交下拨，手机上点一点审批，后续记账、付款数据自动生成。这就是「流程」真正的价值——它不是让人多点几下，而是让数据在系统之间自己流动，把人从重复录入里解放出来。

你现在还用不上接口，但心里要有这张图：表单是入口，流程是骨架，数据是血液。三者接上，一个应用才算活。

5. 新手避坑：5 个让应用返工的翻车现场

前面三章讲的是怎么搭，这一章讲怎么别搭废。下面这五个坑，是我见过出现频率最高的，每一个都能让你推倒重来。

5.1 坑一：一上手就想搭「企业进销存」

现象：打开手册翻到实践案例，看到「企业进销存」「企业报销流程」觉得这才叫应用，于是新建一个空应用开始往里塞。搭到第三天，字段建了四十多个，流程连了七八个节点，自己都记不清哪个字段是干嘛的，然后放弃。

原因：把学习项目当成了生产项目。进销存这类案例是给已经熟悉平台的人看的，它默认你已经懂了表单、流程、权限、报表这些东西，直接展示「组合起来能做成什么样」。你连单个零件都没摸过，直接装配整机，卡住是必然的。

解决：给自己定一条硬规矩——前三个应用，每个字段不超过 8 个，每个流程不超过 4 个节点。T 恤统计、办公用品领用、会议室预约，这类小东西搭三个，你对平台的手感就有了。手册里的复杂案例留到第 6 章再回头啃，那时候你看它会完全不一样。

5.2 坑二：字段名随手写「文本1」「单选2」

现象：搭的时候图快，控件拖上去不改名，一路「文本1」「文本2」「单选1」。三个月后要做报表，打开字段列表一看，二十个字段全是这种名字，没人记得哪个是尺码、哪个是部门。想改吧，又怕改了把流程弄坏。

原因：只顾着「能填就行」，没想过数据后面还要被用。字段名不只是给人看的标题，它背后还有一个key在撑着所有引用关系。标题可以改，key改不了，而很多人在建的时候连标题都懒得改。

解决：建表那一刻就把三件事一次做对——标题写成人话（「报修人部门」而不是「部门1」）；key用英文加下划线，语义清楚（repair_dept）；建完立刻在纸上或者文档里记一行「字段名 / key / 谁填 / 给谁看」。这份一页纸的清单，就是你以后的后悔药。我见过太多项目，最后不是死于功能不够，是死于没人说得清数据是什么意思。

5.3 坑三：流程改一版，在途的单子全乱了

现象：上线一周，发现审批顺序不对，顺手在设计器里调整了一下节点顺序。改完发现，正在审批中的二十几单，有的卡在原地不动，有的从头开始走，还有的审批人变成了空白。

原因：没搞清楚「流程定义」和「流程实例」的关系。你改的是模板，但在途的单子是按老模板跑起来的实例，模板一动，实例的参照系就变了。这不是平台的问题，是所有流程系统共有的特性。

解决：三条纪律。第一，大改之前先清空在途，把手上跑着的单子处理完再动刀。第二，先在一个测试应用里改一遍、跑一遍，确认没问题再动正式的。第三，改完自己立刻提交一单走完全程，别等别人来告诉你坏了。如果实在要在在途状态下改，优先「新增节点」而不是「删除或调换节点」，新增对老实例的冲击最小。

5.4 坑四：权限没设，全公司都能看见不该看的

现象：工资核算表、供应商报价单、员工绩效评分，这些明显敏感的表，某天被别的部门同事随口提了一句「我昨天点进去看到了」。

原因：发布的时候图省事，权限选了最宽的那一档；或者压根没意识到还有权限这一栏，以为发出去就是给指定的人。

解决：发布前走一遍四问清单——谁能看到这个应用？谁能填这张表？谁能看全部数据，谁只能看自己提交的？谁能导出？四问里任何一问答不上来，就别点发布。另外养成一个习惯：每建一个新表单，默认先把权限收到最紧，然后按需要往外放，而不是反过来。收紧了最多是多配一次，放开了可能就是一次事故。

5.5 坑五：以为 0 代码就不用测试

现象：链接发到群里，第一天收到二十条私信：「提交不了」「选项里没有我们部门」「手机上按钮点不动」。

原因：只在自己电脑的浏览器上试过一次，而且只填了「正确」的数据。手机没试、别人的账号没试、错误输入没试。0 代码降低了搭建门槛，但没降低「东西会被真实的人用」这件事的复杂度。

解决：发布前跑三条测试线。换设备：拿手机填一遍，看看排版、看看上传照片顺不顺。换身份：找个同事的账号登进去看，他看到的界面和权限，跟你看到的大概率不一样。故意填错：必填项空着提交、数字框里填字母、选项全试一遍，看系统会不会给出人话的提示。三条线跑完，通常十分钟，能挡掉八成的上线事故。

6. 下一步学什么：从会搭一张表到能搭一套系统

搭完 T 恤统计和设备报修，你已经跨过了最难的那道坎——知道了表单、流程、数据这三样东西怎么咬合在一起。接下来的路，我按周给你排一下，都是业余时间能完成的量。

这个顺序不是我拍的，手册的目录本身就是这么排的：核心要素打底，快速入门跑通，进阶教程补能力，实践案例练组合。唯一的调整是我把两个中等难度的案例提前了，因为报表和提醒这两个能力，在你做第二个应用的时候就会用到，早点会早点舒服。

再给你一个具体的小技巧，比学任何功能都值钱：每搭一个应用，写一份一页纸的「字段说明」。左边一列写字段名，中间写 key，右边写「谁填、给谁看、能不能改」。搭的时候写，改的时候更新。听起来像形式主义，但当你手上有了七八个应用、上百个字段之后，这份纸就是你唯一能搞清楚状况的东西。

最后说个我自己的教训。早年我搭第一个正式给人用的应用，自信满满地发到群里，结果当天下午被叫去救火——手机上图片上传按钮被挡住了，十几个人卡在这一步，有人在群里说「这系统是不是坏了」。其实功能一点没坏，就是我没在手机上试过。从那以后我每搭一个应用，都强制自己先用手机填一遍、再借别人的账号看一遍，两遍都过了才敢把链接发出去。这个习惯救过我很多次。

手册和案例都在那份 PDF 里，注册入口和沟通群的信息也在最后几页。挑一个你今天就想解决的小事，打开它，从第一个字段开始拖。希望帮到你。

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