半导体行业的软件发布消息，一年到头不算少，但这次 Exensio® Aurora 发布我确实多看了两眼。原因很简单，“PB 级半导体数据”和“智能体 AI”这两个词凑在一起，说明产品要解决的已经不是“报表还能不能刷出来”的问题，而是“数据多到人已经看不过来、分析得靠 AI 帮你干活”的问题。这篇文章我打算拆一拆 Aurora 到底做了什么、底层怎么撑住 PB 级数据、智能体 AI 在半导体场景里到底怎么用，以及真正落地时哪些坑值得提前避开。适合正在搞良率分析、设备工程、CIM 系统，或者企业数据平台建设的朋友参考，尤其是已经被数据量和分析效率折磨过的团队，这篇应该能给你一些共鸣。

1. Exensio Aurora 解决的到底是什么问题

1.1 半导体数据规模，早就不是“加个服务器”能打发的事

先聊聊数据规模这件事。很多人听到“PB 级”觉得是营销词，但在先进制程晶圆厂里，这还真不是夸张。你想想看，一座 12 寸晶圆厂里，光刻、刻蚀、薄膜沉积、扩散、CMP 这些工序设备加起来动辄上千台，每台设备的传感器都在按毫秒到秒级频率上报数据，一个炉管可能同时监控几十个温区、几百个气体流量计，一天下来的时序数据就是几个 TB。加上 WAT 允收测试、CP 晶圆测试、缺陷检测的检查机台、CD-SEM 量测、Overlay 量测，每片晶圆会产生成千上万条测试结果，而一个成熟产品一个月的出货量就是几万片晶圆，数据很容易往 PB 量级冲。

更麻烦的是，这些数据不会只留在工厂内部。多厂区对比、研发实验数据、设备商回传日志、供应链数据，全部汇到一起，数据规模已经远远超出传统电子表格和常规数据库的舒适区。我见过不少 FAB 的良率工程师，分析一个“Bin1 异常上升”的 case，要导出的历史数据动不动就是几亿行，SQL 查询跑几十分钟甚至几个小时，导出来之后 Excel 一打开就卡死，这种体验相信不少人都经历过。这也是 Aurora 这类产品出现的直接背景：数据已经多到人跟系统都“扛不住”了，必须有新的底座来承接。

1.2 传统分析平台最尴尬的三件事

传统数据分析平台在半导体场景里，我有三个特别深刻的痛点。

第一个是查询响应太慢。很多工厂的核心分析系统还停留在关系型数据库加 BI 报表的模式，数据量一旦大了，交互式分析基本没法用。你想下钻一个机台、一天、某个参数组合，数据库就得全表扫描，P95 响应时间动不动几十秒，真正分析的时间还没有等结果的时间长。

第二个是数据孤岛严重。设备数据在设备厂商的采集软件里，良率数据在测试系统里，生产数据在 MES 里，工艺数据在配方管理工具里。工程师想做一个跨数据的关联分析，得先从五个系统导出五张表，再在 Excel 里 VLOOKUP。这个过程我称之为“手工数据工程”，耗时至少占整个分析时间的 70%。

第三个是口径打架。同一个产品的良率，工程部门和 IT 部门算出来的可能差一个点，原因可能是分母定义不一样，可能是时间窗口不一样，也可能是 Bin 归类方式不一样。指标口径不统一的问题，在数据量大了以后会特别突出，因为没人愿意手工去核对几十亿行数据的口径是否一致。

这三个痛点组合在一起，就是半导体行业数据平台的“老三大难”。Aurora 这类新一代平台的思路，不是在这三个问题上面继续打补丁，而是把数据底座、指标语义和 AI 分析能力一次性重构掉。

1.3 Aurora 的产品定位：数据底座＋AI 执行环境

那 Aurora 到底是什么？我理解它不是一个单纯的报表工具，也不是传统的 BI 平台，而是一套面向半导体行业的数据基础设施加智能分析环境。它首先把全域数据集成到一个统一的数据层里，包括设备传感器数据、测试数据、良率数据、缺陷检测数据、生产执行数据，形成一套统一的数据模型；然后在这一层之上，提供工程分析、可视化和 AI 智能体的执行环境。

