星曜数据平台：我如何为制造业造一座数据工厂

一、先说痛点：物料数据的三个「靠」

在一家大型制造企业里，物料数据大概是所有数据里最「散」的一种。以一颗普通物料的来龙去脉为例：编码和属性在 PLM 与主数据系统里；它被哪些机型引用，要问工艺；价格在采购的比价表里；是否已停用，要看另一个系统的状态位。每一处都有一套账号、一套口径、一种导出格式。于是查数靠工单——提个取数需求，排期等回复；管控靠人脑——哪些物料是某机型专用、哪些半成品的 BOM 高度雷同，答案在几位老师傅的经验里，人一休假，答案跟着休假。

三个「靠」可以再拆细一点：

• 数据散：源系统各管一段，跨系统的关联要么靠人工比对，要么靠邮件附件里那份不确定是不是最新版的表格；
• 口径散：同一个「专用物料」，两个部门两种算法，报表数字对不上，会先吵半天口径再谈正事；
• 经验不走：品类策略、重复 BOM 排查这类判断高度依赖个人经验，PPT 里只有结论，没有过程，人一调动，经验跟着人走。

青岛星曜电子（虚构企业代称，下同）的物料数据平台，就是冲着这三个「靠」去的。定位很克制：不替换任何源系统，只做物料数据的统一出口。研发、品类、采购三类角色，各自在里面拿到四种东西：查得快的检索、搭得动的看板、信得过的 AI 策略流水线，和一个能提问、能说话的助手。门户首页把这几条最常用的路径摆在同一屏，先看一眼它的样子：

上图重绘自门户首页：英雄区三张入口卡分别通向检索、分析与助手，下方规模数据条只给量级不给精确值——真实平台的口径数字不出内网。

规模先给一组量级（真实口径数字属于内网信息，这里只说体量）：物化宽表百万行级、数十列，每日凌晨重建；一批专用检索场景全部流式返回；数百个品类纳入策略流水线；前端功能页面全量懒加载；数十个回归测试守着认证、导出、同步、查询四条核心链路。后面八章，按架构、查询、看板、策略、统计、生态、开放、演进的顺序展开。

二、总体架构：一个进程，三种存储，一条管道

图 1 · 总体架构：单进程装配全部业务模块，数据层三类存储分工明确，LLM 网关与定时管道挂在同一进程旁边

前端：React 19，重点在「百万行的手感」

前端是 React 19 + Vite 6 + Tailwind 4 + Recharts，路由全部懒加载，进哪个页面才加载哪个模块。真正的难点不在页面多，在大表：百万行级的宽表上做检索和看板，任何一次全量渲染都会卡死浏览器。解法是一套组合拳——查询走 SSE 流式，行数据边到边渲染；前端用一个节流行泵每 50 毫秒放 3 行进列表，新行带 0.35 秒滑入动画错峰显现；聚合表格本地分页每页 100 行，排序基于全量算好、DOM 只渲染当前页。用户感知到的「跟手」，是这一串小决定叠出来的。

服务端：单进程动态装配

后端是一个 Node.js 进程，同时托管静态前端和全部 API。启动时扫描路由目录，把每个模块动态 import 进来挂载——新增一个路由文件即自动上线，不改主入口。检测到证书文件就同进程监听 HTTPS 443 和 80，另开一个 8443 端口做「证书探针」，供没有客户端证书的环境验证服务可用性。登录墙中间件注册在静态服务之前，匿名 HTML 请求会先被重定向到 OAuth，静态资源才放行。

数据层：双库加 JSON，外加一个外部源

MySQL 是主力：物料主数据表（十几万行）、机型引用表（百万行级）、BOM 父子关系表、采购物料表、降本措施表、生产版本表，再加两张每日重建的物化宽表——通用一张百万行级、数十列，专用物料一张体量相近。把宽查询预物化成宽表，是整个平台查询性能的底座。SQLite 存权限表（WAL 模式），JSON 文件存场景注册表、看板配置、服务端会话和访问统计——JSON 是故意选的：人读得懂、diff 得了、备份就是拷文件。整机项目数据只存在于 Oracle，经飞书 MCP 查询，是全平台唯一的外部源，故障半径被隔离在单一场景里。

上图为这批主数据在平台上的统一浏览入口——分类库：大、中、小、细四级类目在页首汇成 KPI 卡，明细表支持筛选、排序与分页，十几万行主数据就沿着这棵类目树组织。

认证与权限：两档角色，三层兜底

