AI-Native架构重构制造业ERP/MES：从数据底座到智能排产实战

1. 为什么说这次重建不是给老系统“加个 ChatGPT”

1.1 “AI-Native”和“AI套壳”本质上是两码事

先把这个概念掰开。如果只是给传统 ERP/MES 的界面上加一个对话框，让用户问“这个工单到哪一步了”，然后系统去查一张数据库表把结果吐出来，这不叫 AI-native，这叫“给老房子刷一层新漆”。AI-native 的核心在于，AI 不是系统的附属功能，而是系统设计时的第一公民。业务规则、数据流向、交互方式、异常处理策略，全部围绕“模型可以理解、模型可以决策、模型可以被评测”来组织。

我在第一版设计时犯过很典型的错误：把一套运行多年的 MES 数据表直接暴露给大模型，期望它能通过自然语言回答一切问题。结果模型确实能回答，但回答里掺杂了大量幻觉，工单号会编造、数量会算错、状态会张冠李戴。后来我才意识到，问题不在模型，而在底层数据的组织方式。传统 ERP/MES 的数据结构是给“人+表单”设计的，字段名、关联关系、状态流转全要靠人去理解，模型拿到的只是一个碎片化的快照，它根本不知道该信什么。

这次重建，我把思路彻底翻过来：先定义 AI 的“认知层”，也就是模型理解业务所需的语义模型和上下文，再从认知层出发设计数据模型和业务接口。用一句话概括：先让系统能“读懂”工厂，再谈让系统去“干活”。

1.2 制造业 ERP/MES 是验证 AI 架构最好的“硬骨头”

选制造业作为落地场景，不是因为它容易，恰恰是因为它足够复杂。ERP 管的是企业资源，计划、采购、财务、成本、库存，MES 管的是车间执行，派工、报工、质检、设备、物料追溯。两者叠加之后，你要面对的不只是功能堆叠，而是一条极其漫长的核心链路：销售订单进来，拆成生产计划，计划再拆成工单，工单落到产线，产线按工艺路线执行，每道工序要报工、要抽检、要记录设备参数，最后完工入库，再回冲成本。这条链路里任何一个环节的数据失真，后面全都白搭。

更麻烦的是长尾场景。同一个集团下，不同工厂的工艺路线可能完全不同，有的按批次生产，有的按单品流；有的质检靠人工目检，有的靠在线检测仪；有的物料是严格先进先出，有的可以替代混用。传统系统面对这种差异，只能靠堆积配置项和定制开发，结果就是上线周期长、维护成本高、每个工厂都成了“一套私有系统”。而 AI 恰好擅长从异构数据里提取模式。如果架构到位，它可以把分散的老师傅经验、历史工艺参数、设备运行日志整合起来，在适配层做到“每个工厂有自己的模型，但共用一套底层平台”。

1.3 从零重建的整体架构：先分层，再分阶段

我的做法是“两条腿走路”。一层是稳定内核，承载不可动摇的业务规则和数据主数据；一层是智能增强层，承载所有需要判断、预测、推荐、优化的环节。两层之间用领域服务接口隔离，确保 AI 输出的结果永远只能作为“建议”进入业务主链路，而不是直接篡改表单数据。具体分层我整理成了这样一张表，后续所有设计都围绕它展开：

这张表和传统微服务架构最大的区别在第 3 层。如果团队全部资源有限，我强烈建议只保留“数据底座 + 领域服务”两层，其余全部用成熟组件替换。前期没必要自己训练模型，也没必要造 Agent 框架，先用现成的 LangGraph 这类流程编排工具跑通两三个场景，比铺一个大摊子稳妥得多。

2. 模型底座与 AI 基础设施：先想清楚再动手

2.1 选型原则：私有化优先，能本地跑就不上公网

