LLMs are inside fabs, so why aren't they solving core problems?

在讨论大模型为什么还没有攻克晶圆厂的核心难题之前，我们先要客观承认一个事实：通用大模型（LLM）其实已经在很多头部 Fab 里用起来了。就行业现状而言，大多数先进晶圆厂早就有成熟的内部私有云、充足的本地算力，以及在防火墙内安全部署的本地大模型工作负载。同时，Fab 的数据不仅非常全，而且还在持续迭代升级——因为晶圆厂一直在向设备商（Tool Vendors）施压，推动机台开放更高频、更丰富、更有效的传感器与工艺数据。由于从私有云、算力、数据到本地模型部署这几个环节都已经打通，很多一线工程师每天都在用内部 LLM 生成早晚会（Passdown）的汇报 Slides，或者辅助编写一些基础的数据处理脚本。

从这个角度看，外围的日常办公辅助其实已经跑通了。但回到我们上一篇关于 Fab 核心价值的讨论：靠 AI 完全替代晶圆厂工程师在技术上根本不成立；而仅仅让工程师把早晚会 Slides 做快一点、少写几行基础脚本，也远不是晶圆厂对企业级 AI 真正期待的核心价值。对 Fab 真正有决定性价值的，是解决产线上的硬骨头——尤其是直接关系到晶圆产出与客户交付的良率（Yield）异常和可靠性（Reliability）失效调查。

更重要的是，这件事的工程门槛正在急剧升高。过去某些微小波动或许还能靠常规抽样掩盖，但可预见的是，随着智能汽车与智能驾驶的快速普及，车载芯片在晶圆需求中的占比越来越高。车载芯片对良率一致性和早期潜在可靠性缺陷的要求极其严苛，对每一片 Wafer 的过程控制标准远高于传统消费级设计。然而，一旦从“写早晚会 Slides”迈入真正的良率掉点或可靠性异常调查，通用的 LLM 用法就会立刻撞上“两个半”核心痛点。

第一个绝对痛点是，通用大模型缺乏“实证科学计算（Empirical Scientific Computing）”的执行机制与执行能力。一旦进入真正的异常定界，无论是 Defect（缺陷检测）团队、Yield / PIE（良率与工艺整合）团队，还是 Quality / Reliability（质量与可靠性）团队，工程师面对的核心工作都不是“文字总结”，而是严密的空间几何、高维统计与物理失效分布计算：

在真实的 Fab 调查里，任何一个脱离了明确统计口径、边缘排除范围、参考对照组条件和确定性可复算过程的数字，都无法作为批次处置（Lot Disposition）或机台复机的工程依据。靠概率预测下一个 Token 的通用语言模型，天生无法独立承担这套实证科学计算。

依托厂内私有云与全量数据，通用模型已能辅助整理日常交接汇报，但尚未触及产线良率与可靠性定界的核心痛点。

将跨步 Adder 配准、1,000+ 步混杂变量剥离与 Weibull 尾部拟合交由确定性的科学计算引擎执行，确保每个数字口径可复查。

不止于静态文本问答（RAG），而是把过往经验转化为自动拉取关联工序 Context、对齐基线并逐步排除干扰项的执行流程。

顺应 Fab 工程师直接查找、观察晶圆空间形貌、比对分布并核对原始记录的使用习惯，由四位一体的专用 Agent 完成闭环。

第二个核心痛点在于，如何把以前的工程师积累下来的实战经验，真正有效地融合到异常分析的完整过程中。通用大模型确实掌握公开教科书上的半导体物理与工艺常识，但在一场真实的 Fab 良率或可靠性调查里，最耗费心力的往往是前面横跨数十道关联工序的流程梳理与数据上下文准备（Context Preparation）——当某类特定电测失效或空间形貌出现时，应该回溯哪几个关联 Patterning 循环？需要拉取哪些机台腔室的 PM 前后窗口、Recipe 步长变化与 FDC 传感器摘要？老工程师又是按照什么先后顺序排除假阳性和干扰项的？

这些针对特定产线与特定工艺的流程知识，通用 LLM 本身并没有。而如果只是把历年的 8D 报告、交接 PPT 或排障总结扔进向量检索库里做简单的文本问答（Text RAG），系统最多只能复述几句历史摘要，依然无法面对新的异常自动完成跨工步的数据拉取、口径对齐与分步排查。只有把沉睡在历史案例中的工程经验，转化为指导系统“如何准备多步数据、如何构建参考对照组、如何一步步调用科学计算验证假设”的可执行规范，历史经验才能在每一次新调查中真正发挥作用。

除了上面两个硬核技术痛点，还有“半个”在实际落地中同样决定生死的痛点——用户体验（User Experience）与工程师使用习惯。不同于从零发明一个全新的物理仿真算法，在今天的半导体制造与工程软件领域，许多单点的基础计算组件其实已经被现有的各个流程与工具覆盖得相当完善了。当我们在这个基础上探讨如何进一步提高跨工步异常调查的整体效率时，用户体验与交互方式就变得至关重要。

从长期做芯片设计、EDA 工具研发以及服务一线工程用户的经验来看，想要强行培养或改变工程师的一个固有使用习惯是非常困难的。Fab 里的 PE、PIE、Defect 和 Reliability 工程师常年养成的是“视觉与证据优先”的工作习惯：通过直接查找、直接观察晶圆图与空间分布、在图表与参考组分布之间点击下钻、直接核对原始加工记录来确认判断，这些动作在他们熟悉的视觉界面里原本就能直接完成。而通用 LLM 提供的是一个纯文本聊天框（Chatbox），要求工程师靠打字提问和阅读长篇文字来排查晶圆问题，这完全违背了 Fab 工程师观察、比对与验证问题的直觉习惯。

因此，我们的结论非常明确：面对车规级时代愈发严苛的良率与可靠性挑战，单纯的通用 LLM 本身不是解，但专门针对晶圆制造异常调查场景深度设计的 Agent 才是解。要设计出一个不止步于写早晚会 Slides、真正能在 Fab 核心调查流程中用起来的专用 Agent，要求设计者必须同时深刻理解以下四件事：

Mango AI 与 WaferPilot 的工程实践：以 AI for Empirical Scientific Computing（实证科学计算 AI）为底座，将科学计算执行机制、结构化工艺排查经验与符合工程师直觉的视觉证据工作台融为一体，协助团队攻克良率与可靠性调查深水区，缩短晶圆生产周期。