企业官网建设流程全解析

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代码生成器早已模块化的能力，例如：

1. 创建数据库表sys_order。
2. 生成实体类Order.java。
3. 生成MyBatis-Plus Mapper接口和XML。
4. 生成Service接口及实现类。
5. 生成Controller，包含RESTful API。
6. 生成Vue3前端页面组件，包括查询表单、表格、新增/编辑模态框。
7. 配置前端路由。
8. 初始化菜单和权限数据。

Skills内部维护着一个庞大的“原子能力”图谱，它知道完成“销售订单管理”需要依次调用哪些能力，以及这些能力之间的依赖关系（例如，必须先有实体类，才能生成Service）。

第三层：原子能力执行与代码合成。这是JeecgBoot传统优势所在。对于每一个拆解出来的原子任务，Skills会调用对应的代码生成模板、数据初始化脚本或配置生成器。这些生成器是经过千锤百炼的，产出的代码符合JeecgBoot的最佳实践和规范。最后，Skills将所有生成的代码片段、配置文件、SQL脚本进行合成，形成一个完整的、可立即运行的模块，并提供一键导入IDE或部署的选项。

2.2 Skills与传统代码生成器的本质区别

这里必须厘清一个关键概念：Skills不是替代了原有的代码生成器，而是为其加装了一个“智能大脑”。传统的代码生成器是“填表式”的：你需要手动填写表名、字段名、字段类型、注释等信息，然后点击生成。它高效，但不够智能，要求使用者对数据库设计和系统架构有基本认知。

而Skills是“对话式”和“意图式”的。它的输入是模糊的、自然的人类语言，输出是完整的、可运行的系统模块。它承担了从“业务需求”到“生成器输入参数”这段最耗时的分析、设计和决策工作。这相当于把资深架构师或技术负责人的经验，沉淀成了随时可调用的AI能力。

注意：当前Skills的成熟度，还高度依赖于其“原子能力”库的丰富度和对大模型意图理解的准确性。对于极其复杂、非标的业务逻辑（如一个涉及多状态机、复杂计算和外部集成的审批流程），它可能仍需要开发者介入，在生成的代码基础上进行二次开发。但其价值在于，它已经完成了80%的标准化、重复性工作。

3. 实战：用一句话构建一个会议管理系统

理论说得再多，不如亲手试一下。我们来模拟一个真实场景：公司需要内部开发一个简单的会议管理系统，用于登记会议、预订会议室、发送通知。

传统低代码（v1.0）方式：

1. 打开平台，新建一个“应用”。
2. 在数据模型中，手动创建“会议”表，添加字段：会议主题、会议室、开始时间、结束时间、发起人、参会人、状态。
3. 拖拽一个“表单”组件到页面，手动绑定每个字段到对应的输入框（下拉框、时间选择器等）。
4. 拖拽一个“表格”组件，配置列和数据源。
5. 配置“新建”按钮的点击事件，打开表单。
6. 配置表单的提交逻辑，调用后台保存接口。
7. 手动编写会议室冲突校验的逻辑（可能需要写代码）。
8. 配置邮件通知功能（可能需要集成外部服务，写更多代码）。

这个过程虽然不用写基础CRUD代码，但大量的拖拽、绑定、配置工作依然繁琐，且容易出错。

JeecgBoot v3.9.2 with Skills（v2.0）方式：

1. 在JeecgBoot的开发界面中找到Skills对话入口。
2. 输入指令：“请创建一个会议管理系统，需要记录会议主题、会议室（从会议室列表选择）、开始时间、结束时间、发起人、参会人（多选），状态为待开始、进行中、已结束。会议室预订需要检查时间冲突，会议创建后需要邮件通知参会人。”
3. Skills可能会进行一轮确认对话：“已识别您的需求。‘会议室列表’需要作为一个独立的数据表吗？包含名称、容量、设备等字段。” 你回答：“是的。”
4. 片刻之后，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. 冲突校验 LambdaQueryWrapper<Meeting> 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虽然强大，但并非万能。在上面的例子中，它完成了“骨架”和“标准肌肉”，但一些需要连接外部环境或高度定制化的“神经”和“皮肤”，仍需要开发者手动处理：