制造业工厂的信息化环境，和互联网公司做开发完全是两个世界。大部分工厂对内网有严格要求，生产网段与管理网段物理隔离，数据出不了厂区。更不用说很多企业还有国产化适配要求，CPU 架构、操作系统、数据库都可能不是主流 x86 + 商用数据库的组合。所以第一原则就是：所有 AI 组件必须能私有化部署，且不能依赖公网 API。

我实际用的组合是国产开源大模型加 vLLM 做推理服务。7B 到 14B 规模的中文模型在工单语义理解、工艺知识问答、排产建议生成这三个场景里已经够用。用 4bit 量化之后，一张 24G 显存的显卡就能跑 7B 模型，推理延迟在 2 秒以内，这个表现对工厂场景足够友好。量化和非量化版本在中文效果上有差异，根据我们自建的评测集，大概会掉 2% 到 5% 的准确率，但换来的部署成本和运维简单程度是值得的。

为什么不直接用公有云大模型 API？在制造业这个行业，数据合规和数据主权不是小问题。生产工单里有工艺参数、有客户信息、有成本数据，这些一旦出域，法务风险直接拉满。就算只是调用 API 做语义理解，请求报文里也会带上业务上下文，这个口子不能开。所以从一开始就把私有化部署定为硬约束，到了实施阶段反而省了很多扯皮。

2.2 AI 基础设施四件套：模型网关、知识库、提示词管理、可观测性

很多团队做 AI 改造时最容易犯的错误，是只关心“模型好不好”，不关心“模型怎么接入系统”。大模型是一个概率引擎，它会胡说八道，会格式错乱，会因为提示词改动一点点就输出完全不同的结果。所以要把它稳定地嵌入业务系统，基础设施的成熟度比模型本身的强大多几十倍。

第一件是模型网关。这里的网关不是 API 网关那么简单的转发，它要负责统一多模型路由、请求限流、上下文管理、输出格式校验。同一个业务能力背后可能切换多个模型，提示词模板也是按业务场景隔离的，这些都要由网关统一管控。我在实际项目里直接基于 Spring AI 框架扩展了一层，把模型供应商全部抽象成统一的接口，后续替换模型不会影响上层的业务代码。

第二件是 RAG 知识库。把工艺卡、设备维护手册、质量检验规范、历史变更记录全部结构化后写入向量库，再按车间和工序做分区检索。LangGraph 在里面承担了检索增强的流程编排，比如“先检索相关工序的工艺参数，再让模型基于检索结果做分析”。这一步极其关键，因为 LLM 的幻觉问题无法根除，只能靠“先给它正确的参考资料，再要求它严格基于资料回答”来压制。知识库的更新不能靠手动上传文档，要配套一个文档解析管道：PDF、Word、Excel 进来自动切分、清洗、向量化，然后人工审核后发布。

第三件是提示词管理平台。这个很多人不重视，直到出了事故才后悔。一个排产建议生成的提示词，哪怕只是改动了一个变量描述，都可能导致输出结构完全变化。我的做法是每个业务场景的提示词都有版本号、审批人、上线时间，并且配套一份针对该场景的评测数据集。提示词更新必须先跑回归测试，通过后才能发布。

第四件是可观测性。LangSmith 负责 AI 链路的日志追踪，记录每次检索命中了哪些知识片段、模型输入输出是什么、置信度多少。同时用 SkyWalking 对整体微服务链路做 APM 监控，看 AI 服务调用是否拖慢了主流程。在 MES 这种实时性要求高的系统里，一个 AI 服务超时不能阻塞工单报工，必须设超时熔断和降级开关。

2.3 和旧系统并行期的集成策略

从零重建不等于一夜之间替换老系统。制造业最忌讳的就是把还有大量业务在跑的系统突然停掉。我的方案是“双轨并行 + 消息同步”：旧系统继续跑财务和账务功能，新系统优先接生产执行侧的工单、报工、质检数据，两侧通过 Kafka 消息队列做实时同步。这里有个血泪教训：集成层必须由一个专职小组负责，ERP 的主数据（物料、BOM、供应商）是每天全量同步，MES 的工序数据是实时增量同步，两边一旦出现数据不一致，谁也不敢信哪边是对的。

