数据分析Jupyter模板：良率分析的标准流程

FAB良率工程师的Jupyter Notebook标准化模板，含数据清洗/统计分析/可视化/报告生成

每次做良率分析都要从头写代码——有没有一个模板能直接套用

一、背景故事：两百份分析报告教会我的事

2018年我刚进厂的前三年，做过的良率分析报告少说也有两百份。每一次流程都惊人地相似：从测试系统导出晶粒级数据，从制造执行系统导出批次履历，从统计过程控制系统导出工艺参数，从设备管理系统导出机台状态。然后把这些文件拖到本地，打开集成开发环境，写一段代码读取、清洗、对齐、分组、绘图、统计检验、导出结论。写完之后把图表贴到幻灯片里，附上几段文字说明，发给经理和客户。最讽刺的是，我曾经花两天时间做的一份分析，后来发现半年前已经写过几乎一模一样的脚本，只是当时的数据文件名不一样、分组变量换了一个而已。

团队协作的场景更加混乱。我们组有六个良率工程师，每个人都有自己的脚本习惯和数据定义方式。有人把良率定义为通过测试的晶粒数除以被测晶粒数，有人会把边缘不完整晶粒剔除后再算，还有人习惯按最终测试而不是中间测试来统计。结果同一个批次，不同人算出来的良率数字能差出零点五个百分点。一次客户审核的时候，我们被要求复现三个月前的一份分析报告，结果发现当时的中间数据文件已经被清理，代码也没有版本管理，执行顺序更是无从追溯，最后只能凭记忆重新写了一份，数字对不上就用当时的结论硬凑。

那次审核之后，经理给了一个硬性要求：所有良率分析必须做到可复现、口径统一、能在半小时内从原始数据完成全部分析。这个要求听起来简单，但要落地却不容易。我们花了将近半年时间，经历了十多次迭代，从最初的混乱代码逐步演变成一个模块化、参数化、带单元测试和自动报告生成的完整工具集。现在，团队里的任何一个人拿到一份新的分析需求，只需要在模板里修改几行配置，二十分钟之内就能生成一份包含趋势图、帕累托图、晶圆图和统计检验的完整报告。这篇文章要分享的，就是这套模板的设计思路、核心代码和实际应用经验。

在开始讲模板之前，有必要先理解良率分析的数据模型和统计基础。半导体测试数据的层级结构非常清晰：最细粒度是晶粒级，每个晶粒包含坐标、测试结果和若干参数测量值；往上是晶圆级，一片晶圆包含数百到数万颗晶粒，同时携带晶圆编号、工艺路径等属性；再往上是批次级，一个批次通常由二十五片晶圆组成，携带产品型号、工艺流程版本、时间属性等。良率分析的本质，就是在这个层级结构上做聚合与下钻，并与工艺参数、设备履历建立关联。

理解这种层级结构对于设计高效的分析流程至关重要。在实际工作中，工程师经常需要在不同粒度之间切换视角：当发现良率异常时，首先需要在批次级查看趋势，判断是偶发事件还是系统性问题；然后下钻到晶圆级，观察失效的空间分布模式；最后可能需要深入到晶粒级，分析特定失效代码与工艺参数的关联。这种多层级、多维度的分析需求，要求我们的工具必须具备灵活的数据聚合能力和高效的查询性能。

二、技术原理：良率分析的数据模型与统计基础

良率的定义看似简单，但细节很多。最基础的是晶粒良率，即通过测试的晶粒数除以被测晶粒总数。但这里有几个坑：边缘不完整晶粒算不算被测晶粒？工艺控制监控用的测试结构要不要剔除？前道报废的晶粒在分母里怎么处理？不同工厂、甚至同一工厂不同工程师的习惯都可能不一样。除了总良率，还有按测试项分解的分项良率、按失效代码分类的失效率、以及重测后的最终良率。模板设计的第一原则，就是把良率定义的各种口径都标准化，并且在每一份报告的页脚打印出本次分析使用的具体定义，让数字可以被追溯和质疑。

在统计方法层面，良率分析常用的工具并不多，但每一个都要用对场景。比较两组晶圆的良率是否有显著差异，样本量足够且分布接近正态时可以用双样本t检验，样本量小或者分布偏斜时曼惠特尼秩和检验更稳健。比较多组时用单因素方差分析，但要注意事后多重比较来控制错误率。判断某个工艺参数与良率的相关性，连续变量用皮尔逊相关系数，存在单调非线性时用斯皮尔曼秩相关系数。空间模式识别是良率分析中最有价值但也最容易被忽视的部分：同样是百分之八十五的良率，失效晶粒是均匀随机分布、边缘集中分布还是呈现某种同心圆环形，指向的是完全不同的根因方向。

