做工业自动化开发，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异或，这个算法没有捷径，只能把函数写对。第三是数量限制。读取线圈或寄存器的单次数量不能超过0x7D（125），这是一个协议层面的硬性约束，很多实现偷懒不做校验就直接返回数据，结果把主站搞蒙。第四是地址对齐。协议报文里的寄存器地址是从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生成的代码框架通常长这样：主线程创建socket，bind到端口，循环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接手初稿，我再做协议层的把关，效率和可控性基本达到了平衡。
