企业官网建设流程全解析

简介：围绕AI大模型与数字化工厂融合的专题演示文稿，面向智能制造、工业软件及数字化转型领域的从业者与方案架构师。内容以工业4.0为背景，系统阐述MES、WMS、SCADA与IoT多系统协同下的智能化工厂建设思路，从技术架构、智能生产优化、物流仓储管理到人机协同决策、环境安全升级与实施保障，均给出模块化阐述，并具体涉及生产计划动态预测、质量追溯、预测性维护、AGV路径规划、供应链风险预警等落地场景。整个资料包共1个文件，为pptx演示文稿，大小约614KB，结构完整清晰，便于方案汇报、内部培训或在此基础上做二次整理。已有37人学习，可作为快速理解AI大模型在数字化工厂中应用路径的参考。通过数据流闭环与持续迭代思路，读者能抓住从感知、分析、决策到执行的整体框架，适合用于项目预研与方案规划。

1. AI 大模型赋能数字化工厂：这套方案解决的不仅是报表，是人机协同的最后一公里

在 MES+WMS+SCADA+IoT 已经跑了一两年的工厂里，最不缺的就是数据和报表，最缺的反而是“人怎么跟这一堆系统对话”。AI 大模型进数字化工厂，落点不是做一个花哨的聊天机器人，而是把人从“扒数据、对字段、猜原因”里解放出来。这套人机一体化智慧解决方案，本质是在已有的制造执行、仓储管理、过程监控和设备物联四层体系之上，加一层 AI 推理与交互中枢。适合正在做数字化转型规划、或者已经在用 MES/WMS 但觉得系统越来越重的工厂 IT、MES 产品经理和售前方案人员。方案的价值不在 PPT 多华丽，而在能不能回答一个最简单的问题：车间里的普通人，今天能不能用一句话拿到本来要翻三个系统才能凑齐的答案。

2. 先理清四个系统的边界：MES、WMS、SCADA、IoT 在 AI 大模型方案里各自扮演什么角色

2.1 四个系统是数据源而不是终点：AI 大模型要接哪几类数据

数字化工厂的现状是：MES 管工单和质量，WMS 管物料批次和库位，SCADA 管过程参数和报警，IoT 管设备状态和点检。这四个系统本来就各拉各的数据，报表上一看都是“数字化”。但 AI 大模型方案要的不是报表，而是要在这四套数据之上形成推理能力。所以第一步不是选模型，而是把数据边界画清楚。

MES 系统这边，AI 最需要的是未结工单、工艺路线、物料清单、质检记录这四类。工单是排产和调度推理的锚点，质检记录是质量归因的样本，工艺路线是 SOP 问答的依据。这里有个极易踩的坑：MES 里字段名跟业务叫法不一致。比如系统里叫 res_code，车间叫机台号，提示词喂进去之前必须做一层字段映射，否则大模型会理解错。

WMS 系统给 AI 的是库存水位、批次效期、库区和出库波次。关键不是 WMS 的单据，而是“齐套率”这种跨系统语义。齐套率等于物料可用量除以工单需求量，可用量在 WMS，需求量在 MES，AI 要同时看到两边才能回答“3 号工单能不能开工”。这就决定了你在设计接入层时，不能按系统分接口，而要按语义组装上下文。

SCADA 的数据比较特殊，它是时序的，每秒一条。AI 大模型没法把几百万条时序点塞进上下文窗口。常见的做法是让接入网关先做形态变换：稳定段取均值，波动段取最大值、最小值和斜率，再把压缩后的特征文本送给大模型。国内主流的中控 SCADA、开源领域的 Rapid SCADA 都提供点位读取接口，但读点位这个动作不能放在提示词里让模型自己来，要通过程序把点位状态先翻译成文本。

IoT 设备层给出的则是振动、温度、电流等传感器数据。相比 SCADA，IoT 更偏设备健康管理，数据分散在边缘网关或时序数据库里。AI 在这一层的主要用途是设备告警归因和设备手册问答。IoT 数据的单位、采集频率、传感器位置命名，最好在接入层就统一掉，否则模型会被“10 号传感器”这种歧义搞到胡言乱语。

