消費電子製造商：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（看板），都在客戶自己的基礎設施裡。