企业官网建设流程全解析

制造业的 ERP 和 MES 这两套系统，做过的人都知道，它们是典型的"历史包袱重、定制程度高、数据割裂严重"的三高系统。我在工厂信息化这个圈子里摸爬滚打了十来年，从最早的 Delphi 单机版 ERP，到后来基于若依框架二次开发的 MES，再到微服务化改造，几乎每一代技术栈都踩过一遍。最近这一年，我一直在琢磨一件事：如果把 AI 当成系统的一等公民，而不是事后挂一个"智能助手"的壳，从零重建一套制造业 ERP/MES，架构上到底应该长什么样？这篇文章就是我这段时间思考和实践的完整记录，包括架构选型的逻辑、核心模块的拆解、实操落地的步骤，以及那些只有真正动过手才会知道的坑。不管你是正在做 ERP/MES 的技术负责人，还是想了解 AI-native 架构到底怎么落地的开发者，相信都能从中拿到一些可以直接抄作业的东西。

1. 为什么传统 ERP/MES 架构撑不住 AI 时代的需求

1.1 传统架构的三个致命伤

先说清楚问题，才能讲明白方案。传统 ERP/MES 的架构，不管是基于 Oracle ERP 那种重型单体，还是基于若依框架快速搭起来的 MES，本质上都是"表单驱动 + 流程引擎"的模式。这个模式在过去的二十年里没什么大问题，因为制造业的核心诉求就是"记录准确、流程可控、报表能出"。但到了今天，这套架构暴露出了三个绕不过去的硬伤。

第一个硬伤是数据模型僵化。传统 ERP 的表结构是围绕"单据"设计的——采购单、销售单、工单、领料单，每张单据的字段在开发阶段就定死了。你想加一个"根据历史数据预测的物料损耗率"字段？对不起，得改表、改代码、改报表，一套流程走下来两周起步。而 AI 模型需要的是灵活的特征输入，它不关心你的单据长什么样，它关心的是"这个工单在当前设备状态、当前人员排班、当前物料批次下，预计良率是多少"。这种需求在传统表结构里根本无处安放。

第二个硬伤是决策逻辑硬编码。传统 MES 里的排产逻辑、质量判定逻辑、异常处理逻辑，全都是 if-else 写死的。比如"当检测值超过上限时触发报警"，这个阈值是工程师拍脑袋定的，定完之后就再也没变过。但实际上，不同批次物料、不同设备磨损状态下的合理阈值应该是动态变化的。AI-native 的思路是让模型从历史数据里学出这个阈值，而不是靠人拍脑袋。

第三个硬伤是系统间数据割裂。ERP 管财务和供应链，MES 管生产执行，QMS 管质量，WMS 管仓库，每个系统一套数据库，靠接口同步。同步延迟、数据不一致、对账困难，这些问题在传统架构里是常态。AI 模型要做出准确预测，需要的是跨系统的全量数据视图，而不是通过接口拼凑出来的碎片。

1.2 AI-native 到底"native"在哪里

很多人把"AI-native"理解成"用了 AI 的系统"，这个理解太浅了。我理解的 AI-native，核心是三条：数据模型为 AI 设计、决策逻辑由模型驱动、系统架构支持模型全生命周期管理。

数据模型为 AI 设计，意味着表结构不能只考虑业务单据，还要考虑特征存储。比如工单表里除了常规字段，还要有"特征向量"字段，或者单独建一张特征表，把设备状态、环境参数、人员技能等维度都结构化存储。决策逻辑由模型驱动，意味着排产、质检、预警这些环节，不再是写死的规则，而是调用模型推理服务，模型输出结果后再由业务逻辑做兜底。系统架构支持模型全生命周期管理，意味着要有模型训练、版本管理、A/B 测试、灰度发布、效果监控这一整套基础设施。

这三条听起来简单，但落地的时候会发现，它要求整个系统的分层方式、数据流向、部署模式都要重新设计。这也是为什么我说"从零重建"比"在现有系统上改造"更靠谱——改造的话，你永远在跟历史包袱做斗争。

1.3 重建 vs 改造：一个务实的判断

