旗舰场景 报告文书 行业 · 半导体与电子信息

YE-01 · CP/FT 良率日报

与自家历史基线对比,异常bin 当天点名

痛点 日报天天都在出 · 但从来只报今天的数,没人对得上三周前的自己

① 场景引入

一、这件事现在是什么样

良率与测试工程 · 真实业务触发

每天早上八点半前要出昨日良率日报。九点晨会 PIE 要拿着它跟模块工程对质,客户稽核时它也是第一份被调阅的文件。会被追问:「你说这个 bin 高了,高多少算异常?跟谁比?」

二、痛点 · 每条都有来源

1良率日报的现状是从 MES 导产量、从质量系统导合格率、Excel 拼接,2-3 小时起步——分析十分钟,取数两小时依据 · 从业者描述良率日报现状:从 MES 导产量、从质量系统导合格率、Excel 拼接,2-3 小时起步20.5% 的良率波动没人在意,三天后跌到 92% 变成客户投诉——异常趋势从来不是没有数据,是没有基线可对依据 · 良率工程师从业者实录:一次 0.5% 良率波动的根因分析耗时两天,要跨 MES / EAP / 物料 / SPC 四个系统手工拉数3测试数据散在离线Excel 和私有数据库里,厂商明说这是数据孤岛,但买不起 YMS 的中小厂就是这么过的依据 · 国产 YMS 良率管理系统厂商对客户上线前状态的描述:良率周报每周手动汇总跨部门 Excel 台账、测试数据散在离线 Excel 与私有数据库、数据孤岛4同一个 bin 号在不同产品上的物理意义不一样,新工程师拿着 bin7 去问老工程师——bin 定义表在老工程师脑子里,不在任何系统里依据 · 良率工程师每天扫 Bin Map 是标准动作(另一位从业者实录)5管理层要 PPT、客户稽核要 PDF、工程师自己要 Excel,同一份数据出三种格式,每种都是手工重排依据 · 良率报告的三种真实形态:管理层调取 PPT、客户稽核要 PDF、工程师自己用 Excel 深挖根因(YMS 厂商文案)

三、换个做法之后

变化不在「快」,在「参与的角色」和「覆盖的范围」

✕ 现在的做法

  • 良率日报的现状是从 MES 导产量、从质量系统导合格率、Excel 拼接,2-3 小时起步——分析十分钟,取数两小时0.5% 的良率波动没人在意,三天后跌到 92% 变成客户投诉——异常趋势从来不是没有数据,是没有基线可对测试数据散在离线 Excel 和私有数据库里,厂商明说这是数据孤岛,但买不起 YMS 的中小厂就是这么过的同一个 bin号在不同产品上的物理意义不一样,新工程师拿着 bin7 去问老工程师——bin 定义表在老工程师脑子里,不在任何系统里

✓ 交给 Agent 之后

  • 多来源文件一次读入,先做口径与完整性校验,再开始算
  • 每条结论绑定来源文件、字段或条号,可以被审
  • 产出是企业真会流转的正式件(带签批栏),不是一张展示用的表
  • 该拦的地方给出「现在还不能提交」,并给不用干等的替代方案

四、场景闭环

5 步 · 每一步的产出都是下一步的输入

  1. 要素校验 · 判断今天的数能不能用逐台机、逐批次检查投测数量与合格数是否闭合;缺批次不阻塞,但标出影响范围
  2. 口径归一 · 折算到统一格式各机台 csv 的列名差异逐列映射:qty/quantity/n 均计投测数,折算依据写进日报附注
  3. 基线对比 · 与自家历史对齐同产品同机台近八周分布作对照带,超出对照带的 bin 逐个点名
  4. 异常识别 · Top fail bin 帕累托按 bin 出帕累托,标注哪个 bin 在涨、涨了几个批次、与基线差多少
  5. 成文与分发 ·生成可签核的日报Excel 版 + 晨会用的对比摘要;签核栏与数据来源附注一次生成

要准备什么:昨日各机台 bin 汇总(多个 csv,列名不统一)每台测试机各自导出,格式随厂家良率台账.xlsx(全厂批次历史)良率工程师手工维护,可能滞后bin 定义表(产品 × bin 号 × 失效模式)多半是老工程师手写的那份

为什么这个场景值得做

优先级评分:痛感 5 × AI 适配 4 ÷ 落地难度 2 = 12.0

