AI 原生代码不是“让大模型写 CRUD”：企业管理系统的 4 层协作方法论

🌐 文档地址：http://ruoyioffice.com | 📦 源码1：https://gitcode.com/zhouzhongyan/ruoyi-office-vben.git | 📦 源码2：https://gitcode.com/zhouzhongyan/ruoyi-office.git | 📦 源码3：https://github.com/yuqing2026/ruoyi-office.git | 💬 微信：17156169080（备注「RuoYi Office」）

AI 编程真正有价值的地方，不是生成一个看起来能跑的 CRUD，而是把企业系统里的重复工程劳动交给 AI，把业务判断、架构边界、权限安全、流程一致性和验收标准留给人。企业系统越复杂，越不能把 AI 当“许愿机”，而要把它放进一套可审查、可复用、可回滚的工程方法论里。

AI 原生代码交付流程 - 方法论全景

▲ AI 原生代码交付不是跳过工程，而是把需求拆解、源码生成、流程编排、多端验收和运营反馈放进同一个闭环

引言：为什么很多 AI 生成系统只能停在 Demo

过去一年，很多团队已经试过让 AI 写代码。

最初的体验通常很好：输入“帮我做一个客户管理页面”，几分钟后就有表格、搜索框、新增弹窗和接口调用。再输入“帮我加导出”，AI 也能补上按钮和 API。

但到了企业系统，问题会很快出现：

数据库字段和业务术语对不上
后端接口缺权限校验
前端表单只管提交，不管流程状态
移动端无法复用 PC 端体验
审批通过后没有业务回调
AI 改了一个文件，却漏掉另外 5 个相关文件
Demo 能跑，但无法进入长期维护

这不是 AI 不行，而是方法错了。

企业系统不是“页面集合”，而是“业务闭环集合”。如果没有明确的工程约束，AI 只会帮你更快地生成技术债。

一、AI 原生代码的第一原则：先建模，再生成

企业管理系统的开发顺序不能是“先画页面”。

应该先回答 6 个问题：

问题	例子	影响范围
单据是什么	用印申请、资产入库、合同审批	数据表、编号、权限、流程
状态有哪些	草稿、审批中、已通过、已拒绝、已撤回	前端按钮、后端校验、移动端展示
谁能操作	发起人、部门负责人、行政、财务	RBAC、数据权限、节点权限
流程怎么走	会签、或签、退回、加签、归还节点	Flowable、流程变量、任务按钮
审批后做什么	生成资产卡片、扣减库存、创建应收	Service 回调、事务、幂等
移动端要不要做	待办、详情、审批、发起	UniApp 页面、API 复用、路由映射

AI 最适合在这些问题被明确后开始工作。

如果直接让 AI “生成一个审批模块”，它会按通用经验补齐 CRUD；如果先告诉它业务对象、状态、流程、字段、权限和已有项目规范，它就能沿着工程结构生成更接近生产级的代码。

二、4 层协作方法论

2.1 业务层：人负责边界，AI 负责展开

业务层最忌讳“让 AI 猜”。

比如“资产入库”听起来简单，但真实系统至少要明确：

入库单是否走审批
审批通过后是否生成资产卡片
一条明细数量为 5 时，是生成 1 张卡片还是 5 张卡片
单价、原值、净值、折旧起始日期怎么处理
资产来源、供应商、验收信息是否要记录
已审批单据是否允许删除

人要做的是把这些边界讲清楚。

AI 要做的是把边界展开为：

数据表字段
Java 实体和 VO
Mapper 查询
Service 事务
Controller 接口
TypeScript 类型
Vue 表格和表单
UniApp 移动端页面

这就是 AI 原生代码的第一个关键点：人不再手工铺满所有重复文件，但必须定义业务判断。

2.2 工程层：用项目规范约束 AI 输出

没有规范的 AI 输出，会像一群风格不同的外包同时改项目。

