SpringCloud+Layui+AI：智能政务微服务审批系统架构设计与实践

基于SpringCloud+Layui+AI的智能政务微服务审批管理系统，我先把结论放在前面：这是一个很适合做计算机毕业设计的选题，因为一条线就能把微服务架构、审批工作流、AI大模型集成全部串起来。但也是因为它跨了三个技术方向，很多同学做得一半就卡住：每个技术都能讲一点，合在一起不知道边界在哪里。

下面我会把它当成一个真实项目来拆，而不是一个PPT标题。先看清楚政务审批到底要处理什么，再拆微服务边界，然后讲工作流怎么接，最后说AI能力应该放在哪个环节、怎么验证、怎么应对答辩追问。如果你是准备做这个选题，或者已经在开发中，按下面这个顺序看会比较顺。

1. 先看清楚这套系统要解决什么问题

1.1 政务审批场景的典型流程

政务审批系统不只是信息管理系统，它有一个很明显的业务特征：流程固定、材料多、留痕要求高。一个常规审批单从提交到办结，通常要经过“申请人填写→窗口受理→科室初审→分管领导审批→办结归档”几个环节。中间还会出现材料不齐需要补正、领导出差需要转办、多人会签等各种分支。

如果只用普通CRUD页面去实现，表面上也能做。但真正的问题是：每个审批单当前在哪个节点、谁办过、卡在谁手里、历史意见去哪查。这些信息一旦散落在多张业务表里，查询和统计会特别痛苦。所以工作流引擎在这里不是锦上添花，而是核心支撑。

从毕业设计的角度看，这个场景的优势在于业务明确、过程可演示、数据关系清楚。评审老师不需要太多背景说明就能理解你在做什么，这点比很多“看着很炫但是讲不清用途”的选题强很多。

1.2 用微服务和AI分别解决哪些问题

微服务解决的是系统结构问题。政务审批系统通常需要用户权限、审批业务、流程引擎、附件存储、消息通知等多个模块。如果全部写在一个单体项目里，功能多起来之后，编译慢、启动慢、多人协作容易冲突。拆成微服务之后，每个服务可以独立开发、独立部署、独立扩容。当然，拆分的代价是服务间通信、配置管理、部署维护都变复杂。毕设范围不会太大，一般拆五到七个服务就足够支撑演示。

AI负责的是辅助层面的能力。比如用户填表时，AI帮助检查材料是否齐全；审核人打开待办时，AI根据材料摘要生成一条拟办意见草稿；遇到政策问题，AI可以从文档库里检索答案。这些功能不改变审批的决策权，但能明显提升系统的演示亮点和课题新颖度。

这里要提前想清楚：AI在政务场景里不是越自由越好，而是越可控越好。评审老师很可能会追问这一点。AI生成的东西只能作为建议和草稿，不能直接作为审批依据，这个定位从一开始就要在设计和代码里体现。

1.3 这个选题适合什么基础的人

如果你已经掌握SpringBoot、MyBatis、MySQL，并且能独立写出一个单体后台管理系统，那做这个选题就属于“跳一跳能够到”的难度。SpringCloud你只需要把注册中心、网关、远程调用、配置中心这四件事跑通，不需要把每个组件都研究到源码级别。Layui属于上手非常快的前端框架，文档多、中文资料多、模板也多。

如果你现在还不会SpringBoot，建议先不要直接上微服务。先把单体版审批系统做出来，再逐步拆分，会比一开始就搭一堆服务容易得多。

2. 技术选型拆解：SpringCloud、Layui、AI、工作流各承担什么角色

2.1 SpringCloud技术栈怎么选

毕业设计建议走SpringCloud Alibaba这条线，原因很直接：国内资料多、中文文档多、老项目的踩坑记录也能搜得到。核心组件先用这四个：

• Nacos：注册中心加配置中心，服务发现和配置管理都靠它，默认端口8848。
• Gateway：统一入口，负责路由转发、跨域处理、登录鉴权校验。注意SpringCloud Gateway底层是WebFlux，不要在网关里直接写业务逻辑。
• OpenFeign：服务之间的远程调用，比手动写RestTemplate更直观，接口风格和本地方法调用接近。
• Sentinel：限流和熔断。毕设阶段可以只做配置和简单演示，不必把规则设计得太复杂。