我给客户的第一个交付物从来不是模型，而是一张数据地图，包含四列：系统、取数接口、关键字段、更新频率。这张图确定了，再谈选哪个模型、上下文怎么做片段化。没有这张基础图，后面提示词写得再漂亮也是空中楼阁。

2.2 人机一体化落点：AI 在制造执行层和仓储物流层的五个切入场景

“人机一体化”不是把 AI 挂成系统旁边的一个问答框，而是让人在关键决策点上用自然语言讲清需求，系统拿真实数据加模型推理把结果回给用户。我从项目里筛出五个验证过最容易被业务接受的场景。

场景一是排产辅助。计划员问“明天 A 线能不能插单”，AI 要拉取 A 线当前工单、在制 WIP、物料齐套率、设备状态，再结合交期输出一句话建议和理由。这个场景不需要模型自己写 SQL，需要的是模型能组织并解释结构化数据，所以上下文质量比模型智商更重要。

场景二是质量异常的根因归因。检验员发现连续三件产品尺寸超差，AI 把近两小时的压力、温度、转速特征曲线和这批次的物料批次、设备编号一起做关联分析。它不直接下结论，而是给出“压力波动与尺寸超差相关性最高，建议优先检查三号工位夹具”这类可操作线索。这里的边界是：AI 是线索生成器，不是质量判定系统。

场景三是 SCADA 报警解释。半夜响起报警，值班员最痛苦的是看不懂报警码。SCADA 触发 P-105 泵压力低报警时，AI 结合设备台账、历史维修记录生成一段“报警原因、影响范围、建议处置”的解释。值班员能一眼决定是跑现场还是继续观察，这是价值最直观的场景，因为报警码翻译这件事没有歧义空间，模型翻车也少。

场景四是 WMS 波次策略。仓库主管问“今晚这批订单用边拣边分还是按单拣货”，AI 看订单件型、库区分布、拣货设备忙闲，给出建议。这里要非常克制，模型只给建议，执行还是由 WMS 完成，人保留最终确认权。

场景五是设备运维问答。维护员问“主轴异响一般先查什么”，AI 基于设备手册、维修工单、备件库存做检索增强问答。这是最容易落地也最容易出效果的场景，因为数据和答案边界都很清晰，而且不涉及实时决策，容错空间大。

五个场景有个共性：AI 大模型一定是在“有据可查”的上下文里输出。凡是靠模型自由发挥的，最后都会翻车。这决定了方案里必须要有数据接入层、上下文组装层和模型调用层，而不是直接把公开问答模型对着 ERP 数据库莽上去。

3. 把 AI 大模型接进 MES/WMS/SCADA：可落地的技术架构与调用链路

3.1 基于什么技术栈封装 AI 交互逻辑：RAG、工具调用和 SSE 流式输出的分工

在工厂场景里谈技术栈，最容易犯的错是把所有交互都做成“聊天框”。实际操作上我按三种场景拆交互逻辑。

知识库类问答，比如设备手册、工艺文件、工单查询，用 RAG 检索增强。先根据问题向量召回相关片段，再连同问句一起交给大模型。这类交互逻辑对实时性要求不高，但对答案的可溯源性要求高，用户要能点回原文。

需要查实时数据或者触发动作的，用工具调用。让大模型先输出一个结构化意图，比如查询库存、查询设备状态，再由网关里的函数去执行并拿结果返回给模型组织语言。这里的关键是工具清单要收敛，不要放十几个函数进去，模型会选错。我一般控制在三到五个核心工具。

输出长内容时必须用 SSE 流式输出，把增量文本一点点推到前端做实时渲染，而不是等几十秒后一次性吐一屏。配合前端 AbortController 的 Abort 能力，用户点击“停止生成”后，前端中断渲染，后端连接也断开，不再继续空跑算力。这三个组合下来，技术栈基本固定：后端 Python FastAPI 做网关，前端标准 EventSource 或 fetch ReadableStream，模型层走 OpenAI 兼容协议，方便在云端 API 和本地部署之间无痛切换。

