表单的本质是展示与采集数据。 控件负责「看见什么、填什么」；业务逻辑负责「改了 A，B 和 C 怎么办」。

在该低代码平台里，表单、流程、单据、门户不直接连接第三方库或接口。中间有一座可配置的桥：

研究任何一个事物，第一步都是分类、起名、下定义，然后分别公式化处理。这是人类对付复杂世界的一贯套路：分而治之，各个击破。

表单是车厢；实体与单据是货物的种类；流程引擎是动力系统。三个都到位了，才能组装出一台真正能跑的车。所以主题非常明确：流程、表单、数据这三者之间，到底是什么关系？...

权限与控制方案随宿主应用而变（流程 / 单据 / 实体）。下文按流程表单把两条线写透；单据、实体可类比「有没有轨迹发送点、有没有独立模板目录」。

表单引擎要同时解决四件事：结构（有哪些字段）、呈现（怎么画）、行为（改了 A 怎么办）、落库（数据存在哪）。 市面上的产品差异，很少出在「能不能画文本框」，而出...

《五大设计器》讲的是造车厢的车间；本文讲的是车厢里三样货怎么摆。车间可以换，货的分类不变。

表单的本质是两件事：展示数据与采集数据。 这两件事决定底层逻辑；元素怎么分类，则决定设计器面板怎么摆、元数据怎么存、运行时怎么渲染。

表单的本质是展示数据与采集数据。 这两件事决定了底层逻辑（控件、落库、校验、扩展），却不决定它挂在哪套应用上。

在该产品体系里：表单是车厢，数据是货物，流程引擎是动力系统。 设计器解决的是——用哪种车间、按哪种工艺，把车厢造出来。

这套课程不是十二个孤立的知识点，是一条从世界观到落地的完整链路：开头五讲打底子——两种世界观、表单的本质、实体与单据、铁三角、技术思维与应用思维；第六讲做第一次...

想做下拉框、想取 ERP 的数据、想在审批通过后通知外部系统，最笨的办法是各处各写各的：请假表单自己去连，报销表单自己去连，客户单据、流程事件，全都自己硬编码—...

三步走完，再把这些业务逐个匹配低代码里的实现手段：流程、实体方法、通用组件。这套东西，屡试不爽。

实体类的诊断方法还是三步：拿到一个系统 → 核对实体类的两条特征 → 看清实体状态该怎么管。

为什么先画主线？因为如果用自然语言去描述整个过程——立项之后要做环保审批、市政审批、供热审批，同时还要做可行性研究，然后进入设计阶段，设计里面又分初步设计和施工...

第一步，拿到一个系统；第二步，逐条核对七条判据；第三步，命中五条以上，确诊。确诊之后才能套用对应的设计公式。

研究任何一个事物，第一步都是分类、起名、下定义，然后分别公式化处理。这是人类对付复杂世界的一贯套路：分而治之，各个击破。

表单是车厢；实体与单据是货物的种类；流程引擎是动力系统。三个都到位了，才能组装出一台真正能跑的车。所以主题非常明确：流程、表单、数据这三者之间，到底是什么关系？...

技术同事眼里的这张报销表，是表名、字段名、字段类型，是主键外键索引长度，是增删改查、事务和慢查询；应用分析师眼里的同一张表，是这是一张单据、它走的是审批流程，是...

如果把员工信息、设备台账、学生档案、车辆登记归到了一组——这一类长期存在、变化很少，像一篇说明文；如果把报销单、请假单、设备维修单、出库单归到了另一组——这一类...