每到月初我都会把自动化与工控这个圈子里过去30天讨论最密集的内容翻一遍既是给自己做行业简报也是为了找接下来一段时间的技术选题和项目方向。6月这一轮的信息量明显比前两个月大而且分成了两条很清晰的主线工业现场那一侧大家在盯着国产化工控平台的落地案例以及工控安全标准到底怎么落到企业里软件工具这一侧自动化测试工具链的更新、AI Agent和各种自动化工作流的新玩法占据了大量版面。这篇文章就把6月值得真正花时间看的内容挑出来逐个展开聊我自己的经验教训也会一并整理进去。无论你做自动化测试、工控系统集成还是运维自动化和AI落地这篇都可以直接当月度行业速览来读。1. 6月热点清单里藏着两条主线从工控现场到软件测试都在转1.1 热搜词是最省力的情报聚合器看资讯其实有个很省力的办法把当月的搜索热词拉出来看一遍。6月这轮热词里自动化测试相关的词占了一大片pytest接口自动化、接口自动化断言规范、playwright自动化框架、appium自动化测试、selenium自动化测试框架、jenkins自动化部署这些词几乎贯穿了整个月。这说明软件质量保障方向的需求依然旺盛而且大家讨论的重点已经从怎么把脚本跑起来变成了怎么把框架做规范、怎么稳定跑在流水线里。另一头是工控现场的方向龙芯2K3000赋能轨道交通AFC系统、国产化工控平台实战全解析、企业工控安全里用到的标准规范这些是搞工业系统集成和设备运维的人在持续关注的东西。两类关键词放在一起刚好折射出自动化这个大概念下的两个世界一边是比特世界的软件自动化一边是物理世界的工业自动化。过去这两个圈子各聊各的现在因为AI、因为国产化、因为安全合规已经开始不断交叉。1.2 不同角色的读者该重点看哪部分要是你的工作偏软件测试或质量保障那第4章和第5章的内容和你直接相关接口自动化的断言规范、Playwright、Appium、AI测试都是这个月的高频话题如果你做工业系统集成、设备运维或者工控安全第2章和第3章更适合你国产化平台怎么选型、IEC 62443和等保扩展要求怎么落地都是绕不开的功课如果你是运维或全栈第6章的内容可以重点看Ansible、Jenkins之外其实还有很多细分场景值得注意。不过我也要提醒一句别被热搜这个词带偏思路。热搜代表的是大家都在问什么并不代表什么最重要。我的习惯是把热搜当作线索然后顺着线索去找背后的技术逻辑和真实项目案例这样才不会停留在刷资讯的层面。2. 龙芯2K3000进入轨道交通AFC国产化工控平台第一次这么近2.1 AFC系统是什么哪一层最需要国产化AFC全称Automatic Fare Collection自动售检票系统是地铁、市域铁路这些轨道交通运营里最核心的系统之一。乘客进出站刷卡/扫码的闸机、现场买票的自动售票机TVM、客服中心的半自动售票机BOM这些每天都会碰到的设备都属于AFC系统的底层设备。整个AFC体系通常分好几层最下面是车票与车站终端设备往上是车站计算机系统SC再往上是线路中心系统LCC最顶层是全网清分中心ACC/ICCS。所以国产化替代这件事不是一个芯片、一台服务器的替换而是从终端到中心逐层推进的系统工程。6月这个热搜案例里龙芯2K3000所扮演的角色恰恰在最贴近乘客的车站终端设备这一层。这一层有个特点不追求极限算力但极其看重长时间稳定运行。闸机和TVM不是跑分设备它们是7×24小时连续工作的嵌入式工控设备选型逻辑和普通PC完全两个世界。2.2 龙芯2K3000在闸机/TVM里到底负责什么一台闸机内部最核心的是那块主控主板。它要承担读卡器数据解析、通行逻辑控制、远程通讯、显示驱动、声音提示控制甚至还要跑一些简单的业务界面。龙芯2K3000在这里的角色就是给这类车站终端设备提供一块核心处理器平台。从工控选型的几个关键维度看2K3000这个方案有几处很适合AFC场景功耗和散热控制得比较好整机有条件做密闭无风扇设计。地铁站里灰尘大、设备常年不停机风扇反而是故障源。周边接口齐全多路串口、USB、千兆网口、GPIO和多种显示接口都有闸机里的读卡器、通行传感器、LCD显示屏可以直连。基于LoongArch自主指令集搭配国产操作系统和国产密码算法在供应链的稳定性上有天然优势。容易被忽略的一点是AFC终端设备的使用生命周期通常按8到10年规划中间还要持续升级软件。所以选型时看的不是单核性能有多强而是长期供应保障、接口兼容性和后续维护能力。这也是龙芯这类方案在轨道交通行业被讨论的原因——不是跑分高而是能稳定供货、能长期维护。2.3 实战视角从主板换上到稳定运行要跨过多少坎实战全解析这几个字说起来轻松做起来全是细节。把主板换上去、系统能点亮这只是万里长征第一步。真正花时间的是后面这些事。首先是操作系统适配。龙芯平台上跑的一般是Loongnix、统信UOS、麒麟这类系统现场原有的AFC应用软件要从其他架构迁移过来重新编译、验证第三方库的兼容性。这一步必须有芯片厂商或原厂的技术支持兜底集成商自己硬啃会非常慢。其次是外设驱动的逐一验证。读卡器、二维码扫描模块、闸机通行控制板每一个外设都要在国产平台上重新过一遍兼容性测试。我在类似项目里的经验是很多项目卡住并不是核心处理器不行而是某个外设SDK没适配整个系统就动不了。所以进场第一步应该先拉一张外设清单逐个做兼容性摸底。再就是实时性和稳定性验证。闸机通行逻辑对响应时间的要求没有运动控制那么极端但也必须稳定可预测不能出现偶发卡顿导致乘客通行失败。建议项目初期就安排一轮长时间压力温度循环测试把主板放进高低温箱连续跑72小时以上监控有没有死机、重启、数据错乱。这种测试很枯燥但能在大规模上线前把问题暴露干净。2.4 这个案例给工控从业者的信号这个案例真正的意义是国产化工控平台已经从跑Demo走到了跑真实业务的阶段。对于集成商来说现在是认真看国产处理器选型资料、拿开发板做适配验证的好时机积累的经验越早越有价值。对于甲方来说也不用再单押某一种芯片架构可以多关注整体平台的生态成熟度。我自己评估国产化工控方案时只看三个指标工具链完不完整编译、调试、烧写、量产工具链缺一环都很难受、周边外设适配案例多不多、厂商对行业项目的响应力度怎么样。这三条都能过关项目成功率才有保障。3. 工控安全标准规范企业落地最容易被绕晕的三组关系3.1 先分清大家在讨论哪几类标准6月热词里企业工控安全里用到的标准规范上榜说明很多人在做安全建设时第一步就被标准选型难住了。这个领域确实乱标准多、层级多、说法多。我按实际使用频率梳理一下企业里最常打交道的就这几类IEC 62443ISA/IEC推出的工业自动化和控制系统安全标准体系最完整从通用要求、安全管理、系统安全到组件安全四个部分覆盖了怎么从方法论上做安全。网络安全等级保护2.0中的工业控制系统安全扩展要求国内合规测评里专门针对工控系统的扩展条款要过等保就绕不开。GB/T 33009、GB/T 36470等国内工控安全相关标准更多用于具体的安全防护技术要求和评估方法。《工业控制系统信息安全防护指南》这类指导性文件很多行业的安全方案都会参照它来定具体措施。这几类标准不是互斥的而是不同维度上的落地工具。IEC 62443解决怎么做才安全的方法论问题等保扩展要求解决合规底线是什么的问题防护指南给出具体的安全措施清单。企业做安全建设最好先明确一件事你是为了合规测评还是为了提升实际安全水平。目标不同落地的侧重点完全不一样。3.2 Zone and ConduitIEC 62443的核心思想并不难聊IEC 62443绕不开区域与管道模型英文叫Zone and Conduit。它是整套标准安全架构的基石。思路其实很朴素把系统按照业务功能和信任级别划分成不同区域区域之间的通信必须经过明确的管道管道上要有严格的安全控制。举个例子工控网络里的DCS控制层和办公网就应该属于两个不同区域。办公网的员工查历史生产数据可以但办公网的终端要直接向控制器下发指令这就触碰到高安全区域了必须经过防火墙、白名单、认证机制这些管道防护。过去很多工控系统出事就是因为没分区病毒在办公网里传开后直接蔓延到了生产网。我在实际项目里做安全方案第一步永远是画网络拓扑分区图。在标准的Zone and Conduit图上标出哪些资产属于哪个区域哪些通信路径是管道。这张图画完安全整改项基本就水落石出了后面的防火墙策略、ACL、白名单全部围绕它展开。所以别把IEC 62443想得太玄乎核心就是先分清边界再管住通道。3.3 IT安全和OT安全的差异决定了你不能照搬打法做工控安全最容易犯的错就是把IT安全的成熟做法直接往OT环境里搬。IT安全讲究快速打补丁、频繁重启、统一端点管理这些在工控现场往往行不通。生产系统的补丁不是想打就能打的。一个安全补丁可能影响DCS的版本兼容性导致控制器参数异常或者某个功能模块不可用。所以OT环境普遍采用补丁滞后策略先用虚拟补丁、白名单、网络隔离这些补偿性控制手段兜住风险等真正有停产窗口了再统一补丁。这个思路对IT出身的人来说很难接受但在生产连续性是第一位的现场这就是现实。另一个重要差异是资产可见性。IT系统可以通过终端管理软件发现所有主机但工控现场还有大量老旧PLC、传感器、嵌入式设备根本没法安装任何代理程序。所以OT安全建设的第一步不是部署一个安全设备而是先做被动资产测绘通过流量分析把网络里的设备指纹识别出来先搞清我家到底有什么再谈怎么保护。3.4 按这个优先级推进比到处找方案更有效结合6月社区里围绕工控安全的讨论再结合我自己的项目经验我给企业工控安全落地排了一个优先级供参考资产盘点与拓扑分区。没有资产清单一切安全措施都是盲打。网络边界防护。控制区和非控制区之间必须有边界设备默认拒绝策略。白名单机制。工控协议特征明显白名单比特征库更可靠误报率低得多。集中审计与告警。收集日志和协议记录保证事后可追溯。这四层做完大部分中小型工控企业的安全基线就算立起来了。至于要不要上更重的态势感知平台看企业规模和预算决定不必一步到位。安全建设不是买设备比赛是把基础动作做扎实的过程。4. 自动化测试6月风向接口、UI、移动端和面试现场4.1 接口自动化断言规范和环境切换才是重点6月热搜里接口自动化接口自动化断言规范最新版python接口自动化如果配置自动切换环境这几个词扎堆出现说明整个技术社区对接口自动化的关注已经从怎么写脚本进入到了怎么把脚本写规范的阶段。先说环境切换。接口测试日常要在开发、测试、预发布、生产多个环境之间切换最忌讳把base_url直接硬编码在用例里。常规做法是统一管理环境配置在pytest.ini或者独立的配置文件里定义不同环境的base_url运行用例时通过命令行参数或环境变量指定当前环境用例内部只读取配置不写死。我建议用fixture动态创建请求客户端这样一个环境对应一个客户端实例用例代码完全复用。很多团队的环境切换做得别扭不是技术方案不行而是用例里到处都是散落的IP地址和域名整理一遍就顺了。断言规范方面我坚持四层断言缺一不可第一层HTTP状态码先确认链路通不通。第二层业务状态码接口返回的code字段是否符合预期。第三层关键业务字段核心数据是否正确比如订单金额、用户状态、分页总数。第四层数据落库校验查数据库确认写进去的数据和接口返回一致。只断言第一层的用例基本等于没测。接口返回200只能代表服务没崩不能代表业务数据是对的这是接口测试里最常见的误区。4.2 UI自动化Playwright为什么在6月讨论里压过了SeleniumWeb UI自动化这个月的高频词集中在playwright和selenium的对比上。Selenium是很多人的入门框架生态成熟、资料多但它有个老毛病代码要自己处理元素等待、自己管理浏览器驱动用例一旦写多稳定性就成了大问题。元素定位偶发失败、网络慢一下用例就挂了维护成本居高不下。Playwright在这方面做了大量改进内置自动等待机制元素不出现就不执行下一步支持Chromium、Firefox、WebKit三套浏览器引擎自带Trace Viewer用例失败后可以回放完整页面操作过程还能拦截网络请求做Mock。这些特性让它在6月的讨论里热度明显高于Selenium。说句公道话Selenium不会马上消失存量项目太多迁移成本客观存在。但如果你现在才开始做Web UI自动化或者准备重构老框架Playwright是更合适的起点。我用Playwright重构过一个Selenium框架用例稳定性从70%提到了95%以上收益主要来自自动等待和失败诊断能力的提升。下面是一个最简的Playwright pytest登录场景示例感受一下写法的简洁度import re from playwright.sync_api import Page, expect def test_login_success(page: Page): page.goto(https://example.com/login) page.fill(input[nameusername], tester01) page.fill(input[namepassword], pass123) page.click(button[typesubmit]) expect(page).to_have_url(re.compile(r.*/dashboard)) expect(page.locator(.user-name)).to_have_text(tester01)这里没有一行显式的等待代码但Playwright会自动等元素出现在做输入和点击。用例可读性很高出问题也容易定位。4.3 移动端和桌面端Appium之外还有哪些细分自动化移动端自动化这边Appium依然是讨论度最高的框架6月热度里ios自动化appium自动化测试都有上榜。Appium能跨Android和iOS但两边的体验差别很大。Android侧生态顺、资料多、调试方便iOS侧需要WebDriverAgent做代理还要处理证书和签名环境配置的坑特别多。所以做iOS自动化的团队我建议先把WebDriverAgent的启动流程完整走通再想用例设计的事。桌面端的自动化热度也在上升热词里有.exe程序自动化windows自动化ubuntu网页自动化脚本。桌面应用自动化选型先确认应用类型再决定工具链Win32应用用pywinautoUWP/WinUI可以考虑WinAppDriver纯粹的重复操作自动化AutoHotkey依然够用。很多做运维和测试的同学忽略了这类能力其实在日常巡检、报表生成这些场景里桌面脚本能省下大量人力。4.4 从面试题看市场要求框架设计和稳定性接口自动化测试面试题、自动化测试面经这些词也进了热榜。这个方向不仅项目里用得多招聘市场同样活跃。我归纳了一下近期社区里的高频面试题核心就三类框架设计能力怎么设计一个分层清晰、易维护的自动化测试框架。用例稳定性处理元素定位不稳定、异步加载导致失败你有什么解决办法。CI集成能力自动化用例怎么接入Jenkins流水线失败后如何通知和定位。这些问题的答案其实都指向同一件事能不能把自动化测试从个人玩具做成团队工具。能稳定跑在流水线里、失败能快速定位、报告能让团队看懂这才是企业真正要的能力。单会写脚本的人现在确实不好找工作了。5. AI加入自动化从测试生成到运维Agent热点很多但落地要冷静5.1 AI驱动的测试Claude和Codex当前最适合干的活6月热词里claude ui自动化测试基于codex的自动化测试ai自动化测试几个词挨得很近。这一波AI参与测试和以前的低代码自动化不是一回事。低代码是把封装好的组件拖拽成流程AI则是在理解需求后直接生成代码。我看到目前最合理的落地场景有两个。一是用Claude这类大模型解析页面结构生成Playwright/Cypress的测试脚本初稿测试人员做Review而不是从零编写二是用Codex这类编程Agent在已有工程里根据代码上下文自动补测试用例尤其是单元测试和接口测试。但我的结论很明确AI在自动化测试里目前适合当高产初级工程师不适合当可信的终极裁判。它生成的用例覆盖率高但有些断言可能是错的接口字段名猜错、业务逻辑理解偏差这些都很常见。所以AI生成的用例必须走代码评审同时团队里要有稳定的基线用例做兜底不能让AI自测自审。5.2 AI运维Agent的harness先管住权限再谈自主ai agent harness自动化运维这个热词挺有意思。harness这个词在自动化运维里通常指的是把Agent放进一个受控的框架里而不是让Agent裸奔。具体来说harness解决三件事权限边界、操作可观测、失败回滚。拿自动化巡检举例一个AI Agent可以读监控指标、分析日志、执行修复命令但如果没有harness它可能误删文件、改错配置。有了harness之后Agent的每次操作都受审批策略控制所有动作都有日志一旦出问题可以回滚到上一个稳定状态。这才是AI运维的正确打开方式。不是让AI完全自主干活而是让AI在一个明确的边界内干活权限、审计、回滚这些交给系统和流程。放在6月这个时间点看这个方向还处于早期但值得开始积累经验了尤其是做运维平台的同学可以把harness机制设计纳入自己的规划里。5.3 非技术场景的自动化工作流订单抓取、Excel处理、甚至写作AI自动化不只是IT圈在聊。热搜里跨境电商多平台订单抓取workbuddy自动化工作流搭建如何用ai建立自动化excel工作流这两个词反映的是普通业务场景也在被改造。这类工作流平台的逻辑本质上是把人登录多个后台、复制粘贴数据、手工填表这类重复劳动变成自动化节点。订单抓取的核心是让系统定时登录各电商平台后台解析订单数据再写入统一的表格或数据库Excel工作流则是让AI读取表格结构、理解需求生成对应的处理脚本自动完成数据清洗统计。我自己试过用AI辅助做Excel报表自动化最实用的路径是三步走先让AI写Python脚本处理pandas/openpyxl的数据整理再把它封装成定时任务跑起来最后加一道人工抽检。这样既快又不至于完全失控。另外热词里的自动化小说写作其实也是同一类逻辑内容自动化生成这件事已经从纯文本扩展到了数据分析、流程处理多个领域。5.4 我的判断维护成本决定了AI自动化能走多远现在聊AI自动化特别容易陷入效率崇拜张口就是效率提升多少倍。我在实际项目里的体感是AI自动化的最大问题不是生成速度而是维护成本。AI生成的脚本质量参差不齐页面结构一变、字段名一改脚本可能就要重写。如果没有清晰的代码结构和回归防线维护成本会很快吃掉效率红利。所以我给所有准备上AI自动化的团队一个建议先约定好代码规范、用例Review流程和定期回归机制把这三件事做扎实再谈规模化的效率提升。顺序反了后面全是坑。6. 运维自动化继续变厚Ansible、Jenkins之外还有哪些新场景6.1 一个能交付的Ansible项目不只是一堆PlaybookAnsible在自动化运维里的地位不用多说6月讨论热度也一直在线。但很多初学者的理解还停留在写几个Playbook跑一下真正能交付给企业的运维项目要规范得多。我的推荐结构是这样Inventory按环境分组dev、test、prod分开放Playbook只做编排不堆任务真正的动作封装成RoleRole内部再拆tasks、handlers、templates、defaults。密码和密钥不写明文全部用Ansible Vault加密运维成员按角色分配不同的Vault密码文件。Ansible项目的核心就两个词可读性和可维护性。三个月之后你回来看自己的Playbook如果还得靠回忆才知道它干了什么那这个项目就是不合格的。写Playbook要像写业务代码一样重视结构和注释。一个最简的Nginx部署Roletasks文件大概长这样- name: Install nginx apt: name: nginx state: present when: ansible_os_family Debian - name: Copy site config template: src: nginx.conf.j2 dest: /etc/nginx/nginx.conf notify: restart nginx - name: Ensure nginx is running service: name: nginx state: started enabled: true注意里面用了template模板和notify配置文件变更时自动触发服务重启这是Ansible里最典型的幂等写法。6.2 Jenkins Pipeline把部署从点按钮变成代码化Jenkins自动化部署也是6月热词。过去很多团队的Jenkins任务是UI上点出来的自由风格任务任务一多就是一团乱麻。现在的主流做法是用Jenkinsfile做Pipeline as Code把构建、测试、部署的完整流程写成代码放进代码仓库统一管理。一个典型的Pipeline会拆成几个stage拉取代码、编译构建、跑自动化测试、构建镜像或产物、发布到测试环境、人工确认后发布生产。每个stage都可以参数化比如用parameters指定部署到哪个环境、选择哪个版本分支。这么改造之后最大的收益是流程可审计、可回滚。每次构建都能对应到某一次代码提交部署失败时能快速定位是哪个环节出的问题而不是靠某个人记得上次是这么点的。对需要频繁交付的团队这一步早晚要做。6.3 电力系统自动化与桌面级脚本两个容易被忽略的细分场景这次热搜里电力系统自动化模板也值得一提。电力系统的自动化和通用IT自动化差别很大它包含调度自动化、配网自动化、变电站监控等方向更强调规约IEC 60870-5-104、Modbus这类、规约转换、实时数据库这些底层能力。最近行业里有明显趋势是把常见场景沉淀成模板比如变电站遥测遥信采集模板、配网线路故障检测模板。新项目从模板起步交付速度会快很多。如果你是电力自动化的从业者建议多积累自己的场景模板这是个人和团队最值钱的核心资产。另一个容易被忽略的方向是桌面级脚本和服务器网页脚本。Ubuntu服务器上跑Playwright做定时网页巡检或者用pywinauto控制Windows桌面程序完成日报生成这类脚本不复杂但实用价值极高。特别是6月热搜里出现的ubuntu网页自动化脚本说明越来越多运维人员在用网页自动化解决内网系统的重复操作问题。6.4 运维脚本的稳定性设计是我的底线最后讲一个我自己的经验。无论是Ansible、Jenkins还是桌面脚本运维类自动化最怕的就是这次跑通下次跑得看运气。所以我在写运维脚本时坚持几条铁律幂等性优先脚本重复执行结果一致不重复安装、不重复重启。关键步骤有检查执行完命令必须验证状态不能只看退出码。失败有通知脚本出错要能发消息到群里不能悄悄死在后台。日志留底每次执行保留完整日志方便事后追溯。这几个原则看起来简单但在真实项目里能把运维自动化的可靠性拉高一大截。很多人踩坑不是不会写技术而是少了这些工程习惯。7. 看完6月资讯我下个月准备这样跟每月资讯汇总最好的使用方式不是从头读到尾而是对照自己的项目线挑两三个方向深入研究。6月这轮内容里我给自己留了三个任务。第一把龙芯2K3000的开发板资料完整过一遍重点看它的接口资源和工具链评估能不能进我们下一个工控项目。现在正好是收集选型信息的好时机等项目真正启动再研究就晚了。第二参考IEC 62443的区域管道模型把现有项目的网络拓扑重新画一遍。安全这件事与其等检查倒逼不如自己先把家底摸清楚。我建议你也试试花一个下午画清楚自己的分区图你会对系统安全状况有个全新认识。第三继续跟踪AI自动化测试的社区实践重点观察维护成本这个指标。AI本身不新鲜新鲜的是它能稳定、可控地融入自动化体系。我打算拿一个小项目做试点让AI生成一套接口测试用例然后记录三个月内的维护投入用数据说话。这几个方向不一定适合所有人但对自动化工控这个领域有兴趣的人应该能找到不少参考价值。6月的信息量很大筛选信息、聚焦项目比单纯收集信息更重要。