当然，从零重建的成本是巨大的。我在决定重建之前，认真评估过改造方案。改造的核心思路是在现有系统旁边挂一个"AI 中台"，通过数据同步把业务数据抽到中台，在中台里做模型训练和推理，再把结果写回业务系统。这个方案的问题是：数据同步有延迟，模型拿到的永远是"过去时"的数据；写回结果又要走一遍业务校验，链路太长；而且业务系统的表结构不支持特征存储，很多有价值的原始数据在录入阶段就丢失了。

所以我的判断是：如果企业规模不大，业务逻辑相对标准，改造方案可以接受；但如果是要做一套支撑未来五到十年发展的核心系统，而且 AI 应用是战略级的，那从零重建更划算。重建的关键是先把架构设计对，再动手写代码，否则重建出来的东西过两年又变成新的历史包袱。

2. AI-native 制造业 ERP/MES 的整体架构设计

2.1 分层架构：从五层到"四层 + 一个平面"

传统企业级架构一般分五层：表现层、应用层、服务层、数据层、基础设施层。我在设计这套系统的时候，把它改成了"四层 + 一个平面"：交互层、智能决策层、业务服务层、数据层，加上一个贯穿所有层的 AI 基础设施平面。

为什么这么分？因为 AI-native 系统里，模型推理不是一个独立的服务，而是渗透在每一层的。交互层需要自然语言理解，业务服务层需要智能排产，数据层需要向量检索，这些都需要 AI 基础设施的支撑。如果按传统五层分，AI 能力会被割裂到各个层里，没法统一管理。

AI 基础设施平面包含的东西很多：特征存储、模型仓库、推理服务、向量数据库、模型监控、实验管理。这些东西不是某一层专属的，而是所有层都可以调用的公共能力。这个设计思路借鉴了微服务架构里"服务网格"的概念——把横切关注点抽出来，做成一个独立的平面。

2.2 核心模块划分与职责边界

模块划分上，我把它分成了六大核心模块：主数据管理、供应链协同、生产执行、质量管理、设备管理、经营分析。每个模块的职责边界要划清楚，否则又会变成传统 ERP 那种"什么都在一个模块里"的混乱局面。

主数据管理负责物料、BOM、工艺路线、供应商、客户这些基础数据的维护。这个模块的特殊之处在于，它要为 AI 模型提供"标准化的特征源"。比如物料主数据里除了常规属性，还要有物料的物理特性、历史质量表现、供应商交付表现等特征字段。

供应链协同负责采购、销售、库存、物流。这个模块的 AI 应用场景主要是需求预测、库存优化、供应商风险评估。生产执行负责工单、排产、报工、追溯。AI 应用场景是智能排产、异常预警、良率预测。质量管理负责检验、SPC、不合格品处理。AI 应用场景是缺陷检测、质量预测、根因分析。设备管理负责设备台账、点检、维修。AI 应用场景是预测性维护、故障诊断。经营分析负责报表、看板、决策支持。AI 应用场景是自然语言查询、智能归因。

2.3 技术选型：为什么选这些而不是那些

技术选型这块，我纠结了很久。后端语言上，Java 和 Python 之间我最终选了"Java 做业务服务 + Python 做 AI 服务"的混合方案。Java 生态在企业级应用上成熟度更高，事务管理、权限控制、分布式协调这些都有现成的轮子；Python 在 AI 生态上是绝对优势，PyTorch、scikit-learn、pandas 这些库没法替代。两者之间通过 gRPC 通信，性能比 REST 好，而且支持流式传输。

数据库选型上，我用了"PostgreSQL + TimescaleDB + Milvus"的组合。PostgreSQL 做业务数据的主库，它的 JSONB 类型对半结构化数据支持很好，适合存特征。TimescaleDB 是 PostgreSQL 的时序扩展，用来存设备传感器数据、生产节拍数据这些时序数据。Milvus 做向量检索，用来支持相似案例检索、语义搜索这些场景。

消息队列用了 Kafka，主要是看中它的吞吐量和持久化能力。制造业现场的数据量很大，一个中型工厂一天产生的传感器数据可能就有几个 GB，Kafka 扛得住。缓存用了 Redis，这个没什么好说的，标配。

前端框架选了 React + TypeScript，UI 库用了 Ant Design。这个组合在制造业管理系统里很常见，组件丰富，开发效率高。移动端用了 React Native，一套代码同时支持 Android 和 iOS，工厂现场用平板和手机的场景越来越多，这个投入是值得的。