并行期通常维持三到六个月。在这个阶段，新系统的价值主张不是“替代旧系统”，而是“先把现场数据抓准、抓全、抓实时”。等到 AI 侧的几个核心场景（排产建议、质量预警、工艺推荐）跑出效果，业务部门自然会愿意切换到新系统。强行切换是灾难。

3. 数据层是 AI-Native 的命根子：从“表结构”走向“实时数据流”

3.1 数据采集：OPC UA、PLC、断点续传，一个都不能少

如果数据进不来，AI 再强也是空中楼阁。制造业的数据采集场景比互联网复杂得多，设备来自不同厂家，支持的协议各不相同，老设备甚至只有硬接线信号。我当前的采集方案是分层的：PLC 和传感器走 OPC UA 或 Modbus TCP 接入，采集网关负责协议转换；扫码枪和人工上报走 HTTP API 或者移动端表单；DCS 系统的数据通过厂商提供的数据接口对接。所有采集器统一把数据包发到 Kafka，由下游决定如何使用。

这个架构里最容易被忽略的是数据补偿能力。车间网络不可能 100% 稳定，交换机半夜重启、光纤被叉车撞断都是日常。采集器如果发现与服务器的链路断了，必须先把数据本地缓存，并在恢复后按时间戳补发。这块在我第一版设计里没做，后来有一个班次的产量记录出现空洞，排产模型拿到的数据比实际少了 8%，给出的建议直接没法用。补偿机制做好之后，就算断网半小时，恢复后也能自动回填，数据完整性基本能达到 99.9% 以上。

点位管理同样重要。工厂里几百台设备，每台设备几十个点位，如果点位表是 Excel 维护的，后续数据治理就是灾难。我把所有点位抽象成统一的数据点模型，包括设备编号、测点名称、数据类型、单位、采集频率、报警阈值。工艺工程师可以在界面上维护点位，而不是让开发人员改代码。点位元数据本身也进入数据字典，作为 AI 理解车间语义的基础。

3.2 业务对象与动态建模：让“物料”“设备”“工艺”变成模型能读懂的东西

传统 ERP/MES 的表结构为了追求稳定，通常会把物料属性、设备参数、质检项目这些全部打平成固定字段。问题是制造业的行业差异实在太大了，SMT 产线和注塑车间的物料属性完全不同，用一套固定的字段去描述所有业务对象，要么字段爆炸，要么只能凑合。我的方案是“固定主键 + 动态属性”混合建模：核心业务字段保留为强类型列，用于关联和统计，其余属性存入 JSONB 扩展属性。这样既保证了关键查询效率，又给不同工厂保留了扩展空间。

这套建模和 AI 的关系在于：无论是 RAG 检索还是模型推理，都需要把业务对象转换成模型能够知道的语义描述。我引入了“业务对象语义层”，每个业务对象都有一个机器可读的上下文描述，包括它属于哪个域、有哪些关键属性、与哪些对象存在关联、当前状态处于什么阶段。模型在生成答案或建议之前，先通过语义层确定业务对象，再获取对象的状态和上下文。这一步消掉了大量模型幻觉——因为它不再是凭空猜，而是基于检索到的对象属性作答。

在这个层面上，六边形架构和领域驱动设计的价值就体现出来了。领域模型封装在业务内核里，AI 服务只依赖领域服务接口，不直接操作数据库表。这样 AI 层无论怎么升级，都不会破坏底层的业务一致性。举个例子，工单的“状态流转”是所有工厂的铁律，AI 可以建议推动状态变更，但实际的状态机操作只能由领域服务完成，AI 无权跳过校验直接修改状态。

3.3 数据血缘与特征存储：让 AI 不“瞎猜”