如果你的课题申报书里写的是SpringCloud而不是SpringCloud Alibaba，也不要慌。微服务的大方向是一致的，区别主要在组件选型。答辩时能说清楚“为什么选择Nacos而不是Eureka”，反而比单纯会用一个框架更出彩。

网关路由配置是一个很容易忽略的点。如果前端请求的接口路径和后端服务路由对不上，会出现页面能打开但数据不加载的情况。建议提前整理一份路由表，把每个接口前缀对应到哪个服务写清楚，联调时能省大量时间。

2.2 Layui的定位是后台管理界面

Layui是一个轻量前端UI框架，核心优势是表格、表单、弹窗这些后台管理页面需要的组件都有现成样式。它的定位就是“拿来就能用”。

在毕设里，Layui有两种接法。第一种是传统非前后端分离：后端用模板引擎渲染页面，Layui提供样式和交互。第二种是前后端基本分离：前端静态页面放在独立目录，通过Ajax调用后端接口。如果是从若依微服务版本起步，直接沿用它的非前后端分离方式，学习成本最低；如果是自己从头搭项目，根据自己熟悉程度选就行。

很多同学纠结Layui是不是太旧。这里要分清：Layui适合的是“后台管理系统”，不是C端官网、移动端App。政务系统场景里，后台管理界面追求清晰、可维护、权限控制方便，Layui正好匹配。另外，毕设重点在后端架构和业务流程，前端能支撑演示即可，没必要在React、Vue上额外投入大量时间。

2.3 AI大模型在系统里的定位

AI必须是辅助，而不是决策主体。政务审批场景对准确性、可解释性、留痕要求非常高，AI生成的内容如果直接作为审批依据，风险很大。所以设计时一定要把AI模块封装成“AI辅助服务”，输出只能是“建议”和“草稿”，所有结果都要人工确认后才能写入正式数据。

具体讲，AI可以处理四类任务：

• 材料完整性预检：对用户提交的申请表单做字段级检查，提示缺失项。
• 审批意见草稿：根据当前材料摘要和流程信息，生成拟办意见，辅助审批人起草。
• 政策知识问答：把政策文档切块后做向量化存储，通过RAG方式回答问题。
• 相似案例检索：根据当前审批单内容，返回历史上相似案件的办理结果。

这四个方向里，材料预检和意见草稿最容易被评委看到效果，因为演示路径短、结果直观。政策问答需要准备知识库和向量数据库，工作量会明显增加，时间紧可以不做。

2.4 工作流引擎：Activiti还是Flowable

审批类系统离不开工作流引擎。常见的两个选择是Activiti和Flowable，Flowable可以理解为Activiti的延续和分支，在文档、API和维护活跃度上都更稳定一些。两者都遵循BPMN 2.0规范，如果只是做常规审批，核心API差别不会太大。

还有一个关键点：如果选择若依微服务版本作为基础，它通常已经集成了Activiti或Flowable的二次开发模块，包括流程设计器、流程管理、任务办理页面。你不需要从零写一套流程引擎，只需要把业务表单和流程变量对接进去。这对毕业设计来说是很大的工作量节省，但也意味着你要花时间搞清楚哪些模块代码能直接用、哪些需要改。

3. 从数据模型到微服务拆分，先搭骨架再写业务

3.1 核心数据表与关系

不管微服务怎么拆，数据表要先行。这里列一个偏通用的表集合，你可以根据业务调整：

有一点要特别提醒：不要把业务数据硬塞进流程引擎表。比如用户的姓名、材料清单、审批金额这些内容，建议在业务表里管理。流程引擎的表只负责流程实例、任务节点、流程变量和历史记录。这样做的好处是，后续你要做自定义查询、报表统计时，不需要去理解引擎表的复杂结构。