3.2 用 Python 搭一个 AI 推理网关：对接 MES 工单、返回排产建议的代码骨架

下面是一个最小可跑的 AI 推理网关，读取 MES 未结工单组装上下文，再通过 SSE 流式把大模型回答回给前端。这段代码只做一件事：跑通 MES 到模型到浏览器的完整链路。

# ai_gateway.py —— AI 推理网关最小骨架 from fastapi import FastAPI, Request from fastapi.responses import StreamingResponse import httpx app = FastAPI() MES_API = "http://mes-service:8080" # MES 系统接口地址 LLM_API = "http://llm-server:8000/v1/chat/completions" # 本地大模型 API def pull_open_orders(): """从 MES 拉取未结工单，压缩成适合提示词的紧凑文本""" resp = httpx.get( f"{MES_API}/api/v1/work-orders", params={"status": "OPEN", "within": "48h"}, timeout=5 ) orders = resp.json().get("data", []) lines = [] for o in orders[:15]: # 最多 15 条，防止上下文超过窗口限制 lines.append( f"工单{o.get('order_no')}：产品{o.get('product_name')}，" f"数量{o.get('plan_qty')}，设备{o.get('line_no', '未分配')}，" f"交期{o.get('due_time')}" ) return "\n".join(lines) def stream_llm(messages): """把请求转发给大模型，逐行读取 SSE 事件并转发给前端""" payload = { "model": "local-model-name", # 按实际部署的模型名替换 "messages": messages, "stream": True, "temperature": 0.2, } with httpx.stream("POST", LLM_API, json=payload, timeout=120) as resp: for line in resp.iter_lines(): if line.startswith("data: ") and line != "data: [DONE]": yield line[6:] + "\n" @app.post("/chat") async def chat(req: Request): body = await req.json() question = body.get("question", "") orders_ctx = pull_open_orders() messages = [ {"role": "system", "content": "你是工厂排产助理。只能依据给定的工单信息回答，不编造工单，不修改物料编码。"}, {"role": "user", "content": f"当前未结工单如下：\n{orders_ctx}\n\n问题：{question}"} ] return StreamingResponse(stream_llm(messages), media_type="text/event-stream")

这段代码里几个参数值得单独说。pull_open_orders 里 timeout=5 是刻意设的，MES 接口变慢时网关要快速失败，而不是让用户等模型干等两分钟。[:15] 切片是为了控制上下文长度，15 条工单约一千来个字，给模型留出推理余量。temperature 设在 0.2，排产建议这种场景要低随机性。stream_llm 里排除掉 [DONE] 标记，只把有效内容转发出去。

前端这边配合的是 fetch 加流式读取，加上 AbortController 控制中断。

// 前端流式渲染 + Abort 控制 const controller = new AbortController(); async function askAI(question) { const resp = await fetch("/chat", { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ question }), signal: controller.signal, }); const reader = resp.body.getReader(); const decoder = new TextDecoder(); let content = ""; while (true) { const { done, value } = await reader.read(); if (done) break; content += decoder.decode(value, { stream: true }); renderStreamingContent(content); // 把增量文本实时渲染到页面 } } // 用户点“停止”时调用 document.getElementById("stopBtn").onclick = () => controller.abort();

AbortController 在这里的价值不只是省流量的。工厂现场工控机上网络不稳定，用户发出一个长问题，模型回答到一半用户已经拿到想要的判断，这时候让他等完整回答是反人性的。有 abort 能力，用户能随时打断，后端 StreamingResponse 感知连接断开后也会停止生成，算力不浪费。

3.3 把 SCADA 与 IoT 实时数据喂给大模型：时序切片与上下文窗口的取舍