这和传统 BI 的区别很本质：BI 是给人看报表的，分析师得自己写 SQL、自己拖拽图表、自己解释结果；而 Aurora 的思路是把“看数据”变成“和 AI 一起用数据”。你想找出“哪个腔室的压力偏移和这次良率下降相关性最强”，传统做法是写几个脚本、跑相关性分析、再验证；在 Aurora 这类环境里，智能体可以自己拆解这个问题、拉取数据、跑分析、给出候选结论，并且把每一步的数据依据都留在报告里。

对我们搞工程的人来说，这种“数据底座＋AI 执行环境”的定位，最大的价值是终于不用在“先有数据平台”还是“先有 AI 能力”之间做选择题了。数据和智能体一起设计，AI 才不是在沙滩上建房，而是真正站在数据地基上干活。

2. PB 级数据能力，底层是怎么撑起来的

2.1 半导体数据到底从哪来：四类核心数据源

Aurora 能撑住 PB 级数据，得先想清楚一件事：这些数据从哪里来，有什么特点。半导体制造过程的数据源，我按工程视角分成四类。

第一类是设备时序数据。设备通过 SECS/GEM 协议上报过程数据，包括温度、压力、气体流量、射频功率、腔室状态、真空度、时间戳计数等等。这类数据的特点是频率高、维度多、数值波动大，是典型的时序数据。第二类是测试与量测数据，包括 WAT 参数（VT、RS、Ioff、Idsat 等）、CP 测试的 Bin 结果、缺陷扫描的坐标和分类、CD-SEM 的关键尺寸、Overlay 的套刻精度。这类数据的特点是和晶圆、批次的映射关系非常强，做分析时经常要按产品、批次、片号、Die 坐标做关联。第三类是生产执行数据，包括 MES 里的批次指令、设备历史、配方切换记录、操作员行为日志、派工规则等。这类数据解决的是“这批产品跑过哪些设备、用了哪个配方、经历了哪些工艺步骤”的溯源问题。第四类是良率与出货数据，包括最终良率、探针卡测试结果、封装测试数据，是工厂最关心的“结果指标”。

把四类数据汇到一起，你会发现问题不只是数据量大，而是数据形态完全不同。既有千万级维度的稀疏表，又有毫秒级采样的时序流，还有图片文件、事件日志、文本描述。想让一个平台承载所有类型，必须在底层存储和索引上做大量工作，这也是 Aurora 这类产品真正的技术壁垒所在。

2.2 关键的工程取舍：列式存储、分区裁剪、冷热分层

承载 PB 级数据，不可能指望一台机器硬扛，核心是架构设计。我挑几个关键的工程取舍讲一讲。

第一个是列式存储。分析型查询通常是“在某几个列上做聚合和筛选”，比如查某个产品线最近一周 Bin1 的比率变化。列式存储只读需要的几列，IO 量直接下降一个数量级。相比之下，传统行式数据库要读整行数据，在宽表场景下特别吃亏。

第二个是分区裁剪。半导体数据天然有时间和批次维度，按时间分区、按产品线分区，查询时只扫描命中的分区。比如你只查昨天到今天的 WAT 数据，系统就不会去扫三个月前的分区。这个道理看似简单，但很多传统系统在架构设计时没做这一步，等到数据量大了再改造就非常痛苦。

第三个是冷热分层。半导体行业有个特点，历史数据不是“没用”，而是“使用频率低、但关键时刻必须捞出来做回溯分析”。比如某个当年的热门产品出现特殊问题，可能要翻两年前的历史机台记录。冷热分层的做法近期数据放热存储，长期不用的数据转冷存储和压缩，但冷数据不是不能查，只是查询时略慢。这样既能控制成本，又能保证关键场景不会缺数据。

还有增量更新、CDC、事件驱动这些概念，本质都是让数据管道从“每天凌晨整批跑 ETL”变成“持续同步”。这对半导体的实时性要求很关键，设备工程师希望看到的是当前 15 分钟内的状态变化，而不是昨天的报表。

2.3 落到实际效果：回溯分析和查询体验的变化

这些工程细节听起来有点枯燥，我换个说法讲实际效果。我接触过一条先进封装产线，过去做良率回溯最痛苦的场景是“某个设备上个月换了 B 版硬件之后，良率有没有变化”。按老的做法，工程团队要导出设备变更记录、生产批次记录、测试结果，三个源拼一起，数据量超过五亿行，查询时长以小时计。很多团队就是等不住，最后凭记忆拍板。

