【摘要】
"我要自动良率预警"。这句话听起来是一个需求，实际上是一个空壳：没有对象、没有判据、没有时效、没有处置、没有责任人。你按它做，做完一定返工；你按它报价，报完一定亏。
FDE 在这个环节干的活不是"记录需求"，是把它拆成对方能拍板的决策点。这篇给一套六问拆解、一张一页纸需求卡，目标是第二次会议结束时，客户已经能对三个问题给出明确答案：谁来判、判错了谁担、多快算合格。
【核心要点】
- 口号式需求必须拆到「对象 + 判据 + 时效 + 处置 + 责任」五要素齐全，才算需求
- 三种需求说法里只有指标式能进验收条款；口号式只能进愿景章节
- 六问顺序不能变：先定对象，再定判据，判据定了才谈时效
- 收敛的产出物不是文档，是一页纸需求卡，其中客户要签字的只有半页
- 报价前必须锁三件事：数据可得性、判定规则归属、误报责任
- 拆不动的需求不是丢掉，是进挂起池，写清解锁条件
---
一、这句话里缺的不是细节，是判断
"自动良率预警"背后藏着五个隐含假设。FDE 要做的是逐个把它们翻出来，而不是急着问"你要什么图表"。
| 隐含假设 | 现场真相 | 必须先确认 |
|---|---|---|
| 良率掉了，系统立刻知道 | 良率要等量测 + CP/FT 回来才有数，12 寸某些层次滞后 3–7 天 | 预警对象是过程指标，还是最终良率 |
| 异常有明确判据 | 良率掉 2% 是异常还是正常波动，客户自己也没定义 | 管制界限谁来定、依据什么 |
| 预警了有人管 | PE 本来就在手工看数据，只是看得慢 | 预警的价值是提前量，不是"发现" |
| 数据都在系统里 | 量测在 EDC、缺陷在缺陷管理系统、WAT 在另一套库 | 数据在哪、字段全不全、能不能实时取 |
| 误报可以忍 | 一天 200 条误报，一周之后没人打开 | 误报率上限、调优次数上限 |
这五行不问清，最后交付出来的东西一定长成这样：一个大屏，上面转着一堆没人看的图。
二、三种需求说法，只有一种能验收
| 类型 | 客户原话 | 能写成什么 | 能不能验收 |
|---|---|---|---|
| 口号式 | "我要自动良率预警" | 只有愿景章节 | 不能 |
| 场景式 | "ET2 刻蚀后 CD 偏 3nm 以上，下一批进站前要通知到 PE" | 功能清单 | 可做 FAT |
| 指标式 | "漏报 <5%、日均误报 <10 条、量测完成到通知 <15 分钟" | 验收条款 | 可做 UAT |
FDE 的活是把第一句翻译成第二句，再和客户一起把第二句量化到第三句。
翻译这一步不能外包给客户。客户写出来的东西一定长成采购文件的样子——"支持多维度分析""具备良好扩展性"，这种话进合同，验收时双方都是输家。
三、六问拆解（顺序不能换）
第一问：对象。 哪条线、哪个站、哪个产品族、哪台机。答"全厂"就是还没想清楚。
第二问：现象与现状。 现在靠谁发现、多久发现一次、发现之后做什么。产出是基线——没有基线，后面所有"效率提升 XX%"都是编的。
第三问：判据。 规则从哪来：SPC 管制线、历史分布、还是 PE 的经验阈值。经验阈值最麻烦——PE 能判断，但说不出边界。这种情况改用分布做偏离检测，先不追求"判定异常"，只做"偏离基线排序"。这一条能救掉大量做不下去的项目。
第四问：时效。 15 分钟和 4 小时是两个完全不同的架构：前者要事件驱动 + 消息推送，后者定时批处理就够。很多项目成本翻倍，就翻在这一问上。
第五问：处置。 收到预警的人要做什么：复查、开 Hold 单、调 Recipe、还是通知设备。如果答案是"知道了就行"，这需求该降级成报表，不该做成预警。
第六问：责任。 误报谁担、漏报谁担。这一问答不清楚，签合同时会很难看。
四、一个真实拆解：八寸厂 ET2 刻蚀
背景：8 寸厂，ET2 刻蚀，CD 量测走 CD-SEM，量测数据进 EDC，SPC 有管制图但 OOS 只发邮件给 PE 主管。客户原话："我们要自动良率预警，最好大屏上能看到。"
Day 1｜跟班：不访谈，站在 PE 旁边看他干什么。发现每天 9:00 手工拉 EDC 做透视，1.5 小时。这就是基线。
Day 2｜摸数据：CD 有值，但 Recipe 版本号字段为空。这意味着判据无法绑定 Recipe——不同 Recipe 的 CD 目标值差 20nm，不绑定版本，判据全是错的。这一个发现改变了整个方案。
Day 3｜对判据：PE 给的阈值是经验值，写不成规则。改方案：用近 90 天同 Recipe 同层次的分布，做偏离度排序，SPC 管制线作为硬阈值。
Day 4｜定范围：V1 只做 ET2 的 CD 一项，交付三样东西。
| 交付物 | 内容 | 验收指标 |
|---|---|---|
| 异常清单 | 每天 8:30 出，按偏离度排序，带 wafer / Recipe / 机台 | 覆盖率 100%，字段无空 |
| 实时告警 | 超硬阈值 15 分钟内推送到 PE 企微 | 从量测完成到送达中位 <15 分钟 |
| 处置留痕 | PE 点确认 / 忽略 / 开 Hold 单 | 抽样 20 条，留痕率 100% |
明确不做：不做良率预测，V1 不做大屏。理由要能当面讲：大屏不改变任何人的行为，只改变谁来看。V1 的验收指标是"PE 早上 1.5 小时的活变成 10 分钟复核"——行为改变，能量化，能签字。
五、一页纸需求卡
收敛的产出物就是这一张，超过一页说明还没收敛完。
| 字段 | 填写要求 |
|---|---|
| 需求编号 / 一句话描述 | 一句话说完，不许出现"智能""自动"这种形容词 |
| 对象 | 线别 + 站别 + 产品族 + 机台范围 |
| 判据 | 规则来源 + 阈值 + 谁维护 |
| 时效 | 数据产生到送达的时间上限 |
| 处置 | 谁、做什么动作、留什么痕 |
| 责任人 | 客户侧业务 owner（不是 IT） |
| 数据来源 | 系统 + 表 + 字段 + 更新频率 |
| 验收指标 | 可测量，含基线与目标 |
| V1 范围 / 不做清单 | 两者必须同时写，只写范围不算收敛 |
| 待确认项 | 每条带责任人和截止日 |
"不做清单"这一栏最容易被省略，但它才是防返工的护栏。口头说的"这个先不做"，三个月后一定变成"当时不是说好了吗"。
六、报价前必须锁死的三件事
1. 数据可得性。 字段有没有、准不准、能不能实时取。锁不住就在方案里写"以数据可用性为前提"，并附数据核查清单。ET2 那个空的 Recipe 版本号，就是典型的"报价时以为有，实施时才发现没有"。
2. 判定规则归属。 规则是客户的工艺 IP，还是我们的产品能力？正确切法是：规则由客户提供并签字确认，我们只做执行引擎和规则管理工具。这条不锁，后面规则不准，全部算成你的系统不准。
3. 误报责任。 预警类需求最容易死在"误报太多"。合同里写两个数：误报率上限、调优次数上限（比如上线后 3 次免费调优，超出按人天计）。这不是推责任，是把"预警系统需要调"这个事实提前变成共识。
七、拆不动的需求进挂起池
总有一部分需求当场拆不动：判据没有、数据没权限、预算没批。处理方式不是硬拆，也不是拒绝，是进挂起池，每条写三样：卡在哪、解锁条件（谁在什么时间点提供什么）、解锁后谁跟进。
它的作用是把"客户觉得你不理他"变成"客户知道卡在谁那里"——很多矛盾不是需求没做，是客户不知道进度。
八、可复用点
- 客户的口号和可验收需求之间，差六个问题，不是差一份文档。
- 先定对象再定判据。顺序反了，会做出一个"什么都能预警"的系统。
- 判据客户给不出时，用分布代替规则，先做偏离检测——这一步能救活一半做不下去的预警项目。
- V1 的范围用一个可量化的行为改变来界定（1.5 小时 →10 分钟），比功能清单有说服力。
- 预警类需求，合同必须写误报率与调优次数，否则验收必然扯皮。
下一篇讲分级：同一个客户会在同一张纸上写下 20 条需求，真正该进 V1 的不超过 5 条。怎么判断是哪 5 条，怎么把另外 15 条讲成客户能接受的"不做"。