AI 做预测最怕的是脏数据。做过制造业数据分析的人都懂，现场数据的质量参差不齐，有的车间数据靠人工录入，录错单位、漏记班次是常事。如果模型只看到“数值很正常”却没发现“这个数值来自一个很久没校准的传感器”，预测结果就不可能可靠。所以我在数据底座层专门加了一个数据血缘追踪模块，记录每个指标从原始点位到加工计算的全过程。任何一个 AI 输出，都可以回溯到它依赖了哪些原始数据，这些数据是否完整、是否被标记为异常。这个机制对审计和排障意义极大。

另外还需要一个特征存储层。排产模型要用的“设备利用率”、质检模型要用的“不良率趋势”、供应链模型要用的“供应商准时交付率”，这些特征会被多个场景复用。如果每个模型各算各的，口径不统一，结果自然对不上。特征层统一负责计算、缓存和版本管理，AI 服务从特征层获取数据，而不是各自连接业务库查询。

4. 业务功能重设计：AI 在真的制造业场景里到底怎么用

4.1 智能排产：生产计划从“人拍脑袋”到“多目标寻优”

车间排产是制造业永恒的老大难。作业车间调度问题本身是 NP-Hard 的，设备多了、工单多了，穷举根本不现实。过去工厂靠计划员在 Excel 里或者直接在 MES 的甘特图界面上手工拖拽，一个熟练的计划员排一天才能排出勉强能用的方案。更麻烦的是，计划永远赶不上变化，插单、设备故障、物料缺料随时打乱一切。

我用 AI-native 的方式重新设计了排产模块。核心不是让大模型直接生成排产方案，而是把它拆成两层：约束求解层 + 智能寻优层。约束求解器负责把工单的工序依赖、设备能力、物料齐套时间、交期优先级、换型时间这些硬性条件全部建模，确保输出结果不违反物理约束。智能寻优层则负责在可行解空间里寻找更优方案，优化目标包括最短完工时间、最低设备负载失衡度、最大准时交付率。大模型在这套流程里扮演的角色是“方案解读器”和“多目标平衡助手”，负责把计划员的口头约束（比如“这条产线下午要优先跑老客户的订单”）快速翻译成约束条件，以及把求解结果展示成易懂的描述。

用一个简化后的伪代码来说明我的实现思路：

# 排产决策服务（简化版） def suggest_schedule(work_orders, resources, constraints): # 1. 将自然语言约束转换为结构化约束（LLM 参与） nl_rules = parse_human_constraints(constraints) # 如 "周六不排设备3" # 2. 用约束求解器生成初始可行方案 initial = constraint_solver.solve(work_orders, resources, nl_rules) if not initial.feasible(): return {"conflict_type": parse_conflict(initial.conflicts)} # 3. 用大邻域搜索做多目标优化 best = local_search.optimize(initial, objectives=["makespan", "due_date", "load_balance"]) # 4. 将方案转成自然语言建议（LLM 参与） return { "schedule": best.as_json(), "summary": llm.summarize(best), "confidence": calc_confidence(best) }

我实测下来的效果是：在一个 20 台设备、150 张工单的车间，传统人工排产要两三个小时，系统方案在 3 到 5 分钟内能给出一个比人工更好或者相当的排产结果。而且方案的每一次调整都有记录，计划员可以对比“AI 建议版”和“人工改动版”的差异。这样做的好处是，计划员从执行者变成了决策者——他们不再花时间做重复的拖拽计算，而是把时间花在判断“哪个方案更合理”上。

4.2 工艺路线自动编排：把老师傅的经验变成知识库

工艺路线是制造领域的核心知识资产。零件怎么加工、先车后铣、热处理放哪个环节、每道工序用什么设备什么刀具什么参数，这些经验大部分存在老师傅脑子里，或者散落在多年积压的工艺卡文档里。这套知识一旦没有结构化，AI 根本使不上劲。

