上个月帮一个在东莞某自动化装备公司做了五年自动化工程师的朋友看简历。他从初级自动化工程师做到中级，独立交付过七八条产线——从3C电子装配线到新能源电池模组线，从食品饮料灌装线到汽车零部件压装检测线。西门子S7-1200/1500用得很熟，倍福（Beckhoff）TwinCAT也做过两个项目，EtherCAT、Profinet、EtherNet/IP三种工业以太网都实战过，还带过两个初级工程师。
他投了一个半月简历，面试只有四家——一家规模比他现公司还小一半的小型系统集成商（薪资涨了8%，但要重新从单机做起）、一家台资工厂的设备维护岗（薪资持平、方向不对）、一家甲方工厂的自动化工程师（薪资涨了12%但面试官说「你的简历看不出你独立做过方案设计」）、一家做AGV的创业公司（薪资涨了15%但要996）。他真正想去的一家头部锂电设备上市公司和一家外企自动化事业部的岗位——简历全沉了。
我打开他的简历，工作经历第一条这么写的：
负责多个自动化产线项目的控制系统设计与调试。熟练掌握西门子S7-1200/1500系列PLC、倍福TwinCAT 3平台，精通TIA Portal和VS编程环境。熟悉EtherCAT、Profinet、EtherNet/IP等工业以太网通信协议及其网络架构设计。掌握伺服驱动系统参数调试和多轴运动控制，使用过西门子S120、三菱MR-J4、汇川SV660等伺服系列。有视觉系统集成经验，使用过康耐视、基恩士等视觉系统。能独立完成整线自动化联调和故障排查。
「五年了。你独立主导过一个完整的项目吗——从甲方提需求、你出方案、你选型、你画网络拓扑图、你定控制策略——不是leader定好了架构然后你去写程序，而是架构本身就是你设计的？」我问他。
「有啊。去年那个新能源电池模组线，12个工位、18个伺服轴、3套视觉系统、2台六轴机器人——整条线的控制架构就是我一个人定的。连用EtherCAT做主干网、哪个节点挂哪个从站、运动控制是用PLCopen的MC功能块还是自己封装——全是我做的决策。」他说。
「那你简历上怎么写的？」
「我想着……写架构是不是太虚了？面试官会不会觉得我在吹？」
问题就在这里。很多中级自动化工程师把三五年里实打实主导过的完整项目——从架构设计到技术选型到现场联调——写成了一句「负责多个自动化产线项目的控制系统设计与调试」，把那些能证明你「不止会写程序，更能做技术决策」的关键证据全扔了，然后奇怪为什么头部公司和外企不给你面试。
对中级自动化工程师的简历来说，有一条和初级截然不同的规则：初级看「你能不能独立搞定一个控制站」；中级看「你能不能主导整条产线的自动化方案——从需求分析到架构设计到技术选型到最终验收，你一个人能不能扛住技术决策」。面试官筛中级自动化工程师简历的时候，在心里问的是五件事：第一，你能不能从零设计一条产线的控制系统架构——不是「leader告诉你用S7-1500你就用」，而是你自己判断了为什么选这个PLC、为什么用EtherCAT而不是Profinet、控制网络怎么分层。第二，你做过多少轴的运动控制——不只是「调过伺服参数」，而是同步精度什么级别、用过什么高级运动控制功能、遇到了什么同步难题怎么解决的。第三，视觉系统是你集成的还是你只是在旁边看——相机选型你参与了吗、光源打光方案你拍板了吗、通信对接和检测逻辑是你设计的吗。第四，整线联调的时候你是那个站在中间协调各方的还是站在旁边等指令的——系统级故障你能不能从现象到架构一层层定位根因。第五，你有没有带过人、有没有在客户面前扛过技术压力、有没有跟机械工程师吵架后达成过技术妥协——一句话，你是不是一个能独立扛项目的工程师，而不只是一个高级PLC程序员。
下面从六个维度，一个一个拆开讲。
先搞清楚：中级自动化工程师的简历要证明什么
在对齐具体写法之前，先对齐一件事：自动化技术总监/工程经理筛一份中级自动化工程师（3-6年经验）的简历，到底在找什么信号。
初级自动化工程师要证明的是「我能独立搞定一个工位/一个控制站」——给你一个灌装工位、一套PLC、几个伺服和传感器，你能从IO点表做到验收交付。中级自动化工程师要证明的是完全不同的四样东西：
第一，你能不能做系统级的技术决策。 甲方跟你说「我们要建一条新能源电池模组组装线，12个工位，节拍要求15秒/件，关键工位精度±0.05mm，核心工艺数据要上传MES」。你能不能从这句话出发，自己画出控制网络拓扑图、自己选PLC品牌和型号（以及为什么选它）、自己决定运动控制总线的选型（EtherCAT还是Profinet IRT还是POWERLINK？）、自己设计数据流架构（哪些数据进PLC、哪些直连上位机、哪些走OPC UA到MES）？这个能力——「面对模糊需求做技术决策」——是中级和初级的本质分界线。
第二，你能不能搞定复杂的多轴运动控制。 初级自动化工程师的运动控制通常是「一个伺服、一个步进、点到点定位」。中级面对的是「18个伺服轴、电子凸轮、电子齿轮、多轴插补、高速同步」——主从轴之间的同步误差要求微秒级、加减速段的跟随误差必须控制在一个脉冲当量以内、凸轮曲线的设计直接影响机械冲击和设备寿命。你得证明你做过、你知道难点在哪、你解决过什么问题。
第三，你能不能主导视觉系统的集成。 视觉集成在自动化行业里有一个很微妙的地位——很多PLC工程师觉得「视觉是视觉工程师的事，我只要接个触发信号、读个结果就行」。但中级自动化工程师必须跨过这条线——相机怎么选、光源怎么打光、图像怎么触发和传输、检测结果通过什么协议回传给PLC、误判率和漏检率怎么优化——你得证明你不是「PLC和视觉之间的传话筒」，而是那个能独立搞定整套视觉集成方案的人。
第四，你能不能扛住整线联调的压力。 初级工程师的联调通常是「我调我这个站的PLC程序——调通了告诉你」。中级工程师的联调是「20个控制站同时上线、生产经理站在旁边掐着秒表、所有问题都指向「自动化是不是有问题」——你能不能在这种压力下，不被情绪裹挟，用系统级的分析方法逐层剥离定位根因」。每一次联调中的系统级排障——通信架构的设计缺陷、时钟同步的漂移、安全联锁的跨站延迟——都在考验你是不是一个有「系统观」的工程师。
带着这四个问题，下面从六个维度一个一个拆。
一、独立系统设计与架构能力：别写「负责控制系统设计」，写你面对什么需求、做了什么架构决策、为什么
系统设计是中级自动化工程师简历里最核心、也最容易被写成「岗位说明书」的部分：
改前案例
负责多个自动化产线项目的控制系统设计与调试工作。根据项目需求，完成控制系统方案设计、硬件选型和网络架构规划。采用西门子S7-1500作为主控制器，通过Profinet工业以太网与分布式IO、伺服驱动器、视觉系统等进行通信。设计控制程序架构，编写PLC程序和HMI界面。主导现场调试和系统联调，确保产线按时交付。
这段话，自动化技术总监看完脑子里只有一个信息：这个人做过产线项目、用过S7-1500加Profinet。但他到底做了什么级别的架构决策？他为什么用S7-1500而不是S7-1200或者倍福CX系列？他为什么用Profinet而不是EtherCAT？控制网络分了几层？数据流怎么走的？——一概不知。
「根据项目需求完成控制系统方案设计」——这句话可以在任何一本自动化教材的目录里找到。面试官想知道的是：你面对的具体需求是什么？你权衡过哪些方案？你最终为什么选了这个方案而不是另一个？
改后案例
新能源电池模组组装线——我独立设计的控制系统架构 | 倍福 CX2040 + TwinCAT 3 + EtherCAT 主干网
甲方核心需求： 12个工位、18个伺服轴、3套视觉检测系统、2台六轴机器人（Fanuc）。节拍要求 ≤ 15秒/件，关键工位定位精度 ±0.05mm。所有工艺参数和检测数据实时上传MES，上传延迟 ≤ 500ms。安全等级要求 PL d（ISO 13849-1）。
我的架构决策——不只是「选了个PLC」，而是四个关键选择：
第一，为什么用倍福而不是西门子？ 这个项目有18个伺服轴——而且不是简单的点到点定位，极耳折弯工位需要电子凸轮（主从轴之间做非线性跟随）、激光焊接工位需要多轴插补。西门子S7-1500做多轴运动控制要靠S120驱动器加CU320控制单元——18个轴的成本和接线复杂度会非常高。倍福的TwinCAT直接运行在工业PC上，EtherCAT是纯软件实现的主站——18个伺服轴只需要一根EtherCAT网线菊花链串联，每个伺服驱动器作为一个EtherCAT从站挂在总线上。硬件成本和接线工时大概只有西门子方案的60%。甲方设备经理听完我的对比分析后当场拍板：「就按你说的，用倍福。」
第二，控制网络为什么分三层？ 我没有把所有设备挂在一个扁平网络上——那样虽然简单，但出问题的时候定位困难，而且数据流容易互相干扰。我设计了三层网络架构：
- 实时控制层（EtherCAT，100Mbps全双工，总线周期1ms）： 18个伺服驱动器 + 12个EtherCAT耦合器（带远程IO模块）全部挂在EtherCAT主干网上。这一层只跑实时运动控制数据和IO刷新——对延迟和抖动极度敏感。我把运动控制周期设为1ms、IO刷新周期设为2ms——实测网络抖动 ≤ 50μs。
- 视觉与机器人通信层（EtherNet/IP + TCP/IP，千兆以太网）： 3套视觉控制器（基恩士CV-X系列）和2台Fanuc机器人控制器通过千兆交换机接入——视觉图像数据和机器人状态数据量大（单帧图像约5MB），不适合跑在EtherCAT的100Mbps链路上。视觉控制器通过EtherNet/IP向PLC发送检测结果（OK/NG + 尺寸数据），机器人通过TCP/IP Socket与PLC交换抓取坐标和状态字。
- 上位机与MES层（OPC UA + MQTT，千兆以太网）： 每15秒把关键工艺参数（温度曲线、压力曲线、检测数据、产量计数）通过OPC UA推送至MES。我用TwinCAT自带的OPC UA Server功能——不用额外加一台工控机做数据网关，省了约1.5万的硬件成本和两周的开发时间。
第三，安全控制为什么用独立的安全PLC而不用TwinCAT的安全功能块？ 倍福TwinCAT 3有TwinSAFE软件安全方案——在同一个IPC上跑安全逻辑。但这条线的安全联锁跨了12个工位——急停按钮、安全光幕、安全门开关加起来有60多个安全输入点。如果安全逻辑跑在同一个IPC上，IPC一旦蓝屏——整个安全系统就瘫了。我坚持用独立的倍福EL6900安全PLC模块挂在EtherCAT总线上——安全PLC和主控IPC物理分离、通过FSoE（Fail Safe over EtherCAT）协议通信。安全回路响应时间实测 12ms，满足PL d要求。后来在联调阶段，主控IPC因为Windows Update自动重启了一次——标准控制全部停机，但安全PLC独立运行、安全回路始终在线——甲方的安全工程师专门发微信跟我说「你坚持独立安全PLC是对的，我们审厂一定会查这一点」。
第四，架构文档不只是「交差用的」——我画了一张让甲方设备经理能看懂的图。 通常的系统拓扑图是一堆方块和连线——电气工程师看得懂，设备经理和工艺主管一脸懵。我画了两版拓扑图：一版是给电气工程师看的详细版（标注了每个从站的FSoE地址、EtherCAT的DC时钟分配、各网段的VLAN划分），另一版给甲方设备经理看的是「功能视图」——用不同颜色区分实时控制层/视觉通信层/上位机层，每层旁边标注了「这一层出问题会影响什么」。甲方设备经理翻了30秒说：「以后我们工厂自己维护团队看图就简单了。」
架构效果： 整条线18个伺服轴EtherCAT通信零丢包；视觉检测结果回传延迟 ≤ 80ms；工艺数据上传MES延迟 ≤ 300ms（目标500ms）。产线从电气安装到整线联调打通——总共用了5周（项目经理预估8周）。甲方在验收总结会上说了一句让我印象极深的话：「之前我们另一条AB PLC的产线联调搞了三个月——你们这条线联调速度快，控制架构的底子好。」
自动化技术总监读完这段经历，看到的不是一个「会用倍福PLC」的工程师，而是一个**「面对12工位18轴3视觉2机器人的复杂产线，能独立做出四大架构决策（PLC品牌选型、三层网络设计、安全PLC独立部署、双版本文档交付）、每个决策都有清晰的技术逻辑和成本/时间对比、最终整线联调周期从预估8周压缩到5周的工程师」**。他看到的是系统级思维——不只是「我会写程序」，而是「我知道整条产线的数据该怎么流、风险该在哪里隔离、架构该怎么为联调和维护服务」。
系统设计的写作公式
项目名称 + 甲方核心需求（节拍、精度、轴数、通信要求、安全等级）→ 你的1-2个关键架构决策（为什么选这个PLC/总线、网络怎么分层、安全怎么隔离）——每说一个决策都要带对比和理由 → 架构带来的量化效果（联调周期缩短、通信丢包率、延迟达标、甲方反馈）
这个公式有两个关键点：
第一，架构决策必须带「对比」。 「我选了倍福」不叫架构决策——「我在18轴运动控制的场景下对比了倍福TwinCAT+EtherCAT和西门子S7-1500+Profinet IRT两个方案，硬件成本和接线工时倍福方案只有西门子的60%」才叫架构决策。面试官想看到的是「你思考过、你对比过、你选得有道理」。
第二，架构的效果要量化。 「网络运行稳定」不如「18个伺服轴EtherCAT通信零丢包、网络抖动 ≤ 50μs」。「联调顺利」不如「整线联调从预估8周压缩到5周」。
二、多轴运动控制与伺服系统：别写「调试过伺服驱动器」，写你做过什么同步运动、遇到过什么难点、怎么解决的
多轴运动控制是中级自动化工程师简历里最能拉开差距的板块——也是绝大多数从初级升上来的工程师最薄弱的板块。为什么？因为初级做的大多是单轴点到点——设定目标位置、设定速度、走你。中级面对的是「18个轴之间有严格的同步关系——一个轴的位置偏差超过0.1mm，后面的工位全废了」。
改前案例
掌握多轴运动控制系统调试，熟悉伺服驱动器的参数设置和调试。使用过西门子S120、三菱MR-J4、汇川SV660等伺服系统。能完成电子齿轮、电子凸轮等同步运动控制的编程与调试。熟悉伺服电机的惯量匹配、刚性调整和振动抑制。
面试官的内心OS：「所以呢？任何一个做过两年自动化的人都写过电子齿轮、都调过伺服刚性。你做的电子凸轮——是简单的一个主轴带着一个从轴做匀速比，还是从轴要跟着主轴的非线性曲线做高速跟随？你调伺服刚性——是调了一个轴的增益让它不抖，还是调过18个轴之间的耦合振动？」
改后案例
我理解的「多轴运动控制」不是「把伺服电机转起来」——是在高速、高精度的条件下，保证多个轴之间的相位关系不丢、跟随误差不超标、机械末端不共振。
在一条锂电池极片模切线上，我做过最复杂的运动控制——「飞剪同步」的精度保卫战。
项目背景： 锂电池极片模切机。工艺流程：极片料带以 60米/分钟 的线速度连续送料——模切刀辊必须跟料带精确同步：刀刃在接触料带瞬间，刀刃的线速度必须与料带线速度完全一致——否则极片切口会被撕裂。同步精度要求：刀辊与料带的线速度偏差 ≤ 0.05%（60米/分钟下即 ≤ 0.05米/分钟）。这个精度不是「写个电子齿轮比就行了」——从来料到模切是一段连续运动，料带不是恒定速度（加速段、减速段、恒速段），刀辊不能只是「按比例转」——必须在每个周期内做精确的加减速同步。
我的同步方案：
- 主轴定义： 料带的实际速度来自一个安装在牵引辊上的增量式编码器（1024脉冲/圈）。这个编码器信号不是直接给刀辊伺服做电子齿轮——因为编码器信号有抖动（机械振动导致瞬时速度波动约 ±2%），直接送给从轴会让刀辊产生高频速度振荡。
- 虚拟主轴 + 速度平滑滤波： 我在PLC里做了一个虚拟主轴——先对编码器原始信号做了20ms滑动平均滤波去掉机械振动噪声，再通过TwinCAT的MC_GearIn功能块把滤波后的速度映射为虚拟主轴。刀辊伺服（从轴）通过电子凸轮表跟随虚拟主轴——凸轮表定义了「主轴每转一圈，从轴的位置/速度曲线」。不是简单的1:1线性关系——而是根据刀辊的直径、刀刃数量、以及加速段的S曲线加速度限制，定制了一条非线性的凸轮曲线。
- 电子凸轮表的设计是这个项目最难的环节。 刀辊每转一圈完成一次模切——在一个周期内，刀刃接触料带的时间窗口只有约15ms。在这15ms内，刀刃线速度必须精确等于料带速度——偏差超过0.05%就会撕极片。但刀辊从上一个刀刃离开料带到下一个刀刃接触料带，中间只有约85ms的「空闲时间」——刀辊必须在这85ms内完成减速→等相位→加速到同步速度。我在TwinCAT的凸轮编辑器中设计了一条五阶多项式凸轮曲线——五阶保证了位置、速度、加速度在同步段的二阶连续性，避免了速度拐点造成的机械冲击。
调试中遇到的最大难题——高速段的相位漂移。
刀辊在60米/分钟的满速下跑了一段时间后（大约连续运行2小时），会出现一个诡异的现象：刀刃接触料带的位置慢慢往前漂——从切口中心漂了约0.3mm。这个漂移量累积到1mm左右就会导致极片切偏。我的排查过程：第一反应是编码器信号丢脉冲——但用示波器抓了编码器的A/B相波形，没有丢。第二反应是电子凸轮表的主从轴映射相位偏了——但用TwinCAT Scope跟踪了主轴和从轴的实时位置曲线，发现相位关系是对的。第三次排查——我开始怀疑是不是机械侧的问题。我用激光干涉仪测量了刀辊的实际角位置——发现刀辊在长时间高速运行后，由于轴承温升导致刀辊外径热膨胀了约0.015mm——别小看这0.015mm，乘以刀辊的转速，每小时的累积相位漂移就是0.3mm左右。
解决方案：我在PLC程序里加了一个「动态相位补偿」功能——在刀辊轴承旁装了一个温度传感器（PT100），根据温度变化计算热膨胀量，实时微调电子凸轮的主轴相位偏移值。补偿策略是线性的——每升高1℃，相位补偿3个编码器脉冲。这个补偿逻辑上线后，连续运行24小时——切口位置漂移控制在 ±0.05mm 以内（目标 ±0.1mm）。
产线效果： 模切精度从调试初期的 ±0.15mm 优化到了 ±0.05mm——良率从92%提升到99.3%。这条线后来成了公司模切机产品线的标准运动控制方案——后续3台同型号设备的运动控制程序直接复制了这一版的凸轮表和补偿逻辑。
面试官读到这里，脑子里不是一个「调过伺服参数」的工程师，而是一个**「在60米/分钟高速飞剪场景下，从编码器信号处理→虚拟主轴→五阶多项式凸轮曲线设计→高速段热膨胀相位漂移诊断→动态温度补偿——完整走完了一条多轴运动控制的深水区」**的工程师。这不是「会用MC_GearIn功能块」——这是理解了运动控制底层物理过程之后，用软硬件结合的手段解决了一个真实的工程难题。
多轴运动控制的写作公式
项目名称 + 运动工艺场景（飞剪？追剪？缠绕？电子凸轮？多轴插补？）→ 同步精度要求（数值——0.05%？1个脉冲当量？微秒级？）→ 你的同步方案（主轴是什么、从轴怎么跟随——电子齿轮/电子凸轮/插补曲线类型、有没有滤波/补偿环节）→ 调试中遇到的一个运动控制难题（同步抖动？相位漂移？高速下跟踪误差超标？轴间耦合振动？）→ 你怎么分析定位的（用了什么工具——TwinCAT Scope？示波器？激光干涉仪？频谱分析？）→ 怎么解决的 → 最终的运动精度和产线效果
三、视觉系统集成：别写「使用过视觉系统」，写你独立选型、独立调试、独立优化——从拍不到图到99.7%的一次检测成功率
视觉系统集成在中级自动化工程师简历里是一个极度被低估的加分项——但也是写得最虚的板块：
改前案例
有视觉系统集成经验，使用过康耐视In-Sight系列和基恩士CV-X系列视觉系统。负责视觉检测工位的相机安装、光源调试和通信对接。配合视觉工程师完成检测算法的调试和参数优化。
这段话，面试官看完只有一个感觉：你是那个在视觉工程师旁边帮忙拧螺丝和插网线的。你选过相机型号吗？你设计过光源打光方案吗？你调过检测算法的阈值吗？视觉和PLC之间的通信协议是你定的吗？——全不知道。
改后案例
我对视觉系统集成的理解不是「等视觉工程师把图拍清楚了我接个结果就行」——是「从检测需求出发，独立完成相机选型、光源方案设计、图像触发与通信架构、检测逻辑编写和误判率优化的全流程」。
案例：新能源电池模组线——极耳焊接前的「极片对齐检测」视觉工位
检测需求： 在极耳超声焊接之前，必须确认正负极片是否对齐——如果正负极片错位超过 0.1mm，焊接后会造成内部短路（这是电池安全等级最高的缺陷之一）。节拍要求：每个电芯的检测时间 ≤ 400ms（整线节拍15秒，分配给视觉检测的窗口只有400ms）。误判率要求：过杀率（把良品判成不良品）≤ 0.5%、漏检率（把不良品判成良品）≤ 0.01%——漏检一个不良品等于放了一个有安全隐患的电池下线。
我的选型与方案设计——不是在样本册里挑一个贵的：
相机选型： 检测视野约 50mm×40mm，要求分辨出0.1mm的错位——我按「最小特征尺寸=0.1mm、按照至少3个像素覆盖一个最小特征」的原则计算：每个像素对应约0.033mm，视野50÷0.033≈1500像素。我选了Basler ace2系列500万像素工业相机（2592×1944像素，全局快门，USB 3.0接口）——全局快门是因为工件在运动中拍照（不是停下来拍——停下来等拍照会吃掉节拍），卷帘快门在运动中会产生拖影。USB 3.0是因为传输距离只有3米、不需要CameraLink那种长距离抗干扰能力。
光源方案——这个项目最让我头疼的部分。 极耳是铜箔和铝箔——两种材料反光特性差别极大：铜箔是暗红色、反光率低；铝箔是银白色、反光率高。如果用普通的环形白光直接打——铝箔区域会过曝（全白）、铜箔区域会欠曝（全黑）——检测软件根本找不到极片边缘。我试了三种光源方案：1）低角度环形红光——铝箔过曝问题依然严重；2）同轴光源——铜箔和铝箔的对比度不够，边缘检测不稳定；3）最终方案：穹顶漫射光源（Dome Light）——光源不是直接打到工件表面，而是先打到半球形漫反射罩上、再均匀地漫反射到工件表面。这个方案让铜箔和铝箔的对比度都保持在检测软件的最佳工作范围内——实测灰度直方图的峰值信噪比从最初方案的约18dB提高到了约34dB。
检测逻辑与通信——我自己写，不依赖视觉供应商的默认方案。 甲方一开始说「用视觉控制器自带的检测工具就行了」——基恩士CV-X自带的边缘检测工具确实能用。但实际跑起来发现一个问题：自带的边缘检测在极片有轻微褶皱时（褶皱高度<0.05mm）会把褶皱的边缘误判为极片边缘——导致错位值测出来偏大，过杀率高。我放弃自动工具，自己在CV-X的脚本功能里写了一套检测逻辑：先用高斯滤波降噪、再用Sobel算子做边缘检测、然后对检测出的边缘做直线拟合——用RANSAC算法剔除褶皱产生的离群边缘点、只保留真正的极片边缘。这套逻辑上线后，过杀率从原来的约3.2%降到了0.3%（目标0.5%以下）。
与PLC的通信架构： 视觉控制器通过EtherNet/IP协议向PLC传送检测结果——不是只传一个OK/NG信号，而是传了一个5-word的数据包：检测结果（OK/NG）+ 正极片位置X + 负极片位置X + 错位值 + 错位方向。PLC收到后，不光判断OK/NG——还把错位值记录到工艺数据库中。后面工艺工程师做质量追溯的时候，可以直接翻出每个电芯的极片对齐数据——不需要另外导视觉控制器的日志。
效果： 一次检测成功率 99.7%（无复拍）、过杀率 0.3%、漏检率 0%（上线6个月零漏检）。甲方品质总监在验收时专门问我：「你以前是不是做过视觉？」我说没有系统学过——这次是一边学CV-X的脚本编程一边调的。他说：「那你的自学能力确实强——我们这个检测是电池安全项，之前找过两家视觉方案商来试，都没把过杀率和漏检率同时做下来。」
面试官读到这里，脑子里不是一个「配合视觉工程师调试」的工程师，而是一个**「从相机像素计算、到三种光源方案对比验证、到放弃默认工具自己写边缘检测逻辑、到用RANSAC算法把过杀率从3.2%降到0.3%、到设计5-word检测数据包服务工艺追溯——独立完成了整套视觉集成方案」**的工程师。这不只是「懂视觉」——这是「把视觉当成了自己自动化工具箱里的一把刀」。
视觉集成的写作公式
检测需求（测什么、精度多少、节拍窗口多大）→ 你的选型决策（为什么选这个相机/光源/通信方式——要带计算和对比）→ 调试中遇到的核心难题（过曝？欠曝？边缘不准？误判率高？）→ 你的解决方案（打光方案调整？算法策略调整？阈值优化？）→ 量化效果（一次检测成功率、过杀率、漏检率、甲方反馈）
四、整线自动化与产线联调：中级工程师的终极考验——系统级思维在压力下的实战
整线联调是中级自动化工程师简历里最能直接证明「我能扛项目」的板块——但绝大多数简历把这部分写成了「负责现场调试和系统联调」十个字。面试官想知道的是：你在联调现场到底是那个在中间协调各方、做关键决策的「大脑」，还是那个等指令干活的「手」？
改前案例
负责项目现场的系统联调和设备调试。协调机械、电气、软件各专业完成整线联调工作。对调试过程中出现的系统性问题进行分析和处理，确保产线按时交付验收。
改后案例
新能源电池模组线——12工位整线联调中的72小时「时钟同步」攻坚战
这条新能源电池模组线有12个工位——为了方便维护和并行调试，甲方要求每个工位独立配备一台PLC（实际是倍福CX系列嵌入式控制器，每工位一台）。12台CX控制器通过EtherCAT Automation Protocol（EAP）进行工位间的数据交换——前一个工位做完后通过EAP告诉后一个工位「物料已就绪」，后一个工位确认后开始动作。这是一个「分布式控制、工位间握手」的架构。
整线联调前两天一切顺利。第三天下午，生产经理安排了一轮连续运行测试——目标连续运行4小时不走停。跑到第2小时47分钟的时候——整条线突然停了。不是某一个工位停，是12个工位几乎同时报「工位间握手超时」。所有HMI画面上的「工位就绪」信号从绿色全跳成了红色。
操作工慌了——生产经理打电话把我从酒店叫过来：「你们这条线白天跑得好好的，晚上就不行了——今晚必须搞定，明天宝马的审核团要来巡线。」
我到现场打开最前端的第1工位CX控制器的诊断日志——发现握手超时故障发生前约3秒，第1工位和第2工位之间有一次EAP通信重传。顺着这个线索，我逐台检查了12台CX控制器的系统时钟——发现第2工位和第1工位的系统时间差了约11秒。EAP握手协议里有超时判断——如果两个工位之间的时间差超过10秒，握手包会被当成过期包丢弃——导致握手超时。
问题是：为什么第2工位的时间会漂走？
我查到第2工位的CX控制器NTP时间同步设置出了问题。整条线的12台CX控制器本来配置了通过交换机的NTP Server做时钟同步——每10分钟同步一次，确保12台之间的时间差不超过50毫秒。但第2工位在联调初期，电气工程师为了方便调试，把它的网线临时插到了一个没有NTP Server的独立交换机上——后来还原回主交换机的时候，Windows CE的NTP客户端没有自动重新发现NTP Server（这是一个已知的Windows CE NTP bug ——在更换网络后首次NTP查询失败后，NTP客户端会停止重试，而不是一直等到超时再重试）。
根因找到了。我的解决方案分三步：
- 立即恢复： 手动在第2工位CX控制器的命令行里执行
net time \\NTP_Server_IP /set /yes，把时钟拉回正确时间——产线立即恢复运行。- 根治： 我在每个工位的PLC程序里加了一个「时钟偏移监控」FB——每30秒，每个工位读取一次自己的系统时间，通过EAP广播给第1工位。第1工位持续监控所有工位的时钟偏移量——任何一个工位与第1工位的时间差超过5秒，就在HMI上弹出黄色预警（不是红色报警——还不影响运行，但提醒维护人员检查）；超过10秒，触发红色报警并暂停产线，同时自动执行NTP强制同步命令。
- 长期： 我写了一份《分布式控制系统时钟同步配置规范》给甲方维护团队——包括NTP Server的冗余配置（至少两台）、CX控制器在更换网络后的NTP恢复步骤、以及定期检查各工位时钟偏移的SOP。
这套监控FB上线后，再也没有因为时钟漂移导致过工位间握手超时。甲方的自动化主管后来跟我说：「你这个时钟监控FB写得特别好——我们以前另一条AB的分布式产线也出过类似的时钟问题，当时搞了两周才定位到。你这套东西我们直接复制到那条线上用了。」
整线联调从开始到连续72小时无故障跑合通过——总周期4.5周，比项目经理预估的7周压缩了36%。宝马审核团巡线当天，产线从上午9点到下午4点连续运行7小时——零停机。生产经理巡完线以后请我们团队吃饭，说了一句：「今晚终于不用被老板打电话叫回来了。」
面试官读到这里，脑子里不是一个「负责现场系统联调」的工程师，而是一个**「半夜被叫到现场、面对12工位同时停机的混乱局面、冷静地从诊断日志入手→逐台检查时钟→定位到Windows CE NTP bug→三步闭环（立即恢复+根治监控+规范沉淀）→最终让产线扛住了宝马审核团7小时零停机的压力测试」**的工程师。这就是中级工程师的终极画像——在压力下保持冷静、用系统级思维逐层分析、不仅解决当下的问题还为未来建立了防御机制。
整线联调的写作公式
产线规模和架构（多少个控制站、什么通信架构、工位间怎么协作）→ 联调中出现的系统级问题（不是单机故障——是跨站通信、时钟同步、数据流瓶颈、安全联锁延迟这种架构层面的问题）→ 你的排查过程（从什么线索入手、怎么缩小范围、用了什么诊断工具）→ 你做了什么（立即恢复+根治方案+长期规范）→ 联调的量化结果（联调天数、连续运行无故障时长、客户反馈/压力测试结果）
五、项目主导与团队协作：中级工程师的「软实力」——带人、扛客户、跟机械工程师「吵架」
中级自动化工程师几乎都会被推到一个位置：你不仅要写程序，还要带初级工程师、跟客户做技术汇报、在技术方案上和机械工程师「吵架」（然后达成合理的技术妥协）。但简历上这部分往往只写了一行「协助项目经理管理项目进度」。
改前案例
协助项目经理进行项目进度跟踪和资源协调。指导初级工程师完成程序编写和调试工作。与机械工程师、电气工程师紧密配合，协调解决多专业交叉的技术问题。参与客户技术交流和方案汇报。
改后案例
最近两年，我在三个关键项目上承担了远超「自动化工程师」职责范围的工作——带人、扛客户、在多专业冲突中做技术判断。
带人——一个初级工程师的「从不会到独立」的四个月。 2024年在一条汽车零部件压装检测线项目上，公司给我配了一个刚入职半年的初级工程师小陈——自动化专业本科，学校学过西门子PLC，但没有现场经验。项目经理跟我说：「老张，这个项目你带小陈——你负责主站程序和系统架构，让他写几个简单工位的PLC程序和HMI画面。但进度不能拖。」
我的做法不是「扔给他一个工位让他自己琢磨」——那样他会浪费很多时间在基础问题上，最后还得我返工。我给他设计了一个四个月的成长路径：
- 第1个月： 让他跟着我在现场看——不是让他动手写程序。我每做完一个工位的调试，就拉着他复盘10分钟：「这个工位的控制逻辑为什么这样设计？」「我刚才查那个故障的思路是什么？」一个月下来，他看了我调了4个工位——对整条线的控制逻辑有了全局认知。
- 第2-3个月： 我挑了两个难度适中的工位给他——一个气缸输送工位（纯数字量逻辑）、一个伺服压装工位（含一个伺服轴和力传感器）。我不写程序给他看——让他先自己写、自己调、调不出来再来问我。但我不是直接告诉他答案——我让他先把问题分析写出来：「现象是什么？你排查了哪些可能？你觉得根因是哪个？你的修复方案是什么？」我只看他的分析，然后问他：「你有没有查过伺服驱动器的报警历史？」「你有没有用万用表量过这个传感器的信号？」——引导他自己找到答案，而不是直接给他答案。
- 第4个月： 他独立负责了最后新增的一个工位——从IO点表到程序编写到现场调试全部自己搞定。我只在验收前做了一次code review——指出两个潜在的隐患（一个互锁条件遗漏、一个超时判断没有做）。他在第四个月的表现让项目经理很惊讶——「小陈跟刚来的时候完全不一样了」。后来小陈被派到下一个项目独立负责了两个工位——他发微信跟我说：「张哥，你前几个月让我写故障分析的习惯，现在救了我好几次。」
跟客户扛技术判断——不是客户说什么就做什么。 还是这条压装检测线，甲方工艺主管有一天找到我：「你们这条线的压装工位速度太慢了——我要把压装时间从4秒压缩到2.5秒。你把伺服速度调大一倍就行。」
我没有直接说「做不到」——也没有直接说「好我去改」。我做了两件事：第一，我把他拉到HMI屏幕前面，打开压装过程的力-位移实时曲线：「您看——现在4秒的压装时间内，压入力从0升到5吨的斜率是这样的。如果压缩到2.5秒，液压缸的流量需要翻将近一倍——但您这条线的液压站流量上限是40L/min，现在已经在用35L/min了。翻一倍要上80L/min——液压站要换、管路要加粗、整个液压系统要重新设计。这不是伺服参数的事。」第二，我给了他一个替代方案：「如果我们把压装工序拆成两段——第一段气缸快进（2秒，空行程）、第二段液压加压（2.5秒，压实行程）——总时间4.5秒。虽然比2.5秒慢，但比现在的单液压主方案省了1.5秒，而且不用改液压站。」甲方工艺主管听完想了一会：「那先按你这个方案试——如果节拍还是不够我们再讨论。」后来整线节拍达标了（不是因为压装变快了，是因为我在前道工序做了并行优化把总节拍吃下来了）。
跟机械工程师「吵架」——从「这是你的事」到「我们一起来看」。 2023年在一个项目上，机械工程师设计了一个检测工位的「定位夹具」。但这个夹具的夹紧气缸行程选得太小——理论上夹紧了，但实际工况下，来料的尺寸有公差——个别工件夹不紧。我在调试时发现检测结果飘得很厉害——查了半天不是你视觉的问题，不是传感器的问题——是工件在检测时没夹紧，在轻微晃动。
我去找机械工程师老刘：「老刘你这个夹具夹紧力不够——有些工件夹不紧，检测数据在飘。」老刘第一反应是防御：「图纸上夹紧行程是够的——你看计算。」我说：「计算是对的——但计算用的是公称尺寸。实际工件的公差范围是±0.2mm，你不是不知道吧？」老刘沉默了一会，跟我到现场看了一下。他用塞尺量了工件和夹具之间的间隙——确实有0.15mm的晃动。最后他重新设计了夹具——把夹紧气缸行程加了5mm、夹爪加了一个弹簧预紧——问题解决。
后来老刘请我喝了瓶水，说：「说实话一开始你来找我，我心里不爽——觉得你在挑我设计的毛病。但你最后那句'计算用的是公称尺寸，但实际有公差'——让我一下子服了。你是对的。」
面试官读到这里，脑子里不是一个「协助项目经理」的机械臂，而是一个**「能用四个月把一张白纸的初级工程师带成能独立负责工位的人、能在客户不合理需求面前用数据和替代方案扛住而不是直接说'做不到'、能在和机械工程师的冲突中用事实和逻辑说服对方而不是扯皮」**的中级工程师。这个「能扛事」的能力——在任何一个自动化团队里都是极度稀缺的。
项目主导的写作公式
选1-2个具体场景：带人（你是怎么带的、被带的人后来怎么样了）、扛客户（客户提了什么需求、你为什么不能直接做/为什么不能直接拒绝、你怎么处理的——替代方案或数据说服）、跨专业协作（跟谁出了什么冲突、你怎么解决的、结果怎么样）——每个场景都要有具体对话/动作/结果
六、自我评价：中级自动化工程师的自我评价——从「精通西门子PLC」到「五个清晰的技术标签」
中级自动化工程师的自我评价，十个里有九个长这样：
改前案例
5年工业自动化系统集成经验，精通西门子S7-1200/1500系列PLC和倍福TwinCAT 3平台。熟练掌握EtherCAT、Profinet、EtherNet/IP等工业以太网通信协议及网络架构设计。具备丰富的伺服运动控制系统调试经验，熟悉多轴同步控制。有独立完成整线自动化联调的项目经验。良好的团队管理和项目协调能力，能适应现场工作压力。
这段话没有任何致命错误——但它也没有任何一个能让技术总监记住你是谁。「精通西门子PLC」——投这个岗位的100份简历里大概80份写了这句话。「丰富的伺服调试经验」——每个人都能说。面试官15秒扫完，总结：「一个做了5年、用过西门子和倍福、能出差的自动化工程师。」
改后案例
5年工业自动化系统集成经验，独立主导设计过7条产线的控制系统——涵盖新能源电池模组组装（12工位/18伺服轴/3视觉/2机器人）、汽车零部件压装检测（6工位/8伺服轴）、3C电子装配（全自动贴标检测分选）、食品饮料灌装包装等。五个核心能力标签：
一是控制架构设计能力。 不只会写程序——能从甲方模糊需求出发，独立完成控制网络拓扑设计、PLC品牌和总线选型、控制网络分层架构、安全系统独立部署。在12工位电池模组线上主推倍福TwinCAT+EtherCAT方案替代原西门子S7-1500+Profinet方案——硬件成本和接线工时降至原方案60%，整线联调周期从预估8周压缩到5周。
二是多轴运动控制能力。 做过最复杂的运动控制场景——60米/分钟极片模切飞剪同步：从编码器信号滤波→虚拟主轴→五阶多项式电子凸轮→到高速下热膨胀相位漂移的动态温度补偿。最终定位精度±0.05mm，良率从92%提升至99.3%。18轴EtherCAT同步刷新，网络抖动≤50μs。
三是视觉系统集成能力。 不是「配合视觉工程师」——是独立完成相机选型、光源方案验证（试过3种方案最终选定穹顶漫射光源）、检测逻辑编写（放弃默认工具，用高斯滤波+Sobel+RANSAC自写逻辑）、通信架构设计（EtherNet/IP+5-word数据包服务工艺追溯）。过杀率从3.2%压至0.3%、漏检率0%、一次检测成功率99.7%。
四是整线联调与系统级排障能力。 在12工位分布式控制系统联调中，面对全线同时握手超时停机的突发故障，从诊断日志入手→发现时钟偏移→定位到Windows CE NTP bug→三步闭环（立即恢复+运行时监控FB+配置规范）。联调周期4.5周（预估值7周），扛住宝马审核团7小时连续运行零停机。
五是项目主导与团队建设能力。 带过一个初级工程师（4个月从零到独立负责工位），在客户提出「把压装时间压缩一半」的不合理需求时，用液压站流量数据和替代方案（气液两段加压）扛住了技术判断。跟机械工程师因为夹具设计冲突时，用「公称尺寸vs实际公差」的工程逻辑说服对方——而不是扯皮。
期望方向：在一个技术氛围浓厚、鼓励工程师做架构级决策的平台上向高级自动化工程师和技术管理方向发展。
五段话。面试官15秒扫完，脑子里留下五个清晰的技术标签：这个人能独立做整线控制架构决策（不是只会按leader定的方案执行）；能做60米/分钟飞剪级别的多轴运动控制（不是只会调伺服刚性）；能独立搞定整套视觉集成（不是只会接触发信号）；能在12工位停工的压力下冷静定位系统级故障（不是慌了手脚等人救）；能带人、能扛客户、能用工程逻辑而不是情绪处理跨专业冲突。每一个标签背后都是一个可以展开讲四十分钟的真实工程案例。
而原版自我评价扫完15秒，只记得：「哦，又一个精通西门子PLC、熟悉EtherCAT、能适应现场压力的自动化工程师。」
自我评价的铁律： 每个能力标签 = 一个你亲自操刀的代表性项目 + 一个你解决过的具体技术难题 + 至少两个让面试官眼前一亮的数字。任何换一个干了五年的自动化工程师也能写的标签——「精通XX」「丰富经验」「良好的XX能力」——全删。
写完后的自检清单
- 简历里有没有一段经历写的是你独立做的系统架构决策——不是「根据项目需求完成方案设计」，而是「面对什么需求和约束、你对比了哪几个方案、为什么选了这个、这个决策带来了什么效果」？
- 多轴运动控制部分——有没有超过「调试过伺服驱动器」？有没有写清楚你做的是什么运动工艺（飞剪/追剪/凸轮/插补）、同步精度什么级别、遇到过一个什么具体的运动控制难题并怎么解决的？
- 视觉集成部分——如果只写了「使用过康耐视/基恩士视觉系统」，回去重写。你有没有独立选过相机型号？设计过光源方案？调过检测算法阈值？通信架构是你设计的吗？
- 整线联调部分——你有没有写过一次系统级的排障经历？不是「换了一根网线就好了」——是那种从现象出发、用诊断工具和逻辑分析、一层层定位到根因、最后还建立了预防机制的复杂故障？
- 你带过人吗？简历里有没有你带初级工程师的经历——你是怎么带的、被带的人后来怎么样了？
- 你有没有在客户面前扛过技术判断的经历——不是客户说什么就做什么，也不是直接说「做不到」——而是用数据和替代方案跟客户做技术沟通？
- 自我评价是否删到了5行以内？每个标签背后有没有一个具体的项目和至少两个数字？删掉「精通XX」「丰富的XX经验」「良好的XX能力」这些换任何一个人都能写的标签。
- 简历整体读完，面试官能不能一句话说出：「这个中级自动化工程师最擅长什么（架构决策？运动控制？视觉集成？）、他做过最大规模的系统是什么（多少控制站、多少轴、是否含视觉/机器人）、他解决过最棘手的问题是什么？」
中级自动化工程师写简历，最致命的陷阱是觉得自己和初级一样——只是经验多了几年、项目做多了几个。所以把简历写成了一份「高级版的初级简历」：更多的PLC品牌、更多的通信协议、更多的项目清单——唯独没有展示「我能做架构决策」「我能搞定复杂的运动控制」「我能独立集成视觉」「我能在整线趴窝的时候冷静定位根因」「我能带人、能扛客户、能跟机械工程师在技术层面达成共识」这些中级工程师独有的能力。
把你独立主导设计过的最复杂的控制系统架构写出来——不是「负责XX项目控制系统设计」，是「面对12工位18轴3视觉2机器人的产线需求，我独立完成了四大架构决策——PLC品牌选型（倍福替代西门子，成本降40%）、控制网络三层分层设计、安全PLC独立部署、双版本文档交付——最终联调周期从8周压缩到5周」。把你啃过的运动控制深水区写出来——不是「调试过伺服驱动器」，是「在60米/分钟飞剪同步中，从编码器滤波到五阶凸轮设计到热膨胀相位补偿全流程搞定——最终定位精度±0.05mm、良率92%→99.3%」。把你从零到一搞定的视觉方案写出来——不是「使用过视觉系统」，是「从相机像素计算到三种光源对比验证到自写检测算法——过杀率3.2%→0.3%、漏检率0%」。把你在联调现场面对12个工位全部趴窝的那72小时写出来——不是「负责系统联调」，是「凌晨被叫到现场、独自分析时钟偏移、定位到Windows CE NTP bug、三步闭环彻底解决问题的全过程」。
初级自动化工程师证明的是「我能把程序写好」。中级自动化工程师证明的是「我能把项目扛住」。
把你的TIA Portal最小化、TwinCAT Scope关掉。翻开那条你做过的最复杂的产线的联调日志。回想一下那个让你熬了两天才定位到的系统级故障、那个你在客户面前用一张液压站流量曲线图扛住了不合理需求的关键10分钟、那个你用一个四个月的成长路径把一个新人从什么都不会带到能独立负责工位的经历。把这些写出来——不是「我做过很多项目」——而是「我能主导整线自动化方案从零到交付的全过程」。
写好之后不确定效果？好简历的免费诊断可以帮你从架构设计、运动控制、视觉集成、联调能力、项目主导几个维度做一次全面扫描，每一段经历都会给出强弱项分析和改进建议。