用支持 PB 级数据的新平台后，这种查询基本可以秒级到分钟级返回，因为系统已经把设备变更、批次、测试数据统一建模，分区裁剪和列式存储让查询只碰必要的数据块。更重要的是，查询结果可以直接和智能体对话，让 AI 继续往下分析：“既然换硬件后良率下降了 0.8%，帮我看看是不是只影响某些产品线，影响的参数集中在哪些电性指标上。”

从“等几个小时拿到一张静态表”到“几分钟内完成多轮下钻分析”，这个体验差距，背过生产压力的人都懂。PB 级数据能力的价值，不是让报表显示快一点，而是让工程师敢去做以前根本不会去做的深度分析。

3. 智能体 AI 在半导体场景里的正确打开方式

3.1 智能体不是聊天机器人，而是一套“感知—推理—执行”闭环

现在到处都在说 AI 智能体，但很多人的理解还停留在“聊天机器人”上。在工业场景里，智能体远不止“对话”这么简单。我更喜欢把智能体理解成一套“感知—推理—执行”的闭环。

感知环节，智能体要能听懂工程问题，比如“最近三天哪台设备的腔室压力异常”。它需要理解“腔室压力”对应数据模型里的哪个字段、“异常”用什么标准判断、“最近三天”的时间窗口如何界定。推理环节，智能体要把大目标拆成小步骤：先查询设备列表、再拉时序数据、算统计量、做基线对比、找偏移点。执行环节，智能体要真正调用分析工具、跑模型、生成结果，而不是只会说“我建议你去看一下设备数据”。最后它把整个过程和结果整理成工程人员看得懂的报告，每一步都可以溯源。

这其实很像一个新来的工程分析助理，只不过它读数据的能力比人快很多。但关键在于，它做每一步前都需要数据底座支撑，所以智能体的“智力”很大程度取决于数据平台给它的“口粮”够不够好。

3.2 良率异常归因、设备预测维护、工艺推荐：三个最接地气的场景

智能体在半导体里最容易被想清楚的应用场景，我列三个。

第一个是良率异常归因。良率崩了是工厂最紧急的事，传统做法是老师傅凭经验猜，或者组织跨部门会议逐个排查。智能体可以做到的是收到一个任务，比如“Bin1 比率从周一开始升高 12%”，它会自动拉取相关产品线的批次、设备、参数、材料数据，跑一遍相关性分析，再看哪个机台的参数分布偏移最大，再检查是否是特定配方或特定批号引起，最后输出一个按怀疑度排序的候选根因清单，并且附上置信度和验证方法。这个流程过去要好几个小时的会议，现在能压缩到十几分钟内。

第二个是设备预测维护。设备异常往往不是突然发生，而是传感器数据先出现偏移。智能体可以持续监控关键设备腔室的压力、温度、RF 参数，和机台的基线做对比，一旦发现偏移趋势，就自动生成预警，并且推荐最适合的维护窗口。更进一步，它还能结合维修记录和备件库存，建议该换哪个零件、需要什么物料。这就是把“计划性维护”升级成“预测性维护”的关键路径。

第三个是工艺推荐与参数调试。当你面对一个新产品工艺开发任务，智能体可以拉历史 DOE 数据做分析，找出哪些参数组合在历史上更容易满足目标电性指标，再结合当前机台状态，给出一组初始参数建议。它不能替代工艺工程师做最终决策，但能把“从零试错”变成“从数据里找线索”，效率和成功率都会明显提升。

这三个场景，共同特征是都涉及多源数据、多步骤推理和结果验证。这些恰恰是智能体相比传统规则系统或者单点模型最有优势的地方。

3.3 智能体效果的天花板，取决于数据底座的质量

前面夸了智能体这么多，但有一条我必须提醒：智能体的效果瓶颈，绝大多数时候不是模型不够好，而是数据底座不够扎实。我见过不少团队兴致勃勃上了大模型，结果一问工程数据，智能体给出的字段名是错的、口径是混乱的、权限是一锅粥的，最后生成的报告看着漂亮，落地一验证全是错的。

