企业官网建设流程全解析

2026年，我们的一条试点产线真正实现了“黑灯”运行，灯光可以关掉，产线照常跑，订单照常交付。更关键的是，那套让产线“懂事”的调度中枢，不再是一堆写死的规则脚本，而是一个能读维修手册、能翻历史工单、能自己写排产建议的AI大模型。业内现在讨论很多的这类大模型，我这里统一用“D大模型”来代称。这篇文章既是一份技术复盘，也是一份踩坑记录，给正在搞智能制造、想把大模型落到工厂里的工程师和运营团队参考。

1. 项目概述：黑灯工厂到底缺什么

1.1 黑灯工厂的现状：自动化不缺，缺的是“处理异常的人”

很多人对黑灯工厂有一个误解，以为里面真的一个人都没有。实际落地过的朋友都清楚，黑灯工厂只是把正常的重复劳动交给机器，把人员从产线上撤下来，但依然有一群人在中控室里盯屏幕、处理异常。产线停机的瞬间、质量波动的瞬间、设备参数漂移的瞬间，都需要有人能快速判断“发生了什么、该不该停、下一步找谁”。

传统自动化解决的是“正常流程里的自动执行”，比如机器人按轨迹抓取、PLC按时序控制、AGV按路径运输。这些环节只要参数稳定，确实可以做到无人化。可一旦出现偏差，情况就变了。设备报警后要翻维修手册、查历史故障代码；排产遇到急单插单，要重新评估设备状态和物料齐套；质检发现缺陷，要判断是来料问题、刀具磨损还是参数漂移。这些工作本质上都是“基于多源信息的决策”，靠人做，靠经验做，很难被传统自动化覆盖。

我们的模拟项目X一开始也踩在这个坎上。产线自动化率已经很高，但中控室需要三班倒，每班至少两个人，主要负责处理异常和协调资源。真正让黑灯工厂“永远亮着数据、黑着灯光”的关键，不是让机器人更快，而是让决策响应更快。2026年这个时间节点上，大模型恰好补上了这一环。

1.2 为什么2026年的趋势是把大模型放在生产决策环里

大模型进入工业现场，绝对不是赶时髦。过去几年，工厂里已经积累了大量小模型和算法，有做视觉质检的，有做振动分析的，有做能耗预测的。这些算法在单一场景下很准，但彼此之间是孤岛。比如视觉模型发现了一个缺陷，它能告诉你“缺陷类别是划痕”，但不会自动告诉你“可能是上一道工序的刀具钝了，建议停机检查”。缺的就是一个能综合理解上下文、调用多种工具、把碎片信息串起来的“大脑”。

D大模型这类大语言模型，最擅长的事情恰恰是阅读、归纳、推理和生成结构化内容。给它设备手册、工艺参数、历史工单和实时传感器数据，它就能像一位经验丰富的老师傅一样，把“数据”翻译成“动作”。更重要的是，它支持工具调用，可以通过API去查MES、写工单、发通知，甚至调用优化算法做排产计算。这时候大模型就不再只是一个聊天机器人，而是生产运营的“调度中枢”。

2026年的趋势，是从“规则驱动的自动执行”走向“模型驱动的自适应决策”。黑灯工厂的下一个阶段，不再只是无人操作，而是具备自感知、自诊断、自优化能力的自主运营。大模型在这个体系里扮演的角色，有点像人的“大脑皮层”，底层设备还是那些设备，但上层决策从规则和人工换成了模型加知识库。

2. 整体架构与设计思路拆解

2.1 五层架构：从设备数据到AI大脑再到执行

我们在模拟项目X里落地的整体架构，没有用太复杂的东西，核心是五层。

第一层是数据接入层。PLC、传感器、工业相机、MES数据库、ERP接口，统一通过OPC UA、Modbus TCP、API网关和中转表把数据送上来。这一层的核心不是技术，而是“哪些数据该采集、采多细”。我们最终选择只采跟决策相关的关键参数，比如主轴负载、温度、振动、产量、订单状态、质量结果，避免数据泛滥。

第二层是知识层。设备说明书、SOP文件、维修记录、历史工单、工艺标准，全部做格式化、切片和向量化，放进私有知识库。大模型回答和决策之前，先做检索增强，把最相关的几段内容拉出来，再结合实时数据生成答案。这一步非常关键，相当于给大模型配了一个“随时能查的老师傅笔记本”。

