语之溪
进入学校业务系统开发之后，我接触到了一种和过去不太一样的开发方式：系统不一定从空白项目开始，很多业务能力已经由低代码平台提供，但实际交付仍然需要理解需求、配置平台、补充代码，并把功能真正落到业务流程里。
这也是我想记录“低代码平台之外”的原因。低代码并不意味着不用理解代码，更不意味着所有需求都能通过拖拽直接完成。
平台能力解决一部分问题
低代码平台通常已经提供了一些基础能力，例如表单、数据模型、流程、权限和工作台。面对常见的业务需求，可以先利用这些能力搭建基础结构，再根据业务要求继续调整。
业务需求
-> 识别平台已有能力
-> 配置表单和流程
-> 补充特殊业务逻辑
-> 联调和验证平台能力的价值在于减少重复建设，但前提是先理解需求。一个字段应该放在哪里、一个审批节点需要什么条件、不同角色能够看到哪些内容，都不能只靠平台默认配置决定。
二次开发需要理解业务边界
学校业务系统通常包含教务、行政和资源管理等场景。它们看起来都是表单和流程，实际却有不同的业务规则。
同一个“提交”动作，在不同场景下可能意味着保存草稿、发起审批、提交审核或完成某个业务节点。页面上的字段也不只是展示内容，可能会影响后续流程、权限和数据状态。
所以二次开发时，我会先确认几个问题：
- 这个功能是平台标准能力，还是业务特殊需求；
- 字段由谁填写、谁修改、谁查看；
- 数据提交后会进入什么状态；
- 流程节点之间有什么前置条件；
- 平台配置能否覆盖需求，哪些部分需要代码扩展。
这些问题本身不依赖具体平台，属于业务系统开发中的通用分析方法。内部表单、流程和权限配置不在公开文章中展开。
代码扩展不是重新造平台
当平台能力无法直接覆盖需求时，就需要补充代码。但补充代码并不等于把平台完全替换掉，也不等于从零独立开发整套系统。
更实际的方式通常是保留平台提供的基础能力，再围绕特殊业务做扩展，例如：
平台基础能力
+ 业务字段和表单调整
+ 特殊校验
+ 接口或数据处理
+ 页面交互补充
+ 流程结果验证这也是我对“平台能力 + 代码扩展”模式的理解。平台负责通用部分，开发工作负责把特殊业务接起来，并处理平台默认行为无法覆盖的部分。
具体使用了哪些前端组件、接口路径和内部扩展方式，涉及项目实现细节，本文不公开展开。公开文章只保留方法和职责边界。
独立技术开发和平台二次开发可以同时存在
在这个阶段，我的工作并不只有平台配置，也包含独立技术开发。两者的区别不在于有没有使用平台，而在于具体功能由什么方式完成、本人承担了哪一部分责任。
平台二次开发通常是在已有能力上扩展：先了解平台的模型、流程和权限，再接入业务需求。独立技术开发则需要更多地负责具体功能的设计、实现和联调。
但这两种工作也不是完全割裂的。一个独立开发的功能，可能仍然需要和平台中的表单、流程、权限或数据模型连接起来；一个平台配置功能，也可能需要通过代码解决特殊边界。
因此，不能简单地把低代码项目概括成“只做配置”，也不能把其中的代码扩展写成“完全从零开发整套平台”。更准确的表达是：在平台能力基础上进行二次开发，同时完成部分独立技术开发。
低代码仍然要求工程判断
低代码平台能够加快业务应用建设，但它没有消除工程问题。需求是否理解准确、字段是否设计合理、流程是否覆盖异常情况、权限是否符合角色边界、上线后能否正常使用，这些仍然需要开发人员判断。
配置完成
-> 功能联调
-> 正常流程验证
-> 异常和权限验证
-> 用户反馈整理
-> 调整并再次验证这套流程是业务系统交付中的通用做法，不对应某个内部项目的完整验收表。平台提供的是工具和能力，最终能不能落地，仍然取决于需求理解、实现方式和验证过程。
目前我对这个阶段的认识是：低代码降低了重复建设的成本，但没有降低理解业务的要求。真正的二次开发，既要知道平台能做什么，也要知道平台默认行为在哪里不够用，以及应该用配置还是代码去补上这部分能力。