1. 邮件服务配置：Skills生成了emailService.sendMeetingNotification(meeting)的调用和邮件模板，但具体的EmailService实现、SMTP服务器地址、端口、用户名密码，需要你在项目的配置文件中补充，或者实现一个具体的Service Bean。Skills可能会在代码中留下清晰的// TODO注释或抛出一个需要你实现的接口。
2. 用户选择器数据源：参会人“多选”组件，Skills会默认绑定到JeecgBoot内置的用户接口上。但如果你的用户体系是自定义的，可能需要你修改这个组件的数据源API。
3. 更复杂的业务规则：比如“只有部门经理才能预订大型会议室”，这种涉及复杂权限和业务规则的校验，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会开始工作：

1. 需求澄清：主动向你提问，了解供应商分类、订单状态机、对账周期等细节。
2. 技术设计：自动分析后，建议你创建“供应商”、“采购订单”、“付款单”等核心表，并给出ER图让你确认。
3. 迭代开发：根据确认的设计，一次或分次生成所有模块的代码。在生成过程中，如果发现缺少“货币类型”字段，它会主动询问：“采购订单涉及外币吗？需要增加‘币种’和‘汇率’字段吗？”
4. 联调与测试：代码生成后，Agent可以自动运行单元测试，甚至启动一个测试环境，进行基础的功能流测试，并给你一份测试报告。
5. 部署上线：根据你的运维规范，自动生成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 当前可能面临的挑战

1. 需求理解的模糊性：自然语言本身具有歧义性。“做一个用户管理”，AI可能不知道你是想要一个后台管理的用户列表，还是一个用户注册登录的前端页面。这需要多轮交互来澄清，对使用者的表达能力和耐心有一定要求。
2. 复杂逻辑生成的不可控性：对于非常复杂的业务规则、算法或性能优化代码，AI生成的结果可能不尽如人意，甚至存在隐蔽的bug。生成的代码必须经过严格的审查和测试，不能盲目信任。
3. 现有系统的集成难题：Skills擅长从零开始生成新模块，但对于改造已有系统、在古老代码中插入新功能，其能力可能有限。它更适用于新项目或相对独立的新功能开发。
4. 技术锁定的风险：深度依赖JeecgBoot的Skills，意味着生成的代码会紧密贴合JeecgBoot的技术栈（Spring Boot, MyBatis-Plus, Vue3）。如果未来想迁移到其他框架，成本会比较高。

5.2 高效使用Skills的最佳实践

基于以上分析，要最大化发挥Skills的威力，我建议采用以下策略：

1. 从“标准化模块”入手：初期优先使用Skills创建最经典、最通用的管理后台模块，如数据字典、组织架构、日志监控等。这些模块业务逻辑简单，生成质量高，能立即见效。
2. 扮演“产品经理”和“架构师”：在与Skills对话前，自己先想清楚。最好能简单画个草图，明确实体、字段、主要操作和关键业务规则。用清晰、结构化、无歧义的语言描述需求。例如，与其说“要权限控制”，不如说“需要基于角色的访问控制，分为管理员、部门经理、普通员工三级，管理员能看所有数据，部门经理只能看本部门数据”。
3. 生成-审查-迭代模式：绝对不要指望一次生成全部。采用小步快跑的方式。先让Skills生成核心的CRUD功能，导入项目，运行起来。审查生成的实体、API和页面是否符合预期。然后，再通过新的指令去迭代增强，比如“为刚才生成的订单模块增加一个状态字段，并添加状态流转逻辑”。这样风险可控，也便于调试。
4. 建立团队规范：如果团队内推广使用，需要建立对AI生成代码的审查规范。重点审查业务逻辑、安全漏洞（如SQL注入、越权访问）、性能问题（如N+1查询）等。将Skills视为一个强大的初级程序员，它的产出需要高级工程师的指导和把关。
5. 拥抱“混合开发”：将Skills作为“先锋”和“主力”，快速搭建系统框架和标准化功能。对于那些Skills不擅长或无法生成的、高度定制化的、性能要求极高的核心业务组件，则由资深开发者亲手操刀。两者结合，才能实现效率与质量的最优平衡。

JeecgBoot v3.9.2的这次升级，与其说是一个功能发布，不如说是一份面向未来的宣言。它宣告了低代码开发进入了一个以“自然语言”和“AI智能”为核心的新阶段。虽然前路仍有挑战，但方向已经清晰。对于开发者而言，与其焦虑是否会被取代，不如主动学习和掌握如何与这样的AI工具协同工作，将自己从重复劳动中解放出来，去攻克那些真正体现创造力和价值的难题。这或许才是技术进化带给我们的最大礼物。