企业官网建设流程全解析

在半导体行业待久了，你会发现一个现象：不管外面怎么夸AI、大数据，真正常年泡在Fab（半导体晶圆厂）里的人，最依赖的其实是那套看起来不够“酷”的制造执行系统——MES。晶圆从拉单晶到封装前的几百道工序，每一片Lot（批次）在哪个设备、跑哪个Recipe（工艺配方）、要不要被Hold（冻结），全靠MES来调度和记录。这篇文章我想围绕Fab里的MES系统，把它的架构定位、核心模块、实施要点、常见坑，以及近期AI Agent可能带来的变化，都摊开讲一遍。如果你是刚进Fab做智能制造、IT或工艺系统的人，或者你想了解一套真正“长在产线上”的MES长什么样，这篇应该对你有用。

1. 半导体Fab为什么离不开MES——先搞清楚它解决什么问题

1.1 Fab制造的四个特殊之处，决定了系统有多复杂

我见过不少从电子组装厂转来做半导体MES的同事，一开始都特别不适应。同样叫MES，在组装厂管的是“工单做到第几道、做了多少个、良品多少”，在Fab里完全不是这个逻辑。Fab的制造执行系统之所以复杂，根本原因在于Fab本身有四个比较“极端”的特点。

先说第一点：工艺流程不是直线，而是反复回流。一片晶圆从衬底到成品，往往要经过几百道工序，而且不是从头到尾走一遍就行，像薄膜、光刻、刻蚀、去胶这一套组合，会反复出现几十次。这意味着MES里的工艺流程（Process Flow）是带循环的，每个节点的前后关系、返工分支、分批合并逻辑都非常复杂。

第二点，设备贵重、工艺窗口极窄。Fab里一台光刻机动辄几千万，工艺参数只要发生微小漂移，整批晶圆的良率就会崩掉。所以系统不能只在事后记录设备做了什么，更要在事前用配方校验和防错机制挡住错误动作，在事中用SPC和APC实时监控参数、及时止损。

第三点，在制品（WIP）的价值太高。一片12寸晶圆加工到中后段，价值就可能上万甚至更高，一个Lot就是几十片上百万的货值。Fab的MES必须做到单片级追溯，任何一次人为误操作、设备异常、物料混批，都必须能被系统快速识别并Hold住。

第四点，瓶颈设备的波动会像多米诺骨牌一样传导。Fab里的机台动不动就是几十上百台，瓶颈设备（比如光刻区）一旦出现计划外停机，整个厂的Cycle Time就会拉长，月底产出就不达标。所以MES里必须有一个强大的实时派工模块，不停地在每台设备、每个队列、每个Lot之间做调度权衡。

这四个特点叠加起来，决定了Fab的MES从来就不是一套“记录系统”，而是一套“指挥系统+防错系统+追溯系统”。这也是为什么业界会把Fab MES单独当成一个高门槛专项来看，和普通离散制造业MES完全是两个物种。

1.2 从四层架构看MES的位置，为什么不是ERP直接管产线

我经常被刚入行的同事问：我们厂不是有ERP吗，为什么还要单独搞一套MES？这个问题的答案，其实可以从工厂系统架构里看出来。在一个典型的Fab信息化架构里，从上到下大致分四层：

• 最上层是ERP，负责销售订单、物料采购、成本核算、财务等企业级资源计划，时间颗粒度通常是天或小时。
• 中间层是MES和APS，负责生产执行、详细排程、质量管控、追溯防错，时间颗粒度是分钟甚至秒级。
• 再往下是EAP、设备控制、SCADA这一类，负责和设备通信，下发配方、触发工艺、采集实时数据。
• 最底层才是实际的生产设备，比如光刻机、刻蚀机、炉管、清洗机、量测设备。

