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

一、先讲个场景

清晨八点，青岛星曜电子的采购工程师老周接到产线电话：明天上线的控制板上，有一颗板对板连接器，系统显示库存够，仓库却说找不着。他开始找数。先开 PLM 查编码——编码九位，他记不全，按描述搜出三个相近的；再开共享盘里的库存表，文件名从「连接器库存」一路排到「连接器库存-新版-最终0801-改」，他挑了修改日期最近的一个；价格不在库存表里，在去年一封邮件附件的报价单里，而那家供应商去年底刚换过一轮价格。等他把三处数字对齐、确认能放心答复产线，一个小时过去了——这还是顺利的时候。

老周的问题不是不努力，是数据本来就不在一处。这家两千多人的电子厂，物料数据散在 PLM、ERP、几十个部门 Excel 和数不清的邮件附件里：编码在 PLM，库存在 ERP 和仓库的自留表，价格在采购的比价表，供应商资质在品质的共享盘。每套系统都是某个年代、某个部门为某个目的建起来的，单独看都没错，合在一起，却回答不了最简单的问题：这颗料，多少钱，谁供的，还剩多少。

我在制造业干了十八年，其中七八年专门跟物料数据打交道，见过太多老周，也当过老周。当时我在星曜电子负责品类管理数字化，把这件事变成一个系统，最后落到了我头上——大概因为我既是懂物料的人，又是受不了低效的人。

二、于是有了这座平台

平台最后起名叫「星曜数据平台」，名字朴素，野心也有限：不替代任何现有系统，只做一件事——把散落的数据拢到一处，让四种人各自拿到答案。管理层看整体，工程师查单料，品类经理定策略，内勤出报表。对应四个模块：

• 数据看板，回答「现在整体什么情况」：物料总数、月查询量、供应商数、导出次数四张卡，十二个月趋势加品类分布，一屏看完，没有第二屏；
• 物料查询，回答「这颗料到底怎么回事」：一个搜索框，名称、编码、规格模糊匹配，品类和供应商可筛，点开一行看价格、库存、替代料和更新时间；
• 品类策略，回答「这个品类该往哪走」：每个品类按供应保障、质量、成本三个刻度打分，挂上成本优先、质量优先、双供应商平衡、国产化替代这类策略标签；
• 报表导出，回答「怎么把结论带出去」：和看板同一条查询管道，筛完一键导出真正的 xlsx。

技术底盘说出来不值钱：Express 加 SQLite，数据从源系统增量同步，部署在一台内网服务器上。这是权衡后的选择，不是将就，第七章细说。

数字都是内网实测的：平台收进三万两千条物料编码、四百一十六家供应商；上线一年，日均查询两千次出头，注册用户一百八十七人，研发、采购、品质、计划四个部门都在用。老周那个要一个小时的查找，现在三秒出结果；采购内勤月底的报表，从对半天 Excel 变成点一次按钮两分钟。

纸上谈兵不如直接看货。我把四个模块做了一个脱敏的在线演示（点这里进演示），里面全是假数据，但交互是真的。接下来四章按这四个模块逐个讲，每一章你都可以进演示里对着看。

三、看板：让数据先说话

先说场景。周一直早会，采购经理要汇报上周情况，提前一天就让内勤从各系统抽数拼页；拼出来的数是上周五的，而且物料部说的库存和采购说的库存经常对不上——不是谁算错，是口径不同：一个算账面量，一个扣掉了在途和冻结。会开一半在吵数，真正的决策反而没时间。

看板做的第一件事不是画图，是定口径。每一种数字底下写清楚统计规则：库存按可用量，查询按人次，供应商按有效合作；口径定一次，所有图表共用，谁也不能私下再算一版。数据凌晨四点同步完，早八点看到的永远是今天。四张 KPI 卡，一条十二个月的查询趋势线，一张品类分布饼图，到此为止。

价值落在早会上：从「对数会」变回「决策会」。意外的是趋势线自己会说话——某个月查询量猛涨四成，顺着查下去，发现是一个车间把平台当库存台账在用。这本身就是业务信号，后来促成了车间备料流程的一次梳理。数据先说话，说的常常不是数据的事。

四、查询：一秒钟，一颗料

