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