消费电子制造商：AI 知识库 + 生产看板

在这个项目之前，想知道产线情况得等一条人力链路：后端同事写 SQL 查数，另一位同事把结果做成 Excel 表或 PPT，报告才能传到高管手上——往往是数据产生后几小时甚至几天。链路之外的人没法自己去看。我作为自由全栈开发者（2025-06 至 2025-10）被请去，把这条链路换成高管能自己打开的看板，并给全公司（1,000+ 人，大部分在产线）一个能直接问公司自有文档的地方，不用再满世界找对的人问。

一个统一登录门户挡在其他系统前面：账号密码登录加钉钉内免登，其他系统未登录时先跳到这里，登录后带 token 跳回去——returnUrl 会校验白名单，防止被利用成开放重定向。权限建模为用户 → 角色 → 权限树，分菜单级和按钮级两层权限码（共 17 个），7 个页面对接约 85 个后端接口。

一个在钉钉里用的「报表中心」，办公室人员和产线管理者都在用：16+ 张报表，覆盖出货、AOI 颜色 / 外观良率（细到炉次）、TT 工站生产追踪、PVD 追踪报表，以及 TDM 交期——从来料登记到首次出货的时长，以 P25 / 中位数 / P75 分布呈现，内部版还带一个支持 Excel 导入导出的数据中心。24 个业务图表 / 表格组件搭在 6 个可复用图表基础组件之上（柱、线、面积、组合、饼图，加仪表盘和数字卡），基于 Recharts 套在 shadcn/ui 的 Charts 组件里，一键导出 PNG 和 Excel，并针对钉钉内置 webview 做了缓存调优。报表是按查询刷新、细到小时，不是实时推送。

约 20 张报表接上了 AI 分析按钮：一键流式返回对眼前这张图的解读，模型的推理过程以可折叠的轨迹显示在最终答案上方。这是从「这是一张图」到「这是发生了什么、为什么」最快的路径，不用再等人写一页解读 PPT。

和看板（不到 10 位高管在用）不同，这个前端面向全公司开放。它有两种模式：「知识库问答」基于公司上传的文档回答，带可点击的行内引用，能预览或下载原文；「AI 智能聊天」可以选内置助手角色，也能自定义 system prompt，还能上传文件让模型读。另有一个知识库管理页，批量上传 PDF / DOC / DOCX / XLSX / XLS，轮询每份文件的状态直到处理完成。我自己用 fetch + ReadableStream 解析服务端流式返回（没用现成的 SSE 库），做了可折叠的推理展示，把正文里的引用标记解析成可悬停的引用，并按 sessionId 保留多轮对话历史、支持重命名。检索和生成本身跑在另一个后端背后的托管知识服务里——这个前端做的是界面和接口集成，不是 RAG 管线本身。

知识库助手背后是我写的一个 Spring Boot 3.4 / Java 17 服务，职责是编排而不是重新实现检索和生成。query 改写、召回、rerank 发生在一个托管知识服务的 API 里；生成由托管大模型完成。我这一层包在外面：在把召回片段当作引用之前按分数阈值过滤，用 Spring 的 SseEmitter 在有上限的线程池里把回答流式传回去（逐行解析上游 SSE，转发成自己的事件——metadata、answer、reasoning、end、error），并跑一个独立的聊天模式，内置两个角色加自定义 system prompt。文档方面：Word 直接入库；PDF 渲染成图片，扫描件或表格密集、提取不到多少文字的页面，交给带视觉能力的模型处理，让它们也能被检索到。删除操作按顺序作用在知识服务、对象存储和数据库三处，保证三者一致。这套服务上线用于内部，没有针对公开暴露做加固——接口目前没有鉴权，这是留给后续维护者的待办。

前端（× 3 套）：React 19、TypeScript（strict）、Vite 7、Bun、TanStack Router / Query / Table、Zod 4（校验所有 API 响应）、shadcn/ui + Tailwind CSS 4，看板用 Recharts 套在 shadcn/ui Charts 里，知识库助手用 Vercel AI Elements + react-markdown + KaTeX。
后端：Spring Boot 3.4、Java 17、MySQL（MyBatis-Plus）、Spring MVC 的 SseEmitter 做流式输出、Apache POI（Word）和 PDFBox（PDF）做文档文本抽取。
AI：托管知识服务 API 做检索，托管大模型做生成，以及用视觉模型对扫描文档做文本提取。
部署：PM2（前端），PM2 + Nginx（看板），都在客户自己的基础设施里。