ERP的问题在于它离设备太远。打个比方，ERP更像公司的年度预算，告诉你这个月要生产多少货、采购多少料；而MES是现场指挥，它知道此刻光刻区第三号机的例行维护还有十五分钟结束，知道队列里有个急件已经等了两个小时，知道上一批产品的膜厚测量值偏高了3%，这些事ERP根本管不了。

MES在Fab里还要和几类系统联动，这是它区别于普通工厂系统的核心。比如RTD实时派工系统（有的厂把派工逻辑放在MES内部，有的单独成模块），决定每个Lot下一站去哪台设备；SPC统计过程控制系统，监控工艺参数是否稳定；APC先进过程控制，跑R2R（Run-to-Run）模型，根据上一批的测量结果自动调整下一批的工艺参数。这些模块虽然名称各异，但最终都长在MES的数据主线上，共享同一套Lot、设备、配方、工序主数据。

所以，如果你问Fab为什么离不开MES，最直接的回答是：没有MES的Fab，就像没有交通灯的城市主干道。设备能跑、产品能流，但很快就会乱成一锅粥，而且出了问题谁也说不清到底是哪一步出的错。

2. 核心能力拆解：一片晶圆在MES里的完整旅程

2.1 批次流转与RTD实时派工：决定下一站去哪

我想用一个具体的场景来拆解MES的核心功能。假设一片晶圆刚在薄膜区完成沉积，接下来要进入光刻工序。这时候MES在做什么？

当MES从生产计划中收到一个生产工单后，它会按规则创建Lot。这个动作看起来简单，背后的逻辑其实不少：按哪个产品编号、哪套工艺流、哪个批次数量、批号怎么编、是否支持分批合并，这些配置都在后台。创建完成后，Lot才正式进入MES的管辖范围，从第一个工艺步骤开始流转。

在每一站，操作员或自动化搬运系统（AMHS）需要对Lot做Track In，也就是报到。MES校验当前站点是否与工艺流程一致、设备是否有权限跑这个产品、配方匹配不匹配，校验通过后才允许开始生产。等设备完成加工，系统收到事件后把Lot移到下一步，这是Track Out。一个完整的站内循环就是Track In → Process → Track Out，而MES要保证这个循环在几百道工序中不串站、不跳站。

真正让Fab MES显得“聪明”的，是RTD实时派工。当一批晶圆完成上一道工序进入某区域队列时，它面临的可能不是唯一选择，而是三台设备都空闲，或者其中一台是当前瓶颈机台，另一台马上要停机保养。RTD会根据规则引擎来决策。我做过的派工规则大概分这样几类：急件优先、瓶颈设备优先、先进先出、机台匹配度优先、批次组合条件限制等。

举个例子，一批Hot Lot（急件）进入刻蚀区，它需要在这批特急产品的规定时间内完成加工，否则后面整个组装和测试计划都会delay。RTD规则可以给它很高的调度优先级，允许它插队到普通批次前面；但系统也会给普通批次设一个最长等待保护，防止“急件永远插队、普通Lot饿死”的极端情况。这些规则写起来不难，真正难的是在业务运营中持续调优，我后面再讲。

2.2 配方管理、EAP与防错：让设备只做该做的事

在Fab里，Recipe（工艺配方）是设备动作的参数组合，它是产品良率的命根子。MES本身不直接向设备下发所有配方内容，大多数情况下它通过EAP（设备自动化程序）来和设备通信，最底层的协议是半导体行业通用的SECS/GEM。

流程大致是这样的：MES确认某个Lot要在这台设备上加工后，向EAP发一个命令，比如“准备加工这个Lot”；EAP根据产品、工序、设备型号，从配方库中选出一份对应的配方版本，下载到设备控制器上，触发工艺启动，并在完成后把结果事件返回给MES。整个过程对操作员来说可能只需要扫一下条码、按一下启动，但背后MES和EAP的交互信息是很密的。

为什么MES在这个流程里要做那么多防错校验？因为Fab里最怕的就是“错把A产品用B配方跑了一遍”，这种错误一旦发生，一批晶圆可能直接报废，或者混入不良品流到下游。常见的防错点有三个：

