1. 从“拖拉拽”到“一句话”低代码的范式革命如果你在过去几年里接触过低代码平台那么“拖拉拽”这三个字一定不会陌生。它几乎成了低代码的代名词在画布上拖拽组件在右侧面板配置属性再通过连线定义流程。这种方式确实比写代码快但天花板也显而易见——复杂的业务逻辑、个性化的交互、非标的集成往往还是得回归到写代码的老路上所谓的“低代码”最后变成了“低代码高代码”的混合体开发和维护的心智负担一点没少。最近JeecgBoot v3.9.2的发布打出了“告别拖拉拽Skills加持一句话搭建系统”的口号。这可不是一次简单的版本迭代在我看来这是一次对低代码开发范式的彻底重构。它试图回答一个根本问题当AI大模型已经能理解自然语言并生成代码时我们与机器协作构建软件的方式是否应该从“图形化配置”升级为“自然语言对话”“Skills”是这个新范式的核心引擎。你可以把它理解为一个高度智能的、专为JeecgBoot生态训练的AI助手。但它又不止于此Skills更像是一套可扩展的“超能力”插件系统将大模型的理解能力、代码生成能力与JeecgBoot成熟的代码生成器、权限框架、表单引擎等基础设施深度结合。用户不再需要关心组件在哪里、属性怎么配、API如何对接只需要用最自然的语言描述需求比如“创建一个员工管理系统包含姓名、工号、部门、入职日期字段支持按部门和入职时间范围筛选并能导出Excel”。Skills会理解你的意图自动完成从数据库表设计、前后端代码生成、到页面路由和权限配置的全过程。这标志着低代码从1.0的“可视化组装”时代迈入了2.0的“意图驱动”时代。1.0时代工具的核心是降低图形化操作的门槛2.0时代工具的核心是理解并实现开发者的意图将开发者从繁琐的、重复的、结构化的劳动中解放出来去专注于更核心的业务创新和复杂逻辑设计。对于广大中小企业的内部开发者、业务部门的“公民开发者”以及追求效率的全栈程序员来说这无疑是一个“王炸”级别的升级。2. Skills架构深度解析不只是个AI聊天框很多人第一眼看到“一句话搭建系统”可能会认为这只是一个集成了ChatGPT接口的噱头功能。但如果你深入研究JeecgBoot v3.9.2中Skills的实现会发现它的背后是一套精心设计的、将AI能力工程化的架构。这绝不是简单的“调用API并返回文本”那么简单。2.1 核心三层架构理解、规划与执行Skills的工作流程可以抽象为三个核心层次自然语言理解层、任务规划与拆解层、原子能力执行层。第一层自然语言理解与意图识别。当你输入“做一个销售订单管理模块”时Skills首先做的不是直接生成代码而是理解这句话背后的“意图”。它通过内置的或对接的大模型可能是经过微调的领域模型将你的口语化描述转化为结构化的“开发意图描述”。这个描述包括了实体识别识别出核心业务对象如“销售订单”。属性抽取从上下文中推断或通过多轮对话确认订单应有的字段如订单号、客户、金额、日期等。操作枚举识别出需要的基础增删改查CRUD操作以及可能的高级功能如“审批流程”、“统计报表”。非功能性需求捕捉例如“列表页要支持快速筛选”、“表单提交后需要发邮件通知”。第二层任务规划与原子能力拆解。得到结构化的意图后Skills不会用一个庞大的模型去一次性生成所有代码那样不可控且容易出错。相反它像一个经验丰富的项目经理将一个大需求拆解成一系列有序的、可执行的原子任务。这些原子任务对应着JeecgBoot代码生成器早已模块化的能力例如创建数据库表sys_order。生成实体类Order.java。生成MyBatis-Plus Mapper接口和XML。生成Service接口及实现类。生成Controller包含RESTful API。生成Vue3前端页面组件包括查询表单、表格、新增/编辑模态框。配置前端路由。初始化菜单和权限数据。Skills内部维护着一个庞大的“原子能力”图谱它知道完成“销售订单管理”需要依次调用哪些能力以及这些能力之间的依赖关系例如必须先有实体类才能生成Service。第三层原子能力执行与代码合成。这是JeecgBoot传统优势所在。对于每一个拆解出来的原子任务Skills会调用对应的代码生成模板、数据初始化脚本或配置生成器。这些生成器是经过千锤百炼的产出的代码符合JeecgBoot的最佳实践和规范。最后Skills将所有生成的代码片段、配置文件、SQL脚本进行合成形成一个完整的、可立即运行的模块并提供一键导入IDE或部署的选项。2.2 Skills与传统代码生成器的本质区别这里必须厘清一个关键概念Skills不是替代了原有的代码生成器而是为其加装了一个“智能大脑”。传统的代码生成器是“填表式”的你需要手动填写表名、字段名、字段类型、注释等信息然后点击生成。它高效但不够智能要求使用者对数据库设计和系统架构有基本认知。而Skills是“对话式”和“意图式”的。它的输入是模糊的、自然的人类语言输出是完整的、可运行的系统模块。它承担了从“业务需求”到“生成器输入参数”这段最耗时的分析、设计和决策工作。这相当于把资深架构师或技术负责人的经验沉淀成了随时可调用的AI能力。注意当前Skills的成熟度还高度依赖于其“原子能力”库的丰富度和对大模型意图理解的准确性。对于极其复杂、非标的业务逻辑如一个涉及多状态机、复杂计算和外部集成的审批流程它可能仍需要开发者介入在生成的代码基础上进行二次开发。但其价值在于它已经完成了80%的标准化、重复性工作。3. 实战用一句话构建一个会议管理系统理论说得再多不如亲手试一下。我们来模拟一个真实场景公司需要内部开发一个简单的会议管理系统用于登记会议、预订会议室、发送通知。传统低代码v1.0方式打开平台新建一个“应用”。在数据模型中手动创建“会议”表添加字段会议主题、会议室、开始时间、结束时间、发起人、参会人、状态。拖拽一个“表单”组件到页面手动绑定每个字段到对应的输入框下拉框、时间选择器等。拖拽一个“表格”组件配置列和数据源。配置“新建”按钮的点击事件打开表单。配置表单的提交逻辑调用后台保存接口。手动编写会议室冲突校验的逻辑可能需要写代码。配置邮件通知功能可能需要集成外部服务写更多代码。这个过程虽然不用写基础CRUD代码但大量的拖拽、绑定、配置工作依然繁琐且容易出错。JeecgBoot v3.9.2 with Skillsv2.0方式在JeecgBoot的开发界面中找到Skills对话入口。输入指令“请创建一个会议管理系统需要记录会议主题、会议室从会议室列表选择、开始时间、结束时间、发起人、参会人多选状态为待开始、进行中、已结束。会议室预订需要检查时间冲突会议创建后需要邮件通知参会人。”Skills可能会进行一轮确认对话“已识别您的需求。‘会议室列表’需要作为一个独立的数据表吗包含名称、容量、设备等字段。” 你回答“是的。”片刻之后Skills反馈“已完成。已创建‘会议室管理’和‘会议管理’两个模块。包含完整的增删改查页面、会议室时间冲突校验逻辑、以及邮件通知的集成点需配置SMTP服务器信息。代码已就绪是否立即导入项目并启动”接下来我们深入看看Skills具体生成了什么3.1 生成的代码结构分析Skills并非生成一堆无法理解的“黑盒”代码。它生成的代码完全符合JeecgBoot项目的标准结构并且有清晰的注释。后端 (jeecg-module-system或独立模块):entity/Meeting.java: 会议实体类字段对应你的描述JPA注解完整。entity/MeetingRoom.java: 会议室实体类。mapper/xml/: MyBatis-Plus的Mapper接口和XML文件基础的SQL都已写好。service/IMeetingService.java impl/: 服务层接口和实现。关键点在这里Skills在saveMeeting方法中不仅插入了数据还自动插入了会议室冲突校验的逻辑。它可能生成类似下面的伪代码Override Transactional public boolean saveMeeting(Meeting meeting) { // 1. 冲突校验 LambdaQueryWrapperMeeting wrapper new LambdaQueryWrapper(); wrapper.eq(Meeting::getRoomId, meeting.getRoomId()) .ne(meeting.getId() ! null, Meeting::getId, meeting.getId()) // 更新时排除自己 .and(w - w .le(Meeting::getStartTime, meeting.getEndTime()) .ge(Meeting::getEndTime, meeting.getStartTime()) ); if (meetingMapper.selectCount(wrapper) 0) { throw new RuntimeException(该时间段会议室已被预订); } // 2. 保存会议 boolean result super.save(meeting); // 3. 异步发送邮件通知 if (result) { emailService.sendMeetingNotification(meeting); // emailService需要你自己实现或配置 } return result; }controller/MeetingController.java: Restful API控制器标准的RequestMapping 返回统一的Result对象。resources/template/: 可能还会生成邮件通知的HTML模板文件。前端 (jeecg-vue3):views/meeting/MeetingList.vue: 会议列表页。包含查询表单主题、会议室、时间范围下拉、高级表格以及“新建”、“编辑”、“删除”按钮。views/meeting/MeetingModal.vue: 会议新增/编辑的弹窗组件。表单控件已正确绑定会议室是下拉选择器数据源来自会议室接口参会人是用户选择器时间是日期时间选择器。api/meeting.js: 封装了调用后端会议管理API的所有方法。路由和菜单已自动在router/index.js和菜单配置中注册。数据库执行生成的SQL脚本会创建meeting和meeting_room表字段类型、长度、索引都根据Java实体类智能推断生成。3.2 需要人工介入的“集成点”Skills虽然强大但并非万能。在上面的例子中它完成了“骨架”和“标准肌肉”但一些需要连接外部环境或高度定制化的“神经”和“皮肤”仍需要开发者手动处理邮件服务配置Skills生成了emailService.sendMeetingNotification(meeting)的调用和邮件模板但具体的EmailService实现、SMTP服务器地址、端口、用户名密码需要你在项目的配置文件中补充或者实现一个具体的Service Bean。Skills可能会在代码中留下清晰的// TODO注释或抛出一个需要你实现的接口。用户选择器数据源参会人“多选”组件Skills会默认绑定到JeecgBoot内置的用户接口上。但如果你的用户体系是自定义的可能需要你修改这个组件的数据源API。更复杂的业务规则比如“只有部门经理才能预订大型会议室”这种涉及复杂权限和业务规则的校验Skills可能无法通过一句话完全领会需要在生成的校验逻辑基础上进行增强。这恰恰是JeecgBoot Skills设计的高明之处它负责所有可标准化、可重复的部分而将真正体现业务独特性的、需要连接特定环境的“集成点”清晰地暴露出来交给开发者处理。这是一种高效的“人机协作”。4. Skills生态与未来从“代码生成”到“AI Agent”JeecgBoot引入Skills其野心显然不止于做一个更好的代码生成工具。结合网络热词中出现的“AI Agent”、“MCP排行榜”、“Superpower Skills”等概念我们可以窥见其未来的发展方向——构建一个围绕JeecgBoot的AI智能体生态。4.1 Skills的扩展性自定义你的“超能力”Skills的设计应该是可扩展的。官方会提供一系列基础Skills如“生成CRUD模块”、“生成报表页面”、“生成工作流表单”等。但更强大的是允许社区和开发者贡献自己的“Skills”。假设你所在行业经常需要处理“合同”业务你完全可以开发一个“合同管理Skill”。这个Skill封装了合同特有的字段合同编号、甲方乙方、金额、生效日期、终止日期、附件管理、特有的业务流程审批、用印、归档以及行业特定的校验规则。开发完成后你可以将其发布到Skills市场。其他开发者在使用JeecgBoot时只需要对AI说“创建一个合同管理模块”并选择启用你的“合同管理Skill”就能一键生成符合行业规范的功能。这相当于将领域知识Domain Knowledge和最佳实践Best Practice进行了产品化和可复用化。4.2 与AI Agent的融合从被动生成到主动协作目前的Skills工作模式还是“你问我答”的被动式。未来的进化方向可能是“AI Agent”模式。想象一下这样一个场景你启动一个JeecgBoot开发Agent给它一个目标“为公司开发一个供应商管理系统需要管理供应商信息、采购订单、对账和付款流程。” 这个Agent会开始工作需求澄清主动向你提问了解供应商分类、订单状态机、对账周期等细节。技术设计自动分析后建议你创建“供应商”、“采购订单”、“付款单”等核心表并给出ER图让你确认。迭代开发根据确认的设计一次或分次生成所有模块的代码。在生成过程中如果发现缺少“货币类型”字段它会主动询问“采购订单涉及外币吗需要增加‘币种’和‘汇率’字段吗”联调与测试代码生成后Agent可以自动运行单元测试甚至启动一个测试环境进行基础的功能流测试并给你一份测试报告。部署上线根据你的运维规范自动生成Dockerfile、Kubernetes部署脚本并触发CI/CD流水线。在这个场景里Skills不再是孤立的工具而是AI Agent可以调用的“手”和“脚”。Agent负责高层的规划、决策和与你沟通而Skills负责具体任务的执行。这就是“AI编程”的终极形态之一。4.3 对开发者角色的重塑这种变化对开发者意味着什么绝不是取代而是升级。低代码1.0时代开发者是“操作工”在画布上拖拽。低代码2.0时代开发者是“指挥官”和“架构师”。核心价值转移开发者的核心能力将从“编写CRUD代码”转变为“精准定义业务需求”、“设计复杂系统架构”、“处理非标集成”和“训练与调教AI助手”。你需要更懂业务更善于抽象和沟通。工作重心变化大量时间将从编码转向需求分析、AI指令工程如何与Skills有效沟通、代码审查审核AI生成的代码、以及处理那些AI尚且不擅长的、最顶层的复杂逻辑。技能要求更新了解AI的工作原理、掌握提示词Prompt编写技巧、具备更广阔的架构视野这些将成为开发者的新必修课。5. 理性看待当前局限与最佳实践在拥抱这项变革性技术的同时我们必须保持理性。JeecgBoot v3.9.2的Skills功能是一个开创性的起点但并非没有局限。5.1 当前可能面临的挑战需求理解的模糊性自然语言本身具有歧义性。“做一个用户管理”AI可能不知道你是想要一个后台管理的用户列表还是一个用户注册登录的前端页面。这需要多轮交互来澄清对使用者的表达能力和耐心有一定要求。复杂逻辑生成的不可控性对于非常复杂的业务规则、算法或性能优化代码AI生成的结果可能不尽如人意甚至存在隐蔽的bug。生成的代码必须经过严格的审查和测试不能盲目信任。现有系统的集成难题Skills擅长从零开始生成新模块但对于改造已有系统、在古老代码中插入新功能其能力可能有限。它更适用于新项目或相对独立的新功能开发。技术锁定的风险深度依赖JeecgBoot的Skills意味着生成的代码会紧密贴合JeecgBoot的技术栈Spring Boot, MyBatis-Plus, Vue3。如果未来想迁移到其他框架成本会比较高。5.2 高效使用Skills的最佳实践基于以上分析要最大化发挥Skills的威力我建议采用以下策略从“标准化模块”入手初期优先使用Skills创建最经典、最通用的管理后台模块如数据字典、组织架构、日志监控等。这些模块业务逻辑简单生成质量高能立即见效。扮演“产品经理”和“架构师”在与Skills对话前自己先想清楚。最好能简单画个草图明确实体、字段、主要操作和关键业务规则。用清晰、结构化、无歧义的语言描述需求。例如与其说“要权限控制”不如说“需要基于角色的访问控制分为管理员、部门经理、普通员工三级管理员能看所有数据部门经理只能看本部门数据”。生成-审查-迭代模式绝对不要指望一次生成全部。采用小步快跑的方式。先让Skills生成核心的CRUD功能导入项目运行起来。审查生成的实体、API和页面是否符合预期。然后再通过新的指令去迭代增强比如“为刚才生成的订单模块增加一个状态字段并添加状态流转逻辑”。这样风险可控也便于调试。建立团队规范如果团队内推广使用需要建立对AI生成代码的审查规范。重点审查业务逻辑、安全漏洞如SQL注入、越权访问、性能问题如N1查询等。将Skills视为一个强大的初级程序员它的产出需要高级工程师的指导和把关。拥抱“混合开发”将Skills作为“先锋”和“主力”快速搭建系统框架和标准化功能。对于那些Skills不擅长或无法生成的、高度定制化的、性能要求极高的核心业务组件则由资深开发者亲手操刀。两者结合才能实现效率与质量的最优平衡。JeecgBoot v3.9.2的这次升级与其说是一个功能发布不如说是一份面向未来的宣言。它宣告了低代码开发进入了一个以“自然语言”和“AI智能”为核心的新阶段。虽然前路仍有挑战但方向已经清晰。对于开发者而言与其焦虑是否会被取代不如主动学习和掌握如何与这样的AI工具协同工作将自己从重复劳动中解放出来去攻克那些真正体现创造力和价值的难题。这或许才是技术进化带给我们的最大礼物。