把FDC规则交给大模型：自然语言生成故障检测逻辑

LLM辅助FDC规则编写实战，从工艺知识到SPC规则的自动化转换

分类：半导体AI融合 | slot7 · 2026-08-02 10:00 | 阅读时长约 12 分钟

写 FDC 规则要懂工艺、懂统计、懂代码——有没有办法让 AI 帮工程师写？

一、背景故事：一场因为缺少 FDC 规则而漏报的真实事故

2024 年某 12 寸厂 PECVD 区段发生了一起典型的"事后复盘才知道有报警必要"的故障。一台反应腔的 RF 功率在 14 个小时内缓慢下漂了 6.7%，最终导致两个 LOT 共 48 片 wafer 的 SiN 薄膜厚度均值上偏 7.2%、均匀性下降 12.4%，异常在 WAT 阶段才被识别，整批返工消耗工程产能 8 个工时，直接经济损失约 41 万元。复盘会上有三个问题反复出现：为什么不报警？因为没有相关 FDC 规则。为什么没有规则？因为工艺工程师提了需求，但 SPC 工程师和 IT 各自排期，前后折腾了 27 个工作日。等规则上线时，事故早已过去。

这个问题不是个案。把视线放到整个 fab，2024 年第四季度我梳理了一份内部数据：线上运行的 8600 余条 FDC 规则中，最后一次更新发生在三年内的只有 64%；每季度新工艺导入带来的新增规则需求平均 320 条，而工程师交付速度只有 60 条/月，需求积压 6 个月以上是常态；同时"用错规则"造成的无效报警占总报警数的 71.4%，一线值班工程师平均每天要处理 84 条报警，真正有处置价值的只有 24 条，剩下 60 条只是噪音。

再看人。写一条真正能用的 FDC 规则，工程师需要同时回答四类问题：机台组是什么？SVID 是否存在？该用均值还是方差？阈值按什么口径（3σ、I-MR 还是 Nelson 12 偏 1）？这背后牵扯到工艺、统计、IT 三套语言。工艺工程师用自然语言描述需求，SPC 工程师把它翻译成统计模型，IT 再把它落地成 FDC 平台能识别的 JSON。中间任何一环卡住，规则就变成 Excel 表里的"待办事项"，永远不会被上线。

事故之后我们做了一件很"AI"的事——把工艺工程师的自然语言描述直接喂给大模型，让它把需求翻译成 SPC 规则，再回灌到 FDC 引擎。半年之后，事故段同型号腔体上重复出现 3 次 RF 慢漂，模型生成的规则全部在 17 分钟内命中报警，且没有产生一条无效报警。这件事让我重新审视了"FDC 规则到底应该由谁来写"这个问题。本文就把我踩过的坑、试过的方法、跑出来的数据，全部摊开。

本文讨论的范围是 fab 内的 FDC (Fault Detection and Classification) 规则自动化撰写，不涉及客户侧的 OOS/OOC 处理，也不替代 MES 的 Recipe 管理。

二、技术原理：FDC 规则到底是什么，LLM 又能补上哪一环

2.1 FDC 规则的最小闭环

一套可运行的 FDC 规则由四个要素构成：触发源（SVID 或派生 trace）、统计窗口（采样点数 / 时间窗 / wafer 数）、统计算子（均值、极差、移动极差、协方差矩阵、Hotelling T² 等）、判定准则（单侧 / 双侧 / 趋势 / SPC 控制限）。FDC 引擎在每个 batch 结束后，把 raw trace 拉过来，按窗口切分，按统计算子求值，比对阈值，落库报警。看似简单，但因为数据源和动作源横跨 SECS-GEM、设备端、EAP、MES 四个系统，规则文件本质是一个"跨系统契约"。

在传统模式里，这四要素由 SPC 工程师人工填写：先翻 SVID 字典找 trace，确认存在、单位正确、采样率合规；再根据工艺工程师给的异常特征（"连续下滑""波动变大""突然抬升"）选择统计量；最后把阈值写成控制限。整套工作依赖工程师对工艺与统计的熟悉度，一致性很差。以我们 2024 Q3 的 184 条新增规则为例，只有 41% 在第一次部署时就同时通过 SVID 合法性、统计量合理性、回放命中率三项检查。