最大差异点:不要求先上 MES/YMS、不要求统一 csv 格式。机台导出的 bin 汇总原件直接扔进来,列名不一致由

Agent 折算到同一口径,折算规则逐列写明。对比基线不是行业平均值,是本厂同产品同机台的历史分布——这一列数是客户自己的资产。

评分口径:痛感看「这事没做好谁会生气、生气到什么程度」;

AI 适配看「输入是否非结构化、是否要跨部门取数、错了能不能当场看出来」;

落地难度是分母 —— 需要客户先做数据治理的场景,分数会被压得很低。

五、会产出什么

判断标准只有一个:这份东西能不能直接进企业的流程

  • 正式件本体:良率日报.xlsx 含基线对比与签核栏
  • 可派发清单:异常bin清单.xlsx 可派发 · 每个 bin 带差值与历史出处
  • 可派发清单:机台数据待确认单.xlsx 数据质量存疑机台的单独说明

这套东西不承诺什么:不做测试判定与批次放行——合格与否是质量责任行为,日报只报事实与偏差,判定栏留给质量部签字。推荐处置意见栏一律留空。

② Live Demo(演示逐步)

演示模式 · 可视化预演 本页展示的是「应该怎么跑、每一步看什么、交付什么」,用的是真实业务格式的脱敏构造数据, 不宣称已接入客户生产系统,也不承诺任何效率提升百分比。

案例设定:穗芯电子封测事业部(东莞厂)2026-09-02 周三早 8:30 前要出 9-1 的 SC3021 良率日报;昨日 T2 机台三批bin7 偏高、T3 机台良率虚高待确认,九点晨会 PIE 要拿日报跟模块工程对质。

昨日投测(SC3021)5 批 · 42,846 颗bin7 越带3 批 · 帕累托 Top1 43.7%本批多损失214 颗 ≈ 3,500 元今日结论日报可出· T3 附页 · FT2638 升 RRA

输入半导体与电子信息企业手上能拿到的东西

不需要整理格式、不需要改文件名 · 直接拖进对话框

  • 01_T1机台bin汇总_20260901.xlsx 1 号测试机(T1)昨日 SC3021 两批的 bin 汇总,厂家 A 导出格式T1 机台自动导出 ·每日
  • 02_T2机台bin汇总_20260901.xlsx 2 号测试机(T2)昨日 SC3021 三批的 bin 汇总,厂家 B 导出格式——bin7 异常的三批都在这台T2 机台自动导出 · 每日
  • 03_T3机台bin汇总_20260901.xlsx 3 号测试机(T3)昨日 SC3018 两批的 bin 汇总,厂家 C 导出格式——良率 98.00% 偏高T3 机台自动导出 · 每日 · 导出工具 v2.3
  • 04_良率台账_近八周.xlsx SC3021 近八周周度台账与三起历史事件——基线对比的数据底座良率工程师手工维护 · 每周五更新
  • 05_bin定义表_陈工手写版.xlsx 产品 × bin 号 × 失效模式对照表(手写件转录)——bin7 在两颗产品上阈值不同资深 PIE 陈工手写(2024-06 原稿)·不转录就只存在他脑子里

注意标橙色那一份 —— 05_bin定义表_陈工手写版.xlsx。它资深 PIE 陈工手写(2024-06 原稿)· 不转录就只存在他脑子里,平时压根不在核对范围里。这个场景的价值,很大一部分就来自把它读进来。

提示词就说这么几句

没有模板、没有表单 · 专业规则由 Skill 兜底

把这三个文件里的昨日测试数据整理成良率日报,产品、批次、机台分开列。 每个 bin 的数要跟我们自己过去八周的水平比,超出的单独点名。 昨天 3 号机台的数据先别并进去,单独放一页,标注待设备确认。 判定栏留空,结论只写数据事实和对比结果。

短是因为折算规则和基线口径都写在能力包里了。你只需要说清要哪几份文件、跟谁比。

触发八点半前要出昨天的良率日报,九点晨会就要用

谁催、几点要交、会被追问什么

三台测试机的汇总今早才导齐。九点晨会 PIE 要拿这份日报跟模块工程对质,客户稽核时它也是第一份被调阅的文件。会被追问的仍是那句:「你说 bin7 高了,高多少算异常?跟谁比?」

第 1 步 · 要素校验 · 先判断今天的数能不能用