老周的困境拆开是三件事：编码记不住；叫法不统一——同一颗连接器，研发叫板对板，采购叫 BTB，供应商目录上印的是 0.5mm 40P；价格和库存在不同人手里各有一份，版本比人还多。

查询页因此只留一个搜索框，对名称、编码、规格三个字段做模糊匹配——输「0.5」也能把那颗连接器捞出来；品类树和供应商下拉用来收窄范围；结果表按更新时间排，点开任意一行，右侧抽屉里是这颗料的全部：规格参数、单价、库存、最近一次价格更新日期、替代料、供应商评分。比如搜「板对板」，第一行就是恒润电子那颗 4.6 分的 40P。「更新时间」这个字段是最先加的，也是被问得最多的——「这数是哪天的」这个灵魂拷问，从此有地方看。

上线一个月后统计：搜索平均响应不到一秒，九成查询第一页命中。新来的采购工程师当天就能独立找料，不用再拜师认编码。老周现在接产线电话，一边通话一边把数报了。

五、品类策略：把经验变成刻度

每年做品类策略，最依赖的是几位老品类经理的脑子：哪个品类该压成本，哪个该囤产能，他们心里有数。但数在脑子里，PPT 上只有结论；两个经理地盘交界处，同一个品类，一个说该砍供应商，一个说该加备份，评审会上谁也说服不了谁。最要命的是，人一调动，经验跟着人走。

策略模块把「心里的数」变成三个刻度：供应保障、质量、成本，零到一百分，每个品类每季度按平台里的真实数据自动算。分数往策略标签上挂：成本优先的品类重点看成本分，质量优先的看质量分，双供应商平衡的看供应保障分；标签想改，得写理由、留记录。任意两个品类可以拉出雷达图并排比，分歧在哪一目了然。

评审会从「听结论」变成「看刻度」。前面那场砍与不砍的争论，雷达图挂出来五分钟就有了结论——不是图有魔力，是把两个人的依据摆到了同一张纸上。老经理退休前，他的判断已经沉淀成三年的评分曲线；新人接手，先看曲线，再看物料。

六、报表：一键，且真实

月底出报表，是内勤小陈的固定加班日：从看板抄一组数、从 ERP 导一组数、从比价表拼一组数，光对齐格式就要一两个小时。比慢更头疼的是有人拿着报表来问：「这个数怎么跟你看板上不一样？」——报表和看板是两套代码查的两个库，抄写过程里口径还会悄悄漂移。慢是小事，不真实才是大事。

报表模块和看板共用同一条查询管道，筛选维度一模一样：看板上怎么筛，报表里就怎么筛。点导出，后端用同一个查询把数据写成带格式的 xlsx——表头冻结、列宽排好、数字格式照财务的习惯，不是那种改个后缀冒充 Excel 的 CSV。每一次导出都留痕：谁、几点、筛的什么条件、导了多少行；这些记录反过来又成了看板上「导出次数」那张卡的数据源。

月度报表从半天变成两分钟，小陈的月底加班日取消了；再没人问过「数对不上」——导出即所见。审计来的时候，导出记录直接调出来，一页清单顶过去半小时的解释。报表从此成了平台公信力的一部分。

七、工程手记

前面六章讲业务，这一章讲技术，写给同行：四个当初没写进任何汇报里的决定和事故。

7.1 架构：为什么本地 SQLite 敢扛全公司查询

方案评审时几乎所有人都问过同一个问题：为什么不上个像样的数据库？我的回答是不配——这个平台的负载形状太温和了。写只发生在凌晨同步的那两个小时，白天全是读；活跃用户一百八十七人，峰值并发二十出头；三万条物料主数据加百万级价格流水，撑死几个 GB。这种负载，SQLite 开 WAL 模式后读写互不阻塞，单机读性能富余到可以随便加索引。

真正花心思的是同步和分层。源系统的变更走 binlog 增量解析进来，凌晨再批量对账一次兜底，数据延迟稳定在分钟级，也不跟源系统抢资源。冷热分层解决「表越长越胖」：近十二个月有交易、状态在产的物料留在主表，九成以上查询天生只碰热数据；停产物料和三年前的历史价格压进归档库，冷查询命中时再按需加载。附带的好处是备份简单到不好意思说——拷一个文件完事。这个架构的天花板很清楚：真到了日查询十万次、并发过百的那天就该换。但天花板应该够到了再拆，不该提前三年拆。

