织信开发日志 14表单引擎不是页面生成器而是业务入口上一篇写数据模型。这一篇继续往前走一步表单。很多人理解低代码第一反应是拖表单。但在企业系统里表单不是几个输入框。它是业务数据进入系统的入口。入口设计得不好后面的流程、权限、统计、自动化都会被拖住。表单首先承接数据模型在项目管理系统里项目表已经有一组字段项目编号项目名称项目状态项目经理项目优先级开始日期截止日期项目进度。这些字段在设计端是模型。到了运行端就变成用户真正要填写的表单。所以表单不是凭空设计出来的页面。它是数据模型的一种交互形态。模型里有什么字段表单里就要考虑怎么录入、怎么展示、怎么校验。必填不是越多越好我在运行端打开创建项目表单可以看到项目编号、项目名称、项目状态、项目优先级、项目进度都是必填。这正好说明一个问题表单规则不能只追求完整。项目编号、项目名称必填很合理。项目状态必填也可以接受。但项目进度是否一开始就必填就要看业务。如果项目刚创建进度通常应该默认是 0而不是让用户手填一个数字。必填项太多表面上数据更完整实际会增加录入负担。用户为了提交表单会填一些并不准确的值。这种数据进入系统以后后面的统计也会被污染。表单校验的原则应该是只校验真正影响业务流转的字段。字段类型决定后续能力表单字段不能只看输入体验。字段类型会影响后面的查询、权限、统计和自动化。负责人如果是文本系统只知道这是一段字。负责人如果是用户字段系统就可以做权限判断、消息通知、人员维度统计。状态如果是文本用户可能输入“进行中”“开发中”“处理中”。状态如果是选项字段系统才能稳定筛选、分组、统计和触发规则。这就是字段语义的价值。表单引擎真正要做的不是把输入框摆出来而是让每个字段都带着明确的业务含义进入平台。表单要服务不同角色同一张表单不同角色关心的内容不一样。项目经理创建项目时关注项目目标、负责人、截止日期。成员查看项目时更关心自己的任务和工时。主管看项目时关注进度、风险、延期。所以表单不能只有一种固定形态。它要能根据角色、场景、状态做不同呈现。有些字段创建时可编辑进入执行阶段后只读。有些字段普通成员不可见管理员可以看到。有些字段只有在项目状态变成“进行中”以后才必填。这些都不是页面细节而是业务规则。表单和动作要连在一起表单不是填完保存就结束。保存以后可能要触发自动化。状态变化可能要提醒负责人。风险等级变高可能要通知主管。项目提交后可能要进入流程。所以表单引擎要和动作体系连在一起。创建、编辑、删除、提交、审批、导入、导出、触发自动化这些都不是孤立按钮。它们都围绕同一份业务数据发生。表单负责采集数据动作负责推动业务继续往下走。AI 也需要理解表单AI 生成应用以后还会继续参与配置。它要修改必填规则就必须知道哪个字段对应哪个业务含义。它要生成测试数据就必须知道哪些字段必填、哪些字段有关联。它要配置自动化就必须知道表单状态变化意味着什么。如果表单只是一些没有语义的输入框AI 很难可靠地继续工作。所以表单引擎越清楚AI 后续越容易接手。这也是我现在重新看表单引擎时最在意的点表单不只是给人填写也要让 AI 能理解。我的判断表单引擎不是页面生成器。它至少要承担四件事承接数据模型控制录入和校验连接权限和动作让后续流程、统计、自动化、AI 都能理解这份数据。低代码平台的第一眼可能是表单。但真正决定它能不能走远的是表单背后的字段语义、业务规则和扩展能力。表单做浅了只是一个录入页面。表单做深了才是企业数字化系统的入口。