第三层是模型层。D大模型私有化部署在一个独立的推理服务器上，同时跑好几个专用Agent：排产Agent、设备诊断Agent、质检复核Agent、安全巡检Agent、知识问答Agent。每个Agent有自己的提示词、工具权限和输出模板。

第四层是执行层。模型生成的结论不会直接去开停设备，而是通过一套自动化网关，转成RPA操作、工单系统API、MES状态变更和消息推送。动作权限严格分级，有些只读，有些需要人确认，只有低风险的自动执行权限才放开。

第五层是安全与监控层。所有模型的输入输出都有日志留痕，每次自动执行都有审计记录，还有一套独立于模型的急停机制。即使模型判断错误，现场硬件安全回路仍然优先接管。

这套架构最核心的设计理念是：大模型负责“理解和建议”，系统负责“控制和执行”，人在中间保留“最终批准权”。不要试图让模型直接操作危险设备，这是底线。

2.2 大模型的六个落地角色，按风险和价值排序

我们梳理出大模型在黑灯工厂里可以扮演的六个角色。

第一个是设备诊断医生。输入是设备实时参数和报警代码，输出是故障原因分析、处置建议和维修工单草稿。这个角色价值高，风险低，因为它的主要输出是“建议”，不是直接控制。

第二个是生产排程员。输入是订单、交期、设备状态、物料齐套、人员技能，输出是排产方案和甘特图建议。排产涉及资源冲突，风险中等，所以需要人工确认后才能写回系统。

第三个是质检判官助理。视觉检测抓到缺陷图，模型结合工艺上下文判断缺陷的可能原因、影响等级和返工路线。这个角色可以大幅减少质检工程师的重复劳动。

第四个是安全巡检员。接入现场摄像头和传感器，识别未戴安全帽、闯入危险区域、通道堵塞等隐患，生成告警和巡检报告。输出简单直接，容易落地。

第五个是工艺知识顾问。工人和管理人员在现场问“这个参数上次调过吗”“这个报警代码什么意思”，大模型基于知识库给出准确回答，减少查手册的时间。

第六个是数据分析师。每天凌晨自动汇总前一天产量、良率、设备OEE、能耗，生成一份经营日报，包含趋势变化和异常解读。这个角色最容易见效，不要小看它。

我们给这六个角色做了优先级排序：知识问答和日报生成先上，设备诊断和质检复核跟上，排程和自动执行最后放开。为什么这样排？因为越靠近“信息输出”风险越低，越靠近“自动控制”风险越高。先把低风险的事做扎实，建立起团队对模型的信任，再逐步扩大权限。

2.3 模型选型与部署的四个关键参数

很多团队问我们当时怎么选模型。我们主要看四个参数。

第一是语义理解和指令遵循能力。工厂里很多表达并不规整，比如工单里写“3#机又抖了”，模型要能理解这是三号设备振动异常。我们当时用了一批真实工单做了测试集，让模型生成诊断结论，再用工程师人工打分。

第二是上下文长度。排产Agent一次要读入几十行订单、设备状态和约束条件，上下文至少要到32K，否则信息塞不下。低于这个长度就得频繁截断，效果大打折扣。

第三是工具调用能力。我们要求模型能按JSON格式输出“查设备表”“更新工单”“发送消息”等动作，且参数格式必须严格正确。选型时一起测了多个模型的工具调用准确率，差异很大，这一步不能凭感觉。

第四是私有化部署能力。工厂数据不能出园区，这是硬指标。我们选的是可私有化部署的开源模型底座，显存占用可控，也能根据现场数据微调。算力估算有一个很简单的方法：模型参数量乘以2字节（FP16权重），再乘1.2到1.5的冗余系数。比如70亿参数的模型，FP16大概是14GB权重，加上推理缓存和激活值，建议准备32GB以上显存。如果做了4bit量化，权重降到约4GB，一张消费级显卡也能跑起来，但推理效果会有轻微损失。

部署上，我们最终用了两卡并行跑一个中等规模模型，外加一个更小的快速模型处理简单问答。大模型处理复杂诊断，小模型处理高频基础查询，成本比单一大模型降低不少。

3. 核心模块实操要点

3.1 数据接入、清洗与知识库构建

数据接入听起来简单，实际最容易翻车。我们一开始想把所有传感器数据都接进来，结果一天产生几十GB时序数据，模型根本处理不过来，查询也慢。后来狠心砍掉大部分低频无关数据，只保留跟异常强相关的特征，比如主轴负载、振动、温度、电流、报警代码。