SCADA 和 IoT 数据是最难喂给大模型的，根本原因是量级不匹配。一套中控 SCADA 系统一个车间就可能上万个点位，一秒一条数据，一天数据能到亿级。直接把原始序列丢给模型，任何上下文窗口都撑不住。

我的做法是三层处理。第一层是采样降频。对稳定运行的连续变量，比如冷却水温，直接取五分钟均值就够了。对波动型变量，比如压力、电流，额外记录最大值、最小值和变化率。第二层是事件切片。只在报警触发或质量异常时才把前后五分钟的特征值提取出来组装上下文，平时不调用模型，节省推理成本。第三层是点位映射。设备编号、传感器编码全部转换成业务语言再进提示词，比如 sensor_03 写成“三号工位主轴温度”。

IoT 侧还要多做一件事：边缘网关先做清洗。振动传感器经常有毛刺数据，不先做滤波，模型会基于噪声做归因，结论完全不可用。趋势大于精确值，这是 SCADA 和 IoT 数据接入的准则。

4. 本地部署与 API 调用怎么选：算力、延迟和数据不出厂约束下的决策

4.1 先算三笔账：显存、并发、延迟

本地部署 AI 大模型这件事，在方案 PPT 里一句话，落地时是纯算力问题。做决策前先算三笔账。

第一笔是显存。模型参数量决定显存下限。工厂场景绝大多数任务用 7B 到 14B 参数量级别的模型就够，不需要上超大模型。16G 显存的消费级卡刚好能跑 4bit 量化后的 7B 模型做验证，但生产环境我建议至少 24G 起步，留出并发余量。

第二笔是并发。工厂里的 AI 方案不会像互联网那样有几万用户同时在线，但早班交班那十分钟，操作员会集中提问。并发哪怕只有五个，显存也要按五份算。手里一张卡跑一个模型，并发上来后每请求延迟成倍增加。

第三笔是延迟容忍度。排产问答要求十秒内返回，操作员等不了。质量归因分析可以接受一两分钟，毕竟是离线式的深度分析。RAG 类问答要控制在五秒以内，这里面大模型推理时间可能只占一半，另一半是检索时间。

三种场景混在一个模型服务里时，我一般按最高要求设超时，也就是十秒。再长就直接提示失败，不要吊着用户。

通用参考配置如下表。量化位数越低，显存占用越少，但输出质量会轻微下降，核心业务场景别低于 4bit。

4.2 本地部署的推荐启动方式与参数：一次别贪多

本地部署我习惯用支持 OpenAI 兼容接口的推理框架，这样上层代码不用绑死某个服务。下面是 vLLM 框架启动一个量化模型的参考命令，生产环境我会加几个关键参数。

# 本地部署大模型：vLLM 启动参考命令 python -m vllm.entrypoints.openai.api_server \ --model /data/models/factory-7b-awq \ --served-model-name factory-llm \ --quantization awq \ --max-model-len 8192 \ --gpu-memory-utilization 0.85 \ --max-num-seqs 4 \ --host 0.0.0.0 \ --port 8000

--max-model-len 设 8192，这是工厂上下文的合理值。设太大显存不够，设太小工单列表加系统提示词就溢出了。--gpu-memory-utilization 设 0.85，不跑满显存，给 KV cache 留余量，也避免偶发峰值导致 OOM。--max-num-seqs 控制同时处理的请求数，设 4 对企业内一个小团队足够，峰值时后面的请求排队而不是挤爆显存。--served-model-name 是让网关调用的名字，代码里 model 参数对应这个值。

很多团队一上来就部署 70B 大模型，结果一张卡跑不动，量化后效果变差，最后怪模型不行。我的实际经验：先把 7B 级别在当前车间跑顺几个场景，再评估要不要升级。工厂场景的专业性不在模型大小，在上下文质量。

4.3 用云端 API 快速验证效果，再无缝切到本地

方案初期可以用成熟大模型 API 验证提示词和场景效果。等确认了 prompt 模板和上下文组装逻辑后，再切到本地部署。切换的成本几乎为零，因为本地推理框架普遍提供 OpenAI 兼容接口。

