语之溪
在学校业务系统中，一个需求通常不会只对应一个页面。表单负责收集数据，审批流程负责推动状态变化，工作台则负责让不同角色看到自己需要处理的事项。
这几个部分如果分别配置，页面可能都能打开，但业务不一定能真正走通。真正的交付，需要把数据、角色、流程和入口串在一起。
表单不只是输入框
表单最直接的作用是收集数据，但字段设计还会影响后面的流程和权限。
同一个字段可能有几种状态：创建时由申请人填写，审批时只能查看，退回后允许修改，完成后又变成只读。字段是否必填、谁可以编辑、什么条件下显示，都需要和业务过程一起考虑。
业务对象
-> 字段定义
-> 填写与校验
-> 提交后状态变化
-> 审批和后续使用这是一种通用的表单设计思路，不对应内部业务系统的具体字段和配置。
流程连接角色和状态
审批流程的作用，不只是把一条数据从一个人送到另一个人。它还需要说明数据当前处于什么状态，以及下一步由谁处理。
一个简化的流程可以表示为：
草稿
-> 提交
待审核
-> 通过 -> 已完成
-> 退回 -> 待修改每个状态都可能对应不同的操作权限。待审核状态下，申请人可能只能查看；退回状态下，申请人可以修改并重新提交；已完成状态下，普通用户可能只能查看结果。
平台通常能够提供流程节点和角色配置，但具体哪些角色参与、什么条件可以通过、退回后哪些字段可编辑，仍然需要结合业务需求判断。
工作台是业务入口
工作台把待办、已办、草稿和相关业务入口集中起来，让不同角色能够快速找到需要处理的内容。
对于申请人，工作台可能重点展示自己的草稿、待修改和已提交记录；对于审核人，重点可能是待审核事项；对于管理人员，则可能需要查看统计和整体进度。
因此，工作台的内容不是简单地把所有菜单放在一起，而是需要根据角色和数据状态筛选出合适的入口。
当前用户
-> 角色与权限
-> 可见业务范围
-> 待办和历史记录
-> 进入表单或审批节点这是公开业务系统中常见的设计方式，项目内部的角色名称、菜单和数据范围不公开展开。
三者之间必须保持一致
表单、流程和工作台之间最容易出现的问题，是各自的配置没有同步。
例如，表单提交后已经进入待审核状态，但工作台没有生成审核人的待办；或者流程退回后允许申请人修改，但表单仍然是只读；又或者工作台显示了一条记录，但打开后用户没有对应权限。
排查这类问题时，可以沿着一条完整链路检查：
- 表单是否收集到了正确数据；
- 提交接口是否改变了正确状态；
- 流程是否根据条件找到正确角色；
- 工作台是否查询到了对应待办；
- 点击入口后，权限和页面状态是否一致。
这类检查是通用联调方法，不代表项目内部存在上述具体故障。
平台配置和代码扩展
低代码平台可以快速配置表单、流程和工作台，但业务系统往往会有一些特殊规则。例如，某个字段是否显示取决于前置选择，某个审批节点需要根据数据内容动态决定，或者提交前需要执行平台默认校验之外的逻辑。
这些需求可能通过平台配置完成，也可能需要增加代码扩展。判断方式不是看到特殊需求就全部写代码，而是先确认平台能力能否覆盖，再选择配置、表达式、接口或代码扩展。
平台标准能力
-> 能否覆盖需求
-> 配置解决
-> 配置不足时补充代码
-> 联调并验证状态闭环公开文章只介绍这种通用决策过程，不展开内部扩展点、接口和实现细节。
业务闭环比单页完成更重要
一个业务功能完成的标志，不只是表单页面能提交，也不只是审批节点能够保存。还需要确认从创建、提交、审核、退回、再次提交到完成的整个过程是否连贯，工作台入口是否和状态同步，权限是否始终符合角色边界。
现在我会把这类需求看成一条业务闭环：表单负责表达数据，流程负责推动状态，工作台负责组织入口和任务。低代码平台可以提供很多基础能力，但真正的交付仍然需要把这些能力按照业务规则组合起来。