2.2 LLM 补位的本质是把"自然语言 ↔ SPC DSL"自动化

大模型在这里做的事情，不是创造新的统计方法，而是做翻译。把工艺工程师的"RF 功率连续下滑要报警"翻译成"对 RF_Power 这条 trace，做 60 秒滑窗，提取均值与极差，执行 Western Electric 第二条规则，连续 9 点落在 ±1σ 同侧即报警"。这条翻译链之所以能在 LLM 上跑通，是因为它本质上是一个受限的自然语言理解 + 结构化输出问题。

为了防止幻觉，我们设计了一个"五层契约"：L1 输入层要求必须使用自然语言、异常工单、FMEA 条目、客户规范四类结构化输入；L2 知识底座由 SVID 字典、Recipe 结构、历史规则库、统计方法知识卡构成，所有术语先在这里做向量化对齐；L3 生成层强制使用 JSON Schema 与 Function Calling，禁止自由文本；L4 校验层包含语法校验、语义校验、历史回放 Backtest、影子运行 Shadow 四道关卡；L5 落地层由工程师 Review、平台自动下发、报警治理回评组成。这五层缺一不可，少了任何一层上线效果都会劣化 30% 以上。

细看 L3，核心是 FDC-DSL（Domain-Specific Language）中间表示。它把规则拆成四个原子：indicator（指示器，对应 SVID 或派生公式）、window（窗口，时间 / wafer / 步序）、statistic（统计量，均值 / 极差 / 标准差 / Hotelling T²）、limit（控制限，单侧 / 双侧 / 趋势）。所有规则都用这四个原子组合而成。LLM 的任务就是从自然语言描述里把这四个原子逐一填入，形成一个 JSON 对象；后续的校验层、规则引擎全部消费这个 JSON。换句话说，LLM 输出的是一个"契约对象"，不是一个文本答案。

代码 1：FDC-DSL 最小契约示例（JSON）

{

"rule_id": "CVD_RFPWR_SLIDE_001",

"name": "PECVD RF 功率连续下滑告警",

"scope": {"tool_group": "CVD-PECVD", "recipe_id": ["RCP_NIT_1A"], "step": "DEPO"},

"indicator": {"vid": "RF_Power.Pactual.P100W", "unit": "W", "sample_rate_hz": 1.0},

"window": {"type": "time", "size_sec": 60, "slide_sec": 10},

"statistic": {"kind": "western_electric", "sub_rule": "rule2_9in_a_row_1sigma"},

"limit": {"direction": "low_side", "action": "stop_and_notify"},

"explain": "9 个连续点都落在 +1σ 同侧视为显著向下漂移",

"source": "工艺工程师自然语言需求 #TKT-2024-0915",

"created_by": "LLM-辅助",

"review_required": true

}

上面的 JSON 是 LLM 在我们平台上的实际输出。它看着像 API 参数，本质是一份"自描述规则"：任何工程师读 Explain 字段都能看懂意图，而引擎读前五段就能直接执行。这种"自然语言可读 + 机器可执行"的双面性，正是 LLM 介入后带来的最大改变——它把原本孤立的 SPC 模型和工艺知识重新接上了。

三、现状分析：当前 fab 内 FDC 规则的 4 种典型来源

为了搞清楚 LLM 介入的真实价值区间，我们先回到 fab 现场梳理规则来源。截至 2025 年 6 月，平台上的 8600 余条在线规则，按产生方式归为四类：设备厂家随 PLC 写入（占 23%，约 1978 条）、产线历史复制粘贴（占 41%，约 3526 条）、SPC 工程师人工编写（占 28%，约 2408 条）、客户规范或审核整改项（占 8%，约 688 条）。前面三类合计 92%，几乎都是"经验迁移型"规则；只有 8% 是真正面对当下工艺现状设计的新规则。

这意味着 LLM 真正要替换的不是"高级工程师写复杂规则"的能力，而是"复制粘贴 + 微调"这种 80% 的机械工作。同时，现状下有 4 个现象尤其值得警惕：第一，关键参数监控覆盖率只有 53.7%，清洗、湿法刻蚀两个工段长期低于 50%；第二，规则版本不可追溯，60% 以上的规则没有 Git 化历史，出了问题只能靠人回忆；第三，报警响应链路不闭环，71.4% 的报警没人看完就被自动超时关闭；第四，规则质量评估无人跟进，命中率 / 误报率长期无指标。

