1. 项目缘起从“重复造轮子”到“AI提效”的思考作为一名有多年全栈开发经验的程序员我最近想给自己搭一个个人博客。这个念头其实由来已久一方面是记录技术心得另一方面也是想有个完全由自己掌控的技术自留地。一开始我的想法很“程序员”从零开始自己设计数据库、写后端API、搭前端页面用最熟悉的Spring Boot Vue 3再搞点花哨的动画效果。但转念一想这不就是典型的“重复造轮子”吗一个博客的核心功能——用户管理、文章CRUD、分类标签、评论——这些功能模块在任何一个成熟的后台管理系统里都是标配。于是我的目光很自然地投向了RuoYi-Vue。这个基于Spring Boot和Vue的前后端分离权限管理系统在Java圈子里几乎是无人不知。它那套成熟的后台管理框架拿来改造成一个博客后台简直是“专业对口”。但问题也随之而来虽然基础框架有了但博客业务相关的实体、接口、页面逻辑还是得一行行代码去敲。这工作量没个一两周根本下不来而且大部分时间都会耗在枯燥的增删改查和页面联调上。就在我对着RuoYi-Vue的代码仓库“望洋兴叹”时一个念头闪过为什么不试试让AI来当我的“结对编程”伙伴呢现在的大语言模型在代码生成、逻辑理解和上下文关联上已经非常强大了。如果我能清晰地告诉AI我的需求——“基于RuoYi-Vue的现有架构扩展一个博客模块”它能不能帮我完成从数据库设计到前端页面的绝大部分代码这个想法让我非常兴奋。这不仅仅是为了省时间更是一次对“AI辅助开发”工作流极限的探索。我想知道当经典的企业级开发框架遇上现代的AI生产力工具开发一个标准业务系统的效率能提升多少这就是本次“博客系统开发之旅”的初衷。2. 技术选型与整体架构设计2.1 为什么是 RuoYi-Vue AI选择RuoYi-Vue作为基底是基于多方面的考量。首先它提供了一个开箱即用的企业级开发脚手架集成了用户认证、权限管理、菜单路由、字典管理、操作日志等基础设施。这意味着我不需要从零开始处理Spring Security的配置、JWT令牌的签发与验证、基于角色的访问控制RBAC这些复杂且容易出错的部分。其次它的前后端分离架构清晰前端基于Vue 2和Element UI后端是经典的Spring Boot MyBatis技术栈非常主流社区资源和解决方案丰富。最重要的是它的代码结构规范模块化做得很好这对于AI理解上下文和生成符合项目风格的代码至关重要。而选择AI作为核心辅助工具则是为了验证一种新的开发范式。我使用的工具是Cursor Editor它深度集成了GPT-4等模型具备强大的代码补全、生成和对话能力。我的思路是将AI定位为“高级代码生成器”和“逻辑审查员”而不是完全替代我。由我来把控整体架构、业务边界和核心逻辑而将具体的、模式化的代码实现交给AI。例如设计好数据库表结构后让AI生成对应的MyBatis实体类、Mapper接口和XML文件定义好API接口的路径、参数和返回值后让AI生成Controller和Service层的骨架代码。2.2 博客系统核心模块设计在开始编码之前我花了大约半小时进行核心模块的梳理。一个博客系统抛开华丽的前端皮肤其核心数据模型并不复杂。我规划了以下几个核心实体博客文章BlogArticle核心实体包含标题、摘要、封面图、正文内容支持Markdown、发布状态、浏览量等字段。文章分类BlogCategory用于对文章进行归类支持多级分类。文章标签BlogTag与文章是多对多关系提供更灵活的内容组织方式。文章评论BlogComment支持对文章的评论设计上考虑嵌套回复父子评论和审核机制。在RuoYi-Vue的体系下我需要将这些实体无缝集成进去。这意味着数据层面在现有的ry数据库中新建blog_article、blog_category等表。后端层面在ruoyi-admin模块中新建对应的domain、mapper、service和controller包。前端层面在ruoyi-ui的views目录下新建blog目录并创建文章管理、分类管理等Vue组件。权限层面需要将博客相关的菜单、按钮权限集成到RuoYi的权限管理体系中。这个设计过程本身也是我向AI描述需求、进行“需求澄清”的过程。我会用自然语言把上述思考写成注释或对话为后续的代码生成提供清晰的上下文。3. AI辅助开发实战从零到一的完整流程3.1 第一步数据库设计与实体类生成我首先在项目的SQL脚本目录/sql下创建了一个blog_init.sql文件。我没有直接写完整的DDL语句而是先用注释描述表结构。-- 博客分类表 -- 字段分类ID主键分类名称父分类ID用于多级分类显示顺序状态0正常 1停用 -- 需要逻辑删除标志del_flag和RuoYi标准的创建者、创建时间等字段 -- 博客文章表 -- 字段文章ID主键文章标题摘要封面图URL正文内容longtext分类ID发布状态0草稿 1发布是否置顶浏览量。 -- 同样需要标准字段然后我将光标放在注释下方使用Cursor的指令或类似的AI生成功能输入提示词“根据以上注释生成完整的MySQL建表语句字段名使用下划线风格并添加必要的索引和注释。” AI在几秒钟内就输出了格式规范、包含所有字段、索引和InnoDB引擎设置的SQL语句。我检查了一遍确认符合RuoYi的命名规范如del_flag,create_by,create_time后直接执行了这些SQL。接下来是生成Java实体类。我导航到后端domain包打算新建一个BlogArticle.java。我直接在新文件中输入提示词“生成一个BlogArticle类对应blog_article表继承RuoYi的BaseEntity使用Lombok注解字段使用驼峰命名并添加Swagger注解。” AI瞬间就生成了近乎完美的实体类代码它正确地引用了BaseEntity为每个字段添加了TableField注解因为RuoYi默认集成了MyBatis-Plus并生成了对应的ApiModelProperty。我唯一手动调整的是为content字段明确指定了JDBC类型为LONGVARCHAR以确保长文本正确处理。实操心得在让AI生成代码时**提供尽可能明确的“上下文”和“约束”**是关键。直接说“生成一个文章类”效果很差但告诉它表名、继承的基类、使用的框架注解风格它就能产出几乎可直接使用的代码。这步的准确率高达95%极大节省了时间。3.2 第二步Mapper、Service与Controller的链式生成有了实体类后面的工作就形成了一条流水线。我首先创建BlogArticleMapper.java接口。我的提示词是“生成BlogArticle的MyBatis Mapper接口继承RuoYi框架的BaseMapper。” AI生成无误。然后是Mapper XML文件。在resources/mapper目录下新建BlogArticleMapper.xml我的提示词更加具体“生成对应的Mapper XML文件包含BaseResultMap定义以及根据文章标题、分类、状态进行分页查询的SQL片段查询条件要使用if test\...\动态SQL。” AI生成的XML文件结构清晰动态SQL条件也写得正确我只需要微调一下查询字段的顺序。Service层和Controller层的生成是效率提升最明显的部分。对于IBlogArticleService接口我提示“生成Service接口包含分页查询、根据ID查询、新增、修改、删除逻辑删除文章的方法声明。” 对于BlogArticleServiceImpl实现类我提示“生成实现类注入Mapper实现上述接口方法。新增和修改方法需要调用RuoYi的SecurityUtils获取当前用户名并设置createBy/updateBy。” AI不仅正确实现了业务逻辑还自动处理了RuoYi框架下的用户上下文代码风格与项目中原有的Service类高度一致。Controller层也是如此。我提示“生成BlogArticleController继承RuoYi的BaseController。提供分页查询列表、获取详细信息、新增、修改、删除接口。使用PreAuthorize注解保护新增、修改、删除接口权限字符串定义为‘blog:article:add’等。所有接口返回AjaxResult。” AI生成的Controller代码完全符合RuoYi的RESTful风格和权限控制规范。至此一个具备完整CRUD和分页查询功能的文章管理后端模块从数据库到API接口我只用了不到15分钟并且手动输入的代码极少大部分时间花在检查和微调上。3.3 第三步前端Vue组件与API集成后端API就绪后我转向前端。RuoYi-Vue的前端基于Vue 2和Element UI其管理页面的结构有很强的模式一个包含查询表单和操作按钮的顶部中间是一个表格展示数据底部是分页组件。我在src/views/blog目录下创建article/index.vue。我的提示词开始利用上下文“基于RuoYi-Vue的前端风格生成一个博客文章管理页面。包含以下要素1. 查询表单文章标题输入框、分类下拉选择、状态下拉选择。2. 操作按钮新增、修改、删除、导出。3. 表格列ID、标题、分类、状态、创建时间、操作编辑、删除按钮。4. 分页组件。使用Vue 2语法/api/blog/article作为API模块路径。”AI生成的Vue文件骨架非常完整模板部分直接复制了RuoYi经典的页面布局脚本部分包含了data、methods、created生命周期钩子等基本结构。但它生成的API调用方法是空的。这时我需要先创建API模块。在src/api/blog目录下创建article.js我的提示词是“生成article的API模块包含分页查询、获取详情、新增、修改、删除方法使用import request from ‘/utils/request’。” AI完美地生成了这些方法。然后我回到Vue文件将光标定位到getList方法内部给出指令“调用listArticleAPI方法传递查询参数和分页参数并将返回的数据赋值给this.list和this.total。” AI补全了具体的请求代码。我用同样的方式让AI补全了新增、修改、删除等操作对应的弹窗表单和数据提交逻辑。注意事项AI在前端组件生成时对组件间通信和复杂状态管理的理解有时会不够深入。例如在生成“新增/编辑”弹窗的代码时它可能会忘记在关闭弹窗后重置表单数据或清空编辑状态。这需要开发者手动检查和补充。我的经验是**让AI生成“模式化”的部分而由自己来编写和调试“交互逻辑”与“状态流转”**的部分。3.4 第四步菜单配置与权限打通最后一步是将我们新建的博客模块集成到RuoYi的菜单系统中。这需要修改后端的一个常量类和前端的路由配置。在后端我需要修改ruoyi-admin模块下的ShiroConfig类或类似的权限配置类为博客相关的接口路径添加匿名访问或权限规则。但更关键的是菜单SQL。我直接让AI生成插入语句“生成向sys_menu表插入博客管理菜单的SQL语句。一级菜单叫‘博客管理’图标‘blog’。其下子菜单有‘文章管理’指向/blog/article、‘分类管理’、‘标签管理’。菜单类型、排序号、可见状态、权限字符按RuoYi常规设置。” AI生成了一组可以直接在数据库中执行的INSERT语句。在前端路由配置是自动根据菜单生成的但我们需要确保src/views/blog下的Vue组件路径与菜单配置的组件路径如Blog/Article/index能正确映射。通常RuoYi的动态路由会自动处理但为了保险我检查了src/store/modules/permission.js中生成路由的逻辑确认其能正确解析我们新建的视图路径。4. 开发过程中的挑战与AI解决方案4.1 挑战一业务逻辑的“模糊地带”与AI的“臆想”在开发评论的嵌套回复功能时我遇到了第一个挑战。我的需求是评论表blog_comment有一个parent_id字段指向父评论前端需要以树形结构展示。我告诉AI“在Service层写一个方法根据文章ID查询所有评论并组装成树形结构列表返回。”AI生成的代码大致思路是对的先查询出所有平铺的评论列表然后通过递归或循环找出根评论parent_id为0再为每个根评论递归查找其子评论。但是它生成的递归算法在处理大量数据时可能存在性能问题N1查询的变体并且返回的DTO结构没有完全按照我的想法来。我的解决方案我没有直接采用AI的代码而是利用它作为“灵感启发器”。我让AI“解释一下它生成的树形组装算法的思路”然后根据它的解释我自己编写了一个更高效的算法首先一次性查询出该文章下的所有评论在内存中构建一个MapLong, ListCommentVO父ID到子评论列表的映射然后遍历找出根评论并通过Map快速填充其子节点列表。这样只需要一次数据库查询。核心技巧对于复杂的业务算法不要期望AI一次生成最优解。应该让AI提供实现方案草案然后由你进行评审、优化和重写。AI的价值在于快速提供可工作的基础版本节省你从零构思的时间。4.2 挑战二与框架特定机制的集成RuoYi框架有一些自己的约定比如操作日志Log注解和数据权限DataScope注解。当我让AI在Controller的方法上添加Log注解时它能够正确生成。但对于数据权限情况就复杂一些。我的博客系统可能希望“用户只能管理自己发布的文章”这是一个简单的数据权限场景。我尝试提示“在BlogArticleService的分页查询方法中实现数据权限过滤让普通用户只能看到自己创建的文章。” AI给出的方案是在SQL的WHERE条件中手动添加AND create_by #{username}。这虽然可行但不是最优雅的因为RuoYi提供了更通用的DataScope注解和基于部门的数据权限体系。我的解决方案我查阅了RuoYi官方文档中关于数据权限的部分然后明确指示AI“修改BlogArticleMapper.xml中的分页查询SQL在where标签内加入数据权限过滤使用${params.dataScope}。” 同时我在Controller的查询方法上手动加上了DataScope注解。这样我就将数据权限的控制权交还给了框架更加规范和解耦。4.3 挑战三前端组件样式的微调AI生成的前端表格和表单样式是标准的Element UI但我想让博客的编辑界面更友好比如将文章内容的输入框从一个简单的el-inputtype“textarea”替换为一个功能丰富的Markdown编辑器。我引入了项目中可能已有的或我决定引入的mavon-editor组件。我告诉AI“现在将表单中的‘内容’字段从普通的文本域替换为mavon-editor组件。需要处理v-model的双向绑定并设置合适的高度。” AI能够根据指令修改模板部分将el-input替换为mavon-editor v-model\form.content\ :style\{height: ‘500px’}\” /。但它不会自动帮我导入组件。我需要自己确保在script部分通过components注册了mavonEditor或者在全局进行了注册。这个过程体现了当前AI辅助开发的典型模式它能出色地完成局部的、语法正确的代码替换和生成但对于项目的全局依赖、构建配置和组件注册仍然需要开发者自己来把控和串联。5. 项目复盘效率对比与经验总结5.1 耗时统计与效率分析我们来算一笔时间账。如果完全手动开发这个博客系统的后台管理功能文章、分类、标签、评论的CRUD及关联功能数据库设计 SQL编写约30分钟。后端代码Entity, Mapper, Service, Controller每个实体按4个层计算4个实体就是16个文件。熟练工每个文件平均10-15分钟加上联调调试至少需要4-6小时。前端代码Vue组件、API模块每个管理页面约1-1.5小时4个页面加上路由配置约需5-6小时。菜单权限集成与测试约1-2小时。总计约10-15小时1.5-2个工作日这还是在思路清晰、不踩大坑的前提下。而在AI辅助下我的实际耗时如下需求梳理与指令设计约30分钟这部分时间无法节省且至关重要。数据库与后端代码生成得益于链式生成4个实体的全套后端代码约16个文件在1小时内完成且代码风格统一。前端代码生成与对接生成4个页面的骨架和API模块约30分钟填充交互逻辑和调试约1.5小时。集成、调试与样式微调约2小时。总计约5-6小时。效率提升接近60%-70%。最明显的节省在于那些模式化的、重复性的代码编写工作如Getter/Setter、基础的Mapper XML、Controller的模板方法等。AI将这些工作从“手动敲击”变成了“审阅和修正”思维负担大大减轻。5.2 核心经验与最佳实践经过这个项目我总结出几条AI辅助开发RuoYi这类框架项目的核心经验你必须是框架专家AI是强大的“执行者”但你是“架构师”和“质检员”。你必须比AI更懂RuoYi的规范、配置方式和运行机制。只有这样你才能给出准确的指令并判断AI生成的代码是否正确。如果你自己不熟悉框架AI生成的代码可能会把你带偏。指令工程是关键生产力模糊的指令得到模糊的结果。要学会给AI“喂”高质量的上文。最佳实践是“框架约束 具体需求 示例代码”。例如不要只说“生成一个分页查询”而要说“在RuoYi框架下生成一个BlogArticleController的分页查询方法使用PreAuthorize做权限控制返回TableDataInfo参考项目中SysUserController的list方法。”采用“生成-审查-迭代”的循环不要指望一次生成全部正确的代码。应该小步快跑。生成一个方法或一个文件后立即进行审查。审查的重点包括依赖注入是否正确、异常处理是否合理、是否符合框架安全规范如防止SQL注入、事务注解Transactional使用是否得当。发现问题后直接针对问题代码块向AI提问让它修正。前端开发更需谨慎前端涉及状态、生命周期和异步操作逻辑更离散。AI生成的前端代码在静态布局上很棒但在动态交互上容易出错。建议先让AI生成完整的页面模板和API调用方法壳然后由开发者自己逐步填充和调试methods中的交互逻辑特别是涉及表单验证、弹窗开关、数据回显等场景。将AI用于“探索”和“学习”遇到不熟悉的RuoYi模块比如操作日志的存储细节、定时任务集成可以直接问AI“在RuoYi中如何自定义操作日志的保存内容” AI能快速给出配置类和示例这比翻阅文档或搜索更高效。它可以作为一个随身的、上下文感知的框架助手。5.3 最终的成果与Git仓库最终我用大约一个工作日的时间完成了一个具备完整后台管理功能的博客系统。它拥有文章、分类、标签、评论的管理功能集成了RuoYi的权限、日志体系前端界面风格统一。虽然前端用户博客页面尚未开发但管理后台的完成为后续工作打下了坚实基础。我将这个项目的代码放在了GitHub上作为一个“RuoYi-Vue AI”辅助开发的实践案例。仓库地址是https://github.com/[YourUsername]/ruoyi-blog-ai-demo注此为示例地址实际地址已省略。在仓库的README中我详细记录了开发步骤、AI提示词示例以及遇到的主要问题和解决方案。这次实践让我确信对于基于成熟框架的业务系统开发AI已经成为一个强大的“力量倍增器”。它并非取代开发者而是将开发者从繁琐的、重复的体力劳动中解放出来让我们能更专注于架构设计、核心业务逻辑和创造性解决问题。当RuoYi-Vue遇上AI开发一个博客后台从“小项目”变成了一个“快速原型验证”这或许就是当下这个时代赋予我们开发者的新红利。
