AI-native架构重建制造业ERP/MES系统：从排产到执行的完整实践

我在制造业信息化这条路上摸爬滚打了十多年，从早期单体 ERP 到后来微服务改造，再到这两年接触的各种"智能工厂"项目，见得太多了。今年年初我给自己定了一个有点疯狂的目标：用 AI-native 架构，从零重建一套面向制造业的 ERP/MES 系统。不是给老系统挂个"AI 助手"，而是把大模型当作运行时的一部分，把排产、报工、异常处理、质量判定这些核心业务，全部改写成可被 AI 调度、可被大模型理解的形态。这篇文章是我目前已经完成的整体思路、架构决策、实操路径和踩坑记录的完整复盘。如果你正在做制造业信息化、工业软件，或者单纯想看看 AI 怎么真正落到车间，这篇内容应该对你有用。

1. 为什么传统 ERP/MES 非改不可

1.1 传统架构的四个死穴

先别急着谈技术选型，我得先说说为什么要动手重建。传统 ERP/MES 这套东西，在制造业里跑了三十年，底子非常扎实，但也把一些结构性毛病固化下来了。

第一个死穴是计划与执行断层。ERP 里的计划员排完产，得到的结果是一张张工单和交期承诺，但车间里真实情况是设备随时可能故障、人员可能请假、物料可能晚到。MES 系统接收执行结果后，只会把报工数据回传，计划员还是靠 Excel 手动调整。两个系统各干各的，数据永远差半天。这个问题我在三个工厂都见过，几乎没有例外。

第二个死穴是数据孤岛。ERP 管订单、采购、库存，MES 管工单、工序、质检，两套系统的物料编码、工序编码、工作日历都各有一套。我见过最夸张的案例，同一个物料在 ERP 里叫"CNC-01-0023"，在 MES 里叫"数控件A-23"，Excel 映射表有三百多行。这种数据基础，后面的统计分析全都不靠谱。

第三个死穴是交互反人类。操作工在工控机上完成一次报工，要填工单号、工序号、数量、合格数、不良数、设备号、班次，十来个字段，一轮下来三分钟。老师傅宁可手写在小本子上，也不愿意碰那个界面。质检员就更痛苦了，一套来料检流程要跳五六个页面，填十几张表。

第四个死穴是变化响应慢。制造业最怕什么？插单、缺料、设备宕机。传统系统面对这些突发情况，只能事后记录一笔"异常工单"，然后等计划员第二天早上开会协调。现场决策完全依赖人的经验，系统本身是一个哑巴盒子。

这四个死穴不是靠修修补补能解决的，它们根植于过去的架构假设：系统是记录工具，人是决策主体，数据是事后资产。要改变这个局面，必须把决策能力搬进系统本身，而这正好是 AI-native 架构能做的事。

1.2 AI-native 到底指什么

这几年 AI-native 这个词被用滥了，很多厂商把老系统接个 ChatGPT 接口就说自己是 AI-native，这是很误导人的。我自己对 AI-native 的定义，有四个硬性条件。

第一，模型在架构中是一等公民，而不是外部调用。传统集成是业务代码里偶尔调一次大模型 API，AI-native 则是模型通过 Agent 运行时参与业务编排。排产、异常处置、质量判定这样的事件，触发之后可以交给模型分析、生成方案、调用工具执行。

第二，业务对象必须有语义层。系统里的物料、BOM、工艺路线、工单、报工记录，不仅要有数据库字段，还要用结构化描述告诉模型这些概念的层级关系、约束条件、业务含义。模型不是靠猜来理解"工单 W001 的第 3 道工序报工 50 件"，而是通过领域模型和工具契约来准确理解。

第三，交互方式从表单驱动变成意图驱动。操作工可以对着系统说"3号设备加工完成 50 个"，系统解析之后自动匹配工单、工序、设备，生成报工记录并校验。这种交互不是把表单搬到聊天框里，而是让系统理解上下文后主动完成一系列动作。

第四，决策链路必须是可回滚、可审计、可校验的。AI 给出的任何排产建议、质量判定、异常处置方案，都要有决策记录表，标明输入参数、模型输出、执行结果。允许 AI 犯错，但不允许它犯完错不留痕迹。

搞清楚了这四点，就明白为什么我说不能直接把旧系统包一层壳就完事。旧系统的核心流程是固定写死的，模型插不进去。重建不是为了追热点，是为了换一种系统组织方式。

