先说结论：值得，但不是所有人现在都要学到同一个深度。这篇把最近圈里的争论、SCL的真实边界、以及不同处境的人该怎么投入，一次讲清楚。
这轮争论是怎么烧起来的
7月中旬，知乎上一篇叫《梯形图已死》的文章在工控圈炸开了锅。作者话说得很重：都2026年了还死磕梯形图，是在给自己的职业生涯挖坟墓。它的核心论点其实就一条——AI的"母语"是文本语言。知乎
差不多同一时间，做AI生成PLC程序的团队RealPLC发了篇官方解释：为什么目前只支持ST/SCL、不支持梯形图？理由很直白——大模型的训练语料里，TypeScript、C、Java这类开源代码海量，梯形图的资料极少，而ST这类文本语言可以直接借鉴C/C++的算法积累，实测生成效果也明显更好。知乎
这波讨论一直烧到8月。有意思的是，吵归吵，两边的老工程师最后给出的答案高度一致，跟我看了一圈知乎专栏、B站教程评论区之后的判断也一样：不是谁取代谁，是分工。知乎
把情绪放一边：双方到底在吵什么
把两边的观点拆干净，其实吵的是三个层面的事：
第一层，AI生成能力。 这是真的差异。梯形图是图形，大模型生成和验证都困难，目前主流AI写PLC代码，输出基本都是ST/SCL。想做"描述需求→AI出代码→编译验证"这套新玩法，你只会梯形图就接不住。有人把话说得更绝对：ST是AI时代实现PLC编程的最佳方式，至少目前是。知乎
第二层，复杂逻辑的开发效率。 一位干了8年PLC的工程师讲过自己的实测：我做过一个50个电机的项目，梯形图复制了50次，光找bug就找了一天；同样的需求用SCL，代码不到50行，调试2小时搞定。知乎这种量级差距，做过批量设备的人应该都有共鸣。
第三层，现场维护和安全性。 这是反方最硬的阵地。安全PLC、SIS安全连锁系统至今大量使用梯形图；工厂里大量老程序是梯形图写的，得有人维护；现场电工排查故障，看触点线圈比读代码快得多。知乎连激进的"已死派"都承认这一点。
所以真实的工程共识是：简单互锁、安全回路、维护为主的场景留给梯形图；运算、数组、通信解析、PID这类逻辑交给SCL，大项目两种语言混着写。
SCL的真实边界：哪些事它干不了
想判断值不值得学，先要知道SCL在你手里的设备上到底能不能用。这几个事实经常被搞混：
S7-1200 / S7-1500：博途（TIA Portal）里原生支持SCL，新建块直接选语言就行，不用装任何东西。
S7-200 SMART：不支持SCL。如果你的活儿全在200 SMART上，学SCL对眼前项目没有直接收益。
S7-300 / 400：经典的STEP 7环境里，SCL是选件包（S7-SCL），需要单独安装授权。知乎
场景上，圈内对比下来基本是这个格局：电机启停这类简单逻辑，梯形图扫一眼就懂，SCL反而要读代码；但一到"100个采样值找最大值"这种数组操作，SCL五行搞定，梯形图要间接寻址加循环跳转画好几个网络；PID自己写、Modbus报文解析这些，SCL的优势是碾压级的。一句话概括：梯形图擅长逻辑控制，SCL擅长数据处理。知乎
另外两个流传很广的误解也该澄清：一是"SCL不能在线监控"——博途里断点、单步、变量监视都有；二是"写得慢、执行慢"——在S7-1200/1500上，各语言编译后执行效率没有实质差别，选型不用考虑性能。知乎
先自测：你属于哪一类，就学到哪个深度
第一类：以维护、维保为主的电工。 日常是保产线跑着，不怎么写新项目。你的优先级仍然是把梯形图读透，SCL只需要学到"能看懂"——认识IF、FOR、CASE，能看懂同事写的块在干什么。投入两三个周末足够，不必深入。
第二类：做项目的中段工程师（这是这轮争论里最该行动的人）。 会梯形图，做过几个项目，开始接到带通信、带数据采集、配方管理的需求。SCL对你不是加分项，是必需品——新项目越来越多直接要求SCL，尤其汽车、半导体行业。知乎建议系统学，目标是能独立用FB封装功能。
第三类：学生、准备入行的新人。 梯形图要会看（现场维护绕不开），但编程能力的主线直接押SCL。理由很现实：一是它和高级语言思维一致，迁移成本低；二是AI工具链都长在文本语言上，会用SCL，你才能吃到AI辅助编程的红利，而不是被AI替代。
梯形图思维转SCL，三个最容易摔的坑
看B站教程的评论区，翻车的几乎都在这三处，提前知道能省很多时间：
坑一：扫描周期的思维惯性。 梯形图里一个支路，条件满足就"通"，大家习惯了。到了SCL，有人就问出过这种问题：“这句赋值不在循环里，每个扫描周期不都会执行一遍吗？”——答案是会，所以实际工程里要靠上升沿指令做触发，让代码只在该执行的那一个周期执行。哔哩哔哩这是从"看图"思维到"读文"思维最核心的一跳。
坑二：把SCL写成"文字版梯形图"。 一行行平铺直叙地翻译触点线圈，写出来的代码比梯形图还难读。SCL的价值在结构化：FOR循环、数组、CASE、FB封装。50台电机不是写50段，而是一个循环加一个数组。知乎
坑三：FB和FC分不清。 需要保存状态的（比如电机运行状态、通信状态机）用FB，配背景数据块；纯计算、无状态的（比如工程量转换）用FC。混着用，后期维护就是灾难，很多初学者容易混淆两者的使用场景，导致程序设计不合理，后期维护困难。知乎
最小投入路线：按这个顺序学
如果决定学，别从语法手册第一页啃起。圈里验证过的高收藏内容，基本都指向同一条路径：
先过语法关：SCL核心就是IF、FOR、CASE加上赋值，有C语言基础的人上手很快，没基础的一两周也够。
练数组+循环：这是SCL相对梯形图的第一个爽点。B站8月中旬刚更新的"数组+FOR循环10个实用案例"可以直接跟着敲，UP主还把源码放了出来。哔哩哔哩
拿通信开刀：Modbus轮询是SCL的成名场景——有个收藏量2000+的经典案例，100个从站的轮询通信，用SCL十几行代码搞定，比梯形图编程要简单许多，适合PLC采集10个以上仪表数据的场合。哔哩哔哩
攒框架：7、8月份B站连续更新的"十大经典SCL程序"和"十大SCL程序框架"，本质是状态机、调度、报警这些通用结构的现成写法，收藏下来在项目里直接套。哔哩哔哩哔哩哔哩
资源方面，B站有个持续更新的SCL系统教程，播放57万+、收藏2.2万+，从基础语法到项目实战都覆盖了，官方简介明确说适合已学过LAD、FBD、STL中任意一种或有高级语言基础的人。哔哩哔哩遇到具体卡点，知乎上"如何系统学习SCL"这类问题的描述，本身就是梯形图工程师想转型的真实画像，提问的人往往只会梯形图和功能块图这种图形化编程。知乎
往后值得盯的三个信号
这篇文章不劝你焦虑，但有三件事值得放进关注列表：
一是AI生成PLC代码的闭环进度。RealPLC这类工具的路线很明确：先把ST/SCL的"生成→编译→验证"闭环做稳，再考虑梯形图。知乎这套工具一旦成熟，会写、会审、会改SCL的工程师，就是第一批拿到杠杆的人。
二是项目需求里的语言要求。接新项目、看招标时留意"编程语言"那一栏，SCL出现的频率就是市场温度。
三是国产和日系阵营的跟进。三菱叫ST、欧姆龙也有对应文本语言，IEC 61131-3的结构化文本是同一套标准下的方言，在西门子上学到的SCL，大部分能力可以平移。
一句话收尾：梯形图没有死，它只是回到了自己最擅长的位置；而SCL，已经从"进阶选修"变成了项目工程师的必修。想清楚自己是哪一类人，然后按最小路线开始就行。