我做了两件事。第一件事，把历史工艺卡文档批量结构化。普通的文档解析工具搞不定复杂表格，我专门训练了一个文档抽取管道，利用文档版面分析与 OCR 的混合方式，把工序名称、工序顺序、设备要求、工装夹具、质量检验项这些字段全部抽取出来，写入知识图谱。第二件事，用大模型在知识库之上提供“工艺推荐”能力。当工艺工程师接到一个新物料号的试制任务，系统会基于历史相似物料和已知工艺模板，推荐一条候选工艺路线。工程师可以对推荐结果进行修改、确认或者否决。

这里必须强调一个安全边界：AI 只能推荐，不能自动变更已批准的工艺路线。在制造业，工艺文件一旦批准就是受控文件，任何修改都要走正式的工程变更流程。我见过有些团队为了让 AI 显得“智能”，直接让它改工艺参数，这几乎等同于在生产线上埋炸弹。AI 的价值在于把“找相似案例、查历史参数、写标准工序文本”这些体力活自动化，而不是替工程师做决策。

4.3 质量缺陷识别与闭环：AI 视觉 + 实时质检

质检是 AI 在制造业最容易出成果、也最容易挖坑的领域。最容易出成果是因为缺陷识别是典型的视觉任务，模型能力成熟，而且效果直观——检测出几个漏检的次品，老板马上能看到价值。容易挖坑是因为制造业的缺陷样本通常非常少，不良率千分之一甚至万分之一，采集到的缺陷样本根本无法支撑训练一个高质量视觉模型。

我的方案是“小样本迁移学习 + 在线难例挖掘”。先用公开的工业缺陷数据集预训练一个通用特征提取模型，再在工厂现场用少量缺陷样本做微调。每个缺陷类别只要有 200 张原始样本，配合旋转、缩放、光照扰动、噪声叠加这些数据增强手段，就可能训练出可用的模型——注意我这里说的是“可能”，因为不同缺陷的视觉特征差异很大，有些缺陷本身就很隐蔽，样本不够就是不行。

视觉模型的输出只是 AI 能力的一部分，真正有价值的是它和 MES 的闭环联动。当视觉系统检测到缺陷时，不再只是“截图保存”，而是自动触发质检工单、关联到对应的生产工单和批次、通知质检员复核、把缺陷图像和判定结果写入质量追溯档案。如果连续多批出现同类缺陷，系统会自动提高抽样频率，同时将趋势推送给工艺工程师。整个过程是数据驱动，而不是靠人工在纸质质检记录里翻找。

4.4 供应链风险预警：从“事后追”到“事中兜底”

制造业的供应链链条非常长，一个关键物料缺料可能导致整个产线停产。传统 ERP 的 MRP 运算跑完之后只告诉你“缺什么”，但不会告诉你“大概率什么时候会缺”“为什么缺”。有些资深采购经理能凭经验提前感觉到风险，但这种能力没法复制到每个采购员身上。

我用时间序列预测模型处理供应商交期数据，结合采购订单的齐套率、供应商历史准时交付率、库存水位和物料替代关系，预测未来四周的关键物料缺料概率。当系统预测某个物料在三天内有高概率缺料时，会自动生成预警单并推送给对应的采购员，同时附带建议动作：提前下单、加急运输、启用替代料、联系第二供应商。采购员可以选择采纳、修改或者忽略，每条建议的执行结果都会回流到模型，作为下一次预测的反馈。

当前这套模型跑下来，预警准确率在 75% 左右。这个数字意味着它可以当参考，但不能当圣旨——如果系统说“高概率缺料”但实际没缺，采购员会逐渐不信任系统；如果系统没预测到缺料但实际缺了，采购员会觉得系统“添乱”。所以预警文案里必须说明预测依据是哪些指标，让采购员能判断“这个预测到底靠不靠谱”。