登录走飞书 OAuth。浏览器持五个 cookie，服务端把会话持久化到 JSON 文件，重启不停登录态；access token 两小时过期，但配套的刷新与续期让 cookie 有效期做到 30 天。会话有三层兜底：登录墙带过期校验；cookie 被清后凭 session_id 向服务端续期重写；再不行走恢复页从 localStorage 找回。权限只分两档——admin 与 query_full，存在 SQLite 表里实时生效，改了不用重启；受限场景（生产版本、整机项目）在服务端校验，无权限直接 403 并写审计日志。前端藏菜单是体验设计，服务端校验才是权限本身，这两件事从来不混。

缓存与数据管道：凌晨的流水线

缓存三层：图表聚合结果内存缓存 5 分钟，同一配置秒回；飞书来源表数据走磁盘缓存、启动即恢复，新闻类条目加 30 分钟 TTL，防止旧数据复活；品类属性表 6 小时缓存配 stale-while-revalidate，过期先回旧值再后台刷新。数据管道靠 Windows 计划任务串成一条链：每日 7:30 主数据全量重建，8:05 物料增量同步，8:30 两张宽表重建加缓存预热，全程约 12 到 14 分钟；另有 2:40 影子快照、3:00 全量备份、8:50 数据守护——行数低于门槛的 70% 即告警。任务互斥用 PID 锁，飞书来源表的月度同步走「临时表导入加原子 RENAME 换表」，导入失败也不会污染在线表。后台「任务管理」页把 6 张任务卡的状态、当日总结、近 3 天历史摆出来，白名单内 3 个任务支持一键重跑，运行中轮询自动从 30 秒加密到 5 秒。

架构与管道讲完的是模块怎么连。换个视角看它对外提供什么：平台把 AI 能力沿物料的生命周期铺开，从规划准入到应用、再到淘汰，每个阶段都有对应的智能能力，系统说明页把这张能力矩阵整页呈现。

上图重绘自系统说明页：这张能力矩阵按生命周期三阶段排布，后面各章的模块都能在里面找到自己的位置。

三、查询引擎：多场景，一条事件流

上图重绘自数据检索页：左侧一排场景卡对应本章的各个场景，右侧是智能检索输入区——示例提示、可增删的输出字段折叠，确认后 Cmd/Ctrl+Enter 直发查询。

图 2 · SSE 流式查询：meta 声明列、row 逐行推送、progress 汇报进度、done 收尾报总数，前端边到边渲染

查询引擎的设计哲学是两个「统一」。输入统一：所有场景都吃关键词数组，物料编码、企业项目编码、机型、平台、描述可以混着输，逗号、空格、换行自动分词，上限 50 个关键词。输出统一：所有场景都吐同一种 SSE 事件流——meta 事件先声明列头，row 事件逐行推送，progress 事件汇报进度，done 事件收尾报总数；前端列先到先渲染，状态栏实时显示「已加载 N 条」，完成后显示「共 N 条、耗时 X.X 秒」，另有 9 分钟客户端超时兜底。所有场景共用这套协议，前端结果表、导出按钮、脱敏逻辑全部只写一遍。

每个场景各自回答什么问题

智能检索：先给一张可编辑的理解卡

自然语言入口没有做成「一句话直接查」，而是先解析、后确认。用户的描述交给 LLM 解析（带最近 10 轮上下文），产出一张查询理解卡：识别出的场景、关键词芯片、输出字段建议，芯片可以增删，字段可以勾选，受限场景带锁标。用户确认后才真正执行，人工的每次修正回写进多轮上下文，下一轮解析更准。立场很明确：AI 可以理解错，但不允许悄悄执行错。配套的防御也是同一思路——解析结果先经白名单净化再使用，解析失败返回一张降级卡片请用户换说法，而不是抛一个报错了事。

守门：配置即上线，不是配置即注入

这批场景里绝大多数已进入场景注册表（JSON 单一事实源），管理员在后台选表、选匹配列、定义输出字段，30 秒生效免重启。配置化把注入面从代码转移到了配置，所以执行器上有硬校验：输出字段走白名单，非法字段直接 400；表名限定字母数字下划线正则，列名走中文、字母、数字白名单正则，不合法的配置拒绝装配；受限场景服务端校验权限并留审计日志。

四、自助看板：把提数工单还给业务

图 3 · 自助看板闭环：筛选、图表、下钻核对、存为模板；不满意随时改，官方模板可设为全员默认

