【摘要】
PRD 写粗了，开发全程靠猜，猜错的部分在联调时变成返工；写细了，三百页没人看，客户签字的人都读不完。这个问题在 Fab 里比在互联网里尖锐得多——因为 Fab 的流程状态多、异常分支多、还有一堆单位与精度问题，猜错的空间特别大。
颗粒度的分界线不在字数，在三样东西上：状态机有没有画全、异常分支有没有穷举、字段约束有没有落到类型和单位。这三样齐了，剩下的篇幅可以很克制；这三样缺一样，写多少页都是无效文档。
【核心要点】
- 颗粒度的合格线只有一条：开发不需要再来问你"这里出现 X 怎么办"
- Fab 里一半的功能本质是状态流转，先画状态机再写功能描述，顺序反了必漏分支
- 正常流只有一条，异常流通常有八到十条——异常分支的密度才是文档质量
- 字段约束要写到类型、单位、精度、时区、枚举全集，Fab 里最容易出事的五个字段有固定名单
- 界面样式、数据库设计、算法实现不写进 PRD：写接口契约和结果定义
- 每条需求自带验收条款，"做完了"的标准在写文档时就要定，不能等验收时再谈
---
一、合格线：开发不再来问你
判断一篇 PRD 合不合格，不用审内容，数问题就行。开发在实现期间来找你确认的每个问题，都是文档欠的债。
三类问题对应三种欠账：
| 开发问的问题 | 文档缺的东西 | 典型后果 |
|---|---|---|
| "设备断连时这个界面显示什么？" | 异常分支 | 上线后界面白屏，被当成系统故障上报 |
| "Lot 数量是小数还是整数？单位是片还是 lot？" | 字段约束 | 数量字段存了 0.5 片，对账对不上 |
| "批次的两个状态同时成立时听谁的？" | 状态机 | 状态互相覆盖，追溯链断裂 |
注意一个陷阱：开发不问你，不代表文档合格——可能他自己替你做了决定。三个月后出问题追溯时，你会发现某段行为的"设计依据"是开发当时随手写的一行注释。所以自检不能只数问题，还要抽查：挑三个功能问开发"这个异常分支为什么这么处理"，他答"我猜的"，就是文档问题。
二、先画状态机，再写功能
Fab 里一半以上的功能本质是状态流转：Lot 在跑、Hold、排队、报废；设备在 Run、Down、PM、Engineering；单据从创建、审核、执行到关闭。功能描述写得再顺，不如先把状态图画对。
写状态机只需要两样东西：全部状态 + 全部合法迁移。非法迁移比合法迁移更重要——"哪些状态之间不允许直接跳"是开发最容易做错的地方。比如 Lot 从 Run 状态能否直接改 Scrap？按很多厂规，必须先经过 Hold。这句话如果不在文档里，开发就会做成"下拉框随便选"。
Fab 场景的状态机有三个必答题，写文档时逐个过：
- 并发互斥：两个状态条件同时成立，听谁的？（设备既报缺料又报告警）
- 回退路径：每个状态能不能退回上一个？谁来退、要不要审批？
- 终止态全集：哪些是终态？进了终态还能不能改？（报废的 Lot 能否重新投产——这个问题的答案因厂而异，必须客户给）
画完状态机，功能描述降级为"对迁移的补充说明"。这个顺序写出来的文档，开发拿着就能干。
三、异常分支：正常流一条，异常流十条
写文档的本能是顺着正常流写：登录 → 选批次 → 录入数据 → 提交 → 成功。这条线一天就能写完，但它只覆盖实际运行时间的两成。
Fab 系统的异常分支有固定的高发区，逐个过一遍，漏不了几个：
- 数据缺失：上游没传过来的字段，界面显示什么？拦住还是放行？
- 设备断连：EAP 掉线期间的数据是补传还是丢弃？补传的时间戳用哪个？
- 重复提交：网络抖动导致双重提交，幂等怎么做？
- 权限不足：有查看权没有编辑权的人打开编辑页，是隐藏按钮还是置灰+提示？
- 超时：操作半天没响应，用户再点一次会发生什么？
- 半途取消：流程走到一半用户关页面，已写入的数据回滚还是留半截？
- 并发冲突：两个人同时编辑同一条记录，后保存的覆盖还是提示冲突？
- 边界值：批次刚好 0 片、刚好满量、刚好跨班次，怎么算？
这八条不是Fab 特有的技巧，是所有事务型系统的通用清单。但 Fab 的特点是：每一条的答案都可能被厂规改写（比如"半途取消必须留半截，因为工艺日志不许删"），所以你不能套用默认答案，必须逐条问客户、逐条落进文档。
一个实用的做法：每个功能页配一张"异常分支表"，三列——触发条件、系统行为、用户看到什么。二十行的表，能省掉联调期一半的来回。
四、字段约束：最容易出事的五个字段
字段约束写到什么程度？标准是：开发拿着它能建表、能写校验、能做界面提示，不需要再问。
Fab 里最容易出事的是这五个：
- 时间戳。必须写明时区（ fab 本地？UTC？）、精度（秒还是毫秒）、以及"业务时间 vs 记录时间"是不是两个字段。跨班次报表的对不上账，八成是这里埋的雷。
- 数量与单位。片、lot、箱、盒，哪一级是系统存储单位？显示单位谁负责换算？小数位允许几位？损耗率的分母是什么？
- 枚举值全集。"设备状态"有哪几种合法取值？新增一个值要走什么流程？枚举不封口，开发就会用字符串存状态，半年后报表分组出乱码。
- 精度与舍入。良率 99.987% 存几位、显示几位、四舍还是五入？不要觉得这是小事——良率差 0.01 个点，客户的质量会议就要开一下午。
- 主键与唯一性。什么字段保证一条记录不重复？LotID 在换批重投后会不会复用？这个答案直接决定追溯系统能不能建。
字段表建议固定格式：字段名、类型、单位、精度、必填、默认值、校验规则、来源、谁有权改。九列，一行一个字段，看着枯燥，但它是最不容易出事的部分——因为一切都白纸黑字。
五、不写进 PRD 的东西
颗粒度还有一个方向：有些东西写了反而有害。
- 界面样式不写死。写"数据表格，支持按列排序"就够了，别画像素级的图。你画得越具体，改一版成本的争议越大。例外：影响操作安全的界面（权限入口、删除按钮位置）要写死。
- 数据库设计不规定。分表还是分库是开发的事，PRD 只规定查询性能指标（如"任一批次追溯查询 ≤3 秒"）。
- 算法实现不规定。写"排产建议按交付日期优先、换线次数最少"这个结果契约，别写遗传算法的参数。写死了，开发没法用更好的实现，你也背上了维护算法说明书的义务。
判断标准一句话：PRD 定义"是什么、对不对"，不定义"怎么做"。越过这条线的内容，放设计文档，不放需求文档。
六、每条需求自带验收条款
PRD 和验收标准分成两份文档，是返工的另一个来源——验收时才讨论"做完了"的标准，等于给双方都留了扯皮空间。
正确做法：每条需求的末尾跟一行验收条款，当场写。格式很简单：
需求：异常批次自动推送看板。
验收：模拟 3 个异常批次，10 秒内出现在对应工程师的看板，且包含批次号、机台、异常码三个字段；误推为 0。
写验收条款时会逼出大量隐藏分歧——客户心里想的是"所有异常"，你理解的是"三类已定义异常"，这个分歧在写验收条款的十分钟暴露，成本是改一行字；在验收那天暴露，成本是加一个月工期。
七、可复用点
- 颗粒度合格线：开发不再来问"这里出现 X 怎么办"。数问题就是数文档的债。
- 先画状态机再写功能。非法迁移（哪些状态不许跳）比合法迁移更重要。
- 异常分支有固定八条清单：缺数据、断连、重复提交、权限、超时、半途取消、并发、边界值。逐条过，逐条问厂规。
- 字段约束写到类型、单位、精度、时区、枚举全集。Fab 五大雷区：时间戳、数量单位、枚举、舍入、主键。
- 界面、数据库、算法不写死——PRD 定义"是什么"，不定义"怎么做"。
- 验收条款跟着需求当场写。分歧早十分钟暴露，成本差一个量级。
下一篇讲需求变更管理：项目过半客户要加一个字段，为什么这个字段敢报八万——数字怎么算出来的，怎么让客户认这个账。