逐台机、逐批次检查投测与合格是否闭合;缺批次不阻塞,但标出影响范围

演示数据(表格原文)机台批次投测颗数合格颗数闭合校验判定T1FT2636 / FT263718,42017,768闭合可用T2FT2638 / FT2639 /FT264024,42623,079闭合可用 · bin7 待基线对比T3FT2521 / FT252215,14014,837闭合复测率 0 · 待设备确认合计7 批57,98655,684闭合T3 两批单独附页T3 数据闭合没问题,问题在别处:良率 98.00% 高于台账 SC3018 历史区间(96.5% 至97.2%),且复测记录为空——数据能用,但先不并入正文。

这一步的看点 · 该拦的地方拦住了台账 2026-06 有一模一样的先例:T3 测 SC3018 良率虚高至 97.8%、复测率 0,最后查实是测试程序版本回退、漏电阈值收紧项没生效,升版复测后回落 96.9%。本次结论:T3 两批数据先不并入汇报正文,先让设备确认测试程序版本。替代方案:用其余机台数据出报,T3 单独附一页待确认说明——晨会不等它。

第 2 步 · 口径归一 · 三台机三种列名折算到统一格式

列名差异逐列映射,折算依据写进日报附注

演示数据(表格原文)机台导出列名出现于统一口径折算依据qty / pass\_cntT1(厂家 A)投测数 / 合格数厂家 A 导出手册 v3 · 8-13 起换列头quantity / okT2(厂家 B)投测数 / 合格数厂家 B 导出口径,与 A 一一对应n / pT3(厂家 C)投测数 / 合格数导出工具v2.3 固定缩写bin7 / bin\_07 / f7三台各自bin7 漏电失效颗数bin 定义表逐条转录跨产品不折算绝对值:SC3018 的 bin7 阈值是 2.5μA、SC3021 是 1.8μA——本日报里 SC3018 只做纵向自比,不与 SC3021 的 bin7 横向比大小。

第 3 步 · 基线对比 · 与自家近八周对齐,越带的逐个点名

同产品同机台近八周分布作对照带,超出的单独点名

演示数据(表格原文)批次机台bin7 颗数bin7 占比八周基线对照带上限判定FT2636T1880.95%0.80%1.20%带内FT2637T1961.05%0.80%1.20%带内FT2638T22853.20%0.80%1.20%越带 2.0pp · 基线 4 倍FT2639T22192.80%0.80%1.20%越带1.6ppFT2640T21852.41%0.80%1.20%越带 1.2pp五批合计—8732.04%0.80%1.20%3 批越带 · 升级 RRA

这一步的看点 · 从历史里想起了公司踩过的坑台账 2026-05 那次 bin7 缓涨(0.8%→1.1%,三周),根因是南湾晶圆 CMP 边缘研磨漂移,换批后自愈,经手的 PIE 周工已经离职——这条不靠当年经手的人还在不在职。但方向不能想当然:八周序列每周只涨不到 0.01pp,照这个速率 40 多周才摸到带顶;FT2638 的 3.2% 是单批跳变,不是缓涨的延续——不能套「等换批自愈」的老经验,必须单独归因,这就是它升级 RRA 的理由。

第 4 步 · 异常识别 · Top fail bin 帕累托

按 bin 出帕累托,标注哪个在涨、涨了几个批次、与基线差多少

演示数据(表格原文)bin失效模式昨日颗数占比走势与依据bin7漏电失效87343.7%在涨 · 3 批越带 · 单批最高 3.2%bin9功能失效54227.1%持平 · 带内bin3开路32816.4%持平 · 近八周 37 批从未越带bin5参数超规25612.8%持平 · 带内合计—1,999100%—单看FT2638 一批:fail 575 颗里 bin7 占 285 颗(49.6%)——问题集中在漏电一项,不是全线漂移。

这一步的看点 · 排除性结论bin3(开路)可以排除——近八周 37 个批次从未越带,昨日 16.4% 与基线持平,不用启动针对测试接触问题的排查,省掉一轮。依据就在台账里:任何一个 bin 都能给出「越带/未越带 + 历史出处」,点名清单不是拍脑袋。

第 5 步 · 成文与分发 · 生成可签核的日报

Excel 正式件 + 晨会摘要;签核栏与数据来源附注一次生成