1.3 这套系统解决什么问题、适合谁参考

这套系统的目标用户，我定位在中小型制造企业。大型集团早就自建了完整信息化体系，很难推倒重来，但中小工厂恰恰是传统 ERP/MES 渗透率低、痛感最强的群体。他们没有几百人的 IT 团队，需要一套更轻、更聪明、能小步快跑落地的东西。

它解决的问题，说白了三句话：让排产计划贴近车间真实状态，让现场报工和异常处理不再依赖纸质和 Excel，让管理层随时能用自然语言问出"这个月哪条产线拖期最严重"并且拿到实时答案。

如果你正在做制造业信息化相关的项目，或者你是独立开发者想切入工业软件市场，又或者你只是对 AI Agent 在垂直行业落地感兴趣，这篇文章里的取舍思路应该都能给你一些参考。我后面写的所有东西，都是基于真实编码踩坑得出的结论，不是从 PPT 里抄来的概念。

2. 整体架构设计与技术选型

2.1 六边形架构 + DDD 的分层拆分

整个系统我采用了**六边形架构 + 领域驱动设计（DDD）**的组合。这套组合在互联网行业已经非常成熟，但在传统工业软件里见得不多，原因是工业软件之前的交互模式太固定，不需要这么灵活的分层。

六边形架构的核心思想是：把业务逻辑放在最内层，把数据库、外部接口、AI 模型、消息队列这些技术细节全部放在外层的适配器里。举个例子，排产引擎是内层核心，它可以接收来自 Excel 导入的数据、来自 MES 接口的工单、来自 AI Agent 的指令，但它本身不关心这些指令从哪里来。这种设计带来的最大好处，就是领域逻辑不会被技术栈绑架。

选型时我做过一次对比测试：用传统三层架构写排产模块，用了两周，代码和 SQL 强耦合；后来按照六边形重构，多花了三天拆层，但后面新增 AI 接入的时候，我只写了三个适配器类，没有动任何核心代码。这个账，长期看非常划算。

DDD 的部分，我重点用在了领域建模上。物料、BOM、工艺路线、工单、报工、质量任务这些概念，如果只是建表，后面所有业务逻辑都会变形。我花了三周时间做事件风暴，把十来个核心实体的行为、状态、事件梳理清楚。比如"工单"这个实体，不是一张表，而是一组状态机：创建、下达、开工、完工、关闭、重开。每一次状态变更都会产生领域事件，供其他模块响应。

2.2 把大模型当"运行时组件"而不是"外部工具"

这个设计决策是整个 AI-native 架构最核心的部分，我要单独拿出来说。刚开始我也犯过很多团队的毛病，把大模型当成了"高级查询接口"，后来我彻底改掉了这个思路，把它当作一个运行时组件。

所谓运行时组件，意思是模型被编织进业务事件循环里。当系统检测到设备故障信号，会触发一个"设备异常处置事件"，这个事件既可以被规则引擎处理（如果规则明确，比如"停机超过 30 分钟自动通知主管"），也可以被 AI Agent 接管。Agent 拿到事件上下文后，会调用工具去查询当前这个设备上的在制工单、物料准备情况、替代设备产能，然后生成一套处置方案。方案经过人确认后执行，执行结果回写系统。

为了让模型能调用业务方法，我把核心业务能力全部暴露成结构化工具。比如query_capacity(work_order_id, date_range)、report_progress(operation_id, qty, defect_qty, equipment_id)、suggest_reschedule(work_order_id, priority)这类的。每个工具都有严格的入参出参描述，系统在模型返回 JSON 指令后做参数校验和权限校验，再真正执行。

这才是 AI-native 和"接个大模型 API"的本质区别：模型不是问一句答一句的聊天对象，它是业务流程里一个可以调度资源、执行动作的参与者。

2.3 核心模块拆解

整个系统我拆分成了八个核心模块，每个模块之间通过事件和消息通信，不搞大一统的数据库级耦合。这八个模块是：

• 主数据服务：物料、BOM、工艺路线、设备、设备组、班组、工作日历，这一层是所有业务的底座。
• 订单协同：销售订单、预测、变更管理，承接商机到计划的需求输入。
• 计划与排产引擎：粗能力平衡、精细化排产、插单模拟、交期承诺。
• 车间执行：任务派工、工单流转、报工、工时归集、异常上报。
• 质量体系：来料检、过程检、终检、不良品处理、质量追溯。
• 设备管理：点检、保养计划、故障申报、维修记录、OEE 计算。
• 追溯与批次：批次档案、序列号管理、正向反向追溯。
• 报表与分析：面向管理者的实时看板、经营分析、AI 问答报表。

