一、问题背景：FAB里RCA为什么这么难做在半导体Fab里，异常事件几乎每天都在发生：良率骤降、设备报警、批次延误、缺陷率超标。每一件异常背后，品质部都会要求一份RCA报告，也就是根因分析报告。一份合格的RCA要回答三个问题：发生了什么、为什么会发生、怎么防止它再发生。听起来简单，做起来却非常耗时。先讲一个我们亲历的真实案例。某批次产品在CMP工序后检测发现划伤类缺陷率从0.5%飙升到3.8%，品质部要求48小时内给出RCA报告。团队连续两天加班，开了三次跨部门会议，期间工艺工程师和设备工程师一度争执不下，最后才发现根因是浆料更换批次后发生颗粒团聚。整个排查过程里，真正用于定位根因的时间只占两成，剩下八成全部消耗在信息收集、会议讨论和报告撰写上。这个案例非常典型。我们把大量RCA案例复盘后，总结出人工RCA的四个痛点。第一个痛点是经验依赖强：老工程师能凭直觉快速缩小范围，新人面对同样的问题往往无从下手，只能从头到尾把所有可能查一遍。第二个痛点是5Why追问不彻底：很多分析到第二、三个Why就答不上来，链条直接断裂，报告里写一句"供应商来料问题"就草草收场。第三个痛点是证据记录缺失：讨论时有人说"当时好像改过参数"，但没有人去查证变更记录，结论建立在口头记忆上。第四个痛点是报告复用率低：RCA做完就归档，同类问题换一台设备、换一条产线，又从头再来一遍。为什么我们会想到用GPT来尝试解决？原因在于RCA的本质是"基于证据的因果推理加结构化输出"，这恰好是大语言模型相对擅长的领域。模型虽然没有Fab经验，但它读过海量的工程分析案例，对"原因-机制-证据"这种推理链条的把握并不差；而工程师真正的价值在于对现场、设备和数据的理解。所以我们给自己定的目标很明确：不是让GPT替代工程师，而是让GPT先把80%的脏活干完，工程师只做最关键的证据校验和最终决策。这个定位决定了后面所有的设计思路。二、结构化5Why方法论：先有框架，再谈自动化5Why方法起源于丰田生产方式，核心逻辑是对一个问题连续追问"为什么"，直到找到可以采取对策的根本原因。经典的润滑泵案例就是连续五层追问：机器停了是因为超载保险丝断了，超载是因为轴承润滑不足，润滑不足是因为油泵没泵上油，油泵不上油是因为轴磨损，轴磨损是因为没有安装过滤器导致碎屑进入。每一层都有物理证据支撑，链条完整，对策明确。在FAB里实践5Why，最常见的失败模式有四种。第一种是链条断裂：问到第二层就停在"供应商的问题"这种不可验证的结论上。第二种是答案跳跃：从"参数漂移"直接跳到"更换设备"，中间跨越了两三个因果环节。第三种是主语不明：写"我们没注意""系统出错了"，到底是哪个环节、哪个人、什么机制，完全没有界定。第四种是混淆因果与相关：把"同时发生"当成"因为所以"，这是数据分析里最常见的认知陷阱。为了让GPT能够按照规范执行5Why，我们把每一层Why结构化成五个必填字段：层级、问题陈述、直接原因、证据来源、验证方式。问题陈述必须包含明确的主语、谓语和对象，并且是可测量、可复现的现象；直接原因必须是与现象直接相邻的物理或逻辑机制；证据来源必须是客观记录，比如设备日志、SPC数据、变更记录；验证方式必须写明用什么手段确认这个原因是成立的。我们内部立了一条铁律：每个Why的答案必须指向可验证的客观事实，凡是写"可能是""大概是""据说"的一律打回重写。这条铁律同样写进了给GPT的提示词，从源头约束输出质量。下面这张表就是我们使用的5Why结构化模板，字段设计直接决定了GPT输出能不能被后续校验和复用。Why层级字段填写要求FAB示例Why1问题陈述主语加现象，可测量可复现CMP后划伤缺陷率从0.5%升至3.8%Why2直接原因与现象直接相邻的物理机制浆料中颗粒团聚划伤晶圆表面Why3中间原因机制背后的条件变化浆料批次更换后粒径分布异常Why4