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界面搭建、发送线程和界面线程的通信、异常处理。每一项单独看都不算难，但合在一起，加上调试时的各种边界情况，保守估计要一个完整工作日。
问题是我当时没有一整天的时间。现场那边设备等着联调，我这边连基础报文都不能完整拼出来，这时候再按传统路径走，估计要加班到深夜。所以我把目光转向了AI辅助开发。这个决定最关键的原因不是"AI能写代码"这么简单，而是104调试助手这种工具的属性非常适合AI生成——边界清晰、单机运行、逻辑独立、不涉及复杂架构，正是大语言模型最擅长的中等复杂度工具类项目。
2.2 AI辅助开发工具的选型与边界划定
现在市面上能用的AI编程工具很多，我这次主要用的是DeepSeek网页版，偶尔用Kimi做辅助核对。选择它们的核心原因是网页版随开随用，不需要配置环境，语义理解在中文提示词下表现相当不错，生成Python代码的质量也在线。另外本地有跨平台需求的，也可以考虑Cursor这类IDE集成的AI工具，但对我这种以"快速得到一个可用工具"为目标的场景，网页版对话式生成反而是最高效的。
这里要特别强调一下"零代码开发"的真实含义。我不是说连代码文件都没见着，恰恰相反，AI生成的核心代码、辅助函数、界面逻辑我都过了一遍，然后复制粘贴到本地的.py文件里运行。所谓零代码，指的是我自己没有手工编写任何业务逻辑代码，每一次逻辑创造都来自提问和AI的回复。我干的活是：把需求表达清楚、把AI给的代码粘到文件里、运行、把报错贴回去让AI修。这套模式下，我的角色从"写代码的人"变成了"提需求和验收的人"。
不过边界要划清楚。这种模式适合工具类、单次运行、规模可控的脚本型项目。如果你要做的是高并发的生产系统或者对可靠性要求极高的核心模块，直接拿AI一次性生成的代码上生产环境，那无异于拿自己的职业生涯开玩笑。AI生成的代码必须经过人工评审、测试验证才能进入关键路径，这是底线。
3. 调试小助手功能定义：把我脑子里没想清楚的需求一点点问明白
3.1 从原始需求到AI提示词：功能边界的收敛过程
很多人用AI写工具失败，问题不在AI，在于需求根本就没想清楚。我一开始的想法特别朴素：能发包、能看报文就行。但真要把这个工具做起来，需要拆解的功能远比想象中多。
我花了大概二十分钟在纸上画了画真正需要的功能清单。首先是连接管理，既能做服务端监听终端接入，也能做客户端主动连接从站。然后是报文收发，这个必须有时间戳、方向标识、原始Hex显示，还要能解析出帧类型和ASDU字段。接着是模板发送，总召唤、时钟同步、单点遥控、链路测试这类常用报文不能每次手敲Hex，得一键发送。还要有定时器，周期性总召唤或者周期链路测试，对排查通信稳定性特别有用。最后是报文统计，收发帧数、异常次数、最近一次错误提示，这些信息在现场联调时非常救命。
我把这份清单念给AI听之前，自己先按优先级排了个序。核心功能是第一和第二项，模板发送是第三项，定时器和统计属于加分项。这样即使AI只完成前两项，工具也已经能用了。把功能需求想清楚再动手，是我这次最受益的一步。
3.2 提示词里必须写清楚的六个要素
同样是给AI提需求，不同的人提出来效果天差地别。我总结下来，一份能产出合格代码的提示词至少要包含六个要素。
第一是角色设定。我给AI的开场白是"你是一名有十年电力自动化调试经验的资深工程师，精通IEC 60870-5-104规约"，这能让AI后续生成代码时自动带上规约知识，而不是泛泛地写一个TCP调试工具。
第二是功能清单。明确列出上面说的连接管理、报文收发、模板发送、定时器、统计这些功能，逐条编号，让AI知道这是硬性需求。
第三是技术栈约束。我明确要求只用Python标准库，界面用tkinter，网络用socket，线程用threading。这个约束极其重要，因为只要允许用第三方库，AI就可能会编造一个不存在的库名或者推荐需要额外安装的包，纯标准库方案能把环境问题降到最低。
第四是界面布局要求。我让AI按照左侧连接配置、中间报文列表、右侧快捷发送区、底部解析详情的方式排布，这样一个界面的雏形就有了，不用来回反复调整。
第五是规约细节。一句话讲清楚控制域I/S/U帧的区别、ASDU各字段顺序、公共地址和信息体地址低位在前，这些关键信息足以让AI避开大部分解析雷区。
第六是异常处理要求。我明确告诉AI：任何解析失败都不能让程序崩溃，必须在日志区域打印错误信息并继续运行。这个要求对现场工具太关键了，一次坏帧就把工具弄崩的场景谁遇到谁崩溃。
实际提示词我大概是这么组织的，贴出来给大家一个参考：
你是一名有十年电力自动化调试经验的资深工程师，精通IEC 60870-5-104规约。请用Python标准库开发一个104调试小助手GUI工具，要求：
- TCP服务端和客户端两种模式，端口可配置，默认2404
- 报文收发区带时间戳、方向标识、Hex原文、解析结果
- 解析结果需区分I/S/U帧；ASDU字段需显示类型标识、可变结构限定词、传送原因、公共地址、信息体地址，并翻译成中文名称
- 快捷发送区包含总召唤、时钟同步、单点遥控预置/执行、链路测试等常用报文模板，可自定义信息体地址
- 支持定时发送总召唤
- 统计收发帧数和错误次数
- 界面使用tkinter，Socket使用独立线程接收，用queue将数据回传UI线程，避免界面卡死
- 任何解析异常不得崩溃，须在界面显示错误日志
所有字段遵循104规约标准：控制域4字节，I帧第一字节bit0为0，发送序号占前两字节，接收序号占后两字节；ASDU传送原因、公共地址、信息体地址低字节在前。
这份提示词基本上就是我把前面想到的所有要素浓缩后的产物。AI拿到这样的输入，返回代码的准确率会显著提高，后面修的bug大多集中在协议细节层面，而不是大方向的错误。
4. 实际生成过程复盘：AI如何一步步把工具砌出来
4.1 第一轮对话：搭出TCP服务端骨架
第一轮我让AI生成的是整体框架，重点看网络层能不能跑通。AI返回的代码里有一个TCP服务端类，监听端口后每个客户端连接分配一个线程，接收到的数据放进queue，由tkinter的after方法周期性从queue取数据刷新界面。这个模式我看了觉得符合基本要求，而且它把主界面刷新的实现做成了事件驱动的机制，不需要额外操作界面刷新相关模块。
值得夸一句的是，AI第一次就把服务端和客户端模式做成了统一接口，通过一个连接模式的选择框切换。这比很多手写代码的开发者在架构上想得还周到。我在本地跑了一下，用了一个简单的测试脚本去连接这个服务端，发了几条字节序列，发现接收线程正常打印了收到的hex，界面也能显示出来。第一轮主要目标达成。复制粘贴AI的代码到main.py，运行，没有任何语法错误，这算是一个非常好的开局。
不过我也发现了一个细节问题：AI生成的TCP服务端默认绑定的是127.0.0.1，这在本地测试没问题，但真到现场连终端时，终端通常不在本机，必须绑到0.0.0.0才能接受外部连接。我让AI改成了0.0.0.0，同时保留了界面上的绑定地址输入框，这样本机模拟和跨设备联调都能用。这个改动虽然很小，但它反映了我在场景理解上比AI多走了一步。
4.2 第二轮对话：ASDU解析与报文可视化
骨架通了之后，第二轮我让AI专注做报文解析。这一步是整个工具的核心价值所在。AI生成的解析函数里有一个parse_apdu()，输入原始字节，输出一帧完整解析结果。它先从第一个字节判断是不是0x68，然后读第二个字节的长度，接着判断控制域是I、S还是U帧，最后把ASDU部分拆分成各个字段。
这里AI一开始犯了个典型错误：它在解析公共地址和信息体地址的时候用了大端字节序，也就是高位在前。104规约里这两个字段都是低位在前，所以解析出来的站地址完全不对。这是一个很隐蔽但影响非常大的bug，如果不仔细看，解析工具给出的地址会偏差巨大。我在测试的时候发现站地址显示和配置的不一致，意识到是字节序问题，直接跟AI说"104规约公共地址和信息体地址都是低字节在前，请用struct解包的<符号控制字节序"。AI立刻修正了解析逻辑，测试结果和预期完全一致。
ASDU部分AI做得很细，把类型标识翻译成了中文说明，比如64对应"总召唤"，2D对应"单点遥控"，01对应"单点遥信"，0D对应"短浮点遥测"。这些翻译不是AI瞎猜的，而是我提示词里让它按IEC 60870-5-101标准来实现的。翻译出来直接在界面上显示，现场调试时不用再翻手册查类型标识，方便太多。
4.3 第三轮对话：规约状态机的调试辅助
第三轮补的是"能主动干活"的能力——模板发送和链路管理。AI生成了一组构造帧的函数：build_total_call()构造总召唤报文，build_clock_sync()构造时钟同步，build_single_command()构造遥控报文，build_test_frame()构造链路测试帧。每个函数都返回完整的字节序列，只需要传入公共地址和信息体地址等参数。
在调测这部分时，我发现AI构造的U帧STARTDT报文和标准有出入。标准U帧是68 04 07 00 00 00，其中控制域第一个字节07表示STARTDT激活。AI一开始把启动字节和长度写对了，但控制域写成了03，那是STOPDT的帧格式，作用完全不同，一个激活一个停止，搞反了终端直接掉线。我对照标准把这个问题指出来，AI很快修正了相关模板函数。
另一个值得说的地方是AI帮我处理了I帧序号递增的逻辑。模板函数每次发送时，发送序号加1，接收序号记录最近一次从对端收到的帧序号。这个逻辑虽然不复杂，但手写的时候非常容易漏——发了几百帧以后序号乱了，对端静默丢帧，你还在那排查物理链路呢。AI把序号维护封装在send_i_frame()函数内部，我只需要调用它，序号递增逻辑自动处理。这一下把现场最容易踩的隐性坑提前填掉了。
5. AI生成代码最容易翻车的几个点：我踩过的坑
5.1 报文大小端与位域处理错误
如果说这次AI辅助开发有什么最值得分享的教训，那一定是大小端问题。104规约里传送原因、公共地址、信息体地址这些字段全部是低字节在前，这跟很多通用通信协议的高字节在前习惯正好相反。AI基于它对协议的混合记忆，生成解析代码时特别容易默认用大端，导致短地址类字段解析出现偏差。
我测试时发现站地址显示值比配置值多了几百，最开始还以为是AI解析逻辑算错了，后来把hex逐字节校对才发现是解包字节序的问题。解决办法是在解析模块统一封装一个低字节序解包工具，所有字段都走那一个入口，从根上避免每次各写各的，这样即使后续要扩展新类型标识，也不会重蹈覆辙。这个经验适用于任何二进制协议解析工具，不只是104。
位域处理同样容易翻车。控制域第一个字节的低两位才是帧类型标识，I帧是00，S帧是01，U帧是03。AI生成判断逻辑时，如果直接拿整个字节去比对，那S帧和U帧会混淆，因为同样包含低位特征。它可能从网上训练数据中学到一些模棱两可的写法。最后让AI改成按0x03做掩码再判断，逻辑就干净了。写这类解析代码时，掩码操作一定要写明确，别偷懒用整数字节比较。
5.2 模拟量标度变换的系数陷阱
这个坑是AI在解析遥测报文时踩的。104规约里模拟量有好几种格式，归一化值、标度化值、短浮点值，每种占的字节数和换算系数都不一样。AI在处理短浮点遥测时一开始用了struct的'f'格式解包，这本身没错，但它在生成标度化值的算法时，直接把系数写成了1.0，等于没有做标度变换。
实际工程里，标度化值的满量程可能是0到4095、0到16383甚至0到65535，对应的工程量上下限也各不相同。像我这边的实际需求，温度量程0到100度，对应标度值0到4095，如果系数写成1.0，解析出来的温度就是0到4095度的离谱值。把这个问题抛给AI后，它建议我留一个标度系数配置项，在界面上让用户填，我不需要改代码，只填量程就够。话说回来，这个设计其实不错，通用性更强了。但它的初始代码假设我使用默认系数就等于1这件事，还是要靠有现场经验的人来识别并修正。
5.3 编造函数与库版本幻觉
AI编造不存在的API，这个坑做AI辅助开发的人迟早会碰上。我这次遇到的案例是AI第一次生成UDP相关代码片段时，引用了一个我没见过的socket方法，一运行直接AttributeError。还有一次它建议我用一个第三方协议解析库，说"已经内置104规约支持"，我查了一下根本不存在。AI的底层机制是预测下一个词，不是查数据库，所以当它生成的内容特别顺畅但具体接口非常冷门时，就要怀疑是不是在幻觉。
对策很简单，也很粗暴：在提示词里限制死"只能用Python标准库"，拒绝一切第三方库调用。标准库的API是AI训练数据里最稳固的部分，幻觉概率低很多。另外，每次运行出错就把完整Traceback复制回给AI，不自己猜。AI看着报错信息修自己的代码，准确率比让它凭空重写高得多。这个流程我和AI配合得越来越顺，基本上一来一回就能修好一个错误。
除了这三个坑，还有一个界面线程同步的问题值得提醒。tkinter的界面更新必须发生在主线程，socket接收线程不能直接修改界面控件。AI第一次的代码就犯了这个问题，界面时不时卡死。我跟它说用queue加after轮询来串，它改完以后运行平稳，再也没有出现过界面无响应的情况。这类典型的GUI线程问题在AI生成代码里特别常见，因为训练数据里很多示例代码是一口气写完、没考虑线程安全的。
6. 工具在变电站现场的实际表现与提效对比
6.1 模拟主站和从站的自测过程
工具跑起来后，我第一件事不是直接拉去现场，而是先在办公室里做了一轮自测。我的方法是用一个终端模拟程序做对端，同时把调试助手分别跑在服务端模式和客户端模式下做交叉验证。
服务端模式下，我让终端模拟程序主动连上2404端口，然后我在工具上点击"STARTDT激活"，对端回了确认后，我再发总召唤。整个流程在报文列表里看得明明白白，激活帧、确认帧、总召唤、遥信遥测数据帧，一到两个字节的差异都能通过解析结果定位。客户端模式下，我让工具主动连终端模拟程序，这次重点看序号管理和断线重连，重复开关TCP连接、中断又恢复，工具都能自动重连并重新走STARTDT流程。
自测还帮我发现了一个问题：当终端在短时间内回发大量数据时，工具的解析速度有点跟不上，界面刷新显得卡顿。后来让AI把解析和界面刷新拆开了，解析在接收线程里完成，queue里只放解析好之后的字符串，界面线程只负责显示字符串。这样一来，即使一秒内到几百帧，界面也只是排队显示，不会拖垮接收线程。这个优化思路在真实现场非常重要，因为变电站的全站数据上送是瞬间的高频突发。
6.2 从一次现场联调故障看小助手的实际价值
真正让我觉得这个AI小助手没白做，是后面一次现场联调。某站点配网终端接入主站时总召唤老是失败，主站侧通道显示异常，通道建立后终端就是不上送数据。现场同事查了一上午，物理链路、路由、端口都没问题，最后把这台调试助手接到了终端上。
我用客户端模式直连终端，先看链路激活能不能通过。工具解析结果显示STARTDT确认正常返回，这排除了链路层问题。随后我手动点了一次总召唤，结果工具收到的不是大量数据上送，而是只有一条激活确认，之后就没了下文。我把工具发出去的总召唤报文和主站发出去的报文对比了一下，发现工具发出的帧序号在通道建立后是0，而主站那边发出的序号可能从某个历史值继续累加，导致终端认为收到的I帧序号不连续，直接整帧丢弃。
好家伙，问题不在终端，在主站侧的序号管理。这个结论让我和现场同事都非常意外，因为主站侧一般不会暴露序号逻辑，抓包看到的TCP层正常，很容易让人以为业务层没问题。调试助手把协议层解析直接摆在界面上，序号到底是多少、总数有没有跳，一目了然。有了明确证据，我们反馈给主站厂家，很快就定位并修复了序号同步逻辑。
这个案例最大的价值不是工具本身多厉害，而是它让排查问题的层次从"现象玄学"变成了"协议证据"。我拿着工具解析出来的报文截图，不用跟任何人争论到底是哪一层出了问题，单帧结构、序号、类型标识全都摆在截图里。这种效率提升，对于一个搞自动化调试的人来说，比什么都值钱。
经过这次AI辅助开发，我自己对工具类小项目的开发方式有了一些变化。以前遇到调试小工具的刚需情况，我潜意识还是觉得得自己动笔写；现在我会先想想这个工具的边界清不清晰、重不重，如果是个能在这个周末跑起来的轻量工具，AI出代码、我来验收，基本半天就能搞定。104/101这套协议本身很成熟，报文结构固定、逻辑边界清楚，恰好是AI发挥的场景。建议还在观望的朋友，挑一个自己的高频小需求，用这种方式试一把，踩一次流程，收获的不只是工具本身，还有一套全新的动手思路。