模块划分的标准并不是"按页面切"，而是按业务生命周期切。比如质量追溯模块为什么独立？因为质量数据的生命周期（产生、流转、判定、闭环）和工单生命周期不一样，混在一起会让两边都很难改。

2.4 技术栈选型与实际落地清单

技术栈方面，我一开始就走了比较务实的路线，没盲目追新。后端用Java 21 + Spring Boot 3.2 + Kotlin 混合开发。Java 的生态和人才储备是制造业场景最稳的，Kotlin 则让核心领域逻辑的表达简洁很多。数据库选了PostgreSQL 16，业务数据全放这，时序类数据（设备采样、温度、功率、振动）用 TimescaleDB 扩展。消息中间件用了 RabbitMQ，够用、易维护，不引入 Kafka 这种重量级组件。

前端是 React + TypeScript + Tailwind CSS。我不是前端出身，选了最保守的组件库组合，没有搞花活。部署方面，单机先用 Docker Compose，后续多节点再迁到 Kubernetes。这一步很多团队会一步到位上 K8s，结果运维成本直接把小团队拖垮。

AI 层面的选型要特别说明。我没有只依赖云端大模型 API，因为制造业车间对数据私密性和离线连续性的要求非常高。我的方案是双通道模型路由：常规查询和辅助建议走本地部署的 Qwen2.5-72B，用 Ollama 和 vLLM 跑；复杂推理、跨模块综合分析走云端的大模型通道。业务层做了一层模型网关，当一个通道不可用时自动降级到另一个。

2.5 为什么不用现成低代码平台

这个事我必须展开说，因为好多朋友听说我要从零做，都会问我一句：为啥不用低代码平台？我认真评估过，结论很明确——低代码平台撑不起 AI-native 这种架构需求。

低代码平台的核心能力是表单 + 流程 + 报表，这对行政管理类应用很够用，但对制造业 ERP/MES 来说远远不够。排产引擎需要复杂的约束求解算法，低代码平台没有这种编辑器；设备数据采集需要协议适配层，低代码平台通常只提供数据库读写；AI-native 要求模型能和业务方法自由组合调用，低代码平台的扩展插件机制根本接不住这种复杂度。

更关键的是，低代码平台会把你锁在一个别人的抽象层里。等你做到第三年想改它的底层架构，会发现改不动，只能推倒重来。制造业系统的生命周期动辄十年起，这个锁死风险我承受不起。

3. 核心引擎实现：从排产到执行的闭环

3.1 产能模型与排产算法的设计思路

排产引擎是 ERP/MES 里最难啃的骨头，也是最容易翻车的模块。我的设计原则是：先用规则引擎兜底，再用启发式算法优化，最后让 AI 在边缘场景做决策，三个层次逐级递进。

产能模型的底层数据很简单：设备、设备组、工作日历、工序标准工时、物料可用量。每个工序有一个标准时间，再乘以设备效率系数，得到实际加工时间。工作日历定义了设备每天的工作时段，比如三班倒、倒班规则、节假日。这些都是基础数据结构，但百分之八十的项目死在它们没建好。

排产算法我用了两层。第一层是约束满足，把一个工单分解成若干工序，每个工序匹配到可用设备组，检查物料是否齐套、设备日历是否可用。这层必须保证产出的是可行排产方案。第二层才是优化，用遗传算法，目标函数是交期达成率、设备负荷均衡度、换型次数加权求和。遗传算法的种群规模设 100，迭代 200 代，在单条生产线上十来个工单的规模，跑一次大概五秒，完全够用。

AI 在排产里的角色，我限定在插单模拟和异常重排。当临时订单进来，规则引擎先给一版排产结果，AI Agent 会分析这版结果对现有工单的影响，给出"优先插单 A、推迟工单 B 两天"这样带理由的建议。排产结果一定要可解释，不能是黑盒，否则车间根本不接受。

3.2 AI 助手的接入方式：Function Calling 与 MCP

AI 助手不是我后来加的，它从一开始就是系统的一部分。为了让模型具备调用业务方法的能力，我采用了Function Calling + MCP（Model Context Protocol）的标准组合。