数据库设计时，最好把所有建表语句整理成一个sql脚本，按系统域、业务域、流程域分目录存放。答辩时老师如果问到数据库设计，你可以直接展示表关系图，比现场翻代码高效很多。

3.2 微服务怎么拆

针对政务审批场景，推荐一个适合毕设的拆分方案：

• gateway-service：路由网关，统一接收前端请求。
• auth-service：登录认证、Token下发、用户权限查询。
• system-service：用户、角色、菜单、部门管理。
• business-service：审批单业务，负责申请材料保存、业务状态流转、列表查询。
• workflow-service：流程引擎封装，启动流程、待办查询、任务审批、流程历史。
• ai-service：AI辅助能力，材料预检、意见草稿、知识问答。

如果时间紧张，file-service附件服务可以不单独拆，放进business-service里。ai-service也可以作为可选服务，只在需要演示AI功能时启动。服务数量控制在五到七个，演示时启动顺序清晰，答辩时也能讲得清楚。

这里给一个判断标准：如果一个模块没有独立部署、独立技术栈或独立扩展的需求，就不要单独拆服务。强行把用户管理拆成两个服务，只会增加服务间调用的复杂度，答辩时反而很难自圆其说。

3.3 服务间调用和数据一致性

服务拆开后，最大的问题是数据怎么保持一致。毕设阶段的一个常规做法是：业务服务保存审批单后，通过OpenFeign调用流程服务启动流程实例，然后把流程实例ID回写到业务表。流程任务完成时，通过消息或回调通知业务服务更新当前节点状态。

这条链路最容易出问题的不是业务逻辑，而是服务调用的超时和事务边界。在毕业设计里，建议用“最终一致”的简化方案：先保存业务数据，再启动流程；启动失败就把状态标记为“流程启动失败”，由定时任务或人工修复，不要强行要求跨服务强一致。演示时如果遇到偶发调用失败，重新发起一次通常就能恢复。

一个OpenFeign调用的典型写法可以参考：

@FeignClient(name = "workflow-service") public interface WorkflowClient { @PostMapping("/workflow/instances/start") R startProcess(@RequestBody StartProcessDTO dto); }

调用方注意三个点：服务名要配正确，路径要保持一致，返回超时时间要调大一点。默认超时时间比较短，启动流程时如果涉及多个节点判断，很容易超时。

4. 审批流程怎么做：从流程定义到自定义查询

4.1 流程模型与BPMN部署

流程设计通常借助流程设计器完成，也可以用Flowable提供的BPMN建模工具。一个最简单的政务审批流程模型，包括这些节点：

• 开始事件
• 用户任务：窗口受理
• 用户任务：科室初审
• 排他网关：判断是否通过
• 用户任务：领导审批
• 结束事件

流程文件保存为XML后，通过RepositoryService部署到引擎。部署成功后，会生成流程定义ID，发起审批时通过流程定义Key启动实例。

流程示例（简化版） 发起申请 → 窗口受理 → 科室初审 → 领导审批 → 办结

这里要注意流程Key的唯一性。改过一次流程定义后，旧的任务如果没有跑完，代码里按Key启动时用的还是最新版本。所以毕业设计中建议先设计好流程，再开始联调，不要一边改流程一边测试，容易出现流程版本混乱。

4.2 发起审批、办理任务、加签与驳回

启动流程的代码思路比较简单：

ProcessInstance instance = runtimeService .startProcessInstanceByKey("approve_flow", businessKey, variables);

businessKey建议用业务表的主键ID，这样可以通过流程实例反向找到审批单。

办理任务时，先查询当前用户拥有的任务列表，然后对指定任务执行complete，同时可以设置流程变量：

taskService.complete(taskId, variables);

会签和多实例节点属于进阶功能。一个多实例节点可以让多个审批人同时收到任务，所有人通过才继续。在毕设里可以作为加分项，但优先级不高。驳回建议实现“退回到上一节点”或“退回到发起人”中的一种，两种都做会显著增加边界判断。

4.3 自定义查询怎么配合流程表

这是“Activiti + 自定义查询 + 微服务”这个组合里最容易被问到的点。