RuoYi Office 这类项目必须给 AI 明确约束：

约束	示例
后端包名	`cn.iocoder.yudao`
接口前缀	`/admin-api/{module}/...`
前端 API 路径	`apps/web-antd/src/api/{module}/{feature}/index.ts`
前端页面路径	`apps/web-antd/src/views/{module}/{feature}/index.vue`
移动端 API	`ruoyi-office-uniapp/src/api/{module}/...`
流程标识	使用 `processDefinitionKey` 显式绑定
权限命名	`module:feature:action`
前端组件	`Page`、`useVbenVxeGrid`、`TableAction`、`useVbenModal`

AI 不是不能写企业代码，而是不能在没有上下文的情况下写企业代码。

一旦规范稳定，AI 可以非常高效地完成“按模式复制并适配”的工作。

2.3 流程层：审批不是状态字段，而是业务驱动器

很多系统把流程做成一个 status 字段：0 草稿、1 审批中、2 通过、3 拒绝。

这只能解决展示问题，解决不了业务闭环。

企业审批真正要处理的是：

发起流程时构造流程变量
流程实例与业务单据绑定
审批状态实时回写
审批通过触发业务动作
审批拒绝后允许修改重提
移动端能根据流程定义展示对应业务详情

RuoYi Office 后端通过 FlowBillService 这类接口，把流程状态和业务逻辑显式挂钩。

java

String processInstanceId = processInstanceApi.submitProcessInstance(
        startUserId,
        new BpmProcessInstanceCreateReqDTO()
                .setProcessDefinitionKey(AssetBillTypeEnum.ASSET_RECEIVE.getProcessDefinitionKey())
                .setVariables(variables)
                .setBusinessKey(String.valueOf(id))
).getCheckedData();

receive.setProcessInstanceId(processInstanceId);
receiveMapper.updateById(receive);
return id;

这段代码里有三个关键点：

processDefinitionKey 明确绑定业务流程
variables 把业务字段传给流程条件和审批人计算
businessKey 把流程实例和业务单据绑定起来

这比“配置一个审批按钮”更重，但它能承载真实企业系统。

2.4 验收层：AI 输出必须经过多端闭环验证

AI 生成代码后，不能只看页面能不能打开。

企业系统至少要做 5 类验收：

验收项	检查内容
后端接口	权限、参数校验、事务、异常、分页、导出
Web 页面	列表、搜索、表单、详情、按钮权限、字典显示
移动端	待办、详情、发起、审批、返回刷新、弱网提示
流程	发起、审批、拒绝、撤回、回调、状态同步
数据	主子表一致性、幂等、历史数据、删除限制

AI 可以帮忙写测试、生成检查清单、解释报错，但最终验收标准必须由团队定义。

三、RuoYi Office 的 AI 原生代码架构

RuoYi Office AI 原生代码架构 - 分层图

▲ RuoYi Office 的关键价值在于把 Web、移动端、业务模块、Flowable 流程、Spring AI 和工程基础设施放在一套源码体系内

RuoYi Office 适合 AI 协作开发，原因不是“用了 AI 模块”，而是它的工程结构足够清晰。

层级	主要内容	AI 协作价值
体验层	Vue3 + Vben Admin、UniApp、工作台、审批中心	AI 可按既有组件模式生成页面
业务层	OA、HRM、CRM、ERP、资产、合同、项目	AI 可参考同类模块做增量开发
流程层	Flowable、BPMN、流程变量、业务回调	AI 可定位流程与业务单据关系
智能层	Spring AI、多模型、知识库、AI 工作流、MCP	AI 能力不是外挂，而是业务模块之一
工程层	Spring Boot、Java 17、MyBatis、RBAC、多租户	AI 输出受稳定架构约束

这种架构对 AI 友好，因为每个业务概念都有“源码落点”。

低代码平台的问题在于，很多业务语义只有运行时才知道；RuoYi Office 这类原生工程则把语义尽量放在可读源码里。