MCP 主要用来管理上下文和工具定义。我把系统的领域模型、常见业务流程、工具清单都通过 MCP 暴露给模型，模型每次运行时能感知到"当前有哪些工具可用、每个工具的参数要求是什么、哪些动作被允许"。这样模型不会凭空编造一个不存在的接口。

下面是我给 AI 助手注册工具的一段核心代码，用 Spring Boot 的 Bean 方式暴露：

@Component public class WorkOrderTools { private final WorkOrderService workOrderService; public WorkOrderTools(WorkOrderService workOrderService) { this.workOrderService = workOrderService; } @McpTool(description = "根据工单号查询工单当前状态、工序进度和剩余数量") public WorkOrderStatusVO queryWorkOrderStatus(@McpParam(name = "workOrderId", description = "工单编号") String workOrderId) { return workOrderService.getStatus(workOrderId); } @McpTool(description = "为指定工单的指定工序提交完工数量，可选填不良数") public ReportResult reportOperationProgress( @McpParam(name = "operationId") Long operationId, @McpParam(name = "completedQty") BigDecimal completedQty, @McpParam(name = "defectQty") BigDecimal defectQty) { return workOrderService.reportProgress(operationId, completedQty, defectQty); } }

这里的关键是工具描述必须写清楚业务语义。比如"提交完工数量"工具，如果不说明"提交后该工序状态变为已完工，不可重复提交"，模型就可能在同一道工序上报两次。为了规避这类问题，我在每个工具的实现里都加了状态机校验，防止模型产生非法操作。

模型返回的是结构化 JSON 指令，比如{"tool": "reportOperationProgress", "params": {"operationId": 123, "completedQty": 50, "defectQty": 2}}。我的执行引擎会先做参数合法性校验、权限校验，然后才真正调用业务方法。任何一次调用都会写入审计日志。

3.3 数据模型设计要点与字段级细节

数据模型设计上，我把主数据和单据数据、实时数据严格分开。主数据表有 material、bom、route、equipment、device_group、calendar；单据表有 sales_order、work_order、operation_record、quality_task；实时表有 equipment_status、temp_log、power_log。

我踩过的一个大坑是时间字段类型。传统系统里很多人用本地时间，跨班次、跨时区一算就乱。我从一开始就统一用timestamptz，所有接口传 ISO 8601 带时区格式。另一个坑是批次字段，我之前偷懒用自增 ID，后来发现做批次追溯时根本没法定位唯一记录，强烈建议用 UUID 或雪花 ID。

工单表的设计我额外加了一个字段snapshot_json，每次工单状态变更时，把当前的完整上下文（工艺路线、已完工序、在制数量、设备分配）序列化存进去。这样追溯的时候不需要回放所有历史日志，直接读快照就行。代价是多了点存储，但换来的是追溯查询从秒级变成毫秒级，这个取舍非常值。

3.4 让 AI 理解车间语义：提示词与领域模型设计

这一步是最容易被忽略、但实际效果差异最大的部分。我发现直接给模型一本操作手册它是不会用的，真正有效的方式是给它一个领域词典 + 工具契约 + 少量示例。

领域词典里，我会定义"工单=生产任务，包含多道工序；工序=在特定设备组上的加工步骤；报工=对某道工序完成输入的操作"。模型需要理解这些词的关系，才能把"3号机干完了"这句话正确映射到"设备编号 E003 对应的工序完成报工"。

Few-shot 示例也非常重要。我写了三五个真实场景，比如"客户电话要求插单 500 件，最迟周五"应该触发什么工具、输出什么格式。示例不需要写很多，三五个高质量的就够让模型进入正确的工作模式。

还有一个细节：不可见上下文不参与决策。我给模型传的业务数据，是定了白名单的，涉及成本和利润的敏感字段默认不传。不是说模型不可信，而是这个系统使用场景是车间，有些数据确实不属于 AI 决策范围。

4. 实操过程与踩坑记录

4.1 从零搭建第一步：领域建模不要先画界面

很多开发者的第一反应是画界面、建数据库表，我这次完全反着来。项目启动后的头三周，我几乎没有写代码，全程在做事件风暴。我用一面白板加便利贴，把"订单录入、计划评审、工单下达、开工、报工、质检、入库、异常处理"这些业务流程全部推演了一遍。