演示数据(表格原文)交付物形式接收人签核/状态良率日报(正式件)Excel · 含签核栏与来源附注PIE / 模块工程 / 质量部良率工程师起草· 质量部签核晨会对比摘要一页九点晨会 PIE随日报分发T3 待确认附页单独一页设备部待程序版本确认后回填异常bin 清单Excel · 每条带差值与历史出处模块工程派发后 48 小时内回复原因判定栏留空——合格与否是放行判定,落在质量部签字链上;日报只报事实与偏差。

这一步的看点 · 把技术动作翻译成钱bin7 漏电本批多损失 214 颗(285 颗 −基线预期 71 颗),按 12 寸单片产值 2.1 万、每片 1,284 颗折算,恰好等于一片晶圆的六分之一产值 ≈ 3,500 元——这是晨会上老板唯一会记住的那个数。注意口径:3,500 元是已发生的损失;在库三批 24,426 颗(约 39.9 万货值)的隔离与否,是 RRA 要回答的问题,不在日报里替质量部做决定。

日报可以出,但 T3 两批不并入、FT2638 当天升级 RRA数据闭合与口径归一全部通过,SC3021 五批 8:30 前可以出报;但两件事不能等:T3 机台复测率为零、良率高于自身历史区间,数据先不并入正文;FT2638 的 bin7 = 3.2%,是基线的4 倍、超对照带 2.0pp 的单批跳变,不能按「等换批自愈」的老经验处理,当天升级低良批次 RRA。方案一(推荐):日报按时出,T3 两批单独附「待确认页」派设备部核对程序版本——晨会照常有数可对;FT2638 的 214 颗 ≈ 3,500 元已发生损失写进头版,RRA 今天启动,在库三批约 39.9 万货值的隔离决策不被拖延。方案二:先对 T3 抽 500 颗复测(与 FT2629 留样同口径)确认程序无误后再出完整日报——日报顺延到上午 11 点,晨会没数可对;而 FT2638 的损失与隔离决策一天都不能等,等于拿 3,500 元的已发生损失和 39.9 万的风险敞口,去换一个「T3 数据好不好看」的确认。

之后这一次跑完,公司多了什么

不讲省了多久:讲少了几个隐患、沉淀了什么

  • ✓ 良率台账每天自动续一行,八周基线从「老工程师脑子里」变成可复算的数字
  • ✓ bin 定义表第一次被结构化——新工程师不用再追着人问 bin7 是什么
  • ✓ 三份机台 csv 的列名折算规则被固定下来,明天同一格式直接复用
  • ✓ 岗位角色变了:从「2 小时拼表」变成「看 10 分钟点名清单再决定追谁」

追问现场可能被问到的

答不上来的问题,比答得漂亮的问题更能决定这场演示的结果

  • 能不能直接告诉我哪个批次该拦? 不能。拦批次是放行判定,落在质量部签字链上。日报给你的是点名清单和依据。
  • 我们机台导出的格式每家都不一样,也能处理吗? 能。列名差异由折算规则吸收,规则随日报附注一起交,可以逐条核。
  • 没有历史台账怎么办? 那就没有基线可比——头两周只出事实层(数、bin 分布),第三周起才有对照带。我们会明说,不会拿行业平均数冒充你的基线。

③ 能力沉淀(Skill / 提示词 / 预期输出 / 人工边界)

1. Skill 能力包

导入之后,同类任务会自动按这套规则走 —— 提示词才能写得那么短

CP/FT 良率日报 —— 与自家历史基线对比,异常 bin 当天点名 · Skill

SKILL.md 主本 + references(输出骨架 / 判据 / 渲染脚本)· 符合 WorkBuddy Skill 规范

版本 v1.0

yield-daily-report.zip

在 WorkBuddy 里直接上传这个 zip 即可导入

包内结构

  • SKILL.md 主本 —— YAML 元信息 + 执行流程 + 硬规则 + 人工边界
  • references/output_template.md 输出骨架(sheet 名 / 分区顺序 / 列头)+ 可直接运行的渲染脚本
  • references/judgement_rules.md 判据与口径 —— 什么情况算异常、什么情况必须拦住

references 不会一次性全读进来 —— Agent 按需取用。所以 Skill 可以写得很细,不会拖慢每次对话。

2. 原始素材

这些就是半导体与电子信息企业手上真实能拿到的东西 —— 格式不统一是常态,不是问题

📁YE-01 · 演示素材