3. 数据层设计：让数据为 AI 服务

3.1 业务数据与特征数据的分离存储

数据层设计是整套系统的地基，这块如果设计错了，后面全是坑。我的核心思路是业务数据和特征数据分离存储。业务数据就是传统的单据数据，存在 PostgreSQL 里，保证 ACID。特征数据是从业务数据里抽取出来的、面向模型训练和推理的数据，存在专门的特征存储里。

为什么要分离？因为两者的访问模式完全不同。业务数据的访问是"按单据 ID 查单条记录"，特征是"按时间窗口批量拉取某个实体的所有特征"。如果混在一起存，查询性能会互相影响。而且特征数据需要频繁地做批量计算和更新，业务数据则要求强一致性，两者的运维策略也不一样。

特征存储我选的是 Feast 这个开源框架，它支持离线存储和在线存储两套。离线存储用 Parquet 文件存在对象存储上，用于模型训练；在线存储用 Redis，用于推理时的实时特征读取。Feast 的好处是它把特征定义、特征计算、特征服务这三件事统一管理起来了，避免了"训练时用的特征和推理时用的特征不一致"这个经典问题。

3.2 时序数据的处理策略

制造业现场最不缺的就是时序数据。设备传感器每秒上报一次温度、压力、振动，一条产线几十台设备，一天下来就是几千万条记录。这些数据的处理策略直接决定了系统能不能扛住。

我的方案是三级存储：热数据存 TimescaleDB，保留最近 7 天，支持实时查询；温数据存对象存储的 Parquet 文件，保留最近 1 年，支持批量分析；冷数据归档到低成本存储，保留 3 年以上，只在需要时拉取。

TimescaleDB 的使用有几个关键点。第一是分区策略，我按设备 ID 做哈希分区，按时间做范围分区，这样查询单台设备的历史数据时只需要扫描一个分区。第二是压缩策略，超过 7 天的数据自动压缩，压缩率能到 10 倍以上。第三是连续聚合，把原始数据按分钟、小时、天做预聚合，查询聚合指标时直接查聚合表，不用扫原始数据。

注意：TimescaleDB 的压缩是不可逆的，压缩前一定要确认数据已经不需要做细粒度的更新操作。我踩过一次坑，压缩之后发现有个字段的解析逻辑写错了，想改都改不了，只能重新导入。

3.3 向量数据库的引入与使用场景

向量数据库是 AI-native 架构里比较新的东西，很多人不清楚它到底用来干什么。在我的设计里，Milvus 主要承担三个场景：相似案例检索、语义搜索、推荐。

相似案例检索是质量管理和设备管理里的刚需。比如某个工单出现了质量问题，工程师想知道"历史上有没有类似的案例，当时是怎么解决的"。传统做法是按关键词搜，但关键词搜不准。用向量检索，把每个历史案例的文本描述、工艺参数、设备状态都编码成向量，查询时把当前问题也编码成向量，算余弦相似度，就能找到真正相似的案例。

语义搜索用在知识库和文档管理上。工厂里有大量的作业指导书、设备手册、工艺文件，传统搜索只能按文件名或标签搜，用向量检索可以做到"用自然语言描述你要找什么，系统帮你找出来"。

推荐用在两个地方：一是给操作工推荐最优的工艺参数，二是给采购推荐替代供应商。这两个场景本质上都是"根据历史数据找最相似的场景，然后推荐当时的最优选择"。

Milvus 的部署我选的是单机版，因为制造业的数据量还没到需要分布式集群的程度。索引类型用了 HNSW，查询速度快，召回率也够用。向量维度是 768，用的是开源的文本编码模型，具体哪个模型可以根据实际效果调。

4. 智能决策层：模型怎么嵌入业务流程

4.1 模型服务化的三种模式

模型要嵌入业务流程，有三种模式：同步调用、异步调用、批量计算。这三种模式适用的场景完全不同，选错了会严重影响系统性能。