# 切换 base_url 就能从云端 API 迁移到本地模型 from openai import OpenAI client = OpenAI( base_url="http://10.10.1.15:8000/v1", # 本地推理服务地址 api_key="local-key-placeholder", # 本地服务通常不校验，但参数必须存在 ) resp = client.chat.completions.create( model="factory-llm", # 对应 --served-model-name messages=[ {"role": "system", "content": "你是工厂车间调度助手，能看懂 MES 工单上下文。"}, {"role": "user", "content": "帮我检查 3 号工单的物料是否齐套。"} ], stream=True, temperature=0.3, ) for chunk in resp: if chunk.choices[0].delta.content: print(chunk.choices[0].delta.content, end="")

注意 api_key 这里纯粹占位。本地服务大多不校验密钥，但 SDK 要求传这个字段。迁移时改动就 base_url 一行，业务代码不用动，这个便利性在方案验证阶段能省下大量返工。

4.4 提示词温度与上下文窗口的参数设置：分场景，不要一套打天下

模型参数不是玄学，但在工厂场景里确实需要分场景设置。排产建议追求稳定可解释，temperature 设在 0.2 附近。质量归因需要一点发散来找线索，可以放到 0.4，但再高就满嘴跑火车了。设备维修问答严格按照手册来，0.1 比较稳。top_p 我一般不单独调，保持默认即可。

上下文窗口是更值得花心思的地方。8K 上下文对单个场景足够，但要注意系统提示词本身会占掉一部分。MES 工单列表和 SCADA 特征值加起来控制在 3000 字以内，给工具调用结果和模型回答留出空间。如果场景需要引入历史对话，建议只在最后两轮内回放，对话历史是上下文占用的隐形杀手。

Prompt 模板也要工程化。我通用模板里固定三段：角色定义、数据来源声明、约束条件。角色定义写明你是谁，数据来源声明写明本次回答只能依赖哪些信息，约束条件写明禁止做什么，比如禁止编造工单、禁止修改物料编码。三段结构清晰后，换场景只换中间的数据部分，不用重新设计提示词。

5. 避坑指南：AI 大模型进工厂最常见的 5 个翻车现场

5.1 现象：模型一本正经地推荐参数，对应 SCADA 点位却根本没采集

方案验证时，AI 对设备状态做了详尽的归因分析，指出了某个变量异常。结果下车间核查发现，那个点位压根不存在，是设备台账里淘汰的传感器还在配置文件里留名。模型不知道实时点位在线状态，只能凭历史文本里的“残影”推理。

原因是接入层没有把点位在线状态追加进上下文。模型以为给它的数据都真实存在，但历史数据里埋着废弃点位。

解决：在系统提示词前先注入一段点位状态表，列出“在线点位清单和最后更新时间”，并明确告知模型“不在清单内的点位不可引用”。同时接入层定期同步 SCADA 点位配置，把废弃点位从历史数据源里标记掉。

5.2 现象：SSE 流式输出到一半断流，界面一直转菊花

前端通过 SSE 接大模型输出，回答到一半就不动了，刷新页面重问一次又正常，但第二次断得更早。排查发现工厂现场网络走了转发代理，代理对响应内容做了缓冲，缓冲区一满就掐断。

原因是中间链路不支持流式转发。厂区网络设备、反向代理默认会缓存响应体，SSE 这种长连接被缓存策略埋在中间。

解决：在反向代理配置里关闭响应缓冲，把 SSE 接口的代理缓存设为 off，同时给响应头加上 cache-control 加 no-cache、x-加速-过期头等参数。前端侧也要做自动重连，断流后基于已渲染内容重新发起请求，而不是让用户手动刷新。注意重连时应带上最后一条已收到的消息序号，避免重复生成。

5.3 现象：大模型把物料编码“好心”改成了不存在的编码

质量归因场景里，模型识别出某个物料批次号“疑似拼写错误”，自动给它纠正成了另一串编码。这个问题最隐蔽，因为结果看起来合理，实际已经污染了 MES 里的追溯链。

