最近在搞一个户外环境监测的小项目现场一堆RS485接口的传感器——风速仪、土壤墒情探头、光照度传感器个个都要配波特率、设备地址、数据位这些参数。隔壁还要挂几个LoRa透传模块用来把采集数据从田间传回网关扩频因子、带宽、发射功率、空中速率都得对着手册一个个调。以前遇到这种活我的做法是拆一个USB转RS485的小板子打开任意串口助手手搓十六进制指令还要拿计算器算Modbus CRC太折腾了。后来想到Workbuddy这类AI编程助手既然它能按自然语言生成代码那干脆让它把这个“RS485 / LoRa 参数调试工具”整个写出来。试下来效果真不错从描述需求到拿到一个能跑的桌面工具大约只花了一个下午其中大部分时间还是花在我自己验证和改坑上。这篇文章直接把完整过程写出来需求怎么拆、提示词怎么设计、Workbuddy生成的代码长什么样、实测遇到哪些坑希望对想用AI工具加速嵌入式调试的同行有点参考价值。1. 从手动改数据到让AI写工具这个调试需求是怎么来的先说下场景。我这次要调的设备分两类一类是RS485总线上的Modbus-RTU从机设备比如风速传感器默认波特率9600只要给它发一条Modbus报文就能修改设备地址和波特率另一类是LoRa无线模块比如E22-400M系列通过串口接收AT指令可以查询和修改频率、扩频因子、带宽、发射功率、校验方式等。以前我用的调试方式比较原始打开串口助手选择COM口和波特率然后在发送区填十六进制数据CRC校验自己用计算器或者一个小加密狗算。Modbus改地址和波特率的指令还不一样有的是功能码0x10写多个寄存器有的是0x06写单个寄存器稍微搞错就失败。LoRa模块的AT指令倒是文本格式但返回的PARAM: 868500000,9,7,1,4,20这种一长串我经常要对着说明书解析半天。为什么想到用Workbuddy因为这类调试工具本质上是个“串口收发 参数面板 协议解析”的小软件逻辑上不算难但手写一个完整带GUI的要花不少时间。我平时用Python比较多用tkinter加pyserial大概要写四五百行里面还涉及串口扫描、十六进制转换、CRC计算、日志循环等边角功能。这些恰好是AI编程助手比较擅长的领域。Workbuddy的交互方式类似一个“项目级”的智能体可以给它交代一个多步骤任务它会自己拆分、写代码、给出使用说明比一条条问答案方便得多。所以我给自己定了一个目标用Workbuddy生成一个“RS485 / LoRa 参数调试工具”这个工具要能做三件事扫描并连接电脑上的串口支持设置波特率、数据位、停止位、校验位针对RS485总线设备内置Modbus-RTU报文构造功能可以方便地读寄存器、写寄存器自动算好CRC针对LoRa模块能发送AT指令并把返回的参数解析成可读的配置项支持直接改频段、扩频因子、带宽、功率等。另外还要能保存日志、读取内置的常用命令模板。把这些需求列清楚后下一步就是怎么跟Workbuddy说。2. 需求拆解和提示词设计RS485与LoRa参数调试到底要什么直接丢给Workbuddy一句“给我写一个串口调试工具”是不行的它生成出来的东西大概率是个空壳什么协议都没内置。要让AI写出能真正干活儿的工具得自己先把需求拆成小块再把每一块的细节写清楚。这个过程很重要甚至可以说比写代码本身更考人。2.1 RS485调试子系统的关键点RS485物理上是半双工总线通常采用Modbus-RTU协议。作为调试工具至少要处理这几类操作串口连接需要列出本机的串口设备号能选择波特率。RS485传感器常见波特率有9600、19200、38400、115200等也要支持数据位、停止位、校验位组合。Modbus报文构造Modbus-RTU帧的结构是“设备地址 功能码 数据 CRC16”。调试时最常用的是功能码0x03读保持寄存器、0x04读输入寄存器、0x06写单个寄存器、0x10写多个寄存器。改设备地址一般是写保持寄存器改波特率一般是写某个厂商自定义的寄存器地址这些要可配置。CRC校验Modbus的CRC16是多项式0x8005初始值0xFFFF低位在前。这个必须让AI准确实现很多工具算错就是多项式高低位搞反了。报文收发与显示一次完整的读寄存器指令是8个字节地址 功能码 起始地址(2字节) 寄存器数量(2字节) CRC(2字节)。发送后收到设备回复要在界面上以十六进制显示并解析出寄存器值。我在给Workbuddy的提示词里特意把这些点都列了出来并且给了一个读寄存器的请求示例。2.2 LoRa调试子系统的关键点LoRa模块的调试跟RS485不太一样大多是通过AT指令操作。不同厂家的指令略有区别但常见的配置项是统一的频率如ATBAND868500000扩频因子ATSF9一般取值7到12带宽ATBW7不同模块的数值对应125kHz/250kHz/500kHz编码率ATCR1取值1到4发射功率ATPOWER20单位dBm范围取决于模块硬件模块地址和目标地址ATADDR0001这种空中速率/串口速率等。LoRa模块一般上电默认是透传模式发送普通字符就会发送到空中。要在“参数配置模式”和“透传模式”之间切换很多模块是通过拉低M0/M1引脚或者发送特定指令进入配置模式。作为上位机工具我们只需要把AT指令通过串口发出去然后解析返回的字符串。为了让Workbuddy写出来的工具贴合这种用法我在提示词里特别说明了LoRa部分要以“命令行交互”的方式工作用户在输入框里可以直接输入AT指令也可以从下拉列表选择常用配置项配置项选择后会拼出完整的AT指令工具的显示区要能同时显示发送和接收的ASCII文本并能对这些文本做简单的时间戳标记。2.3 一份可以“抄作业”的提示词如果你也想用Workbuddy做类似工具可以直接参考我当时写的提示词。我把它分成“任务背景”“功能需求”“技术限制”“交付要求”四块像项目需求文档一样喂给AI。请用Python编写一个用于RS485 / LoRa参数调试的桌面工具使用tkinter做GUIpyserial做串口通信。 功能要求 1. 自动扫描并列出所有可用串口可以设置波特率、数据位、停止位、校验位默认9600-8-N-1。 2. 支持Modbus-RTU协议报文构造 - 可以填写设备地址、功能码、起始地址、寄存器数量/写入值 - 自动计算CRC16多项式0x8005初始值0xFFFF输出为两个字节低字节在前 - 发送后接收响应以十六进制显示并尝试解析寄存器数值。 3. 支持LoRa模块配置 - 有一个单独的标签页可以输入AT指令 - 提供常用配置参数下拉框频率、扩频因子、带宽、编码率、发射功率、模块地址 - 选中参数后自动生成对应的AT指令并发送 - 接收区显示返回的文本信息。 4. 所有收发记录都要显示时间戳并保存到日志文件debug_log.txt。 5. 界面布局不要拥挤发送区、接收区、参数配置区要分开。这份提示词其实已经把大逻辑都讲清楚了Workbuddy拿到后会生成一个单文件Python脚本。如果它生成的代码报错再把出错信息复制给它让继续修就行不用自己改太多。 ## 3. Workbuddy自动生成的代码长什么样串口帧、Modbus和AT指令的实现 Workbuddy第一次生成的代码结构非常清晰整个程序约500多行一个文件搞定包括三个主类SerialPortManager、ModbusRTU、LoRaConfigTool再加上一个主窗口类DebugToolApp。 ### 3.1 串口扫描和连接管理 串口扫描是第一步。Workbuddy使用了serial.tools.list_ports.comports()这个在pyserial里很常用能列出设备名和描述。代码如下 python import serial import serial.tools.list_ports def list_serial_ports(): ports serial.tools.list_ports.comports() return [f{p.device} - {p.description} for p in ports]连接部分更关键要在打开串口时处理权限、占用、设备不存在等问题。Workbuddy写了一个connect_serial函数把serial.Serial的异常都捕获了比如设备不存在时提示“未找到对应串口设备”设备被占用时提示“串口被占用请关闭其他调试工具”。这点比我想象中细心省得我一会儿加异常处理。打开串口的参数配置也很标准self.ser serial.Serial( portport, baudratebaudrate, bytesizeserial.EIGHTBITS, stopbitsserial.STOPBITS_ONE, parityserial.PARITY_NONE, timeout0.2, write_timeout0.5 )其中timeout0.2是延迟等待返回意味着每次发送后最多等200毫秒。这个值对RS485快读写来说够用对LoRa模块AT指令也比较合适。如果你的设备响应慢可以手动改成0.5。3.2 Modbus-RTU CRC的实现这是我最关心的一块因为以前手写CRC踩过坑。Workbuddy生成的CRC函数用的是标准查表法其实也可以直接计算但查表效率更高。看起来是这样的def crc16_modbus(data: bytes) - bytes: crc 0xFFFF for byte in data: crc ^ byte for _ in range(8): if crc 0x0001: crc (crc 1) ^ 0xA001 else: crc 1 # Modbus CRC为低字节在前 return bytes([crc 0xFF, (crc 8) 0xFF])注意这里最后返回的顺序是低字节在前这符合Modbus-RTU发送帧的要求。比如计算01 03 00 00 00 01的CRC结果是0x84 0x0A那报文就是01 03 00 00 00 01 84 0A。Workbuddy生成的函数还附带了一个单元测试入口可以用已知的帧验证这点很好可以直接拿来测。3.3 Modbus发送和解析AI生成的主界面里有一个“Modbus调试”页签几个输入框分别对应设备地址、功能码、起始地址、寄存器数量、写入值。点击“发送读取指令”时工具会动态拼装报文并调用ModbusRTU.build_read_holding_registers(addr, start, count)方法。生成TCP模式或者RTU模式这里默认RTU。接收响应的处理也不复杂读取串口收到的字节如果长度超过预期去掉首尾可能的多余数据解析出寄存器数值。Workbuddy写了一个解析函数def parse_read_response(response: bytes, count: int): if len(response) 5 2 * count: return [] data response[3:3 2 * count] values [] for i in range(0, len(data), 2): values.append(int.from_bytes(data[i:i2], byteorderbig, signedFalse)) return values根据Modbus协议读寄存器的响应帧是“地址 功能码 字节数 寄存器值 CRC”。这个解析逻辑是对的16位寄存器值按大端字节序转成整数。风速、土壤湿度这类传感器的寄存器十有八九都是16位大端所以能直接看到十进制数值。3.4 LoRa AT指令面板LoRa部分Workbuddy也分了两个块一个“手动AT指令”输入框一个“参数快捷配置”区。快捷配置区的下拉框选项是基于当前市面上常见的LoRa模块AT指令集来设计的。比如带宽选项0125kHz7125kHz某些模块1250kHz2500kHz这个数字因模块而异但工具提供了下拉框让用户自己选。配置完点击“发送配置”后界面在发送框会显示实际拼出来的AT指令比如ATBAND868500000。点击后原样发给串口。接收区会显示模块返回的OK或ERR等。这个设计的好处是透明不会因为工具“太自动化”而让人看不懂实际在发什么。我当时特意在提示词里要求“生成的指令必须显示在发送输入框中可以由用户手动修改后再发送”这样即使是普通用户也能看清楚每个参数背后的AT指令长什么样。4. 实测中遇到的那些坑自动换向、CRC校验、十六进制盲区工具生成后的第一版能跑但真的接入硬件后还是暴露了好几个问题。这里把排查过程写出来给大家当反面教材参考。4.1 RS485半双工的“自动换向”问题问题现象用USB转RS485模块连接风速传感器发送读指令后接收区经常只有一会儿有反应一会儿没反应或者收到的数据莫名其妙不完整。排查过程我先怀疑是波特率不对重新看了设备配置9600没有错。接着怀疑是接线问题A/A、B/B都接对了电源也正常。后来用示波器看A、B波形发现发送结束到接收开始这段时间总线方向没有及时切换。原因分析市面上很多USB转RS485模块是通过芯片内部的收发器自动切换方向的比如CH340加MAX13487、FT232RL加SP485这种。但自动换向需要靠“发送使能”信号控制有的模块使用RTS引脚来做方向切换有的使用DTR引脚。Workbuddy生成的程序里我在打开串口时并没有设置RTS或DTR的状态。默认情况下pyserial可能把它们置于某种电平导致模块一直处于发送状态或者方向切换迟钝。解决方式在打开串口后根据模块说明书设置RTS信号。典型做法是发送前把RTS置高发送完再拉低。但是具体高低对应哪个状态也因模块而异。我用的这个模块是发送时RTS拉低接收时拉高。于是我在代码里加了self.ser.set_rts(False) # 初始设为接收状态然后在发送前self.ser.set_rts(True) # 切到发送状态 self.ser.write(data_bytes) self.ser.flush() self.ser.set_rts(False) # 切回接收状态这段代码我是直接让Workbuddy改的告诉它“需要在发送时切换RTS来控制485方向”它很快就给出了修改。实测后通信稳定多了说明这类方向切换逻辑很适合交给AI快速改。提示如果你用的USB转RS485模块不是RTS方向控制而是靠硬件自动换向那就不需要手动设置RTS。先确认模块型号再决定要不要加这段逻辑。4.2 CRC计算多了个坑顺手把16进制字符串转成字节另一个坑出现在用户手动输入。Workbuddy默认在界面里把十六进制输入的文本直接当成ASCII字符发送而不是转成字节。比如用户想发送01 03 00 00 00 01 84 0A结果工具真的把这串字符包括空格作为ASCII码发出去了这会对端设备直接忽略。排查起来也很坑因为我发现通过“Modbus快捷构造”发送的指令是正常的但手动输入十六进制报文时总是不对。后来看日志才发现手动输入走了另一个发送函数那个函数直接把str.encode()了。修复方案让Workbuddy增加一个“手动发送”模式当输入框内的字符串包含空格或全部是十六进制字符时自动把它转成字节再发送。代码逻辑很简单def bytes_from_hex(hex_str: str) - bytes: clean hex_str.replace( , ).replace(0x, ) return bytes.fromhex(clean)然后发送前判断一下如果字符串可以按十六进制解析就直接当成十六进制发送否则按ASCII发送。这样既保留了AT指令等文本发送能力又兼容了Modbus十六进制报文。这个改动我描述给Workbuddy后它重新生成了发送函数加了十几行代码实测通过。4.3 LoRa模块透传模式下收到“乱码”LoRa模块的坑在于它上电后可能处于透传模式此时你发ATBAND...会被当成空口数据发出去模块不会本地响应自然就没有返回。所以工具连接后第一次发AT指令经常石沉大海。我的处理方法是先通过模块的配置引脚把模块切到“配置模式”或“工作模式切换”状态。比如有些E22模块需要把M1拉高、M0拉低才能进入配置模式这是硬件层面的设置上位机控制不了。但软件上工具可以支持“发送唤醒指令”ATCMD或ATRESET来让模块先回到配置状态。所以我在LoRa页签里加了一个“唤醒/重置”按钮Workbuddy生成的代码如下def send_attention_command(self): self.send_ascii(ATRESET\r\n)实测下来发送ATRESET后再发送参数配置指令大部分模块就能正常响应了。如果你手头的模块是用引脚切换的那需要手动拨一下模块上的拨码开关工具这边只能保证指令格式正确。4.4 十六进制显示区自动加空格的小技巧日志显示那块一开始Workbuddy直接把接收到的字节打印成原始ASCII遇到非打印字符整个界面就乱掉了。后来让它改成统一格式化输出比如def format_received(data: bytes) - str: return .join(f{b:02X} for b in data)这样接收区既能显示Modbus的十六进制帧也能把LoRa的AT返回文本正常显示。但是LoRa返回的文本是ASCII如果也强制十六进制显示用户就看不懂了。所以我做了个切换如果收到的数据里可打印字符比例超过70%默认按文本显示否则按十六进制显示。这个策略很实用让一个接收区同时兼容两种协议。5. 让这个工具变得顺手界面打磨、日志记录和扩展方向Workbuddy生成的工具底子有了但离“顺手”还有一段距离。我实际用了几次后做了以下几个调整都通过再次向Workbuddy提需求来完成。5.1 界面布局调整第一版的界面三个页签分别是“串口设置”“Modbus调试”“LoRa调试”但每次切换串口参数要回到第一个页签挺别扭。后来我让Workbuddy把串口连接设置放到了顶部工具栏不固定在某一个页签里这样在两个调试模式下都能随时重连、切换端口。另外接收区的字体默认很小看十六进制报文很累。我在提示词里补充了一句“接收区字体用Consolas或Courier New字号12”生成后看起来舒服多了。如果你也做类似工具建议一开始就提字体要求不然后面改起来虽然不难但总会忘几个控件没改到。5.2 日志轮转与按时间戳记录原先的日志就是一个txt文件持续追加时间久了会很大。我让Workbuddy改成按日期分文件比如log_20250614.txt并且每条记录加时间戳、方向标识发送/接收。现在这个工具连续跑了一周日志文件都很整齐每次现场回来只要翻对应日期的文件就能看到当时发过哪些指令这对排查现场问题太重要了。import datetime def log_record(self, direction: str, data: str): timestamp datetime.datetime.now().strftime(%Y-%m-%d %H:%M:%S) line f[{timestamp}] {direction}: {data} with open(flog_{datetime.date.today()}.txt, a, encodingutf-8) as f: f.write(line \n)这样的日志格式简洁明了关键信息齐全。5.3 后续扩展方向这个调试工具虽然小但后续可以扩展的点不少Modbus轮询功能在工具里预设一批待读寄存器定时循环读取直接把每个传感器的数值画成曲线。这对环境监测的长期测试很有用。LoRa多模块组网测试可以同时开多个串口每个串口连接一个LoRa模块一键把一组参数写到多个模块上用来快速配置一个星形网络。参数模板导入导出现场设备多了之后每次手动填参数还是麻烦。把常用设备的参数保存成JSON模板换新设备时一键加载能省不少时间。这个需求我给Workbuddy提了以后它生成了一段配置文件读写逻辑加上界面上的“保存模板”“加载模板”按钮20多行代码就解决了。远程Web化现在工具是本地桌面版如果想让现场的同事在手机上也能操作可以考虑把它改造成一个内网Web工具用Flask提供串口通信接口前端用浏览器调试字段。这个复杂度就高一些但Workbuddy也能处理。5.4 关于Workbuddy使用的整体感受整个项目做下来我的体会是用Workbuddy写这种“参数调试工具”非常合适因为需求边界清晰、技术栈固定Python/串口/Modbus/AT而且可以用交互式修正来不断逼近正确代码。比起完全手写效率高不少。但前提是你自己要清楚RS485和LoRa这些协议细节至少能判断生成代码里的CRC顺序对不对、波形方向反没反。AI生成的代码看着合理实际跑起来还是得靠人来验证。就比如CRC那道坎如果不懂Modbus帧格式AI给了错的字节序可能也识别不出来。所以我把这次经历写出来也是想提醒大家像Workbuddy这类工具是很好的写代码助手但不能替代你对硬件通信协议的理解。如果你也想做一个类似的RS485 / LoRa参数调试工具可以按照我上面的提示词去试建议先跑一个最简单的“扫描串口 发送十六进制数据”的版本再逐步加上Modbus、LoRa的功能每加一个模块就实测一下。这样既不容易翻车也能慢慢积累出自己的一套调试工具库。