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 常见问题速查表我们在调试和试运行阶段遇到了不少问题整理成一张速查表给准备复制的团队参考。问题现象可能原因排查与解决思路诊断结论张冠李戴把A设备故障说成B设备上下文数据没带设备编号或知识库混入了错误文档强制在输入模板里标注设备ID和报警代码知识库按设备分库排产建议严重违反产能约束模型直接算排产而不是调用优化算法改成大模型负责解析需求算法负责求解模型只做结果包装回答速度太慢超过5秒模型过大、GPU负载高、检索太慢小模型处理高频问题大模型异步处理复杂问题向量库加缓存同样的故障今天报A原因明天报B原因提示词不固定检索结果不稳定固化提示词版本加上检索结果排序策略重要场景用规则兜底工人反馈“看不懂模型在说什么”输出太啰嗦术语太多输出模板加“一句话结论”再附详细说明移动端卡片式展示自动工单建错执行权限过大动作分类不清晰审核环节缺失重新梳理动作权限高风险动作一律人工确认这张表里的问题我们几乎都碰到过。最典型的还是模型输出不稳定不是靠改一个参数就能解决而是要同时调整输入、检索、提示词和权限四个环节。4.2 我踩过的三个坑第一个坑是把所有数据都塞给大模型。一开始我以为数据越多越聪明就在请求里放了最近72小时的全量数据结果模型崩溃不说延迟直接飙到十几秒答案还稀烂。后来改成只送特征摘要和最近几次关键报警效果立刻改善。大模型不是大数据处理器它需要的是“精炼过的上下文”不是原始日志。第二个坑是提示词随意改。项目前期大家都有创造力今天加一句话明天换一段约束结果同一个故障模型给出的结论越来越奇怪。后来我们把每个Agent的提示词纳入版本管理修改要走评审和回归测试流程拿历史问题集反复验证确保上线质量。第三个坑是忽略边缘容灾。有一次工厂网络抖动数据传不到推理服务器排产Agent直接罢工差点导致产线停线。从那以后所有关键Agent都加了“本地缓存降级模式”网络中断时先沿用上一次方案同时发出网络异常告警。黑灯工厂的黑灯可以关数据链路不能断。4.3 避坑清单上线前逐条自查准备上线的团队这份清单可以一条条打钩。所有高风险动作是否保留了人工确认/急停机制大模型账号权限是否为最小化执行动作是否单独授权所有输入输出是否留痕是否可以被审计追溯知识库文档是否完成脱敏和版本控制是否准备了网络中断、模型不可用时的降级方案是否用真实历史用例做过回归测试是否给一线操作人员做了简单易懂的使用培训和反馈通道是否有独立的软硬件急停回路不依赖模型判断这八条里面最后一条最重要。我们内部有一句口头禅大模型可以犯错黑灯工厂的安全底线不能破。所有自动化的前提是保留人的最后一道防线。最后再分享一个小技巧。如果你正在规划类似项目别急着追求全流程无人化。先选一条产线几种典型故障把知识问答、日报生成、异常诊断这些低风险模块跑起来用三个月时间记录下“每次模型建议是否被人工采纳、采纳后结果如何”。这些记录比任何指标都更能说明问题。等模型准确率稳定了再逐步开放排程建议和设备控制权限。这个节奏我们验证过走得稳比走得快更重要。后续这个项目还有很大扩展空间比如能耗自动分析、工艺参数自主寻优、跨工厂知识共享都可以在同样的架构上继续长出来。