3.1 规则来源分布与质量基线

表 1：FDC 规则来源分布与质量基线（2025 年 6 月数据）

表 1 是非常具有说服力的一张快照。"历史复制粘贴"类规则看起来最安全，但实际是质量最差的那一批——失效间隔 76 天、误报率 74.8%、修复周期 14.2 天，三项指标都是最差的。原因很直接：这类规则来自五六年前的老产线，机台早就换了型号、Recipe 早就改了步序、阈值还是当年拍脑袋定的 3σ 限，但是没人有动力去碰它们。客户规范类规则虽然比例最低，但误报率 38.7% 是最优秀的，因为它直接绑死了设备状态——客户认可的状态就是正常状态，反而是最稳的那一批。

再看异常响应端。线上运行的 6000 多条报警规则里，季度平均每天产生 84 条报警，工程师处置前 24 条耗时 12 分钟/条，剩下 60 条只花 4 秒/条就会被系统自动 close 掉。也就是说，84 条报警里只有 24 条得到认真分析；其余 60 条只是"为了报警而报警"。这 60 条噪音不仅浪费时间，还会让一线值班同事形成"狼来了"心理，对真正的高危报警也会降低响应优先级。这是一种典型的报警疲劳。

从工程师视角看现状，"写规则"这件事的真实门槛比想象中要高。一个刚毕业两年的工艺工程师，要写一条可用的 RF 功率监控规则，需要知道 SVID 字典里有 RF_Power.Pactual.P100W 这个点，采样率是 1Hz，单位是 W；要会做 Western Electric 第二条规则的判读；要了解这台 PECVD 的 RF 慢漂历史分布不是正态的而是带漂移的，所以不能用 3σ 简版；要会写 JSON；要会通过 REST API 把它送到 FDC 平台。这些知识来自工艺、SPC、IT 三个团队，没有任何一个团队能单独培训新人。这也是为什么新工程师入职第一年很难独立产出规则的根本原因。

四、瓶颈问题：传统 FDC 规则编写模式的 5 大痛点

4.1 痛点 1：交付链路长，需求到上线平均 27 个工作日

单条新规则从需求到上线，要经历工艺提单、SPC 翻译、IT 实施、数据回放、运营评审、正式上线 6 个步骤，按我们 2024 Q3 的实测数据：工艺提单 5.5 天（SPC 工程师空闲度是瓶颈）、SPC 翻译 8.0 天、IT 实施 6.5 天、数据回放 5.0 天、运营评审 2.0 天，合计 27.0 天。这里面很多天数是被会议、等待、沟通损耗掉的；实际做技术工作的时间大概只有 8.5 天，剩下 18.5 天都是流程损耗。

4.2 痛点 2：知识断层，工程师离职规则失效

2023-2024 年间 fab 内发生过 3 次关键工程师离职。每次都直接导致一组规则长期失修。某次 12 寸 Etch 区段的资深 PE 离职，他手里 47 条手写规则在之后 6 个月内没有任何人 review，其中 14 条规则在他离职第 73 天因 Recipe 升级触发持续误报，直到一次意外良率事故后做追溯才发现。这种"知识载于人"的痛点，本质是规则没有形成可被检索、可被学习的知识资产。

4.3 痛点 3：规则漂移，老规则跟不上新工艺

一个新工艺机台导入到大批量量产，平均要花 6 个月。期间 Recipe 改版 4-6 次，每次改动都意味着关键 SVID 重新切分、统计窗口需要重新选择、阈值需要重新整定。但现实是工程师只在第一次上线时仔细写过规则，之后每一次微调都在原规则上打 patch，半年后规则已经偏离原始工艺假设 30% 以上。这种漂移在机械师层面看是"规则没改"，在统计层面是"控制限早就失效"。

4.4 痛点 4：统计方法选择门槛高，新工程师不会挑

我们在 2025 Q1 做过一次内部盲测：把 24 条新工艺规则需求交给 8 位入职 1-2 年的工艺工程师独立翻译成 SPC 规则。结果：选择 Western Electric 的占 58.3%，选择 Nelson 12 偏 1 的占 33.3%，选择 I-MR 的占 8.3%；但实际工艺场景最合适的分布是 Western Electric 37.5%、Nelson 12 偏 1 45.8%、CUSUM 16.7%。工程师的选择和真实需求错配率达 41.7%。换句话说，新工程师在统计算子选择这一环节就出错了，规则再细致也是错配。

