把EDA分析交给Code Interpreter：一句话出良率报告

一、背景故事：周一早上那份永远赶不出来的良率周报

先说明一个容易混淆的名词。半导体圈子里说EDA，大多数人第一反应是Electronic Design Automation，也就是Synopsys、Cadence那一套设计工具。但本文说的EDA是Exploratory Data Analysis，探索性数据分析，是数据科学里的概念。在Fab的良率工程场景中，它指的是拿到一批良率数据后，先做描述统计、分布检查、分组对比、相关性扫描，在建立正式假设之前把数据的形状摸清楚。这是良率分析真正开始之前的必经环节，也是最耗时、最枯燥、最容易被压缩的环节。

我们组过去的周报流程是这样的：周五下午从数据仓库导出本周所有量产批次的良率明细，通常是三到五个CSV文件，加起来二十几万行；周末在家用pandas清洗一遍，把设备号、配方版本、测试程序版本对齐；周一早上七点开始画图，把良率趋势、工序分解、Top缺陷模式做成十几张图，塞进PPT；九点半交给经理，十点参加良率例会。整个流程平均要花6.5小时，其中真正需要动脑子的部分不到一小时，剩下的全是机械劳动。

更让人沮丧的是，这些机械劳动做完之后，经常发现某个维度没切分到。比如经理会问一句"按测试机台分组看过吗"，那就得再回去跑一遍，重新画图重新排版，又是四十分钟。人的耐心是有限的，被这样问过几次之后，很多工程师就会选择在周报里少写一点，只保留最保险的几张图，反正问了再补。这直接导致周报的信息密度越来越低，良率例会变成了念数字大会。

2026年初我们开始尝试把这部分工作交给大模型的Code Interpreter能力。需要说清楚的是，Code Interpreter和普通对话不是一回事：它会真的在沙箱里跑Python，读取你上传的CSV，执行pandas和matplotlib，返回真实计算出来的数字和图片，而不是凭语言模型的直觉编造。这个区别至关重要，因为编造的良率数字比没有数字更危险。

图1：良率EDA七个环节的人工与Code Interpreter辅助耗时对比。结论撰写环节耗时反而上升，因为人工复核与业务解读无法也不应被替代。

二、技术原理：Code Interpreter为什么能做EDA，边界在哪里

2.1执行沙箱的本质：模型写代码，代码算数字

理解Code Interpreter的可靠性边界，关键是理解它的两层结构。第一层是语言模型，负责理解你的自然语言意图，把它翻译成Python代码；第二层是执行沙箱，一个隔离的Python运行时，预装了pandas、numpy、scipy、matplotlib、scikit-learn等常用库。模型生成代码之后，沙箱执行，把标准输出、异常栈、生成的图片文件回传给模型，模型再根据执行结果决定下一步是解读还是修正代码重跑。

这个循环带来一个非常重要的性质：数值是算出来的，不是猜出来的。当模型说"A组均值92.3%，B组均值88.7%，t检验p=0.003"时，这三个数字来自真实的scipy.stats.ttest_ind调用，它们的正确性等价于代码的正确性，而不是等价于模型的记忆准确度。这是Code Interpreter相比纯对话模式在数据分析场景下最大的可信度提升来源。

但风险也随之转移了。数字本身可能是对的，代码逻辑却可能是错的。最常见的错误不是语法错误（那会报错，模型会自己修），而是静默的语义错误：groupby之后忘记dropna，导致某些分组的样本量其实只有2；把包含工程批的数据混进量产批统计；用了不适合的检验方法却给出显著性结论。这些错误代码能跑通，结果看着也合理，只有懂业务的人才能发现不对。

2.2三种数据接入方式的取舍

第一种是直接上传CSV。最简单，适合一次性分析，但有文件大小限制（多数平台单文件在100MB上下），而且数据离开了内网，合规风险最高。我们只对彻底脱敏后的样本数据用这种方式。

第二种是本地部署的Code Interpreter。用开源方案（比如基于Jupyter Kernel Gateway自建的执行环境）接一个私有化部署的模型，数据完全不出内网。缺点是模型能力通常弱于顶级闭源模型，代码一次通过率会下降15到25个百分点，需要更多轮次的修正。我们最终选的是这条路。