知识库构建同样有讲究。设备手册和SOP文档不能直接扔给模型，需要先做文本清洗、去页眉页脚、按章节切片，再嵌入向量库。切片长度我们测试后认为512到1024个字符比较合适，太短语义不完整，太长检索噪音大。知识库里还放了一部分“经验问答对”，是老师傅平时处理问题的口述记录，整理成“问题-处置动作-结果”三条结构，模型检索到之后能直接复用。

这里有一个注意事项：所有进入知识库的文档必须先脱敏，去掉无关人员姓名和敏感生产参数。黑灯工厂讲究数据合规，这个环节一定不要省。

3.2 生产排程Agent的搭建与提示词模板

排程Agent是我们项目里最有代表性的一个模块。它要做的事是：读取当前未完成订单、设备状态、物料齐套日期、工艺路线，生成未来48小时的可行排产方案，并标出优先级和风险。

核心流程分四步。第一步，Agent通过API从MES拉取订单和设备状态；第二步，把数据整理成结构化文本，交给大模型理解；第三步，大模型调用一个排程优化算法接口，算法算出初步结果，而不是让模型自己逐条排；第四步，模型把算法结果整理成人话，加上风险提示，推送给计划员确认。

很多团队容易犯一个错误，就是让大模型直接计算排产。大模型不擅长精确的约束求解，订单一多就容易算错。正确做法是让大模型做“翻译和协调”，真正的最优化计算交给传统运筹学算法。大模型的价值在于理解约束条件和业务上下文，并用自然语言生成可执行的排产建议。

这里分享一个简化版的提示词模板，实际使用时我们会在前面插入实时数据：

你是一名生产计划员。根据以下输入生成未来48小时的排产建议： 订单列表：... 设备状态：... 物料齐套情况：... 工艺路线：... 约束条件： - 每台设备同时只能加工一个订单 - 切换产品需要30分钟准备时间 - 紧急订单优先级最高 要求： 1. 输出按优先级排序的排产甘特图建议 2. 对每个订单标注预计开始时间、结束时间、使用设备 3. 列出可能的瓶颈设备和风险，并给出调整建议 4. 不要直接操作MES，只输出建议方案

这个模板的关键是“约束清晰、输出明确、权限受限”。我们实测下来，即使模型偶尔排得不完美，有经验的生产主管也能快速修正，比从零开始手工排程省了一半时间。

3.3 设备异常诊断与预测维护Agent

设备异常诊断是黑灯工厂最容易体现价值的功能。传统设备报警只能报“参数超限”，但一线人员想知道的是“为什么会超限，该怎么办”。我们让D大模型结合设备实时数据和知识库，自动输出诊断报告。

具体实现是：边缘侧先做异常检测，比如用滑动窗口统计振动特征是否超过阈值，或者利用轻量级时序模型预测残差。一旦触发异常，就把最近五分钟的传感器数据、报警代码和历史维修记录取出来，汇总成一段上下文，交给大模型生成处置建议。

为了防止大模型“一本正经地胡说八道”，我们给模型设了严格的边界。所有具体数值必须来自数据源，模型只能基于检索到的维修案例做归纳，不能凭空编造故障原因。输出格式也做了强制限定，必须是“异常描述、可能原因、建议动作、是否需要停机、建议通知班组”这几项。凡是模型没有把握的，必须输出“信息不足，需要人工进一步排查”。

动作执行方面分了三级。一级是低风险动作，比如“自动生成维修工单”“给组长推送异常简报”，直接放行。二级是中等风险，比如“调整某个不影响安全的工艺参数”，需要组长在移动端确认。三级是高风险，比如“建议立即停机”，模型只输出建议，实际停机由现场人员按急停。这套权限设计运行了三个月，没有出现过误触发导致的安全事故。

3.4 视觉质检与安全巡检联动

黑灯工厂里视觉质检是标配，但传统视觉模型只能输出缺陷位置和类别。我们在视觉模型后面接了一层大模型，让缺陷结果变得更有“业务意义”。比如表面划痕检测模型判定一个产品存在划痕，大模型会根据当前的工艺参数和最近一次刀具更换记录，判断这个划痕大概率是刀具磨损引起，还是来料本身问题，并给出复核建议。

这里用到的技术也很直接。视觉模型把缺陷代码、置信度、坐标和产品批次传给大模型，大模型再结合MES里的工艺数据进行推理。整个过程在200毫秒内完成，不影响产线节拍。我们看到的最大变化是，质检工程师不用再对着屏幕一条条看缺陷，而是只看大模型筛选出来的“需要人工复核”的高风险项。