四、代码证据：移动端流程入口如何绑定业务

移动端不是把 PC 页面缩小，而是重新组织审批场景。

RuoYi Office 在 UniApp 里通过 bpm-menu-config.ts 把流程定义、权限、移动端创建页和移动端详情组件显式绑定。

typescript

{
  key: 'oaSealApply',
  name: '用章',
  icon: 'edit-outline',
  iconColor: '#9333ea',
  permission: 'bpm:oa-seal-apply:create',
  processDefinitionKey: 'oa_seal_apply_bill',
  mobileCreatePath: '/pages-oa/seal/create/index',
  mobileViewComponent: 'SealApplyDetail',
  forceDetailTaskNames: ['申请人归还印章'],
},
{
  key: 'oaMeetingRoom',
  name: '会议室预定',
  icon: 'secured',
  iconColor: '#16a34a',
  permission: 'bpm:oa-meeting-room-apply:create',
  processDefinitionKey: 'oa_meeting_room_apply',
  mobileCreatePath: '/pages-oa/meeting-room/create/index',
  mobileViewComponent: 'MeetingRoomBookingDetail',
}

这段配置比普通菜单配置更重要。

它解决了三个问题：

移动端知道某个流程应该打开哪个业务详情
权限与流程入口一致，不会出现“PC 能发起、APP 找不到”的断裂
特殊节点可以强制展示业务详情，比如“申请人归还印章”

这就是原生代码的优势：AI 可以读懂这个结构，继续帮你扩展新业务流程。

五、代码证据：Web 与移动端共享同一套后端语义

Web 端 API 以 TypeScript 类型描述业务对象。

typescript

export namespace AssetTransferApi {
  export interface TransferVO {
    id?: number;
    billCode?: string;
    transferDate?: string;
    transferReason?: string;
    fromDeptId?: number;
    fromDeptName?: string;
    toDeptId?: number;
    toDeptName?: string;
    processInstanceId?: string;
    processStatus?: number;
    fileUrls?: string[];
    items?: Item[];
  }
}

export function submitTransfer(data: AssetTransferApi.TransferVO) {
  return requestClient.post<number>('/asset/transfer/submit', data);
}

移动端审批接口同样围绕流程实例和任务处理。

typescript

export function getTaskTodoPage(params: PageParam) {
  return http.get<PageResult<Task>>('/bpm/task/todo-page', params)
}

export function approveTask(data: {
  id: string
  reason: string
  signPicUrl?: string
  nextAssignees?: Record<string, number[]>
}) {
  return http.put<boolean>('/bpm/task/approve', data)
}

export function rejectTask(data: { id: string, reason: string }) {
  return http.put<boolean>('/bpm/task/reject', data)
}

这说明 RuoYi Office 的多端不是“各做各的”，而是同一套业务对象、流程实例和任务接口在不同端呈现。

AI 在这种代码库里工作，会比在封闭低代码平台里舒服得多：它可以读 API 类型、读页面调用、读后端实现，然后跨端修改。

六、真实界面：AI 原生代码最终要落到业务体验

RuoYi Office Web 工作台 - 待办任务与模块入口

▲ Web 端工作台不是简单首页，而是把待办、已办、OA、HRM、CRM、ERP、项目、资产等能力聚合到一个办公入口

RuoYi Office 移动端工作台 - 移动首页与业务入口

▲ 移动端首页展示考勤打卡、公告、工资信息、企业云盘和任务入口，说明三端统一必须从 API、权限、流程和页面体验一起设计

AI 原生代码的最终目标不是“代码写得像人”，而是“系统真的能服务业务”。

比如上面的两个截图，其实体现了几个底层能力：

统一登录认证
统一用户、部门、岗位信息
统一流程任务中心
统一业务单据状态
统一文件和云盘能力
PC 与移动端共同承载企业办公