审批系统的列表页通常要求按标题、状态、申请人、时间查询，同时显示当前节点和办理人。流程引擎表里字段很多，直接join会非常难受，而且引擎表的结构和版本有关。更稳定的做法是维护一张业务表冗余状态。

SELECT t.id, t.title, t.apply_user_id, t.current_node, t.status, t.create_time FROM biz_apply t WHERE t.status = #{status} AND t.title LIKE CONCAT('%', #{keyword}, '%') ORDER BY t.create_time DESC

流程推进时，无论经过哪个节点，都把最新节点名称和办理人回写进biz_apply表。查询列表只查业务表，点进详情时再通过流程实例ID查历史记录。这种“业务状态冗余”设计在中小型系统里非常实用，答辩时遇到“为什么要冗余”的提问，也能给出合理解释。

4.4 会签、驳回、撤回的边界处理

给一个务实建议：毕业设计不用把审批操作做全，但要把做过的操作讲清楚。

• 会签：适合多部门联合审批，配置为多实例顺序或并行审批。
• 驳回：如果只做一种，做“退回发起人”，实现简单、演示直观。
• 撤回：只在流程未开始时允许，发起人点击撤回后删除流程实例，业务状态改回草稿。

类似这种边界，在论文里可以写成“功能设计适度取舍”，在答辩时能体现你考虑过真实业务。不要把简单需求过度设计，更不要让流程状态出现无法解释的值。

5. AI能力落地：材料预检、意见生成、语义检索怎么做

5.1 先确认AI模块的定位

AI在这个系统里最容易犯的错，是把它做成一个独立的大杂烩页面，比如“聊天机器人”，和审批业务毫无关系。这样演示时评委看不懂，论文也难写。

更合理的做法是让AI嵌入到业务动作里：

• 点击“提交申请”前，触发材料预检，返回缺失项。
• 打开待办任务时，自动生成一条“拟办意见草稿”。
• 在政策咨询页面，输入问题返回文档段落和来源。

这三个入口都绑定实际业务，不用单独给AI设计演示剧本。后面会再讲具体怎么演示。

5.2 本地部署大模型还是调用API

在毕设阶段建议优先考虑API调用，理由很直接：开发速度快、不依赖本地显存、调试方便。调用时把API密钥放到Nacos配置中心，不要写死在代码里，更不要提交到Git仓库。

如果你的环境有独立GPU，可以尝试本地部署参数量在7B到14B的开源模型。部署成本可以参考下面这个判断：

本地部署8B模型通常建议显存不低于16G，如果只有CPU没有GPU，能跑但速度会很慢，演示体验不好。无论哪种方式，都要提前确认依赖版本和网络条件，不要在答辩前临时换方案。

5.3 一个可演示的AI材料预检示例

材料预检本质上是把用户填写的申请表单字段发给大模型，让模型判断有没有缺失或者格式不合规的内容。这是一个很典型的文本分类和抽取任务。

调用接口的请求结构可以简化成：

{ "model": "qwen-plus", "messages": [ { "role": "system", "content": "你是政务审批材料预检助手，你只负责检查申请材料是否完整，不输出任何政策建议。" }, { "role": "user", "content": "申请类型：营业执照变更；名称：已填；统一社会信用代码：未填；法人：已填；材料：无。请给出缺失项。" } ], "temperature": 0.2 }

注意这里的model名称和接口地址只是示例，实际以你接入的服务为准。temperature设为0.2是为了让模型输出更稳定，不要像聊天一样随意发散。拿到模型返回后，把结果解析成缺失项清单，展示在页面上，同时写入ai_check_result表，保证留痕。

5.4 AI内容要可控可解释

这个部分非常重要。

一是安全边界。AI返回的内容不能直接写进正式审批意见，必须由审批人点击确认后才会落库。系统里要有记录：哪条意见是AI生成的，哪条是人工确认的。

二是数据边界。不要把用户的身份证号、手机号等敏感字段发给大模型。如果只是做功能演示，可以脱敏后再发送，论文里也可以写“敏感信息本地脱敏后接入”。

