面对一个庞大且成熟的现有项目，比如我们熟知的 RuoYi-Vue-Plus，想要在其中新增一个功Neng模块，心里多少是有点犯怵的。毕竟这不仅仅是写几行代码那么简单，你得理清父子模块的关系，还得遵循项目既有的代码规范，稍不留神就可Neng破坏了原有的架构美感。不过现在的开发环境变了咱们有了 AI 这种强力辅助，事情变得有趣多了。今天我就以在 RuoYi-Vue-Plus 中新增“商品分类”功Neng为例，聊聊怎么利用 AI来搞定这一切，顺便kankan怎么把那些繁琐的配置工作变成一种享受。

在正式开工之前，咱们得先和我们的“结对编程伙伴”——AI 模型，达成某种共识。你想想，Ru果它一会儿用英文跟你聊，一会儿生成的代码风格跟项目里现有的完全不一样，那岂不是越帮越忙？所以建立一个全局的规则文件至关重要。这就像是给新来的实习生发了一本员工手册，告诉它怎么在这个团队里生存。

我习惯在用户目录下放一个全局的配置文件。这里面Zui基础的一条，就是强制要求它使用简体中文跟我交流。这听起来有点好笑，但hen多模型默认是英文优先的，咱们中文开发者kan着英文注释和解释，总归是没那么亲切。除了语言，代码风格才是重头戏。比如我这个人有点强迫症，我喜欢在类的公有方法和私有方法之间画一条清晰的分割线。这不仅仅是为了好kan，geng是为了在阅读代码时Neng一眼区分出对外接口和内部逻辑。

于是我在规则里明确写道：“在类的公有方法和私有方法中间加上‘//////////////////////////////////////公私有方法分割线//////////////////////////////////’”。当然我也补充了例外情况：接口类不用加，Ru果全是公有方法，也就没必要多此一举了。这种细节上的约束，Neng让生成的代码kan起来就像是出自一位资深老手之手，而不是东拼西凑的产物。

这里得插一句题外话，工具的选择决定了体验的上限。一开始我试过免费的 MiniMax M2 Free 模型，结果发现它在处理数据库连接这种稍微底层一点的操作时就显得力不从心了。它告诉我找不到 MySQL 客户端工具，没法直接操作远程数据库。虽然它Zui后也给了我一堆脚本，让我自己去跑，但这离我想要的“全自动”还是差了点意思。

后来我换成了 Claude Sonnet，甚至用了 Opus 来处理复杂的框架设计，那感觉简直是天壤之别。Claude Neng通过安装 Node.js 的 mysql2 包来直接连库，那种行云流水的操作，才叫真正的辅助编程。所以Ru果你也想尝试这种工作流，建议还是得找个好点的模型，比如 GitHub Copilot 里集成的那些，虽然可Neng需要点“特殊手段”才Neng用，但绝对物超所值。

规则定好了接下来就是具体的业务了。这次我们的目标是Zuo一个“商品分类”的增删改查。在 RuoYi 这种多模块的项目结构里直接在 `ruoyi-system` 这种核心模块里塞业务代码肯定是不合适的，咱们得新建自己的业务模块。不过为了演示方便，咱们先专注于功Neng的实现，模块的拆分Ke以视情况而定。

得有张表吧？我直接在 OpenCode 的对话框里跟它说：“帮我在远程的 MySQL 数据库上创建本项目所需的数据库，顺便把 `t_goods_category` 表建好。” 为了防止它瞎搞，我把表结构也一并给了它。这里面包含了 `id`、`parent_id`、`name`、`level`、`sort_order`以及一些常规的 `create_time`、`update_time` 和逻辑删除字段 `deleted_flag`。

kan着 AI 在控制台里噼里啪啦地执行命令，那种感觉真的hen奇妙。它不仅建了表，还贴心地往里面插了几条测试数据。等到我在数据库里kan到那几条崭新的记录时心里那块石头总算是落地了。这一步，Ru果是以前，我得手写建表 SQL，还得考虑字段类型、索引什么的，现在全交给 AI，我只需要负责“审核”就行。

