1. 项目概述：当低代码遇上AI，开发效率的“核聚变”

最近在技术圈里，一个词被反复提及：AI Skills。这不再是那种泛泛而谈的“AI辅助编程”，而是指一系列具体、可插拔、能直接作用于开发流程的AI技能。而当我看到JeecgBoot这个老牌的低代码平台，竟然也推出了自己的“AI Skills代码生成器”，并且喊出“一句话生成模块，甚至整个系统”的口号时，我的第一反应是：这到底是营销噱头，还是真的能改变我们这些老码农的日常？

作为一个在Java企业级开发领域摸爬滚打了十多年的老兵，我对JeecgBoot再熟悉不过了。它本质上是一个基于Spring Boot的快速开发平台，通过代码生成器，你可以根据数据库表，一键生成前后端增删改查的基础代码，大大减少了重复的CRUD工作。但传统的代码生成器有个天花板：它只能基于你已有的、结构清晰的表来生成。如果你脑子里有一个复杂的业务模块，但还没设计表结构，或者你需要生成一些带有特定业务逻辑、非标准流程的代码，传统生成器就无能为力了。你得先手动建表，再跑生成器，最后再去生成的代码基础上大改特改。

而这个“AI Skills代码生成器”瞄准的，正是打破这个天花板。它的核心思路是，将自然语言描述的需求，通过AI的理解和推理，直接转化为可执行的JeecgBoot项目代码。你不再需要先纠结于数据库字段是varchar(50)还是int，你可以直接告诉AI：“我需要一个员工绩效考核模块，包含员工信息、考核周期、KPI指标、自评、上级评分和最终等级，并且要能按部门统计平均分。” 剩下的，让AI去思考表结构、字段类型、关联关系，并生成对应的实体类、Mapper、Service、Controller乃至前端Vue页面。

这听起来很像之前火过的GitHub Copilot或Codeium，但又有本质不同。那些是“代码补全”工具，在行内给你建议。而JeecgBoot的AI生成器是“项目生成”工具，它的输出是一个完整的、符合JeecgBoot框架规范、可以直接导入IDE运行的功能模块。它深度融合了低代码平台“快速产出标准化代码”的能力和AI“理解模糊需求并结构化”的能力。我花了些时间深入研究并实际测试了这个功能，下面就把我的实战体验、背后的技术逻辑、具体的操作步骤以及那些官方文档里不会写的“坑”和技巧，毫无保留地分享给你。

2. 核心原理与架构拆解：它到底是怎么“想”的？

要理解这个工具，我们不能只停留在“输入一句话，输出一堆代码”的表面。我们需要拆解它的工作流程，看看AI是如何扮演“高级业务分析师”和“架构师”角色的。

2.1 从自然语言到结构化指令的“翻译”过程

当你输入“创建一个会议室预订系统”时，AI并不是直接开始写Java代码。它的思考过程是多层的：

1. 需求澄清与实体提取：AI首先会解析你的句子，识别出核心业务实体。在这里，“会议室预订系统”暗示了至少两个核心实体：MeetingRoom（会议室）和Reservation（预订）。它会进一步推理可能需要的属性，比如会议室可能有“名称”、“容量”、“设备”；预订记录需要有“预订人”、“开始时间”、“结束时间”、“状态”。

2. 关系与约束推理：接着，AI会推断实体间的关系。一个预订Reservation必然关联一个会议室MeetingRoom（多对一），也可能关联一个用户User（多对一）。同时，它会加入业务约束，例如“预订时间不能冲突”、“开始时间必须早于结束时间”。这些约束有些会转化为数据库唯一索引或校验逻辑，有些则会成为服务层的业务规则。

3. JeecgBoot元数据构建：这是最关键的一步。AI需要将推理出的实体、属性、关系，翻译成JeecgBoot代码生成器能理解的“元数据”。在JeecgBoot中，这通常是一个JSON或特定格式的配置，描述了表名、字段名、字段类型（映射Java类型和数据库类型）、字段注释（用于生成页面标签）、是否为主键、是否为查询条件等。

我的理解：这个过程相当于AI在模拟一个资深开发者在接到需求后的“脑图”阶段。区别在于，人的脑图可能更跳跃、更模糊，而AI的推理结果必须足够结构化、无歧义，才能被下游的代码生成引擎消费。这极度依赖于AI模型本身的逻辑推理能力和对JeecgBoot领域知识的掌握。

2.2 与Claude Code等AI编程助手的本质区别