7.2 权限：三轮演进

权限我做了三轮，前两轮都是学费。第一轮，可见范围校验：价格、成本、供应商这些敏感字段，每个接口各写各的判断。三十多个接口三十多份规则，新加一个品类要改五处，漏一处就是越权——内测时真出过事：一个只有查询权限的账号从导出接口拿到了成本价，前端按钮藏了，接口没挡住。

第二轮想借力：把应用搬到飞书低代码平台上，组织架构和权限体系直接复用，平台每天推一份数据快照过去。权限确实省心了，但快照天生是隔夜饭，延迟以小时计；更要命的是，三维评分这类复杂交互，低代码的表达力顶到天花板，页面退回到只能看不能查。

第三轮收回自建主站，把前两轮的教训固化成一条铁律：权限只能有一个真相源。所有请求过同一个策略层，谁能看什么字段、哪些行，在一个文件里声明，查询构造器在同一个位置注入行级过滤，三十多份规则收敛成一份。后来新增「供应商门户」角色，只改策略层一处，一小时上线。三轮下来我确认一件事：权限体系的价值不在功能多，在规则永远只有一个出处。

7.3 一个反斜杠引发的排查

上线第二个月，用户报障：一颗料的编码「搜不出来」，但料明明在库里。我按标准动作走：复现，看接口日志，SQL 和参数都打印出来，肉眼检查完全正确；把同样的语句拷进数据库终端手敲，还是零行。参数对、语法对、数据在，三个都对，结果不对，卡了我一晚上。

第二天早上想明白了：那颗料的编码里有个反斜杠。LIKE 查询里，反斜杠是转义符，百分号和下划线是通配符。参数化防住了注入，防不住通配符：输入「100%」会匹配所有 100 开头的料，下划线顶替任意一个字符，反斜杠悄悄吞掉紧随其后的字符。这不是安全问题，是语义问题，参数化管不着。

修法十行代码：查询入口统一加一层转义，反斜杠翻倍，百分号和下划线转义，语句补上 ESCAPE 子句。真正记住的是教训：参数化承诺的是「这段输入不能变成代码」，没承诺「这段输入按字面意思匹配」；模糊查询的通配符是语义，得自己守。从此我的查询测试用例里固定躺着三个刁钻输入：百分号、下划线、反斜杠。它们再也没能上线。

7.4 如果重来

重来一次，架构我不会动，SQLite 今天还是我的答案。会动的，是四件更该早点做的事。第一，权限策略层从第一天就立起来，不给它三十个接口的繁衍时间。第二，字段口径先于代码：项目里一半的返工，源于同一个词在两个系统里含义不同——光一个「库存」，PLM、ERP、仓库三方三种算法；先花两周把每个字段的口径写成契约，后面能省两个月。第三，「报表和看板共用一条管道」不该是吃了亏才补的设计，该是出生时的骨架。第四，决策留痕：每个「当时为什么这么选」写三五行存档——半年后我自己都说不清某张汇总表为什么按周预计算，只好读代码考古。技术债好还，记忆债难还。

八、尾声

现在可以交代了：青岛星曜电子是一家虚构的公司，老周和小陈是拼起来的人，数字做过脱敏和缩放——真实项目里的名字和规模，不能写进公开的长文。但故事的骨架没有虚构：数据散在各处、口径各说各话、经验锁在人脑子里、报表对不上数，这四件事我在每一个制造业团队里都见过，一份不少。

平台真正解决的不是「查得快」，快只是副产品；它解决的是「同一件事只有一个真相」：一颗物料一条编码、一个库存口径、一份评分、一条导出通道。老周们要的从来不是炫技的界面，是八点钟产线打来电话时，能笃定地报出一个数。

你的团队里，大概率也有一位老周。想聊聊物料数据怎么从 Excel 的沼泽里捞出来，欢迎到玄关给我留言；也可以先进在线演示玩一玩——那里有一座缩小的星曜数据平台，数据是假的，问题是真的。