业务人员最常见的诉求不是「给我一套报表」，而是「我自己能不能随时拉一版」。自助看板把这件事压成一条流程：左侧添加行筛选（10 种操作符：等于、不等于、大于、小于、大于等于、小于等于、包含、IN、为空、不为空，行间的 AND 和 OR 可以直接点击切换），点查询，右侧画布上加图表，图表卡内改配置即时生效。全流程不需要写任何 SQL，也不需要提工单。

上图重绘自自助看板工作台：上方筛选区正用字段加操作符组合条件，下方柱状、折线、月度趋势与指标表各卡，数据为示意。

图表支持 7 种：表格、柱状图、折线图、饼图、专用分析（生产版本乘平台直接出专用物料数，走专用物化表）、指标表、指标图（12 个月目标对实际的双折线，最新月的实际值自动取实时数）。配置深度照顾到品类经理这一层：Y 轴聚合支持去重计数、计数、求和、平均；TopN 从 10 到 5000 或不限；刻度和数值标签字号可调；每张图表还能挂独立筛选。指标表另有 38 列字段选择器和 9 字段的面板筛选，指标字段支持区间过滤。

下钻是闭环的关键一环：点表格任意行或图表任意扇区，弹出明细窗口——服务端分页每页 500 行，字段自选，Esc 关闭。看板上看到异常，当场钻到明细核对，不用切换系统。对完数存模板：筛选加图表整体保存为个人配置或官方配置，官方配置可设为默认，打开页面自动加载并执行；支持拖拽排序、导出为 Markdown、从 Markdown 导入——看板本身也是数据，存 JSON，可迁移可分享。

取数链路按场景分两条：普通图表走 GROUP BY 聚合接口；表格不带 Y 轴时走去重查询接口，靠前缀索引加服务端分页避免全量拉取。筛选值下拉默认给 Top200，本地搜不到时自动 300 毫秒防抖发起全库模糊搜索并合并结果。业务自助分析跑在百万行级的宽表上，依然跟手——这是第二章那套前端手感工程在分析场景的复用。

五、品类策略：六步流水线，把 AI 关进流程里

图 4 · 六步流水线：每步产物落盘可恢复，菱形是验收门——来源为空或解析不出属性即终止，虚线是人工回退路径

品类策略是平台里 AI 浓度最高的模块，也是最容易被 AI 玩坏的场景——让模型自由发挥，它能给你编出一份看起来很专业的策略文档，属性是猜的，约束是凑的。所以这个模块的设计原则只有一条：AI 只在流程内的指定环节干活，每个环节有验收，全程留痕。六步严格顺序执行，每步产物落盘到任务目录，失败可以定位到第几步：

1. 获取品类信息：从数百个品类中按名称精确匹配，拿到该品类专属的多维表格 ID；查不到或缺 ID 直接报错，绝不拿别的品类凑数；
2. 导出物料明细：读品类专属多维表格全量，上限 1 万条，用户身份优先、应用身份兜底，超限自动切换检索接口分页拉全；
3. 分析物料属性：先按可采购属性过滤，再逐字段做值分布统计（每字段取 Top50、标记空字段、排除 14 个已知的噪声字段），为下一步圈定候选属性；
4. 解析品类策略：按策略文档的实际形态分发抓取（文档、知识库、电子表格、多维表格各有专用解析，表格类支持指定页签精读），10 万字符 prompt 预算按来源均分、按页签智能取舍，交给 LLM 输出核心属性与约束关系；
5. 属性映射与规格表：LLM 属性映射（命中排除字段或重复映射的强制作废），可解析的约束自动过滤笛卡尔积，不可解析的生成优化建议；组合生成预定义优先，否则全量笛卡尔积配约束剪枝，上限 5000 组；最后以用户本人的 OAuth 身份创建规格管理多维表格，500 行一批写入并带限流重试；
6. 生成报告与导图：结构化章节驱动双渲染，主路径一次成型写入飞书智能文档，降级链路走 md 导入加纯块型逐块写入（表格转等宽 ASCII 网格，只用实测验证过的块型）；思维导图与报告同源，PlantUML 与 mermaid 双输出，再失败就降级为报告内源码。

上图重绘自流水线入口页：顶部横幅确认品类策略文档已获授权，中部输入品类名与策略文档链接，下方任务历史里每条记录就是一次跑完的六步流水线——那个「已完成」徽章，代表六步全部通过验收。

防编造铁律