我强烈建议你在这个阶段千万别着急开发。我的原因是：制造业业务流程每个厂都不一样，你如果按某个厂的习惯建了表，换一个厂就死了。事件风暴帮你把业务里恒定不变的那些核心概念挖出来，这些概念才是系统的地基。

具体做法是：找三个业务专家（在工厂里就是生产经理、计划员、车间主任）各聊一下午，把事件的顺序理出来，再把每个事件关联的数据和决策点标出来。这个投入一点都不浪费，后面写代码可以快一倍。

4.2 大模型接入的三种模式对比

我先后试了大模型接入的三种模式，这里列个表给你参考：

我最终的方案是第三种为主、第二种补充。RAG 主要用于设备维修知识库的问答，Agent 编排用于计划、执行、质量的核心闭环。如果你一开始就上 Agent，大概率会被各种意外输出折磨到崩溃，所以我建议先从 API 直调跑通流程，再逐步切到 Agent。

4.3 数据同步与工业协议对接

车间层的数据采集是 MES 的根基，对接协议基本绕不开 OPC-UA、MQTT 和 Modbus TCP。老设备大部分用 Modbus，新设备基本都有 OPC-UA 或者 MQTT 网关。我在系统里做了一层统一采集适配器，不管底层是啥协议，数据到了系统里都是一个统一结构：设备 ID、参数名、时间戳、数值、质量戳。

这个设计看似简单，实际帮我省了非常多麻烦。原来对接每台新设备都要写一整套逻辑，现在只需要配置设备参数映射表。比如 Modbus 的寄存器地址 40001 对应"主轴电流"，在映射表里配一条记录，数据就自动入库了。一个两百多台设备的车间，用了不到两周就把主要产线接完了。

这里有个提醒：设备数据的质量戳（quality flag）一定要保留。很多数据采集项目把这个字段丢了，结果系统显示"主轴当前转速 9000"，谁知道是真值还是传感器坏了？带质量戳才能区分有效值和异常值。

4.4 性能与成本控制：不让 AI 拖垮系统

AI-native 最现实的问题是成本和延迟。如果每个操作都要经过大模型，系统会又慢又贵。我做了两个重要决策。

第一个决策是高频场景不走模型。设备报工这件事，是车间里最高频的操作，一天可能几千次。这种场景用规则引擎直接处理，两毫秒完成。AI 只处理那些需要判断、需要整合信息的低频场景，比如异常分析、插单影响评估、质量趋势归因。

第二个决策是语义缓存。同一个业务问题（比如"上月 A 线 OEE 是多少"），很多人会反复问，我做了查询结果的语义缓存，命中后直接返回，不再调模型。同时模型调用全部走流式响应，用户在界面先看到"正在分析"的占位，实际响应体感快很多。最终测算下来，每千次调用的成本比全量直调低了七成。

4.5 权限与安全：车间数据不能乱给 AI

AI-native 架构下，安全和权限模型必须重新设计。传统系统的权限是页面级、按钮级的，AI 系统里，模型可能通过工具访问任意数据，所以权限控制必须下沉到工具调用和数据访问层。

我用了 ABAC（基于属性访问控制），每个请求都携带主体属性（用户、角色、所属车间、班组）、资源属性（数据所属产品线、密级）、环境属性（时间、地点）。比如质检员小王，只能查看自己班组的数据，只能触发质量判定相关工具，不能调用排产修改工具。

还有一个铁律：AI 没有删除和批量修改的权限。模型返回的指令里，如果包含 drop、delete、batchUpdate 这类操作，执行引擎直接拒绝并记录告警。AI 只能做"建议"和"执行可逆操作"，不可逆操作必须人工确认。这个约束让我后面的测试阶段少了很多惊吓。

审计上，我建了一张 ai_audit_log 表，每条 AI 调用至少记录：触发场景、输入上下文摘要、模型输出、调用了哪些工具、执行结果、耗时。这张表在系统的每一天都在增长，但它是我排查问题最重要的依据。

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

5.1 常见问题速查表

这个项目开发到中期，我攒了一批典型问题，列成速查表放在开发文档里，现在直接分享给你：

5.2 LLM 上下文爆掉怎么办

这个问题出现过好几次，症状是模型忽然开始胡言乱语或者返回空结果。原因基本都是上下文塞太多不相关的东西。我后来定了上下文管理规范：每个请求最多携带最近十轮消息和当前业务对象的精简视图，长文档走 RAG，不直接塞进 prompt。