很多人会把这款工具和VSCode插件市场里的Claude Code、GitHub Copilot进行比较。这里必须厘清一个关键区别：定位不同。

• Claude Code / GitHub Copilot：它们是“编码伴侣”。你在写一行代码时，它们帮你补全下一行；你写一个函数注释，它们帮你生成函数体。它们的上下文是你当前编辑的文件和项目，目标是提高编码速度。它们不关心你项目的整体架构，也不会生成一个包含多个文件、配置完整的模块。
• JeecgBoot AI Skills生成器：它是“模块工厂”。它的输入是高层业务需求，输出是一个完整的、立即可用的功能模块包。它深度绑定JeecgBoot的框架规范、项目结构和代码模板。它的目标是消灭从需求到基础代码的“零到一”过程。

你可以这样类比：Copilot是给你一把更快的雕刻刀，而JeecgBoot AI生成器是直接给你一个已经粗雕出形状的雕塑毛坯。前者赋能个体工匠，后者革新生产线。

2.3 技术栈猜想：大模型 + 特定领域微调 + 代码模板引擎

虽然官方未完全开源其实现，但根据其行为，我们可以合理推测其技术栈：

1. 大语言模型（LLM）核心：需要一个具有强大代码理解和生成能力的模型作为大脑。考虑到对中文需求的理解和代码能力，国内可能是DeepSeek-Coder、CodeQwen或通义千问的代码模型，国外则可能是Claude 3系列（这也是“Claude Code”热词关联的原因）。模型负责完成上述的“需求分析”和“结构化”。
2. 领域知识微调（Fine-Tuning）或提示工程（Prompt Engineering）：单纯的通用代码模型不知道“JeecgBoot的在线报表配置怎么写”、“JEditableTable组件的参数是什么”。因此，必须用大量的JeecgBoot项目代码、代码生成器配置样本对模型进行微调，或者设计极其精准的“系统提示词”（System Prompt），将JeecgBoot的开发规范、目录结构、常用组件库“灌输”给AI。
3. JeecgBoot原生代码生成引擎：这是最终的执行层。AI输出的结构化元数据（JSON），会被喂给JeecgBoot原有的、久经考验的代码生成器。这个生成器根据元数据和预设的Velocity或Freemarker模板，批量生成实体类、Mapper XML、Service、Controller、Vue页面文件等。AI并没有“写”出每一行代码，而是“驱动”了传统的模板引擎。

这种架构的优势是稳定：AI负责最灵活、最易变的“需求理解”部分，而成熟的代码生成引擎负责保证产出代码的质量和规范性，规避了AI直接生成代码可能带来的风格不一、潜在Bug多的问题。

3. 实战全流程：从一句话到一个可运行模块

理论讲再多，不如亲手跑一遍。我以一个相对复杂的“项目工时填报与审批系统”为例，带你走完整个流程。

我的需求描述：“开发一个项目工时填报系统。员工每天可以填报在不同项目上花费的工时（按小时计，支持小数），需要选择项目、工作日期、工作内容。填报后提交给项目经理审批。项目经理可以批准或驳回，驳回需填写理由。员工可以查看自己所有的填报记录和审批状态。项目经理可以查看下属员工的填报，并按项目、时间进行统计汇总。”

3.1 环境准备与工具接入

首先，你需要一个JeecgBoot项目。可以从官网下载最新版本（如v3.6.0）。我假设你已经有一个能正常启动的JeecgBoot基础项目。

AI Skills生成器通常以两种形式提供：

1. 在线SaaS服务：JeecgBoot官方可能提供一个在线平台，你在网页上输入需求，它生成代码包供你下载。
2. IDE插件：集成在IntelliJ IDEA或VSCode中，在本地环境运行。

我测试的是IDEA插件版本。安装方式与常规插件无异，在IDEA的插件市场搜索“JeecgBoot AI Skills”或类似名称进行安装。安装后，重启IDEA，你会在右侧工具栏或顶部菜单看到一个新的图标。

关键配置点：

• API密钥：工具需要调用后端AI服务，因此你需要配置API Key。这里就关联到“Claude Code”等热词。你可能需要前往对应AI服务商（如Anthropic的Claude，或国内深度求索等）的官网申请API Key，并填入插件设置中。
• 网络连通性：由于涉及调用外部AI API，必须保证你的开发机网络能够稳定访问该服务。这也是部分用户遇到“unable to connect to api”错误的根源。