来源抓取为空即终止；解析不出属性即失败；来源不足 50 字符时在 prompt 里显式警告「请勿据此编造」；未获文档授权在建任务前就 403 拒绝；令牌过期自动刷新重试一次，权限错误给出升级授权的指引。

四条铁律的取向是一致的：宁可不产出，不编造产出。品类策略文档是要进评审的东西，一份掺了猜测的文档比没有文档危害更大。

LLM 全程留痕

第 4、5 步的每一次模型调用，把模型名、输入输出 token 数、耗时、思考过程预览全部写进任务事件流；「查看完整 Prompt」和「查看原始输出」的终端风只读视图随时可开，原始 prompt 与返回按白名单文件落盘（只许看本任务的文件，防路径穿越）。事件流本身是内存环形缓冲 600 条加磁盘追加双写，重启可恢复，单事件序列化设 8KB 上限做深度截断，防止一条大产物把内存和前端撑爆。用户问「AI 到底干了什么」，答案不是一句「智能生成」，是一次可以点开复盘的调用记录。

前端：报告即进度

流水线跑起来后，前端每 2 秒轮询任务进度，页面是一张「生长」出来的文档：顶部状态条显示品类名、当前第几步、总耗时；左栏步骤轨上每个节点有完成、运行中、失败、待开始四态，运行中的节点带外圈扩散动画并显示实测耗时；右侧章节随步骤逐个淡入，未到的章节显示骨架屏。完成后切换为完整 Markdown 排版，报告里的思维导图被自研的零依赖解析器转成可交互横向导图（超过 60 个节点自动收起一级分支、300 节点截断保护、解析失败降级显示源码）。失败态会精确指出第几步失败、错误原文和针对性建议——比如直接提示去哪里点授权。

六、访问统计：同一份数据，两个消费端

图 5 · 访问统计数据流：前端三类埋点、服务端环形缓冲加落盘，后台看板与运维日报消费同一份文件

平台上线后我最想知道的问题排序是：谁在用、用哪个功能、每天有多少人。访问统计就是回答这三问的，而它的架构可以用一句话概括：埋点上报进内存环形缓冲，异步落盘成一个 JSON 文件，然后让两个消费端读同一份文件。

上图重绘自管理后台访问统计页：TOP10 柱图示意访问分布，用户名一律为演示账号；这张图就是下面那套埋点管道最终交付的样子。

埋点与在线判定

埋点分三类。切页埋点由路由监听组件完成，每次切页上报一次页面路径；心跳埋点在用户进入平台后立即上报一次、此后每 30 秒一次；动作埋点散布在各业务链路——登录、加密导出、语音提问、论坛发帖编辑删除、知识库搜索各上报自己的动作，智能体开放通道的每次调用由服务端统一上报。存储端是一个上限 1 万条的全内存环形缓冲，每次写入异步落盘，服务启动时从磁盘恢复——这里有个值得自曝的细节：恢复逻辑最初忘了在启动时调用，直到某次重启后统计清零才发现，注释里记下了这次修复。口径上有一条刻意的克制：平台不统计「页面停留时长」。「当前在线」由心跳判定——用户名到心跳时间的映射表，120 秒没有心跳即视为离线并清理；停留信息由 30 秒粒度的心跳间接承载。做一个看似精确、实则靠猜的停留时长指标，不如把口径做得朴素而可靠。

后台看板与加密导出

管理后台的访问统计页签，进门是 7 张 KPI 卡：当前在线、今日访问、今日用户、今日语音、今日 API 调用、今日提交、今日搜索。往下三组图表：用户访问 TOP10；每日访问量对访问人数的双系列柱图，带近 7 天、30 天、90 天切换；页面功能 TOP12——页面路径先经一张字典译成中文页名（如数据检索、策略流水线），图题旁附功能维度的文字摘要（登录、导出、语音、发帖、搜索、智能体调用各多少次）。再往下是明细区：在线用户的胶囊墙、按天、按周、按人三种维度的统计报表（访问、语音、提交、搜索、API 调用、用户数六指标）、带动作徽章的浏览流水。右上角一个按钮：全量访问记录走统一加密导出管道，列是时间、用户、页面、动作、原始路径——谁在什么时候看了什么，这本身就是敏感数据，导出也必须留痕。

运维日报

同一份落盘文件还有第二个消费端：运维机定时经 SSH 拉取，统计最近一天（可回溯多天）的访问数据——总访问次数、访问用户数、按人访问排名、页面访问 TOP15，以及每人乘每页面的明细矩阵，组装成日报推送。产品内看板服务运营观察，运维日报服务例行通报，两个消费端读同一份文件，所以两边数字永远对得上。这不是巧合，是设计：一个口径一个出处，剩下的都是视图。