• 设备与Lot绑定校验：系统确认这个Lot当前允许使用的设备群组中包含这台设备，没有权限的设备根本不允许Track In。
• 配方版本控制：工艺工程师变更Recipe时，旧版本必须走审批流程，MES端只允许当前生效版本被下载使用。很多厂都发生过“工程师改了配方但没提交评审，结果被误用”的教训。
• 载体与端口绑定：FOUP装到哪个Loadport、对应哪台设备，系统都要做校验，防止人工把FOUP放错机台。

这部分的核心理念是，MES不是靠人的自觉来保证正确，而是通过系统强制校验来兜底。工程师可能会觉得流程繁琐，但出过一次事故之后，所有人都会同意这套机制是对的。

2.3 数据采集、SPC与APC：MES不只是记账本

很多人以为MES就是个数据库，存一下哪个Lot在哪个工序就行了。但在Fab，MES和数据的紧密结合才是它的核心价值。

每一道工艺步骤完成后，设备会产生大量工艺数据：温度、压力、气体流量、RF功率、时间、厚度、线宽等。EAP采集这些数据后，一部分直接接入MES的质量模块，一部分进入SPC系统做统计分析。SPC会针对每个工艺参数建立控制图（比如X-bar R图），设定控制上限和控制下限。一旦某台设备的腔室温度连续几次超出控制线，SPC就触发异常报警，并让系统把相关Lot自动Hold住，等待工艺工程师排查。

我当初最早接触这个逻辑时觉得有点“过度反应”，后来被现实教育了：设备参数漂移如果不管，批量性良率损失会比想象中来得更快。Fab里良率就是命，MES的SPC功能实际上是在帮工艺工程师“提前踩刹车”。

再往上还有APC。以CMP（化学机械抛光）举例，一片晶圆经过抛光后要测量膜厚，如果测出来偏厚，下一批的抛光时间就应该适当延长。APC的R2R控制器读取上一批的测量结果，根据建好的模型计算出工艺偏移量，再把调整后的参数通过EAP下发给设备。这个闭环过程在MES的大框架里完成，体现了MES从“记录发生了什么”向“主动调节将发生什么”的演进。

数据采集这里还有个容易被忽略的问题：数据量很大。Fab的采集频率如果设置得太密，历史数据库很快就会被写爆；设置得太疏，追溯时又会发现缺关键点。这个平衡要在实施时认真设计，我后面会专门讲排坑。

2.4 WIP跟踪与追溯：出了问题，能查到骨子里

Fab的追溯要求比离散制造业严格得多。所谓Genealogy（谱系追溯），就是能回答“这颗芯片用到哪批光刻胶、在哪个刻蚀腔室加工、工艺参数是否超限、是谁在几点几分做的操作”这一类问题。

我举个例子：某批产品在客户端出了可靠性问题，质量部门要启动8D分析。追溯的起点可能是从最终失效芯片倒推到封装批次，再到晶圆批次，再到Fab内的具体Lot。此时MES里的Genealogy模块会把这个Lot对应的物料件批号、设备编号与腔室号、配方版本、关键工艺参数快照、操作员账号、Track In/Out时间全部串起来。如果中间有任何一块数据缺失，分析就会卡壳，严重时只能把整批产品作废处理。

这也是为什么Fab对MES的数据完整性要求极高。MES的追溯数据不是“有就行”，而是“不能有任何一环缺失”。一个常见的隐患是：设备和MES之间的通信断了几分钟，期间正好有批次完成加工但结果没上报。如果只是记录缺失还好，怕的是后续系统自动恢复后错误地把未确认完成的批次放行，导致追溯链断裂。

所以，Fab的MES在WIP跟踪上很少做“乐观放行”，更倾向于“状态不明就先Hold”，宁可让人来处理，也不能让数据带着洞流下去。这一条，我觉得是做Fab MES和做普通MES在思想层面最大的区别。