同步调用适合"实时性要求高、模型推理快"的场景，比如质量判定。工单报工时，系统需要立刻判断这个产品是合格还是不合格，这时候就同步调用质量预测模型，模型在 100 毫秒内返回结果，业务逻辑根据结果决定下一步操作。同步调用的关键是超时兜底，模型服务如果挂了或者超时了，业务逻辑必须有降级方案，不能因为模型不可用导致产线停线。

异步调用适合"实时性要求不高、模型推理慢"的场景，比如排产优化。排产是一个复杂的组合优化问题，模型可能需要几秒钟甚至几分钟才能算出结果。这种场景下，业务系统提交排产请求后不等待结果，而是通过消息队列异步通知。模型算完后把结果写回数据库，前端轮询或者通过 WebSocket 推送。

批量计算适合"周期性执行、数据量大"的场景，比如需求预测。每天晚上跑一次，把未来一个月的需求预测算出来，存到数据库里供第二天使用。批量计算用 Spark 或者 Python 脚本都可以，关键是任务调度和失败重试要做好。

4.2 排产模型的落地实践

排产是 MES 里最核心也最复杂的模块，我在这块花的时间最多。传统排产靠人工经验或者简单的规则引擎，AI-native 的排产要综合考虑交期、产能、物料、人员、设备状态等多个约束，目标函数可以是"最小化总延迟"或者"最大化设备利用率"。

我的实现方案是**"规则引擎 + 强化学习"的混合架构**。规则引擎负责处理硬约束，比如"某台设备今天必须停机保养"、"某个订单必须优先生产"，这些是绝对不能违反的。强化学习模型负责在满足硬约束的前提下，优化软目标，比如"尽量减少换型次数"、"尽量均衡各设备负载"。

强化学习模型的训练环境是自己搭的仿真器，把历史工单数据、设备状态数据、工艺参数数据都灌进去，让模型在仿真环境里反复试错。训练好的模型部署成推理服务，排产时调用。这里有个关键点：模型输出的排产方案必须经过规则引擎校验，确保不违反硬约束。我见过有团队直接拿模型输出就用，结果排出来的计划违反了安全规程，这是绝对不能接受的。

排产效果的评估指标我用了三个：订单准时交付率、设备平均利用率、平均换型次数。上线后对比人工排产，准时交付率提升了 8 个百分点，设备利用率提升了 5 个百分点，换型次数减少了 15%。这个提升幅度不算惊艳，但考虑到制造业的基数大，换算成经济效益是很可观的。

4.3 质量预测与根因分析

质量预测是另一个核心场景。传统 MES 的质量管理是"事后检验"，产品做完了再检，不合格就返工或报废。AI-native 的质量管理要做到"事前预测、事中控制"。

事前预测是在工单开始前，根据物料批次、设备状态、工艺参数、人员技能等特征，预测这个工单的良率。如果预测良率低于阈值，系统会提前预警，让工程师介入调整。事中控制是在生产过程中，实时监控关键参数，一旦发现偏离正常范围，立刻调整或者停机。

根因分析是质量管理的难点。产品出现缺陷后，要找出是哪个环节、哪个参数导致的。传统做法是靠工程师经验，一个个排查。AI 的做法是用因果推断模型，从历史数据里学出"哪些参数的异常会导致缺陷"。这里要注意，相关性不等于因果性，直接用相关性分析会得出很多误导性的结论。我用的是 DoWhy 这个因果推断框架，它能区分相关关系和因果关系，给出的根因更可靠。

5. 业务服务层的微服务拆分与治理

5.1 服务拆分的粒度怎么把握

微服务拆分最怕两件事：拆得太细，服务间调用复杂，运维成本高；拆得太粗，又变成了分布式单体。我的经验是按业务能力拆分，而不是按技术分层拆分。

具体来说，我拆了这些服务：主数据服务、采购服务、销售服务、库存服务、工单服务、排产服务、报工服务、质量服务、设备服务、报表服务。每个服务对应一个业务能力，有自己的数据库，通过 API 对外暴露能力。

拆分的粒度判断标准是：如果一个功能的变化频率和另一个功能差异很大，就应该拆开。比如排产逻辑经常调整，而库存管理相对稳定，这两个就应该拆成独立服务。反过来，如果两个功能总是一起变化，那就不应该拆开，否则每次改动都要同时发布两个服务，反而麻烦。

5.2 服务间通信与数据一致性