可复现性是良率分析的基础设施。一份可复现的分析报告需要满足四个条件：输入数据有唯一标识且不可变、分析代码有版本管理、执行环境的依赖声明清晰、输出结果带有完整的元信息。在交互式Notebook环境里，最大的风险是单元格乱序执行导致的隐藏状态。我们的模板采用强制约定来规避这个问题：模板被划分为固定的执行区块，每个区块的输出被显式保存到变量，下一个区块只能从已保存的变量读取，不允许跨区块直接访问Notebook的隐式状态。这种做法牺牲了一定的交互灵活性，但换来了可审计性和团队协作的便利。

从工具生态来看，今天的晶圆厂在良率分析上的方案大致分为三个层次。最上层是商业化系统，功能完整但价格昂贵，定制困难，通常只覆盖日常监控场景；中间层是各厂自研的数据平台，能完成大部分标准化查询和报表，但灵活性有限，遇到复杂下钻需求时往往力不从心；最底层是工程师本地的脚本环境，以Python和R为主，辅以Excel做快速探索。实际上，大部分深度分析工作仍然在最底层完成，商业系统主要负责日常指标监控和告警。在这个生态中，Python已经成为绝对主导，原因在于pandas提供了处理表格数据最便捷的接口，numpy和scipy覆盖了数值计算和统计检验的全部需求，matplotlib和seaborn则能满足从快速探索到正式发表的各种可视化需求。

选择合适的统计方法和可视化工具，需要工程师对数据特征有深入的理解。例如，当良率数据呈现明显的偏态分布时，使用均值作为中心趋势指标可能会产生误导，此时中位数或众数可能更合适；当不同机台之间的良率方差差异较大时，简单的均值比较可能掩盖重要的工艺信息，需要采用更稳健的统计方法。我们的模板内置了多种统计方法和可视化选项，工程师可以根据数据特征灵活选择，同时模板也会给出方法选择的建议，帮助工程师做出更合理的决策。

三、现状分析：从个人脚本到团队协作的困境

分析模板化正在成为行业趋势，背后的驱动力有两个。一是分析需求的增长速度远超工程师人数的增长，如果不把套路沉淀成可复用的组件，团队很快就会被重复劳动淹没。二是质量体系和客户审核对分析过程的可追溯性要求越来越严格，国际上的先进工厂已经把分析模板纳入标准作业程序管理，任何偏离模板的做法都需要书面说明理由。但在现实中，大多数工厂的良率分析仍然停留在个人英雄主义阶段，分析质量高度依赖具体工程师的水平，资深工程师离职会带走大量隐性知识，新人成长周期长，团队整体能力波动大。这个问题的根源不在技术，而在组织层面：分析脚本没有被当作需要维护的资产，没有人为公共组件的开发投入正式工时，也缺乏沉淀和传播好的分析套路的机制。

第一个瓶颈是数据获取的碎片化。一次完整的良率分析通常需要至少四个来源的数据：测试数据、制造执行系统履历、统计过程控制参数、设备状态日志。这些数据分别存储在不同的系统里，由不同的供应商提供，数据模型不一致，批次和晶圆的标识规则也不对齐。工程师在真正开始分析之前，往往要花掉一半以上的时间在数据的定位、导出和对齐上。我们的模板通过封装统一的数据加载模块来解决这个问题，模块内部处理所有的标识映射、时间对齐和缺失值填充，对外只暴露一个标准化的数据框接口。

第二个瓶颈是口径与参数的不一致。除了前面提到的良率定义差异，还有时间窗口怎么选、离群值怎么处理、分组变量用哪些、统计检验的显著性水平设多少等一系列选择。这些选择往往隐藏在代码的某个角落，导致不同工程师面对同一批数据得出相反的结论，而且很难追溯是哪个环节出了问题。模板的做法是把所有这类选择都提取到配置区块，用显式的参数代替隐式的硬编码，并且在报告输出时把这些参数完整打印出来，让任何数字都可以被质疑和复现。