3. Fab MES实施与集成：手把手复盘一次项目

3.1 项目起步：主数据梳理比选型更该花时间

如果让我给一个刚启动MES项目的团队提建议，第一句话一定是：别急着选软件，先把主数据摸透。很多人觉得MES项目最难的是代码，实际上最难的是把工艺流程、设备、配方、物料这些主数据理清楚。主数据乱了，后面所有模块都会跟着错。

我在项目里一般按这个顺序摸底：

1. 先按产品系列梳理完整工艺流程。搞清楚每个步骤的先后关系、哪些步骤有循环、哪些设备群可以加工、有哪些返工分支。
2. 再梳理异常流。Fab里生产不是天天顺的，要弄清Hold的种类和触发条件、Rework怎么走、Split/Merge（分批/合并）的业务规则、Scrap的审批链路。这些异常流如果定义不清楚，系统上线后会天天被业务挑战。
3. 后做UI原型评审。让现场工艺、设备工程师、操作员都参与，不要只和IT讨论。操作员的反馈往往最直接：这个界面点几下能完成操作？放错了有没有提示？
4. 最后定义权限模型。角色、部门、数据范围、功能权限都要画清楚，尤其要处理好“谁能Release Hold”这类高风险权限。

这里我列一份比较常见的Fab MES主数据准备清单：

如果这些数据的责任人和审批流程没定义清楚，项目实施期间就会不断返工。我见过最折腾的情况是，工艺部门一直在改Recipe版本，MES还没上线，主数据已经改了三轮，最后只能冻结变更窗口。

3.2 设备对接硬仗：SECS/GEM联调是最磨人的环节

如果统计一下Fab MES项目的工时分布，设备对接通常能占到三成以上。MES的业务逻辑就算设计得再好，设备连不上，一切都是白搭。

设备对接主要是让MES通过EAP和设备做SECS/GEM通信。常见的报文类型包括：S1F1/S1F2用于询问设备是否在线、S2F41用于远程命令下发、S6F11用于事件报告上报、S7F5用于配方请求等。每种设备厂商的实现还会有不少私有逻辑，光看协议文档不够，必须逐台设备联调。

我总结的设备联调大体分三步走：

• 第一步，设备厂商提供SECS/GEM接口文档，IT方用模拟器（SECS Simulator）做报文级验证。这一步主要是把MES和EAP的逻辑调通，不碰真实设备，效率最高。
• 第二步，真机空跑。设备不带产品，只做机械动作和事件流验证，确认设备能收到远程命令、能正确上报完成事件、断线重连能恢复。
• 第三步，带产品试跑。在一个小范围产品上做全流程验证，同时让操作员在实际界面里操作，观察有没有异常。

联调阶段最常见的问题有这么几类：设备离线后MES没及时发现；事件上报乱序，比如Process End事件先于Start事件到达，导致MES状态机错乱；远程命令超时，EAP发了一个命令但设备没回应，系统卡在中间态；还有就是配方名不一致，MES里的配方编码和设备内部的Recipe名称对不上，导致下载失败。

这些问题没有捷径，只能在联调阶段一点一点磨。我的建议是，一定要把联调计划和每个设备的物料清单里都写清楚，验收标准要包含“断线重连测试”和“事件丢包测试”，否则上线后被动的就是自己。

3.3 ERP/MES集成：边界清楚，后面才能少扯皮

Fab MES不是孤岛，它一定要和ERP打交道。很多项目团队在ERP/MES集成上反复扯皮，根子在于边界没划清楚。

我通常这样划分：ERP管计划、资源、成本；MES管执行、质量、追溯。具体到集成点，常规有这几处：

• ERP下发生产工单（Work Order）到MES，MES据此生成Lot。
• 物料发料时，ERP发出物料批次信息，MES绑定到工单和Lot。
• 完工入库时，MES把完工信息回传给ERP，ERP做成本结转和库存更新。
• 不良品处理结果（报废、返工）和关键质量事件也要回传ERP，便于财务和计划端评估损失、调整计划。

