先理解：这里到底在诊断什么？
Fab 是制造芯片的晶圆工厂。晶圆会反复经历沉积、光刻、刻蚀、清洗等加工，也不断接受检测和量测。当图像上出现异常、设备与参考表现不一致，或分析模型的表现下降，工程师需要回答：现象是什么，哪些解释值得查，下一步该做什么？
这个比喻中的“病例”就是待调查的工程问题。工程师是负责病例的人：知道工艺背景，提出目标，复核结果，并决定现场行动。AI 会诊助手组织分析与推理，科学工具和原始材料提供判断依据。
工程师使用一次，会经历什么？
先看一个概念场景：晶圆外圈出现较多候选对象。工程师打开图像和已有报告，想知道这个分布说明什么，以及下一步应查哪些条件。下面画的是使用过程，不是实际产品截图或已完成的现场诊断。
- 01
打开病例
图像、已有分析、可用工程记录
- 02
明确问题
AI 核对对象、范围和本次目标
- 03
取得依据
选择检查，调阅原值与方法
- 04
核查与判断
比较口径，保留冲突和缺口
- 05
形成建议
说明查什么、为什么、怎么验证
- 06
工程师复核
看原材料，决定行动与下一轮
交付目标是一份可复核的调查意见：把发现、候选解释、检查或调整建议、验证方式和证据缺口放在一起。有足够依据时，建议可以具体到需要核查的 Recipe 参数或腔室条件；尚未定位时，应明确下一项检查，不能凭空给出调参值。
看到了什么？哪些解释得到支持，哪些仍未排除？
下一步查什么？满足哪些条件后，可以检查或调整什么？
采用的方法、实际结果、来源和限制，逐项可查。
专家经验怎样帮助 AI，又给它留下判断空间？
一家专科中心会积累稳定的方法：处理这类病例，先确认哪些事实，什么检查适用，哪些结果不能直接比较，出现什么缺口时需要补证。WaferPilot 将经过审核的这类方法组织成有版本的 Expertise Package。
方法规定必须完成的专业责任、适用条件和证据要求。具体案例进入后，Agent 结合当前材料选择行动、提出候选解释、检查结果，再更新判断。模型可以运用知识与推理能力；涉及实际数据的主张仍要由可核查的材料支持。
明确问题
要回答哪些对象、量与关系？还有什么歧义？
确立依据
实际取得了什么？口径是否可比？还缺什么？
解释与限制
能回答哪部分？建议依据是什么？哪些仍未确定？
这些步骤称为 Rails。它们属于一类问题的专业方法；同类问题可以共用一套步骤。每个案例具体问什么、读什么、选择哪项检查，则根据当前问题和获准能力确定。不同任务可以使用不同的专业 Package。
图中的三个 Rails 以已有科学结果问答的目标设计为例；它们不是对所有设备诊断或新分析执行的完整流程定义。
白盒：每项意见背后，有什么可以检查？
想象会诊意见旁边附有完整病历：引用了哪份检查记录，指标如何定义，采用什么方法，结果支持了哪一步判断。工程师可以沿着这条记录回看原始材料，而不必只接受一句结论。
- 输入与范围
来自哪片晶圆、哪次运行、哪些工程条件？
- 专业方法
为什么选择这个检查？其适用条件是什么？
- 实际读算
读到了哪些原值？执行了什么计算与参数？
- 判断与限制
结果支持什么解释？还缺哪部分证据？
- 建议与复核
建议做什么、怎样验证，谁负责下一步？
“白盒”指这些决策与证据记录可见、可定位、可复核。它提供发现错误和修正判断的条件。材料带有指纹，可以核验版本是否一致；方法和数值的科学正确性，还需要相应验证。模型内部思维也不等同于这条可审查的证据记录。
展开一个真实口径示例：为什么两个面积不能直接互换？
样本报告同时记录全片已检面积和六段径向面积。它们都以 cm² 为单位，但定义与计算方式不同。准确的解释需要把两个数值连同各自定义一起取得。
| 报告中的量 | 原值 | 怎样定义 |
|---|---|---|
| 全片已检面积 | 678.7843 cm² | 已检站点数乘以 die 面积。 |
| 六段面积合计 | 676.154504 cm² | 记录的视场（FOV）并集与各环带求交面积之和，采用栅格近似。 |
这支持“口径不同，不能直接互换分母”的解释。单凭差值，不能认定算法错误、设备故障，也不能把差值全部归因于某一个几何因素。会诊助手应说明已知定义和仍未验证的部分。
这里的 561 个已检站点属于站点总体信息；若计算 objects/cm²，分母是相应的面积，不能把站点数与面积混用。标注对象也不自动等同于已确认缺陷。
再把熟悉的角色，对应到平台组件。
下面的名称只用于帮助理解分工。阅读时先记住每一层负责什么，再认识它在系统中的名字。
| 诊断中心的角色 | 平台中的对应 | 负责什么 |
|---|---|---|
| 待调查的病例 | 图像与工程背景 | 提供异常现象、实际条件与调查目标。 |
| 专科团队的方法 | Expertise Package | 沉淀审核过的方法、适用条件、例外和证据要求。 |
| 必须完成的会诊责任 | Rails | 稳定地明确问题、确立依据、解释有依据的部分与限制。 |
| 智能会诊助手 | Grounding Agent / LLM | 在专业方法与当前材料内推理，选择行动并提出判断。 |
| 会诊流程管理 | Kernel / Session | 管理合法行动、状态、已接受判断、执行记录与恢复。 |
| 检验科与专业工具 | Pipeline / Methods | 实际执行科学分析或获准的读算，并记录输入与结果。 |
| 有版本与口径的报告 | ELS / 科学语义声明 | 核验来源与发布版本，声明原值的单位、范围、方法和限制。 |
| 档案调阅中心 | Scientific RAG | 检索相关材料，精确调阅原值、定义和来源，组织证据。 |
| 负责病例的人与工作台 | 工程师 / ImageLens / Notebook / 报告 | 观察现象，复核分析，查看建议，决定现场验证与调整。 |
为什么还需要完整的平台与工作台？
工程调查需要把原始现象、计算过程和处理意见放在同一上下文中。像诊断中心的阅片台、检验记录与会诊报告一样，WaferPilot 的几个界面承担互相连接的工作。
ImageLens
看晶圆全貌、空间分布和局部图像，定位对应材料与发现。
Notebook
查看分析输入、方法、参数和结果，检查实际计算过程。
调查意见与报告
汇集候选解释、建议、验证方案和依据，供工程师复核。
平台的交付目标是支持工程判断和后续行动。可视化让现象容易看见，科学执行让分析有实际结果，证据记录让建议容易核查；这些能力共同支撑一个端到端的调查体验。
这个比喻，也有清楚的边界。
诊断意见可以包含下一步检查、补证和验证建议。有足够依据时，可以更具体地指出需要核查的参数、设备条件或模型环节；“有建议”并不意味着已经证明根因。
查询已发布的结果，与执行新的科学分析，是两个不同任务。调阅计划负责读哪些已有材料及获准计算；新分析还需要相应的方案、权限与执行流程。不能把“可以查询”展示成“已获准自动运行新 Pipeline”。
“智能诊断中心”是对工程平台组织方式的比喻。它不把模型当作无误的专家，也不靠保存记录来宣称结论正确。方法检验、实际证据和工程师复核，始终是判断可靠性的基础。
本文介绍架构原则与目标体验。具体已验证能力与试点范围，请参阅 当前演示与能力说明。