AI原生开发实战：告别真实PLC，用大模型构建Modbus仿真器

这两年做工业通信相关的项目最让我头疼的往往不是协议本身而是调试环境。现场只有一台真实的PLC程序改一版就得跑一次设备风险大、周期长有些模拟量工况还不方便反复造。后来我开始用Modbus仿真器替代真实从站才算是把开发和验证从物理设备里解放出来。而最近重新折腾这个仿真器我干脆换了一套全新的工作方式——AI原生开发说白了就是让大模型参与从需求拆解到代码生成、测试、文档输出的全流程我只做架构判断和结果审查。这套玩法跑下来效率和代码质量都超出我的预期所以这篇文章就围绕“AI原生开发Modbus仿真器”这个项目把完整思路、实操步骤和踩过的坑都整理出来给同样做工控、物联网或者嵌入式调试的朋友做个参考。无论你是想快速搭一个调试用的从站模拟工具还是想试试AI辅助开发到底能省多少事这篇文章都能给你实打实的路径。1. 项目到底要解决什么问题1.1 为什么需要Modbus仿真器Modbus是工控领域最老牌的通信协议之一PLC、变频器、仪表、传感器基本都带这个口。它的优点是简单、开放、跨厂商兼容但缺点也很明显调试依赖真实硬件。你写了一个上位机程序想验证读取保持寄存器的逻辑对不对要么去现场接PLC要么买一个从站模块折腾线序、对照文档、还得担心设备损坏。而Modbus仿真器就是一个纯软件方案它在PC上模拟一个标准从站监听端口、响应请求、返回你预设的寄存器数据完全不需要物理设备。配合主站工具或者自己写的客户端就能在几分钟内完成协议联调、异常测试、大数据量压力测试。在我的实际项目里仿真器帮了大忙。之前做一个设备数据采集的上位机需要对接不同厂商的仪表每个仪表的数据地址、数据类型、字节序都不一样。我直接在仿真器里建了多套设备映射表把寄存器区布置成和真实仪表一致然后反复切换场景验证采集逻辑问题定位速度提升了不止一倍。更关键的是很多边界条件——比如寄存器越界请求、非法功能码、通信超时——在真实设备上很难触发但仿真器可以随意注入这对健壮性测试是不可替代的。这个项目的“AI原生开发”部分则完全是另一层需求。传统写法下我要自己梳理协议封包、CRC校验、多线程处理、异常模拟等一堆细节费时费力。这次我决定把主流程交给AI来完成看看在协议栈这种逻辑密集型的场景下AI到底能发挥多大作用又有哪些环节必须人工兜底。这个实验本身就是项目最有价值的部分。1.2 核心功能清单与验收标准先明确一下这个仿真器的目标。它不是简单返回固定数据的玩具而是要满足以下功能点支持Modbus TCP和Modbus RTU两种模式TCP监听端口可配置RTU通过虚拟串口或物理串口透传。完整支持01、02、03、04、05、06、15、16这8个常用功能码读线圈、读离散输入、读保持寄存器、读输入寄存器、写单线圈、写单寄存器、写多线圈、写多寄存器都能正确响应。寄存器数据可配置支持bool、int16、uint16、int32、uint32、float32等多种数据类型能自定义大小端字节序。支持异常注入响应超时、非法地址、非法功能码、CRC错误报文用于测试主站的容错能力。具备日志功能记录每个请求的报文内容和响应耗时方便回放分析。验收标准很简单用独立开发的测试主站和第三方工具分别连接仿真器读写的值必须完全一致异常注入后主站能准确捕获错误码连续压测1小时无崩溃、无内存泄漏。这些标准看着基础但每一项背后都有不少协议细节要处理后面我会逐个展开。2. AI原生开发和传统开发模式的区别2.1 为什么这次选择了AI原生开发传统开发一条路走到底需求文档、设计、编码、自测、修bug每一步都是人肉驱动。这个流程本身没问题但在Modbus仿真器这种需求相对明确、协议非常标准化的场景里AI的发挥空间其实很大。因为Modbus规范是公开的、报文格式是固定的、边界条件是可枚举的这些恰恰是AI最擅长处理的知识密集型任务。让它生成协议解析的代码框架比让人从零敲键盘要快得多。但“AI原生开发”绝不只是把代码丢给AI生成。我的理解是整个研发流程以AI为第一生产力包括需求拆分、原型设计、代码生成、测试用例编写、甚至README撰写而人要切换到“架构师审查者”的角色。举个例子我在项目开始时做的第一件事不是写代码而是把需求用结构化的方式描述给AI让它先输出一个技术方案和实施计划然后我再根据经验调整模块划分。这一步很关键因为AI给出的方案虽然合理但未必贴合实际场景需要人工修正。再具体一点AI原生开发的好处体现在三方面。第一上手速度快AI几分钟就能给出一个能跑的基础版本省去了查文档、搭骨架的时间。第二知识覆盖广像CRC算法、字节序处理、报文格式这类细节AI能直接给出规范写法减少人为疏忽。第三迭代灵活想加一个功能或者改一种异常模拟方式直接用自然语言描述需求AI会返回修改后的代码比起自己改大段逻辑高效得多。当然这套模式的代价是审查成本变高了AI生成的东西必须逐行确认协议栈尤其不能全信这一点后面细讲。2.2 实操中的角色分配AI做什么人做什么根据我这次的经验一套合理的人机分工大致是这样的。AI负责生成代码主框架包括Modbus报文解析、响应封包、寄存器数据管理生成单元测试用例覆盖正常和异常场景生成接口文档和启动说明根据反馈做局部重构比如把单线程改成多线程、增加配置项。人负责把需求拆成AI能理解的任务单元提供必要的协议细节约束审查生成的代码重点检查字节序、地址边界、CRC位序这类AI容易搞错的点设计并执行真实环境测试用上位机工具实测通信做性能和稳定性压测确认AI写的代码扛得住实际负载。这里有个容易踩的误区把AI当搜索引擎问一句就照单全收。实际上AI生成代码时会有“自信的幻觉”尤其在一些冷门细节上。比如我让它生成CRC16校验代码时第一次给的算法多项式是对的但字节和结果的位序处理反了导致计算出的校验值完全不对。这种错误如果不做报文级验证根本发现不了。所以我在这个项目里定了一条铁律AI生成的每段核心代码必须配一个针对性的测试用例要么通过实测报文比对要么通过单测断言否则不允许合入。这也是“AI原生开发”和“AI随便写写”的分水岭。从工作流上看我的节奏是这样的先让AI产出V0.1版本跑起来看到基本通信成功然后按模块逐段审查和加固最后用真实主站做端到端验证。整个过程像带着一个很懂协议但偶尔犯迷糊的实习生你得盯住关键环节但效率确实比一个人硬扛高很多。3. Modbus协议核心细节与仿真器架构拆解3.1 一文看懂Modbus报文结构要写仿真器协议本身必须吃透。Modbus RTU和TCP虽然承载方式不同但应用层的数据模型是统一的。先说数据模型Modbus把从站内部数据划分为四个区线圈Coil、离散输入Discrete Input、保持寄存器Holding Register、输入寄存器Input Register。线圈和离散输入都是位数据线圈可读可写离散输入只读保持寄存器和输入寄存器都是16位字数据保持寄存器可读可写输入寄存器只读。这个划分是所有功能码的基础仿真器的数据结构也是围绕这四个区来设计的。功能码是协议的核心。读操作的四个功能码01、02、03、04分别对应线圈、离散输入、保持寄存器、输入寄存器写操作05是写单个线圈、06是写单个寄存器、15是写多个线圈、16是写多个寄存器。每个功能码的请求和响应报文格式都不同但框架是固定的从站地址、功能码、数据区、校验。RTU模式下报文末尾是两个字节的CRC16校验TCP模式下报文头部多了一个MBAP头包含事务处理标识符、协议标识符、长度字段不用CRC靠TCP保证完整性。以最常用的03功能码为例请求格式是从站地址1字节、功能码1字节、起始地址2字节、寄存器数量2字节。响应格式是从站地址、功能码、字节计数1字节、寄存器数据N*2字节。如果出错响应就变成从站地址、功能码最高位置1即原功能码加0x80、异常码1字节。常见的异常码有01非法功能、02非法地址、03非法数据值。仿真器必须严格按照这套规则解析和响应差一个字节都会导致主站报错。3.2 仿真器模块划分与数据结构设计我设计的仿真器按功能分了四个核心模块和AI协作时也是按这个模块粒度来沟通的。第一个是数据存储模块负责维护四个数据区。实现上我用了一个统一的内存映射表每个区都是一个数组线圈和离散输入用bit数组存储寄存器用uint16数组存储。每个数据项除了数值本身还要记录数据类型和字节序配置这样在读写时才不会把字节搞乱。给AI的指令很明确数据结构用面向对象的方式实现每个区一个类提供读写接口读写时要做边界检查。第二个是协议解析模块负责收到的字节流解析成结构化请求也负责把响应数据封包成字节流。这是整个项目最核心的部分也是AI最容易出错的地方。我让AI分别实现了RTU和TCP两种解析器共用一套功能码处理器。解析的重点包括从字节流中提取事务标识符TCP或校验码RTU、解析功能码和地址区间、校验请求长度是否合法。响应封包时则要按功能码拼接字节序列同时处理好长度字段的填充。字节序默认是大端Motorola格式但为了兼容不同仪表我加了全局配置项支持改为小端模式。第三个是功能码处理模块负责执行具体的读写逻辑。这里需要实现8个功能码的请求处理和异常构造。每一个功能码处理器都要先做权限检查比如对只读区执行写操作就返回非法功能码然后做地址范围检查越界就返回02异常码最后才执行实际的数据读写。写操作里有个细节要注意写多个寄存器时请求报文里带的是字节计数和实际数据响应报文回显的是起始地址和数量不包含数据体这个格式差异很容易被忽略。第四个是通信服务模块负责网络监听和连接管理。TCP模式下我用Python的socket库实现一个多线程服务器每个客户端连接分一个线程处理RTU模式下通过串口或者虚拟串口收发字节流。同时还需要实现一个可配置的异常注入层它可以按概率丢弃响应、故意延迟响应、发送非预期错误码甚至模拟CRC错误。这个模块让仿真器从“正常从站”升级成“故障演练平台”测试价值很大。3.3 为什么选用Python而不选其他语言这个项目我用Python实现不是没有考虑性能问题。Modbus协议本身吞吐量不高对于仿真器这种工具性质的应用单线程处理上百个请求每秒已经足够。Python的socket和struct库让字节解析非常简单开发效率极高和AI协作时也更容易生成可读性强的代码。如果你后续要把仿真器嵌入资源受限的嵌入式设备再考虑C或者Rust但对PC端调试来说Python是很合适的。可能有人担心Python的GIL会影响多客户端并发。实际上我在仿真器里用了线程池管理连接每个连接内的请求处理是顺序执行的连接之间并行。即便有GILI/O密集型任务的影响也不明显。真正的瓶颈反而可能是你本机的防火墙或者端口占用这个后面会在常见问题里专门说。4. 实操过程AI生成主框架到端到端联调4.1 给AI的初始化提示词设计AI原生开发的起始点不是代码而是提示词。为了得到一个可用的基础版本我按“需求约束产出格式”三个维度设计提示词。需求部分声明要开发一个Modbus仿真器支持TCP和RTU两种模式列出要支持的8个功能码和四个数据区。约束部分明确使用Python 3使用标准库不要引入第三方依赖代码要模块化关键函数要有注释。产出格式部分要求给出完整的目录结构和每个文件的职责说明。这段提示词写好后我做了两次交互。第一次让AI生成整体架构方案和文件列表我审查后发现它把RTU的帧解析做成了基于包内完整帧的假设没有考虑串口断帧粘帧的问题这就是一个需要人工修正的设计缺陷。第二次让AI根据修正后的设计生成代码生成的版本基本达到可用状态。这里分享一个经验提示词里写得越具体代码质量越高。比如你直接说“实现Modbus协议解析”AI可能给你一版过于理想化的代码但你说“Modbus RTU帧格式是从站地址1字节、功能码1字节、数据区、CRC16低字节在前高字节在后请按此格式解析”它出的代码就规范得多。另外让AI生成一个自测脚本也很划算。我用提示词要求它输出一个测试用例文件里面包含构造请求、解析响应、校验CRC的单元测试。这部分尽管不能替代真实联调但能在早期拦截掉70%的格式错误。4.2 核心代码实现与人工修正点下面这段是AI生成的TCP模式下处理03功能码的核心代码我截取了关键部分并标注了人工修正的地方。为了可读性我做了简化。def handle_read_holding_registers(self, request): # request: 已解析的请求对象 if not self.valid_address(request.start_addr, request.quantity): return self.build_exception_response(request.func_code, 0x02) data self.registers.read_words(request.start_addr, request.quantity) resp bytearray() resp.append(self.slave_id) resp.append(request.func_code) resp.append(len(data) * 2) for value in data: resp.extend(struct.pack(H, value)) return self.build_tcp_header(request.transaction_id, resp)AI最初生成的版本里struct.pack(H, value)写成了struct.pack(H, value)没用显式的大端字节序。我的运行环境是x86小端机器这就导致多字节数据全部反了。修这个bug花了十分钟但如果我在提示词里注明“所有多字节字段按大端序存取”一次性生成正确的概率会更高。还有一处细节是数量字段为0的请求。按规范Modbus请求中寄存器数量为0是非法的应该返回异常码03非法数据值。但AI第一版代码里没有检查quantity为0的情况直接尝试读取0个寄存器并返回成功。单测里没暴露这个问题因为单测都是按正常值构造的。后来我用真实主站故意发了几个畸形请求才抓到。这些边界条件AI模型容易忽略必须靠人的测试意识补上。4.3 从站功能模拟让仿真器更真实单纯响应请求只能算半个仿真器真正好用还得让数据“活”起来。我给仿真器加了一个可选的动态数据模拟功能寄存器数据可以按照预设的曲线周期性变化比如模拟一个温度采集点每秒钟数值在20.0到80.0之间波动或者模拟一个累计流量数值持续递增。实现方式很简单用一个后台线程定时更新指定寄存器的数值更新规则写在配置文件里。这个功能在调试上位机时非常有用。比如你要验证趋势曲线的绘制逻辑让仿真器跑一组正弦波数据界面就能画出真实感的曲线你要验证报警阈值判断就让某个线圈按时间规律翻转。对AI来说这个功能也就是一个线程加一个配置解析器的事它很快就能写出来。但要提醒的是更新频率别太高普通寄存器区刷新10到20Hz足够了太高反而会给日志模块造成压力。4.4 异常注入的实现方式异常注入是仿真器区别于普通模拟工具的核心亮点。我在实现时做了分层设计保证正常模式和异常模式互不干扰。第一层是响应延迟注入可以对指定功能码或指定寄存器区间施加固定的延迟时间比如让03功能码统一延迟2秒响应用于测试主站超时处理。第二层是错误响应注入可以强制返回指定的异常码比如模拟非法地址、非法数据值。第三层是数据破坏注入直接在响应报文中篡改一个字节或者故意算错CRC用于测试主站的容错能力。代码上我定义了一个异常规则配置类每个规则包含触发条件按功能码、寄存器区间、概率比例和动作延迟、丢包、返错、篡改。AI原生开发的便利在这里体现得很明显规则的解析和匹配逻辑基本都是AI生成的我只需要明确描述规则结构再审查结果。实测下来用这套注入功能测试客户端能发现很多平时隐藏很深的处理缺陷比如主站在收到异常码后没有正确释放连接资源、超时后没有重试等。4.5 端到端联调AI代码的真实检验代码写完不是终点端到端联调才是硬标准。我的测试环境分两端主站端用了一个开源的Modbus客户端工具从站端就是我们的仿真器。联调步骤按功能码逐个过先读后写再测异常。先配置好TCP Server运行在502端口工具连接后读取保持寄存器区确认能拿到预设值然后写单个寄存器和多个寄存器再读回来确认写操作生效。线圈区的读写同样过一遍尤其测试15功能码写多个线圈时要确认响应报文的地址和数量字段回显正确。RTU模式的联调稍微复杂。我在Windows上用虚拟串口软件创建了一对互联的COM口主站工具连COM1仿真器监听COM2这样完全绕开物理串口设备。用RTU模式测试时重点验证了CRC校验逻辑故意用测试工具发一个CRC错误的报文仿真器应该丢弃响应而不是返回错误帧——这是Modbus规范要求的从站行为。AI生成的代码在这个环节通过检验没有出现违反规范的行为。5. 常见问题与排查技巧实录5.1 字节序与数据类型踩坑字节序问题是Modbus开发里最经典的坑AI也不例外。比如一个float32数值20.5在Modbus中按两个16位寄存器存储但具体哪个寄存器存高位、哪个存低位不同厂商的设备习惯不一样。仿真器作为“万能从站”必须能配置这些规则。我实现了一个数据类型转换层读取和写入寄存器时根据配置自动完成字节序和组合逻辑的转换。实际踩坑案例之前遇到一个仪表它的浮点数在协议文档里没写清楚字节序我用仿真器按大端模式模拟上位机读出来是几千上万的不正常数值。折腾了半天后来换小端字节序存储到两个寄存器里数值立刻正常了。所以给AI写需求时我特别要求它把字节序抽成独立配置模块而不是写在业务代码里。这条经验同样适用于所有Modbus仿真工具的开发灵活配置永远是第一优先级。5.2 端口被占用与连接断开问题TCP模式下最常见的故障就是端口被占用尤其是默认502端口。Windows下排查要先用命令查出是谁占用了端口然后停掉进程或换一个端口测试。仿真器配置里支持自定义端口默认502起不来就换1502或者5502两边一致就行。连接断开的问题也遇到过。仿真器长时间运行后主站端偶尔报连接重置。一开始我怀疑是AI生成的多线程代码有问题后来排查发现是操作系统对空闲连接做了保活超时客户端没有及时发心跳连接被系统回收了。解决方法是仿真器侧加了TCP KeepAlive配置主站侧也加了周期性地读取操作来保活。如果嵌入式设备连接不稳定还可以在仿真器里加自动重连逻辑虽然从站通常是被动方但保持TCP会话稳定是双方共同的责任。5.3 并发压力下的异常抖动为了验证仿真器在并发场景下的稳定性我用多线程工具模拟了20个客户端同时连接每个客户端循环执行读操作持续1小时。过程中发现日志文件的写入频率非常高磁盘I/O一度成为瓶颈导致偶发响应延迟。定位后用异步日志写入代替同步写文件并把日志等级从DEBUG调到INFO问题消失。这个教训说明仿真器本身虽然逻辑简单但日志、配置加载等周边模块也可能影响通信实时性。另一个并发问题是寄存器区的线程安全。多个客户端同时读写同一块寄存器区域时如果没有锁保护可能出现数据竞争。AI生成的初版代码里没有加锁我用压测脚本重复写同一个寄存器时偶发读回不一致的值。审查后给数据存储模块加了一个读写锁写操作独占读操作共享问题解决。这类并发问题在功能测试阶段不明显只有压测才会暴露所以排查时要有意识地往线程安全方向想。6. 用AI生成测试用例与自动化验证6.1 单元测试的选取与设计测试范围我划分为四个层次报文编码解码测试、功能码处理逻辑测试、异常注入规则测试、端到端集成测试。其中报文编码解码测试最能拦截AI的格式错误我把每一个功能码的请求和响应报文设计成真实字节序列然后断言代码解析或生成的结果和字节序列完全一致。比如03功能码请求报文直接给出一段十六进制数据期望解析出的起始地址和数量是确定值。功能码处理逻辑测试则侧重于边界条件。每个功能码都测试地址越界、数量为0、数量越界、对只读区域执行写操作这四类异常场景。这些测试用例很大一部分由AI批量生成但生成的思路需要人来引导——我会先给AI写两个示范用例让它仿照格式补齐剩余的功能码这样生成质量明显高于直接让它凭空发挥。6.2 用主站工具做端到端回归单元测试通过后我习惯再用真实协议工具做一遍回归测试。开源的Modbus工具可以自由构造报文等价于一个可视化调试器。我先配置默认的连接参数再手动操作读写功能确认结果无误。接着跑一遍异常测试手动发送一个请求起始地址超出寄存器区范围的报文仿真器应该返回02异常码发送一个CRC故意错误的RTU报文仿真器应该不响应。这种端到端验证很有价值它能发现单元测试覆盖不到的交互问题。比如MBAP头里的长度字段是否合理、异常响应是否也正确携带了事务处理标识符等都是靠主站工具抓真实报文比对确认的。我建议所有基于AI生成的Modbus代码最终都必须用真实协议工具过一遍这是检验AI成果的底线。6.3 自动化压测与稳定性观察稳定性压测我用自制的压测脚本完成。脚本里开多个线程每个线程循环执行“读保持寄存器-写单个寄存器-读回校验”的流程记录成功率和平均响应时间。初始版本连续跑20分钟后我发现内存占用缓慢上涨怀疑有连接资源泄漏。排查后确认问题出在某个异常路径的socket没有及时关闭AI生成的代码里遗漏了finally语句。修复后再压测内存曲线平稳成功率达到100%。这里想多说一句AI原生开发里最容易被忽视的就是资源管理。因为AI生成代码时主路径通常漂亮但异常路径的清理逻辑经常缺失。所以人工审查时要重点追查这类问题每个异常分支是否有return、是否有资源释放、连接关闭逻辑是否覆盖所有场景。这种审查习惯比多写一千行代码更值钱。7. 项目扩展方向与个人体会仿真器这个项目还可以朝几个方向扩展。一个是Web化把仿真器的配置界面做成浏览器访问方便团队共享使用不用每台电脑都配Python环境。另一个是支持更多协议比如把S7、CANopen、OPC UA这些工业协议也做成仿真能力形成一个统一的多协议模拟平台。还有一个方向是把仿真器接入自动化测试框架在CI/CD流水线里自动启动和停止配合回归测试脚本完成协议层的自动验证。这些扩展都能继续沿用“AI生成人工审查”的开发模式开发成本相比传统方式会低很多。最后分享一下个人体会。经过这个项目我对AI原生开发的看法从“尝鲜”变成了“务实工具”。它确实能大幅提升编码效率尤其在协议解析这种有标准答案的领域但前提是使用者必须具备扎实的基础功。你需要知道Modbus报文长什么样、CRC的字节序哪里容易错、并发场景下哪些资源需要保护这些知识决定了你能否准确识别AI的错误。也就是说AI不是替代你的技术能力而是放大你的技术能力前提是你自己得先有那份能力。如果你也想试试别一上来就追求全自动。先拿一个小模块做试点比如只让AI生成03功能码的处理代码你自己把其他部分写好跑通了再逐步扩大范围。这样既能感受到效率提升又能在可控范围内积累AI协作的经验。希望这篇文章能给你一些启发少走我踩过的那些坑。