为什么会这样？因为大模型本身不具备“看到真实数据”的能力，它依赖的是数据平台提供给它的语义层和查询接口。如果数据平台里的字段没有标准定义、指标口径没有统一、数据血缘没有建立，智能体就是在输入错误和噪声的基础上做推理，“Garbage in, garbage out”这句老话放在哪都适用。

所以我的观点特别明确：想用好 Aurora 这类平台上的 AI 智能体，第一优先级是把数据管好，包括字段命名规范、口径定义统一、数据质量规则、访问权限清晰。这些基础的功夫，比调模型参数重要得多。数据底座越扎实，智能体的表现越像“懂行的人”；数据底座一团糟，智能体只会把错误放大一百倍。

4. 从部署到落地：工程化接入的几条硬经验

4.1 数据集成方式：不是替换老系统，是做全域数据层

部署 Aurora 这类平台，很容易被误解成“要替换现有系统”。实际上正确理解是它做全域数据层，把老的 MES、设备采集软件、测试系统继续保留，数据通过工业标准接口汇聚到 Aurora 里统一存储和分析。用生活的说法，原来每个系统都是独立的仓库，Aurora 是在上面建了一个中心仓，老仓库依然有人在发货，但分析统一到中心仓做。

实际接入时，按数据优先级分几个阶段推进比较靠谱。第一批接的应该是良率数据和测试数据，因为它们和业务价值直接挂钩，变量也相对规整；第二批接设备传感器时序数据和 MES 数据，数据量最大，但分析收益同样明显；第三批再接图片、日志这类非结构化数据，等技术团队上手后再拿它练手。

每个阶段都要设定明确的验收指标，比如查询响应时间、数据同步延迟、数据质量通过率。不要试图“一口吃成胖子”。我见过一个工厂，第一周就想把 20 个系统一次性接完，结果一个月后还在调接口，业务部门已经完全失去耐心，这个项目最后烂尾了。嘴要小，才能吃得好。

4.2 权限模型与合规边界：AI 建议必须有据可查

半导体工厂的数据，很多是商业机密级的。设备参数、良率数据、工艺配方，泄露出去对企业竞争力影响很大。所以上智能体，权限模型必须在一开始就设计好，不能等出了问题再补。

具体来说，访问权限至少分几层。操作员和技术员，通常只看本区域的实时数据和基础报表；工艺工程师，只能访问自己负责的产品线和机台数据；IT 管理和数据平台团队，可以访问全量数据但通常只做平台运维；还有设备厂商远程支持，往往只能访问受限的诊断数据。这些权限不仅控制看哪些数据，也要控制智能体“能对哪些数据做分析”。你不能让一个负责封装的工程师通过智能体查光刻工艺的详细配方，哪怕智能体有这个能力，权限模型也要把它拦住。

另外智能体给出的任何建议，都要有数据血缘和操作日志。它说“机台 A 的压力异常”，你要能点开看到底是哪个时间段的哪个传感器数据支撑了这个结论；它推荐“某参数调整为 8.5”，你要能看到这个推荐是基于哪些历史数据计算出来的。这样即便 AI 犯错，工程人员也能快速发现并纠正，而不是稀里糊涂地采纳。

4.3 落地节奏建议：先试点后推广，别一开始就做全域大屏

讲到落地节奏，我的经验一直是“先试点后推广”。选试点的时候，最好是选一条产线或者一个产品系列团队，他们的问题够具体、数据闭环相对完整、价值也好衡量。试点目标不要定得太宏大，“良率根因定位时间缩短 50%”这种指标就很好，既有挑战性又可验收。

试点跑出成效后，再往设备预测维护、多厂区对比、供应商数据优化这些方向推广。每次推广都保留前一批的成功经验模板，包括数据接入模板、分析流程模板、智能体提示词模板，这样复制速度快，团队的学习曲线也平滑。

顺便泼一盆冷水：我不建议一开始就做所谓的全域智能决策大屏，那是典型的面子工程。把所有数据堆在一个大屏幕上，看着很震撼，但对工程师的实际帮助极其有限，还容易因为数据量复杂导致系统迟迟跑不起来、智能体效果遥遥无期。真正有效的路径永远是从一个小问题、一条产线开始，做出成绩，再逐步扩大范围。

