# 低代码和AI Coding怎么选？两种审批开发路径拆给你看

标准申请、字段和审批规则经常调整，优先考虑低代码；涉及主子表计算、业务状态限制和专用服务，再用AI Coding展开代码。企业项目可以两种都用，前提是每一条规则都有明确归属，而不是两边各存一套。

这个判断来自RuoYi Office的两次教学实践：一张采购申请通过表单配置发布；一张设备维修单通过Cursor Agent开发，再接入Flowable。两者都跑到了实际审批结果，遇到的问题却很不一样。

![低代码与AI Coding的开发职责对照](https://developer.qcloudimg.com/http-save/yehe-12798805/e2d6029b7dc6f00fd0d67cc89e6262e6.png)

*主图：两种开发方式，共用审批、权限、数据与验收要求。*

## 先把业务要求写出来，选择才有依据

采购申请的核心是“哪些字段、谁来审批”。教学案例配置六个业务字段，发布到独立表，金额不超过5000元走部门审核，超过5000元增加财务复核。后续再增加一个收货地点，检查旧单和新单是否分别按原版本展示。

设备维修申请的要求多了一层：主表下面有维修项目明细，数量乘单价得到小计，所有明细合成预算；可以先存不完整草稿，正式提交时必须校验；只能修改本人的可编辑单据；附件与审批中心需要共用业务对象。

两张页面都能画成“输入框加提交按钮”，但页面相似不代表实现成本相同。

| 要求 | 本次采购申请 | 本次设备维修单 |
|---|---|---|
| 数据组织 | 发布独立业务表 | 专用主表与明细表 |
| 主要变化 | 字段、节点、金额条件、版本 | 明细计算、状态限制、业务接入 |
| 开发产物 | 表单定义、流程定义与发布结果 | 前后端代码、SQL、菜单与流程模板 |
| 验收重点 | 条件边界与新旧表单 | 数据一致性与业务状态 |

这张表不是给所有低代码平台划能力上限。有的平台支持复杂明细和自定义服务。它比较的是当前项目已经验证的两条路线：**团队选型时，应该比较实际可交付能力，而不是比较两个名词的热度。**

## 低代码的价值，是让规则可以配置、发布和追溯

采购案例先配置表单，再发布独立表`bpm_f_tutorial_purchase_08`，随后让流程模型关联这份表单。字段定义、流程条件与用户权限分别配置，它们共同决定一张申请能否发起和走到正确的人。

![采购表单的真实配置预览](https://developer.qcloudimg.com/http-save/yehe-12798805/2a94642ca0ff15ba4a65e99a5f28fe64.png)

*[实测·历史教程] 表单预览展示输入方式；还需要发布和普通用户验证，才能判断是否可用。*

这里不把“拖完字段”当作完成。发布后用普通用户发起两张申请：5000元与5000.01元。前者只经过部门审核，后者增加财务复核，最终均完成审批。

一分钱的差异很有用：它能区分条件写的是“大于5000”还是“大于等于5000”。如果只用1000元和10000元测试，两种配置都可能得到看起来正确的结果。

![超过5000元的实际流程分支](https://developer.qcloudimg.com/http-save/yehe-12798805/53bd1e6586b3667bbae15b20a142be2b.png)

*[实测·历史教程] 金额条件要用边界两侧的数据检查，不能只看设计器里有没有画出两条线。*

接着在原表单上新增可选字段`deliveryLocation`，发布第二版，并发布关联流程。新申请1200元保存了收货地点，旧申请仍按第一版展示。数据库只读核对中，三张单据对应版本为1、1、2，流程状态均为2。

这正是标准业务适合配置的原因：变化集中在字段、条件与版本，平台能够承担重复建设。业务人员提出“加一个收货地点”，不必首先拆成Controller、Service和页面修改任务。

但这次实际验证只覆盖新增可选字段。删除字段、修改字段类型、历史金额重新计算，需要另外设计迁移规则，不能把一次成功的版本升级当成任意变更都安全。

## AI Coding接手的是业务实现，不是把截图翻译成代码

维修案例一开始就固定业务标识、主子表关系、草稿和提交规则，要求读取当前项目规范与近邻实现。已有的附件、单号、表格、权限和流程服务继续复用。

下面是按教学需求整理的输入骨架。它比“帮我写一个维修页面”多出的内容，主要是业务约束，而不是修饰词。

```text
业务对象：设备维修申请，主表关联多条维修明细。
草稿：允许未填完整；重开后应保留已保存内容。
提交：检查必填项、有效明细、数量和单价。
计算：服务端按数量×单价重算小计及总额。
身份：只允许制单人修改处于可编辑状态的申请。
集成：复用项目附件、单号、审批及独立详情组件。
产物：源码、DDL、菜单DML、流程模型与验证清单。
执行：先在隔离教学环境核验，不自动操作客户库。
```

这样得到的产物是可以继续维护的专用代码。教学实例使用`oa_tutorial_repair_bill`和明细表，由`billId`连接；附件通过单据类型与业务ID关联；流程实例ID另行保存，不能混用成业务主键。

![设备维修单主子表与金额效果](https://developer.qcloudimg.com/http-save/yehe-12798805/08fc864698249fcb27739c6323f0d2ea.png)

*[实测·历史教程] 两行维修项目分别为980元、300元，总预算1280元；明细与主表要一起保存和回显。*

真正影响交付的，是代码生成后仍然需要检查什么。本课补充了服务端制单人和状态校验，并验证“非制单人修改”和“已通过单据修改”均被拒绝，业务主表与明细没有变化。

审批中心还遇到过一次容易误判的故障：接口返回了明细，首次打开页面却显示空表。原因是表格尚未挂载，刷新操作没有生效。修复在本课组件里先设置数据选项，等待挂载后再刷新，没有修改全局组件兜底。

这两类问题分别说明，AI Coding的验收至少跨越两层：服务端是否守住规则，页面是否在实际生命周期里显示正确。生成代码数量和页面首屏效果，都不能代替它们。

## 两条路线最终要汇到同一个业务底座

低代码的表单和手写业务页面可以不同，但“谁能发起、谁能处理、数据属于谁、结束后如何回查”不能因此各自定义。

采购案例由已发布的表单与流程承接申请。维修案例则需要对齐流程Key、单据类型、发起路由和审批查看组件，再把业务主表ID传给流程。审批结束后，业务状态通过现有接入机制回写。

![维修申请完成后的真实结果](https://developer.qcloudimg.com/http-save/yehe-12798805/65e2876854d86bc52b2d3bc9841f5a0a.png)

*[实测·历史教程] 同一张维修单在部门负责人及三位财务成员办理后通过，金额、明细和附件继续对应原单。*

财务角色包含三个人，模板配置为依次审批。第一人点通过后，流程没有结束。这不是状态回写失败，而是后面还有两项任务。可见，无论选择哪种开发方式，业务人员仍然必须明确“多人都处理”还是“任意一人处理”。

如果想在一个项目里同时采用两条路线，可以先约定三个归属：表单定义由谁发布，业务规则由哪个服务负责，审批状态由哪个流程驱动。一个金额不能在设计器里算一遍、页面里算一遍、服务端又用另一种规则，最后没有人知道哪一个是正式结果。

也不要把两种方案都用在同一功能上当作“保险”。采购表单已经足够表达的规则，额外生成一套维护相同数据的页面和接口，反而增加同步与升级负担。

## 改需求时，按变化的性质决定下一步

企业项目不会停在首版。相比争论哪种方式更先进，下面这组判断更适合实际排任务。

| 新需求 | 优先检查什么 | 这两次案例给出的依据 |
|---|---|---|
| 增加收货地点 | 组件、存储、版本与旧单展示 | 采购第二版已经验证新增可选字段 |
| 改金额审批边界 | 表达式、候选人、发布定义 | 5000与5000.01走不同路线 |
| 添加多行计算规则 | 平台是否原生支持；服务端谁负责重算 | 维修单采用专用主子表服务 |
| 通过后触发库存或付款 | 业务服务、事务、重复执行与失败处理 | 两次教程均未验证，不可直接宣布具备 |
| 换一个开发工具 | 项目上下文、代码差异与验收方式 | 已有成功流程不会替新工具自动背书 |

其中第四行尤其容易被标题掩盖。“接上审批”与“审批后自动完成所有业务”相差很远。维修审批通过，只表示这次申请通过，并不意味着已经维修、扣减配件或支付款项。

将这些后续动作单独列成任务，反而有助于控制首版范围：先把申请和审核做完整，再决定哪些操作能够自动执行、失败如何恢复。不要让一个演示成功承担整个业务闭环的承诺。

## 宇擎建议：两种都要，但每种解决明确的问题

对于字段规范、审批为主、变更集中在配置层的申请，先走已经验证的低代码路线。验收时留住发布版本，至少测试一个条件边界、一个普通用户和一张升级前旧单。

对于需要专用计算、主子表结构、服务端状态限制的业务，采用AI Coding可以帮助展开项目代码，但必须提供已有组件和规则。先核验身份、金额、日期和持久化，再核验审批中心与最终回查，不能只对着管理员页面点一次提交。

如果团队无法解释业务数据和审批结果如何关联，就暂时不适合继续扩大自动生成范围。先用一张完整单据把规则理顺，往往比同时生成十个模块更有价值。

这两次教程没有做同需求、同团队、同环境的计时对照，因此本文不给出“快几倍”的结论。可以确定的是：采购配置验证了字段、分支与版本；维修开发验证了代码接入、问题修复与实际审批。**两种方式配合得好不好，最终看每次业务变化能否找到负责的配置或代码，并在同一条验收链上得到结果。**

标准申请、字段和审批规则经常调整，优先考虑低代码；涉及主子表计算、业务状态限制和专用服务，再用AI Coding展开代码。企业项目可以两种都用，前提是每一条规则都有明确归属，而不是两边各存一套。

低代码和AI Coding怎么选？两种审批开发路径拆给你看

用采购表单与设备维修单两个真实教学案例，比较低代码配置和AI辅助编码的适用边界、交付产物及验收方式。

人工智能

低代码适合字段和审批规则频繁调整的场景，AICoding适用于主子表计算、业务状态限制等复杂逻辑。企业项目可结合使用，但需明确规则归属，避免配置与代码双轨脱节。选型关键在验收能力，而非技术概念热度。

数据一致性

代码解释

数据库

路由

腾讯云双十一大促

weda

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

低代码和AI Coding怎么选？两种审批开发路径拆给你看-腾讯云开发者社区-腾讯云

低代码和AI Coding怎么选？两种审批开发路径拆给你看

低代码和AI Coding怎么选？两种审批开发路径拆给你看

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