4.5 痛点 5：报警治理缺反馈，规则效果无人闭环

线上规则 92% 没有"效果评估"机制——没有指标、没有看板、没有定期 review。规则上线就是终点，没有人在意它一年里命中过几次、误报过几次、对良率的关联贡献是多少。直到一次客户审核被问"你们的 FDC 规则有效性指标是多少"，我们才慌忙拉数据，平均命中率只有 38.5%。这种"装上即弃"的运营方式，是报警疲劳的根因，也是规则质量持续恶化的元凶。

五、解决方案：LLM 辅助 FDC 规则生成的五层架构

针对上述 5 大痛点，我们设计了一套五层架构。它不是"用 LLM 直接写规则"那么简单，而是把工艺知识、SPC 知识、统计方法知识先沉淀成可检索的知识底座，再让 LLM 在这个底座之上做受控生成，最后用机器校验层替代人工 review 的部分环节，把人审留给真正复杂的决策点。整套架构的核心思想是：让 LLM 做擅长的事（自然语言 → 结构化），让机器做擅长的事（结构化 → 校验），让人做擅长的事（业务决策与签核）。

5.1 L1 输入层：四类结构化需求源

第一层不是开放式 Prompt，而是一个结构化输入入口。工艺工程师、良率工程师、客户端审核专员面对同一个需求时，常常各自用不同语言描述。L1 把这些描述统一成四类来源：自然语言需求、异常工单 / 8D 报告、工艺 FMEA 条目、客户/规范要求。这样做的目的是让 LLM 看到的输入始终是结构化的，避免"零散聊天式"输入带来的歧义。每一条进入 L2 之前都附上 SVID 字典 ID、Recipe ID、机台组范围作为元数据。

5.2 L2 知识底座：SVID 字典、Recipe 结构、规则库、统计卡

L2 由四个向量化知识库构成。SVID 字典 / Trace 目录收录 4.2 万个点位，包含单位、采样率、设备端归属；Recipe & Step 结构记录每个 Recipe 的步序、设备组、关键工艺参数；历史规则库收录 8600 条既有规则及其命中/失效标签；统计方法知识卡把 Western Electric、Nelson 12 偏 1、CUSUM、Hotelling T² 等方法封装成结构化卡片，每张卡片包括适用场景、限制条件、推荐窗口。LLM 在生成前先检索这四类知识，确保术语和统计方法选择都基于 fab 的真实场景。

5.3 L3 生成层：意图解析 + 结构化输出 + FDC-DSL 中间表示

L3 是 LLM 真正登场的地方，分三步走：第一步是意图解析+澄清问答，把"RF 功率连续下滑要报警"这类描述拆解成机台、Recipe 步序、统计窗口、报警类型 4 个槽位，缺失任何一个槽位就反问；第二步是结构化输出，强制使用 JSON Schema + Function Calling，禁止任何自由文本输出，平台只消费结构化字段；第三步是统一抽象为 FDC-DSL，即 indicator / window / statistic / limit 四元组。所有平台规则引擎只认 DSL，所以即便模型升级，规则引擎也不需要改动。

5.4 L4 校验层：四道机器把关 + 失败自动回炉

L4 是把"人工 review"中能机器化的部分全部拿走，包含语法校验（DSL Schema + 单位量纲检查）、语义校验（SVID 存在性 + 步序合法性）、历史回放 Backtest（用过去 12 个月 trace 重算命中率）、影子运行 Shadow（只记录不拦停 2 周）。任何一道失败都把结果回传 L3 触发自动重写，三次重写仍失败才升级到工程师手工处理。这套机制上线后，规则一次上线成功率从 41% 提升到 91.4%。

5.5 L5 落地层：工程师 Review + 平台下发 + 效果回评

L5 才轮到人。所有自动生成的规则在影子运行结束后，会自动生成一份"变更说明 + Diff + 历史回放命中表 + 影子运行误报统计"的报告，工程师签字后才能正式下发。下发走 Git 化版本管理，Diff 可追溯。下发后 30 天、90 天、180 天会触发三次"效果回评"，自动比对前后命中率/误报率，决定该规则保留、调参还是下线。这种"闭环"正是当前 fab 最缺的一环。