第三种是混合模式：数据留在本地，只把schema和统计摘要传给云端模型，让它生成代码，再拿回本地执行。这种方式合规性好、模型能力强，但模型看不到真实数据分布，遇到脏数据时生成的代码鲁棒性差，来回调试的次数反而更多。适合分析逻辑固定、数据质量稳定的场景。

2.3脱敏不是删字段，是保关系

很多人做数据脱敏的第一反应是把敏感列删掉。这在良率分析里行不通，因为分析的价值恰恰在于维度之间的交叉。删掉设备号，就没法做设备间对比；删掉配方版本，就没法定位是不是换配方引起的下滑。正确的做法是保留关系、替换标识。

表1：Fab良率数据交给大模型前的脱敏与预处理规则

这张表是我们踩了几次坑之后固化下来的规则。特别提醒两点：配方参数做线性缩放时，同一参数在所有批次上必须用同一组缩放系数，否则参数之间的相关性会被破坏，分析结论直接作废；时间戳做日期偏移时，偏移量必须是整数天且全局一致，否则星期几这个非常重要的维度（很多Fab周末的良率确实和工作日不同）就没了。

三、现状分析：我们对六类分析任务做了三个月的可靠性打分

为了搞清楚哪些活能放心交出去，我们做了一件比较笨但很有价值的事：从2026年3月到5月，每次用Code Interpreter做分析，都由一名工程师用传统方式独立复算一遍，然后逐项打分。累计样本是187次分析任务，覆盖六个类别。

图2：六类分析任务的可靠性评估矩阵。描述统计与分组对比可放心交付，根因推断一次通过率仅41%、逻辑误导率高达58%，必须由工程师主导。

结果基本符合直觉但也有意外。描述统计一次通过率97%，这类任务本质是调API，模型很难做错。分组对比93%，扣分主要来自小样本组没有被自动过滤。

意外在相关分析。一次通过率88%看起来还行，但逻辑误导率有14%。典型情况是：模型算出某个工艺参数和良率的Pearson相关系数是0.62，然后写道"该参数对良率有显著正向影响，建议提高设定值"。相关不等于因果这个道理谁都懂，但当它出现在一份格式规整、有图有表有p值的报告里时，很容易被顺着读下去。在Fab里，一个错误的工艺参数调整建议可能造成几十片wafer的损失。

根因推断这一项，一次通过率只有41%，逻辑误导率58%。这个结果并不意外——根因推断需要的是工艺物理知识、设备维护历史、厂内变更记录这些数据之外的信息，模型没有这些上下文，只能基于统计相关性编故事。我们的结论是：根因推断这一步坚决不交给模型，最多让它列出候选假设供工程师筛选。

四、瓶颈问题：三个月里真正卡住我们的四件事

4.1长对话中的上下文漂移

第一次分析时你告诉模型"Yield列是百分制，取值0到100"，前十轮它都记得。到了第二十五轮，它突然在代码里写了一句yield_rate = df["Yield"] * 100，把92.3变成了9230。这类漂移在长会话里几乎必然发生，因为早期的约束在上下文窗口里被后续内容稀释了。

我们的对策是"约束前置化"：把数据字典和口径约束写成一个固定的文本块，每隔八到十轮就完整重贴一次，而不是指望模型记住。这个做法很土，但把漂移导致的错误从每周三四次降到了两周一次。

4.2图表默认样式与工厂规范不一致

模型生成的matplotlib图默认是白底、英文标签、默认配色，而我们的周报模板要求深色背景、中文标签、公司标准色。每次手工改样式，把节省下来的时间又吐回去一半。

解决办法是准备一个样式初始化代码块，在每次会话开始时让模型先执行它（设置SimHei字体、深色主题、固定配色列表、DPI=150），后续所有绘图自动继承。这个小改动单次分析节省约二十分钟。

4.3沙箱环境的库版本与本地不一致