5. 常见问题与避坑心得

5.1 我踩过的坑：数据膨胀、智能体幻觉、口径不一致

写这篇文章时，我把自己过去几年踩过的坑也整理了一下，值得单独说。

第一个坑是数据膨胀失控。时序数据没做采样和聚合策略，直接裸存原始值，存储成本一个月翻一倍，查询性能也明显下降。解决思路是定义分层存储策略：原始高频率数据保留最近 90 天，之后降采样到分钟级聚合，再往后的历史数据转冷存储。另外关键是要保留“异常标记”，工程回溯时能跳过热数据，直接查异常段。

第二个坑是智能体幻觉。它有时会一本正经地编造不存在的机台名或者字段名。我们的做法有三层：一是语义层白名单，智能体接触字段必须经过标准词汇表映射；二是每次查询限制扫描范围，强制加时间窗口和产品线条件；三是输出要求标注置信度和数据来源。这样即使模型偶尔犯傻，工程人员也能一眼看出来。

第三个坑是口径不一致。不同厂区的“良率”定义有细节差别，有的按晶圆数量做分母，有的按 Die 数量做分母。智能体如果不知道这些差异，算出来就是驴唇不对马嘴。我们最后靠统一度量层解决：在数据平台里把每个指标的标准口径固化成计算逻辑，智能体只能调用标准指标，不能自己乱定义。

5.2 把 Aurora 用好的五个操作习惯

再分享五个我个人认为对用好这类平台特别有帮助的操作习惯。

第一，定期巡检数据质量。给关键字段配置质量规则，比如缺失率、唯一性、取值范围，每天出报表，异常自动报警。AI 再聪明，数据缺失了它也补不回来。

第二，给智能体限定查询范围。不要让它默认全表查询，强制限定时间窗口、产品线、厂区范围，既提升响应速度，也减少出错的概率。

第三，关键字段加约束。唯一标识、外键关系、数据类型要在建模时定义清楚，避免到了分析层才发现字段没办法正确 join。

第四，训练数据和线上数据要对齐。智能体的推荐模型如果用几个月前的数据训练，而产线最近换了材料，结果必然失真。要定期用最新数据重新评估模型和基线。

第五，关键决策留人工审批环节。工艺参数修改、机台放行这种高风险动作，智能体只能给出建议和方案对比，最终确认必须由工程负责人签字，这个流程不能省，对人对事都是保护。

5.3 一张表总结：什么时候该上，什么时候该等

最后我做一张决策表，帮团队判断自己是不是该上 Aurora 这类平台。

维度	建议上	建议再等等
数据量	数据量已经到 TB 级甚至 PB 级，查询慢到影响决策	数据量还比较小，传统数据库还能撑两三年
数据基础	关键字段已标准化，跨系统联查是常态	各系统接口都没打通，数据还在 Excel 里流转
业务场景	有明确的 AI 应用场景，比如良率归因、设备预测维护	只是想“上个 AI 平台”，没有具体业务诉求
权限合规	对数据权限有清晰规划，有数据治理责任人	权限和合规没有方案，数据汇聚后会失控
组织意愿	有愿意扛 KPI 的试点负责人和工程团队	业务部门对 AI 无感，推动全靠 IT 一头热

我的判断逻辑其实很简单：技术平台永远是为业务问题服务的，想不清楚业务问题，再牛的底座也白搭。

6. 一点私人感受：平台发布之外，真正值得关注的事

结尾想写一点个人感想。我见过太多数据平台项目的失败案例，几乎没有哪个是因为技术不够好，基本都是业务场景没想清楚或者数据基础没打牢。Aurora 把 PB 级数据和智能体 AI 放在一起发布，给行业一个信号：半导体数据分析正在从“人看数据”走向“AI 帮你分析数据”。

但工具只是工具，真正决定价值的还是用它的人。如果团队能先把数据管好、把场景选对、把权限规范好，Aurora 会成为一根很值得信赖的杠杆；如果只是把它当一个新的数据库，期待它自动解决所有问题，那落差一定很大。我个人觉得，接下来一年值得密切关注的不是平台本身又有多少个新功能，而是有多少工厂能真正用这套东西缩短良率分析的时间、降低设备停机率。