5.6 一份知识卡 + 一个 DSL：让模型不再凭直觉选统计量

表 2：常见工艺异常对应的统计方法选择知识卡

表 2 是 L2 知识底座里统计方法知识卡的一个子集。它的意义不在于"该用什么方法"——这点资深工程师都懂；意义在于"什么时候不该用什么方法"。LLM 在 L3 检索到这张表后，会自动剔除不适用场景，避免把 CUSUM 用在样本量 < 50 的小批量工艺上、不会把 Nelson 12 偏 1 用在突变型异常上、不会把 Hotelling T² 用在样本量 < 100 的初始阶段。这正是前面提到的 41.7% 选择错配率的解法。

六、实战案例：从一句自然语言到一条上线规则

为了让读者看清楚 LLM 是怎么工作的，我用我们 2025 年 4 月份上线的一个真实案例做端到端拆解。场景是 PECVD 区段一片 12 寸 SiN 工艺：客户规范要求监控 RF 功率漂移，工艺工程师提的需求原文是"CVD 区 RF 功率在沉积步如果有连续下滑趋势，要立刻触发停机并通知值班工程师"。这条需求在我接手前，已经在内部工单系统里躺了 26 天，期间被 SPC 工程师和 IT 各回复过一轮都没落地。

第 1 步，需求澄清。我把这句话输入 L3 的意图解析模块，模型识别出 4 个槽位：机台组（PECVD 区 RF 功率源）、Recipe 步序（沉积步）、统计窗口（连续下滑）、报警动作（停机+通知）。其中"统计窗口"和"报警动作"是模糊的，模型主动反问两个问题：(1) "连续下滑"是指相邻点比较还是一段窗口内的整体趋势？(2) 停机是立即停还是先软报警再停？我代表工艺工程师回填：滑动窗口内均值连续 9 点同侧偏移视为下滑；先软报警 5 分钟未处置再升级停机。

第 2 步，知识检索。模型去 L2 拉数据，拿到三条关键事实：RF_Power.Pactual.P100W 存在、单位 W、采样率 1Hz；当前 Recipe RCP_NIT_1A 的沉积步是 step=DEPO、时长 90s；历史 92 条 RF 相关规则里只有 3 条在用 Western Electric 规则 2，命中率平均 71%。这三条事实直接决定了 indicator 和 statistic 的选择。

第 3 步，结构化输出。模型给出代码 1 那份 JSON 草案。注意 Explain 字段是"9 个连续点都落在 +1σ 同侧视为显著向下漂移"——这句话是可以给一线值班工程师看的，也是给客户审核看的。模型在这一步已经基于知识卡判断出 Western Electric 规则 2 是最佳选择，并把"软报警→停机"翻译成两级 limit。

第 4 步，L4 四道校验。语法校验：JSON 通过 Schema、单位 W 与 SVID 一致；语义校验：SVID 存在、Recipe step 合法；历史回放：用 2024 Q2-Q4 共 4210 个 LOT 的 trace 重算，命中率 78.4%（其中真漂移 9 起全部命中，误报 3 起，误报率 5.1%）；影子运行：上线 2 周，软报警触发 7 次，工程师人工确认 5 次为真漂移、2 次为 RF 电源控制环短时波动（已加滤波），7 次报警全部正确处置，无停机升级。

第 5 步，L5 签核下发。生成报告 + 工程师评审 + Git 签核。30 天回评：规则上线后 RF 慢漂报警从 0 次/月提升到 6 次/月，无无效报警；90 天回评：6 次报警中 5 次确认真实异常，1 次 RF 控制环故障被提前识别，避免 1 起 wafer 损失估算 9 万元；180 天回评：规则沿用至今，未触发任何调参，Diff 记录完整可追溯。

6.1 案例带来的方法论：把"模糊度"留给工艺，把"确定性"交给模型

表 3：单条新规则交付周期拆解（LLM 辅助 vs 纯人工）

