做工业自动化开发Modbus这个协议你一定不陌生。PLC、仪表、传感器、上位机组态软件十几年来基本靠它沟通。但协议熟悉归熟悉真到联调阶段设备没进场、点位没接好、想模拟一个设备掉线或者数据跳变的工况往往比写业务代码还折腾。这篇博文我就用AI原生开发的思路从零搭一个Modbus仿真器。简单说就是我把“要一个什么样的仿真器”描述清楚让AI承担代码生成的主体工作自己负责协议校验、边界打磨和实测验证。整个过程里提示词怎么设计、生成后的代码怎么审查、哪些坑必须手动填我都会拆开讲。适合正在做上位机开发、协议测试或者想试着用AI驱动完整小项目的工程师参考。1. 为什么选择AI原生开发方式做这个仿真器1.1 工业调试中的真实痛点做过程控或物联网项目的朋友大概率遇到过这几类场景。第一类设备还没有到货但上位机界面、数据采集逻辑、告警规则都得提前开发和自测。总不能让整个项目组干等硬件到位。第二类设备在现场但你不敢随便拿真实设备做破坏性测试比如强制让传感器上报异常值、让从站延迟响应、或者测试主站在设备断线时能不能正确告警。第三类网络里同时挂着十几个从站每个站有三四十个寄存器点位上位机要按站号轮询而你手里根本没有十几台真实设备去组网。这些场景其实都在指向同一个刚需你需要的不是一台真实设备而是一个“可编程的、行为可控的、能模拟各种异常情况的假设备”。这就是Modbus仿真器最核心的用处。市面上有不少现成的仿真工具有的能模拟简单的寄存器读写有的为了兼容通用性把界面做得非常重。但真正到了项目里你要的可能只是“按我定义的寄存器表启动一个TCP服务并且能随时把某个站切到离线状态”。这种轻量、定制、随拆随用的工具反而很少有现成产品能完全满足。与其浪费时间在通用工具里配置不如自己动手做一个符合自己业务习惯的仿真器。1.2 AI原生开发与传统编码的差异我理解的传统开发模式链路大概是这样的先查协议文档确认报文格式再设计一个框架然后逐段写代码实现功能最后写测试用例不断修正。整个过程里电脑只是一个编辑器核心的脑力劳动全部由开发人员承担。而AI原生开发最大的变化在于你可以用自然语言把需求讲清楚让AI先生成一个大半成品然后你来做架构审查、协议核对、边界补全和验证。这有点像你身边有一位非常熟悉代码但不太了解业务上下文的老工程师你把需求描述得越准确他给你的初稿质量就越高而你只需要负责把最关键的协议细节和项目约束注入进去。这种开发方式的收益不是“少打了几行字”这么简单而是把开发者的注意力从重复的轮子搭建转移到更具价值的“需求定义”和“质量验证”上来。仿真器这种项目特别适合AI原生开发因为它协议标准明确、边界场景丰富、测试手段直观AI生成的代码能覆盖大量路径而人工需要盯住的反而是协议细节、资源管理和异常注入这些“脏活”。1.3 功能取舍与选型思路动手前我先给自己定了个边界避免做成一个不伦不类的大杂烩。第一版本只做Modbus TCP从站仿真不做RTU串口模式因为TCP调试起来最方便无论是本机回环还是局域网访问都不用关心串口占用和波特率问题。第二版本只实现从站侧行为也就是作为被读取的一方响应主站的报文请求。这样能覆盖绝大多数“验证上位机逻辑”的需求。第三版本要留出口子方便以后扩展RTU模式和主站模式。功能码方面我要求支持读线圈、读保持寄存器、写单个线圈、写单个寄存器、写多个线圈、写多个寄存器这几个最常用的。寄存器地址范围不做死通过配置动态分配。异常响应必须支持因为测试上位机对异常码的处理往往是仿真器价值最大的部分。选型上我决定用Python理由后面详细说。整个项目的核心原则就一句话先做一个能跑的、行为可控的TCP从站再逐步把边界和异常场景补上。2. Modbus协议核心要点与仿真器设计拆解2.1 协议里最容易混淆的几个点做仿真器之前协议细节必须抠干净否则生成出来的代码表面上能监听端口、返回数据实际上全是错的。Modbus里最容易踩坑的有四件事。第一是字节序问题。Modbus寄存器是16位宽传输时默认使用大端序也就是高字节在前低字节在后。假设你有一个寄存器值为0x1234上位机读到的字节流必须是0x12 0x34反过来就是错的。这个细节不仔细核对很容易出现寄存器值“怎么读都差好远”的问题。第二是CRC校验。串口RTU模式用CRC16校验虽然TCP模式本身有TCP校验和但很多Modbus TCP设备在报文层也保留了CRC字段部分工具和代码库也会做校验。正确计算CRC的底层逻辑是初始值为0xFFFF按位异或后右移遇到低比特位为1时与多项式0xA001异或这个算法没有捷径只能把函数写对。第三是数量限制。读取线圈或寄存器的单次数量不能超过0x7D125这是一个协议层面的硬性约束很多实现偷懒不做校验就直接返回数据结果把主站搞蒙。第四是地址对齐。协议报文里的寄存器地址是从0开始计数的。比如你配置了一个保持寄存器地址范围从0到99那么主站请求报文中要读的地址就填0到99但很多PLC里的点位表习惯从1开始命名配置工具里常做加一减一的转换。仿真器内部必须明确以协议报文里的地址为真实下标不要让外部显示习惯污染协议层逻辑。2.2 仿真器的三层内部结构我在设计这个仿真器时刻意把代码分成三层让AI生成的代码也按照这个结构去组织。最底层是数据层负责保存所有寄存器、线圈和离散输入的状态。可以简单用字节数组或者Python的list来存储每个地址映射一个值。为了让仿真器灵活这一层最好做成可配置的比如通过JSON或YAML文件描述寄存器总数、初始值、每个寄存器周期变化规律。第二层是协议层职责是解析从socket接收到的原始字节流提取事务标识符、协议标识符、长度、单元标识符、功能码和数据然后根据功能码读写数据层最后组装成Modbus TCP响应报文。这一层是整个仿真器最核心的部分AI生成时最需要人工核对的就是这里。第三层是交互层提供启动参数解析、运行时日志输出、异常注入开关。它不参与协议处理只负责跟使用者打交道。三层的价值在于你后续无论怎么扩展功能改动都会被限制在某一层里。比如要新增一个功能码你只需要动协议层要让某个寄存器值按照正弦波自动变化你只需要动数据层。AI生成代码时这种清晰的边界也能让生成结果不跑偏。2.3 为什么异常注入功能很重要普通仿真工具最让人挠头的地方就是它只会正常应答不会给你使绊子。可实际测试里最有价值的往往就是那些“异常时刻”。主站软件能不能在从站掉线时弹告警重试几次才算合理寄存器地址越界时主站会不会正确处理异常码这些场景需要在仿真阶段就暴露出来而不是等到现场设备出问题才去排查。所以我的仿真器必须支持三类异常注入。第一类无响应。也就是主站发来了请求但从站故意不回答让主站产生超时重连的逻辑行为。第二类CRC或格式错误。往正常响应里插入错误的校验码或者在报文中加一段垃圾数据模拟链路被干扰。第三类合法异常码。比如请求地址超出配置范围时返回0x02非法数据地址请求功能码不支持时返回0x01非法功能码从站处理不过来时返回0x06从站忙。有了这几个开关你的上位机健壮性测试就基本覆盖到位了。3. 实操过程从提示词到可运行仿真器3.1 开发语言与运行环境准备语言我直接选Python理由很现实。第一第三方库和脚本资源丰富AI对Python代码生成的准确率明显高于其他语言。第二标准库socket和struct就能完成Modbus TCP的收发和字节拆包不需要引入庞大的依赖。第三后期如果要加界面比如用tkinter或者Web方式Python也都有比较轻的方案。环境方面我建议使用Python 3.9以上版本。项目除了标准库之外如果要做自动化验证可以临时安装一个Modbus客户端调试工具比如现成开源的ModbusPoll开源替代品或者直接用Python的pymodbus库做回测。但项目本身的依赖约等于零这对一个仿真器来说非常理想。Windows和Linux都可以跑监听端口默认用502这是Modbus的标准端口。不过Windows下直接在低端口监听需要管理员权限简单处理方式是允许运行参数里改成用1502或10502这些非特权端口测试时在客户端里填对应端口就好。3.2 提示词设计把需求讲成AI听得懂的结构化描述AI原生开发里提示词就是需求文档。我发现一个很好用的套路把需求拆成“目标输入输出约定行为细节测试要求”四个部分。我实际用的提示词大概是这个思路请用Python实现一个Modbus TCP从站仿真器监听指定端口。要求 1. 支持功能码0x01读线圈、0x03读保持寄存器、0x05写单个线圈、 0x06写单个寄存器、0x0F写多个线圈、0x10写多个寄存器。 2. 使用标准socket库监听TCP默认端口502。 3. 寄存器空间大小通过启动参数或者配置文件设置 初始值在模块内定义。 4. 请求报文按Modbus TCP格式解析 事务标识符2字节 协议标识符2字节 长度2字节 单元标识符1字节 功能码1字节 数据区。 5. 响应报文必须保持相同的事务标识符和协议标识符。 6. 注册到日志模块启动时输出监听地址和端口信息。 7. 对不支持的功能码返回异常响应0x01。注意我没有让AI直接写“全部实现”而是先让它把框架和标准功能码实现出来。这样生成的代码更容易审查也不会因为一次需求太多而出现逻辑混乱。如果项目里还要模拟异常注入我会在拿到第一版可运行代码后再追加需求而不是在第一轮就把异常响应、日志等级、配置文件全塞进去。AI原生开发里小步迭代比一次性完整描述更不容易失控。3.3 核心代码生成与人工审查AI生成的代码框架通常长这样主线程创建socketbind到端口循环accept来一个连接就开一个线程处理。从直观性讲这个结构是标准的能跑。但作为开发人员我不能直接说“可以了”逐行审查是必须的。我建议重点盯三个位置。第一半包与粘包处理。TCP是一个字节流协议一次recv可能只收到上半截报文也可能一次性收到了好几个请求粘在一起。如果代码只做单次recv然后立刻解析那么高并发或者慢速网络下必然出问题。我的做法是每个连接维护一个缓冲区不断接收并尝试按MBAP头部里的长度字段确定这一帧是不是已经完整不完整就继续等。第二监听地址。AI很自然地会用127.0.0.1但要作为仿真器给局域网里的上位机连接必须绑定0.0.0.0。这是一个必须在人工审查阶段发现的问题。第三线程序号增长。如果用threading处理的连接没有做异常捕获或者线程回收一个客户端断开时可能抛出异常导致整个服务崩溃。我通常在异常处理里把线程放在try/except里并记录客户端断开日志而不是让异常冒泡出来。核心代码实现以读保持寄存器0x03为例AI生成的解析逻辑大体会是这样def handle_request(data): transaction_id data[0:2] protocol_id data[2:4] length int.from_bytes(data[4:6], big) unit_id data[6] func_code data[7] if func_code 0x03: start_addr int.from_bytes(data[8:10], big) quantity int.from_bytes(data[10:12], big) if quantity 125: return build_exception(transaction_id, unit_id, func_code, 0x03) if start_addr quantity len(holding_registers): return build_exception(transaction_id, unit_id, func_code, 0x02) values holding_registers[start_addr:start_addr quantity] response struct.pack(H, 1 quantity * 2) bytes([func_code, quantity * 2]) struct.pack( H * quantity, *values) return transaction_id protocol_id struct.pack(H, len(response) 1) bytes([unit_id]) response这里需要注意事务标识符和协议标识符必须原样返回长度字段计算的是“单元标识符功能码数据区”这一段的总长度一个字节都不能多算少算。AI生成时经常把长度算错我的经验是拿到代码后自己手动构造几个已知报文逐字节验证再放行。3.4 测出来才算数本地回环与客户端回测代码能启动之后我坚决不只用“启动没有报错”来验收。我会做两轮测试。第一轮是构造已知报文做单测。我直接构造一个读保持寄存器0x03的报文请求地址从0开始读4个寄存器然后检查响应里的数据区是不是跟配置的初始值一致。比如初始值是[100, 200, 300, 400]那么大端序返回的字节就该对应0x0064,0x00C8,0x012C,0x0190。第二轮是用现成的Modbus客户端工具连接仿真器读取真实点位写入寄存器再读回来。这一轮能验证跨语言、跨实现的兼容性很多自研仿真器就是栽在这一步——自己跟自己玩没问题跟别人的客户端一握手就露馅。如果条件允许把仿真器部署到Linux服务器上再用Windows上位机软件走局域网连接这样还能顺带验证网络环境、防火墙、端口映射这些实战场合的问题。仿真器的好处就在这它不是为了跑通一遍流程而是为了反复模拟各种上线后的恶劣情况让问题在进机房之前就暴露出来。4. 常见问题与排查技巧实录4.1 协议实现上的坑我自己在做的过程中最大的坑是字节序和长度字段。AI第一次生成的struct格式用的是小端结果寄存器值全部高低颠倒读出来的数值跟配置完全对不上。排查方式很简单构造一个已知的寄存器值用Wireshark抓包或者手工打印响应报文看字节顺序。第二个坑是长度字段多算了一个字节因为有些示例代码把单元标识符的长度漏了导致客户端一直报“报文格式错误”。这类问题靠肉眼看代码不容易发现靠抓包能看到到底多出来的一个字节在哪。第三个坑是边界读寄存器的时候起始地址合法但起始地址加数量之后的结束地址越界了。这个校验条件如果写成大于等于而不是大于会把最后一个合法地址也拦掉导致主站读取失败。第四个坑是半包。之前在局域网上跑没问题结果用弱网环境模拟主站读取频繁丢包排查下来是recv只收了一次就着急解析拆包不完整导致的。4.2 AI生成阶段的协作问题用AI生成不等于当甩手掌柜。“AI生成的代码看起来很有道理”往往是藏雷最多的地方。我遇到过AI声称调用了某个标准库函数但实际上Python这个版本里根本没有这个API一运行就报AttributeError。也遇到过AI把协议层的逻辑写成了从某个文件读取配置的方式虽然也是按我的需求来但显然跑偏了。还有一次它生成的异常响应里功能码忘了加0x80等于告诉主站“我正常处理了这条不支持的功能码请求”这在协议层是完全错误的行为。所以我给自己定了几条AI协作的规矩。第一要求AI给出“关键算法”的测试用例比如CRC函数直接跑几个已知结果校验。第二一次只改一个需求点不要让AI同时处理新增功能码和重构线程模型。第三所有生成代码必须拿着Modbus协议规范过一遍任何“看起来差不多”的函数都要单独验证。AI是很好的初稿生成器但不是权威裁判。4.3 实用排查工具与验证技巧做这类协议仿真器光看代码和日志还不够我习惯搭配三个工具做多维度验证。第一是抓包工具直接看以太网帧里的原始字节流确认事务标识符、长度、数据区都符合预期。第二是现成Modbus客户端用一个与项目毫无关联的第三方实现来连我的仿真器这种“独立视角”的兼容性测试最有说服力。第三是自动化脚本批量构造正常请求、异常请求、越界请求和畸形报文验证仿真器在各种攻击性输入下不崩溃。自动化脚本里我会跑一个循环连续写入一个寄存器1000次再读出来检查数据是否一致排除并发中的状态覆盖问题。这些工具组合起来基本能覆盖一个Modbus从站仿真器的全部测试维度。我个人最大的体感是测试比编写功能本身更费时间。仿真器本身逻辑不复杂难就难在你要让它在真实网络环境下面对各种不按套路出牌的请求还能稳如泰山。5. 一点个人体会把整个仿真器从需求描述到可运行这一轮做下来我的感受是AI原生开发真正改变的不是“写代码”这个动作而是把人的精力逼到了更重要的地方——定义清楚边界、审查协议细节、设计验证路径。仿真器这种协议型工具恰好是AI生成代码的高地因为Modbus规范足够明确网上示例足够多AI输出的框架能节省至少一半时间。但协议这东西错一个字节就是错算法再聪明也不如实际报文验证来得踏实。如果手头没有真实设备又想练一练Modbus调试和上位机开发按照这个思路做一个仿真器确实是个非常合适的方向。我现在还保留了那个自动化测试脚本后续再新增功能码或者调整异常注入逻辑都用它回归一遍。下一步我准备给它加一个简单的Web控制面板把寄存器读写、异常注入开关都做成网页上的按钮这样现场工程师不用碰命令行也能灵活控制仿真流程。AI原生的开发节奏很适合这种持续增补的小工具每补一个功能请AI接手初稿我再做协议层的把关效率和可控性基本达到了平衡。