这些能力在代码层面是分散的，但在用户体验里必须是一体的。

这也是为什么企业系统不能只靠页面生成器。

七、AI 原生代码开发的推荐工作流

实际开发中，可以按 8 步走：

步骤	产物	AI 参与方式
1. 业务访谈	场景、角色、单据、流程	帮忙整理问题清单
2. 数据建模	表结构、字段、索引、枚举	生成 DDL 初稿
3. 后端骨架	DO、VO、Mapper、Service、Controller	按项目模式生成
4. 流程接入	processDefinitionKey、流程变量、回调	生成接入代码并解释风险
5. Web 页面	API、列表、表单、详情	按 Vben 模式生成
6. 移动端	API、列表、详情、审批入口	按 UniApp 模式生成
7. 测试审查	单元测试、接口测试、验收清单	补测试和查边界
8. 文档沉淀	开发说明、运维说明、博客文章	生成结构化说明

这里有一个经验：

AI 最适合做“有样板的扩展”，不适合替团队做“没有边界的判断”。

RuoYi Office 已经有大量业务模块样板，所以当新增资产、合同、项目、HRM 流程时，AI 可以参考既有模式快速复制并适配。

八、AI 原生代码团队要避免的 5 个坑

8.1 不要让 AI 直接改大范围文件

企业系统里跨模块依赖很多。

应该让 AI 先读上下文、列出影响范围，再分步骤修改。一次性“重构整个审批系统”很容易出事故。

8.2 不要接受看起来很完整但无法解释的代码

AI 生成代码后，要让它解释：

为什么这样设计表结构
为什么这个字段可空
为什么这个方法需要事务
为什么审批通过后要做幂等判断
为什么移动端路由这样绑定

解释不清楚的代码，不要轻易合并。

8.3 不要忽略权限和数据隔离

企业系统最容易被 AI 漏掉的不是页面，而是权限。

每个接口至少要检查：

是否有 @PreAuthorize
是否存在租户隔离
是否需要部门数据权限
是否有导出权限
移动端是否复用同样权限

8.4 不要把 AI 当测试替代品

AI 可以生成测试，但不能替代测试。

尤其是流程系统，要真实跑：

发起
审批
拒绝
撤回
加签
移动端审批
业务回调
历史单据查看

8.5 不要让低代码配置和原生代码割裂

如果项目中同时使用动态表单或低代码能力，必须明确边界。

推荐原则：

核心业务逻辑放原生代码
灵活字段和轻量表单可以配置化
配置变更也要版本化
AI 能读到的文档和导出结构要同步维护

九、为什么 RuoYi Office 适合做 AI 原生代码底座

RuoYi Office 的价值，不只是模块多，而是它给 AI 协作提供了“稳定地形”。

能力	对 AI 协作的意义
Spring Boot 3.5 + Java 17	后端结构清晰，AI 容易理解分层
Vue3 + TypeScript	前端类型明确，跨文件修改更稳
UniApp 移动端	可以把 PC 业务扩展到移动审批
Flowable 7	流程不是状态字段，而是标准引擎
多业务模块	AI 可参考大量同类模块模式
Spring AI	企业 AI 能力能落在业务平台内部
源码开放	可审查、可二开、可迁移

这类项目会越来越适合未来的 AI 开发方式。

因为 AI 不怕代码多，它怕语义混乱。代码多但结构清楚，AI 能读；配置少但语义隐藏，AI 反而难帮忙。

十、快速体验

端	地址	推荐体验
Web 端	http://localhost:5800/	工作台、流程中心、OA/HRM/CRM/ERP 模块入口
移动端	http://localhost:9000/	首页、审批、待办、业务申请、云盘

源码与文档：

类型	地址
文档	http://ruoyioffice.com
Web 前端	https://gitcode.com/zhouzhongyan/ruoyi-office-vben.git
Java 后端	https://gitcode.com/zhouzhongyan/ruoyi-office.git
GitHub	https://github.com/yuqing2026/ruoyi-office.git

