用 CodeBuddy 在 ruoyi-vue-pro 上快速搭建业务模块，效率提升 3 倍实战分享

一、背景介绍

最近在基于 ruoyi-vue-pro（v2026.08-snapshot，Java 17 + Spring Boot 3.5 + Vue3 + TypeScript）开发一个地质灾害管理平台，需要在原有框架上新增灾害信息管理、监测点管理、预警记录等业务模块。

如果纯手工写，每个模块从数据库建表 → 后端 CRUD → 前端页面，至少要 2-3 天。这次尝试用 CodeBuddy 辅助开发，把单个模块的开发周期压缩到了半天。

二、开发环境

三、实战第一步：用 CodeBuddy 快速生成后端代码

3.1 描述需求，让 CodeBuddy 生成实体类

在 CodeBuddy 对话框中输入：

帮我基于 ruoyi-vue-pro 的项目结构，创建一个地质灾害隐患点管理的实体类 DisasterPoint，字段包括：隐患点名称、隐患点类型（滑坡/崩塌/泥石流/地面塌陷）、经度、纬度、详细地址、威胁户数、威胁人数、风险等级（低/中/高）、监测状态（正常/异常/预警）、备注。遵循 yudao 框架的 BaseDO 基类和 @TableName 注解规范。

CodeBuddy 很快生成了完整的实体类代码，自动继承了 BaseDO，加上了 @TableName("disaster_point") 注解，字段命名也遵循了驼峰转下划线的规范。

心得：描述需求时把框架规范说清楚（比如"继承 BaseDO""遵循 yudao 框架"），生成的代码基本不需要二次修改，直接就能用。

3.2 生成 Controller / Service / Mapper

继续在对话中输入：

基于上面的 DisasterPoint 实体，帮我生成完整的 Controller（含分页查询、详情、新增、修改、删除接口）、Service 接口及实现类、Mapper 接口及 XML。遵循 yudao 的多层级架构（controller/admin + service + dal/mysql）。

CodeBuddy 一次性生成了以下文件结构：

yudao-module-system/
└── src/main/java/cn/iocoder/yudao/module/system/
    ├── controller/admin/disasterpoint/
    │   ├── DisasterPointController.java
    │   ├── vo/
    │   │   ├── DisasterPointPageReqVO.java
    │   │   ├── DisasterPointSaveReqVO.java
    │   │   └── DisasterPointRespVO.java
    ├── service/disasterpoint/
    │   ├── DisasterPointService.java
    │   └── DisasterPointServiceImpl.java
    └── dal/mysql/
        ├── DisasterPointMapper.java
        └── xml/DisasterPointMapper.xml

心得：一次生成整个 CRUD 链路，比手敲快了至少 5 倍。关键是 VO 对象的分页查询参数、保存参数、返回参数都自动拆分好了，符合 yudao 框架的规范。

四、实战第二步：前端页面开发

4.1 生成 API 接口层

在 CodeBuddy 中输入：

帮我基于上面的后端接口，在 yudao-ui-admin-vue3 前端项目中生成对应的 API 模块。路径放在 src/api/system/disasterpoint/index.ts，包含 getPage、get、create、update、delete 五个方法，使用 request 工具方法，遵循项目现有的 API 文件风格。

生成的代码自动使用了项目中的 request 封装，接口路径也正确拼接了 /admin-api/system/disaster-point 前缀。

4.2 生成 Vue 列表页面

帮我生成一个地质灾害隐患点管理的 Vue3 页面，放在 src/views/system/disasterPoint/index.vue。包含：搜索表单（名称、类型、风险等级、监测状态）、操作按钮（新增/导出）、el-table 列表展示、分页组件、新增/编辑弹窗表单。使用 Element Plus 组件，遵循 yudao 前端的页面结构。

CodeBuddy 生成了完整的页面，包含以下功能：

