第二章：需求分析与系统设计
说实话，很多做智能制造平台的人，一上来就急着写代码、搭框架。我见过太多这样的团队了——干了三个月，发现需求没对齐，推倒重来。嗯，这一章我们就聊聊怎么把地基打牢。
2.1 业务需求调研方法
做半导体MES这类系统，最怕的就是「我以为」。你以为产线需要A功能，结果人家要的是B。为什么会这样？因为你不懂现场。
我的调研三板斧：
- 跟线观察法：我习惯直接去产线待两天。看操作员怎么点屏幕、怎么扫码、怎么处理异常。你坐在办公室里永远想不到，一个简单的「批次拆分」操作，现场能搞出七八种花样。
- 角色访谈法：别只找经理聊。操作员、设备工程师、工艺工程师、生产计划员，每个人视角都不一样。我记得有一次，设备工程师随口说了句「每次recipe下载都要等5秒」，结果这就是EAP优化的关键点。
- 历史数据分析：翻翻过去三个月的生产报表、设备报警记录、良率数据。数据不会骗人，它会告诉你瓶颈在哪。
小技巧：调研时带个录音笔，回来整理成「需求卡片」。每张卡片写清楚：谁、在什么场景下、需要什么、为什么。这比写长篇文档管用多了。
2.2 功能模块划分
一个完整的半导体智能制造平台，核心模块就这几个。我按重要性排个序：
| 模块 | 全称 | 核心职责 | 我的经验 |
|---|---|---|---|
| MES | 制造执行系统 | 工单管理、批次追踪、物料管控 | 这是大脑，所有模块都围着它转 |
| EAP | 设备自动化平台 | 设备联机、recipe下发、数据采集 | 最容易出坑的模块，协议兼容性要命 |
| SPC | 统计过程控制 | 实时监控工艺参数、报警 | 别搞太复杂，先抓关键参数 |
| RMS | 配方管理系统 | recipe版本管理、权限控制 | 我曾经因为recipe版本搞混，报废了一批晶圆... |
| RMS | 报表与分析 | OEE、良率、产能分析 | 老板最爱看，但别做成数据垃圾场 |
模块之间怎么协作？我画了张图，你看一眼就明白了：
你看，MES是中心枢纽。EAP负责和设备打交道，SPC盯着工艺参数，RMS管配方版本。报表模块则从各个模块拉数据做分析。说白了，这就是一个「采集-控制-分析」的闭环。
2.3 系统架构设计
选微服务还是单体？这是个大问题。我直接说结论：
- 小厂/初创阶段：用单体架构。别折腾微服务，你连运维都搞不定。我见过一个10人团队搞了8个微服务，结果天天修服务间调用问题。
- 中大型产线：必须上微服务。因为MES、EAP、SPC的更新频率不一样。EAP可能每周都要适配新设备，而MES半年才发一次版。拆开才能独立迭代。
我的建议架构：核心业务（MES）用单体起步，外围模块（EAP、SPC）用独立服务。等系统跑顺了，再逐步拆分。这叫「演进式架构」，别一步到位。
2.4 技术选型
技术选型这事儿，说白了就是「够用就好」。我踩过的坑太多了，直接给你清单：
| 组件 | 推荐方案 | 理由 | 避坑 |
|---|---|---|---|
| 编程语言 | Java (Spring Boot) + Python | Java稳，适合核心业务；Python做数据分析快 | 别用C#，半导体设备厂商的SDK基本都是Java/C++ |
| 数据库 | PostgreSQL + Redis | PG支持JSON、时序数据；Redis做缓存和队列 | 别一上来就用Oracle，贵且没必要 |
| 消息队列 | RabbitMQ 或 Kafka | RabbitMQ适合EAP设备事件；Kafka适合SPC海量数据 | 我曾经用RabbitMQ扛SPC数据，结果队列积压到崩溃...后来换了Kafka |
| 前端 | Vue3 + Element Plus | 上手快，组件丰富，适合工业界面 | 别用React，招人难，而且工业UI不需要那么复杂的状态管理 |
重要提醒：技术选型一定要考虑「设备兼容性」。半导体设备厂商（比如ASML、TEL、Lam）的SECS/GEM协议实现千奇百怪。我建议EAP模块用Java，因为Java的SECS库最成熟。Python虽然写起来爽，但遇到协议兼容问题你会想哭。
2.5 数据流设计
数据怎么流？我画个简单的：
设备 → EAP（采集原始数据） → 消息队列（Kafka）
↓
SPC（实时计算，报警） → 数据库（PostgreSQL）
↓
MES（更新批次状态） → 报表（定时聚合）
↓
RMS（recipe版本校验） → 设备（下发参数）这个流程我优化过很多次。核心原则就一条：数据采集和业务处理解耦。EAP只管收数据，别让它干MES的活。我曾经见过一个项目，EAP里写了批次状态更新逻辑，结果设备一换，整个产线停了...
2.6 需求文档怎么写
最后聊聊文档。很多工程师讨厌写文档，但半导体行业不行——设备验证、GMP合规、客户审计，哪样都离不开文档。
我的文档模板：
- 用户故事：作为操作员，我希望扫码后自动显示当前批次信息，以便减少手动输入错误。
- 验收标准：扫码后2秒内显示信息；支持模糊搜索；错误率低于0.1%。
- 技术约束：必须支持SECS/GEM协议；数据库响应时间<100ms。
避坑指南：我曾经因为需求文档里没写「设备断线重连」的逻辑，上线第一天就出了事故。现在我的文档里一定会加「异常场景」章节，专门写网络中断、设备宕机、数据重复这些情况。
好了，需求分析和系统设计这块，核心就是这些。记住一句话：调研要深、设计要稳、选型要准。别急着写代码，先把这些想清楚，后面能省你80%的返工时间。
公众号:蓝海资料掘金营，微信deep3321