三是可解释性。政策问答场景需要附上来源文档，不然评委随便问一个问题，系统答不上来或答错来源，会很难看。RAG方案天然满足“答案+出处”的需求，比直接问大模型更可控。

6. 前端Layui对接微服务接口的实测要点

6.1 先想清楚页面方案

如果沿用若依微服务版本的目录结构，页面一般是放在后端资源目录里的，通过模板引擎渲染，Layui负责页面美化。如果自己搭建项目，也可以把Layui静态资源独立成前端目录，用Ajax对接网关。

建议第一次跑通时先选一种方式，不要混用。最怕的就是一半页面由后端渲染，一半页面纯静态，接口路径和鉴权逻辑各写一套，调试时非常容易乱。

6.2 请求带Token和权限判断

前端对接微服务接口，通常需要做两件事：登录后把Token存下来；所有Ajax请求统一在Header里带上Token。网关在收到请求后解析Token，把用户信息透传给下游服务。

在Layui里可以统一封装一个Ajax入口：

layui.use(['jquery', 'layer'], function () { var $ = layui.jquery; $.ajaxSetup({ headers: { 'Authorization': localStorage.getItem('token') } }); });

这里只是示例。实际项目里Token存储和刷新策略要根据你的认证方案来。如果页面调接口返回401，优先检查Token是否过期，再去查网关的token校验逻辑。

6.3 表格、表单和流程追踪页面的选择

Layui的table模块做审批列表很合适，支持分页、排序、行点击。form模块负责申请填表。弹窗用layer组件，比浏览器原生弹窗好看很多。

流程追踪页面是加分项。简单做法是把流程图静态图片展示出来，根据当前节点名称高亮对应节点；更复杂一点可以在后端返回节点坐标，前端渲染动态流程图。毕设阶段建议先做静态高亮，稳定之后再考虑动态渲染。

6.4 前端常见问题

做Layui页面时，最常见的问题不是Layui本身，而是接口联调。建议优先打开浏览器F12，看Network面板里请求的URL、状态码和返回体。看到404先检查网关路由是否配置；看到401先检查Token；看到500再去看后端日志。

还有一些页面显示问题，比如表格滚动时表头错位。遇到这类问题先确认表格容器是否设置了固定宽度，再检查数据加载完成后是否调用了table.resize。页面展示问题修复优先级不高，不要为了一个布局问题花掉一整天。

7. 演示和答辩时要盯住的三个环节

7.1 启动顺序和检查清单

演示当天最怕的不是代码有bug，而是服务启动顺序不对导致连环报错。建议按这个顺序准备：

1. 启动MySQL和Redis，确认服务能连。
2. 启动Nacos，确认后台能登录。
3. 启动auth-service，看注册中心有没有出现服务实例。
4. 启动system-service、business-service、workflow-service。
5. 最后启动gateway-service。
6. 打开前端页面，登录一次，发起一条审批，走完整个流程。

每启动一个服务，就看一次Nacos控制台里的服务列表，确认实例状态。不要在日志还没刷完的时候就去点页面，很可能服务还没注册完成。

7.2 评审老师最可能追问的点

这个选题答辩时，评委大概率会问这三类问题。

为什么需要微服务？可以回答：系统包含用户权限、审批业务、流程引擎等多个模块，拆分后便于独立升级和团队协作，并通过演示说明网关和服务注册的作用。

审批数据的一致性和事务怎么处理？回答策略是：跨服务场景不追求强一致，业务表保存主数据，流程实例通过业务表关联，流程状态回写采用重试机制，保证最终一致。不要硬说用了分布式事务。

AI是谁生成的？准确率多少？回答时重点强调：AI只提供辅助预检和意见草稿，所有结果必须人工确认；数据脱敏后再调用大模型；评估指标以缺失项识别准确率为主。如果论文里有测试数据，比空谈“效果很好”更有说服力。

7.3 常见报错排查顺序

建议把排查顺序固定下来，越慌越要按顺序走：

1. 看控制台日志，找第一条异常，不是只看最后一行。
2. 看注册中心