用 FcDesigner 低代码表单设计器配一张会「看情况变」的在线申办表

网上办食品经营许可，用户点进申请页，第一道题是「主体业态」。选「食品销售经营者」，后面是预包装、散装、特殊食品；选「餐饮服务经营者」，后面变成热食、冷食、生食、自制饮品；选「单位食堂」，又是另一套。同一张许可证，不同业态要填的字段、要交的材料、要过的校验几乎没有交集。

这道题答不对，或者答对了却带不出正确的后续，就是行政许可申办里最常见的一类差评：申请人以为照着页面填就行，填到一半发现字段对不上自己的业态，退回、重填、再提交。

低代码表单设计器在这里的价值，就是把这种「看情况变」做成规则。把这张申请表交给 FcDesigner 做可视化配置、交给 FormCreate 做动态渲染，业态和经营项目就不再是页面里的一堆 v-if，而是一条可发布、可复用、可回放的规则。

这张表难在哪：业态一分，字段全变

食品经营许可的申请表，不是「字段多」的问题，是「字段的集合随选择变」的问题。

主体业态一列，通常就有食品销售经营者、餐饮服务经营者、单位食堂、食品添加剂经营者等若干类。这几类要的字段差异很大：

主体业态	展开的分组 / 字段
食品销售经营者	销售品类（预包装/散装/特殊食品）、贮存条件
餐饮服务经营者	餐饮制售项目、加工场所与专间
单位食堂	供餐对象、就餐人数、集中供餐管控

经营项目本身还是个多选，而且项目之间有真实约束：选了冷食、生食类制售，通常要有专间；选了自制饮品，通常要有相应的清洗消毒条件。这些约束各地要求可能不同，但方向一致——不是所有组合都合法，也不是所有非法组合都要靠提交后人工退回才能拦住。

再加上从业人员健康证、主要设施设备这类「一行一条」的子表，以及场所平面图、食品安全管理制度这类随情况增减的材料，这张表几乎不可能用一张写死的页面扛住。

写死有两种坏结局。一种是做一张巨长的万能表，把所有业态的字段都摊开，靠文案告诉用户「不是你的请跳过」——用户跳过会漏，不跳会烦。另一种是为每种业态各做一张表，结果事项一改，页面、校验、材料清单各维护一份，改一处要改五处。

一张可配置的申请表，在系统里长什么样

把它收成一张主表加若干按业态展开的分组，问题就收敛了。

主表放所有业态都有的东西：主体信息（从统一身份带出，不重采）、主体业态、经营场所、法定代表人、联系人。主体业态用单选，经营项目用多选。这两项是后续所有联动的开关。

按业态挂分组：选了「餐饮服务经营者」或「单位食堂」，展开「餐饮制售项目」和「加工场所与专间」；选了「食品销售经营者」，展开「销售品类」和「贮存条件」。分组用条件显示，用户选一次业态，后面的表自己成形，而不是被路由到另一张页。

经营项目的多选做校验，而不是靠审批岗事后拦。冷食、生食制售要求专间，勾了项目却没填专间信息，提交前就该提示；选了餐饮制售项目却一个制售类别都没勾，也一样过不去。数字类的——就餐人数、经营面积——用公式做即时提示，终审仍在审批工作台，但网厅不放行明显不成立的组合。

从业人员健康证、主要设施设备用子表，一行一条。场所平面图、食品安全管理制度这类材料，跟随业态和项目出现或隐藏，不是永远摊在页面上。

审批工作台不再为每个科室画一张详情。同一份 JSON，现场核查岗打开「场所与专间」段可审，健康证核验岗打开「从业人员」段，其他段阅读模式，基础信息锁定。移动端政务服务只保留业态、经营项目、进度和待补材料，健康证列表、设施设备清单这类明细留在 PC 网厅。设计一次，PC 与移动端共用规则，移动端按 Vant 风格呈现。