服务拆开之后，数据一致性就成了大问题。传统单体应用里，一个事务能搞定的事，拆成微服务后就要用分布式事务。我的原则是尽量避免跨服务的事务，如果避免不了，用最终一致性而不是强一致性。

具体做法是：核心业务操作只在一个服务内完成，跨服务的操作通过事件驱动的方式异步处理。比如报工服务完成报工后，发一个"工单已完成"的事件到 Kafka，库存服务消费这个事件后扣减库存，质量服务消费后触发检验任务。这样每个服务只关心自己的事务，通过事件来协调。

这里的关键是事件要可靠投递。我用的是 Kafka 的事务生产者，保证事件发送和本地事务的原子性。消费端用幂等消费，防止重复处理。这套机制搭起来有点复杂，但一旦搭好，后面加新服务就很方便了。

5.3 服务治理：限流、熔断、降级

微服务架构下，一个服务挂了可能引发雪崩。服务治理是必须做的，我用的是 Sentinel 做限流和熔断，用 Nacos 做服务注册和配置管理。

限流策略上，我按服务的重要程度分了三级。核心服务比如报工、质量判定，限流阈值设得很高，保证产线不停；非核心服务比如报表、分析，限流阈值设得低一些，高峰期可以降级。熔断策略上，我设置了慢调用比例和异常比例两个指标，任何一个超过阈值就熔断，熔断后走降级逻辑。

降级逻辑要提前设计好。比如排产服务不可用时，降级到"按交期先后顺序排产"的简单规则；质量预测服务不可用时，降级到"按固定阈值判定"。降级不是失败，而是"用次优方案保证业务继续"。

6. 实操落地：从零搭建的关键步骤

6.1 环境准备与基础设施搭建

动手之前，先把基础设施搭好。我用的是 Docker Compose 做本地开发环境，Kubernetes 做生产环境。本地环境包含 PostgreSQL、TimescaleDB、Milvus、Redis、Kafka、Nacos 这些组件，用 Docker Compose 一键启动。

生产环境的 Kubernetes 集群，我建议至少三个节点，每个节点 16 核 64G 起步。制造业的数据量和计算量都不小，配置太低跑不动。存储用 NFS 或者 Ceph，数据库用云厂商的托管服务更省心，如果自建的话要做好备份和容灾。

部署顺序上，先部署基础设施（数据库、消息队列、注册中心），再部署 AI 基础设施（特征存储、模型仓库、推理服务），最后部署业务服务。每部署一层，都要做健康检查，确保下层可用后再部署上层。

6.2 核心服务的开发与调试

开发顺序上，我建议先做主数据服务和工单服务，这两个是其他服务的基础。主数据服务提供物料、BOM、工艺路线这些基础数据，工单服务提供生产任务的管理。这两个服务跑通了，其他服务才有数据可用。

调试的时候，我强烈建议先写集成测试，再写单元测试。微服务架构下，单个服务的逻辑往往很简单，复杂的是服务间的交互。集成测试用 Testcontainers 启动真实的依赖组件，能发现很多单元测试发现不了的问题。

接口调试用 Postman 或者 Apifox，把常用接口做成集合，方便回归测试。日志用 ELK 收集，每个服务打日志时带上 traceId，方便追踪一个请求跨多个服务的完整链路。

6.3 模型训练与部署的工程化

模型训练不是跑个 notebook 就完事了，要工程化。我用的是 MLflow 做实验管理和模型注册，用 Airflow 做训练任务调度，用 ONNX Runtime 做推理加速。

训练流程是这样的：Airflow 定时触发训练任务，任务从特征存储拉取训练数据，用 PyTorch 训练模型，训练完成后把模型和指标记录到 MLflow，如果指标超过当前生产模型，就注册为新版本。部署时，推理服务从 MLflow 拉取指定版本的模型，加载到内存中提供服务。

模型更新要灰度发布。新模型上线后，先切 10% 的流量，观察一周，指标没问题再逐步扩大。如果指标下降，立刻回滚到旧版本。这套机制听起来简单，但真正做起来，模型版本管理、流量切换、指标监控这些都要有配套工具，不然全靠人工操作，迟早出问题。

7. 常见问题与排查技巧实录

7.1 数据一致性问题的排查

