简介：《0代码，搭应用——宜搭开发手册》PDF面向希望以低成本推进企业信息化的业务人员、管理者及低代码学习者，针对业务缺少系统支撑、流程与系统脱节、信息孤岛和开发运维成本高等问题，梳理宜搭这一零代码应用搭建平台的定位与能力。文件包仅含1个PDF，约22.76MB，篇幅覆盖宜搭简介、产品优势、客户案例、使用教程与搭建实践等模块。已有6790人学习，说明其在零代码入门与案例参考方面具有一定关注度。读者可从中了解通过拖拽配置页面、表单和流程快速构建应用的方法，并借助杭州市一医院内控升级、老板电器品质管理、居然之家OA改造、海纳威生产数字化等案例理解落地场景；教程部分从核心要素、快速入门延伸到进阶操作，T恤尺码收集、设备报修、企业进销存、报表分析、定时消息通知和企业报销流程等实践案例，则提供了较完整的应用搭建思路，便于对照学习和查漏补缺。
1. 0 代码搭应用是怎么回事：把写程序换成摆积木
同事在群里发来一张表格，让你统计部门三十个人的 T 恤尺码；你填完回传，他又合并了三个版本，最后谁也说不清哪份才是最新的。0 代码搭应用要解决的正是这类事：不写一行程序，靠拖拽控件、勾选配置，把一张表单、一条审批流、一张统计图拼成一个能真正跑起来的应用。它的名字取“适宜搭建、容易搭建”之意，核心是把开发从“写代码”换成“摆积木”——积木的形状和拼接顺序，才是需要动脑筋的地方。搞懂这件事，你就能明白为什么有的内部系统能在一小时内上线，有的却要排期三周。
2. 为什么会有 0 代码平台：被邮件和 Excel 拖住的那几年
企业里最常见的情况，并不是系统太多，而是该有系统的地方什么都没有。一张收集表靠邮件发，一份台账存在本地表格里，一次跨部门协作靠群里喊人。这些动作单看都不费劲，叠加起来却是一笔不小的隐形开销：数据反复录入、版本互相覆盖、进度只能靠问。0 代码平台并不是为了取代那些大型系统，它关注的是这些大型系统覆盖不到的环节。要理解它为什么出现，得先看清企业信息化到底卡在哪。
2.1 五个卡点，个个都很具体
原始资料把企业在信息化过程中遇到的问题归纳成五类，说成通俗的话就是：业务没有系统支撑，大量工作靠邮件和线下表格来收集数据、协调进度；系统里的流程和实际干活的流程对不上，想改一次要等很久；各系统之间不关联、不兼容，数据搬来搬去全靠手工；数据要么没有，要么质量差到没法用来做判断；开发和运维的成本一直降不下来。前三条是“用不上”，后两条是“用不起”。
把这几条串起来看，会发现一个共性：卡点几乎都不在技术难度上。真正难的是“谁来把需求翻译成系统”。业务人员最清楚流程怎么走，但他不会写代码；开发人员会写代码，但他得先花几天听懂业务，再花几周把听懂的东西实现出来。这个翻译环节一长，业务早就变了，系统刚上线就过时——做过内部系统的人，大概都有这种血泪经验。
提示：判断一个流程该不该上系统，先看它一个月内会不会重复三次以上。只跑一次的临时事项，用表格反而更快。
2.2 差旅报销：两三周和一小时差在哪
原始资料给了一个很直观的对照：同类的差旅报销应用，传统开发模式大约需要两到三周，用可视化配置的方式只要一小时。很多人的第一反应是“一小时做出来的肯定很简陋”，其实差距不在功能多少，而在流程长度。
传统开发要走的链条是：业务提需求、产品写文档、设计出原型、前端做页面、后端写接口、联调、测试、上线、后续运维。每一环都要排期，每一环都可能出现理解偏差，改一个字段的文案都要再走一遍发布。配置式搭建把这条链条压缩成一个人在一张画布上的连续动作——拖一个“金额”字段，设一条“大于 5000 走二级审批”的条件，选一下审批人，保存发布。中间那些“翻译”和“等待”被省掉了，省下来的时间并不是写代码变快了，而是不需要写了。
这也解释了为什么它在“变更”这件事上优势特别明显。业务流程最怕的其实不是上线慢，而是上线后改不动。配置式搭建把改动成本压得很低，业务调整时重新拼一遍就行，不用再走一次完整的开发周期。反过来，如果一个流程三年都不会变、并发量又极大，那手工配置未必比定制开发划算——这条边界后面还会细说。
2.3 换掉的不是工具，是干活的人
真正被改变的是“谁来做”这件事。过去业务提需求、技术来实现，中间隔着一层翻译；现在需求方自己就是搭建方，脑子里想的是什么，画布上摆的就是什么，翻译损耗直接归零。平台方给的定位很明确：把原本需要多人协同完成的工作，交给业务同学自主完成。
这个变化并不只是提效，它改变的是组织的反应速度。某大型企业集团在内部把这类平台孵化运行了两年多，承载的协同应用超过两千个，服务了集团三成以上的用户——能铺到这个量级，靠的不是技术团队加班，而是各业务线自己动手。某三甲医院用半个月完成内控管理升级，覆盖合同、预算、采购、审批、执行多个环节，横跨院办、设备、信息、总务、采购、财务等部门；某家电制造企业让零代码基础的品质部门人员自己搭应用，做关键物料质量控制、内部质量管理、供应商质量管理。这些场景的共同点是：需求方最懂细节，而细节恰恰是外部开发者最难问全的。
成本结构也跟着变了。平台以租赁方式按需付费，不用自己买服务器、不用维护机房，投入门槛从“先批一笔预算”降到“先用起来再说”。对那些预算有限、又急需把线下流程搬到线上的中小企业来说，这个门槛差异往往比功能差异更致命。
3. 三大核心能力：页面、规则、数据各管什么
任何一个企业应用拆到底，无非三层：长什么样、按什么规矩走、数据落在哪里。平台把这三层分别做成三块可配置的能力，也就是页面设计、业务规则定义、数据收集与分析。下面逐层拆开看，你会发现“0 代码”并不是不用懂技术，而是把技术细节换成了选择题。
3.1 页面设计：表单是拖出来的，不是写出来的
页面设计解决的是“人怎么把信息填进来”。可用的控件大致就是常见的那几种：单行文本、多行文本、数字、日期时间、单选、多选、下拉、附件、图片、人员选择、关联查询。拖到画布上，再改标题、改是否必填、改取值范围，一个字段就成型了。听起来平淡，但这一步恰恰是传统开发里最耗沟通的部分——字段叫什么名字、要不要必填、最多传几张图，全靠来回确认。
下面这段不是让你去写代码，而是让你看清“配置”到底在配什么。
// 一张"设备报修"表单的字段定义（示意写法，用来说明配置项在描述什么） const form = { name: "设备报修", fields: [ { key: "device_no", label: "设备编号", type: "text", required: true }, // key 即数据表字段名 { key: "fault_type", label: "故障类型", type: "select", options: ["电气", "机械", "其他"] }, { key: "level", label: "紧急程度", type: "radio", options: ["一般", "紧急"] }, { key: "photos", label: "现场照片", type: "image", max: 6 }, // 最多 6 张，防止附件过大 { key: "expect_at", label: "期望完成时间", type: "datetime" } ], layout: { columns: 2, mobile: "single" } // 桌面两列、手机单列，这就是"一次搭建双端适配" };几个参数值得解释：key是数据表里的字段名，一旦有人填了数据就别随便改，改了等于换了列；label是给人看的标题，随便改不影响数据；type决定控件形态，也决定后端怎么存；required、options、max是校验规则，它们决定了脏数据能不能进得来；layout管的是排布，桌面端两列、移动端单列，同一份配置在电脑和手机上都能正常看。
所有控件都在同一套画布上拼装，所以调整顺序和增删字段的成本极低。这也是为什么“一次搭建双端适配”这种特性很重要——如果还要为手机端单独做一版，前面省下的时间又还回去了。
3.2 业务规则与流程：审批链是配出来的
表单解决“填”，流程解决“走”。一条审批流的构成要素其实就那么几样：起点、若干审批节点、每个节点上由谁处理、节点之间的条件分支、超时后怎么办、办完通知谁。配流程的过程，就是把这些要素一个个填进去。
// 报销审批的流程骨架（示意），重点看 condition 和 approver 两类配置 const flow = { start: "员工提交", nodes: [ { name: "直属主管审批", approver: "发起人的直属上级", timeout: "24h", onTimeout: "提醒并升级" }, { name: "财务审核", approver: "角色：财务专员", condition: "amount > 5000" }, // 金额不超 5000 时跳过 { name: "总监审批", approver: "固定人员", condition: "amount > 20000" } ], end: { notify: ["发起人", "出纳"] } // 走完自动推消息，不用人去问进度 };approver常见有三种写法：固定某个人、发起人的上级这类关系型、某个角色或部门。用关系型和角色型的好处是人员变动时不用改流程，这也是权限独立设置的一部分价值。condition是条件分支，把“什么情况下多走一个节点”写成表达式，比在纸上画流程图省事得多。timeout和onTimeout是容易被忽略的一项，但在真实业务里恰恰最有用——审批卡住的时候，系统提醒一次比人催十次管用。
某家居零售企业的行政办公场景就是这么搭的：刻印公章申请、单位间盖章、公文发布、借用公章、借用营业执照，各自一条流程；再按使用视角分成集团、分店、分公司等几个入口页。这类流程单条都不复杂，但数量多、变动频繁，手工开发根本排不过来。
3.3 数据收集与分析：报表是攒出来的
这一层最容易被误解。很多人以为报表是“画”出来的，其实报表是“攒”出来的——表单每提交一次，就往数据表里落一行，字段就是你定义的key。攒够了数据，拖一个图表控件，选横轴选纵轴，折线柱状饼图就出来了。难点从来不在画图，而在数据本身够不够干净。
所以平台在数据侧的功夫，大多花在“能不能扛住”上：海量数据的高效存储与查询、租户隔离、分库分表、多引擎自动适配优化。这些词听着玄，翻译一下就是——不同企业的数据放在各自的“抽屉”里互不干扰；数据量大到一个库放不下时自动拆开存；查询时自动挑最合适的引擎执行。使用者完全不用感知这些，但一旦少了，几千条数据之后报表就会转圈转到你怀疑人生。
某箱包代工厂的做法很有代表性：生产线上布置了一千多台平板设备，通过摄像头和边缘服务器采集数据完成工序计件，数据落在系统里，自动算出每个工人一天的工作量，用来做产能平衡。这里面没有任何“写代码”的动作，靠的是表单、采集、报表三件事串起来。报表分析类应用的通用套路也一样：先用一张表单把口径定死，再让图表去读这份口径——口径不统一，图表做得再漂亮也是错的。
3.4 权限与消息：能不能真用起来的两道门槛
应用搭完能打开，不等于能用。真正决定它能不能活下来的，往往是两个不起眼的能力。
第一个是权限。同一张表单，车间主管只看本班组，财务只看金额字段，HR 只看人员信息——如果做不到字段级、部门级的独立授权，这个应用一上线就会被数据泄露的风险拦住。权限独立设置说的就是这件事：每个应用自己定谁能看、谁能改、谁能审，而不是全平台一套规则。
第二个是消息。流程走到谁那里、单据超时多久、报表什么时候出，都得有人被提醒。可定制的消息提醒推送可以按节点、按条件、按时间触发，比如某条流程卡了 24 小时自动催一次，或者每周一早上把上周的统计推给负责人。原始案例里那个“定时消息通知”的实践，就是专门讲这个的——很多人第一次搭应用时只想着表单好不好看，上线后才发现没人知道要来处理，最后还得在群里挨个 @。
4. 常见误区与易混概念：0 代码、低代码、无代码到底差在哪
这一章说几个初学者最容易混淆的地方。它们之所以值得单独拎出来，是因为搞混了不会立刻报错，而是会在半年后以“系统没人用”“数据全是脏的”“改一次全崩”的形式集中爆发。
4.1 误区一：0 代码等于不用懂业务
易混点：以为门槛低就等于没门槛，随便拖几个控件就是一个应用。
为什么会混：宣传语里“人人都会搭”太顺口，把“操作简单”误读成“不需要思考”。实际上一张表单最难的部分不是拖控件，而是想清楚这个字段到底要不要、这个口径到底怎么算、这个节点到底该谁审。控件是十分钟的事，想清楚是十天的事。
怎么区分：把“会不会用工具”和“会不会描述业务”分开看。工具门槛确实接近零，业务门槛一点没降。判断标准很简单——如果你不能用三句话说清这个流程的起点、终点和中间谁签字，那就还没到打开画布的时候。
4.2 误区二：0 代码什么都能搭
易混点：把零代码当万能，指望它替代核心业务系统。
为什么会混：它能搭的东西确实多——报名登记、调查问卷、财务管理、人力资源、行政管理、资产管理、客户管理、工作流转、任务审批，几乎覆盖了日常办公的所有缝隙。覆盖面一广，就容易产生“什么都能干”的错觉。
怎么区分：看三件事——并发量、算法复杂度、以及对既有系统的依赖深度。高并发交易、复杂计算、深度定制交互，这些都不是配置能解决的。它的定位是填缝隙，不是换地基。某家电制造企业的情况说得很明白：公司里 ERP、CRM、SRM、OA、PLM 各类大系统都在跑，系统与系统之间的业务覆盖不到，那才是零代码上场的地方。
4.3 误区三：低代码和 0 代码是一回事
易混点：两个词经常混着用，看着像营销话术的不同说法。
为什么会混：边界确实模糊，而且同一家厂商的不同产品线叫法还不一样。
怎么区分：看“要不要写代码”这条线。0 代码（零代码）原则上全程可视化，靠拖拽和配置完成；低代码则保留了写代码的出口，配置搞不定的部分可以补一段脚本或调用接口。落到实际选择上：业务人员自己维护的场景，优先 0 代码，因为写下的每一行代码都是未来没人能接手的债；需要和外部系统深度打通的场景，留一个代码出口反而更务实。
4.4 误区四：搭完上线就结束了
易混点：把“发布”当终点。
为什么会混：搭建过程太快了，一小时就能上线，心理上自然会觉得后面也没什么工作量。
怎么区分：上线才是开始。要盯的是三件事——数据质量（字段有没有人乱填）、流程通畅度（哪个节点经常卡住）、权限是否还准确（人走了权限还在不在）。这几件事没人管，三个月后系统就成黑匣子。所以“边使用边建设”这种说法才靠谱：先上一个能用的版本，用起来再改，而不是一次设计到完美。
4.5 误区五：有了平台就能消灭信息孤岛
易混点：以为把所有东西搬到一个平台上，数据自然就通了。
为什么会混：孤岛的成因看起来是“系统不关联、不兼容”，于是直觉上认为统一平台就能解决。
怎么区分：孤岛的根因是主数据不统一，不是系统数量多。人员信息以谁为准、组织架构从哪同步、单据编号由谁生成——这些不定义清楚，搬到同一个平台上照样是两套口径。某家居零售企业的做法值得参考：以人事系统为主数据，单向同步到搭建的应用里，靠接口查询、回调处理、定时任务、手动触发几种方式配合，才把数据一致性维持住。统一平台只是必要条件，不是充分条件。
5. 平台优势的边界：租赁、隔离、可靠性这些词在说什么
产品介绍里常出现一串听着很厉害但不太懂的词：按需付费、租户隔离、分库分表、同城双备、异地多活、数据可靠性 99.9999999%。这些不是形容词，每一个都对应一个具体的工程问题。搞懂它们在说什么，你就能判断哪些承诺跟你有关、哪些跟你无关。
5.1 租赁与免运维：成本从买服务器变成付租金
传统做一套内部系统，账面上是开发人力，账面下还有服务器、机房、带宽、备份、值班。小团队最怕的其实不是开发那一下，而是系统上线后没人管——服务器磁盘满了、证书过期了、半夜挂了没人知道。
租赁模式把这些打包成一项支出：按需付费，用多少付多少，服务器和机房不用自己维护。对预算有限的中小企业来说，这一步的意义是“不用先证明价值再拿钱”，而是“先用起来，用出价值再谈规模”。当然边界也在这儿：如果只是给五个人用一年，订阅费可能比一台旧服务器贵；如果流程变动频繁、又要覆盖多个部门，那这笔钱花得就值。
5.2 那串 99.9999999% 到底在说什么
数据可靠性 99.9999999% 意思是：存进去的数据，在一年时间里丢失的概率极低。这个数字对应的是多副本存储——同一份数据在物理上存好几份，坏掉一份还有别的顶上。注意它说的是“可靠性”，不是“可用性”，两者常被混为一谈。
可用性讲的是“服务能不能打开”，资料里给的是 99.9% 不中断，靠的是同城双备、异地多活——同城有一套备用环境随时接手，异地还有一套防止整片区域出问题。可靠性和可用性解决的是两件不同的事：一个是数据别丢，一个是服务别停。对内部审批这类场景，99.9% 其实够用；对生产线上的实时采集，才需要更严苛的可用性指标。
5.3 双端适配与权限隔离：看不见但天天在用的两件事
“一次搭建双端适配”听着像个技术参数，实际影响的是使用率。内部应用的大量使用场景在手机上——车间里、路上、会议间隙。如果只在电脑上能用，实际使用率会掉一大截。适配做在配置层，意味着你不用为两端各维护一套，改一处两边都变。
权限隔离则是另一种“看不见”。租户隔离说的是不同企业的数据在存储层就分开，不是靠查询条件过滤；权限独立设置说的是每个应用自己定规则。这两条在演示时完全体现不出来，但一旦要做正式系统，它们就是能不能过内部审核的门槛。
5.4 开放接口：给 0 代码留的后悔药
纯配置有个天然短板：一旦要跟外部系统说话，就卡住了。所以成熟的平台都会留出口——标准化接口、数据服务、回调服务。
- 数据服务：单据里需要展示人事信息时，实时查一下并回填，而不是把人员表再抄一份。
- 回调服务：审批节点提交时触发一段自定义处理，把结果推给外部系统。
- 主数据同步：人员、岗位、组织架构这类基础数据单向同步进来，以来源系统的编码为唯一标识，有则更新、无则新增。
- 定时与手动同步：按频率自动对齐，或者运维页面点一下立刻对齐。
这套机制的意义是：你可以先用配置把 80% 搭完，剩下 20% 靠接口缝上，不必因为一个对接需求就把整个应用推倒重写。某家居零售企业把报销、对外付款、资金下拨的审批结果同步到财务系统，自动记账、自动发起支付，走的就是这条路。留不留这个出口，是选平台时最该问清楚的一件事——它决定你半年后是继续加功能，还是被迫重来。
6. 什么时候该上配置式搭建，什么时候别上
把前面几章收束成一张判断表，遇到具体场景时挨条对一遍，比凭感觉决定靠谱得多。
| 场景特征 | 建议 | 原因 |
|---|---|---|
| 一个月重复三次以上的收集、登记、台账 | 直接搭 | 手工维护的隐性成本最高，越早搬上线越省 |
| 审批链条固定但节点多、涉及部门多 | 直接搭 | 配置流程比开发流程快一个数量级 |
| 需求三个月内还会变 | 直接搭 | 改配置的成本远低于改代码 |
| 需要与既有系统双向同步核心数据 | 先定主数据再搭 | 口径不统一，搭得越快错得越远 |
| 高并发交易、复杂计算、强交互界面 | 别用 | 配置解决不了性能和算法问题 |
| 只跑一次、以后不再有 | 别用 | 搭的时间和用表格差不多，还多一份维护负担 |
判断的时候，我习惯先问三个问题：这份数据一个月产生几次？这条流程三个月内会不会改？出问题的时候谁来维护？三个问题里有两个答不上来，就先别动手，回去把流程画在纸上。
举个具体的例子。某高校实验室要收实验耗材的领用申请：每周十几单，需要导师签、管理员签，季度要出一张按项目统计的表。判断过程是这样的——重复频率够（每周十几单）、流程短且固定（两个节点）、数据要汇总（季度统计），三条都指向“该搭”。真正动手时的顺序也不是先拖控件，而是先把三件事定下来：领用单上到底要几个字段、每个字段谁填、季度报表按哪个维度汇总。这三件事定完，画布上的活半小时就结束了。
反过来的例子同样常见。某团队想做一套实时设备监控大屏，要求每秒采集、秒级刷新、异常自动告警。这种需求一上来就撞在配置式搭建的短板上——高频写入、实时计算、复杂图表联动，都不是拖拽能解决的，硬上只会得到一个卡到不能看的面板。这种时候老老实实走定制开发，反而是省钱的。
还有一类容易被忽略的“别用”：只是为了把一份文件存起来。有人习惯把所有东西都建成应用，结果半年后平台里躺着几十个没人打开的表单，权限也没人清。从那以后我每次要新建一个应用，都强制先走一遍那三个问题，答不上来就先不建——这个习惯替我挡掉了至少一半的无用功。希望帮到你。
本文还有配套的精品资源，点击获取
