MyBatis-Plus代码生成器Skill：一句话让数据库表变成完整分层代码
核心结论速览
- 这是一个专门为 MyBatis-Plus 技术栈打造的 AI 技能，能把「数据库表结构 + 功能需求」直接翻译成 Entity、Mapper、Service、ServiceImpl、Controller、DTO、VO、BO 等成套代码文件。
- 它不只是一个模板替换工具，而是一套带 8 步标准工作流 的生成流程：收集配置 → 确定架构 → 收集需求 → 确定语言 → 创建待办列表 → 生成代码 → 进度更新 → 输出统计。
- 支持 MVC、DDD、分层架构、整洁架构等多种项目结构，并同时支持 Java 与 Kotlin 两种语言，模板基于 FreeMarker 语法并与 MyBatis-Plus 官方模板保持一致。
- 它有一个非常明确的触发边界：只有当你明确提到 MyBatis-Plus 或 mybatis-plus-generator 时才会启用，从而避免干扰 JPA、Hibernate 或其他 ORM 场景。
- 生成结果带有上下文感知的智能注释（类注释、方法注释、字段注释），而不是干巴巴的模板占位符，更接近可直接进入代码评审的生产级骨架。
该技能叫什么？如何一键安装 AI 技能提升开发效率？
基本信息
| 项目 | 内容 |
|---|---|
| 技能中文名 | MyBatis-Plus代码生成器Skill |
| 技能英文名 | mybatis-plus-generator |
| 技能ID | 12692 |
| 技术定位 | MyBatis-Plus 专属代码生成指导技能 |
| 支持语言 | Java、Kotlin |
| 支持架构 | MVC、DDD、分层架构、整洁架构、自定义架构 |
它解决什么问题
在典型的 Java / Kotlin 后端项目里，一张业务表往往要配套写出六到八个文件：实体类、Mapper 接口、Service 接口、Service 实现、Controller，再加上 DTO、VO、BO。这些文件的骨架高度重复，但细节又各有差异——字段类型映射、主键策略、包路径、注解风格（Swagger 2 还是 OpenAPI 3）、分层架构下的目录约定，每一项都可能写错。
传统做法是用 MyBatis-Plus 自带的代码生成器跑一遍配置，但配置项多、目录结构一旦换成 DDD 或整洁架构就要重新调整，而且生成出来的注释往往只是列名的直译，业务含义还得人工补。这个技能要做的，就是把这套「配置 + 调整 + 补注释」的过程交给 AI，用自然语言对话完成，并且保证生成结果符合你项目的实际分层规范。
「一键安装」的思路与步骤
由于技能详情中未给出具体的安装命令与下载地址，以下按通用流程说明，实际命令与入口请以官方说明为准。
- 确认安装前提：你使用的 AI 客户端或开发环境需要支持 AI 技能（Skill）机制，并能加载技能包内的
templates/、reference/、examples/等目录资源。同时本地应具备 MyBatis-Plus 项目基础（JDK、构建工具、数据库可连接或可提供建表语句）。 - 找到安装入口：在技能市场、技能仓库或团队的技能配置入口中搜索技能名
mybatis-plus-generator，或按技能 ID12692定位。具体入口路径以官方说明为准。 - 执行安装 / 启用：按平台提供的启用方式加载该技能，注意技能依赖的模板文件与参考文档需要一并就位，否则生成阶段可能缺少模板。
- 验证是否生效：启用后，在对话中输入明确包含「MyBatis-Plus」的请求，例如「用 MyBatis-Plus 根据 user 表生成 Entity、Mapper、Service、Controller」。如果技能正常触发，它会先向你询问数据库信息、架构类型、语言等配置，而不是直接输出代码——这就是生效的信号。
- 反向验证触发边界：试着只说「帮我根据表结构生成代码」而不提 MyBatis-Plus，技能应当不被触发。这能帮助你确认调用姿势正确。
该技能的主要功能和特点
- 全组件覆盖：可生成实体类（Entity）、数据访问接口（Mapper）、服务接口（Service）、服务实现类（ServiceImpl）、控制器（Controller）、数据传输对象（DTO）、视图对象（VO）、业务对象（BO）、数据模型（Model），基本覆盖后端分层所需的所有骨架文件。
- 多架构适配：内置 MVC、DDD、分层架构、整洁架构以及自定义架构的目录映射规则，能按架构类型决定「生成哪些对象」和「放到哪个目录」。例如同样是
user表，MVC 下实体落在entity/User.java，DDD 下则可能落在domain/model/aggregate/user/User.java。 - Java + Kotlin 双语言：模板目录同时提供
.java.ftl与.kt.ftl模板，Kotlin 侧支持数据类、空安全等语言特性。 - 需求驱动的方法生成：不只生成标准 CRUD，还会根据你描述的业务需求分析出自定义方法，例如「根据邮箱查询用户」「根据用户名查询用户」「订单状态更新」等，并生成方法签名与业务逻辑骨架。
- 智能注释而非占位符：类注释会解释业务用途并列出主要字段，方法注释包含参数类型、返回类型与异常说明，字段注释解释业务含义而不只是列名翻译。
- API 文档注解可选：支持 Swagger 2（
@ApiModel、@ApiModelProperty、@ApiOperation等）与 OpenAPI 3（@Schema、@Tag、@Operation等）两套注解体系，并会主动询问你选哪一套，避免 Spring Boot 3 项目里混入过期注解。 - 待办列表 + 实时进度 + 统计报告：生成前先输出结构化待办清单，生成中逐项勾选并汇报进度，生成后输出表数、对象数、方法数、文件数、行数等统计与代码质量检查清单。
- 精准触发边界：仅在明确提到 MyBatis-Plus 时启用，不干扰 JPA、Hibernate、TypeORM、Sequelize 等其他持久层方案。
和普通代码生成工具比强在哪：普通生成器强在「快」，弱在「懂上下文」——它不知道你的项目是 DDD 还是 MVC，也不知道这张表在业务上到底需要哪些查询方法。这个技能把「架构判断」和「需求分析」放进了流程里，先问清楚再动手，生成的是符合项目规范的代码骨架，而不是一堆需要重新搬运的文件。
如何使用该技能？
技能内部固化了 8 步工作流，你在对话中会依次经历下面这些环节。理解这套流程，能让一次生成跑得更顺。
步骤 1：提供数据库信息与全局配置
技能会先收集四类配置。你需要准备好：数据库类型（MySQL、PostgreSQL、Oracle 等）、连接 URL 或建表语句（CREATE TABLE 语句也可以）、库名、表名；全局配置包括作者名、输出目录（默认 src/main/java）、文件覆盖策略（覆盖 / 跳过 / 询问）、是否启用 Lombok、是否启用 API 文档及文档类型、是否启用校验注解。
提示：如果你不方便提供数据库连接，直接把建表语句贴进去即可，技能支持从表结构推断。
步骤 2：选择架构类型
技能会列出架构选项供你确认：
请选择项目架构类型：
- [ ] 传统 MVC：生成 Entity, Mapper, Service, ServiceImpl, Controller
- [ ] DDD：生成 Entity, Mapper, Service, ServiceImpl, Controller, DTO, VO, BO
- [ ] 分层架构：生成 Entity, Mapper, Service, ServiceImpl, Controller
- [ ] 整洁架构：生成 Entity, Repository, UseCase, Controller, DTO
- [ ] 自定义架构：自行指定对象类型
选定后还需确认基础包路径（例如 com.example.order），技能据此套用目录映射规则。若项目结构不明确，它会主动追问「请确认项目的目录结构」。
步骤 3：描述功能需求
这是决定自定义方法质量的关键一步。你可以这样写：
用户管理：需要根据邮箱查询用户、根据用户名查询用户、用户登录验证
订单管理：需要订单统计、订单分页查询、订单状态更新
技能会据此拆解出标准 CRUD 方法 + 自定义查询方法 + 自定义业务方法，并给出方法签名（参数与返回类型）。
步骤 4：选择编程语言
Java 或 Kotlin，二选一。
步骤 5：确认待办列表
技能会输出按表组织、带复选框的待办清单，逐条列出要生成的文件和每个文件里的方法，例如 UserService.java 下会列出 saveUser()、findById()、findByEmail()、findByUsername() 等。建议在这一步仔细核对，此时调整成本最低。
步骤 6：生成代码
生成顺序固定为：实体类 → Mapper → Service → ServiceImpl → Controller → DTO/VO/BO。每个对象都会加载对应模板、分析表结构、填充智能注释、写盘到正确目录。
步骤 7：跟踪进度
每完成一个对象、一个方法，待办列表会被勾选并同步进度。
步骤 8：查看统计报告
全部完成后输出整体统计（表数、对象数、方法数、文件数、行数）、按表统计、按类型统计、文件位置以及代码质量检查清单。
输入输出示例
输入一句话：「用 MyBatis-Plus 根据 user 表生成代码，MVC 架构，Java，基础包 com.example.app，启用 Lombok 和 OpenAPI 3，需要根据邮箱和用户名查询。」
预期输出：User.java、UserMapper.java、UserService.java、UserServiceImpl.java、UserController.java 等文件，其中 Service 层包含 findByEmail()、findByUsername() 两个自定义方法骨架与业务注释，Controller 层包含对应的查询接口。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装 / 使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| MyBatis-Plus代码生成器Skill（本技能） | AI 对话式代码生成指导 | 多架构目录映射、双语言、需求驱动自定义方法、智能注释、待办与统计 | 需支持技能机制的 AI 环境；以对话交互为主，几乎无配置学习成本 | 需要快速搭建符合团队分层规范的成套骨架，尤其是 DDD、整洁架构项目 | 优势：懂架构、懂需求、注释质量高、过程透明；不足：依赖 AI 环境，生成结果仍需人工评审 |
| MyBatis-Plus 官方代码生成器（AutoGenerator） | 框架自带生成器 | 基于配置类生成 Entity、Mapper、Service、Controller，模板可替换 | 需编写 Java 配置代码，理解 GlobalConfig、PackageConfig、StrategyConfig 等概念 | 结构固定的传统 MVC 项目、批量生成场景 | 优势：官方维护、稳定、可脚本化；不足：配置项多，DDD 等复杂分层需自行改造，注释偏模板化 |
| MyBatis Generator（MBG） | 通用 MyBatis 代码生成工具 | 生成实体、Mapper XML、DAO，支持多种数据库 | 需编写 XML 配置文件，配置学习曲线较陡 | 传统 MyBatis（非 Plus）项目、需要精细控制 XML 的场景 | 优势：生态成熟、XML 可控性强；不足：非 MyBatis-Plus 原生，缺少 IService、BaseMapper 等便捷能力 |
| 通用 AI 助手直接生成 | 无技能约束的对话式生成 | 直接输出代码片段 | 无门槛，但需自行描述项目规范 | 零散文件、临时验证 | 优势：随问随答；不足：不了解 MyBatis-Plus 项目约定，容易漏掉分层目录、注解体系不统一，且难以保证多文件一致性 |
从对比可以看出，本技能的差异化在于把「项目规范」当作一等公民：它不是生成「一份能跑的代码」，而是生成「一份符合你项目分层与注解规范的代码」。
该技能的典型应用场景与实际体验情况
场景一：新业务模块冷启动（后端开发工程师）
痛点：接到一个新需求，比如「积分商城」模块，需要 5 张表。手写骨架至少要半天，而且写完之后还要逐个检查包路径、注解、注释是否规范。
使用方式：把 5 张表的建表语句一次性贴给技能，声明 MVC 架构、Java、基础包与 Swagger 版本，然后描述每个表需要的业务方法。技能会输出完整的待办清单，逐表生成。
实际体验：上手难度低，因为技能是「问答式推进」的——它问什么你答什么，不需要预先背配置项。效果上，最省心的部分是多文件之间的一致性：Service 接口里的方法与 ServiceImpl、Controller 里的实现能对得上，不会出现「接口改了实现没改」的低级问题。注意事项是建表语句要贴完整，字段注释缺失会导致生成的字段注释质量下降。
场景二：老项目从 MVC 迁移到 DDD（架构师 / 技术负责人）
痛点：分层改造最耗时的不是设计，而是把几十张表的文件按新目录规范重新摆放，domain/model/aggregate/... 这类深层路径极易出错。
使用方式：在步骤 2 选择 DDD 架构，确认基础包路径，技能会按架构目录映射规则把实体放进领域层、Controller 放进接口层，并额外生成 DTO、VO、BO。
实际体验：这是该技能价值最突出的场景。技能内置了 architecture-directory-mapping-guide.md 与快速查找表，DDD、六边形、整洁架构、COLA 等路径规则都有覆盖。需要注意的是，如果项目结构有自定义约定，一定要在步骤 2 明确告知，否则可能生成到默认路径。
场景三：Kotlin 技术栈团队的标准化（Kotlin 后端团队）
痛点：不少生成器对 Kotlin 支持有限，生成出来的数据类不符合 Kotlin 习惯（空安全、data class 特性）。
使用方式：步骤 4 选择 Kotlin，技能会切换到 .kt.ftl 系列模板，生成数据类、Mapper 接口、Service 接口等。
实际体验：模板为 Kotlin 单独维护，能体现数据类与空安全特性。注意事项：Kotlin 模板同样遵循 MyBatis-Plus 官方模板结构，如果你的团队对命名或注解有额外约定，建议在需求描述里一并说明。
场景四：接口文档体系切换 Spring Boot 3（升级改造项目）
痛点：项目从 Spring Boot 2.x 升级到 3.x，Swagger 2 的 @ApiModel 等注解需要整体替换为 OpenAPI 3 的 @Schema、@Tag、@Operation，混用会出问题。
使用方式：在步骤 1 启用 API 文档并明确选择 OpenAPI 3，技能会向你确认文档类型后再生成。
实际体验：这个「强制询问」的设计非常必要——它能防止 AI 凭默认习惯直接套用 Swagger 2 注解。技能还提供了 Swagger 2 与 OpenAPI 3 的注解对照参考，便于团队自查。
该技能能为用户带来的价值
效率层面：把一张表的成套骨架生成从「写配置 + 反复调整目录 + 补注释」压缩成「一次对话」。以典型的六文件结构计算，单表手工耗时通常在数十分钟级，而技能在配置信息齐备的情况下可在一个回合内产出全套文件。多表批量场景下收益更明显。
规范层面：目录映射、注解体系、命名策略、包结构都由技能统一执行，减少了「同一个项目里两种风格」这类长期维护成本。对团队而言，这相当于把架构规范固化成了一条可复用的生成流程。
质量层面：上下文感知的智能注释让生成代码具备可读性，配合生成后的代码质量检查清单，可以直接进入代码评审环节，而不是「生成完还要重写一遍」。
门槛层面：过去使用代码生成器需要理解 GlobalConfig、StrategyConfig、PackageConfig 等一整套配置模型；现在用自然语言描述需求和架构即可，对新人尤其友好。
长期价值：技能绑定了 MyBatis-Plus 官方模板体系与 FreeMarker 模板结构，模板可演进、可替换，随着项目规范升级可以持续复用，而非一次性工具。
常见问题 FAQ
Q1：这个技能怎么安装？装完怎么确认能用？
按你所在平台提供的技能安装入口搜索技能名 mybatis-plus-generator 或技能 ID 12692 加载，具体命令与入口路径以官方说明为准。验证方式是输入一句明确包含「MyBatis-Plus」的请求（如「用 MyBatis-Plus 根据 user 表生成 Entity 和 Controller」），如果技能先反问你数据库信息、架构类型和语言，而不是直接吐代码，说明已生效。
Q2：为什么我让它「根据表结构生成代码」它没反应？
这是技能的刻意设计。技能详情明确规定：仅在用户明确提到 MyBatis-Plus 或 mybatis-plus-generator 时才触发；「根据表结构生成代码」「生成 CRUD 代码」「代码生成器」这类未包含 MyBatis-Plus 的表述被视为过于通用，不会触发。同理，JPA、Hibernate、TypeORM、Sequelize 等场景也不在它的服务范围内。调用时把技术栈说清楚即可。
Q3：这个技能收费吗？
技能详情中未涉及价格信息，是否收费取决于你获取该技能的平台与授权方式，请以官方说明为准。技能本身声明了许可条款见 LICENSE.txt，使用前建议查看。
Q4：它生成的代码能直接用吗？还需要人工改吗？
可以直接作为项目骨架使用。技能会生成标准 CRUD 方法与基于需求的自定义方法签名，并为自定义方法添加业务逻辑注释与待办提示（TODO），业务实现部分仍需开发者补全——这是设计意图而非缺陷。生成结束后，技能会输出代码质量检查清单，建议对照检查一遍再提交。
Q5：我的项目是 DDD / 整洁架构，不是传统 MVC，它支持吗？
支持。技能覆盖 MVC、DDD、分层架构、整洁架构以及自定义架构，会根据架构类型决定生成哪些对象以及文件输出到哪个目录。如果你的项目目录约定比较特殊，在步骤 2 明确告知基础包路径与目录结构即可，技能也提供了多套架构的目录映射参考文档支撑这一过程。
Q6：Java 和 Kotlin 都能生成吗？注解能配 OpenAPI 3 吗？
语言支持 Java 与 Kotlin，模板分别提供 .java.ftl 与 .kt.ftl 版本。API 文档注解支持 Swagger 2 与 OpenAPI 3 两套，启用时会主动询问你选哪一套——Spring Boot 2.x 项目通常选 Swagger 2，Spring Boot 2.2+ 与 3.x 项目建议选 OpenAPI 3。