参考资料

Stack Overflow 2025 Developer Survey：开发者对 AI 工具的采用、信任和调试成本，见官方发布与 AI 章节。
GitHub Universe 2024：AI-native developer experience、Copilot 多模型和组织采用，见 GitHub 官方发布。
McKinsey 2025 State of AI：企业 AI 使用广泛，但规模化仍需组织和流程支撑，见 McKinsey 2025 State of AI。

结语

AI 原生代码不是让 AI 替你随便写一个系统，而是让 AI 进入一套成熟工程流程：按业务建模、按项目规范生成、按流程机制集成、按多端体验验收。

低代码把“写代码”这件事藏起来，AI 原生代码则把“重复写代码”这件事交给 AI，同时保留源码透明、架构清晰和长期可维护。

RuoYi Office 的方向正是如此：用 Spring Boot、Vue3、UniApp、Flowable 和 Spring AI 搭出一个企业管理系统底座，让 AI 帮团队更快扩展业务，而不是把业务锁进看不见的配置黑箱。

💡 想要体验 RuoYi Office 的完整能力？
🌐 在线文档：http://ruoyioffice.com
📦 源码仓库：GitCode 前端 | GitCode 后端 | GitHub
💬 技术咨询：添加微信 17156169080，备注「RuoYi Office」

AI 原生代码不是“让大模型写 CRUD”：企业管理系统的 4 层协作方法论 ​

引言：为什么很多 AI 生成系统只能停在 Demo ​

一、AI 原生代码的第一原则：先建模，再生成 ​

二、4 层协作方法论 ​

2.1 业务层：人负责边界，AI 负责展开 ​

2.2 工程层：用项目规范约束 AI 输出 ​

2.3 流程层：审批不是状态字段，而是业务驱动器 ​

2.4 验收层：AI 输出必须经过多端闭环验证 ​

三、RuoYi Office 的 AI 原生代码架构 ​

四、代码证据：移动端流程入口如何绑定业务 ​

五、代码证据：Web 与移动端共享同一套后端语义 ​

六、真实界面：AI 原生代码最终要落到业务体验 ​

七、AI 原生代码开发的推荐工作流 ​

八、AI 原生代码团队要避免的 5 个坑 ​

8.1 不要让 AI 直接改大范围文件 ​

8.2 不要接受看起来很完整但无法解释的代码 ​

8.3 不要忽略权限和数据隔离 ​

8.4 不要把 AI 当测试替代品 ​

8.5 不要让低代码配置和原生代码割裂 ​

九、为什么 RuoYi Office 适合做 AI 原生代码底座 ​

十、快速体验 ​

参考资料 ​

结语 ​

AI 原生代码不是“让大模型写 CRUD”：企业管理系统的 4 层协作方法论

引言：为什么很多 AI 生成系统只能停在 Demo

一、AI 原生代码的第一原则：先建模，再生成

二、4 层协作方法论

2.1 业务层：人负责边界，AI 负责展开

2.2 工程层：用项目规范约束 AI 输出

2.3 流程层：审批不是状态字段，而是业务驱动器

2.4 验收层：AI 输出必须经过多端闭环验证

三、RuoYi Office 的 AI 原生代码架构

四、代码证据：移动端流程入口如何绑定业务

五、代码证据：Web 与移动端共享同一套后端语义

六、真实界面：AI 原生代码最终要落到业务体验

七、AI 原生代码开发的推荐工作流

八、AI 原生代码团队要避免的 5 个坑

8.1 不要让 AI 直接改大范围文件

8.2 不要接受看起来很完整但无法解释的代码

8.3 不要忽略权限和数据隔离

8.4 不要把 AI 当测试替代品

8.5 不要让低代码配置和原生代码割裂

九、为什么 RuoYi Office 适合做 AI 原生代码底座

十、快速体验

参考资料

结语