织信开发日志 03：表单引擎从 0 到 1 的设计过程
作者：Skydu
摘要：表单引擎看起来是低代码平台里最基础的能力，但它真正承载的是业务建模、数据结构、权限、流程和后续 AI 理解业务的入口。
开篇
如果说上一篇是在讲织信为什么不是一个单纯的低代码工具，那么从这一篇开始，我想进入具体功能。
第一个要写的模块，是表单引擎。
原因很简单：在低代码平台里，表单看起来最基础，但它并不只是一个页面。很多企业业务系统的第一步，都是从一张表单开始的。客户登记、合同审批、项目立项、采购申请、库存入库、设备巡检、生产报工，本质上都是业务数据的采集、组织和流转。
所以表单引擎不是"拖几个输入框"的问题，它是整个平台业务建模能力的入口。
最开始的需求很简单
做表单引擎之前，我最朴素的想法是：用户应该可以自己创建业务表单，自己配置字段，然后让系统自动生成录入页面和数据列表。
这个想法听起来并不复杂。一个表单名称，一组字段，一个保存按钮，一个数据列表，似乎就够了。
但真正开始做以后，很快就会遇到一连串问题。字段类型有哪些？字段能不能分组？字段之间有没有联动？数据要不要校验？表单提交后是否触发流程？不同人能不能看到不同字段？表单数据怎么被报表、自动化和 AI 使用？
这些问题叠在一起，表单引擎就不再只是前端组件，而是一个连接数据模型、权限体系、流程体系和自动化体系的核心模块。
表单不是页面，而是业务模型
我后来越来越明确一个判断：低代码平台里的表单，不能只按页面来设计，而要按业务模型来设计。
页面解决的是"用户看到什么、怎么填写"的问题；业务模型解决的是"这个业务对象是什么、数据怎么存、关系怎么表达、后续怎么流转"的问题。
比如一个客户表单，表面上只是客户名称、联系人、电话、来源、负责人这些字段。但它背后其实对应一个客户对象。这个对象可能关联跟进记录、合同、订单、回款、项目，也可能参与 CRM 流程、销售看板和客户分层分析。
如果只把表单当页面，后面每一个能力都会变得割裂；如果把表单当模型入口，流程、权限、报表和 AI 才能围绕同一套业务对象继续扩展。
第一版表单引擎的核心对象
我在设计第一版时，先把表单拆成几个核心对象。
第一个是应用。应用是业务系统的容器，比如 CRM、项目管理、采购管理、设备管理。
第二个是数据表。数据表承载某一类业务对象，比如客户、合同、订单、任务、设备。
第三个是字段。字段描述业务对象的属性，比如文本、数字、日期、选项、人员、部门、附件、关联数据等。
第四个是视图。视图决定数据以什么方式呈现，比如表格视图、详情页、表单页、看板、日历、仪表盘。
第五个是动作。动作决定用户可以对数据做什么，比如新增、编辑、删除、提交审批、导入导出、触发自动化。
这样拆开以后，表单就不再是一块孤立页面，而是数据表、字段、视图和动作组合出来的一种交互形态。
字段设计是第一个难点
表单引擎里最容易被低估的是字段设计。
字段看起来只是类型选择，但不同字段背后对应完全不同的数据结构和业务语义。文本字段可以模糊搜索，数字字段可以统计汇总，日期字段可以做时间筛选，人员字段可以连接组织架构，关联字段可以建立业务对象之间的关系。
所以字段不能只服务于"填写"，还要服务于查询、统计、权限、流程条件和 AI 理解。
比如一个"负责人"字段，如果只是普通文本，系统就不知道这个人是谁，也无法判断权限、发送通知或做人员维度统计。但如果它是人员字段，就可以和组织、角色、数据权限、消息通知连接起来。
这就是字段类型设计的价值：它把业务含义沉淀到了平台模型里。
第二个难点是动态与稳定的平衡
低代码平台要求字段可以动态配置，但企业系统又要求数据稳定可靠。
这中间有一个很现实的矛盾：如果一切都太动态，系统很灵活，但查询、统计、性能和维护都会变复杂；如果一切都太固定，系统很稳定，但业务一变化就要重新开发。
所以表单引擎的设计，核心不是追求绝对动态，而是在动态和稳定之间找到边界。
哪些东西应该让用户配置？哪些东西应该由平台固化？哪些能力可以通过元数据驱动？哪些地方必须保留工程约束？这些问题比"能不能拖拽"更重要。
表单和权限必须一起考虑
很多系统一开始做表单时，只考虑字段和页面，权限放到后面再补。
但企业系统里，权限往往不是附加项，而是从一开始就应该进入表单设计。
同一张表单，不同角色看到的字段可能不同；同一个字段，有的人能编辑，有的人只能看；同一条数据，部门负责人、创建人、协作人、管理员的权限也可能完全不同。
如果表单引擎没有预留字段级权限、数据级权限和动作权限，后面接业务场景时就会非常痛苦。
所以在织信里，我希望表单不是孤立生成页面，而是天然连接权限体系。表单字段、数据范围、操作按钮，都应该能被权限规则控制。
表单和流程也不能割裂
企业里的很多表单，填完之后并不是简单保存，而是进入某个业务流程。
比如采购申请要审批，合同要法务审核，项目立项要负责人确认，费用报销要财务处理。
这意味着表单引擎必须和流程引擎协同。表单负责采集和展示数据，流程负责推动数据在不同节点之间流转。
更进一步，流程中的每个节点可能都有自己的表单权限：发起人能填写哪些字段，审批人能修改哪些字段，抄送人只能看到哪些内容。
所以我理解的表单引擎，不只是"录入页面生成器"，而是流程中业务数据的承载层。
表单数据未来也要被 AI 理解
现在做表单引擎，还必须考虑 AI。
如果未来希望 AI 帮用户生成表单、分析数据、配置流程、回答业务问题，那么表单模型必须足够清晰。
AI 需要知道每个字段是什么含义，哪些字段是人员，哪些字段是金额，哪些字段是状态，哪些字段代表时间，哪些字段和其他业务对象有关联。
如果表单只是一个个没有语义的输入框，AI 就很难真正理解业务。它也许能生成页面，但很难安全、准确地参与企业流程。
所以 AI + 低代码不是在表单外面加一个聊天框，而是要让平台内部的模型、字段、关系和权限都能被 AI 理解和调用。
第一版我最看重什么
如果只做第一版，我不会追求把所有高级能力一次做完。
我最看重三件事。
第一，模型要清楚。应用、数据表、字段、视图、动作之间的关系要稳定，后面才能继续扩展。
第二，字段要有语义。字段类型不能只是前端控件，而要能支撑查询、统计、权限、流程和 AI。
第三，边界要留好。表单要能连接权限、流程、自动化和报表，但第一版不一定把所有能力都做到极致。关键是架构上不能堵死。
平台型产品最怕的不是第一版功能少，而是第一版模型错。功能少可以补，模型错了后面每一步都会变重。
踩过的一些坑
做表单引擎时，我也踩过不少坑。
第一个坑，是过早关注界面效果。拖拽体验、控件样式、布局细节很容易让人兴奋，但如果底层模型没想清楚，界面做得越漂亮，后面改起来越痛苦。
第二个坑，是低估字段联动和校验。真实业务里，字段不是孤立的。选择客户后带出联系人，选择部门后限制人员范围，金额超过阈值后触发审批，这些都要求表单具备规则能力。
第三个坑，是把列表和表单分开看。很多业务不是只需要录入，还需要筛选、排序、批量操作、导入导出、统计汇总。表单和列表其实是同一个数据模型的两种视图。
第四个坑，是后补权限。权限如果一开始没进入模型，后面补字段级权限、数据权限、流程节点权限时，会牵一发动全身。
写在最后
表单引擎是低代码平台最基础的模块，但基础不代表简单。
它连接的是企业业务系统里最核心的那件事：如何把业务对象、业务数据和业务规则沉淀到平台里。
在我看来，一个好的表单引擎，不应该只让用户更快搭页面，而应该帮助企业更清晰地定义业务。
这也是织信要继续往下走的方向：从表单开始，但不止于表单；从低代码开始，但最终服务的是企业数字化和智能化。