数据库有了接下来就是后端的 Java 代码了。这一步ZuiNeng体现之前定下的“规则”有多重要。我发出了指令：“结合当前项目的开发规范，在项目的合适包中，生成针对 `t_goods_category` 表的增删改查接口。”

没过多久，代码就生成了。我拿过来一kan，心里那个美啊。它生成的 `GoodsCategoryServiceImpl` 类，完美地遵循了我设定的“分割线”规则。你kan，所有的 `select`、`insert`、`update`、`delete` 这些公有方法dou整整齐齐地排在上面而在它们下面一条长长的分割线格外醒目，分割线下面才是 `buildQueryWrapper` 这种私有方法。

//////////////////////////////////////公私有方法分割线//////////////////////////////////
/**
 * 构建查询条件
 *
 * @param bo 查询条件对象
 * @return LambdaQueryWrapper
 */
private LambdaQueryWrapper buildQueryWrapper {
    LambdaQueryWrapper lqw = Wrappers.lambdaQuery;
    lqw.eq != null, GoodsCategory::getParentId, bo.getParentId);
    lqw.like), GoodsCategory::getName, bo.getName);
    // ... 其他条件
    return lqw;
}

而且，它用的全是 MyBatis-Plus 的 `LambdaQueryWrapper`，这种链式调用的写法既安全又优雅。它还自动处理了 Bo和 Vo的转换，用的正是项目里自带的 `MapstructUtils`。这说明 AI 不仅仅是懂语法，它还读懂了项目的上下文，知道用什么工具Zui顺手。这种“懂你”的感觉，真的Neng极大地提升开发幸福感。

代码写完了总得跑起来kankan吧。这时候，配置文件就成了拦路虎。Dev 环境的数据库连接、Redis 的地址和密码，这些敏感信息我可不想让 AI 到处乱填。于是我把具体的 Redis host、port、password 还有 MySQL 的连接信息发给它，让它去修改配置文件。

它也hen聪明，知道我只保留基础功Neng，把那些花里胡哨的开关dou给关了。配置改完，启动项目！kan着控制台上一行行日志刷过Zui后停在“Started RuoYi-Vue-Plus Application”的时候，我知道，成了。

接下来就是接口测试了。我习惯用 Reqable 这类工具。不过RuoYi 自带的权限校验这时候可Neng会来捣乱，没登录直接调接口肯定会被拦截。为了方便调试，我直接让 AI 在接口上加个 `@SaIgnore` 注解，告诉框架：“这个接口先别校验权限，让我测测再说。”

“我要通过 reqable 工具来请求 `/goods/category/listAll`，帮我设置一下不校验相关的权限。” 我刚说完，它就把代码改好了。 请求，数据“唰”地一下就返回了。那一刻的成就感，真的不亚于亲手写完了一个复杂的算法。

回过头来kan，在现有项目中新增功Neng模块，其实是一个系统工程。从数据库设计，到代码规范，再到配置管理和测试，每一个环节dou充满了细节。以前我们可Neng需要频繁地查阅文档，复制粘贴旧代码，稍有不慎就会留下技术债务。

但现在通过 AI 辅助，我们geng像是一个架构师和指挥官。我们负责制定规则，负责描述需求，而 AI 负责把那些繁琐的、重复的、需要记忆的脏活累活给干了。它生成的代码甚至比我们手写的还要规范，因为它不会忘事，不会偷懒，始终如一地遵守着定下的规则。

当然这并不意味着我们Ke以当甩手掌柜。我们依然需要懂技术，需要Nengkan懂 AI 生成的代码，需要在它“犯傻”的时候及时纠正。但不可否认的是这种工作方式极大地释放了我们的创造力，让我们Neng把geng多的精力放在业务逻辑和架构设计上，而不是纠结于“这个方法该叫什么名字”或者“那个分割线有没有加”这种琐事上。

所以下次当你面对一个庞大的项目，需要新增功Neng模块时别慌。先打开你的 AI 工具，给它立好规矩，然后kan着它为你把代码一行行敲出来吧。这就是属于我们这个时代的编程体验。