踩坑记录：我第一次使用时就卡在连接上。错误信息是“Failed to connect to Anthropic services”。排查后发现：1. API Key填写错误，多了一个空格；2. 公司网络有出口限制，需要配置代理（注意，此处仅讨论技术上的网络代理配置，不涉及任何不合规用途）。在插件设置中找到网络配置项，正确设置后解决。务必仔细检查API Key和网络环境，这是第一步也是卡住最多人的一步。

3.2 需求输入与交互精炼

打开插件面板，你会看到一个简洁的输入框。我将上面的需求描述粘贴进去。

点击生成后，AI并没有立即开始“码代码”，而是弹出了一个交互式对话界面。这里体现了高级之处：AI在尝试与我澄清需求。

AI的提问：

1. “系统是否已经存在‘员工’和‘项目’这两个实体？如果需要我一同生成，请描述它们的基本属性。”
2. “工时填报的‘审批流程’是简单的两级（员工->项目经理），还是可能需要更复杂的多级审批？目前按简单两级处理。”
3. “统计汇总功能，您需要具体的图表类型吗？例如饼图显示项目工时占比，折线图显示工时趋势。”

我的回复：

1. “员工实体可关联系统现有用户表（sys_user）。项目实体需要生成，属性包括：项目编号（唯一）、项目名称、负责人（关联用户）、开始日期、结束日期、状态（进行中/已结束）。”
2. “按简单两级审批处理即可。”
3. “需要两种统计：1）项目经理视图：表格展示其负责的所有项目，以及每个项目在选定时间段内的总工时。2）图表展示：该经理下属员工工时分布柱状图。”

这个交互过程至关重要。它避免了因需求歧义导致生成错误代码。你提供的细节越多、越精确，生成的代码就越贴合预期。

3.3 生成结果分析与结构解读

经过几轮简短交互，AI开始生成。大约等待了30秒（取决于需求复杂度），生成完成。它提供了一个完整的模块压缩包，并提示导入项目。

导入后，我的项目src/main/java目录下新增了以下关键内容：

com.example.modules ├── project │ ├── entity │ │ ├── ProjectInfo.java // 项目实体 │ │ └── ProjectMember.java // 项目成员关联实体（AI自动推断出可能需要，用于权限控制） │ ├── mapper │ │ ├── ProjectInfoMapper.java │ │ └── ProjectMemberMapper.java │ ├── service │ │ ├── IProjectInfoService.java │ │ ├── impl/ProjectInfoServiceImpl.java │ │ └── ... // 其他Service │ └── controller │ └── ProjectInfoController.java └── workhour ├── entity │ ├── WorkHourFill.java // 工时填报实体 │ └── WorkHourApproval.java // 审批记录实体（AI将审批拆分为独立实体，设计合理） ├── mapper │ ├── WorkHourFillMapper.java │ └── WorkHourApprovalMapper.java ├── service │ └── ... // 对应的Service ├── controller │ └── WorkHourFillController.java └── dto └── WorkHourFillDTO.java // 包含审批状态等视图逻辑的DTO

同时，前端src/views目录下生成了对应的.vue文件：ProjectInfoList.vue,WorkHourFillList.vue,WorkHourFillModal.vue等。

让我惊喜的细节：

1. 数据库字段设计合理：WorkHourFill实体中，hours字段被定义为BigDecimal类型（对应数据库decimal(10,2)），完美支持小数工时。work_date字段为Date类型。
2. 关联关系正确：WorkHourFill中通过project_id关联ProjectInfo，通过user_id关联sys_user。WorkHourApproval中通过fill_id关联WorkHourFill。
3. 基础业务逻辑已嵌入：在WorkHourFillServiceImpl的submitForApproval方法中，AI不仅生成了更新状态为“待审批”的代码，还自动插入了生成一条WorkHourApproval审批记录的代码。
4. 前端页面功能完整：生成的WorkHourFillList.vue页面，已经包含了查询条件（项目、日期范围）、表格展示、新增/编辑/删除按钮、提交审批按钮。甚至包含了审批操作的模态框。

3.4 生成代码的二次开发与调整

生成的代码是“毛坯房”，可以直接运行，具备完整的增删改查和基础流程。但要满足个性化需求，必须进行二次开发。

我接下来做的事情：