还有一个有效做法是定期摘要。如果一轮对话超过二十轮，系统会把前面的内容压缩成一个结构化摘要，比如"已完成 3 号工单的排产分析，建议推迟 B 工单，等待确认"。这样模型在后续对话里不会丢掉关键信息，也不会被冗余细节淹没。

5.3 排产结果不收敛的排查思路

排产引擎跑不出可行解，是排产模块开发期最容易遇到的事。我排查下来，百分之八十的原因是约束建模太死。比如一台设备日历里被写死了不可用时段，而某个工序只能在这台设备上加工，时间窗口完全重叠，就必然无解。

解决思路是引入松弛变量。把"必须本周完成"改成"建议本周完成，每延迟一天扣 10 分"，然后在优化目标里加惩罚项。这样即使没有完美解，算法也能给一个代价最小的次优解。AI 这时候再上场，解释这个次优解为什么产生、以及可能的补救动作。

5.4 车间网络不稳定的容错机制

制造业车间的网络环境比写字楼恶劣太多。我遇到过 Wi-Fi 信号死角、交换机被叉车撞断、PLC 网关内存溢出，各种情况。容错设计必须从第一版就做。

我给系统加了三层保护。第一层是边缘缓存，报工数据本地先存一份，网络恢复后自动同步；第二层是断线重连补偿，消息队列里未确认的消息会自动重发；第三层是降级模式，云端大模型不可用时，自动切到本地模型或者规则引擎，核心业务不停摆。

还有个小技巧：我在每台工控机上部署了一个轻量本地代理，即使中心服务器挂了，操作工也能在本地完成报工和查看今天的任务清单。这个设计在真实车间里救过我好几次。

5.5 测试策略：双模校验

AI 系统最让人揪心的是它偶尔不按常理出牌。我的测试策略是双模校验：同一个业务场景，同时跑规则引擎和 AI 通道，两边输出对比，差异超过阈值就触发告警并记录。

在排产模块，我导入了过去一年的历史生产数据，用 AI 通道生成排产方案，再和当年实际排产方案对比。如果 AI 方案比实际方案总提前量更高而且约束不冲突，说明排产逻辑是靠谱的。在质量模块，我准备了一千条历史质检记录，让 AI 做判定，和当年质检员判定对比，算准确率和召回率。这套双模校验机制帮我提前发现了两处提示词设计和工具描述的问题，非常值。

6. 后续扩展与个人体会

6.1 从 MES 走向数字孪生

系统核心跑通之后，我接下来的扩展方向是数字孪生。MES 掌握了实时生产数据，只要把这些数据映射到三维车间模型上，就能做虚拟车间漫游、设备状态可视化、瓶颈分析。AI-native 架构在这里又有一个优势：数字孪生里所有查询都可以通过自然语言完成，比如"把 A 线当前瓶颈设备标红"或者"回放昨天下午 3 点的设备温度变化"，模型直接调用孪生查询工具返回结果。

但要提醒一句，数字孪生是个无底洞，别一上来就追求全厂三维高精度建模。先做单条产线的设备三维模型，接到实时数据，跑通一个场景，再逐步扩展。否则建模成本会让你心态崩掉。

6.2 AI-native 团队的组建建议

最后聊几个团队相关的实操体会。AI-native 项目跟传统软件开发对团队能力要求很不一样，最核心的变化是：团队里必须有人懂制造业业务流程，又必须有懂 LLM 工程的人，两边不能各干各的。这个跨界角色我称为业务智能工程师，他能把"车间里一个老师傅的自然语言指令"翻译成系统的工具调用链，这种能力非常稀缺。

另外，我在项目里做过一个很管用的动作：每周让车间主任带着当前版本的测试账号在产线上跑半个小时，看他哪里卡住、哪里不敢点。这一个小时的反馈，比我在办公室看三小时日志都有用。制造业软件是给人用的，不是给电脑用的，这个道理越到后面越深刻。

我自己从年初开始做这套系统，到写完这篇文章时，排产、报工、质量闭环已经在一个试点车间跑通了，每天进出几千条报工记录，AI 助手承担了大约百分之三十的异常分析和插单建议。说实话，距离我理想中的完整 AI-native ERP/MES 还有很大距离，但至少起点是对的。如果你也想做类似的事，我给你的最大建议就是：别把 AI 当外挂，把它当成系统里一个真正干活的角色，一切设计围绕这个角色展开，其他顺势而为。