5. AI-Native 研发模式：你怎么造这套系统比系统本身更重要

5.1 不要“翻译代码”：重构而不是搬砖

很多团队做“从零重建”时，最容易走上的一条弯路是：把旧系统的功能清单拿过来，用新架构重新实现一遍，美其名曰“升级”。实际上这就是一次复杂的代码翻译，业务逻辑没变、数据模型没变、交互模式没变，只是换了技术栈。最后做出来的系统可能性能更好、界面更好看，但 AI 能力依然无处安放。

我这次的做法完全不同。每个业务模块开发前，先做两件事：第一是重新梳理业务目标的北极星指标——比如排产模块的目标不是“能生成排产结果”，而是“计划员做决策的时间减少 50%”；第二是画一条“AI 介入点”的链路图——原来的审批流里哪个环节可以加 AI 建议、哪个环节可以由 AI 自动完成、哪个环节必须保留人工审核。这一步想清楚之后，写代码只是水到渠成的事。

这里我强烈推荐用六边形架构来组织代码。把领域模型放在最内层，外部依赖（数据库、消息队列、模型服务）全部通过端口适配器接入。这样做的好处是，大模型服务迭代频繁，但领域层的稳定程度可以很高。后续换模型、换向量库、换时序库，都只改适配器，不碰核心逻辑。

5.2 智能体（Agent）作为第一公民

AI-native 系统的职责边界不应该停留在“给一个对话框让用户提问”，更合理的形态是智能体。我设计了四个核心 Agent 角色：计划决策 Agent、异常诊断 Agent、知识检索 Agent、数据查询 Agent。它们共享底层的模型网关、知识库和工具集，但各自负责不同的业务场景。

计划决策 Agent 的模式是“人机协同”。生产计划员用自然语言描述目标：“这个订单很急，希望下周之前完成，同时尽量减少 3 号线的换型次数。”Agent 接收请求后，先做意图解析，转化为结构化约束，然后调用排产服务生成候选方案，再以自然语言说明推荐依据。异常诊断 Agent 则更偏向“主动监控”：当采集层发现设备参数异常或者产线节拍下降时，Agent 自动拉取最近时段的数据、检索设备手册知识库、结合历史同类故障的处理记录，生成一份诊断报告推送给维修工。这个报告不是简单罗列可能原因，而是给出按概率排序的排查建议。

Agent 的每个动作必须有审计日志。它问了什么、查了什么、调用了哪个工具、生成了什么建议、用户采纳还是拒绝，全部记录。因为这些 Agent 面向的是制造业生产环境，一旦出了问题，你需要能完整复盘 Agent 的整个推理过程，否则没人敢为它的输出负责。

5.3 安全管理与降级开关：AI 可以有错，但系统不能崩

制造业系统对可用性的要求非常高。白班高峰时段产线同时在报工，系统不能因为某个 AI 服务抖动就卡住。所以我在架构设计里加了三级安全机制。

第一级是置信度门槛。任何 AI 输出，模型都要附带一个置信度评分。低于阈值的结果直接标记为“低置信度，仅作参考”，不会进入自动执行流程。第二级是人工确认。涉及工单变更、工艺参数修改、设备停机建议这些高风险操作，AI 永远没有最终决定权。系统可以在界面上把 AI 建议展开成“建议内容 + 依据 + 影响范围”，由有权限的操作人员进行确认。第三级是降级开关。每个 AI 功能模块都有一个独立的开关，一旦线上效果不稳定，可以随时把该模块降级回传统规则模式。排产模块如果 AI 效果不行，可以退回人工拖拽的甘特图界面；质检 AI 如果误检率飙升，可以切回人工三检流程——核心业务链路必须做到“AI 挂了也不能停产”。

另外，回归基线测试不能省。每次更新模型或者提示词，都要拿历史工单数据做“回放测试”，对比新旧版本对同一批数据的输出差异，确保核心指标没有劣化。没有回归测试的模型升级就是在赌运气，在制造业赌不起。

