EAP 工程师的职业素养为什么你写的代码PE 一眼就觉得不靠谱摘要在 Fab 里EAP 工程师的技术水平往往不是由 HSMS 是否连通、S6F11 是否发出去来定义的而是由 PEProcess Engineer的信任度来衡量的。本文总结了 5 个让 PE 瞬间觉得你不专业的瞬间并给出从能用到可信的进化路径。全是工程实践中的血泪教训没有教科书式的废话。一、前言PE 的眼神不会骗人刚入行时我觉得 EAP 工程师的价值在于把接口打通。直到在一次 FAT 会议上我自信满满地演示完流程PE 只问了一句“你确定这代码能在量产跑吗”那一刻我从他的眼神里看到了怀疑。后来我才明白EAP 工程师写的不是代码是 PE 对自动化系统的信心。如果你的代码充满了侥幸心理和临时方案PE 一眼就能看出来。以下是 5 个最典型的不专业瞬间看看你中了几个。二、瞬间一迷信接口通了1. 现象HSMS 连上了S6F11 发出了Host 收到了你拍胸脯说“Done.”你觉得大功告成接口通了就是胜利。2. PE 的视角PE 心里想的是“这叫’能用’不叫’好用’。”在 Fab 里接口通了只是 1% 的工作。剩下的 99% 在于时间是否对齐E148状态机是否严谨E87/E90异常是否全覆盖3. 不专业的本质用连通性代替正确性。你只验证了 Happy Path正常路径却没有验证 Sad Path异常路径。4. 正确的素养通了只是开始可信才是结束。在见 PE 之前你必须自己先把 PLC 日志对完把时间戳对齐把异常场景跑一遍。不要让 PE 帮你找 Bug你要告诉他“我试过了断网、试过了脏数据、试过了并发都没问题。”三、瞬间二滥用sleep(1)1. 现象Robot 移动需要 2 秒你写time.sleep(2)。工艺需要 30 秒你写time.sleep(30)。代码跑起来了你觉得逻辑闭环了。2. PE 的视角PE 心里想的是“这是在赌运气。”sleep是最脆弱的等待方式。如果Robot 卡住了2 秒没到位怎么办工艺腔体报警30 秒没结束怎么办你的程序会傻等然后超时然后报错甚至撞片。3. 不专业的本质用时间驱动代替事件驱动。你假设了外部环境永远准时但 Fab 里唯一不变的就是变化。4. 正确的素养用状态机驱动不要用时间驱动。等待 PLC 的In_Position信号而不是等待墙上的钟表。错误示例 move_wafer()time.sleep(2)# 赌 Robot 2 秒内到位report_done()正确示例 move_wafer()wait_for_signal(ROBOT_IN_POSITION,timeout5)# 等信号最多等 5 秒ifsignal_received:report_done()else:report_timeout_error()# 超时也是一种明确的异常四、瞬间三吞掉异常Silent Fail1. 现象Robot Pick 失败了真空传感器没信号。为了不让 Host 报错你不报 S6F11或者回一个ACK(Accepted)假装成功。2. PE 的视角PE 心里想的是“这是欺诈。”你掩盖了问题让 Host 以为晶圆还在 Robot 上下一秒 Host 下发 Place 指令晶圆直接掉落在地或者撞在腔体上。掩盖错误比错误本身更可怕。3. 不专业的本质为了流程好看牺牲数据真实。你害怕报错害怕打断流程所以选择了欺骗系统。4. 正确的素养异常必须上报哪怕会炸。上报REJECTED上报LOST让 PE 知道出问题了。S6F11 SubstrateStateChanged SUBSTID: WAFER001 STATE: REJECTED ← 明确告诉 Host失败了 REASON: Vacuum Sensor Not DetectedPE 宁愿看到一个明确的REJECTED也不愿看到一个虚假的COMPLETED。因为前者可以止损后者只能报废。五、瞬间四不考虑并发Single Thread Mindset1. 现象你假设 Host 会按顺序发指令先 Load再 Process再 Unload。你写的代码是线性的没有锁没有队列。2. PE 的视角PE 心里想的是“这代码经不起折腾。”现实中Host 会并发发指令在 Robot 移动时Host 可能会发S1F3 Status Request。在 Process 运行时Host 可能会发S2F41 Pause。你的线性代码会死锁、会丢事件、会状态混乱。3. 不专业的本质用理想环境代替真实环境。你假设了 Host 永远绅士但 Host 其实是个暴躁的并发机器。4. 正确的素养假设最坏的情况一定会发生。你的代码必须能处理插队、超时、重入使用消息队列Queue处理 Host 指令。使用互斥锁Mutex保护共享资源。在任何状态跳转时检查当前状态是否允许该操作。六、瞬间五没有可观测性1. 现象出了问题你只能说“我看日志好像是……下午三点左右。”PE 问你具体时间、具体信号、具体状态你答不上来。2. PE 的视角PE 心里想的是“这不叫调试这叫算命。”在 Fab 里时间是金钱晶圆是生命。没有精确的日志就无法回溯事故。3. 不专业的本质日志是给人看的不是给机器看的。你的日志充满了INFO: Task started、DEBUG: Variable changed但没有关键信息。4. 正确的素养日志即证据。每一条日志都要包含硬件时间戳E148 格式物理信号状态PLC IO 的值逻辑状态EAP 内部状态机错误的日志 [14:32:15] INFO: Robot pick finished. 正确的日志 [2026-08-04T14:32:15.123Z] EVENT: S6F11 SubstrateLocationChanged SUBSTID: WAFER001 FROM: LP1_SLOT01 TO: ROBOT_ARM1 PLC_VACUUM: TRUE ← 硬件信号背书 E148_ACCURACY: ±10ms七、总结信任是最贵的资产写 EAP 代码不是写给编译器看的是写给 PE 看的更是写给未来的自己看的。当你拔掉网线、注入脏数据、制造异常时如果你的代码还能优雅地报错、准确地回溯PE 才会真正尊重你。因为你知道晶圆很贵不能用sleep来赌。信任更贵不能用掩盖错误来维持。愿你的代码里没有sleep(1)愿你的日志里全是证据愿你的 PE 看你的眼神里全是信任。你在工作中遇到过哪些不专业的 EAP 代码或者你有哪些职业素养想分享欢迎在评论区一起交流。 EAP 工程师的职业素养为什么你写的代码PE 一眼就觉得不靠谱摘要在 Fab 里EAP 工程师的技术水平往往不是由 HSMS 是否连通、S6F11 是否发出去来定义的而是由 PEProcess Engineer的信任度来衡量的。本文总结了 5 个让 PE 瞬间觉得你不专业的瞬间并给出从能用到可信的进化路径。全是工程实践中的血泪教训没有教科书式的废话。一、前言PE 的眼神不会骗人刚入行时我觉得 EAP 工程师的价值在于把接口打通。直到在一次 FAT 会议上我自信满满地演示完流程PE 只问了一句“你确定这代码能在量产跑吗”那一刻我从他的眼神里看到了怀疑。后来我才明白EAP 工程师写的不是代码是 PE 对自动化系统的信心。如果你的代码充满了侥幸心理和临时方案PE 一眼就能看出来。以下是 5 个最典型的不专业瞬间看看你中了几个。二、瞬间一迷信接口通了1. 现象HSMS 连上了S6F11 发出了Host 收到了你拍胸脯说“Done.”你觉得大功告成接口通了就是胜利。2. PE 的视角PE 心里想的是“这叫’能用’不叫’好用’。”在 Fab 里接口通了只是 1% 的工作。剩下的 99% 在于时间是否对齐E148状态机是否严谨E87/E90异常是否全覆盖3. 不专业的本质用连通性代替正确性。你只验证了 Happy Path正常路径却没有验证 Sad Path异常路径。4. 正确的素养通了只是开始可信才是结束。在见 PE 之前你必须自己先把 PLC 日志对完把时间戳对齐把异常场景跑一遍。不要让 PE 帮你找 Bug你要告诉他“我试过了断网、试过了脏数据、试过了并发都没问题。”三、瞬间二滥用sleep(1)1. 现象Robot 移动需要 2 秒你写time.sleep(2)。工艺需要 30 秒你写time.sleep(30)。代码跑起来了你觉得逻辑闭环了。2. PE 的视角PE 心里想的是“这是在赌运气。”sleep是最脆弱的等待方式。如果Robot 卡住了2 秒没到位怎么办工艺腔体报警30 秒没结束怎么办你的程序会傻等然后超时然后报错甚至撞片。3. 不专业的本质用时间驱动代替事件驱动。你假设了外部环境永远准时但 Fab 里唯一不变的就是变化。4. 正确的素养用状态机驱动不要用时间驱动。等待 PLC 的In_Position信号而不是等待墙上的钟表。错误示例 move_wafer()time.sleep(2)# 赌 Robot 2 秒内到位report_done()正确示例 move_wafer()wait_for_signal(ROBOT_IN_POSITION,timeout5)# 等信号最多等 5 秒ifsignal_received:report_done()else:report_timeout_error()# 超时也是一种明确的异常四、瞬间三吞掉异常Silent Fail1. 现象Robot Pick 失败了真空传感器没信号。为了不让 Host 报错你不报 S6F11或者回一个ACK(Accepted)假装成功。2. PE 的视角PE 心里想的是“这是欺诈。”你掩盖了问题让 Host 以为晶圆还在 Robot 上下一秒 Host 下发 Place 指令晶圆直接掉落在地或者撞在腔体上。掩盖错误比错误本身更可怕。3. 不专业的本质为了流程好看牺牲数据真实。你害怕报错害怕打断流程所以选择了欺骗系统。4. 正确的素养异常必须上报哪怕会炸。上报REJECTED上报LOST让 PE 知道出问题了。S6F11 SubstrateStateChanged SUBSTID: WAFER001 STATE: REJECTED ← 明确告诉 Host失败了 REASON: Vacuum Sensor Not DetectedPE 宁愿看到一个明确的REJECTED也不愿看到一个虚假的COMPLETED。因为前者可以止损后者只能报废。五、瞬间四不考虑并发Single Thread Mindset1. 现象你假设 Host 会按顺序发指令先 Load再 Process再 Unload。你写的代码是线性的没有锁没有队列。2. PE 的视角PE 心里想的是“这代码经不起折腾。”现实中Host 会并发发指令在 Robot 移动时Host 可能会发S1F3 Status Request。在 Process 运行时Host 可能会发S2F41 Pause。你的线性代码会死锁、会丢事件、会状态混乱。3. 不专业的本质用理想环境代替真实环境。你假设了 Host 永远绅士但 Host 其实是个暴躁的并发机器。4. 正确的素养假设最坏的情况一定会发生。你的代码必须能处理插队、超时、重入使用消息队列Queue处理 Host 指令。使用互斥锁Mutex保护共享资源。在任何状态跳转时检查当前状态是否允许该操作。六、瞬间五没有可观测性1. 现象出了问题你只能说“我看日志好像是……下午三点左右。”PE 问你具体时间、具体信号、具体状态你答不上来。2. PE 的视角PE 心里想的是“这不叫调试这叫算命。”在 Fab 里时间是金钱晶圆是生命。没有精确的日志就无法回溯事故。3. 不专业的本质日志是给人看的不是给机器看的。你的日志充满了INFO: Task started、DEBUG: Variable changed但没有关键信息。4. 正确的素养日志即证据。每一条日志都要包含硬件时间戳E148 格式物理信号状态PLC IO 的值逻辑状态EAP 内部状态机错误的日志 [14:32:15] INFO: Robot pick finished. 正确的日志 [2026-08-04T14:32:15.123Z] EVENT: S6F11 SubstrateLocationChanged SUBSTID: WAFER001 FROM: LP1_SLOT01 TO: ROBOT_ARM1 PLC_VACUUM: TRUE ← 硬件信号背书 E148_ACCURACY: ±10ms七、总结信任是最贵的资产写 EAP 代码不是写给编译器看的是写给 PE 看的更是写给未来的自己看的。当你拔掉网线、注入脏数据、制造异常时如果你的代码还能优雅地报错、准确地回溯PE 才会真正尊重你。因为你知道晶圆很贵不能用sleep来赌。信任更贵不能用掩盖错误来维持。愿你的代码里没有sleep(1)愿你的日志里全是证据愿你的 PE 看你的眼神里全是信任。你在工作中遇到过哪些不专业的 EAP 代码或者你有哪些职业素养想分享欢迎在评论区一起交流。 
算法精解与面试技巧)
