低代码和AI Coding怎么选？做企业应用，当然是全都要
一个报销应用，第一版要多久？
拖几个输入框，加上金额、附件，再接两级审批，页面已经很像样。换成AI Coding，把需求交给编程工具，也能从另一条路开始搭建。
接着需求变了：明细金额要汇总，员工只能选择自己的项目，报销还要关联预算；财务退回后，申请人得看懂哪里需要修改。
这时再争论“拖拽还是写代码”，容易把真正的问题漏掉：哪些规则值得配置，哪些规则必须由业务代码明确负责？
我的选择是两种能力都保留。标准的部分少重复劳动，特殊的部分有地方扩展，组织、权限和审批沿用同一套基础能力。“全都要”说的是这套分工，不是要求每个小应用同时采购两套工具。
先看一个系统里，两种表单怎样共存
在我们开发的RuoYi Office流程中心里，设计器表单和自定义业务表单是两条实际存在的路径。
报销申请的布局、字段、必填项、明细组件，可以放在设计器里维护。开发者看到的是组件与属性，使用者打开的则是可以填写的业务页面。
▲ 已有报销表单的设计界面。金额、事由和明细有各自的位置；配置页面结构，不等于完成全部报销规则。
另一类业务不强行塞进通用画布。例如，需要较多特定交互、领域计算或跨模块操作时，可以使用自己的业务页面，再接入流程。
这让“是否使用低代码”从一个全系统的立场问题，变成一个具体功能的设计决定：同一个平台里，有的表单配置更合适，有的业务保留源码更合适。
之前讨论低代码时，我更强调复杂业务最终需要可维护的代码。这条判断仍然有价值，但不能顺势推出“设计器没有用了”。真正应该避免的是，让设计器承担它不擅长的全部复杂度，或者让编程工具重新发明系统已经有的每一个控件。
▲ 同一报销表单的发起页，左侧填写、右侧选择审批人。这是提交前界面，不是审批完成记录。
页面能配置，业务责任不能含糊
以报销为例，字段名称、排列顺序和说明文字，主要影响使用体验。用配置维护，业务人员能直观看到变化，开发者也不必为每次文案修改重新拼页面。
金额和预算则不同。“金额是数字”只是输入约束；“允许报多少、占用哪个预算、被退回后是否释放占用”，才是业务规则。把这些判断散落在页面脚本里，即使界面生成得很快，也会给后续维护留下难题。
一种可行的职责划分是：界面负责及时提示，服务端负责最终判断；流程负责谁在什么时候处理，业务模块负责处理后的状态与结果。
这不是限制低代码，而是让配置更有价值。配置的作用范围越明确，团队越敢复用。相反，一个看不清副作用的脚本按钮，即使能拖到页面上，也很难放心交给另一个项目使用。
把同一个报销需求分开看，三种做法的差别会清楚得多：
| 需求变化 | 只用配置时要看什么 | 使用业务代码时要做什么 |
|---|---|---|
| 增加说明、调整布局 | 已有组件能否表达 | 复用现成组件，不重复造轮子 |
| 增加明细计算 | 公式范围和数据类型是否足够 | 实现并验证计算规则 |
| 接入预算占用 | 是否有稳定的业务接口 | 明确占用、释放和异常处理 |
| 改变审批路径 | 模型条件和变量是否匹配 | 提供准确的业务变量与结果处理 |
这里没有规定“复杂需求一律不能配置”。如果平台已经提供成熟的预算接口，配置当然可以调用它。关键是预算规则有明确的实现和维护责任，而不是在三个页面分别写出三个版本。
AI Coding应该补在什么位置
最值得交给编程工具的任务，通常不是“再写一个输入框”，而是把新的业务差异接到已有规则里。
例如给现有申请增加一种费用类型，需要一起考虑字段、接口、校验、字典、查询和测试。单独生成一个漂亮页面只覆盖其中一段；如果工具能按现有目录、组件和接口约定组织修改，才更接近一次可交付的开发工作。
这里的上下文不能只有一句“做一个报销系统”。至少要给出已有参考单据、字段含义、状态变化、接口约定与验收条件。对于审批业务，还需要明确流程标识、附件处理和审批详情怎样回显。
编程工具可以协助完成这些修改，但责任不能随着生成按钮一起外包：修改了哪些文件、是否影响旧单据、失败时如何处理，仍要通过代码审查和实际操作核对。
因此，我更看重的组合是：低代码缩小重复建设范围，AI Coding帮助处理剩余的业务差异，已有平台提供共同的运行基础。
可以把给编程工具的任务改成下面这样。它是一份任务拆分示例，不是本次已完成开发的记录：
在现有报销模块中增加“项目费用”类型。 先读取现有表单、接口与服务端校验，列出复用点。 复用项目选择组件和现有附件能力，不另建一套页面框架。 区分草稿保存与正式提交需要满足的条件。 若涉及预算，先确认现有接口及失败后的处理方式。 列出本次修改范围、兼容旧记录的方法和验证步骤。 没有实现依据的部分先标明，不用假接口冒充已接通。这段任务的价值，在于把“生成一个东西”变成“把一个变化接入现有系统”。开发者能审查，测试人员知道验什么，下一位维护者也知道规则在哪里。
配置与代码之间，需要留一扇真正的门
两种能力放在同一个产品里，还不够。如果低代码应用有自己的账号、权限和数据，定制应用又重建一遍，那么使用者依旧要在两套系统之间来回切换。
在实现层面，一个很直接的连接点是流程入口。下面是当前前端选择流程时的分流逻辑摘录，省略了最近使用记录维护：
if(row.formType===BpmModelFormType.CUSTOM){if(row.formCustomCreatePath){awaitrouter.push({path:row.formCustomCreatePath,});}else{message.error('流程定义中未配置业务表单路径');}return;}if(!row.key){message.error('流程定义缺少标识，无法发起');return;}awaitopenProcessFormCreate({processDefinitionKey:row.key});这段代码没有复杂算法，却表达了重要的产品选择：业务页面可以有自己的实现，流程入口不必因此再造一套。使用者选择要办的事，系统根据表单类型进入对应页面。
设计器这一侧也并非只保存一张“画好的页面”。下面的字段编码函数，会读取设计规则、复制配置、处理动态默认值，然后序列化保存：
exportfunctionencodeFields(designerRef:any){construle=designerRef.value.getRule();constfields:string[]=[];rule.forEach((item:any)=>{constencodedRule=cloneDeep(item);stripDynamicSelectorDefaultValue(encodedRule);fields.push(formCreate.toJson(encodedRule));});returnfields;}为什么需要处理默认值？例如部门选择器希望默认当前申请人的部门，就不能把设计时维护人员的部门永久写进配置。配置和代码的结合，往往体现在这种细节里：画布负责表达规则，运行时还得正确解释规则。
设计配置因此也值得当成正式的开发产物管理。字段标识、数据类型、接口引用发生变化，都会影响正在使用的业务。能拖拽，不代表可以跳过版本与回归验证；能由工具修改，也不代表可以绕过审核。
真正体现差异的，是页面背后的业务动作
再看另一种表单：用印申请。它需要选择印章、区分现场用印与外借，并记录预计用章及归还时间。这些字段与报销不同，业务责任也不同。
▲ 已有演示用印单的审批中详情，展示自定义业务页面与流程状态如何并列呈现；它不是前面报销单的后续步骤。
表面上，“用章方式”只是一个选项。真正决定开发边界的，是用户选了“外借”以后发生什么。
当前用印提交逻辑里，对外借方式调用时间冲突检查。这个检查还要考虑同一印章、申请时间区间以及已有单据状态。它的职责显然超过了一个下拉框：
// 摘自提交逻辑：外借方式才进入时间冲突检查if(saveReqVO.getUseMode()!=null&&saveReqVO.getUseMode()==2){validateTimeConflict(saveReqVO);}这不是把整套冲突处理压成四行，也不是并发安全的证明。它说明的是：界面收集的业务选择，需要在服务端触发对应规则。是否允许占用、如何处理同时提交，还要结合完整实现和测试判断。
对于这样的需求，低代码可以继续承担布局、输入和部分联动；AI Coding可以协助梳理、实现或修改业务规则；审批引擎负责流程推进。三者各有工作，没有必要互相取代。
▲ 前面报销流程的配置预览：两级审批均为发起人自选。流程图说明处理顺序，报销金额是否合理、预算如何变化，仍是另一层业务责任。
从数据关系上理解，也不必把一切塞进一张“万能表”：表单配置描述字段怎样呈现，业务数据记录发生了什么，流程实例记录这件事走到了哪里。自定义业务单还需要把单据标识与流程实例关联起来，才能从详情追溯办理进度。
这些关系明确之后，工具选择反而简单了。适合配置的地方继续配置，必须编码的地方有稳定接口，不让使用者承担两种开发方式之间的割裂。
“全都要”，也要知道什么时候少用一点
如果只是短期收集信息，已有表单组件足够，直接配置往往更轻。此时硬加一套定制服务，可能增加部署和维护工作。
如果是长期使用的核心业务，涉及多模块数据、复杂操作和特定体验，保留可审查的业务代码会更有空间。但有源码也不等于维护容易：组件、接口与状态约定一旦各写各的，代码越多，理解成本也可能越高。
还有一种常见情况：团队已经有成熟业务模块，只想增加一个字段或调整一个规则。这时应先找原来的扩展点，而不是因为有了新工具就重做整套系统。
我会用四个问题决定怎么组合：谁来改、多久改一次、改错影响多大、下一位维护者能不能找到规则。布局调整与预算扣减的答案通常不同，开发方式也就不必相同。
对软件团队而言，更值得积累的是可复用组件、明确的业务接口、可靠的交付约定。它们既能让低代码配置有边界，也能让AI Coding获得有效上下文。工具换代时，这些积累依然有用。
低代码和AI Coding不必争一个唯一入口。把界面配置、业务规则和流程处理各自安排好，团队才有机会同时获得可见的开发效率和后续修改的空间。
