Llenlleawg104/101协议，电力自动化现场天天要打交道的规矩。我最近干了一件以前想都不敢想的事：全程用AI工具，硬是没手写一行核心逻辑代码，搓出来一个104调试小助手。从需求拆解到工具能跑，前后就花了一个下午。这篇文章把整个开发过程完整复盘一遍——提示词怎么组织、AI生成的代码在哪些地方翻车、这个工具在变电站联调里到底帮我解决了什么问题，都会讲到。如果你常年被104/101报文折腾得够呛，或者对"用AI零代码做工具"这件事又好奇又存疑，这篇应该对你有用。
1. 104协议调试：为什么说它是电力自动化现场最磨人的环节
1.1 先别急着写代码，104协议到底在传输什么
104协议的全称是IEC 60870-5-104，本质上是把101规约的报文搬到TCP/IP网络上跑，默认端口2404。101走串口，104走网络，两者底层报文结构基本一致，区别主要在链路层的承载方式。电力系统里主站和变电站终端之间的大量遥测、遥信、遥控、遥调数据，都是靠这套规约在跑。
调104调试助手之前，我们得先搞清楚一个核心概念：APDU。104报文的完整结构是APCI控制域加ASDU应用服务数据单元。APCI固定6个字节，包含启动字符68H、APDU长度和一个4字节的控制域。控制域决定了帧的类型——I帧是数据传输帧，携带序号，是真正传业务数据的；S帧是确认帧，只回确认不携带数据；U帧负责启动、停止、测试链路这类控制动作。
ASDU负载里最关键的是这几个字段：类型标识、可变结构限定词、传送原因、公共地址、信息体地址。举个例子，常见的总召唤命令，类型标识是100（0x64），传送原因是6（激活），公共地址就是站地址，信息体地址通常从0开始。一条完整的帧长这样：
68 0C 00 00 00 00 64 01 06 01 00 00 00 00
拆开看就是：68表示起始，0C表示APDU长度12个字节，控制域4个00表示I帧且收发序号都还没动过，64是总召唤类型，01是可变结构限定词，06是激活，01 00是公共地址，最后三个00是信息体地址。这些字段在调试时不需要背，但解析工具必须能一眼帮你拆出来，否则单个字节核对就足够让人崩溃。
1.2 调试现场最常见的三类卡壳场景
做了这么多年电力自动化调试，我遇到最频繁的问题基本就是三类。
第一类，主站显示通道断开。抓包看TCP一直在重连循环，原因往往是链路启动流程没走完。104建链后不能直接发数据，必须先发U帧的STARTDT激活传输，对端回STARTDT确认后才能正常收发。很多终端对这一步非常严格，顺序错了直接不理你。
第二类，总召唤没响应或者只回了一部分。总召唤发出去，终端应该回一个激活确认，然后开始大量上送遥信遥测，最后再回一个激活终止。如果你只看到激活确认，后面数据迟迟不来，大概率是召唤范围、公共地址或者序号处理上出了偏差。
第三类，遥控预置总是超时。I帧序号不连续是这类问题的高发原因。104协议的I帧有发送序号和接收序号，如果对端发现序号跳变或者重复，整帧直接丢弃，主站那边看到的现象就是超时，但协议栈不动声色，排查起来特别恼火。
这三类场景说穿了就是一个需求：我需要一个工具，既能帮我解析每一帧协议结构，又能自己构造常用报文主动发给终端，还能实时看链路状态变化。市面上现成的104调试软件不是没有，但要么收费，要么界面和需求不贴合。这次我干脆用AI从零搭一个。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 零代码开发不是摆拍：为什么这次我选择让AI来写代码
2.1 常规开发路径的隐性成本
放在以前，我大概率会老老实实开一个Python工程，从socket收发写起，再做报文解析、界面展示、定时发送。这个流程我太熟了，清单列下来应该做的事至少包括：TCP服务端和客户端的编写、I帧和S帧序号管理、ASDU的struct解析、tkinter界面搭建、发送线程和界面线程的通信、异常处理。每一项单独看都不算难，但合在一起，加上调试时的各种边界情况，保守估计要一个完整工作日。
问题是我当时没有一整天的时间。现场那边设备等着联调，我这边连基础报文都不能完整拼出来，这时候再按传统路径