• 顶部搜索栏：隐患点名称、类型下拉、风险等级下拉、监测状态下拉
• 工具栏：新增、导出、批量删除按钮
• 表格列：序号、名称、类型（标签展示）、经纬度、威胁户数/人数、风险等级（颜色标签）、监测状态（颜色标签）、操作列
• 分页组件
• 新增/编辑弹窗：表单校验、类型选择、经纬度输入

心得：生成的前端代码直接符合 yudao 前端的 ContentWrap + Search + Table 组件规范，几乎零修改就能跑起来。关键是让它参考"项目现有风格"，这样不会偏离框架约定。

五、实战第三步：菜单配置与路由注册

在 yudao 框架中，新增模块还需要配置菜单和权限。我问 CodeBuddy：

我在 ruoyi-vue-pro 中新增了地质灾害隐患点管理模块，需要配置菜单和权限。帮我写 SQL 脚本：在系统菜单表中插入"地质灾害管理"一级菜单和"隐患点管理"二级菜单，包含查询、新增、修改、删除、导出五个按钮权限。

CodeBuddy 生成了标准的菜单插入 SQL，包含 system_menu 表的 INSERT 语句，权限标识符也遵循了 system:disaster-point:query 的命名规范。

六、遇到的坑与解决方案

坑1：CodeBuddy 生成的 Mapper XML 路不对

生成的 XML 放在了 dal/xml/ 下，但 yudao 框架默认扫描 dal/mysql/xml/。解决方法是明确告诉 CodeBuddy：

Mapper XML 文件请放在 dal/mysql/xml/ 目录下，与 Mapper 接口同包名。

重新生成后路径正确，MyBatis-Plus 正常扫描到了 XML。

坑2：前端字典数据未关联

隐患点类型和风险等级应该用数据字典，但 CodeBuddy 初始生成时用了硬编码的 option。追问一句：

隐患点类型和风险等级请改用 yudao 的数据字典，字典类型分别为 disaster_point_type 和 disaster_risk_level。下拉选项从 useDict 获取。

修正后代码使用了 DICT_TYPE_TO_LABEL 和字典组件，符合框架规范。

坑3：分页 VO 字段名不匹配

后端返回的 respVO 中经纬度字段叫 longitude/latitude，但前端期望 lng/lat。这个问题 CodeBuddy 自己没发现，需要手动对齐前后端字段名。建议在生成时同时给出前后端字段映射表。

七、效率对比

效率提升约 3-5 倍，模块越标准、CRUD 为主的场景效果越明显。

八、使用技巧总结

1. 说清框架规范：每次提问时带上"遵循 yudao 框架""继承 BaseDO"等关键词，生成的代码契合度更高
2. 分步生成：先生成实体 → 再生成后端 CRUD → 最后生成前端，每步验证后再继续，避免一次性生成太多代码出错后难定位
3. 善用追问：发现不满足需求时不要重写，直接追问修正（比如"改用数据字典""调整 XML 路径"），CodeBuddy 会在原代码基础上修改
4. 字段对齐：后端 respVO 和前端字段名最好在生成前就约定好，减少联调时的字段名不匹配问题
5. 参考现有代码：让 CodeBuddy "参考项目中已有的 xxx 模块的代码风格"，生成结果会更贴合项目实际规范

九、总结

CodeBuddy 在 ruoyi-vue-pro 这类规范化的快速开发框架上表现很好，尤其是 CRUD 模块生成、前端页面搭建这类重复性高的工作，节省了大量时间。对于业务逻辑复杂、非标准模式的代码，还是需要人工审查和调整。

建议初次使用的同学先从一个简单的 CRUD 模块入手，熟悉 CodeBuddy 的交互节奏后，再逐步尝试更复杂的业务场景。

本文基于 ruoyi-vue-pro v2026.08-snapshot 实际开发体验撰写，CodeBuddy 版本为 2026.09 更新。

#WorkBuddy #CodeBuddy #ruoyi-vue-pro #SpringBoot #Vue3 #AI编程