技术实现上，我强烈建议不要直接在两个系统之间互相改库。更稳妥的做法是中间库加消息队列（MQ）的异步集成方式。原因很简单：ERP和MES的数据模型、事务机制完全不一样，直接连库看似快，实际上一方发布变更就可能把另一方搞挂。用MQ的好处是解耦，ERP发一条消息，MES消费后更新自己的状态，两边各自保证本地事务一致，最后通过对账单和定时对账来查漏补缺。

这里还要特别强调主数据同步的归属问题。物料编码、BOM、工艺路线这些数据到底以谁为准？我的经验是，ERP是物料和BOM的法定主数据源，MES是工艺流程和设备配置的法定主数据源。两边同步不是单向的，而是各管各的领域，通过接口把对方需要的部分推送过去。如果两边都维护同一份数据，早晚会出现“ERP改了物料描述，MES还显示旧名称”的尴尬。

3.4 实施过程中踩过的坑，写出来给你避雷

这部分我想写几个自己踩过的坑，给做同类项目的人提个醒。

第一个坑：把“灵活”理解为无限自由。需求阶段，工艺工程师总希望界面上什么都能改，结果UI做得极其复杂，操作员根本不愿用，最后绕过系统手工记录。正确的做法是把“必要场景”的灵活性做出来，比如允许指定条件下修改批号备注，但关键字段（产品、工艺流、设备群）必须锁定，改任何一项都要走审批和留痕。

第二个坑：报表需求想在最后再补。很多团队前期只顾着配置核心流程，报表拖到UAT阶段才讨论。结果就是业务一脸懵：“怎么连我们最常用的产量班报都没有？”要避免这个，就需要在项目初始就建立报表清单，和工艺、生产控制、质量部门一起按站点优先级定义报表口径和展示字段，UAT时一起验收。

第三个坑：配方版本变更流程缺失。上线后工艺部门发现某产品的刻蚀均匀性不好，直接改配方并在设备上测试，MES里根本没记录版本变化。过几天另一个批次要用这个配方，发现版本对不上，系统大面积Hold。后来我们补了一道流程：配方变更必须先在MES里申请新版本，经过评审后才能下载到设备，任何直接改设备配方库的动作都会被审计。

第四个坑：网络抖动导致全线停摆。MES一旦抽风，产线就要停，损失是按分钟算的。我们后来在EAP层加了本地缓存和断线自动重连，MES服务端对关键操作做了异步处理和事务补偿。这样网络短时抖动时，设备端还能继续处理到一半的作业，不会因为一次网络超时就把整批Lot卡死。

这四个坑不算多，但每一条都能让项目经理少白几根头发。说到底，Fab MES实施考验的不是编码能力，而是对业务复杂度的敬畏程度。

4. 开源MES、AI Agent与工厂的未来：别盲目追新也别当鸵鸟

4.1 开源MES能不能“下载即用”？我的看法

网上经常看到“github mes系统下载”这类搜索词，说明还是有不少人想找现成的MES系统。我的态度是：可以参考，但别幻想Fab里能拿来即用。

GitHub上确实有一些开源的MES项目，有些还做得比较完整，涵盖工单管理、工艺路线、质量管理这些模块。但坦白讲，它们绝大多数面向的是离散制造或简单流程行业，真正的半导体Fab场景几乎是空白。原因是Fab MES的核心价值在于那些高度行业化的能力：实时派工、多腔室设备管理、SECS/GEM协议对接、R2R自动控制、复杂的谱系追溯。这些不是一个通用开源系统能轻易覆盖的。

还有一个更现实的问题：安全与合规。Fab里的工艺数据、设备参数、良率信息都是核心资产，用没有经过安全审计和商业支持的开源系统承载，风险非常大。我见过一些厂把开源系统用在非核心场景，比如维修工单、培训管理、简单报表展示，这是可行的；但生产主流程，基本都会买商用产品或找专业实施团队基于开源框架深度定制。