第三个瓶颈是不可复现与不可审计。Jupyter的交互特性让代码版本与最终输出之间的对应关系变得模糊，加上中间数据文件的散落、依赖库版本的变化、随机种子的未固定，几个月后想重现一份分析几乎是不可能的。对于需要向客户或质量体系提交证据的场合，这是一个严重的问题。我们的模板通过强制顺序执行、依赖锁定文件、以及输出元信息嵌入来解决这个问题，确保任何人在任何时间用相同的输入都能得到相同的输出。

第四个瓶颈是分析知识的沉淀。资深工程师脑子里有一套完整的排查树和诊断逻辑，但这些知识只存在于个人经验中，新人只能通过长期跟随才能学到。而脚本只记录了做什么，没有记录为什么这么做，导致团队整体分析能力的上限由少数几个人决定，人员流动时这个上限也会波动。我们的做法是把分析套路写成可组合的模块，每个模块附带详细的文档字符串和使用示例，让新人可以从看懂模块功能开始，在实践中逐步理解背后的统计原理和工程判断。

图1 良率分析标准流程（Jupyter Notebook 模块化执行链）

四、瓶颈问题：为什么良率分析总是慢且乱

针对上述瓶颈，我们设计了一套标准化的Notebook模板。模板遵循四个设计原则：配置与逻辑分离，用户只需要在第一个区块修改产品型号、时间窗口、良率定义等参数，后续区块直接执行即可；模块化可组合，每个功能封装成独立的函数放在工具包里，Notebook本身只负责流程编排，这样既保证了可读性，又能被单元测试覆盖；输出即报告，执行完成后Notebook本身就是一份可读的分析报告，无需额外整理；可复现可审计，所有随机过程固定种子，依赖版本锁定，输出带有完整元信息。

整个模板被划分为七个固定的执行区块：参数配置、数据加载、数据清洗与校验、指标计算、可视化、统计分析、报告导出。这个顺序对应分析的自然流程，每个区块的输出都是下一个区块的输入，形成清晰的数据流。参数配置区块只包含纯数据，没有逻辑；数据加载区块负责从各个系统读取原始数据并做初步合并；清洗校验区块检查数据完整性、处理缺失值、标记离群点；指标计算区块按照配置里的定义计算各类良率指标；可视化区块生成标准图表；统计分析区块执行假设检验和相关性分析；报告导出区块把结果保存为带元信息的文件。

下面给出模板的核心代码，总量控制在八十行以内，覆盖从数据加载到可视化的完整流程。首先是参数配置区块，这里用纯Python字典定义所有可调整参数，避免硬编码散落在代码各处。

接下来是数据加载与清洗区块，使用pandas读取测试数据和制造执行系统履历，通过批次号做内连接合并，并执行基础的数据校验。

然后是指标计算区块，按照配置里的良率定义计算总体良率和按机台分组的良率，同时统计失效代码的分布。

最后是可视化区块，使用matplotlib和seaborn生成趋势图、帕累托图和分组对比图，并添加必要的标注和样式。

五、解决方案：标准化Notebook模板的设计

下面用一个真实的产线异常来演示这套模板的实战效果。某天早上八点，我接到生产部门的电话，说一个成熟产品的周良率从稳定的百分之九十二点四跌到了百分之八十八点一，四个百分点的下滑属于重大异常，需要立即给出根因方向。按照过去的流程，这种级别的分析通常需要一整天才能形成初步结论，但那天我直接打开了模板，在参数配置区块填入产品型号和时间窗口，然后一路执行下去。二十分钟后，四张图表清晰地指向了问题所在。

第一张是良率趋势图，显示良率下滑是一个阶跃式的突变而不是渐变，拐点精确地落在六天前的夜班。第二张是失效代码帕累托图，显示新增失效集中在一个特定的失效代码上，这个代码对应的是漏电流超标。第三张是按光刻机分组的良率箱线图，显示四台光刻机之间的良率没有显著差异，排除了光刻环节的问题。第四张是晶圆空间分布图，显示失效晶粒呈现出清晰的边缘环状分布，集中在距晶圆边缘十五毫米以内的区域。这四张图综合起来，指向一个非常具体的方向：六天前的某个变更影响了晶圆边缘区域的某道工序。

