接前一篇文章：PY32F系列MCU在OTA时App区概率性跑不起来的根因分析（5）
四、总结与感悟
前边几篇文章分析定位并解决了笔者在实际项目中遇到的OTA时偶发的程序跑飞问题。本篇文章对于整个过程进行总结，并给出笔者在此过程中的一些感悟。
定位这个问题前后花了差不多一个月的时间，期间笔者经过了前边文章所述的不断增强手段、绕过此问题的过程，但是对于根因一直不能捕捉到。实际上，之前笔者是改过这一块的，前文书给的例子是基于PY32F0系列的，笔者之前修改过这块，只是当时没觉得这块如此重要。真正出现问题、花时间探寻问题的是另外一块板子，它是基于PY32F4的，不过意思上差不多。为了便于说明和理解问题，前文书笔者就合二为一了。
这个问题的解决过程实际上是分了两条线。
- 第一条线
由于笔者一直不能定位到根因，只能采取尽量规避的方案，这个过程就是笔者前文书讲的不断增强复位手段的过程。真正让这个问题有所转机的是那天下午在天使用户家没有经过OTA也出现跑飞的那一次。笔者之前经过最强复位手段仍不能完全解决问题时，就曾怀疑过并非是OTA引发的问题，刚好那天复现同样的问题，印证了笔者的猜测。这样一来就有一个好处，将问题定位范围锁定在了APP_Bootloader_Go函数，进而锁定在APP_DeInitInterface函数中。
按照正常流程，笔者接下来会将APP_DeInitInterface函数也按照PY32F0系列的做修改，修改之后大概率就不会复现问题了。那么再倒推，想清楚为何做出如此改动后会解决问题，从而定位到根因。这个过程属于反向定位。
- 第二条线
本来应该会按照第一条线的流程走，但是当时时间太紧迫了，经过组会集思广益后，决定使用Cursor定位问题。好在当时前一天已经再天使用户家复现了问题，将范围已经缩小到了APP_Bootloader_Go函数中。结果经过了几分钟的思考，Cursor给出了它的根因分析。这个过程属于正向定位。
那天赶得也巧，前一天天使用户家复现问题后，第二天上午就开始走第一条路线，下午基本上代码就快改完了。但由于当时并不知道这样能否解决问题，因此同时走第二条线。两条线在下午交织汇聚到了一起，都指向了APP_DeInitInterface函数。最终解决了该问题。
但是这其中有一个特别要说的，也就是笔者在此过程的感悟。即使走的是第一条线，笔者也只能是先解决问题，再反推代码差异，进而找到问题跟因。并不能做到直接正向分析出根因。笔者从业20多年了，在单片机领域也算颇有经验了，但比AI在短短几分钟之内就能分析代码、正向推断问题的能力相差甚远。后边又有一个问题，同样是靠AI解决的（后边会有专门文章），那个问题的解决过程就更凸显笔者和AI的差距了。这个差距一度让笔者十分沮丧，干了二十年、最起码单片机经验也有十几年，反倒不如AI。不过后来笔者想明白了，笔者所面对的不单单是AI，而是其背后的大数据、大模型。这其中蕴含了全球成千上万的工程师的智慧结晶，笔者比不过AI，其实输得不冤。这就好比一个人和一个汽车比赛谁跑得快是一个道理。