所以，如果你在GitHub上看到MES项目，我建议把它当学习素材，研究它的数据模型、流程引擎、事件处理方式，不要直接在生产环境部署。真要在PoC里用，也要先把数据权限、备份恢复、审计日志这些基础能力验证清楚。

4.2 LangGraph这类Agent框架接进MES，能做什么

最近“AI Agent + 工厂”的讨论很热，LangGraph这类编排框架也被反复提起。我自己也做过一些小范围的探索，说实话，方向是对的，但落地难度比PPT上大得多。

先说说我觉得真正有实际价值的场景。

一个是自然语言查询。MES系统里数据很多，但业务人员不会写SQL，每次想查个WIP分布都要找IT团队。如果做一个Agent，让操作员或工程师直接问“早上8点以来光刻区哪台设备Recipe异常最多”，Agent自动解析语义、生成查询、调用MES接口返回结果，这能省下大量沟通成本。前提是MES的数据字典要整理得很好，Agent才知道“光刻区”对应哪个设备群、“Recipe异常”对应哪个字段。

另一个是异常辅助诊断。系统发现某个Lot被Hold，Agent自动拉取设备日志、SPC数据、历史相似案例，生成一份排查建议给工程师。工程师可以基于建议快速定位，而不是自己翻几套系统去找线索。这个场景我比较看好，因为它不是让Agent直接做决策，而是把人从信息检索中解放出来。

再一个是派工策略的动态调整。RTD规则通常由生产控制部门定期调优，但如果Agent能实时观察WIP分布、瓶颈设备状态、交期要求，提出规则修改建议，会很有用。注意，这里我强调的是“建议”而不是“自动执行”，因为AI一旦在排产上给出错误决策，损失是实实在在的。

现实难度也要说清楚。首先，数据权限问题，不能让Agent随口就能拿到全厂数据，权限要细化到字段级，而且所有Agent访问都要有审计日志。其次，幻觉问题，在制造现场给错结论比不给结论更危险，所以必须设计成人机协同模式，Agent只提供分析，最终动作由人来执行。第三，主数据质量，如果MES里的工艺流程都写得乱七八糟，Agent学到的自然也是错的，这一点绕不过去。第四，接口问题，很多商用MES的API开放程度有限，Agent要接入必须先做一个适配层，这本身也是一笔不小的开发投入。

我的判断是，未来两三年里，AI Agent在Fab里的角色会更多是“助手”和“顾问”，而不是“主控”。它不是替代MES，而是把MES里积累的大量数据用起来，让它转化为能指导人行动的知识。

5. 常见故障与排查技巧实录

5.1 Lot被Hold后放行不了，先按这个顺序查

这是在Fab现场最常遇到的问题之一。操作员扫码准备Track In，结果MES提示这个Lot处于Hold状态，没法继续。

不要急着去数据库里硬更状态，按这个顺序排查：

1. 先查Hold Code和Hold Owner。MES里每个Hold记录都有关联的代码，是SPC触发的，还是物料检验拦截的，还是人工Hold的？责任人是谁？
2. 查Hold触发时间点前后的系统日志。如果刚好在某个时间点有MES事件丢包，有可能是系统之间的Hold消息没传到位。
3. 查这个Lot是否经过了需要审批的返工或分批操作。很多时候是前一步的Return/Release流程没有走完。

处理时特别要注意：不要让普通操作员随意Release。Release是一条高权限操作，必须要看Hold原因、确认风险、填写处理说明。我在实际项目中遇到过一线主管为了赶产量，批量Release了SPC触发的Hold，结果后面查出来整批产品确实有问题，只能作废重新生产，损失惨重。

5.2 追溯数据断链，设备数据丢点怎么办

追溯数据断链，在Fab里是必须严肃对待的问题。现象往往是：质量部门做追溯时发现，某个腔室的压力数据在某一段时间是空的，或者某个批次的状态记录断层。