主表进库，模块进子表，JSON 跟事项版本绑在一起：哪一次申办用的是哪一版表，退回补正打开当时那版，避免拿新文件的字段去审旧申报。设计器可以按字段生成建表 SQL，执行前必须人审。

接进现有政务系统，换的是申报页怎么发布

不需要先替换一网通办。事项编码、办理深度、统一身份、证照核验、签章，继续由政务系统提供。变化发生在发布方式上：事项上线时，除了流程和时限，多发布一份表单 JSON。网厅的食品经营许可入口只打开这一张申报；审批工作台按岗加载同一张，用角色决定能改哪一段。

实施上先把业态枚举、经营项目的合法组合、材料随情况变化的规则写成文字，再进设计器。规则含糊，画布上只会把多个旧页面拼成一张更长的页，那仍不是配置化。AI 表单助理可以按「食品经营许可：主表 + 按业态展开分组 + 经营项目组合校验 + 人员/设施子表」生成第一版，业务在画布上改业态边界和校验，比在多个子系统里分别提需求要快。

自定义组件留给证照核验回写、签章、事项编号回写。自定义模板留给「从业人员健康证列表」「设施设备清单」这类重复块——卫生许可、药品经营许可来了，拖同样的模块，而不是复制整张申报。开源 FcDesigner 够把业态分叉和主表搭出来；角色切开审批岗、公式校验、生成库表、移动端预填，再看 FcDesigner Pro 文档。

FormCreate 自 2018 年开源，由西安锦强未来科技有限公司的 FormCreate 团队维护。

这样配置后，少掉的工作

开发不再为「加一种业态」或「改一个经营项目约束」开迭代。业态、联动、校验、提示文案在设计器里改，JSON 发布后下一次打开即生效。

业务科室可以参与定字段和定规则，而不只是提需求等还原。画布上当场能试：勾了冷食制售，专间信息出不出来；选了单位食堂，餐饮项目该不该出现。

同类行政许可可以复用同一套配置。卫生许可、药品经营许可、道路运输经营许可，同样是「主体类型分叉 + 项目组合校验 + 人员/设施子表」的结构，换枚举、换校验规则，而不是每上一个事项就做一张写死的页。

以上是典型场景里可预期的分工变化，不是某家客户的实施报告。具体能少几人天，取决于你们现在有多少个许可事项的申报页写在代码里。

常见问题

食品经营许可的申报页，为什么不能做一张万能表？

业态分叉加项目组合校验，决定了一张万能表要么塞满用户不用的字段，要么漏掉真实约束。配置化把「哪种业态出现哪些字段、哪些组合合法」做成规则，用户只看到自己业态该看的部分。

FcDesigner 能替代食品经营许可的审批流程吗？

不能。FcDesigner 解决申请表长什么样、谁能改哪一项、组合怎么校验。受理、现场核查、审批、发证仍是政务系统的审批流程。两者通过「事项版本带哪一版 JSON、节点用编辑还是阅读打开」衔接。

每种业态都要做一份 JSON 吗？

优先做一份主表，用业态联动和项目校验消化差异。只有口径彻底不同的（例如单位食堂与食品销售几乎不共享字段）才拆 JSON 版本。自定义模板用来沉淀「健康证列表」「设施设备清单」这类重复块。

只用开源版能不能做食品经营许可？

能做出可填、可校验、可提交的申请表，并接入现有审批流。若要把角色切分审批岗、公式校验、生成库表、移动端 Vant 渲染一次配齐，需要看 FcDesigner Pro 的对应能力。

如果你正在给政务系统里的许可申办做配置化改造，不必先上全量低代码。拿食品经营许可这一个事项，在 FcDesigner 里搭出主表和业态分组，把经营项目的组合校验配通，用 FormCreate 接到网厅入口上。跑通餐饮服务和食品销售两种业态，再决定哪些同类许可收进同一套配置，哪些必须拆 JSON 版本。