5.4 模型评测：用工程化的方式管理模型版本

AI-Native 的研发模式里，模型服务和普通代码一样需要版本管理、测试、发布流程。我在内部维护了一个评测数据集，覆盖三个核心场景：质量判定场景 200 条样本、排产建议场景 100 条样本、工艺知识问答场景 300 条样本。每次大模型版本升级或者提示词模板变更，都要跑一遍全量评测，对比准确率、格式合规率、幻觉发生率和平均响应时间。

评测集里的样本要定期扩充。每次在线上发现模型出错，我都会把错误案例加入评测集并标记为“必测项”。这个机制保证了模型不会在同一个坑里反复跌倒。另外，我会给每个上线的模型生成一张独立的“模型卡片”，记录这个模型的版本号、训练数据范围、适用场景、已知边界和风险点。模型卡片不是形式要求，它是后续排障的基础——当业务部门质疑某个 AI 输出有问题时，我可以根据模型卡片快速判断是模型能力问题、数据问题还是提示词问题。

6. 落地时的坑与实测数据：这些弯路我替你走了

6.1 常见翻车场景速查表

这半年多在客户现场调试，踩过的坑一张表已经装不下了。我挑了几个最有代表性的写在下面，希望能帮你少走弯路：

6.2 三大雷区，踩中一个就得返工

雷区一：把 AI 放在决策位，却没有兜底机制。我在一些项目评审时见过别家团队的设计方案，AI 直接自动修改工单状态、自动下达采购建议。这种方案演示的时候很亮眼，真上线不出三天就会出乱子。务实的做法永远是“AI 建议、人来确认”。哪怕以后业务方对你的系统信任度提升了，这条底线也不要突破。

雷区二：只做了“能聊天的 MES”，业务闭环没打通。对话式的界面只是 AI 能力最表层的体现。如果大模型回答了一个问题，但不能触发实际的业务动作，那它只是一个昂贵的搜索引擎。AI 的价值在于闭环——回答了问题，顺手把对应的预警单创建了；分析了缺陷趋势，顺手把工艺工程师的待办任务生成了。业务闭环没打通，AI 就是企业的支出项而不是价值项。

雷区三：没有建立评测集就急于上线。模型能力迭代是一件持续的事，但如果没有评测集，你根本不知道每次模型更新到底是变好了还是变差了。我现在看到的很多工厂，AI 上线时才临时找几十条数据测一下，效果好不好全靠感觉，全靠运气。评测集不是大厂才需要的东西，任何有 AI 组件的系统都应该从小规模做起，从第一天就开始积累评测数据。

6.3 我个人的几条体会

第一，不要追求一步到位的“全 AI”，要从一个具体痛点切入。我选择从质量缺陷识别和智能排产这两个方向起步，因为这两个场景价值明确、数据相对好、效果容易量化。先把一两个场景做到业务方离不开，再去谈系统性的 AI-native 改造。

第二，数据是 AI 系统的水电煤。前期花在数据采集、点位治理、断点补偿、数据血缘上的时间，后期会在模型效果上十倍百倍地还回来。反过来，数据一团糟，模型再强也救不了。

第三，团队里必须有一个真正懂制造业流程的人。这里的懂，不只是会背几个概念，是那种知道车间里为什么会堆着料、为什么排产排得再好看也执行不下去、为什么工艺员宁可自己查老工艺卡也不用新系统的人。没有这个人的判断，系统会完美地跑在错误的方向上。

第四，这套架构的上限很高。等底层的语义层、特征平台和 Agent 编排都稳定了，后续新增能力会越来越快。今天接一个能耗预测，明天接一个设备寿命预测，本质上都是往 AI 能力层里加插件。但也要警惕，每加一个能力都要回归测试、都要设降级开关。制造业不需要炫技，它需要稳定地变好。