脱敏构造数据 · 真实业务格式 · 埋点可核验

共 5 份

  • 01_T1机台bin汇总_20260901.xlsx 1 号测试机(T1)昨日 SC3021 两批的 bin 汇总,厂家 A 导出格式
  • 02_T2机台bin汇总_20260901.xlsx 2 号测试机(T2)昨日 SC3021 三批的 bin 汇总,厂家 B 导出格式——bin7 异常的三批都在这台
  • 03_T3机台bin汇总_20260901.xlsx 3 号测试机(T3)昨日 SC3018 两批的 bin 汇总,厂家 C 导出格式——良率 98.00% 偏高
  • 04_良率台账_近八周.xlsx SC3021 近八周周度台账与三起历史事件——基线对比的数据底座
  • 05_bin定义表_陈工手写版.xlsx 产品 × bin 号 × 失效模式对照表(手写件转录)——bin7 在两颗产品上阈值不同

怎么用

  • 把素材全部拖进 WorkBuddy 对话框(不需要整理格式、不需要改文件名)
  • 粘贴下方提示词发送
  • 拿到正式件初稿 —— 签批栏留空,推荐意见留空,由你填

3. 提示词卡片

把这三个文件里的昨日测试数据整理成良率日报,产品、批次、机台分开列。 每个 bin 的数要跟我们自己过去八周的水平比,超出的单独点名。 昨天 3 号机台的数据先别并进去,单独放一页,标注待设备确认。 判定栏留空,结论只写数据事实和对比结果。

为什么这么短就够了:短是因为折算规则和基线口径都写在能力包里了。你只需要说清要哪几份文件、跟谁比。

换成你自己的业务:把素材换成你手上的真实文件即可。导入 Skill 之后,

该走几步、什么口径、什么情况必须拦住,Agent 自己知道 —— 你只需要说清这是什么事。

自己组织输入的三步法

  • 用自然语言说清核心需求 —— 就按平时跟同事交代活的方式说:什么事、什么文件、什么要求。不用讲究格式。
  • 调用 Skill 补齐专业规则 —— 导入本页 Skill 后,流程、口径、硬规则 Agent 自己知道。
  • 用「增强提示词」补全遗漏 —— 输入框旁边有增强按钮,把随口说的话补成更完整的表述。

分工:自然语言负责「这是什么事」,Skill 负责「该怎么做」,增强提示词负责「别漏了什么」。

4. 预期输出

不方便现场跑的时候可以直接拿这份给客户看 · 与实跑结果同结构

📋正式交付物

带签批栏 / 冻结首行 / 开筛选 —— 判断标准是「能不能直接进企业的流程」

共 3 份

  • YE-01_良率日报.xlsx 正式件本体 · 含基线对比与签核栏
  • YE-01_异常bin清单.xlsx 可派发 · 每个 bin 带差值与历史出处
  • YE-01_机台数据待确认单.xlsx 数据质量存疑机台的单独说明

Skill 里固化了什么:从历史里想起了公司踩过的坑该拦的地方拦住了排除性结论把技术动作翻译成钱

输入清单:昨日各机台 bin 汇总(多个 csv,列名不统一)每台测试机各自导出,格式随厂家良率台账.xlsx(全厂批次历史)良率工程师手工维护,可能滞后bin 定义表(产品 × bin 号 × 失效模式)多半是老工程师手写的那份

人工边界:不做测试判定与批次放行——合格与否是质量责任行为,日报只报事实与偏差,判定栏留给质量部签字。推荐处置意见栏一律留空。

升为客户真实案例还缺什么:客户当前真实输入文件(不要整理过的)岗位现行 SOP 与审批链(金额分档、谁签字)至少一次真实出过问题的案例客户当前正在用的正式输出模板客户确认的阈值口径(多少天算临期、多少金额算大额)

5. 同一角色下的其他场景

良率与测试工程 · 产出即下一步输入

上下游串起来就是完整链路。每一步的产出都是下一步的输入,不用在不同工具之间来回复制粘贴。

场景内容基于 WorkBuddy 产品能力整理,演示中的企业、人物与数据均为虚构,不代表任何客户的实际成效;痛点引用的公开来源已做脱敏处理。网页版由原资料转换,部分演示表格以原文形式展示。

想把这个场景在你们企业跑通?

顾问会先看你们的数据和流程够不够,再决定从哪一步开始。