这种问题最常见的根因有三个：

• 设备事件上报丢失。SECS/GEM的事务通道不稳定，Process End事件没有及时上报，EAP也没有做补发。
• 数据采集频率太高，历史库被写爆，系统自动丢弃了部分数据点。
• EAP异常恢复时，补偿逻辑没做对，导致正在加工中的批次没有回补完整的事件链。

排查思路是先看EAP的日志，确认设备是否真的上报了事件；再看MES收到的报文时间戳，判断是否存在乱序；最后核对数据采集配置表，看看采集频率和存储策略是否合理。

修复的核心不是把缺失数据手工补上（很多数据已经永远丢了），而是调整机制防止再发生。比如给关键事件加确认和重发机制，给EAP增加断线期间的本地缓存，对数据采集频率做合理性评估。Fab的追溯体系如果没有这些保障，相当于在沙滩上盖楼，平时看不出问题，一出事就是大事。

5.3 交班高峰期MES卡成狗，性能排查三板斧

很多Fab的MES在交班时段会明显变慢，因为所有人都在这个时间点集中扫码、录入、查询、打印报表。系统一卡，产线就排队，然后大家更急躁，操作更快，系统更卡，形成恶性循环。

我处理这类问题通常按三板斧来：

第一板斧，查数据库慢SQL。很多性能问题的根子是一条SQL走了全表扫描，比如wip_transaction表没有按时间建索引。把那些耗时超过几百毫秒的SQL抓出来，逐条优化，加索引、改分页、去掉不必要的关联查询。

第二板斧，把报表查询和操作型业务分离。MES的核心数据库应该专注服务实时交易，也就是Track In/Out、Hold/Release、事件接收。报表这种大查询，应该从数仓或者只读副本里出，别让它和实时业务抢资源。很多厂的做法是MES交易库和报表库做CDC同步，报表直接查同步库。

第三板斧，给高频接口做限流和缓存。比如操作员扫码后要查的BOM、配方、设备状态这些只读数据，可以在缓存里放一份，不必每次都打到数据库。对重复提交类的请求，要做幂等处理，防止网络重试导致数据库压力翻倍。

性能问题没有银弹，关键是提前做容量评估、定期做慢查询巡检，并建立监控告警。等到所有人一起喊“卡”的时候再处理，压力就大了。

5.4 账号权限混乱，审计不过的根子在这

Fab的MES权限治理，是我见过最容易在外审（如客户稽核）时被开缺失项的点。问题通常集中在：离职人员账号没有及时禁用、多个操作员共用同一个账号、关键操作没有留痕到具体个人。

这些问题的根子在于，Fab现场为了操作方便，默认把扫码枪放在工位上，谁来了都能扫。但追溯要求必须精确到个人，否则出问题时无法定位到责任人。

比较有效的治理办法是三层：

• 账号统一接入企业身份源（比如AD/LDAP/SSO），MES不单独维护密码，员工离职或转岗时统一禁用。
• 关键操作（Recipe下载、Hold Release、报废审批、异常参数修改）强制二次认证，比如扫码加刷工牌，或者扫码加动态口令。
• 建立季度权限复核制度，由MES管理员和部门主管一起过一遍账号清单，确认谁还在岗、谁的权限是不是给多了。

权限这块做好了，不仅能通过审计，还能有效减少误操作。很多看似是“人为错误”的事故，本质上都是权限管理太松导致的。

最后再分享一点我这些年做Fab MES的心得：别再迷信“技术多先进”，更别小看“流程多繁琐”。MES说到底是在把生产现场的规则、责任、数据固化成一个可追溯的系统。真正做好这件事，靠的不是炫技，而是愿意蹲在产线旁边，跟操作员聊半小时、跟设备工程师看一次复机、跟工艺人员吃一顿饭的耐心。前期多花一点时间理解业务，后面系统上线后就会少挨很多骂。经验就是这么来的，没有捷径。