七、内容生态与 AI 助手

内容三件套

内容模块有三个：品类资讯（按品类订阅，鉴权后卡片推送进 IM，附件图片走代理）、品类知识论坛（6 个栏目，发帖、评论、点赞，帖子可关联飞书文档，关联后自动进入知识库索引）、品类公告。内容不是挂在平台上的装饰——论坛和公告同时是 AI 助手的检索语料，发一篇帖子，助手的回答素材就多了一篇。

全局 AI 对话：先声明能力边界

全局悬浮入口常驻每个页面，点开是双入口菜单：走协同办公机器人的对话，或网页对话。网页对话首屏先展示一张能力边界卡：能查物料和机型、能查降本措施、能排查重复半成品、能下载图纸、能按品类策略生成管控规则并画思维导图；不能查边界之外的信息，不答无关问题。回复走 SSE 流式增量渲染 Markdown，思考过程可折叠查看，支持停止与开新会话的命令。把「不能做什么」写进产品而不是写进免责声明，是这类助手赢得信任的第一步。

语音问答：从说到说

语音入口是一只麦克风球。识别优先用浏览器自带能力（中文），不支持时自动降级为录音上传服务端识别；识别文本走检索再交给 LLM，回答以音频流式返回，前端边下边播，个别不支持流式的浏览器整段下载后播放。会话 ID 存本地维持多轮，非安全环境明确提示麦克风不可用，而不是假装按钮坏了。整条链路是「说——识别——检索——生成——合成——说」，对产线上腾不出手的场景，这是比打字诚实得多的交互。

八、开放与合规

一套查询逻辑，三种消费形态

智能体开放通道是平台里我最得意的一处架构复用：通道内部注册了一个私有应用，把查询引擎的路由原样加载进来，用一个假响应对象捕获 SSE 事件流，再转成 JSON 吐给智能体。结果是九个场景零改动、行为完全一致地复用——网页在用、开放 API 在用、智能体在用，三种消费形态背后是同一套查询逻辑，改一处三端同步，不存在双实现漂移。安全上四件套齐备：API Key（缺失时自动生成写回环境配置）、内网 IP 白名单、令牌桶限速每分钟 20 次请求每 IP、JSONL 全端点审计，且每次调用结束由服务端上报访问统计。

加密导出的硬上限

全站所有导出统一走一条异步加密管道：提交任务、轮询进度、下载加密文件。硬规则有三条：非管理员单次导出上限 10 万行，超限直接拒绝，绝不悄悄截断——宁可让用户分批导，也不给一份不知道被剪过的数据；下载文件名走白名单防路径穿越；每次下载写审计日志，过期文件每小时清理。数据出平台的方式只有这一条路，所以出平台的每一份文件都能回答「谁、何时、导了什么」。

脱敏分档

敏感处理是分档的：需求数量这类敏感数量列在结果表里按三档脱敏（200 以内、200 到 2000、2000 以上），保护供应商报价谈判空间；受限场景双档权限控制；页面级防复制，但给输入框和 AI 对话区开白名单——防的是无差别搬运，不是防用户干活。

九、结语：从个人脚本长成平台

这个平台不是一次设计出来的。它最早是一个品类策略的 Python 技能脚本：把品类策略文档喂给模型，生成规格表。先证明 AI 能把这一步做对，再把一步扩成六步，再把六步从脚本搬进有权限、有审计、有统计的服务——源码里今天还留着对旧版任务格式的兼容代码，注释里留着 v3.4、v64 这样的迭代编号，.bak 文件排成一排。个人脚本是原型，平台服务是产品，差别不在功能多少，在守门：脚本编造一次结论，浪费的是自己的时间；平台编造一次结论，透支的是所有人对数据的信任。

下一步的方向也顺着这条线：更多检索场景配置化上线、权限关系全面表化、密钥全部迁入环境配置、统计口径继续做减法——宁缺毋假。

回到开头那三个「靠」。数据散、查数靠工单、管控靠人脑，不是某一家企业的毛病，是制造业物料数据的通病，我在每一个团队里都见过它的变体。你的团队里，大概率也有一个等着答案的「老周」。先进在线演示玩一玩——那里有一座缩小的星曜数据平台，数据是假的，问题是真的；看完若觉得同构，书房和工作室里有全部做法。