微服务架构下，数据不一致是最常见的问题。我遇到过一个典型案例：报工服务显示工单已完成，但库存服务显示物料还没扣减。排查下来发现是 Kafka 消息积压，库存服务的消费速度跟不上生产速度。

排查这类问题的思路是：先看消息队列的积压情况，再看消费端的处理日志，最后看数据库的实际状态。如果消息积压，要么是消费端处理太慢，要么是消费端挂了。处理太慢的话，可以增加消费者实例，或者优化消费逻辑。消费端挂了的话，看日志找原因，重启后要注意幂等处理，防止重复消费。

预防这类问题的办法是做好监控和告警。Kafka 的 lag 超过阈值就告警，消费失败的消息进死信队列，人工介入处理。数据库层面，定期做对账，发现不一致及时修复。

7.2 模型推理性能优化

模型推理慢是另一个常见问题。我遇到过一个质量预测模型，单次推理要 500 毫秒，产线根本等不了。优化下来发现，瓶颈在特征读取上，每次推理都要从 Redis 拉几十个特征，网络往返时间占了大头。

优化方案是批量读取特征 + 本地缓存。把同一个工单需要的所有特征一次性拉取，减少网络往返。对于变化不频繁的特征，缓存在推理服务本地，设置合理的过期时间。优化后单次推理降到了 50 毫秒以内。

另一个优化方向是模型量化。把 FP32 的模型量化成 INT8，推理速度能提升 2 到 4 倍，精度损失通常在 1% 以内。用 ONNX Runtime 做量化很方便，几行代码就能搞定。但要注意，量化后的模型要重新做精度验证，确保业务指标没有明显下降。

7.3 常见问题速查表

提示：这张表是我从实际运维中总结出来的，覆盖了 80% 的常见问题。遇到新问题时，先对照这张表排查，能省不少时间。

8. 我在这套架构上踩过的坑与经验总结

8.1 不要过早引入 AI

这是我踩过的最大的坑。项目刚开始的时候，我雄心勃勃，想把所有环节都 AI 化，结果发现很多场景根本不需要 AI。比如物料编码的生成，用规则就能搞定，非要上模型，纯属给自己找麻烦。

我的经验是：先用规则跑通业务，再逐步用 AI 替换规则。规则的好处是透明、可控、好调试，业务跑通之后，你才知道哪些环节是真正的瓶颈，哪些环节 AI 能带来最大价值。一上来就全 AI，往往是既没跑通业务，也没做好 AI。

8.2 数据质量比模型算法重要

另一个深刻的体会是：数据质量决定了 AI 效果的上限。我见过太多团队，模型换了一个又一个，效果就是上不去，最后发现是数据的问题。制造业的数据质量普遍不高，传感器数据有噪声，人工录入的数据有错误，历史数据有缺失。

解决数据质量问题，没有捷径，就是老老实实做数据治理。建立数据标准，做数据清洗，补全缺失值，剔除异常值。这个过程很枯燥，但省不得。我的做法是在数据层加一个"数据质量监控"模块，实时监控关键数据的完整性、准确性、及时性，发现问题及时告警。

8.3 组织变革比技术变革更难

最后说一个非技术的问题。AI-native 系统上线后，最大的阻力往往不是技术，而是人。操作工习惯了按按钮，你让他看 AI 推荐的参数，他不信任；工程师习惯了拍脑袋定阈值，你让他看模型算出来的阈值，他觉得不靠谱。

解决这个问题，关键是让 AI 的结果可解释、可干预。模型给出推荐时，要同时给出推荐的理由，比如"推荐这个参数是因为历史上类似工况下这个参数的良率最高"。同时，要允许人工覆盖 AI 的决策，并且把人工覆盖的数据收集起来，用于后续的模型优化。这样既尊重了人的经验，又让模型能持续学习。

这套系统从设计到上线，前后花了我将近一年的时间。中间经历过推倒重来，也经历过上线后回滚。但回头看，这套架构的方向是对的，AI-native 不是噱头，而是制造业系统演进的必然趋势。如果你也在做类似的事情，我的建议是：架构设计要激进，落地实施要保守。架构上要敢于为 AI 留出空间，实施上要一步一步来，先把基础打牢，再逐步叠加 AI 能力。