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代码。它的思考过程是多层的需求澄清与实体提取AI首先会解析你的句子识别出核心业务实体。在这里“会议室预订系统”暗示了至少两个核心实体MeetingRoom会议室和Reservation预订。它会进一步推理可能需要的属性比如会议室可能有“名称”、“容量”、“设备”预订记录需要有“预订人”、“开始时间”、“结束时间”、“状态”。关系与约束推理接着AI会推断实体间的关系。一个预订Reservation必然关联一个会议室MeetingRoom多对一也可能关联一个用户User多对一。同时它会加入业务约束例如“预订时间不能冲突”、“开始时间必须早于结束时间”。这些约束有些会转化为数据库唯一索引或校验逻辑有些则会成为服务层的业务规则。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 技术栈猜想大模型 特定领域微调 代码模板引擎虽然官方未完全开源其实现但根据其行为我们可以合理推测其技术栈大语言模型LLM核心需要一个具有强大代码理解和生成能力的模型作为大脑。考虑到对中文需求的理解和代码能力国内可能是DeepSeek-Coder、CodeQwen或通义千问的代码模型国外则可能是Claude 3系列这也是“Claude Code”热词关联的原因。模型负责完成上述的“需求分析”和“结构化”。领域知识微调Fine-Tuning或提示工程Prompt Engineering单纯的通用代码模型不知道“JeecgBoot的在线报表配置怎么写”、“JEditableTable组件的参数是什么”。因此必须用大量的JeecgBoot项目代码、代码生成器配置样本对模型进行微调或者设计极其精准的“系统提示词”System Prompt将JeecgBoot的开发规范、目录结构、常用组件库“灌输”给AI。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生成器通常以两种形式提供在线SaaS服务JeecgBoot官方可能提供一个在线平台你在网页上输入需求它生成代码包供你下载。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的提问“系统是否已经存在‘员工’和‘项目’这两个实体如果需要我一同生成请描述它们的基本属性。”“工时填报的‘审批流程’是简单的两级员工-项目经理还是可能需要更复杂的多级审批目前按简单两级处理。”“统计汇总功能您需要具体的图表类型吗例如饼图显示项目工时占比折线图显示工时趋势。”我的回复“员工实体可关联系统现有用户表sys_user。项目实体需要生成属性包括项目编号唯一、项目名称、负责人关联用户、开始日期、结束日期、状态进行中/已结束。”“按简单两级审批处理即可。”“需要两种统计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等。让我惊喜的细节数据库字段设计合理WorkHourFill实体中hours字段被定义为BigDecimal类型对应数据库decimal(10,2)完美支持小数工时。work_date字段为Date类型。关联关系正确WorkHourFill中通过project_id关联ProjectInfo通过user_id关联sys_user。WorkHourApproval中通过fill_id关联WorkHourFill。基础业务逻辑已嵌入在WorkHourFillServiceImpl的submitForApproval方法中AI不仅生成了更新状态为“待审批”的代码还自动插入了生成一条WorkHourApproval审批记录的代码。前端页面功能完整生成的WorkHourFillList.vue页面已经包含了查询条件项目、日期范围、表格展示、新增/编辑/删除按钮、提交审批按钮。甚至包含了审批操作的模态框。3.4 生成代码的二次开发与调整生成的代码是“毛坯房”可以直接运行具备完整的增删改查和基础流程。但要满足个性化需求必须进行二次开发。我接下来做的事情完善审批逻辑在WorkHourApprovalController中AI生成的approve和reject方法只有状态更新。我补充了发送站内信或邮件通知申请人的逻辑。定制统计查询AI生成了一个基础的ProjectInfoController但统计查询需要我自己实现。我在IProjectInfoService接口中添加了getProjectHourSummary方法并在Mapper XML中编写了复杂的统计SQL关联project_info,work_hour_fill,sys_user表。调整前端样式和交互生成的列表页面比较基础我根据公司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 生成代码后的必检清单不要急着运行先做代码审查。数据库脚本检查查看生成的_sql文件夹下的建表脚本。重点检查字段长度是否合理例如varchar(255)用于存储用户名可能不够。索引是否添加特别是外键字段和常用查询字段。唯一约束是否正确。实体关联检查打开生成的Entity类检查OneToMany,ManyToOne注解的fetch属性是LAZY还是EAGER避免N1查询问题。AI通常默认使用LAZY这是正确的。Service层事务检查检查Service实现类的方法上是否有Transactional注解。对于插入、更新、删除操作特别是涉及多表操作的方法必须添加。前端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 最适合的三大场景原型验证与MVP开发创业团队或内部创新项目需要快速构建一个可演示、可测试的最小可行产品。用AI生成器在几天内搭出核心功能框架快速验证市场反馈。企业内部管理系统开发大量的OA、CRM、ERP、工单系统等其核心都是对业务数据的增删改查、流程审批和报表统计。这类系统模块化程度高重复模式多是AI生成器的“主战场”。遗留系统功能扩展一个运行多年的老系统需要增加一个新的管理模块。用AI生成器快速生成这个新模块的标准代码再手动与老系统的用户体系、权限框架进行集成比从头手写要高效安全得多。5.2 当前的主要局限性复杂业务逻辑无能为力AI无法生成涉及复杂算法、第三方系统深度集成如支付回调、消息队列复杂消费逻辑、特定性能优化如分库分表逻辑的代码。这些仍然是高级开发者的核心价值。高度定制化的UI/交互AI生成的页面是标准列表、表单、模态框。如果你需要拖拽式仪表盘、复杂的图形化流程设计器、独特的动画交互必须由前端工程师深度开发。对模糊、矛盾需求的处理能力弱如果需求本身是模糊或自相矛盾的AI要么会多次询问增加交互成本要么会生成错误的代码。“垃圾进垃圾出”的原则在这里依然适用。技术栈锁定你被锁定在JeecgBoot的技术生态中。生成的代码严重依赖Mybatis-Plus、Ant Design Vue等特定框架。如果你的技术栈是Spring Boot JPA React那么这个工具对你毫无用处。5.3 对开发者能力要求的演变这个工具不会取代开发者但会改变对开发者的要求。需求分析能力变得空前重要你必须能精准地将业务需求转化为机器可理解的、结构化的描述。这更像是产品经理或业务分析师的能力。代码审查与重构能力要求更高从“写代码”转向“审代码”和“改代码”。你需要能快速阅读、理解AI生成的代码并判断其优劣进行优化和重构。系统设计与集成能力成为核心如何将AI生成的多个模块有机组合成一个完整、健壮的系统如何设计模块间的接口如何保证数据一致性这些高层次的设计能力是AI无法替代的。掌握“与AI协作”的新工作流学会写有效的Prompt学会在交互中引导AI学会将AI的产出快速整合到自己的项目中这是一项新技能。6. 未来展望与生态猜想JeecgBoot的这一步只是低代码与AI融合的一个缩影。我们可以预见几个趋势从“生成代码”到“生成应用”未来的工具可能不再输出代码文件而是直接生成一个可部署的应用包Docker镜像并自动配置好数据库、缓存等中间件。开发者只需关注业务配置和定制化扩展。垂直领域模型涌现会出现针对特定行业的AI低代码平台例如专门生成电商系统、物联网设备管理后台、医疗病历管理系统的模型。它们对行业术语、业务流程、合规要求有更深的理解。交互方式更加自然从文字描述发展到语音输入、草图识别画个界面草图生成前端代码、甚至直接与AI进行多轮对话动态调整正在生成的应用。开源生态竞争如同当年代码生成器一样AI Skills生成器也会出现开源版本。社区会贡献更多、更好的领域Prompt模板和微调数据集形成繁荣的生态。我个人的体会是这个工具目前已经达到了“可用”并“好用”的程度尤其对于JeecgBoot的忠实用户和从事常规业务系统开发的团队来说它是一个巨大的生产力杠杆。它把开发者从重复的体力劳动中解放出来让我们能更专注于架构设计、性能优化和核心业务创新这些真正创造价值的部分。当然它现在还不够聪明需要你清晰地引导并且你要对它的产出保持审慎。但毫无疑问这扇门已经打开未来已来。最好的应对方式不是抗拒而是主动学习如何驾驭它让它成为你手中最得力的新工具。
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代码。它的思考过程是多层的需求澄清与实体提取AI首先会解析你的句子识别出核心业务实体。在这里“会议室预订系统”暗示了至少两个核心实体MeetingRoom会议室和Reservation预订。它会进一步推理可能需要的属性比如会议室可能有“名称”、“容量”、“设备”预订记录需要有“预订人”、“开始时间”、“结束时间”、“状态”。关系与约束推理接着AI会推断实体间的关系。一个预订Reservation必然关联一个会议室MeetingRoom多对一也可能关联一个用户User多对一。同时它会加入业务约束例如“预订时间不能冲突”、“开始时间必须早于结束时间”。这些约束有些会转化为数据库唯一索引或校验逻辑有些则会成为服务层的业务规则。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 技术栈猜想大模型 特定领域微调 代码模板引擎虽然官方未完全开源其实现但根据其行为我们可以合理推测其技术栈大语言模型LLM核心需要一个具有强大代码理解和生成能力的模型作为大脑。考虑到对中文需求的理解和代码能力国内可能是DeepSeek-Coder、CodeQwen或通义千问的代码模型国外则可能是Claude 3系列这也是“Claude Code”热词关联的原因。模型负责完成上述的“需求分析”和“结构化”。领域知识微调Fine-Tuning或提示工程Prompt Engineering单纯的通用代码模型不知道“JeecgBoot的在线报表配置怎么写”、“JEditableTable组件的参数是什么”。因此必须用大量的JeecgBoot项目代码、代码生成器配置样本对模型进行微调或者设计极其精准的“系统提示词”System Prompt将JeecgBoot的开发规范、目录结构、常用组件库“灌输”给AI。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生成器通常以两种形式提供在线SaaS服务JeecgBoot官方可能提供一个在线平台你在网页上输入需求它生成代码包供你下载。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的提问“系统是否已经存在‘员工’和‘项目’这两个实体如果需要我一同生成请描述它们的基本属性。”“工时填报的‘审批流程’是简单的两级员工-项目经理还是可能需要更复杂的多级审批目前按简单两级处理。”“统计汇总功能您需要具体的图表类型吗例如饼图显示项目工时占比折线图显示工时趋势。”我的回复“员工实体可关联系统现有用户表sys_user。项目实体需要生成属性包括项目编号唯一、项目名称、负责人关联用户、开始日期、结束日期、状态进行中/已结束。”“按简单两级审批处理即可。”“需要两种统计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等。让我惊喜的细节数据库字段设计合理WorkHourFill实体中hours字段被定义为BigDecimal类型对应数据库decimal(10,2)完美支持小数工时。work_date字段为Date类型。关联关系正确WorkHourFill中通过project_id关联ProjectInfo通过user_id关联sys_user。WorkHourApproval中通过fill_id关联WorkHourFill。基础业务逻辑已嵌入在WorkHourFillServiceImpl的submitForApproval方法中AI不仅生成了更新状态为“待审批”的代码还自动插入了生成一条WorkHourApproval审批记录的代码。前端页面功能完整生成的WorkHourFillList.vue页面已经包含了查询条件项目、日期范围、表格展示、新增/编辑/删除按钮、提交审批按钮。甚至包含了审批操作的模态框。3.4 生成代码的二次开发与调整生成的代码是“毛坯房”可以直接运行具备完整的增删改查和基础流程。但要满足个性化需求必须进行二次开发。我接下来做的事情完善审批逻辑在WorkHourApprovalController中AI生成的approve和reject方法只有状态更新。我补充了发送站内信或邮件通知申请人的逻辑。定制统计查询AI生成了一个基础的ProjectInfoController但统计查询需要我自己实现。我在IProjectInfoService接口中添加了getProjectHourSummary方法并在Mapper XML中编写了复杂的统计SQL关联project_info,work_hour_fill,sys_user表。调整前端样式和交互生成的列表页面比较基础我根据公司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 生成代码后的必检清单不要急着运行先做代码审查。数据库脚本检查查看生成的_sql文件夹下的建表脚本。重点检查字段长度是否合理例如varchar(255)用于存储用户名可能不够。索引是否添加特别是外键字段和常用查询字段。唯一约束是否正确。实体关联检查打开生成的Entity类检查OneToMany,ManyToOne注解的fetch属性是LAZY还是EAGER避免N1查询问题。AI通常默认使用LAZY这是正确的。Service层事务检查检查Service实现类的方法上是否有Transactional注解。对于插入、更新、删除操作特别是涉及多表操作的方法必须添加。前端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 最适合的三大场景原型验证与MVP开发创业团队或内部创新项目需要快速构建一个可演示、可测试的最小可行产品。用AI生成器在几天内搭出核心功能框架快速验证市场反馈。企业内部管理系统开发大量的OA、CRM、ERP、工单系统等其核心都是对业务数据的增删改查、流程审批和报表统计。这类系统模块化程度高重复模式多是AI生成器的“主战场”。遗留系统功能扩展一个运行多年的老系统需要增加一个新的管理模块。用AI生成器快速生成这个新模块的标准代码再手动与老系统的用户体系、权限框架进行集成比从头手写要高效安全得多。5.2 当前的主要局限性复杂业务逻辑无能为力AI无法生成涉及复杂算法、第三方系统深度集成如支付回调、消息队列复杂消费逻辑、特定性能优化如分库分表逻辑的代码。这些仍然是高级开发者的核心价值。高度定制化的UI/交互AI生成的页面是标准列表、表单、模态框。如果你需要拖拽式仪表盘、复杂的图形化流程设计器、独特的动画交互必须由前端工程师深度开发。对模糊、矛盾需求的处理能力弱如果需求本身是模糊或自相矛盾的AI要么会多次询问增加交互成本要么会生成错误的代码。“垃圾进垃圾出”的原则在这里依然适用。技术栈锁定你被锁定在JeecgBoot的技术生态中。生成的代码严重依赖Mybatis-Plus、Ant Design Vue等特定框架。如果你的技术栈是Spring Boot JPA React那么这个工具对你毫无用处。5.3 对开发者能力要求的演变这个工具不会取代开发者但会改变对开发者的要求。需求分析能力变得空前重要你必须能精准地将业务需求转化为机器可理解的、结构化的描述。这更像是产品经理或业务分析师的能力。代码审查与重构能力要求更高从“写代码”转向“审代码”和“改代码”。你需要能快速阅读、理解AI生成的代码并判断其优劣进行优化和重构。系统设计与集成能力成为核心如何将AI生成的多个模块有机组合成一个完整、健壮的系统如何设计模块间的接口如何保证数据一致性这些高层次的设计能力是AI无法替代的。掌握“与AI协作”的新工作流学会写有效的Prompt学会在交互中引导AI学会将AI的产出快速整合到自己的项目中这是一项新技能。6. 未来展望与生态猜想JeecgBoot的这一步只是低代码与AI融合的一个缩影。我们可以预见几个趋势从“生成代码”到“生成应用”未来的工具可能不再输出代码文件而是直接生成一个可部署的应用包Docker镜像并自动配置好数据库、缓存等中间件。开发者只需关注业务配置和定制化扩展。垂直领域模型涌现会出现针对特定行业的AI低代码平台例如专门生成电商系统、物联网设备管理后台、医疗病历管理系统的模型。它们对行业术语、业务流程、合规要求有更深的理解。交互方式更加自然从文字描述发展到语音输入、草图识别画个界面草图生成前端代码、甚至直接与AI进行多轮对话动态调整正在生成的应用。开源生态竞争如同当年代码生成器一样AI Skills生成器也会出现开源版本。社区会贡献更多、更好的领域Prompt模板和微调数据集形成繁荣的生态。我个人的体会是这个工具目前已经达到了“可用”并“好用”的程度尤其对于JeecgBoot的忠实用户和从事常规业务系统开发的团队来说它是一个巨大的生产力杠杆。它把开发者从重复的体力劳动中解放出来让我们能更专注于架构设计、性能优化和核心业务创新这些真正创造价值的部分。当然它现在还不够聪明需要你清晰地引导并且你要对它的产出保持审慎。但毫无疑问这扇门已经打开未来已来。最好的应对方式不是抗拒而是主动学习如何驾驭它让它成为你手中最得力的新工具。