安全巡检联动也是同样的思路。摄像头接入边缘侧的人员检测模型，识别出人员未戴安全帽、进入禁止区域等事件，然后大模型判断这个事件的风险等级，比如“临时路过但未闯入”和“长时间停留且无作业票”是不同级别。检测结果通过钉钉或企业微信推送，同时生成巡检记录存入数据库。因为涉及人身安全，这个模块我们坚持“只告警不自动处置”，绝对不让模型直接触发安全联锁。

3.5 人机协同闭环和权限控制

黑灯工厂虽然追求无人化，但我们在设计上始终保留人机协同闭环。大模型每给出一个关键建议，都会在移动端生成一张卡片，上面写清楚“发生了什么、依据是什么、建议做什么、要不要人工点确认”。操作人员可以一键确认，也可以直接驳回并附上理由。驳回的理由会重新进到知识库，成为下次改进的样本。

权限控制上，我们把动作分成read、advise、execute三级。read是模型只能看数据，比如“当前OEE多少”；advise是模型可以生成建议但必须人确认；execute是模型可以直接执行，比如自动生成日报、自动关闭已恢复的告警。每一级权限在Agent配置里单独定义，不搞一刀切。

这个闭环让团队逐步建立了对大模型的信任。最开始大家都觉得它是个高级玩具，后来发现它能准确找到昨晚停机的原因，慢慢开始主动问它问题。我个人的体会是，黑灯工厂的大模型项目能不能成，一半靠技术，一半靠运营，人机协同的设计决定了技术能不能真正用起来。

4. 常见问题排查与避坑心得

4.1 常见问题速查表

我们在调试和试运行阶段遇到了不少问题，整理成一张速查表，给准备复制的团队参考。

这张表里的问题，我们几乎都碰到过。最典型的还是模型输出不稳定，不是靠改一个参数就能解决，而是要同时调整输入、检索、提示词和权限四个环节。

4.2 我踩过的三个坑

第一个坑，是把所有数据都塞给大模型。一开始我以为数据越多越聪明，就在请求里放了最近72小时的全量数据，结果模型崩溃不说，延迟直接飙到十几秒，答案还稀烂。后来改成只送特征摘要和最近几次关键报警，效果立刻改善。大模型不是大数据处理器，它需要的是“精炼过的上下文”，不是原始日志。

第二个坑，是提示词随意改。项目前期大家都有创造力，今天加一句话，明天换一段约束，结果同一个故障模型给出的结论越来越奇怪。后来我们把每个Agent的提示词纳入版本管理，修改要走评审和回归测试流程，拿历史问题集反复验证，确保上线质量。

第三个坑，是忽略边缘容灾。有一次工厂网络抖动，数据传不到推理服务器，排产Agent直接罢工，差点导致产线停线。从那以后，所有关键Agent都加了“本地缓存+降级模式”，网络中断时先沿用上一次方案，同时发出网络异常告警。黑灯工厂的黑灯可以关，数据链路不能断。

4.3 避坑清单：上线前逐条自查

准备上线的团队，这份清单可以一条条打钩。

• 所有高风险动作是否保留了人工确认/急停机制？
• 大模型账号权限是否为最小化，执行动作是否单独授权？
• 所有输入输出是否留痕，是否可以被审计追溯？
• 知识库文档是否完成脱敏和版本控制？
• 是否准备了网络中断、模型不可用时的降级方案？
• 是否用真实历史用例做过回归测试？
• 是否给一线操作人员做了简单易懂的使用培训和反馈通道？
• 是否有独立的软硬件急停回路，不依赖模型判断？

这八条里面，最后一条最重要。我们内部有一句口头禅：大模型可以犯错，黑灯工厂的安全底线不能破。所有自动化的前提，是保留人的最后一道防线。

最后再分享一个小技巧。如果你正在规划类似项目，别急着追求全流程无人化。先选一条产线，几种典型故障，把知识问答、日报生成、异常诊断这些低风险模块跑起来，用三个月时间记录下“每次模型建议是否被人工采纳、采纳后结果如何”。这些记录比任何指标都更能说明问题。等模型准确率稳定了，再逐步开放排程建议和设备控制权限。这个节奏，我们验证过，走得稳比走得快更重要。后续这个项目还有很大扩展空间，比如能耗自动分析、工艺参数自主寻优、跨工厂知识共享，都可以在同样的架构上继续长出来。