1. 完善审批逻辑：在WorkHourApprovalController中，AI生成的approve和reject方法只有状态更新。我补充了发送站内信或邮件通知申请人的逻辑。
2. 定制统计查询：AI生成了一个基础的ProjectInfoController，但统计查询需要我自己实现。我在IProjectInfoService接口中添加了getProjectHourSummary方法，并在Mapper XML中编写了复杂的统计SQL（关联project_info,work_hour_fill,sys_user表）。
3. 调整前端样式和交互：生成的列表页面比较基础，我根据公司UI规范，调整了表格列宽，给“已驳回”状态加了红色标签，并在驳回时，使驳回理由输入框为必填。

核心心得：这个AI生成器的最大价值，是解决了“从0到1”过程中最枯燥、最重复的80%的基础代码工作。剩下的20%涉及复杂业务逻辑、特定集成和UI美化，仍然需要开发者手动完成。但这已经将开发效率提升了数倍。以前需要一天的工作量，现在可能一小时就能搭出框架。

4. 深度使用技巧与避坑指南

经过多个模块的生成尝试，我总结了一些能让你事半功倍的技巧，以及必须绕开的“坑”。

4.1 如何写出“AI友好”的需求描述（Prompt工程）

你的输入质量直接决定输出质量。不要用模糊的语言。

• 差描述：“做个客户管理系统。”
• 好描述：“创建一个客户关系管理（CRM）模块。核心实体是‘客户’，字段包括：客户名称（必填）、统一社会信用代码（唯一）、所属行业（下拉选择：互联网、金融、制造等）、客户级别（VIP、普通）、客户状态（潜在、已签约、已流失）。需要联系人子表，一个客户对应多个联系人。需要跟进记录功能，记录每次与客户的沟通情况。”

结构化描述模板：

1. **模块名称**：[例如：订单管理] 2. **核心实体**： - [实体A名]：描述，主要字段（字段名:类型:说明，如`order_no:string:订单号，唯一`) - [实体B名]：描述，与实体A的关系（一对一、一对多等） 3. **核心功能**： - 增删改查：标准功能。 - 特定业务流程：[例如：订单创建后自动进入“待支付”状态，支付成功后变“待发货”。] - 权限要求：[例如：只有客服角色可以修改订单地址。] - 统计需求：[例如：需要按日统计订单金额和数量。]

4.2 处理AI的“过度设计”与“理解偏差”

AI有时会“想太多”。

• 场景一：过度设计：当你要求一个简单的“通知管理”，AI可能会生成“通知表”、“通知类型表”、“用户通知关联表”、“通知模板表”这一套复杂的体系。对于简单场景，这是负担。
  • 应对：在交互阶段明确说“只需要一张简单的通知表，包含标题、内容、接收人、是否已读字段，无需分类和模板”。
• 场景二：理解偏差：你提到“报表”，AI可能生成需要复杂配置的“在线报表”功能，而你其实只需要一个简单的数据列表导出。
  • 应对：使用更精确的词汇。用“数据列表导出（Excel）”代替“报表”，用“状态机”代替“流程”，用“树形结构选择”代替“级联分类”。

4.3 生成代码后的必检清单

不要急着运行，先做代码审查。

1. 数据库脚本检查：查看生成的_sql文件夹下的建表脚本。重点检查：
   • 字段长度是否合理（例如，varchar(255)用于存储用户名可能不够）。
   • 索引是否添加（特别是外键字段和常用查询字段）。
   • 唯一约束是否正确。
2. 实体关联检查：打开生成的Entity类，检查@OneToMany,@ManyToOne注解的fetch属性（是LAZY还是EAGER），避免N+1查询问题。AI通常默认使用LAZY，这是正确的。
3. Service层事务检查：检查Service实现类的方法上是否有@Transactional注解。对于插入、更新、删除操作，特别是涉及多表操作的方法，必须添加。
4. 前端API对接检查：打开生成的Vue文件，检查api调用部分，URL路径是否正确，请求参数是否与后端Controller的@RequestBody或@RequestParam匹配。

4.4 与现有系统的集成策略

生成的模块是独立的，如何融入已有系统？

• 数据关联：最常见的需求是关联现有用户、部门等数据。在需求描述中就要明确指出：“created_by字段关联系统现有的sys_user表的id”。AI在生成时，会将该字段设置为外键，并在Java实体中使用@TableField(exist = false)等方式关联DTO对象。
• 权限融合：JeecgBoot使用Shiro或Sa-Token进行权限控制。生成的菜单和按钮权限码（如workhour:fill:add）需要你手动整合到系统的角色权限配置体系中。通常，你需要将生成的菜单SQL导入数据库，并在后台管理界面为相应角色分配这些新菜单的权限。
• 样式统一：生成的前端组件使用的是JeecgBoot默认的Ant Design Vue样式。如果你的项目有定制主题，需要手动调整生成的.vue文件中的CSS类名，或引入全局样式覆盖。