云端沙箱的pandas版本可能是2.2，我们本地生产环境还停在1.5。模型生成的代码用了2.x才有的API，拿回本地跑就报错。这个问题在把分析代码固化成定时脚本时特别致命。对策是在提示词里明确写出目标环境的关键库版本，并要求生成的代码避免使用近两年新增的API。

4.4工程师的能力退化风险

这一条是最容易被忽略、但长期看最需要警惕的。用了两个月之后，我发现组里两个新人已经不会手写groupby加agg的组合了，遇到问题第一反应是问模型。当模型给出错误代码时，他们缺乏识别能力，只会说"模型是这么写的"。

我们的应对是硬性规定：所有交付到经理层面的分析，关键结论必须由工程师用独立方式复算一遍，并且每周的组内技术分享，轮流讲一次自己手写的分析代码。工具是用来提升上限的，不是用来降低下限的。

五、解决方案：一套可复制的四层落地架构

5.1第一层：数据管道与脱敏网关

在数据仓库和分析环境之间加一个脱敏网关，用Python实现，核心是一个配置驱动的映射器。每个字段在YAML配置里声明脱敏策略（passthrough / hash / scale / categorize / offset），网关读取配置执行转换，同时把映射关系加密存档，保证分析出结论后可以反查到真实的设备号和批次号。

RULES = {
"EqpID": {"mode": "prefix_reindex", "keep_prefix": 4},
"RecipeP1": {"mode": "scale", "k": 0.837, "b": 0.0},
"LotID": {"mode": "hash", "length": 8, "salt": ENV_SALT},
"Yield": {"mode": "passthrough"},
"ProcTime": {"mode": "offset_days", "days": -137},
}

这里有个细节值得强调：scale模式的系数k必须写死在配置里并纳入版本管理，不能每次随机生成。否则两次分析的数据无法对比，而良率分析最常见的需求恰恰就是"这周和上周比怎么样"。

5.2第二层：五段式提示词模板

提示词不是玄学，它是接口契约。我们把它固化成五段结构，每段有明确职责，工程师只需要填空。

表2：良率EDA提示词模板的五段式结构与实测效果

实际使用时，第1段和第2段是固定的，存在一个模板文件里；第3段是每次分析的变量，工程师写一到两句话；第4段和第5段也是固定的。所以真正需要手写的只有第3段，一般不超过五十个字。这个设计让新人上手时间从半天缩短到二十分钟。

5.3第三层：反向校验机制

拿到模型的分析结果后，不要直接采信，而是执行三个固定的反问。第一问："请打印出每个分组的样本量n，以及被dropna过滤掉的行数"。这一问能抓出绝大部分小样本和缺失值问题。

第二问："请把你用来得出这个结论的中间DataFrame前20行打印出来"。这一问能验证数据切分逻辑对不对，我们抓到过好几次把工程批混入量产批统计的情况。

第三问："以上哪些是计算结果，哪些是你的推测？请分开列出"。这一问对区分事实和幻觉极其有效，模型在被明确要求区分时，通常会诚实地承认哪些是推断。

5.4第四层：固化为定时任务

当某类分析被重复做过五次以上，说明它已经稳定了，这时应该让模型把交互过程中的代码整理成一个独立脚本，人工审核后纳入git，配置成定时任务。之后这类分析就完全自动化了，不再需要模型参与。

这一点非常重要：Code Interpreter的定位是探索阶段的加速器，不是生产环境的执行器。稳定的分析用固化脚本，成本更低、结果可复现、出问题好排查。把每次都一样的活反复交给模型，既浪费token也增加不确定性。

六、实战案例：一次真实的良率下滑排查

2026年4月中旬，某成熟制程产品线的整体良率从周均93.1%掉到90.4%，掉了2.7个百分点。传统排查流程预计需要一天半，这次我们用新流程做，从数据准备到锁定嫌疑范围花了一小时四十分钟。

第一步，脱敏网关导出近八周的批次级良率明细，包含批次号（哈希）、投料日期（偏移）、产品代号、各工序设备号、配方版本、最终良率、Bin分布，共31274行。

第二步，用五段式提示词发起第一轮分析，任务是"识别良率从第6周开始下降的过程中，哪些维度上的分布发生了统计显著的变化"。模型跑了四个维度的KS检验，返回结果指向两个候选：CMP工序的设备分布（p=0.0007）和某个测试程序版本的占比（p=0.013）。