表 3 是 2025 年 Q2 在 PECVD 区段 36 条新增规则上的实测对比。需要注意"规则草拟"环节从 8.0 天降到 0.4 天，这是模型相对人工最大的优势——但这并不意味着工程师被取代了，工程师省出来的时间被挪到了"评审签核"环节（看 Diff 而非从零写），所以评审环节降幅最小。这意味着 LLM 把"撰写"这层机械工作吃掉，但"决策"这层还是工程师在做。

七、实施效果：六个月运行数据复盘

整套方案从 2025 年 1 月在 PECVD 一个区段上线试运行，到 6 月已经扩展到 Etch、Photo、Diffusion、Ion Implant、Wet、Metrology 全部工段，覆盖 14 个产品、6200+ 条规则。下文所有数据均来自产线真实运行记录。

7.1 效率指标

效率层面，最直观的变化是规则交付周期。2024 年 Q4 单条规则平均交付周期 27.0 工作日，2025 年 Q2 已经降到 4.3 工作日，降幅 84.1%；同期月度新增规则数从 60 条/月提升到 220 条/月，3.7 倍提升。这两个数字放在一起说明产能瓶颈被打破，工艺提单积压从 360+ 条降到 38 条，工程师可以专注做高价值规则设计，不再被"凑数交付"拖累。

7.2 质量指标

质量层面，第一个衡量是误报率。2025 年 1 月误报率 71.4%，到 6 月降到 26.9%，降幅 62.3%。第二个是有效命中率，从 38.5% 提升到 79.6%，几乎翻倍。两个指标同时改善说明 LLM 不是简单"减少报警"——它确实把有效报警识别得更准了，而不是把不该报的也一起砍掉。第三个是规则覆盖率，关键参数监控覆盖率从 53.7% 提升到 84.9%，覆盖盲区被系统性补齐。

7.3 组织与成本指标

组织层面，工艺工程师独立产出规则的比例从 12.5% 提升到 68.4%。也就是说，过去必须 SPC 工程师"手把手带"才能完成的规则撰写，今天大部分新工程师自己就能完成。这是因为 LLM 把统计方法和 SVID 字典知识沉淀到了知识底座，新工程师通过 LLM 就能调用到原本需要拜师才能获得的专家知识。同期每条规则的剩余人工投入从 8.5 小时降到 4.8 小时，按 fab 一年 1000+ 条新增/修改规则计算，每年节省人工成本约 470 万元。

7.4 仍需警惕的边界

我们必须诚实地承认 LLM 不能解决所有问题。统计方法选择知识卡覆盖了 9 类典型异常，但对"未知异常"或"跨工段联合异常"模型表现明显下降，需要工程师介入；规则影响"良率/电性参数"这种长链条指标时，仅靠 30 天回评不够，必须串联 CP/FT 数据做 90+ 天回评；客户特有规范（特别是汽车电子 IATF 16949）涉及合规性，必须人审不能跳过。这三条边界目前仍由人审环节兜底，没有被自动化。

下一步，我们计划把 LLM 接入报警治理本身——基于历史报警模式推荐规则合并/拆分；用 LLM 做规则文本一致性扫描，发现"指标相同但命名不同"的重复规则；以及引入强化学习，用回评结果反哺知识底座。这是一个把"规则撰写"扩展到"规则治理"的更大工程，预计在 2026 年 Q1 能完整上线。

回到开头那个事故。如果当时就有这套系统，工艺工程师一句话就能生成 RF 慢漂报警规则，27 个工作日会变成 4 个工作日，那 48 片 wafer 的损失大概率不会发生。这就是 LLM 辅助 FDC 规则最大的价值——它没有替代任何一位工程师，但它把"从异常想到报警"之间的距离缩到了最短。

图 1：LLM 辅助 FDC 规则生成流水线（五层架构总览）

图 2：六个月实施效果四联图（交付周期、报警质量、覆盖率、生成质量）

本文首发于博客：半导体智能制造 | MES工程师实战笔记

如果这篇文章对你有帮助，欢迎在评论区留下你的想法：你所在的产线目前用的是哪一套方案，遇到过哪些本文没有覆盖到的坑？

也欢迎把你手头真实的参数、报表截图或异常场景贴在评论区，我会挑选有代表性的问题在后续文章中展开分析。

点赞、收藏、关注三连，可以让我知道哪一类内容值得继续写下去。半导体智能制造这条路很长，一起把坑填平。