5. 适用场景与局限性评估：不是银弹

这个工具很强大，但它并非万能。清楚它的边界，才能更好地利用它。

5.1 最适合的三大场景

1. 原型验证与MVP开发：创业团队或内部创新项目，需要快速构建一个可演示、可测试的最小可行产品。用AI生成器在几天内搭出核心功能框架，快速验证市场反馈。
2. 企业内部管理系统开发：大量的OA、CRM、ERP、工单系统等，其核心都是对业务数据的增删改查、流程审批和报表统计。这类系统模块化程度高，重复模式多，是AI生成器的“主战场”。
3. 遗留系统功能扩展：一个运行多年的老系统，需要增加一个新的管理模块。用AI生成器快速生成这个新模块的标准代码，再手动与老系统的用户体系、权限框架进行集成，比从头手写要高效安全得多。

5.2 当前的主要局限性

1. 复杂业务逻辑无能为力：AI无法生成涉及复杂算法、第三方系统深度集成（如支付回调、消息队列复杂消费逻辑）、特定性能优化（如分库分表逻辑）的代码。这些仍然是高级开发者的核心价值。
2. 高度定制化的UI/交互：AI生成的页面是标准列表、表单、模态框。如果你需要拖拽式仪表盘、复杂的图形化流程设计器、独特的动画交互，必须由前端工程师深度开发。
3. 对模糊、矛盾需求的处理能力弱：如果需求本身是模糊或自相矛盾的，AI要么会多次询问（增加交互成本），要么会生成错误的代码。“垃圾进，垃圾出”的原则在这里依然适用。
4. 技术栈锁定：你被锁定在JeecgBoot的技术生态中。生成的代码严重依赖Mybatis-Plus、Ant Design Vue等特定框架。如果你的技术栈是Spring Boot + JPA + React，那么这个工具对你毫无用处。

5.3 对开发者能力要求的演变

这个工具不会取代开发者，但会改变对开发者的要求。

• 需求分析能力变得空前重要：你必须能精准地将业务需求转化为机器可理解的、结构化的描述。这更像是产品经理或业务分析师的能力。
• 代码审查与重构能力要求更高：从“写代码”转向“审代码”和“改代码”。你需要能快速阅读、理解AI生成的代码，并判断其优劣，进行优化和重构。
• 系统设计与集成能力成为核心：如何将AI生成的多个模块有机组合成一个完整、健壮的系统？如何设计模块间的接口？如何保证数据一致性？这些高层次的设计能力，是AI无法替代的。
• 掌握“与AI协作”的新工作流：学会写有效的Prompt，学会在交互中引导AI，学会将AI的产出快速整合到自己的项目中，这是一项新技能。

6. 未来展望与生态猜想

JeecgBoot的这一步，只是低代码与AI融合的一个缩影。我们可以预见几个趋势：

1. 从“生成代码”到“生成应用”：未来的工具可能不再输出代码文件，而是直接生成一个可部署的应用包（Docker镜像），并自动配置好数据库、缓存等中间件。开发者只需关注业务配置和定制化扩展。
2. 垂直领域模型涌现：会出现针对特定行业的AI低代码平台，例如专门生成电商系统、物联网设备管理后台、医疗病历管理系统的模型。它们对行业术语、业务流程、合规要求有更深的理解。
3. 交互方式更加自然：从文字描述，发展到语音输入、草图识别（画个界面草图生成前端代码）、甚至直接与AI进行多轮对话，动态调整正在生成的应用。
4. 开源生态竞争：如同当年代码生成器一样，AI Skills生成器也会出现开源版本。社区会贡献更多、更好的领域Prompt模板和微调数据集，形成繁荣的生态。

我个人的体会是，这个工具目前已经达到了“可用”并“好用”的程度，尤其对于JeecgBoot的忠实用户和从事常规业务系统开发的团队来说，它是一个巨大的生产力杠杆。它把开发者从重复的体力劳动中解放出来，让我们能更专注于架构设计、性能优化和核心业务创新这些真正创造价值的部分。当然，它现在还不够聪明，需要你清晰地引导，并且你要对它的产出保持审慎。但毫无疑问，这扇门已经打开，未来已来。最好的应对方式，不是抗拒，而是主动学习如何驾驭它，让它成为你手中最得力的新工具。