第三步，执行反向校验。第一问打出样本量，发现测试程序版本那个信号的样本量只有14个批次，而且集中在最后三天，很可能是刚切换的新版本还没铺开，属于伪信号。CMP设备那条线样本量充足，保留。

第四步，追问CMP设备维度。模型做了设备间良率的箱线图对比，发现CMP-03这台机台在第6周之后处理的批次，良率中位数比其他三台低3.8个百分点，而且它在第6周的产出占比从18%涨到了34%。也就是说，不是CMP-03突然变差了，而是它一直略差，但第6周排产把更多批次压给了它，稀释了整体良率。

第五步，人工介入。我们查了设备维护记录，CMP-03在3月底做过研磨垫更换，之后一直没有做过完整的Cpk验证；再查排产，第6周CMP-01停机保养，产能确实压给了03。两条线索对上了。这一步模型帮不上忙，因为维护记录和排产计划不在分析数据集里。

最终措施：CMP-03暂停接高价值产品，安排研磨垫参数重新验证；排产系统增加设备良率权重，避免把批次过度集中到能力偏弱的机台。两周后整体良率恢复到92.8%。

七、实施效果：三个月的量化数据

统计口径是2026年3月1日到5月31日，与上一季度同期对比。周报制作总工时从平均6.5小时降到55分钟，降幅85.9%。需要说明的是，图1中"结论撰写"环节的耗时从15分钟涨到17分钟，这是有意为之：省下来的时间部分投入到了人工复核和业务解读上。

分析维度的覆盖数量从平均每期4.2个维度提升到11.6个维度。这是我认为比省时间更有价值的变化——过去因为成本高而不做的交叉分析，现在可以随手做。良率例会上"这个维度看过吗"的追问次数从每次平均3.4次降到0.6次。

异常发现的平均提前期从6.2天缩短到2.8天。原因是过去每周只做一次全面EDA，现在每两天可以跑一轮，缓慢的趋势变化能更早被捕捉。

同期需要如实记录的负面数据：三个月里发生了2次因模型输出错误而导致的误判，均在人工复核环节被拦截，未流出到决策层。第一次是分组样本量过小被当作显著差异，第二次是模型把两个不同测试站的良率直接平均而没有加权。这两次都印证了反向校验机制的必要性。

成本方面，本地部署方案的一次性投入约为一台带48GB显存显卡的推理服务器，加上两周的工程搭建时间。按节省的工时折算，回收期大约在五个月，这还没算分析质量提升带来的隐性收益。

八、延伸补充：工程落地的更多细节

8.1什么样的分析任务适合交给Code Interpreter

经过三个月实践，我们总结出一个简单的判断标准：如果一个分析任务，你能在三十秒内向一个懂Python但不懂半导体的实习生讲清楚要做什么，那它就适合交给模型；如果讲清楚需要先铺垫工艺背景，那就不适合。

具体来说，适合的任务包括：数据清洗与格式转换、描述统计与分布检查、按已知维度的分组对比、指定方法的假设检验、标准图表绘制、多文件合并对齐、缺失值与异常值的识别报告。这些任务的共同点是判断标准客观、不依赖领域先验。

配套资料与实战工具包

本文涉及的脚本、参数模板、检查清单已整理成配套资料包，可直接用于工厂落地实施，内容随实践持续更新。点击文章上方「VIP资源」下载区免费获取：

• 良率数据脱敏网关配置模板（YAML规则文件加Python实现）
• 五段式EDA提示词模板（含数据字典填写示例）
• matplotlib深色主题样式初始化代码块（SimHei中文支持）
• Code Interpreter输出反向校验Checklist（三问清单）
• 批次良率EDA标准分析脚本（pandas版，含示例数据集）

────────────────────────────────────────

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

你在实际项目里遇到过类似情况吗？是怎么处理的？欢迎在评论区分享你的实战经验，一起交流进步。

标签：半导体AI融合|半导体Fab | MES系统| SPC |良率提升|智能制造