接下来的下钻分析更加直接。我把分组变量从光刻机改成刻蚀机，重新执行可视化区块，箱线图立即显示出明显的分化：其中一台刻蚀机的良率中位数比另外三台低了近八个百分点，而且该机台的批次几乎全部落在拐点之后。再调用参数相关性分析模块，对该工序的十六个工艺参数与良率做斯皮尔曼相关分析，结果显示腔体压力的批内标准差排在第一位，相关系数负零点六七，显著性远低于百分之一。整个下钻过程从接到异常通知到给出根因方向，耗时不到一个半小时，其中真正花在写代码上的时间是零，全部时间都用在看图和思考上。

结论提交给刻蚀工程组之后，他们检查那台机台，发现节流阀存在响应迟滞，导致腔体压力在工艺过程中出现周期性波动，这种波动在晶圆边缘区域的刻蚀均匀性上被放大，最终造成栅氧边缘损伤。更换节流阀之后，该机台的后续批次良率在两天内恢复到正常水平。这个案例完整地展示了模板的核心价值：它把工程师从重复的数据处理和代码编写中解放出来，让他们把精力集中在判断和分析上，而判断和分析才是工程师真正的价值所在。

# 区块1：参数配置（纯数据，无逻辑）

CONFIG = {

"product": "P28L_V3.2",

"date_start": "2025-06-01",

"date_end": "2025-08-01",

"yield_mode": "die_yield", # die_yield / wafer_yield / final_yield

"exclude_edge": True, # 是否剔除边缘不完整晶粒

"outlier_sigma": 4.0, # 离群值判定阈值（标准差倍数）

"group_by": ["scanner_id", "etcher_id"],

"random_seed": 20260802,

}

# 区块2：数据加载与清洗

import pandas as pd

import numpy as np

np.random.seed(CONFIG["random_seed"])

df_test = pd.read_csv("wafer_test.csv", parse_dates=["test_time"])

df_mes = pd.read_csv("lot_history.csv", parse_dates=["start_time"])

mask = (df_test["test_time"] >= CONFIG["date_start"]) & (df_test["test_time"] <= CONFIG["date_end"])

df = df_test[mask].merge(df_mes, on="lot_id", how="inner")

assert df["lot_id"].nunique() >= 10, "有效批次不足，请检查时间窗口"

# 区块3：指标计算

def compute_yield(g):

if CONFIG["exclude_edge"]:

g = g[~g["is_edge_die"]]

return g["pass"].sum() / g["tested"].sum() * 100

yield_by_lot = df.groupby("lot_id").apply(compute_yield).reset_index(name="yield")

yield_by_tool = df.groupby(CONFIG["group_by"][0]).apply(compute_yield)

fail_pareto = df[df["pass"] == 0]["fail_code"].value_counts(normalize=True) * 100

# 区块4：可视化（matplotlib + seaborn）

import matplotlib.pyplot as plt

import seaborn as sns

fig, axes = plt.subplots(2, 2, figsize=(12, 9))

# 趋势图

ax = axes[0, 0]

df_ts = yield_by_lot.set_index("lot_id")

df_ts.plot(ax=ax, marker="o", title="Yield Trend")

ax.axhline(df_ts["yield"].mean(), color="r", ls="--")

# 帕累托

ax = axes[0, 1]

fail_pareto.head(6).plot(kind="barh", ax=ax, color="coral")

ax.set_title("Pareto of Fail Codes")

# 按机台箱线

ax = axes[1, 0]

sns.boxplot(data=df, x=CONFIG["group_by"][0], y="yield", ax=ax)

ax.set_title("Yield by Tool")

# 相关性热力图

ax = axes[1, 1]

corr = df[["param_a", "param_b", "param_c", "yield"]].corr()

sns.heatmap(corr, annot=True, cmap="coolwarm", ax=ax)

ax.set_title("Correlation Matrix")

plt.tight_layout()

plt.savefig("report.png", dpi=150)

表1 模板模块化清单与功能说明

六、实战案例：两小时定位刻蚀机异常

模板推广一年之后，我们做了一次系统性的效果评估。首先是效率：常规良率分析的平均完成时间从六点五小时降到了一点二小时，降幅超过百分之八十；重大异常的首次结论输出时间从十八小时降到了三点五小时。这意味着同样的人力资源，团队一年内完成的分析数量从三百多份提升到了近九百份，而人员规模并没有增加。更重要的是，那些过去因为时间成本太高而被跳过的探索性分析，现在变得可以随时完成，团队对产线状态的掌握细致程度明显提升。

