尧图网站建设 
简介这份PPT资源以DeepSeek等AI大模型为主线系统梳理其在数字化智能工厂建设中的实践路径适合企业数字化负责人、智能制造规划人员以及APS、WMS、MES、EMS、SRM等业务系统从业者参考学习。内容不仅涵盖技术范式创新如强化学习、知识蒸馏、自动化调参、模型集成、跨模态融合与动态知识库还聚焦行业实践围绕制造业全流程智能化升级展开涉及自动化生产线、预测性维护、智能供应链、质量控制与检测、能源管理与节能减排等场景并延伸至医疗、法律等领域的智能应用。资源为单个pptx文件大小652KB页面组织以目录式章节呈现逻辑清晰便于快速定位相关内容。已有193人学习下载适合用于内部培训、方案汇报或作为AI赋能智能工厂建设的入门与进阶参考资料。1. 智能工厂上 DeepSeek先从能对话的报表开始数字化智能工厂项目里最尴尬的往往不是数据不够而是数据都在系统里人却拿不出来。车间主任问“3号线今天还有多少急单没排进去”仓库主管问“A类物料哪些明天下午会断料”按传统做法要先去APS看排产、去WMS拉库存、再回到MES对工单状态一通操作下来十分钟过去了。DeepSeek这类通用大模型进工厂最先解决的就是这个“最后一公里”问题把ERP、MES、WMS、APS里沉淀的数据变成车间人员能直接问、直接用的对话服务。这篇文章我会围绕APS排产、WMS仓储、MES工序、EMS能耗、SRM供应商协同五个典型模块拆一套可复现的接入方法和提示词工程。别期待大模型直接去控制PLC或者写回调度算法那是危险且不成熟的。常见做法是在既有系统上包一层“AI中间层”让大模型负责理解问题、拆解参数、生成候选方案再由业务系统校验和执行。适合读这篇的人包括智能制造项目经理、企业IT负责人、做AI应用落地的工程师如果你正准备给工厂系统接大模型这里有选型思路、参数设置和坑位清单。2. 落地前的准备DeepSeek 接入方式与 MES/WMS 数据上下文2.1 先选路API 调用和本地部署怎么定在工厂环境里数据不出厂往往是一条死线。APS的工单优先级、WMS的实时库存、MES的工序参数都是运营机密。如果项目允许走外网DeepSeek开放平台的API是成本最低的方案用标准OpenAI兼容客户端就可以调几分钟能跑通第一个问答。如果车间与公网隔离或者对响应延迟有硬要求就得考虑本地部署。本地部署意味着要准备GPU服务器、模型权重文件和一套推理服务运维门槛上了一个台阶但对于集团型工厂数据留在墙内比什么都重要。下面这张表是我在项目里给客户做选型时常用的对比维度直接照着抄就行对比项API 调用本地部署硬件投入接近零按 token 计费GPU 服务器建议显存 48G 以上数据出境会出内网需评估合规数据不出境响应延迟网络往返通常 2~5 秒首批 token 快吞吐受 GPU 限制运维成本官方维护自己盯模型版本、并发、存储适合场景先跑通原型、低敏数据问答核心排产、能耗、供应链正式环境这里有个关键结论不是所有模块都适合同一个部署方式。我一般会把“对外展示的看板问答”走API把“涉及真实工单写回”的放到本地模型后面并用业务系统兜底。比如最典型的MES产量问答模型只负责把自然语言转成查询条件真正取数是MES系统自己做的这样就算模型胡说数据库也不会被写坏。提示本地部署DeepSeek之前先量一下现有MES/WMS的并发查询量。工厂车间并发通常不高几十人同时问已经算重负载不用照着互联网高并发设计。2.2 把 MES/WMS/APS 的表结构变成模型能读的上下文大模型不认识你的数据库它只认识文字。要让DeepSeek回答“3号线A类工单还剩多少”得先把MES里的工单表、WMS里的库存表、APS里的排产结果抽成一段结构化文本或JSON塞进system prompt。这块做得好不好直接决定后面所有场景的效果。我一般会写一个Python脚本定时从工厂数据库拉数据生成一个紧凑的“工厂快照”。下面这个是去掉业务细节后的最小例子import json import sqlite3 from datetime import datetime def build_factory_context(db_path: str) - str: conn sqlite3.connect(db_path) conn.row_factory sqlite3.Row cur conn.cursor() # 拉取未完工的工单带上优先级和交期 cur.execute( SELECT work_order, line_id, product, qty, done_qty, priority, due_time FROM mes_work_order WHERE status RUNNING OR status PENDING LIMIT 50 ) orders [dict(r) for r in cur.fetchall()] # 拉取低库存物料用于回答断料问题 cur.execute( SELECT material_code, material_name, stock_qty, safety_stock, lead_time FROM wms_inventory WHERE stock_qty safety_stock LIMIT 30 ) stocks [dict(r) for r in cur.fetchall()] snapshot { snapshot_time: datetime.now().isoformat(timespecseconds), work_orders: orders, low_stock: stocks } return json.dumps(snapshot, ensure_asciiFalse, defaultstr) # 使用示例 context build_factory_context(factory.db) print(context[:500])这段脚本干了两件事从mes_work_order取未完工工单从wms_inventory取低于安全库存的物料全部转成列表字典后序列化为JSON。ensure_asciiFalse保证中文不转义defaultstr是为了处理时间字段的序列化问题。要注意LIMIT必须加否则一个集团工厂几百万行数据直接喂给模型第一个被击穿的不是显存而是上下文窗口。快照不是实时查询它解决的是“让模型知道当前大致状态”精确到秒的数据仍然要走函数调用去查数据库。如果工厂还没有正式MES只上了ERP或者Excel也可以用同样套路把ERP导出的工单和库存在脚本里读出来再做清洗。前期没有正式MES的工厂也可以先部署一套开源MES系统比如carbon这类项目把工单、库存、设备状态数据落库再让DeepSeek基于同一份数据源做问答这样比直接对接Excel表稳定得多。2.3 上下文窗口和 token 预算的取舍DeepSeek的上下文长度不是无限的工厂快照加历史对话加系统提示词都要占token。我习惯给每个模块固定一个预算系统提示词控制在500 token以内工厂快照最多占2000 token一次问答留给模型的生成空间在500 token左右。超过这个数就做裁剪比如只保留未来3天的工单库存只取低于安全库存的物料。这个做法能让响应时间稳定也方便排查“为什么模型忽然忘了规则”。如果发现模型经常抓不住重点不是模型不行多半是上下文里塞了太多无关数据。把无关字段从快照里去掉效果立竿见影。下一章开始进入具体的业务场景先说最容易出成果的APS排产和WMS仓储。3. 从 APS 到 WMS排产调度与仓储问答的典型落地3.1 APS 排产把“越急越优先”变成模型能懂的多约束APS的高级排产在工厂里一直是个硬骨头。很多工厂根本没有成套的排产算法靠的是计划员用Excel和经验。DeepSeek进来不是替代专业排产软件而是处理一类特别适合大模型的场景临时插单、急单优先、设备冲突时生成候选排产方案。举个具体的例子现在3号线上有5个工单在排队明天上午突然插入一个VIP订单交期是后天。计划员需要知道插在哪台设备、推迟哪些原有工单、影响多大。我让DeepSeek扮演排产助理给它工单列表、设备产能和优先级规则让它在不出数学最优解的情况下输出一个可执行的调整建议。from openai import OpenAI client OpenAI( api_keyyour-deepseek-api-key, base_urlhttps://api.deepseek.com ) system_prompt 你是 APS 排产助理。输入包含当前设备任务列表和新增订单。 请按以下规则输出排产建议 1. 优先级字段越小越先排交付日期不可协商的标记为 urgent 2. 同一台设备不能同时加工两个工单 3. 建议必须明确动作插单到哪台设备、推迟哪个工单、预计影响时长。 只输出 JSON不要输出解释。 JSON 格式 { insert_order: 工单号, suggest_device: 设备号, delayed_orders: [工单号], impact_hint: 一句话说明影响 } user_content 当前3号线任务 - WO-1001设备 CNC-01加工 2 小时优先级 1 - WO-1002设备 CNC-01加工 3 小时优先级 3 - WO-1003设备 CNC-02加工 1.5 小时优先级 2 新增插单WO-2001设备任选加工 1 小时优先级 0交期紧急。 resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: system_prompt}, {role: user, content: user_content} ], temperature0.2, max_tokens800, response_format{type: json_object} ) print(resp.choices[0].message.content)这段代码里两个参数值得多说temperature0.2是为了让输出稳定排产建议不能每次问都不一样response_format{type: json_object}告诉模型必须输出JSON方便后续程序直接解析。如果delayed_orders字段在代码里没有进入界面展示那这个建议就不能算落地至少要把“推迟了谁”变成APS里的一个待确认清单。输出字段的含义如下表实际接界面时直接对应到表格列JSON 字段含义处理建议insert_order要插入的工单号必须是输入里出现过的单号suggest_device建议插入的设备编号校验设备状态为可用delayed_orders被推迟的原有工单列表逐个展示给计划员确认impact_hint对交付影响的说明必须包含小时数或具体日期我在真实项目里会再加一层校验用Python判断模型建议的impact_hint里是否包含具体小时数没有就退回重问一次。这个重试逻辑不是炫技而是防止模型生成“影响不大”这种没法执行的废话。3.2 WMS 仓储问答自然语言转结构化查询要用函数调用WMS仓储物流管理系统最常见的AI需求是自然语言查库存“A类物料还有多少”“明天哪些物料会低于安全库存”。很多人第一反应是让大模型直接生成SQL然后扔给数据库执行。这是个高风险做法模型一旦把字段名写错或者把“小于”写成“大于”轻则查错数重则让业务误判断料风险。我一般不会让模型直接碰SQL而是定义几个白名单函数让模型学会调度函数而不是造SQL。下面是个简化的函数调用例子functions [{ type: function, function: { name: query_stock, description: 查询物料库存。按物料代码精确查询或按库存状态模糊查询。, parameters: { type: object, properties: { material_code: {type: string, description: 物料代码如 A-1001}, below_safety: {type: boolean, description: 是否只查低于安全库存的物料} }, required: [below_safety] } } }] response client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: 查一下A-1001还有多少顺便告诉我哪些物料明天要断料}], toolsfunctions, tool_choiceauto ) print(response.choices[0].message.tool_calls)模型收到后会返回一个tool_calls结构里面是它想调用的query_stock和参数。程序这边解析参数再用自己的查询方法去WMS取数。这样做有三个好处字段校验在我们手里不能由模型决定SQL不会暴露给模型减少prompt注入风险查询慢的问题也好优化因为模型只会调固定接口接口内部可以加缓存、加索引。如果你已经在跑WMS服务加载慢的源头往往是前端一次性加载整月流水。让模型先生成筛选条件把查询范围缩小到今天或本周能显著减少返回数据量。这个思路比后端加索引实在。3.3 一个容易被忽略的坑输出校验字段即使加了response_format模型偶尔也会把JSON字段名改掉比如把suggest_device换成device。所以我每次都会在代码后面加一段硬校验解析JSON后检查必须字段是否存在不存在就强制设置一个默认值并记录日志。这个校验逻辑虽然简单但能避免后续展示层直接崩掉。生产环境里宁可在接口层多写20行校验也不要相信模型每次都能格式精确。4. MES、EMS、SRM 的进阶实践异常归因、能耗优化与供应商协同4.1 MES 产量异常归因用提示词模板收敛分析维度MES系统里最耗人工的活是产量异常分析。今天2号线产量比昨天低20%到底是设备停机、缺料、换型频繁还是人员缺勤传统的MES报表只能展示曲线原因分析靠老师傅拍脑袋。DeepSeek可以把异常前后的工单数据、设备状态、停机记录汇总起来生成一份带数据支撑的归因建议。我常用的提示词模板是这样的组成内容角色你是 MES 生产分析工程师只基于给定的数据回答上下文当前班次产量、设备状态记录、停机原因代码、工单切换次数任务找出最可能的原因给出数据依据和下一步排查动作约束不确定的原因标注“待确认”不要编造停机原因下面是一个极简的调用片段演示怎么把三段数据拼进promptmes_data { line: 2号线, today_qty: 820, yesterday_qty: 1020, down_events: [ {reason: 换料, minutes: 35}, {reason: 设备报警, minutes: 120} ], shift_change_count: 4 } prompt f 请基于以下数据进行产量下降归因 {today_qty} 对比 {yesterday_qty} 下降 {delta}%。 停机记录{down_events} 请输出 JSON包含原因排序和每个原因对应的数据依据。 # 调用方式与上一章一致此处省略参数上这类分析场景建议把temperature调到0.4左右保留一点多样性但不要太高。理由归因本身有主观性完全确定性的输出可能掩盖多因素耦合但超过0.7就会开始编造停机原因了。注意MES的归因和APS排产不一样排产建议要尽量稳定归因分析可以容忍发散。所以同一个模型、同一个工厂不同场景应该使用不同的temperature和prompt。这个细节写进方案里很加分实际运行中也能减少不少无效争论。有些工厂觉得数字孪生看板很炫但用下来真正管用的还是MES里沉淀的数据大模型让这些数据第一次能被车间直接问。4.2 EMS 能耗优化让模型读抄表数据给出班次级建议EMS能源管理系统里积累了大量的水电气数据但工程师通常只看累计用量很少逐日分析。用DeepSeek做能耗预测的常见做法是把最近7天的整点抄表数据按天聚合让模型识别尖峰时段并结合生产计划给出调整建议。energy_data [ {day: 2025-06-01, peak_hour: 14, usage_kwh: 12800}, {day: 2025-06-02, peak_hour: 15, usage_kwh: 14400}, {day: 2025-06-03, peak_hour: 14, usage_kwh: 12100} ] resp client.chat.completions.create( modeldeepseek-chat, messages[{ role: user, content: f 以下是工厂近三天用电汇总{energy_data} 请找出能耗尖峰规律并给出明天的错峰生产建议。 要求建议与生产计划无关的靠后排优先调整可中断设备。 }], temperature0.3, max_tokens600 )这段代码最需要注意的是prompt里最后一句话“优先调整可中断设备”这是把工厂的业务约束塞进生成过程比在解析后硬过滤更有效。EMS场景还有一个特点历史数据是数值不是文本模型对数值的敏感度有限。所以不要让模型直接报“14时比15时高12.5%”而是在输出前把数值变化转成趋势描述再让模型基于趋势给结论。4.3 SRM 供应商协同让模型生成询价单和风险提示SRM系统里采购员每天要发大量询价邮件还要逐条核对交期、含税价、付款条件。DeepSeek在这里最适合做草稿生成。我会让采购员输入物料清单和期望交期模型输出一封结构完整的询价单邮件同时附带一个风险提示清单哪些物料交期太紧、哪些条款可能被供应商拒绝。srm_input { material: 电机 M-300, qty: 200, expect_date: 2025-07-01, payment: 月结30天 } mail_prompt f 你是采购助理。请根据物料信息生成一封中文询价邮件 物料{srm_input[material]} 数量{srm_input[qty]} 期望交期{srm_input[expect_date]} 付款方式{srm_input[payment]} 邮件必需包含物料规格确认、交期可行性、含税报价、包装运输方式。 另外用列表输出2到3条采购风险提示。 # 这里用普通文本输出即可不需要强制JSON这类场景对输出格式要求不高所以不需要response_format。但要在后续处理中把邮件正文和风险提示分开保存否则采购员复制粘贴时会把AI的风险提示也发出去。常见的做法是要求模型用---风险提示---分隔符解析时按分隔符截断。5. 上线前做三件事DeepSeek 幻觉约束、长对话压缩与回归测试5.1 用事实库约束模型禁止凭记忆回答工厂场景里模型幻觉的代价很高比如把安全库存50说成500可能导致采购下错单。我的做法是当问题涉及具体数值时要求模型只引用上下文里出现过的数据如果上下文里没有回复“当前快照中无此数据”。这个约束要写进system prompt但更可靠的是在应用层加一道检查解析模型输出中的所有数字与上下文中的数值做比对上下文里没有的数字一律标记为低置信度由前端用黄色高亮提示。这样比单纯靠提示词可靠得多。5.2 上下文太长时用分段对话代替无限加长DeepSeek达到对话长度上限是会报错的尤其是长时间挂着智能问答看板。遇到长会话先做一轮对话摘要再继续。我一般会用一个轻量脚本把超过10轮的历史消息压缩成100字以内的状态摘要然后作为system prompt的一部分继续。这个技巧能有效避免“请开启新对话”的提示也能保持跨轮次的业务连续性比如前面问了3号线后面接着问“那2号线呢”模型还能接得上。5.3 效果验证写一组固定题目做回归最后分享一个实操方法准备10到15个业务问题作为回归测试集每次改提示词或换模型版本都跑一遍。下面是我常用的最小脚本cases [ {q: 3号线今天有多少个未完工工单, must_have: [WO-]}, {q: A-1001物料库存是否低于安全库存, must_have: [低于]}, {q: 明天EMS预测尖峰时段, must_have: [时]} ] def run_regression(modeldeepseek-chat): passed 0 for case in cases: resp client.chat.completions.create( modelmodel, messages[{role: user, content: case[q]}], temperature0.2, max_tokens300 ) ans resp.choices[0].message.content if all(k in ans for k in case[must_have]): passed 1 else: print(fFAIL: {case[q]}) print(f通过率: {passed}/{len(cases)}) run_regression()这个脚本只检查关键词比较粗糙但对工厂这种领域足够当第一道防线。把must_have换成你必须保障出现的字段比如工单号前缀、物料代码、时间单位。每次重新部署前跑一遍如果通过率低于80%就不要上生产。此外把temperature固定在0.2以下跑回归结果才可复现。跑完回归后再挑三个失败用例看看是prompt问题还是模型本身理解问题这个分析动作比调参更重要。本文还有配套的精品资源点击获取 DeepSeek智能工厂落地：从APS排产到MES归因的五大模块实战
简介这份PPT资源以DeepSeek等AI大模型为主线系统梳理其在数字化智能工厂建设中的实践路径适合企业数字化负责人、智能制造规划人员以及APS、WMS、MES、EMS、SRM等业务系统从业者参考学习。内容不仅涵盖技术范式创新如强化学习、知识蒸馏、自动化调参、模型集成、跨模态融合与动态知识库还聚焦行业实践围绕制造业全流程智能化升级展开涉及自动化生产线、预测性维护、智能供应链、质量控制与检测、能源管理与节能减排等场景并延伸至医疗、法律等领域的智能应用。资源为单个pptx文件大小652KB页面组织以目录式章节呈现逻辑清晰便于快速定位相关内容。已有193人学习下载适合用于内部培训、方案汇报或作为AI赋能智能工厂建设的入门与进阶参考资料。1. 智能工厂上 DeepSeek先从能对话的报表开始数字化智能工厂项目里最尴尬的往往不是数据不够而是数据都在系统里人却拿不出来。车间主任问“3号线今天还有多少急单没排进去”仓库主管问“A类物料哪些明天下午会断料”按传统做法要先去APS看排产、去WMS拉库存、再回到MES对工单状态一通操作下来十分钟过去了。DeepSeek这类通用大模型进工厂最先解决的就是这个“最后一公里”问题把ERP、MES、WMS、APS里沉淀的数据变成车间人员能直接问、直接用的对话服务。这篇文章我会围绕APS排产、WMS仓储、MES工序、EMS能耗、SRM供应商协同五个典型模块拆一套可复现的接入方法和提示词工程。别期待大模型直接去控制PLC或者写回调度算法那是危险且不成熟的。常见做法是在既有系统上包一层“AI中间层”让大模型负责理解问题、拆解参数、生成候选方案再由业务系统校验和执行。适合读这篇的人包括智能制造项目经理、企业IT负责人、做AI应用落地的工程师如果你正准备给工厂系统接大模型这里有选型思路、参数设置和坑位清单。2. 落地前的准备DeepSeek 接入方式与 MES/WMS 数据上下文2.1 先选路API 调用和本地部署怎么定在工厂环境里数据不出厂往往是一条死线。APS的工单优先级、WMS的实时库存、MES的工序参数都是运营机密。如果项目允许走外网DeepSeek开放平台的API是成本最低的方案用标准OpenAI兼容客户端就可以调几分钟能跑通第一个问答。如果车间与公网隔离或者对响应延迟有硬要求就得考虑本地部署。本地部署意味着要准备GPU服务器、模型权重文件和一套推理服务运维门槛上了一个台阶但对于集团型工厂数据留在墙内比什么都重要。下面这张表是我在项目里给客户做选型时常用的对比维度直接照着抄就行对比项API 调用本地部署硬件投入接近零按 token 计费GPU 服务器建议显存 48G 以上数据出境会出内网需评估合规数据不出境响应延迟网络往返通常 2~5 秒首批 token 快吞吐受 GPU 限制运维成本官方维护自己盯模型版本、并发、存储适合场景先跑通原型、低敏数据问答核心排产、能耗、供应链正式环境这里有个关键结论不是所有模块都适合同一个部署方式。我一般会把“对外展示的看板问答”走API把“涉及真实工单写回”的放到本地模型后面并用业务系统兜底。比如最典型的MES产量问答模型只负责把自然语言转成查询条件真正取数是MES系统自己做的这样就算模型胡说数据库也不会被写坏。提示本地部署DeepSeek之前先量一下现有MES/WMS的并发查询量。工厂车间并发通常不高几十人同时问已经算重负载不用照着互联网高并发设计。2.2 把 MES/WMS/APS 的表结构变成模型能读的上下文大模型不认识你的数据库它只认识文字。要让DeepSeek回答“3号线A类工单还剩多少”得先把MES里的工单表、WMS里的库存表、APS里的排产结果抽成一段结构化文本或JSON塞进system prompt。这块做得好不好直接决定后面所有场景的效果。我一般会写一个Python脚本定时从工厂数据库拉数据生成一个紧凑的“工厂快照”。下面这个是去掉业务细节后的最小例子import json import sqlite3 from datetime import datetime def build_factory_context(db_path: str) - str: conn sqlite3.connect(db_path) conn.row_factory sqlite3.Row cur conn.cursor() # 拉取未完工的工单带上优先级和交期 cur.execute( SELECT work_order, line_id, product, qty, done_qty, priority, due_time FROM mes_work_order WHERE status RUNNING OR status PENDING LIMIT 50 ) orders [dict(r) for r in cur.fetchall()] # 拉取低库存物料用于回答断料问题 cur.execute( SELECT material_code, material_name, stock_qty, safety_stock, lead_time FROM wms_inventory WHERE stock_qty safety_stock LIMIT 30 ) stocks [dict(r) for r in cur.fetchall()] snapshot { snapshot_time: datetime.now().isoformat(timespecseconds), work_orders: orders, low_stock: stocks } return json.dumps(snapshot, ensure_asciiFalse, defaultstr) # 使用示例 context build_factory_context(factory.db) print(context[:500])这段脚本干了两件事从mes_work_order取未完工工单从wms_inventory取低于安全库存的物料全部转成列表字典后序列化为JSON。ensure_asciiFalse保证中文不转义defaultstr是为了处理时间字段的序列化问题。要注意LIMIT必须加否则一个集团工厂几百万行数据直接喂给模型第一个被击穿的不是显存而是上下文窗口。快照不是实时查询它解决的是“让模型知道当前大致状态”精确到秒的数据仍然要走函数调用去查数据库。如果工厂还没有正式MES只上了ERP或者Excel也可以用同样套路把ERP导出的工单和库存在脚本里读出来再做清洗。前期没有正式MES的工厂也可以先部署一套开源MES系统比如carbon这类项目把工单、库存、设备状态数据落库再让DeepSeek基于同一份数据源做问答这样比直接对接Excel表稳定得多。2.3 上下文窗口和 token 预算的取舍DeepSeek的上下文长度不是无限的工厂快照加历史对话加系统提示词都要占token。我习惯给每个模块固定一个预算系统提示词控制在500 token以内工厂快照最多占2000 token一次问答留给模型的生成空间在500 token左右。超过这个数就做裁剪比如只保留未来3天的工单库存只取低于安全库存的物料。这个做法能让响应时间稳定也方便排查“为什么模型忽然忘了规则”。如果发现模型经常抓不住重点不是模型不行多半是上下文里塞了太多无关数据。把无关字段从快照里去掉效果立竿见影。下一章开始进入具体的业务场景先说最容易出成果的APS排产和WMS仓储。3. 从 APS 到 WMS排产调度与仓储问答的典型落地3.1 APS 排产把“越急越优先”变成模型能懂的多约束APS的高级排产在工厂里一直是个硬骨头。很多工厂根本没有成套的排产算法靠的是计划员用Excel和经验。DeepSeek进来不是替代专业排产软件而是处理一类特别适合大模型的场景临时插单、急单优先、设备冲突时生成候选排产方案。举个具体的例子现在3号线上有5个工单在排队明天上午突然插入一个VIP订单交期是后天。计划员需要知道插在哪台设备、推迟哪些原有工单、影响多大。我让DeepSeek扮演排产助理给它工单列表、设备产能和优先级规则让它在不出数学最优解的情况下输出一个可执行的调整建议。from openai import OpenAI client OpenAI( api_keyyour-deepseek-api-key, base_urlhttps://api.deepseek.com ) system_prompt 你是 APS 排产助理。输入包含当前设备任务列表和新增订单。 请按以下规则输出排产建议 1. 优先级字段越小越先排交付日期不可协商的标记为 urgent 2. 同一台设备不能同时加工两个工单 3. 建议必须明确动作插单到哪台设备、推迟哪个工单、预计影响时长。 只输出 JSON不要输出解释。 JSON 格式 { insert_order: 工单号, suggest_device: 设备号, delayed_orders: [工单号], impact_hint: 一句话说明影响 } user_content 当前3号线任务 - WO-1001设备 CNC-01加工 2 小时优先级 1 - WO-1002设备 CNC-01加工 3 小时优先级 3 - WO-1003设备 CNC-02加工 1.5 小时优先级 2 新增插单WO-2001设备任选加工 1 小时优先级 0交期紧急。 resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: system_prompt}, {role: user, content: user_content} ], temperature0.2, max_tokens800, response_format{type: json_object} ) print(resp.choices[0].message.content)这段代码里两个参数值得多说temperature0.2是为了让输出稳定排产建议不能每次问都不一样response_format{type: json_object}告诉模型必须输出JSON方便后续程序直接解析。如果delayed_orders字段在代码里没有进入界面展示那这个建议就不能算落地至少要把“推迟了谁”变成APS里的一个待确认清单。输出字段的含义如下表实际接界面时直接对应到表格列JSON 字段含义处理建议insert_order要插入的工单号必须是输入里出现过的单号suggest_device建议插入的设备编号校验设备状态为可用delayed_orders被推迟的原有工单列表逐个展示给计划员确认impact_hint对交付影响的说明必须包含小时数或具体日期我在真实项目里会再加一层校验用Python判断模型建议的impact_hint里是否包含具体小时数没有就退回重问一次。这个重试逻辑不是炫技而是防止模型生成“影响不大”这种没法执行的废话。3.2 WMS 仓储问答自然语言转结构化查询要用函数调用WMS仓储物流管理系统最常见的AI需求是自然语言查库存“A类物料还有多少”“明天哪些物料会低于安全库存”。很多人第一反应是让大模型直接生成SQL然后扔给数据库执行。这是个高风险做法模型一旦把字段名写错或者把“小于”写成“大于”轻则查错数重则让业务误判断料风险。我一般不会让模型直接碰SQL而是定义几个白名单函数让模型学会调度函数而不是造SQL。下面是个简化的函数调用例子functions [{ type: function, function: { name: query_stock, description: 查询物料库存。按物料代码精确查询或按库存状态模糊查询。, parameters: { type: object, properties: { material_code: {type: string, description: 物料代码如 A-1001}, below_safety: {type: boolean, description: 是否只查低于安全库存的物料} }, required: [below_safety] } } }] response client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: 查一下A-1001还有多少顺便告诉我哪些物料明天要断料}], toolsfunctions, tool_choiceauto ) print(response.choices[0].message.tool_calls)模型收到后会返回一个tool_calls结构里面是它想调用的query_stock和参数。程序这边解析参数再用自己的查询方法去WMS取数。这样做有三个好处字段校验在我们手里不能由模型决定SQL不会暴露给模型减少prompt注入风险查询慢的问题也好优化因为模型只会调固定接口接口内部可以加缓存、加索引。如果你已经在跑WMS服务加载慢的源头往往是前端一次性加载整月流水。让模型先生成筛选条件把查询范围缩小到今天或本周能显著减少返回数据量。这个思路比后端加索引实在。3.3 一个容易被忽略的坑输出校验字段即使加了response_format模型偶尔也会把JSON字段名改掉比如把suggest_device换成device。所以我每次都会在代码后面加一段硬校验解析JSON后检查必须字段是否存在不存在就强制设置一个默认值并记录日志。这个校验逻辑虽然简单但能避免后续展示层直接崩掉。生产环境里宁可在接口层多写20行校验也不要相信模型每次都能格式精确。4. MES、EMS、SRM 的进阶实践异常归因、能耗优化与供应商协同4.1 MES 产量异常归因用提示词模板收敛分析维度MES系统里最耗人工的活是产量异常分析。今天2号线产量比昨天低20%到底是设备停机、缺料、换型频繁还是人员缺勤传统的MES报表只能展示曲线原因分析靠老师傅拍脑袋。DeepSeek可以把异常前后的工单数据、设备状态、停机记录汇总起来生成一份带数据支撑的归因建议。我常用的提示词模板是这样的组成内容角色你是 MES 生产分析工程师只基于给定的数据回答上下文当前班次产量、设备状态记录、停机原因代码、工单切换次数任务找出最可能的原因给出数据依据和下一步排查动作约束不确定的原因标注“待确认”不要编造停机原因下面是一个极简的调用片段演示怎么把三段数据拼进promptmes_data { line: 2号线, today_qty: 820, yesterday_qty: 1020, down_events: [ {reason: 换料, minutes: 35}, {reason: 设备报警, minutes: 120} ], shift_change_count: 4 } prompt f 请基于以下数据进行产量下降归因 {today_qty} 对比 {yesterday_qty} 下降 {delta}%。 停机记录{down_events} 请输出 JSON包含原因排序和每个原因对应的数据依据。 # 调用方式与上一章一致此处省略参数上这类分析场景建议把temperature调到0.4左右保留一点多样性但不要太高。理由归因本身有主观性完全确定性的输出可能掩盖多因素耦合但超过0.7就会开始编造停机原因了。注意MES的归因和APS排产不一样排产建议要尽量稳定归因分析可以容忍发散。所以同一个模型、同一个工厂不同场景应该使用不同的temperature和prompt。这个细节写进方案里很加分实际运行中也能减少不少无效争论。有些工厂觉得数字孪生看板很炫但用下来真正管用的还是MES里沉淀的数据大模型让这些数据第一次能被车间直接问。4.2 EMS 能耗优化让模型读抄表数据给出班次级建议EMS能源管理系统里积累了大量的水电气数据但工程师通常只看累计用量很少逐日分析。用DeepSeek做能耗预测的常见做法是把最近7天的整点抄表数据按天聚合让模型识别尖峰时段并结合生产计划给出调整建议。energy_data [ {day: 2025-06-01, peak_hour: 14, usage_kwh: 12800}, {day: 2025-06-02, peak_hour: 15, usage_kwh: 14400}, {day: 2025-06-03, peak_hour: 14, usage_kwh: 12100} ] resp client.chat.completions.create( modeldeepseek-chat, messages[{ role: user, content: f 以下是工厂近三天用电汇总{energy_data} 请找出能耗尖峰规律并给出明天的错峰生产建议。 要求建议与生产计划无关的靠后排优先调整可中断设备。 }], temperature0.3, max_tokens600 )这段代码最需要注意的是prompt里最后一句话“优先调整可中断设备”这是把工厂的业务约束塞进生成过程比在解析后硬过滤更有效。EMS场景还有一个特点历史数据是数值不是文本模型对数值的敏感度有限。所以不要让模型直接报“14时比15时高12.5%”而是在输出前把数值变化转成趋势描述再让模型基于趋势给结论。4.3 SRM 供应商协同让模型生成询价单和风险提示SRM系统里采购员每天要发大量询价邮件还要逐条核对交期、含税价、付款条件。DeepSeek在这里最适合做草稿生成。我会让采购员输入物料清单和期望交期模型输出一封结构完整的询价单邮件同时附带一个风险提示清单哪些物料交期太紧、哪些条款可能被供应商拒绝。srm_input { material: 电机 M-300, qty: 200, expect_date: 2025-07-01, payment: 月结30天 } mail_prompt f 你是采购助理。请根据物料信息生成一封中文询价邮件 物料{srm_input[material]} 数量{srm_input[qty]} 期望交期{srm_input[expect_date]} 付款方式{srm_input[payment]} 邮件必需包含物料规格确认、交期可行性、含税报价、包装运输方式。 另外用列表输出2到3条采购风险提示。 # 这里用普通文本输出即可不需要强制JSON这类场景对输出格式要求不高所以不需要response_format。但要在后续处理中把邮件正文和风险提示分开保存否则采购员复制粘贴时会把AI的风险提示也发出去。常见的做法是要求模型用---风险提示---分隔符解析时按分隔符截断。5. 上线前做三件事DeepSeek 幻觉约束、长对话压缩与回归测试5.1 用事实库约束模型禁止凭记忆回答工厂场景里模型幻觉的代价很高比如把安全库存50说成500可能导致采购下错单。我的做法是当问题涉及具体数值时要求模型只引用上下文里出现过的数据如果上下文里没有回复“当前快照中无此数据”。这个约束要写进system prompt但更可靠的是在应用层加一道检查解析模型输出中的所有数字与上下文中的数值做比对上下文里没有的数字一律标记为低置信度由前端用黄色高亮提示。这样比单纯靠提示词可靠得多。5.2 上下文太长时用分段对话代替无限加长DeepSeek达到对话长度上限是会报错的尤其是长时间挂着智能问答看板。遇到长会话先做一轮对话摘要再继续。我一般会用一个轻量脚本把超过10轮的历史消息压缩成100字以内的状态摘要然后作为system prompt的一部分继续。这个技巧能有效避免“请开启新对话”的提示也能保持跨轮次的业务连续性比如前面问了3号线后面接着问“那2号线呢”模型还能接得上。5.3 效果验证写一组固定题目做回归最后分享一个实操方法准备10到15个业务问题作为回归测试集每次改提示词或换模型版本都跑一遍。下面是我常用的最小脚本cases [ {q: 3号线今天有多少个未完工工单, must_have: [WO-]}, {q: A-1001物料库存是否低于安全库存, must_have: [低于]}, {q: 明天EMS预测尖峰时段, must_have: [时]} ] def run_regression(modeldeepseek-chat): passed 0 for case in cases: resp client.chat.completions.create( modelmodel, messages[{role: user, content: case[q]}], temperature0.2, max_tokens300 ) ans resp.choices[0].message.content if all(k in ans for k in case[must_have]): passed 1 else: print(fFAIL: {case[q]}) print(f通过率: {passed}/{len(cases)}) run_regression()这个脚本只检查关键词比较粗糙但对工厂这种领域足够当第一道防线。把must_have换成你必须保障出现的字段比如工单号前缀、物料代码、时间单位。每次重新部署前跑一遍如果通过率低于80%就不要上生产。此外把temperature固定在0.2以下跑回归结果才可复现。跑完回归后再挑三个失败用例看看是prompt问题还是模型本身理解问题这个分析动作比调参更重要。本文还有配套的精品资源点击获取