这个项目是我的毕业设计，课题是「基于 Spring Boot 与 Vue 的 WMS 智能仓储辅助决策系统」。选这个题目的时候，我给自己定了一个要求：不要做一个只会聊天的 AI 页面，而是让 AI 真的进到业务里去。
前端我用的是 Vue 3、Vite 和 Electron，后端是 Spring Boot 3.4、Java 17 和 SQL Server。系统的目标不是再造一个完整 WMS，而是在已有的仓储数据之上，提供更高效的查询、分析和辅助决策能力——把库存预警、自然语言数据分析、资料增强问答和文档处理放到同一个闭环里。
从「能聊天」到「能处理业务」
做之前我对 AI 应用的理解很朴素：接一个模型接口，做一个对话页面，能问能答，好像就已经是 AI 项目了。
真做起来才发现，业务系统里的 AI 不是这样工作的。一个仓库管理员想要的不是一句泛泛的回答，而是：
- 登录以后，只能看到自己权限范围内的数据；
- 上传一份制度或商品说明，让 AI 回答时优先参考它；
- 直接用自然语言问库存和销售，让系统去查真实数据库；
- 一进来就能看到哪些商品快没货了，而不是自己去翻表；
- 能把文档丢进去，提取内容，预览和下载处理结果。
这些问题逼着我把项目从「智能对话」一点点改成了「仓储辅助决策系统」。也是从这时候开始，我意识到 AI 项目的难点常常不在调模型，而在把模型放进一个可靠的工作流。
自然语言查数据库：分析助手
这个项目里我最满意、也最有成长感的部分，是分析助手。
用户可以直接用自然语言提出库存或销售问题，比如「最近哪些商品库存风险最高」。后端会把这个意图翻译成 SQL，去查真实的 SQL Server 业务库，然后把分析结论、SQL 明细和查询结果一起返回。整个过程还支持连续追问，不用每次都从头描述上下文。
但让它能上线，光会生成 SQL 是不够的。我加了几层保护：SQL 只能是只读查询，限制写入、删除、建表和系统过程调用这类危险关键字；只允许查询白名单里的表；并且对生成的 SQL 做修复保护，降低危险语句的风险。
这一步让我真正理解了 NL2SQL 的价值，也理解了它的边界——让模型查数据很有用，但「让模型随便查数据」是不可接受的。安全和能力必须一起设计。
给模型补上下文：资料增强问答
另一个让我有触动的功能是资料增强问答。
纯靠模型自己，它不知道这家仓库的制度、流程和商品细节。所以我做了一个资料管理模块：用户可以上传、查看和删除业务资料，AI 在回答时会优先参考当前账号上传的这些文档。
这其实就是最朴素的 RAG 思路——不追求复杂的检索算法，而是先解决「让模型看到用户私域资料」这件事。它让我从「直接问模型」走到了「给模型补上下文」，也让我开始思考检索质量、资料归属和上下文长度这些更深的问题。
把多个功能串成一条业务流
单独看，这些功能都不算特别复杂。但我刻意把它们串成了一条完整的业务主线：
- 管理员登录，进入工作台；
- 在资料管理上传一份业务资料，形成这个账号的知识库；
- 进库存洞察，看到低库存商品、风险分级和优先处理清单；
- 对某条高风险商品点「生成处理建议」；
- 系统跳到分析助手，自动带上针对这个商品的分析问题；
- 后端查真实数据库，返回结论和 SQL 明细；
- 再切到智能对话，基于已上传资料继续做制度解释和业务问答。
把功能连成流程，是我在这个项目里学到的很重要的一件事。别人看到的就不再是一堆零散的功能点，而是一个能解决实际问题的系统。
前端、后端和数据库，缺一不可
做这个项目以前，我更关心页面能不能跑起来、接口能不能返回结果。做完以后，我开始关心系统之间的连接。
前端不只是展示，它要处理登录态、路由保护、多会话的本地存储和后端同步、流式渲染（我用的是 SSE，请求里带上 Authorization 头），还要处理资料上传、结果预览这些交互。后端不只是转发模型请求，它还要负责认证（JWT）、数据库访问、文档处理、SQL 安全和一整套业务接口。数据库也不只是存数据，它直接决定了 AI 能分析什么、给出的结论可不可信。
用户账号、会话、聊天历史、还有仓储业务记录，都落在 SQL Server 上；测试环境我用 H2 内存库，这样跑自动化测试时不依赖真实数据库。为了部署方便，我还写了一键部署脚本，用 Nginx 加 systemd 把前后端一起拉起来。
边界和诚实
我也在项目里给自己留了一些诚实的边界。
比如系统配置页集中维护真实的数据库连接和模型配置，分析助手直接用这里保存的配置；普通账号由管理员创建，不开放公开注册；图片入口我保留了，但当前文本模型路径并不承诺图像理解能力，所以演示主线放在文本问答、资料问答、库存洞察和分析助手上。我宁可把能力说小一点，也不想做一个看起来什么都能、实际一碰就露馅的演示。
我学到的东西
第一，AI 功能不能孤立地看。一个好用的 AI 系统，应该知道用户是谁、有什么数据、能访问哪些资料、当前问题属于哪个业务场景。
第二，业务系统要有边界。SQL 只读、表白名单、API Key 不写进代码和提交记录、模型配置能在系统里维护——这些细节不炫技，但它们决定系统能不能继续往前走。
第三，演示也要有主线。一条从登录、资料上传、问答、库存洞察到分析助手的完整流程，比一堆孤立功能更有说服力。
回头看
现在回头看，这个毕业设计还有很多可以打磨的地方：权限颗粒度可以更细，资料检索质量还能提升，文档处理可以更强，部署细节也还能优化。
但它对我最大的意义，是让我第一次把 AI、数据库、后端、前端和业务流程放到一起考虑。它让我从「做一个能对话的页面」，往「做一个能解决业务问题的系统」实实在在地走了一步。