简介《0 代码搭应用——宜搭开发手册》PDF面向希望以低门槛方式推进企业信息化的业务人员、管理者与开发者围绕业务无系统支持、流程脱节、信息孤岛及开发运维成本高等问题系统介绍阿里巴巴宜搭平台的零代码搭建思路。压缩包内共1个PDF文件大小22.76MB内容结构完整便于集中阅读与检索。手册从宜搭简介、产品优势与客户案例切入收录杭州市一医院、老板电器、居然之家、海纳威等实践并给出核心要素、快速入门与进阶教程后半部分以“T恤尺码收集”“设备报修”“企业进销存”“报表分析”“定时消息通知”“企业报销流程”等案例展开帮助读者理解页面、表单、流程与数据分析的配置方法。该资源已有6793人学习适合作为业务人员自主搭建应用、团队评估零代码平台及开发人员快速了解宜搭能力边界的参考手册。1. 从一张 Excel 到一小时内上线这份手册真正解决的是什么0 代码搭应用这件事最容易让人低估的是“配置”两个字的深度。这份《0代码搭应用——宜搭开发手册》我前后翻了三遍第一遍当产品介绍看第二遍照着六个实践案例抄第三遍才看懂它真正的价值——它把“一个业务问题怎么拆成表单字段、审批节点和数据视图”这个完整过程摊开给你看了。它适合三类人被 Excel 和邮件追着跑的业务负责人、手里有零散系统要打通的信息化岗位、想快速验证内部工具的产品同学。不适合指望它替代后端开发的人手册里对接口和集成的描述只到方案层字段映射的细节还得自己补。2. 拆开宜搭的三层结构页面、表单、流程先跟业务对上拿到这类手册多数人的第一反应是从“快速入门”那一节开始往下翻翻到“进阶教程”就开始走神。我建议反过来先把手册开篇那几页讲的三大核心能力页面设计、业务规则定义、数据收集与分析翻译成自己能对上号的业务概念再去动案例。这三层如果一开始没对齐后面每个案例你都会搭出一个“能跑但没法维护”的东西。2.1 三大核心能力对应到具体配置位置手册把平台能力归成三块落到实际界面里其实是四个东西多出来的那一块是流程。很多人把“业务规则定义”直接等同于流程设计器结果搭到一半发现校验逻辑没地方放只能塞进行程审批的备注里最后没人看。手册里的说法实际配置在哪负责什么什么时候必须单独处理页面设计表单页面、自定义页面数据录入界面和展示界面录入字段超过 15 个就要拆分组否则手机上没法填业务规则定义表单校验、数据联动、公式、业务规则字段之间互相约束、自动带值、条件显隐只要出现“A 填了才显示 B”就必须在这里做流程流程设计器审批流转、节点权限、抄送只要涉及多角色交接表单里做不了数据收集与分析数据管理页、报表页面查询、筛选、统计、导出数据量起来后不建索引字段查询会明显变慢这张表看着简单但我见过不止一个人把“数据联动”写在流程的节点提交后事件里结果就是数据只在流转时更新业务同学在列表页改了字段联动值不跟着变对账时一对一个不吭声。联动的归联动流转的归流转这个边界一开始就要划清。2.2 用「设备报修」反推字段清单的四步法手册里的设备报修案例在第 75 页附近篇幅不长但它是全书里最适合拿来练手的一个——数据模型只有一个主表流程只有三个节点正好用来把方法论跑通。我一般按这四步走顺序不能换。第一步先把线下动作列成动词短语不要上来就想字段。设备报修这件事的动作是报修人描述故障、班组长判断是否外修、维修工接单、维修工填结果、报修人确认验收。五个动作对应五个信息产生点。第二步每个动作只问一句“这一步需要谁填什么”。报修环节需要设备编号、故障现象、紧急程度、现场照片判断环节需要处理方式自修/外修和判断意见接单环节需要接单人、接单时间维修环节需要维修措施、更换配件、耗时验收环节需要验收结论和满意度。第三步把同类信息合并成字段并定类型这一步最容易翻车业务含义字段类型选择不要用的类型原因设备编号关联表单关联设备台账单行文本手填必然出现编号错字后续统计全废故障现象多行文本单行文本单行文本在移动端只能看半行维修工要反复点开紧急程度单选一般/紧急/停机数字数字要靠人记 1/2/3 的含义新人必填错现场照片图片限 3 张附件附件要下载才能看审批人不会下载维修耗时数字单位小时保留一位小数单行文本文本没法求和报表做不出来第四步把字段按“谁填”分组表单里做成三个分组标题移动端一屏一组。这一步手册没明说但六个案例的表单页面全是这么分组的你照着看就能发现规律。提示字段命名尽量不带“是否”“状态”以外的前缀报表里字段名会直接变成列名名字太长列会被挤成一坨。这个细节在搭建阶段完全无感等做报表的时候才开始后悔。2.3 什么情况下该把表单和流程拆成两个应用手册里的“企业报销流程”案例用了流程表单“T 恤尺码收集”用了普通表单这两者的区别不是有没有审批而是数据生命周期。普通表单的数据是“收集完就固化”的尺码收完基本不再变流程表单的数据是“随流转演进”的每一笔报销在审批过程中状态一直在变。判断标准很实际如果一份数据在提交之后还会被反复修改状态并且不同状态对应不同的人有不同权限那就用流程表单。如果数据提交后基本不动只是需要汇总统计用普通表单加一个数据管理页就够硬套流程只会让发起人每次提交都要多点两下。还有一种情况是手册里没写、但实际项目中很常见的一个业务既需要收集又需要审批而且收集端和审批端的使用者完全不是一批人。比如访客登记前台收集行政审批。这种我会拆成两个应用收集端用普通表单通过关联把数据推给审批端而不是硬塞进一个流程表单里——一个流程表单挂两套权限后面加字段时权限会乱成一锅粥。3. 六个实践案例的复现顺序从 T 恤尺码收集到企业进销存手册从第 45 页开始给了六个案例目录顺序是T 恤尺码收集、设备报修、企业进销存、报表分析、定时消息通知、企业报销流程。这个顺序是按业务场景的行业分布排的不是按学习曲线排的。照着目录做你会在第三个案例上卡住——进销存涉及主表、子表、关联表单、库存联动复杂度是前两个案例的三倍以上。3.1 按数据模型复杂度重排而不是按页码我推荐的实际复现顺序是T 恤尺码收集 → 设备报修 → 企业报销流程 → 定时消息通知 → 报表分析 → 企业进销存。理由很直接前两个练字段和页面第三个练流程节点和条件分支第四个练时间触发和数据筛选第五个练聚合和图表最后一个才把所有东西揉在一起。定时消息通知和报表分析之所以提到前面是因为它们都可以挂在前三个案例的数据上做不需要新建业务模型属于“低成本高回报”的两个练习早点做能早点建立正反馈。这里有个血泪经验千万不要一上手就做进销存。进销存的难点不在表单而在库存这个数字到底该存在哪。手册里给的思路是入库、出库各建一张子表单库存由报表汇总算出。这个思路没问题但如果你没先做过报表分析那个案例你不知道汇总字段能不能跨表单取数、能不能做条件过滤就会在库存表上耗掉一整天。3.2 前两个案例的最小字段集照着抄就行T 恤尺码收集这个案例看着像玩具但它把“一人一记录 汇总统计”这个最基础的模式讲透了。最小字段集只有六个姓名成员字段不要用文本、部门部门字段、尺码单选 S/M/L/XL/XXL、数量数字默认 1、收货地址地址字段、备注多行文本非必填。这里有两个细节值得说。姓名用成员字段而不是单行文本是因为成员字段能自动带出部门和账号后面按部门统计的时候不用再做一次人工匹配。尺码用单选而不是下拉是因为手机上单选是平铺的一眼能看全五个选项下拉要点开才知道有什么。手册里这两个案例都用的单选不是随手选的。设备报修在前面 2.2 节已经拆过了补一个容易漏的设备台账这个关联源表单要在报修表单之前建好并且至少要填三条测试数据否则你在报修表单里配关联的时候会发现下拉是空的以为是配置错了其实是源表没数据。这个坑我踩过排查了二十分钟。3.3 进销存案例关联表单和子表单怎么分工进销存是六个案例里唯一需要认真设计数据结构的。手册给的结构是商品主数据、入库单、出库单三张表入库单和出库单里各挂一个商品明细子表单。这个结构的关键在于商品编码只存在商品主数据里入库出库只存引用。表主表字段子表单字段关联关系商品主数据商品编码、名称、规格、单位、安全库存无被下面两张表引用入库单入库单号流水号、供应商、入库日期、经办人商品关联、数量、单价、金额公式明细行关联商品主数据出库单出库单号、领用部门、出库日期、用途商品关联、数量、领用说明明细行关联商品主数据子表单里的金额用公式算不要让填单人填。数量乘单价这种计算交给公式人一忙就会填错而且填错了在子表单里极难核对——子表单是横向滚动的你得一行一行对。公式写对了这一整类错误直接消失。还有一个坑安全库存预警。手册里是用报表做条件过滤实现的筛选条件是“当前库存 安全库存”。这里“当前库存”必须是聚合值不能用入库减出库两个字段直接相减因为子表单的行数是动态的字段级公式算不了跨行求和。正确做法是在报表里对出库数量做求和、对入库数量做求和两个聚合值相减再跟安全库存比。这个逻辑想清楚了库存这块就通了想不清楚你会一直在表单里加字段试图硬算。3.4 报表分析案例要挂在自己的数据上别用示例数据手册的报表案例用的是平台自带的演示数据看完会觉得“哦就这样”然后关掉。正确做法是把它挂在你前面做的设备报修或报销数据上至少录二十条真实结构的测试数据再去做图表。二十条是个经验值。低于这个数柱状图和折线图画出来都是几根孤零零的柱子你判断不出分组维度选得对不对、时间粒度是不是太细。我一般会造三十条覆盖三个部门、两个月、四种状态这样才能验证“按部门按月看状态分布”这种三层嵌套的图表配置是否成立。4. 流程、权限与消息参数级的配置清单到这一层能跑通的人不少能配对的很少。手册在这部分的描述偏概念把“权限独立设置”“定制消息提醒推送”当成产品优势一笔带过但真正决定一个应用能不能交出去用的恰恰是这几个参数。4.1 审批节点的处理人设置怎么选处理人设置是流程里最容易配错的一项配错了不会报错只会静默地把单子发给不该发的人。常见的几种设置和适用场景处理人类型适用场景风险点指定成员固定岗位、人员不常变人一调岗所有历史流程的待办都挂在他名下指定角色岗位有备份人角色里加了人但没通知会出现“多出来的审批人”部门主管逐级审批组织架构没维护父子关系时主管字段是空的单子直接卡死表单内的成员字段由发起人指定审批人发起人可以随手填自己等于没有审批发起人本人补充说明节点只能用在非审批节点用在审批上等于自审自批实际项目里我会尽量避免“指定成员”改用角色。代价是前期要维护角色成员收益是人员变动时不用改流程。手册里那几个企业案例讲的都是组织架构频繁变动的场景背后其实就是这个取舍。会签和或签的选择也值得说一句。会签是所有人都要通过或签是任意一人通过即可。财务、法务这类需要留痕的节点用会签日常行政类审批用或签。配成会签但只加了一个人跟或签没区别但审批记录里会显示“1/1”看起来像走了集体决策这种自欺欺人的配置我见过不少。4.2 条件分支的优先级顺序决定漏单率条件分支的坑在于它是按顺序匹配的命中第一条就不再往下走。所以分支的排列顺序不是随意的要从最严格的条件排到最宽松的条件。举个报销的例子金额大于 5000 且含招待费 → 走总经理金额大于 5000 → 走财务总监金额小于等于 5000 → 走部门主管。这三条如果顺序反过来先放“金额小于等于 5000”看起来没问题但如果第一条写成“含招待费”而不带金额条件所有带招待费的小额报销都会被推到总经理那里你会发现总经理的待办列表莫名其妙多了一堆几十块的单子。我一般的做法是给每个分支写一句“这条分支在什么情况下会命中”的注释写在分支名里比如“分支A-大额且招待”。分支名短一点没关系关键是自己三个月后回来看还能看懂。手册里的报销案例分支不多但你只要在它基础上加一条“跨部门”的条件顺序问题立刻就会暴露。4.3 权限是三个独立的开关不是一套这是全书里最需要自己补的一块。宜搭的权限至少分三层应用权限谁能进这个应用、页面权限谁能看这个页面、数据权限谁能看哪些数据。三层是相乘的关系不是覆盖的关系。权限层常见配置配错的典型后果应用权限按部门或角色开放应用发布后外部人员也能搜到入口页面权限表单页、数据管理页、报表页分别设置报表页没设权限普通员工能看到全公司数据数据权限本人 / 本部门 / 本部门及下级 / 全部配成“全部”但本意是“本部门”跨部门数据全暴露字段权限单字段的可见、可编辑审批人能看到薪资字段但本不该看数据权限这一层最容易被忽略因为它的默认值往往是“全部”而人在搭完功能之后通常只测“能不能提交”不测“别人能不能看到”。我现在的习惯是应用发布前一定用一个非管理员的测试账号登录一遍从入口点进去逐个页面看有没有不该看的东西。这个动作五分钟能挡掉后面 90% 的返工。字段权限在流程里更微妙。同一个表单发起人能看到全部字段审批人只应该看到跟判断相关的字段。比如采购申请里的供应商报价部门主管要看但后面的财务节点不一定需要。这种按节点控制字段可见性的配置手册里没展开但在流程设计器的节点设置里是有的值得单独花半小时摸一遍。4.4 定时消息通知的时间参数定时通知这个案例看着简单本质是“在什么时间、按什么条件、给谁发什么”。三个参数里最容易错的是时间。时间配置一般有两种思路固定时间点触发比如每天早上九点和相对时间触发比如截止日期前一天。固定时间点适合日报周报类相对时间适合提醒类。相对时间配置时要特别注意“提前量”的边界如果记录本身的日期就在今天提前一天的通知会立刻触发用户在提交完的下一秒就收到提醒观感很差。条件筛选是第二个坑。通知一般只发给“还没处理”的记录所以筛选条件里必须带上状态字段比如“状态 ! 已完成”。漏了这个条件你会收到已经办完的事又被提醒一遍用户的第一反应是这系统不靠谱。给谁发这块能按角色发就别按人发理由跟 4.1 一样。5. 避坑与排查五处最容易翻车的地方5.1 关联表单下拉为空现象在报修表单里配置了关联设备台账预览时下拉列表是空的但源表单里明明有数据。原因关联表单有过滤条件默认会按某个字段做匹配如果主表和源表之间没有能对上的字段或者过滤条件被设置成了“当前表单某字段等于源表某字段”而那个字段还是空的结果就是空列表。解决先去掉所有过滤条件确认能拉到全量数据再一条条加回过滤条件。另外确认源表单的数据状态是“已发布”而不是草稿草稿数据不会出现在关联里。5.2 移动端和 PC 端显示不一致现象PC 上排版整齐的表单在手机上字段挤在一起图片看不到按钮被遮住。原因手册强调的“一次搭建双端适配”是布局层面的自适应不是内容层面的自动精简。字段太多、分组太粗在窄屏上必然挤。解决每个分组控制在 6 到 8 个字段以内长文本字段在移动端会占据大量纵向空间非必填的长文本考虑收起。图片字段限制数量三张以内。发布前一定用手机实际打开一次不要只看 PC 预览。5.3 公式计算结果跟手算对不上现象子表单里的金额合计跟把明细行手工相加的结果差几分钱。原因多半是小数位处理不一致。数字字段如果设置了保留两位小数展示时是四舍五入的但参与计算的是原始值。逐行四舍五入后求和跟先求和再四舍五入结果会差。解决统一在公式里先做四舍五入再求和或者干脆所有金额字段都不做展示层的四舍五入只在最终展示时格式化。这个规则要在建表阶段就定下来中途改会导致历史数据全部重算。5.4 流程卡在某个节点不动现象单据提交后一直停在某个审批节点处理人说自己没收到待办。原因处理人配置成了“部门主管”但提交人的部门在组织架构里没有配置主管字段系统找不到人流程静默挂起。解决流程设计器里对每个节点做一次“模拟提交”用不同部门的账号各跑一遍。组织架构里主管字段为空这件事从界面上完全看不出来只能靠跑流程暴露。这类问题一旦上线才发现用户会认为系统坏了。5.5 报表数据跟列表数据对不上现象数据管理页显示有 120 条记录报表里统计出来只有 98 条。原因报表的数据集默认带了过滤条件比如只统计已完成的单据或者只统计当前用户有权限看的数据。列表页的权限和报表的权限是分开配的经常不一致。解决做报表前先去数据集里看清楚默认过滤条件是什么把“统计口径”写在报表标题下面的说明文字里。这是给后面接手的人留的后路也是给自己三个月后回来看留的后路。6. 从搭完到验收三个指标和一份五分钟自检搭完一个应用不等于能交付。我现在的验收标准是三个数字首次提交完成率、平均流转时长、字段空值率。首次提交完成率是指发起人打开表单到成功提交的比例这个数字低于 80% 说明表单太长或者必填项设计有问题。测法很简单找三个没参与搭建的同事让他们各填一次你在旁边不说话只看卡在哪一步一目了然。平均流转时长看的是流程效率从发起到结束的中位数时长如果某个节点的停留时间明显高于其他节点多半是那个节点的审批人设置有问题。字段空值率用来找无用字段一个字段如果 90% 的记录都是空的它就该被删掉或者改成选填。下面这份自检清单我每次交付前都会过一遍五分钟能走完检查项通过标准用非管理员账号登录能进应用看不到不该看的页面手机端实际打开字段不挤图片能看按钮可点每个流程节点模拟提交处理人都能正确匹配到人条件分支覆盖测试每条分支至少造一条数据命中报表口径核对报表条数与列表条数差值有明确解释定时通知触发一次收到通知的人、内容、时间都符合预期这里想多说一句关于验收的心态。我以前的做法是功能点全部勾完就交付结果第一个月收到一堆“这个字段能不能改一下”的反馈改起来比搭的时候还费劲。后来我改成交付前自己先用一周把能想到的边界情况都造一遍数据跑一遍——空数据、超长文本、重复提交、跨部门审批。这一周花下去后面三个月的返工基本就没了。从那以后我每次交付前都强制走一遍这份清单哪怕项目再小也不跳。手册本身给的是骨架案例给的是可抄的模板真正让一个应用能交出去用的是这些参数级的细节和验收习惯。六个案例里挑一个最贴近你当前业务的从字段清单开始重做一遍比从头到尾读三遍有用得多。手册和配套的案例结构都在那份 PDF 里拿去做对照希望帮到你。本文还有配套的精品资源点击获取 简介《0 代码搭应用——宜搭开发手册》PDF面向希望以低门槛方式推进企业信息化的业务人员、管理者与开发者围绕业务无系统支持、流程脱节、信息孤岛及开发运维成本高等问题系统介绍阿里巴巴宜搭平台的零代码搭建思路。压缩包内共1个PDF文件大小22.76MB内容结构完整便于集中阅读与检索。手册从宜搭简介、产品优势与客户案例切入收录杭州市一医院、老板电器、居然之家、海纳威等实践并给出核心要素、快速入门与进阶教程后半部分以“T恤尺码收集”“设备报修”“企业进销存”“报表分析”“定时消息通知”“企业报销流程”等案例展开帮助读者理解页面、表单、流程与数据分析的配置方法。该资源已有6793人学习适合作为业务人员自主搭建应用、团队评估零代码平台及开发人员快速了解宜搭能力边界的参考手册。1. 从一张 Excel 到一小时内上线这份手册真正解决的是什么0 代码搭应用这件事最容易让人低估的是“配置”两个字的深度。这份《0代码搭应用——宜搭开发手册》我前后翻了三遍第一遍当产品介绍看第二遍照着六个实践案例抄第三遍才看懂它真正的价值——它把“一个业务问题怎么拆成表单字段、审批节点和数据视图”这个完整过程摊开给你看了。它适合三类人被 Excel 和邮件追着跑的业务负责人、手里有零散系统要打通的信息化岗位、想快速验证内部工具的产品同学。不适合指望它替代后端开发的人手册里对接口和集成的描述只到方案层字段映射的细节还得自己补。2. 拆开宜搭的三层结构页面、表单、流程先跟业务对上拿到这类手册多数人的第一反应是从“快速入门”那一节开始往下翻翻到“进阶教程”就开始走神。我建议反过来先把手册开篇那几页讲的三大核心能力页面设计、业务规则定义、数据收集与分析翻译成自己能对上号的业务概念再去动案例。这三层如果一开始没对齐后面每个案例你都会搭出一个“能跑但没法维护”的东西。2.1 三大核心能力对应到具体配置位置手册把平台能力归成三块落到实际界面里其实是四个东西多出来的那一块是流程。很多人把“业务规则定义”直接等同于流程设计器结果搭到一半发现校验逻辑没地方放只能塞进行程审批的备注里最后没人看。手册里的说法实际配置在哪负责什么什么时候必须单独处理页面设计表单页面、自定义页面数据录入界面和展示界面录入字段超过 15 个就要拆分组否则手机上没法填业务规则定义表单校验、数据联动、公式、业务规则字段之间互相约束、自动带值、条件显隐只要出现“A 填了才显示 B”就必须在这里做流程流程设计器审批流转、节点权限、抄送只要涉及多角色交接表单里做不了数据收集与分析数据管理页、报表页面查询、筛选、统计、导出数据量起来后不建索引字段查询会明显变慢这张表看着简单但我见过不止一个人把“数据联动”写在流程的节点提交后事件里结果就是数据只在流转时更新业务同学在列表页改了字段联动值不跟着变对账时一对一个不吭声。联动的归联动流转的归流转这个边界一开始就要划清。2.2 用「设备报修」反推字段清单的四步法手册里的设备报修案例在第 75 页附近篇幅不长但它是全书里最适合拿来练手的一个——数据模型只有一个主表流程只有三个节点正好用来把方法论跑通。我一般按这四步走顺序不能换。第一步先把线下动作列成动词短语不要上来就想字段。设备报修这件事的动作是报修人描述故障、班组长判断是否外修、维修工接单、维修工填结果、报修人确认验收。五个动作对应五个信息产生点。第二步每个动作只问一句“这一步需要谁填什么”。报修环节需要设备编号、故障现象、紧急程度、现场照片判断环节需要处理方式自修/外修和判断意见接单环节需要接单人、接单时间维修环节需要维修措施、更换配件、耗时验收环节需要验收结论和满意度。第三步把同类信息合并成字段并定类型这一步最容易翻车业务含义字段类型选择不要用的类型原因设备编号关联表单关联设备台账单行文本手填必然出现编号错字后续统计全废故障现象多行文本单行文本单行文本在移动端只能看半行维修工要反复点开紧急程度单选一般/紧急/停机数字数字要靠人记 1/2/3 的含义新人必填错现场照片图片限 3 张附件附件要下载才能看审批人不会下载维修耗时数字单位小时保留一位小数单行文本文本没法求和报表做不出来第四步把字段按“谁填”分组表单里做成三个分组标题移动端一屏一组。这一步手册没明说但六个案例的表单页面全是这么分组的你照着看就能发现规律。提示字段命名尽量不带“是否”“状态”以外的前缀报表里字段名会直接变成列名名字太长列会被挤成一坨。这个细节在搭建阶段完全无感等做报表的时候才开始后悔。2.3 什么情况下该把表单和流程拆成两个应用手册里的“企业报销流程”案例用了流程表单“T 恤尺码收集”用了普通表单这两者的区别不是有没有审批而是数据生命周期。普通表单的数据是“收集完就固化”的尺码收完基本不再变流程表单的数据是“随流转演进”的每一笔报销在审批过程中状态一直在变。判断标准很实际如果一份数据在提交之后还会被反复修改状态并且不同状态对应不同的人有不同权限那就用流程表单。如果数据提交后基本不动只是需要汇总统计用普通表单加一个数据管理页就够硬套流程只会让发起人每次提交都要多点两下。还有一种情况是手册里没写、但实际项目中很常见的一个业务既需要收集又需要审批而且收集端和审批端的使用者完全不是一批人。比如访客登记前台收集行政审批。这种我会拆成两个应用收集端用普通表单通过关联把数据推给审批端而不是硬塞进一个流程表单里——一个流程表单挂两套权限后面加字段时权限会乱成一锅粥。3. 六个实践案例的复现顺序从 T 恤尺码收集到企业进销存手册从第 45 页开始给了六个案例目录顺序是T 恤尺码收集、设备报修、企业进销存、报表分析、定时消息通知、企业报销流程。这个顺序是按业务场景的行业分布排的不是按学习曲线排的。照着目录做你会在第三个案例上卡住——进销存涉及主表、子表、关联表单、库存联动复杂度是前两个案例的三倍以上。3.1 按数据模型复杂度重排而不是按页码我推荐的实际复现顺序是T 恤尺码收集 → 设备报修 → 企业报销流程 → 定时消息通知 → 报表分析 → 企业进销存。理由很直接前两个练字段和页面第三个练流程节点和条件分支第四个练时间触发和数据筛选第五个练聚合和图表最后一个才把所有东西揉在一起。定时消息通知和报表分析之所以提到前面是因为它们都可以挂在前三个案例的数据上做不需要新建业务模型属于“低成本高回报”的两个练习早点做能早点建立正反馈。这里有个血泪经验千万不要一上手就做进销存。进销存的难点不在表单而在库存这个数字到底该存在哪。手册里给的思路是入库、出库各建一张子表单库存由报表汇总算出。这个思路没问题但如果你没先做过报表分析那个案例你不知道汇总字段能不能跨表单取数、能不能做条件过滤就会在库存表上耗掉一整天。3.2 前两个案例的最小字段集照着抄就行T 恤尺码收集这个案例看着像玩具但它把“一人一记录 汇总统计”这个最基础的模式讲透了。最小字段集只有六个姓名成员字段不要用文本、部门部门字段、尺码单选 S/M/L/XL/XXL、数量数字默认 1、收货地址地址字段、备注多行文本非必填。这里有两个细节值得说。姓名用成员字段而不是单行文本是因为成员字段能自动带出部门和账号后面按部门统计的时候不用再做一次人工匹配。尺码用单选而不是下拉是因为手机上单选是平铺的一眼能看全五个选项下拉要点开才知道有什么。手册里这两个案例都用的单选不是随手选的。设备报修在前面 2.2 节已经拆过了补一个容易漏的设备台账这个关联源表单要在报修表单之前建好并且至少要填三条测试数据否则你在报修表单里配关联的时候会发现下拉是空的以为是配置错了其实是源表没数据。这个坑我踩过排查了二十分钟。3.3 进销存案例关联表单和子表单怎么分工进销存是六个案例里唯一需要认真设计数据结构的。手册给的结构是商品主数据、入库单、出库单三张表入库单和出库单里各挂一个商品明细子表单。这个结构的关键在于商品编码只存在商品主数据里入库出库只存引用。表主表字段子表单字段关联关系商品主数据商品编码、名称、规格、单位、安全库存无被下面两张表引用入库单入库单号流水号、供应商、入库日期、经办人商品关联、数量、单价、金额公式明细行关联商品主数据出库单出库单号、领用部门、出库日期、用途商品关联、数量、领用说明明细行关联商品主数据子表单里的金额用公式算不要让填单人填。数量乘单价这种计算交给公式人一忙就会填错而且填错了在子表单里极难核对——子表单是横向滚动的你得一行一行对。公式写对了这一整类错误直接消失。还有一个坑安全库存预警。手册里是用报表做条件过滤实现的筛选条件是“当前库存 安全库存”。这里“当前库存”必须是聚合值不能用入库减出库两个字段直接相减因为子表单的行数是动态的字段级公式算不了跨行求和。正确做法是在报表里对出库数量做求和、对入库数量做求和两个聚合值相减再跟安全库存比。这个逻辑想清楚了库存这块就通了想不清楚你会一直在表单里加字段试图硬算。3.4 报表分析案例要挂在自己的数据上别用示例数据手册的报表案例用的是平台自带的演示数据看完会觉得“哦就这样”然后关掉。正确做法是把它挂在你前面做的设备报修或报销数据上至少录二十条真实结构的测试数据再去做图表。二十条是个经验值。低于这个数柱状图和折线图画出来都是几根孤零零的柱子你判断不出分组维度选得对不对、时间粒度是不是太细。我一般会造三十条覆盖三个部门、两个月、四种状态这样才能验证“按部门按月看状态分布”这种三层嵌套的图表配置是否成立。4. 流程、权限与消息参数级的配置清单到这一层能跑通的人不少能配对的很少。手册在这部分的描述偏概念把“权限独立设置”“定制消息提醒推送”当成产品优势一笔带过但真正决定一个应用能不能交出去用的恰恰是这几个参数。4.1 审批节点的处理人设置怎么选处理人设置是流程里最容易配错的一项配错了不会报错只会静默地把单子发给不该发的人。常见的几种设置和适用场景处理人类型适用场景风险点指定成员固定岗位、人员不常变人一调岗所有历史流程的待办都挂在他名下指定角色岗位有备份人角色里加了人但没通知会出现“多出来的审批人”部门主管逐级审批组织架构没维护父子关系时主管字段是空的单子直接卡死表单内的成员字段由发起人指定审批人发起人可以随手填自己等于没有审批发起人本人补充说明节点只能用在非审批节点用在审批上等于自审自批实际项目里我会尽量避免“指定成员”改用角色。代价是前期要维护角色成员收益是人员变动时不用改流程。手册里那几个企业案例讲的都是组织架构频繁变动的场景背后其实就是这个取舍。会签和或签的选择也值得说一句。会签是所有人都要通过或签是任意一人通过即可。财务、法务这类需要留痕的节点用会签日常行政类审批用或签。配成会签但只加了一个人跟或签没区别但审批记录里会显示“1/1”看起来像走了集体决策这种自欺欺人的配置我见过不少。4.2 条件分支的优先级顺序决定漏单率条件分支的坑在于它是按顺序匹配的命中第一条就不再往下走。所以分支的排列顺序不是随意的要从最严格的条件排到最宽松的条件。举个报销的例子金额大于 5000 且含招待费 → 走总经理金额大于 5000 → 走财务总监金额小于等于 5000 → 走部门主管。这三条如果顺序反过来先放“金额小于等于 5000”看起来没问题但如果第一条写成“含招待费”而不带金额条件所有带招待费的小额报销都会被推到总经理那里你会发现总经理的待办列表莫名其妙多了一堆几十块的单子。我一般的做法是给每个分支写一句“这条分支在什么情况下会命中”的注释写在分支名里比如“分支A-大额且招待”。分支名短一点没关系关键是自己三个月后回来看还能看懂。手册里的报销案例分支不多但你只要在它基础上加一条“跨部门”的条件顺序问题立刻就会暴露。4.3 权限是三个独立的开关不是一套这是全书里最需要自己补的一块。宜搭的权限至少分三层应用权限谁能进这个应用、页面权限谁能看这个页面、数据权限谁能看哪些数据。三层是相乘的关系不是覆盖的关系。权限层常见配置配错的典型后果应用权限按部门或角色开放应用发布后外部人员也能搜到入口页面权限表单页、数据管理页、报表页分别设置报表页没设权限普通员工能看到全公司数据数据权限本人 / 本部门 / 本部门及下级 / 全部配成“全部”但本意是“本部门”跨部门数据全暴露字段权限单字段的可见、可编辑审批人能看到薪资字段但本不该看数据权限这一层最容易被忽略因为它的默认值往往是“全部”而人在搭完功能之后通常只测“能不能提交”不测“别人能不能看到”。我现在的习惯是应用发布前一定用一个非管理员的测试账号登录一遍从入口点进去逐个页面看有没有不该看的东西。这个动作五分钟能挡掉后面 90% 的返工。字段权限在流程里更微妙。同一个表单发起人能看到全部字段审批人只应该看到跟判断相关的字段。比如采购申请里的供应商报价部门主管要看但后面的财务节点不一定需要。这种按节点控制字段可见性的配置手册里没展开但在流程设计器的节点设置里是有的值得单独花半小时摸一遍。4.4 定时消息通知的时间参数定时通知这个案例看着简单本质是“在什么时间、按什么条件、给谁发什么”。三个参数里最容易错的是时间。时间配置一般有两种思路固定时间点触发比如每天早上九点和相对时间触发比如截止日期前一天。固定时间点适合日报周报类相对时间适合提醒类。相对时间配置时要特别注意“提前量”的边界如果记录本身的日期就在今天提前一天的通知会立刻触发用户在提交完的下一秒就收到提醒观感很差。条件筛选是第二个坑。通知一般只发给“还没处理”的记录所以筛选条件里必须带上状态字段比如“状态 ! 已完成”。漏了这个条件你会收到已经办完的事又被提醒一遍用户的第一反应是这系统不靠谱。给谁发这块能按角色发就别按人发理由跟 4.1 一样。5. 避坑与排查五处最容易翻车的地方5.1 关联表单下拉为空现象在报修表单里配置了关联设备台账预览时下拉列表是空的但源表单里明明有数据。原因关联表单有过滤条件默认会按某个字段做匹配如果主表和源表之间没有能对上的字段或者过滤条件被设置成了“当前表单某字段等于源表某字段”而那个字段还是空的结果就是空列表。解决先去掉所有过滤条件确认能拉到全量数据再一条条加回过滤条件。另外确认源表单的数据状态是“已发布”而不是草稿草稿数据不会出现在关联里。5.2 移动端和 PC 端显示不一致现象PC 上排版整齐的表单在手机上字段挤在一起图片看不到按钮被遮住。原因手册强调的“一次搭建双端适配”是布局层面的自适应不是内容层面的自动精简。字段太多、分组太粗在窄屏上必然挤。解决每个分组控制在 6 到 8 个字段以内长文本字段在移动端会占据大量纵向空间非必填的长文本考虑收起。图片字段限制数量三张以内。发布前一定用手机实际打开一次不要只看 PC 预览。5.3 公式计算结果跟手算对不上现象子表单里的金额合计跟把明细行手工相加的结果差几分钱。原因多半是小数位处理不一致。数字字段如果设置了保留两位小数展示时是四舍五入的但参与计算的是原始值。逐行四舍五入后求和跟先求和再四舍五入结果会差。解决统一在公式里先做四舍五入再求和或者干脆所有金额字段都不做展示层的四舍五入只在最终展示时格式化。这个规则要在建表阶段就定下来中途改会导致历史数据全部重算。5.4 流程卡在某个节点不动现象单据提交后一直停在某个审批节点处理人说自己没收到待办。原因处理人配置成了“部门主管”但提交人的部门在组织架构里没有配置主管字段系统找不到人流程静默挂起。解决流程设计器里对每个节点做一次“模拟提交”用不同部门的账号各跑一遍。组织架构里主管字段为空这件事从界面上完全看不出来只能靠跑流程暴露。这类问题一旦上线才发现用户会认为系统坏了。5.5 报表数据跟列表数据对不上现象数据管理页显示有 120 条记录报表里统计出来只有 98 条。原因报表的数据集默认带了过滤条件比如只统计已完成的单据或者只统计当前用户有权限看的数据。列表页的权限和报表的权限是分开配的经常不一致。解决做报表前先去数据集里看清楚默认过滤条件是什么把“统计口径”写在报表标题下面的说明文字里。这是给后面接手的人留的后路也是给自己三个月后回来看留的后路。6. 从搭完到验收三个指标和一份五分钟自检搭完一个应用不等于能交付。我现在的验收标准是三个数字首次提交完成率、平均流转时长、字段空值率。首次提交完成率是指发起人打开表单到成功提交的比例这个数字低于 80% 说明表单太长或者必填项设计有问题。测法很简单找三个没参与搭建的同事让他们各填一次你在旁边不说话只看卡在哪一步一目了然。平均流转时长看的是流程效率从发起到结束的中位数时长如果某个节点的停留时间明显高于其他节点多半是那个节点的审批人设置有问题。字段空值率用来找无用字段一个字段如果 90% 的记录都是空的它就该被删掉或者改成选填。下面这份自检清单我每次交付前都会过一遍五分钟能走完检查项通过标准用非管理员账号登录能进应用看不到不该看的页面手机端实际打开字段不挤图片能看按钮可点每个流程节点模拟提交处理人都能正确匹配到人条件分支覆盖测试每条分支至少造一条数据命中报表口径核对报表条数与列表条数差值有明确解释定时通知触发一次收到通知的人、内容、时间都符合预期这里想多说一句关于验收的心态。我以前的做法是功能点全部勾完就交付结果第一个月收到一堆“这个字段能不能改一下”的反馈改起来比搭的时候还费劲。后来我改成交付前自己先用一周把能想到的边界情况都造一遍数据跑一遍——空数据、超长文本、重复提交、跨部门审批。这一周花下去后面三个月的返工基本就没了。从那以后我每次交付前都强制走一遍这份清单哪怕项目再小也不跳。手册本身给的是骨架案例给的是可抄的模板真正让一个应用能交出去用的是这些参数级的细节和验收习惯。六个案例里挑一个最贴近你当前业务的从字段清单开始重做一遍比从头到尾读三遍有用得多。手册和配套的案例结构都在那份 PDF 里拿去做对照希望帮到你。本文还有配套的精品资源点击获取