原因是模型默认在做一个“助手”，倾向于修复它认为的错误。物料编码是工厂系统的强约束键，一旦被修改，关联关系就断了。

解决：在 system prompt 里明确写“所有编码类字段必须原样复制，禁止修正”。同时在网关层加一道规则校验，让模型输出经过一层实体校验器，凡是不在 MES 字典里的编码一律拦截并提示人工确认。这是提示词和工程规则双保险，缺一不可。

5.4 现象：把大模型当数据库，问它“上周 A 线良率多少”时一本正经地编数据

业务问“上周 A 线良率多少”，AI 回了“约 95%”。后来核对实际只有 91%。模型也不是故意撒谎，它根本看不到统计数据，只能根据上下文里的只言片语“合理猜测”。

原因是把模型当成了数据库引擎。大模型擅长归纳文本和生成建议，不擅长精确查询，特别是数值型结果。

解决：这类问题不应该让模型从记忆里生成答案，而要走工具调用。网关里挂一个统计查询函数，模型识别到意图后调用函数拉取 MES 的报表接口，得到真实数字后再组织语言。核心原则是：凡是数据库能直接回答的，不让模型代劳。前端如果发现是查数类问题，也可以直接走报表接口，连模型都不用调。

5.5 现象：本地模型服务响应越来越慢，最后直接显存溢出

刚部署时响应三秒，用了一个月后变成三十秒，最后直接 OOM 崩溃。运维以为是模型被“聊傻了”，重启后好一天又复发。

原因是会话历史无节制地堆积。每次对话都把整个 session 历史一起发给模型，上下文越积越长，KV cache 占用越来越大。

解决：网关层做会话窗口管理。只保留最近三轮对话和最近一次工具查询结果，超出部分摘要后丢弃。另外设置单会话最大 token 数，接近阈值时强制截断并提示用户开了新会话。工厂场景的操作员会话都比较短，通常两三轮就结束，这个策略对业务无损，但对系统稳定性帮助极大。

6. 怎么验证这套方案值得投入：三条评估线加一个记录表

方案值不值得做，不能只看演示时效果惊艳，要看几个月后的使用率和业务认可度。我习惯用三条评估线来验证。

第一条是决策支持覆盖线。把工厂里高频的排产、质量、设备、仓储问题列成清单，统计 AI 能给出有效建议的比例。刚开始可能只有四成，目标是通过迭代提示词场景到七成以上。覆盖率的提升速度直接反映方案投入的有效性。

第二条是人机协同耗时线。记录一个排产员订一个工单全流程需要多长时间，上线后同样流程缩了多少。这里要注意，只看回答速度没用，要看全流程闭环速度。AI 三秒给建议，但操作员还要去 MES 里手工执行，如果系统间没有联动，那 AI 的价值就被砍掉大半。

第三条是建议采纳线。统计 AI 给出的排产建议、报警解释被用户采纳的比例。这个比例低于五成说明提示词或者上下文数据没喂对，高于八成说明场景选得准。建议采纳率比回答速度更能反映真实质量。

配套做法是建一张 AI 输出日志表。字段包括问题、上下文摘要、模型回答、用户是否采纳、人工做了哪些修改。这张表积累一个月，就能看清哪些场景真正创造价值，哪些场景纯粹是花架子。我见过太多项目上线热两周，第三周就没人用了，原因就是没记录、没分析、没迭代。

投入这套方案之前，建议先用开源 MES 或现成测试环境跑通最小链路，拿真实工单数据验证一到两个场景，再决定是否全面铺开。工厂不像互联网可以随时回滚，系统一旦上线就牵扯生产。先小范围试错，再扩大战果。最后说一个我自己的习惯：任何方案文档我都会多留一页写“不做什么”，凡是涉及生产安全的决策，AI 永远只给建议，人永远握最终拍板权。守住这条，项目就守住了底线。希望帮到你。

本文还有配套的精品资源，点击获取