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 博客系统核心模块设计

在开始编码之前，我花了大约半小时进行核心模块的梳理。一个博客系统，抛开华丽的前端皮肤，其核心数据模型并不复杂。我规划了以下几个核心实体：

1. 博客文章（BlogArticle）：核心实体，包含标题、摘要、封面图、正文内容（支持Markdown）、发布状态、浏览量等字段。
2. 文章分类（BlogCategory）：用于对文章进行归类，支持多级分类。
3. 文章标签（BlogTag）：与文章是多对多关系，提供更灵活的内容组织方式。
4. 文章评论（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），再为每个根评论递归查找其子评论。但是，它生成的递归算法在处理大量数据时可能存在性能问题（N+1查询的变体），并且返回的DTO结构没有完全按照我的想法来。

我的解决方案：我没有直接采用AI的代码，而是利用它作为“灵感启发器”。我让AI“解释一下它生成的树形组装算法的思路”，然后根据它的解释，我自己编写了一个更高效的算法：首先一次性查询出该文章下的所有评论，在内存中构建一个Map<Long, List<CommentVO>>（父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这类框架项目的核心经验：

1. 你必须是框架专家：AI是强大的“执行者”，但你是“架构师”和“质检员”。你必须比AI更懂RuoYi的规范、配置方式和运行机制。只有这样，你才能给出准确的指令，并判断AI生成的代码是否正确。如果你自己不熟悉框架，AI生成的代码可能会把你带偏。

2. 指令工程是关键生产力：模糊的指令得到模糊的结果。要学会给AI“喂”高质量的上文。最佳实践是：“框架约束 + 具体需求 + 示例代码”。例如，不要只说“生成一个分页查询”，而要说“在RuoYi框架下，生成一个BlogArticleController的分页查询方法，使用@PreAuthorize做权限控制，返回TableDataInfo，参考项目中SysUserController的list方法。”

3. 采用“生成-审查-迭代”的循环：不要指望一次生成全部正确的代码。应该小步快跑。生成一个方法或一个文件后，立即进行审查。审查的重点包括：依赖注入是否正确、异常处理是否合理、是否符合框架安全规范（如防止SQL注入）、事务注解@Transactional使用是否得当。发现问题后，直接针对问题代码块向AI提问，让它修正。

4. 前端开发更需谨慎：前端涉及状态、生命周期和异步操作，逻辑更离散。AI生成的前端代码在静态布局上很棒，但在动态交互上容易出错。建议先让AI生成完整的页面模板和API调用方法壳，然后由开发者自己逐步填充和调试methods中的交互逻辑，特别是涉及表单验证、弹窗开关、数据回显等场景。

5. 将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，开发一个博客后台从“小项目”变成了一个“快速原型验证”，这或许就是当下这个时代，赋予我们开发者的新红利。