前段时间帮一个做了两年自动化工程师的朋友看简历。他在一家系统集成商干了两年，做过食品包装线、化工反应釜、汽车零部件装配线三个行业的项目——西门子和三菱的PLC都用过，WinCC和FactoryTalk都碰过，还在客户现场出差加起来小半年。他说自己投了十几家公司——有外企的设备制造商、有甲方工厂的自动化部门、也有更大的系统集成商——大部分简历石沉大海。
我打开他的简历，第一条工作经历长这样：
参与多个自动化系统集成项目，负责PLC程序编写与调试。熟练使用西门子S7-1200/1500、三菱FX5U/Q系列PLC，掌握TIA Portal、GX Works3编程软件。使用WinCC、FactoryTalk View SE开发上位机监控界面。配合项目经理完成现场设备安装指导、系统联调及验收。编写控制系统技术文档和操作手册。
「你这两年做过的项目里，有没有你独立负责的部分——从方案设计到程序编写到现场调试全都你一个人搞定的？」我问他。
「有啊。去年那个食品包装线，整条线的PLC程序就是我一个人写的。从输送带的启停逻辑到六轴机器人的拾放控制，到视觉检测的通信对接——全是我的。」
「那你简历上怎么写的？」
「我想着……写太详细会不会显得我自夸？」
问题就在这里。很多初级自动化工程师把两年里实打实独立交付过的控制系统，浓缩成了一句「负责PLC程序编写与调试」，把所有自己啃下来的技术难题埋在「参与项目」「配合调试」这几个轻飘飘的词后面，然后奇怪为什么甲方和外资设备商不给自己面试。
对自动化工程师的简历来说，有一条和软件工程师简历类似但更容易犯的规则：面试官筛初级自动化工程师的简历，核心看三件事——第一，你有没有独立交付过产线或者控制站？第二，你遇到现场问题的时候是等着别人告诉你怎么查，还是能自己拿着万用表和分析仪一步步定位根因？第三，你写的程序到底给产线带来了什么可量化的效果？ 「熟悉西门子PLC」「掌握TIA Portal」回答不了这三个问题。只有具体的项目、具体的控制方案、具体的故障排查过程和具体的产线指标变化，才能回答。
下面从六个维度，一个一个拆开讲。
先搞清楚：初级自动化工程师的简历要证明什么
在聊具体写法之前，先对齐一件事：自动化经理/技术总监筛一份初级自动化工程师（0-3年经验）的简历，到底在找什么信号。
自动化经理不需要你证明你能独立设计整座工厂的控制架构、不需要你证明你精通五种PLC品牌、也不需要你证明你发过自动化领域的论文。自动化经理对一个工作0-3年的初级工程师的预期非常务实，就四样：
第一，你能不能独立搞定一个控制站或一条工艺段。 给你一个食品灌装工位——4个气缸、2台伺服、1个称重传感器、1台触摸屏。给你工艺要求：灌装精度±2g、节拍不超过3.5秒/件。你能不能从IO点表开始，做完程序架构、写完梯形图和SCL、调完伺服参数、做完HMI画面、在现场把整机跑起来——不需要别人帮你写任何一个功能块？这个能力，「参与PLC程序编写」六个字看不出来——只有把控制方案、程序规模、遇到的难点和最终效果写清楚，自动化经理才能判断。
第二，你到了现场能不能独立排查故障。 这是初级自动化工程师简历里最能拉开差距的东西，也是绝大多数简历里完全缺失的内容。夜里11点，产线突然停机——PLC报了十几个红色的故障灯，操作工说不出到底发生了什么。你到了现场，是等着项目经理远程告诉你「看看是不是传感器松了」，还是你自己先查PLC诊断缓冲区、再用万用表测一遍I/O信号、再看伺服驱动器的故障代码、最后定位到「是一根Profibus DP电缆的终端电阻因为振动松了导致通信间歇中断」？写出一个你独立排查并解决的现场故障案例——这个案例胜过简历里所有「配合调试」的总和。
第三，你的程序到底给产线带来了什么效果。 自动化工程师归根到底是在帮工厂解决三个问题：能不能做得更快（节拍）、能不能做得更好（良品率/精度）、能不能少停机（OEE/故障率）。你的程序写完、调试完、产线跑起来以后——节拍从多少降到了多少？OEE从多少提到了多少？报警误报率降了多少？换型时间缩短了多少？没有这些数字，你就只是一个「会写程序的人」——而不是一个「能用程序解决工艺问题的人」。
第四，你有没有跨专业沟通的能力。 自动化工程师是一个「夹在中间」的岗位——上游要跟机械工程师沟通设备动作逻辑、跟工艺工程师沟通工艺参数和控制目标；下游要跟电气工程师对IO点表、跟操作工解释HMI操作流程。面试官想知道：你有没有在项目里主动找机械工程师确认过一个气缸的行程时间？你有没有因为操作工说「你这个界面我看不懂」而重新设计过HMI的布局？你有没有在验收时跟甲方的设备经理解释过你的控制逻辑为什么这样设计？
带着这四个问题，下面从六个维度一个一个拆。
一、控制系统编程：别写「负责PLC程序编写」，写你面对什么工艺需求、设计了什么控制方案、解决了什么难点
PLC/DCS编程是自动化工程师简历最核心的部分，也是写得最像「技术名词购物清单」的部分：
改前案例
参与多个自动化项目的PLC程序开发与调试。熟练使用西门子S7-1200/1500系列PLC，掌握TIA Portal V16/V17编程平台，能独立完成梯形图（LAD）和结构化控制语言（SCL）的程序编写。使用过三菱FX5U/Q系列PLC，掌握GX Works3编程。熟悉伺服驱动器、变频器的参数设置与调试。掌握Modbus TCP/RTU、Profinet、EtherCAT等工业以太网通信协议。
这段话，自动化经理看完脑子里只有一个信息：这个人用过西门子和三菱的PLC，写过梯形图。但他这两年写的程序到底解决了什么问题、程序复杂到什么程度、有没有自己设计过控制逻辑——一概不知。
「熟悉Profinet通信」——你是调过一两个GSD文件让变频器和PLC能通上，还是独立设计过一条产线上12个从站之间的实时数据交换架构？「能独立完成梯形图」——是写了几个自锁互锁的启停逻辑，还是设计过包含30个功能块的复杂顺序控制程序？
正确写法：每个项目的PLC经验写成三个层次——工艺需求 → 控制方案 → 关键难点
食品包装线控制系统（独立负责PLC编程与调试）| 西门子S7-1200 + TIA Portal V17
工艺需求： 整条包装线包含7个工位——自动上料、视觉定位、六轴机器人拾放、称重检测、封口、喷码、自动码垛。核心要求：节拍 ≤ 45件/分钟、称重精度 ±1g、机器人抓取成功率 ≥ 99.5%。
我的控制方案：
- 程序架构：采用模块化设计，每个工位封装为独立功能块（FB），主程序通过状态机和握手信号协调各工位之间的物料流转。整机程序量约2800行（LAD + SCL），包含23个自定义FB和15个FC。
- 多轴同步：六轴机器人通过Profinet与S7-1200进行实时数据交换——PLC向机器人发送抓取坐标（来自视觉系统的Modbus TCP数据）、机器人向PLC反馈抓取完成信号和状态字。我设计了双缓冲握手机制：机器人在执行当前拾放动作时，PLC已将下一个物料的坐标写入机器人控制器的备用缓冲区——消除了机器人等待坐标数据的时间，将机器人空闲等待时间从约350ms压缩到约50ms。
- PID控制：热封口工位的温度控制采用S7-1200内置PID_Compact功能块。封口膜的加热棒是一个典型的大惯性滞后系统——温度从设定值变化到实际值稳定需要约90秒。我用TIA Portal的PID自整定得到初始参数后，观察到超调量偏大（最高超调约12℃），手动将比例增益Kp从自整定的3.2降到2.1、积分时间Ti从35s加到52s——最终温度稳态误差控制在±0.5℃以内、超调量压到2℃以下。
- 安全逻辑：整条线包含4个急停按钮、2个安全光幕、5个安全门开关。所有安全信号接入S7-1200F故障安全型CPU的F-DI模块——安全程序使用西门子Distributed Safety编写，安全回路响应时间经测试 ≤ 15ms，满足ISO 13849-1 PL d等级。
调试中独立解决的关键问题：
产线试运行时出现一个奇怪的现象：每隔大约40分钟，输送带会莫名其妙停2-3秒然后自动恢复。PLC的诊断缓冲区没有任何报警记录。操作工抱怨「这条线不稳定」，但没有人能复现。我在现场用TIA Portal的在线监控功能盯了差不多一个小时——在故障发生的瞬间捕捉到一个细节：急停按钮的输入信号闪了一下——从TRUE变成FALSE持续约8毫秒后又恢复了。8毫秒太短了，短到正常的急停逻辑判断周期不至于触发停机——但我写的安全程序采样周期设为4毫秒，恰好捕捉到了这个毛刺。
我用万用表量了急停按钮的接线——发现急停按钮的常闭触点接线端子上有一根线压在了绝缘皮上而不是铜芯上。振动导致间歇性接触不良，产生了一个毫秒级的信号抖动。重新压线后，故障消失——产线稳定运行72小时无停机。
产线效果： 最终节拍稳定在43件/分钟（目标45）、称重精度 ±0.8g（目标 ±1g）、机器人抓取成功率达99.7%（目标99.5%）。产线从调试到验收的周期约3周——比项目经理预估的4周缩短了25%。
自动化经理读完这段经历，看到的不是一个「用过西门子PLC」的工程师，而是一个**「能独立设计7工位包装线的控制架构、用双缓冲机制把机器人等待时间从350ms压缩到50ms、能手动整定PID让温度超调从12℃压到2℃、在现场用在线监控捕捉到8毫秒的急停信号抖动并最终定位到是一根线压在了绝缘皮上的工程师」** 。他看到了控制方案的设计思路、看到了程序规模、看到了独立排查故障的完整链路——更关键的是看到了「我设计了、我调试了、产线跑到了什么指标」这个完整的交付闭环。
控制系统编程的写作公式
项目名称 + 工艺描述（几个工位、什么工艺） → 你用的PLC品牌+型号+编程平台 → 程序规模（行数/FB个数/FC个数，大概即可） → 1-2个你设计的关键控制逻辑（多轴同步？PID整定？通信架构？安全逻辑？状态机设计？） → 1个你独立解决的调试难题（什么现象 → 你怎么分析 → 最终定位到什么根因） → 产线跑出来的量化效果（节拍/精度/OEE）
这个公式有三个关键点：
第一，程序规模和架构比技术名词有价值一百倍。 「用TIA Portal编写PLC程序」不如「整机程序量约2800行、包含23个FB和15个FC、采用状态机协调7个工位之间的物料流转」。前者告诉自动化经理「你会用这个软件」——但任何一个培训两周的应届生也会用；后者告诉自动化经理「你能独立做中等复杂度的程序架构设计」。
第二，控制方案要写出你的设计决策。 「使用PID控制温度」不是设计——任何一个PLC工程师都会调PID。你要写的是：你面对了一个什么特性的被控对象（大惯性滞后？非最小相位？强耦合？）、你选择了什么控制策略（单回路PID？串级？前馈+反馈？）、你遇到了什么问题（超调太大？响应太慢？）、你做了什么调整（改了什么参数、换了什么控制结构）、最终达到了什么效果。这个「面对特性 → 选择策略 → 遇到问题 → 调整优化 → 达到效果」的链条，才是一个控制工程师的核心能力。
第三，调试难题不要写成「协助完成调试」。 写一个你在现场独立排查并解决的具体故障——现象、你的分析步骤、你用了什么工具（万用表？示波器？在线监控？诊断缓冲区？报文抓取？）、定位到了什么根因、修复后结果。一个真正好的调试案例，胜过十个「配合调试」。
二、SCADA与HMI开发：别写「开发了上位机界面」，写你为操作工解决了什么信息盲区
SCADA和HMI是自动化工程师简历里最容易写成「画了几个画面」的板块——但也恰恰是最能体现「你有没有站在操作工的角度思考问题」的板块：
改前案例
使用WinCC和FactoryTalk View SE开发上位机监控界面，包括工艺流程画面、设备状态监控、报警管理、趋势曲线、数据报表等模块。HMI界面使用西门子精智面板和威纶通触摸屏开发，操作界面简洁直观、操作流程符合现场作业习惯。
这段话面试官看完，只知道你用过WinCC和FactoryTalk、画过画面。但你画的画面到底是「能用」还是「好用」？你的报警管理——是报警来了全屏弹窗，还是分了三六九等按优先级推送？你的趋势曲线——是做了几个Y-T图丢在那儿，还是帮工艺工程师做了关键参数的关联对比分析？「操作界面简洁直观」——是你的主观判断，还是操作工真实反馈的结果？
改后案例
我对SCADA/HMI开发的理解不是「把PLC里的数据搬到屏幕上」——是「让操作工在最短的时间内看到最需要的信息、做出最准确的判断」。一个好HMI的标准不是画面画得多好看——是夜班凌晨三点的时候，操作工能不能一眼看出哪台设备不对劲、问题有多严重、他应该先处理哪个。
案例一：从「报警风暴」到「三级报警分级推送」——我帮操作工把报警响应时间从8分钟压到2分钟。
在一个化工厂反应釜控制系统的SCADA开发中，甲方工艺主管在需求评审时提了一个让我印象深刻的抱怨：「你们的SCADA老报警。一报警就是几十条全弹出来——高温报警、压力报警、液位报警、泵故障、阀门不到位——操作工根本不知道该先看哪个。结果就是关掉报警弹窗、当没看见。」这就是典型的「报警风暴」——报警没有优先级，所有报警对操作工来说都是噪声。
我没有只是把报警从「全弹窗」改成「列表滚动」——因为列表滚动只是换了一个展示方式，没有解决「操作工不知道该先处理哪个」这个核心问题。我做了三级报警分级体系：
一级报警（红色-立即处理）： 可能造成设备损坏或安全事故的报警——反应釜超温（T > 设定值 + 15℃）、超压（P > 设定值 + 10%）、有毒气体检测报警、急停触发。一级报警触发时——不仅SCADA画面弹出红色醒目提示，还通过工业短信猫向车间主任和值班技术员的手机发送短信告警。
二级报警（橙色-10分钟内处理）： 影响产品质量但不立即造成安全风险的报警——温度偏离工艺窗口但不超限、液位偏高/偏低、泵运行电流异常。二级报警在全屏画面以橙色滚动条提醒、无需手动确认。
三级报警（黄色-关注）： 提示性报警，不影响正常运行但需要关注趋势——过滤器压差升高（提示需要更换滤芯）、电机运行时间累积达到保养周期、仪表信号轻微波动。三级报警在屏幕底部以黄色小图标显示、不弹窗、不打断操作。
我自己写了一套报警触发和判断脚本——在PLC程序里用SCL实现了报警死区（防止临界值来回跳变造成报警风暴）和报警延时确认（瞬时波动不报警、持续超过N秒才报）。这套逻辑上线后，产线的每日报警数量从过去的150条/天降到了约40条/天——不是报警少了，是噪声被过滤了——真正需要操作工关注的报警一条都没有漏。
操作工最直观的反馈是：「以前报警一来就几十条红字，我关掉就当没看见。现在红色报警就一两条——我一眼就知道要去处理什么。」报警响应时间从之前的平均约8分钟缩短到了约2分钟。甲方工艺主管在验收时专门提了一句：「报警系统是这次改造里我们最满意的地方。」
案例二：趋势曲线不只是「画几条线」——帮甲方工艺工程师做了一键关联对比。
在同一个项目中，我发现甲方的工艺工程师在使用历史趋势时有一个固定的操作模式：每次看趋势，他总是先点开反应釜温度的曲线、再点开夹套温度的曲线、再点开搅拌转速的曲线——三条曲线打开、对齐时间轴、对比看——每次操作至少要花三四分钟。
我在趋势画面里做了一个「一键关联对比」功能：工艺工程师只需要选择一个主参数（比如反应釜温度），系统自动在同一个趋势图上叠加关联参数（夹套温度、搅拌转速、进料流量）——并且把时间轴自动对齐到主参数出现最大波动的那个时间点。这个功能上线后，甲方工艺工程师跟我说了一句：「以后再也不用一个一个点了——以前看一次趋势要五分钟，现在15秒。」
HMI的价值从来不在于你画了多少个画面——在于你帮操作工和工艺工程师省了多少时间、消除了多少认知负担。
面试官读完这两段，脑子里不是一个「用过WinCC」的工程师，而是一个**「能从甲方的一句抱怨出发、设计出三级报警分级推送体系、报警响应时间从8分钟压到2分钟、还能从工艺工程师的操作习惯中发现痛点做出15秒一键关联对比的人」**。这就是从「把PLC数据搬到屏幕上」到「让操作工的工作更高效更安全」的跨越。
SCADA/HMI的写作公式
你面对的操作痛点（操作工/工艺工程师的真实抱怨或低效操作） → 你的设计思路（不是「画了什么画面」——是「为了解决什么认知/操作问题做了什么设计决策」） → 具体的功能实现 → 量化效果（报警数量变化、响应时间变化、操作步骤减少、操作工/甲方的正面反馈）
三、传感器与现场仪表：不要只写「熟悉各种传感器」，写你在什么工况下选了什么传感器、为什么
传感器和现场仪表是自动化工程师的「感官」——但初级工程师的简历里，这部分往往被压缩成一行：
改前案例
熟悉各类工业传感器和现场仪表的使用与调试，包括温度传感器（热电偶、热电阻）、压力变送器、流量计、液位计、接近开关、光电传感器、编码器等。
面试官的内心OS：「所以呢？任何一个读过自动化专业的本科生都能写出这句话。」你不知道这个人是在洁净的实验室里用传感器做毕业设计，还是在粉尘弥漫的铸造车间里给高温传感器做冷却保护——这两种「用过」的含金量天差地别。
改后案例
我对传感器和仪表选型的理解不是「照着设备清单买」——是根据实际工况决定用什么传感器、怎么安装、怎么保护，才能让它在现场跑三年不出问题。
在食品包装线上做过的传感器选型与调试：
- 灌装工位的液位检测要求精度 ±0.5mm——用来判断瓶中液位是否合格。传统浮子式液位计在这个速度下响应不过来（灌装速度45瓶/分钟，单瓶灌装时间只有约1.3秒）。我选择了基恩士激光位移传感器（IL系列），采样周期2ms，通过RS-485 Modbus RTU直接跟PLC通信——避开模拟量信号在长线缆上的压降和噪声问题。安装时额外做了一个吹气清洁装置——用压缩空气持续吹扫传感器镜头，防止灌装时飞溅的液滴遮挡光路。
- 在称重工位遇到一个问题：输送带运行时称重读数抖动很大——大到±3g的波动，而客户要求的称重精度是±1g。我排查后发现不是称重传感器本身的问题——是输送带的电机和减速机振动传导到了称重台面。我用了三个方法解决：1）在称重台面下面加了四个橡胶减震垫隔离机械振动；2）在PLC程序里做了10ms滑动平均滤波；3）在物料进入称重台面前增加了一个0.5秒的稳定延时——确保物料完全静止后再读取称重值。三个措施叠加，称重精度从±3g提高到了±0.8g。
- 安全光幕选型——包装线机器人区域需要用安全光幕做人员防护。我选择了SICK deTec4系列，保护高度900mm，分辨率14mm（手指保护级别）。安装高度根据ISO 13855标准计算——光幕底部距地面 ≤ 300mm、顶部距地面 ≥ 900mm，确保无法从上方跨越或从下方钻入。安全光幕通过OSSD安全输出直接接入S7-1200F的F-DI模块——没有经过中间继电器，减少了故障点。
面试官读完这段，脑子里不是一个「用过传感器」的工程师，而是一个**「在45瓶/分钟的高速灌装线上选用了激光位移传感器替代浮子液位计、用吹气清洁方案解决镜头污染、用减震垫+滑动滤波+稳定延时三管齐下把称重精度从±3g做到±0.8g、还能按ISO标准计算安全光幕安装高度的工程师」**。他看到的不是传感器型号列表——是面对真实工况时的判断力和解决问题的工程方法。
传感器与仪表的写作要点
三个层次：
- 选型——你用了什么传感器/仪表、什么品牌什么型号（不是「压力变送器」——是「E+H PMP71压力变送器」）、因为什么原因选了它（精度要求？响应速度？耐温耐压？防爆等级？）
- 通信——传感器跟PLC怎么连的（4-20mA？Modbus RTU？IO-Link？Profinet？）、通信距离多远、有没有遇到过信号干扰
- 工况适应——现场环境有什么挑战（高温？粉尘？振动？腐蚀？）、你做了什么保护措施或安装方式、传感器在现场的实际表现
四、调试与故障排查：面试官最想看到的，绝大多数自动化简历里没有
如果说PLC编程是自动化工程师的「脑」，那现场调试和故障排查就是「手和脚」。一个会写程序但到了现场抓瞎的工程师，在自动化这个行业里走不远。而最残酷的是——绝大多数初级工程师的简历把这部分写成了「配合完成调试」。
改前案例
参与项目现场的设备调试和系统联调，配合机械和电气工程师完成设备安装指导。对现场出现的自动化系统故障进行分析和处理，确保产线按时投入运行。
这句话等于什么都没说。你配合谁、做了什么、处理过什么故障——全是一团雾。面试官看到「对现场故障进行分析和处理」——反应不是「这个人有排查能力」，而是「这个人可能只是站在旁边看」。
改后案例
现场调试中最刻骨铭心的一次故障排查——「通信闪断」的72小时
一个汽车零部件装配线项目，客户现场是一套西门子S7-1500做主站、挂了15个ET200SP分布式IO从站——通过Profinet环网连接。产线在调试阶段一切正常，但正式投产后第三天就开始出问题：每隔2-4小时，整条线突然停机——所有从站同时掉线、CPU报BF（总线故障）红灯、约5-10秒后自动恢复。每天发生6-8次。
客户的生产经理急了：「你们这条线一天停七八次——我一天的产量损失十几万。你们到底能不能搞定？」
项目经理让我去现场排查。我到现场的第一件事不是换网线、不是换交换机——是先把CPU的诊断缓冲区导出来，逐条看故障前后的事件记录。诊断缓冲区显示：每次停机前，15个从站中有2-4个从站几乎同时报「看门狗超时」——从站与主站的Profinet通信丢失。但每次「掉线」的从站不是固定那2-4个——每次都不一样。
这是关键线索——如果是某一段网线或者某一个交换机端口坏了，那么每次出问题的应该是固定那几个从站。问题出在「公共节点」上——很可能是环网中的某个交换机。
我用PRONETA工具对整个Profinet网络做了拓扑扫描——发现环网中有一个SCALANCE XB008交换机的端口4存在间歇性CRC错误计数在涨。但这个交换机安装在产线底部的一个狭小空间里——旁边就是一台大功率伺服驱动器的动力线缆。我用示波器在这个交换机的网线上抓到了一组明显的噪声波形——频率跟伺服驱动器的PWM载波频率（4kHz）完美对上。伺服驱动器一启动，动力电缆的电磁辐射就耦合到了旁边紧挨着的网线上——干扰了Profinet通信。
解决方法：把网线从原来的非屏蔽超五类换成了工业级屏蔽网线（S/FTP双屏蔽）、把网线布线路径从原来贴着动力线缆改为走对面的金属线槽（物理隔离约40cm）、在交换机这一端加了TDK的磁环滤波器。三个措施部署后，CRU错误计数归零——产线连续运行72小时零停机。
客户的生产经理第二天给我发了一条微信：「昨天晚上夜班一次都没停——终于可以睡个安稳觉了。」此后这条产线运行半年，Profinet通信问题再没有复发过。
这次经历让我记住了一件事：自动化故障排查，最难的不是修——是定位。 你面前可能是一百个可能的故障原因——网线、交换机、终端电阻、电磁干扰、IP冲突、固件版本不兼容——你需要在现场用工具和逻辑一步步排除、一步步缩小包围圈，直到找到那根「压在绝缘皮上的线」或者那根「贴着动力电缆的网线」。这个能力，是纯办公室的PLC程序员永远学不到的。
面试官读到这里，脑子里不是一个「配合完成调试」的工程师，而是一个**「能从诊断缓冲区中发现『每次掉线的从站不一样』这个关键线索、用PRONETA做网络拓扑扫描定位到间歇性CRC错误、用示波器在网线上抓到伺服驱动器的4kHz PWM噪声、最终用屏蔽网线+物理隔离+磁环三管齐下彻底解决问题的工程师」** 。这已经不是「调试」了——这是独立完成了一个完整的故障诊断闭环。这种现场经验，在初级自动化工程师的简历里极度稀缺。
故障排查的写作公式
故障现象（什么设备、什么症状、多大影响） → 你的分析步骤（第一反应做了什么检查、发现了什么线索、这个线索让你排除了哪些可能性、缩小了范围） → 你用了什么工具（万用表？示波器？诊断缓冲区？PRONETA？Wireshark？报文抓取？） → 最终定位到什么根因 → 你怎么修好的 → 修好后有没有复发
五、项目交付与文档能力：别只写「编写技术文档」，写你的文档为什么经得起翻查
文档能力在自动化行业里被严重低估——但它决定了一个初级工程师能不能从「干活的」变成「能独立负责项目的」：
改前案例
编写项目技术文档，包括控制系统设计说明书、IO点表、电气原理图、操作手册等。整理项目验收资料，配合甲方完成项目验收。
这段话等于什么都没写——「编写技术文档」是岗位基本要求。
改后案例
我对技术文档的要求不是「验收的时候能交差」——是「一年以后产线出了故障，任何一个新来的工程师拿着我的文档能在半小时内搞清楚控制逻辑、找到故障点」。
在一条化工反应釜控制系统的项目中，我的文档交付包包含：
- 控制逻辑说明书（32页）：不是「概述控制系统功能」——我画了完整的控制流程图（PFC），每一个控制回路的设定值来源、反馈来源、控制算法、联锁条件和安全联锁逻辑全部标注清楚。我的标准是：任何一个没有参与过这个项目的自动化工程师，读完这份说明书，能理解整条产线的控制逻辑为什么这样设计——不需要来问我。
- IO点表（含注释栏）：不只列了信号类型和地址——每一个IO点我都写了「安装位置」「量程」「报警阈值」「联锁逻辑序号」和「调试时实测值」。甲方设备经理翻完后说：「你们的点表是我见过最详细的——以前供应商的点表就三列，你们的有十列。」
- 调试记录（18页）：记录了调试过程中遇到的每一个异常和解决方案——PID参数调整过程（初值→现象→调整→新值→效果）、通信故障排查记录、传感器标定数据。这些记录在项目结束后半年，甲方自己维护团队遇到了一个类似的通信故障，翻出我的调试记录直接用——没有打电话找我们售后。
后来这个甲方的项目经理在二期招标时，点名要我去做：「技术方案各家报价都差不多——但我们知道你的文档质量，后续维护省心太多。」
文档能力写作公式
你交付了什么文档（别只说「技术文档」——列出具体名称和页数） → 你的文档比行业平均水平多了什么（注释？调试记录？故障排查指南？控制逻辑的why而不仅是what？） → 文档带来的实际价值（甲方的反馈？后续项目的复利效应？甲方维护团队自行解决过问题？）
六、自我评价：别写「学习能力强、能吃苦、能适应出差」，写自动化工程的具体事件和数字
自动化工程师的自我评价，是技术类岗位里模板化最严重的：
改前案例
自动化专业本科，2年工业自动化系统集成经验。熟悉西门子、三菱PLC编程及调试，掌握TIA Portal、GX Works3等编程平台。熟练使用WinCC和FactoryTalk View开发SCADA/HMI系统。熟悉Profinet、Modbus TCP等工业网络通信协议。具备独立完成中小型自动化项目的能力。学习能力强，能快速上手新技术。吃苦耐劳，能适应长期出差和现场工作。良好的团队协作和沟通能力。
这段话没有任何致命错误——但它也没有任何一条能让面试官记住你是谁。「熟悉西门子PLC」——投这个岗位的50份简历里有45份写了这句话。「吃苦耐劳、能适应出差」——所有做自动化的都出差，写了等于没写。
改后案例
- 独立交付能力： 独立完成过3条产线的控制系统——食品包装线（西门子S7-1200、7工位、节拍43件/分钟）、化工反应釜（西门子S7-1500、DCS架构、6个控制回路PID整定）、汽车零部件装配线（三菱Q系列、15个Profinet从站、含机器人通信和视觉引导）。每条线都是从IO点表做到现场调试和验收——不是「在leader指导下完成」。
- 现场故障排查能力： 独立解决过的现场问题包括——通过诊断缓冲区和PRONETA网络扫描定位到Profinet通信间歇闪断根因（伺服驱动器PWM噪声耦合、用屏蔽网线+物理隔离+磁环解决）、通过在线监控捕捉到8毫秒急停信号毛刺定位到接线压绝缘皮、用减震垫+滑动平均滤波+稳定延时把称重精度从±3g提到±0.8g。到现场不靠猜、不靠换件——靠工具和逻辑链一步一步定位根因。
- 控制算法能力： 不是只会调PID自整定——面对大惯性滞后系统（封口加热棒、反应釜夹套温度），能根据被控对象特性手动整定PID参数（Kp、Ti、Td），能将温度超调量从12℃压到2℃以内、稳态误差控制在±0.5℃。在六轴机器人拾放场景中，通过双缓冲握手机制将机器人空闲等待时间从350ms压缩到50ms。
- 用户视角： 做SCADA/HMI不是把PLC数据搬上屏幕——是站在操作工的角度解决信息盲区。帮化工厂操作工把报警从每天150条无优先级区分变成三级报警分级推送——报警响应时间从平均8分钟压缩到2分钟。帮甲方工艺工程师做了一键关联对比功能——趋势分析从每次5分钟缩短到15秒。甲方工艺主管验收时专门表扬了报警系统——「是这次改造里我们最满意的地方」。
四行。面试官15秒扫完，脑子里留下四个标签：这个人独立交付过3条产线（包装、化工、汽车零部件——不是纸上谈兵）；到现场能定位通信闪断、信号毛刺、称重漂移这些棘手故障——而且每个都有完整的分析思路和解决工具；PID不是只会按自整定——能根据对象特性手动调参把超调压下来；做HMI不是只画画面——是站在操作工角度解决信息过载和操作效率问题。每一项标签背后都是一个可以展开聊半小时的真实工程案例。
而原版自我评价扫完15秒，只记得：「哦，又一个会用西门子PLC、能出差的自动化工程师。」
自我评价的铁律： 每一行 = 一个核心能力方向 + 你亲自操刀的项目/事件 + 至少两个数字。任何换一个自动化工程师也能写的标签（「熟悉XX」/「吃苦耐劳」/「能适应出差」）——全删。
写完后的自检清单
- PLC编程部分——有没有写过一个你独立交付的项目：什么产线/设备、什么品牌PLC、程序规模（大概行数/FB个数）、1-2个你设计的关键控制逻辑、1个调试中你独立解决的难题——最后产线跑到了什么指标？如果只写了「熟悉XX PLC」，回去重写。
- SCADA/HMI部分——有没有写出你为操作工解决的痛点（报警风暴？信息过载？操作繁琐？）和量化效果（响应时间缩短、操作步骤减少、操作工反馈）？如果只写了「开发了XX界面」，等于没写。
- 传感器与仪表部分——有没有写出具体品牌型号、为什么选它、什么通信协议、什么工况、做了什么保护——不只一行「熟悉各种传感器」。
- 故障排查部分——有没有至少一次你在现场独立完成的故障诊断完整闭环：现象→分析步骤→使用的工具→定位的根因→修复方案→结果？如果没有——这是初级自动化工程师简历里最致命的缺失。现场故障排查能力是面试官判断「这个人能不能独立去客户现场」的第一标准。
- 调试经历里，有没有任何一次你搞了超过半天才找到根因的棘手问题？那种「插上网线就好了」「重启PLC就好了」的不算——要写那种你用工具和方法一层层剥开的复杂故障。
- 「参与」「协助」「配合」「在指导下」在你的简历里出现了多少次？把它们全删——看看剩下的句子还能不能独立表达你做了什么。如果不能，说明你写的是岗位JD的复述，不是你。
- 每个项目经历至少带两个量化数字：节拍时间、OEE、良品率、报警响应时间、称重精度、温度超调量、调试周期、通信延迟——自动化这个行业，没有数字的问题描述就是空话。
- 自我评价删到只留4条以内——每一条都是一个自动化工程方向+你亲自做过的项目或事件+至少两个数字。删掉「学习能力强」「吃苦耐劳」「能适应出差」「熟悉XX品牌PLC」。
- 把你的简历发给一个做自动化的朋友，问他：「如果让你带这个人去现场做项目，你最放心让他独立负责什么？最不放心什么？」他答不上来——回去补项目细节和故障排查案例。
初级自动化工程师写简历，最大的陷阱是觉得自己是「搞技术的」——所以把会用多少种PLC、多少种通信协议、多少种编程语言全罗列上去，觉得技术名词越多简历越强。
但自动化经理筛简历的时候，脑子里想的不是「这个人懂几种PLC」——而是「下个项目派他去现场，他能不能独立把产线调通」。你用的PLC品牌多，不证明你独立搞定过产线——只能证明你在每个平台上都浅尝辄止。你列了七八种通信协议，不证明你处理过通信故障——只能证明你看过协议手册的目录。
把你独立交付过的项目写出来——不是「参与XX项目PLC编程」，是「独立完成食品包装线7工位控制系统，从IO点表做到验收，节拍43件/分钟、称重精度±0.8g」。把你独立排查过的故障写出来——不是「配合调试工程师处理故障」，是「在客户现场用诊断缓冲区和PRONETA定位到Profinet通信闪断根因——伺服驱动器PWM噪声耦合到网线、用屏蔽网线+物理隔离解决」。把你帮操作工做的优化写出来——不是「开发了SCADA界面」，是「三级报警分级推送让报警响应时间从8分钟降到2分钟、一键关联对比让趋势分析从5分钟缩短到15秒」。
自动化工程师的简历，本质上是对三个问题的回答：你能独立搞定一条产线吗？你到了现场能自己查故障吗？你写的程序到底让产线变好了多少？「熟悉西门子PLC」回答不了这三个问题，「能适应出差」也回答不了——只有具体的项目、具体的控制方案、具体的故障排查链路和具体的产线指标变化，才能回答。
把你的TIA Portal最小化。打开那几条你交付过的产线的调试记录。回忆一下那根你查了两天才找到的压在绝缘皮下面的线、那个你手动调了八组参数才稳定的PID回路、那次凌晨三点产线突然停机你一个人在现场用万用表一根线一根线量的经历。把这些写出来——不是「我会PLC编程」——而是「我在现场」。
写好之后不确定效果？好简历的免费诊断可以帮你从项目陈述、成果量化、匹配度和表达清晰度几个维度做一次全面扫描，每一段经历都会给出强弱项分析和改进建议。