嵌入式编程-使用AI查找BUG的启发

最近修复的一个bug让我对AI在软件质量测试及BUG修复上的应用有了新的期待。

• 令人头疼的bug处理

生产反馈，一批设备在进行厂测的时候，有概率出现读取的设备DID会出现乱码。而且出现异常后，设备重新上电读取就能恢复。针对该问题，我们通过生产人员的描述能知道，烧入到flash的DID肯定是正常的，问题应该是出现在DID数据的传输上。所以按照常规的方法，我们需要梳理整个DID的读取流程。DID的读取的流程如下：

1、上位机通过主控的串口0向主控发起读取命令。

2、主控收到上位机读取命令后，调用通信模块通过串口1向zigbee模组读取DID。

3、zigbee模组收到主控的读取命令后，从自身token中读取不同类型的数据并拼接成DID。

由于步骤1，2是使用通信模块进行命令交互的，该模块负责对所有命令进行收发处理，因而出现问题的可能性小点。所以我把重点怀疑的地方放在步骤3。既然有了怀疑的地方，那就需要去查看相应的代码，该部分代码如下：

该部分代码是上一个程序员移交过来的，我也是第一次赏析。初略一看，里面充斥着移位及数组下标操作。要找出问题，需要理清这些移位及数组小标的作用。由于手上还有其它事项再加上本身也比较讨厌看这样的代码。就想着是不是干脆把它丢AI让它看看。

• AI对问题高效处理引发的思考

于是我就将整份代码丢到腾讯元宝，并进行了提问：

神奇的一幕出现了，腾讯元宝一下就找出了4个可疑点，我看到第一个就乐了。基本就是这个局部数组指针的问题了。

正常情况下，查找这样的问题没有大半天是搞不定的。但是AI只用了1分钟不到，这样的效率提升真的让人震撼。我也由此思考，要如何才能让AI在我们的代码测试及BUG修复上稳定且高效地提供助力。

通过分析上述模块，我们能看出该模块的特点是功能比较单一，没有太多的依赖。只需要一个.c文件传入就可以了。对于AI的注意力不会有大的分散。功能单一，没有太多的依赖。这不就是我们软件架构设计上一直说的高内聚低耦合及单一原则吗。

• 模块化是AI时代软件架构的核心竞争力

在AI驱动的开发范式下，模块化设计已不仅是可维护性的需求，更是人机协作的桥梁：于开发者，它解耦复杂性，聚焦核心逻辑；于AI，它提供可解析、可验证的战场，让算法从“经验猜测”升级为“精准打击”