质量方面的改善同样显著。口径不一致引发的争议基本消失，因为所有报告都在页脚打印了完整的配置参数，任何人对数字有疑问都可以直接追溯。分析结论的可复现性达到百分之百，我们抽样验证了半年前的十份报告，重新执行后输出与原报告完全一致，这在最近的客户过程审核中也获得了正面评价。团队能力建设方面的影响最为深远：新入职工程师的独立上手周期从三到四个月缩短到了三周，因为他们可以直接从看懂图表和判断模式入手，在实践中逐步深入理解底层代码。

资深工程师的经验也开始沉淀。我们把常见的排查路径写成了模板的扩展模块，比如边缘失效专项分析模块、机台间比对分析模块、参数漂移追溯分析模块，每个模块都封装了对应场景下应该看哪些图、做哪些检验、如何判断结果。这些模块附带详细的文档和使用示例，新人可以在完成实际任务的过程中学习套路，而不是依赖口头传授。一年下来，团队内部关于分析方法的讨论从怎么写代码变成了怎么看图、怎么判断，讨论质量明显提升。

当然，模板不是万能的。它擅长处理已知类型的问题，对于全新的、结构性的异常，仍然需要工程师跳出模板做定制分析。我们也遇到过工程师过度依赖模板、形成思维定势的情况，只看模板生成的图而忽略了其他可能的线索。为此我们在分析评审规范里加了一条：任何重大异常的分析报告必须包含至少一段模板之外的独立观察，强制工程师跳出舒适区。工具的价值在于自动化重复部分，但判断永远是人的责任。

图2 良率分析可视化面板示例（趋势/帕累托/箱线/空间分布四联图）

表2 良率分析常用统计方法对照表

七、实施效果：效率提升与知识沉淀

回顾这套模板的演进过程，有几个关键决策值得总结。第一个决策是把配置与逻辑彻底分离。早期版本曾经尝试过在代码里用注释标注可调参数，但发现工程师还是会直接改代码，导致版本混乱。后来强制要求所有参数必须集中在配置区块，逻辑区块只读不写，这才保证了可复现性。第二个决策是坚持输出即报告。我们曾经在模板之外维护一份单独的Word模板用来整理结论，但两份文档很快就会不同步。现在的做法是Notebook执行完成后直接导出为带样式的HTML，图表和结论都在同一个文件里，永远同步。

第三个决策是拥抱约束而非追求灵活。Jupyter的交互特性是双刃剑，我们主动放弃了部分灵活性来换取可靠性：强制顺序执行、禁止跨区块隐式状态、随机种子固定、依赖版本锁定。这些约束在初期遭遇过抵触，但运行一年之后团队普遍认可了它们的价值。第四个决策是把模板当作产品来运营。我们设立了专门的维护角色，定期收集使用反馈，每季度发布一次版本更新，修复问题、添加新模块、优化性能。模板有了版本号、变更日志和发布说明，工程师知道遇到问题该找谁、该怎么升级。

对于想要在自己团队推行类似方案的读者，我的建议是分三步走。第一步先统一数据接口，把从各个系统获取数据的过程封装成稳定的函数，这是所有后续工作的基础。第二步再统一分析套路，挑选团队里最常用的三到五种分析场景，把它们的流程写成模板，不要贪多。第三步建立反馈机制，让使用模板的工程师能够方便地提交问题和建议，持续迭代优化。不要指望一次性做出完美的模板，好的模板是用出来的，不是设计出来的。

最后想说的是，工具层面的标准化只是手段，真正的目标是让工程师把时间花在更有价值的事情上。良率分析的本质是透过数据理解工艺，理解设备，理解产品。当工程师不再被重复的数据处理和代码编写消耗精力，他们才有余力去做更深层次的思考：这个异常模式我见过吗？类似的工艺在其他产品上出现过吗？有没有可能从设计端预防？这些思考才是良率工程师真正的价值所在，也是任何模板都无法替代的人类智慧。

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

如果这篇文章对你的工作有帮助，欢迎在评论区留下你的实践经验：你所在产线遇到过哪些类似问题，最终是怎么解决的？

对文中的模型参数、代码结构或者数据口径有不同看法，也欢迎直接指出来，我会逐条回复。

有想看的选题可以在评论区点题，后续会挑呼声最高的方向继续写实战系列。觉得有用的话，点赞、收藏、关注三连支持一下，你的反馈是这个系列写下去的动力。