1. 从“人肉翻手册”到“AI结对编程”：嵌入式开发方式的转变信号
做了这么多年嵌入式开发，我越来越觉得传统开发模式里有个极其消耗精力的环节——芯片外设手册和寄存器配置。你打开一个STM32的参考手册，几百页，看定时器、看DMA、看USART，每个外设的寄存器几十个，配置起来稍不留神就是“现象不对但查不出原因”。更别提还要先搭建好一套完整的环境，再把工程的启动流程、时钟树、中断优先级理顺，等真正开始写业务逻辑的时候，热情已经消耗了一半。
最近大半年，我尝试把AI编程深度嵌入到STM32的实际开发流程里，走了不少弯路，也踩过不少坑。现在慢慢形成了一套相对顺手的运转模式，从需求拆解、方案选型、代码生成，到调试排错、测试验证，AI在每个环节都能发挥不同作用。这篇文章就把这套流程原原本本摊开来讲。
这套方法适合什么样的人？我觉得最适合两类：一类是刚接触STM32不久、正在为“从0到1”的项目搭建和基础外设初始化头疼的初学者，AI能把大量重复劳动接过去，让你把精力放在业务逻辑上；另一类是已经有几年开发经验、但想把手头重复性工作压缩的工程师，AI在你给出清晰约束后，生成的代码质量往往能省掉不少调试时间。
先说清楚，我并不是要主张“AI能完全替代单片机工程师”。恰恰相反，工程经验、硬件背景、调试直觉仍然是决定项目能不能做成、做好的核心壁垒。AI更像一个“读过一万份手册、帮你查资料、帮你写草稿、帮你盯逻辑”的结对搭档，但最终拍板的人，必须是你自己。
2. AI+STM32开发的整体思路与方案选型
2.1 为什么STM32特别适合“AI优先”的开发方式
STM32本身在嵌入式领域的使用率排在前列，芯片型号多、生态成熟、参考资料全，这反而让AI学习得“很充分”。你给AI出的题，只要是STM32范围内的，它几乎都能给出可参考的实现。这背后和AI大模型的训练数据高度相关——网上STM32相关的Demo、开源项目、论坛问答太多了，模型对常见问题早就“见多识广”。
另外一个重要原因是STM32的开发流程趋于标准化。无论用标准库、HAL库还是LL库，初始化代码的套路基本固定：开时钟、配GPIO、配外设、写中断、调逻辑。标准化的流程意味着AI生成代码的出错概率相对可控，因为你给它描述清楚需求，它大概率会按HAL库的固定套路生成一套可编译、可直接套用的模板代码。
如果你用的是ST官方推荐的STM32CubeMX配合HAL库，这套流程的“模板化”属性更强，AI生成代码时的准确性也更高。我个人的建议是，如果你准备用AI辅助写STM32代码，优先选择HAL库，而不是标准库。HAL库的函数抽象层级更高，AI更熟悉它的API命名习惯，生成结果往往更整齐。LL库虽然更精简，但要求你对底层机制更熟悉，AI出错后的排查成本会更高，反而不太适合作为AI辅助开发的主力库。
2.2 当前主流的AI编程工具在嵌入式场景下的分工
现在市面上的AI编程工具不少，各有侧重。从我实测的情况来看，它们不是“谁完全替代谁”的关系，而是各有分工。
对话型AI适合做技术方案咨询、代码审查和问题排查。你把报错信息、代码片段、现象描述丢给它，它能快速给出排查方向。比如你遇到一个USART接收不定长数据的场景，它可以给你画出几种常见思路，DMA+空闲中断、普通接收+超时判断、环形缓冲区等，每种方案的优缺点说得比较清楚。这种“给你多个选项”的价值在于，它帮你拓宽思路，而不是只给你一条路。
IDE内嵌的AI补全工具则适合在写代码过程中做“局部加速”。你写出函数名、参数列表，它能帮你补全函数体；你写一个注释描述意图，它能生成对应的代码块。这类工具最大的价值不是帮你写大段逻辑，而是减少“敲样板代码”的时间，让你思路不中断。
专用AI编程工具（如Claude、Copilot等）在做整个项目的代码生成时更有优势。你可以把整个文件甚至多个文件的上下文交给它，让它基于你的项目风格生成一整套外设驱动模块，这种“整体一致性”对嵌入式项目很重要，因为部分函数的接口命名、参数风格如果前后不统一，后期维护会非常痛苦。
2.3 开发流程的整体设计思路
把AI嵌进STM32开发流程，我建议不要“哪里不会问哪里”，而是先规划好AI在每个环节的介入方式。我当前的流程是这样一个闭环：
需求分析由我主导先把功能拆成模块，AI负责帮你补充边界条件和异常处理思路。方案设计阶段让AI提供备选架构和选型对比，人来做最终决策。编码实现阶段是AI最强的环节，你给出明确的功能描述、引脚分配、接口要求，AI生成初版代码，人来审查和调整。调试阶段把报错、日志、现象丢给AI排查，但最终确认还是靠逻辑分析和硬件测量。测试验证阶段让AI帮你生成边界测试用例和自测程序。
这套流程的关键在于“你掌控方向，AI负责执行”。最怕的是你把整个需求一口气丢给AI让它写完所有代码，然后直接烧录，这是灾难的开端。嵌入式软件里硬件状态、时序、外部中断这些都是AI看不到的实时约束，它生成代码时只能依赖你提供的信息，如果你描述得不够准确，它写出来的代码自然也是有偏差的。
3. 实操前的准备工作：环境搭建与工程创建要点
3.1 开发环境的一站式配置
STM32开发环境，现在主流的就是两个方向：STM32CubeMX生成初始化代码，外接IDE编译调试。
我推荐的环境组合是STM32CubeMX作为初始化工程生成工具，配合Keil MDK或者STM32CubeIDE作为开发和调试环境。这两套组合各有优势。如果你之前一直用Keil，换到STM32CubeIDE需要一点适应时间，但它毕竟是ST自家工具，调试信息更全，对CubeMX生成的HAL库代码兼容性最好，还不收费。Keil则胜在“大多数工程师习惯了”以及一些老工程师的惯性依赖，但商业授权费用不低。
环境配置方面有一个必做事项：确认芯片支持包安装好了。如果你用Keil MDK，芯片包是0.0分靠Keil.STM32F1xx_DFP这样的方式分型号安装，可以在Keil官网直接下载；CubeMX则是在软件内部检查更新即可。这个环节如果漏了，编程的时候会发现找不到芯片型号，编译的时候会报一堆莫名其妙找不到头文件的错误。
建议你实际动手的时候按这个顺序来：安装STM32CubeMX、安装MDK或CMake工具链、在CubeMX里选择芯片型号并配置引脚和时钟、生成初始化代码、在IDE里编译第一个空工程。这一套流程跑通，后面做任何功能都只是往这个骨架里填肉。
3.2 一个值得推荐的“AI辅助立项”实践方式
在动手写代码之前，有一个很有价值的AI用法容易被忽略——是让AI帮你把“抽象的需求”翻译成“硬件的功能描述”。
举个例子。你拿到一个需求：“做一个四路数据采集系统，用串口把数据发到电脑上。”这个描述对AI来说信息不够。你需要先用自然语言拆解清楚，比如：用什么传感器？信号是模拟量还是数字量？采样率多高？精度多少？数据协议是什么格式？串口波特率用多少？是主动上报还是查询响应？这些约束越明确，AI生成的代码越贴近真实需求。
我在实操中习惯先开一个对话窗口，把需求尽可能详细地告诉AI，让它先输出一份“需求问题清单”，帮我把遗漏的点补上。然后再让它基于这份清单生成一份“功能模块拆分表”和“引脚分配建议”。这个过程等于用AI做了一次“虚拟评审”，前期思考越充分，后期写代码越顺。
这里有个细节：引脚分配不是随便定的，哪怕逻辑上看AI分配的没问题，也一定要结合你的实际硬件原理图人工确认。我之前遇到过AI把两个功能分配到了同一个引脚上，编译没错，跑到那一步就死机，查了半小时才发现引脚冲突。所以我把“AI给的引脚表”只当作初稿，实际使用前必须对照板卡原理图过一遍。
3.3 指定AI采用统一的编码规范
嵌入式软件工程里，“编码风格一致性”是代码可维护性的重要保障。用AI写代码时如果不加约束，它生成的代码可能每次风格都不同——上次用的缩进和命名规则，这次可能就变了，甚至出现同一个项目里存在两套命名风格的情况。
对策很简单：在让AI生成代码之前，先给它一份项目约定。比如变量命名用哪种风格、函数名的动词前缀规则、宏定义的大小写规则、注释规范、错误处理方式等。你甚至可以写一份通用的“项目编码规范”文件，每次开启新会话时把这份文件附上，让AI按统一风格生成。
就我个人的习惯而言，函数命名用下划线分隔小写字母，例如uart_send_data；变量命名采用匈牙利前缀加驼峰，例如uint8_t rx_buffer[128]；寄存器操作宏统一全大写。这些规则看似琐碎，但对一个中大型固件工程来说，直接影响后期的团队协作和维护效率。AI一旦习惯了你给它的规则，生成代码的质量会稳定很多，这比每段代码都去人工“调教”要省时得多。
4. 核心开发流程分步拆解与实操要点
4.1 需求解析与任务拆解：AI帮你把“模糊想法”变成“可实现任务”
我拿一个最近做的实际项目举例：用STM32F103驱动一个温湿度传感器，数据在OLED屏上显示，同时通过Wi-Fi模块上报到MQTT服务器，手机端能看到实时数据。
这个项目看起来不复杂，但真正拆开来看，涉及的模块有传感器驱动、I2C/C单总线时序、OLED驱动、Wi-Fi模块AT指令解析、MQTT协议栈对接、低功耗策略、异常处理等，任务量远不像表面那么轻量。
我用AI辅助做任务拆解的方式是：把这个项目描述给AI，让它按功能模块拆分，每个模块再细分到具体的函数级任务，并标注优先级和依赖关系。AI给出的拆分结果一般比较合理，因为这类包含传感器、显示、通信模块的项目在开发社区中太常见了，AI见过的实例足够多。
不过注意，AI给出的拆解是基于“理想情况”的，它不了解供应链里你的传感器型号、OLED屏的驱动芯片、Wi-Fi模块固件版本等硬约束。所以我会把它生成的拆解作为模板，再结合手里实际拿到的硬件物料做调整。这个过程一般花不了多少时间，但能把项目从“脑子里的设想”落成“团队可执行的任务清单”。
4.2 初始化代码生成：让CubeMX和AI协作而不是二选一
很多初学者会纠结一个问题：CubeMX生成的代码要不要用？AI写的初始化代码行不行？
我的建议很明确：初始化代码用CubeMX生成，业务逻辑代码用AI辅助写，别把两者混为一谈。
为什么这么做？因为STM32的时钟树配置、引脚复用、中断优先级这些底层细节，CubeMX作为ST官方工具，天然能基于你选择的芯片型号生成最准确的配置。虽然AI也懂STM32的时钟配置，但它不懂你板子上的晶振频率、供电电压、引脚连接，即使你告诉它型号，它生成的配置也可能和你实际硬件不匹配。
实操时，我先在CubeMX里完成时钟树配置、引脚功能映射、外设参数设置，然后生成初始工程。在这个骨架基础上，再让AI编写各功能模块的具体实现代码。比如CubeMX帮你配好了USART2的引脚和参数，AI写的则是“如何处理接收到的数据”“如何解析自定义协议”这类逻辑代码。
这种分工还有一个好处：如果后续换了芯片型号或调整了引脚分配，只需要在CubeMX里改配置并重新生成代码，AI写的业务逻辑代码不受影响。把初始化配置和业务逻辑解耦，是整个项目架构稳健的基础。
4.3 驱动层代码：AI最擅长的领域，但仍需人工审查的关键环节
外围传感器的驱动代码有两个特点：一是重复度高——I2C读温湿度、SPI读陀螺仪、UART发指令，套路都类似；二是坑点多——芯片上电时序、寄存器配置顺序、等待时间、错误状态处理等，细节决定了成不成。
AI在这方面表现确实亮眼。特别是针对那些网上例程非常多的常用传感器，比如DHT11、DS18B20、MPU6050、SSD1306等，AI生成的驱动代码往往能直接使用——因为大量公开代码、手册数据参与了模型训练，它对这些模块是非常熟悉的。
我给你看一个实际使用AI写DS18B20驱动的案例。我先是让它生成基于HAL库的DS18B20驱动，它很快就给出了一套包含初始化、复位、写字节、读字节、温度转换的完整代码。第一版代码编译通过，但实际运行读数却全是0。我把输出结果告诉AI后，它分析说可能是复位时序的时间和延迟精度不够，建议用更大的延时值并加入忙等待逻辑。我按它的建议改了延时长，再跑，读数正常。
这个案例给我的启发是：AI生成的驱动代码大概率“方向正确，细节有瑕疵”。延时精度问题、GPIO内部上下拉问题、开漏输出配置问题，它都可能会忽略，因为这些问题和具体的硬件电气特性强相关，AI仅凭你口头描述很难准确判断。所以驱动代码必须经过“人工审查+硬件实测”双重验证，不能因为编译过了就放心。
4.4 应用逻辑代码：AI帮你提高效率，但不替你思考
应用逻辑是代码中最能体现工程师“内功”的部分——状态机设计、消息队列管理、内存分配策略、错误恢复机制等，这些直接决定固件的健壮性和可扩展性。
AI在这部分能做的，是帮你快速实现“常见的业务模式”。比如你要维护一个简单的按键状态机，要检测单击、双击、长按，这类需求在社区中有大量类似实现，AI生成的代码一般能覆盖基础功能。但如果你需要的是不常见的自定义协议解析、复杂的动态电源管理策略，AI的能力就会明显下降。
实操层面，我习惯在一个新的对话中把完整的逻辑需求写清楚，包括输入什么、输出什么、有哪些状态、各状态之间如何流转、异常情况如何处理，让AI逐段给出代码。它给出的代码我会先做一次逻辑走读，然后再放进工程里编译运行。
走读的时候重点关注三个点：第一是各状态之间是否所有路径都有明确的“出口”；第二是超时和异常分支是否都有处理，而不是只处理理想路径；第三是全局变量和局部变量的作用域是否合理，会不会出现跨模块的隐式耦合。
4.5 调试与问题排查：AI作为第二双眼睛
嵌入式调试的过程中，AI最有价值的使用方式，不是让它直接给代码，而是陪着你做“逻辑分析”。
比如程序跑飞了，用调试器看程序计数器停在某个中断服务函数里，你不太确定这个中断是不是真的被触发过。这时候你可以把对应的中断服务函数代码、外设配置代码、当前变量值截图一并发给AI，问它“这个场景下还会有什么原因导致单片机进入该中断？”AI会基于上下文给你列出一系列可能性，有些点是你在紧张调试时很容易忽略的，比如某个引脚悬空造成电平抖动、某个外设没有正确关闭造成了意外中断请求等。
另一个常用技巧是让AI帮你分析日志。你可以把串口打印的日志复制给AI，让它根据已有的代码逻辑推测程序执行到了哪一步、哪个变量出现了异常。这在处理一些只在长时间运行后才出现的“偶发问题”时特别有用——人工盯着日志看半小时，不如让AI先把日志里的关键模式抓出来。
当然，嵌入式调试有一个绝对不能省略的环节——用示波器、逻辑分析仪、万用表去验证信号。AI能从代码层面帮你缩小问题范围，但不知道你板上某个引脚的实际电压波形。信号完整性、电气连接、电源纹波这些问题，AI永远帮不上忙，只有仪器能告诉你真相。
4.6 代码审查与重构：让AI当你的“代码评审员”
写完初版代码后，代码审查环节同样可以借助AI。
我经常做的操作是：把写完的一个C文件发给AI，告诉它“帮我做一次代码审查，重点看一下潜在的bug、内存泄漏风险、异常处理缺失、以及可读性问题”。AI会返回一份逐条列出的审查意见，其中有不少确实是值得修改的。
比较典型的审查发现包括：数组越界风险——比如接收缓冲区的大小定义是256字节，但某个拷贝操作的长度是动态计算得到的，AI能提醒你加边界检查；中断与主循环共享变量的风险——如果你在中断中修改了一个全局变量，主循环也在读它，AI会建议加volatile修饰或者使用临界区；错误处理缺失——比如某个API函数返回值没有检查，AI会建议补充错误处理分支。
当然，AI做代码审查也有局限。它对硬件相关问题的敏感度不够，比如某个引脚在进入低功耗模式前没有正确配置为模拟输入，可能导致漏电流变大，这类硬件语义相关的问题，AI很难发现。所以AI的审查意见可以作为重要的参考，但最终的硬件相关符合性，仍然需要人来把关。
5. 几个典型注意事项与实操心得
5.1 关于AI生成代码的“信任级别”
使用AI辅助编程这么久，我总结了一套“信任级别”参考标准：
- 初始化代码：低风险，信任度可放高一点，但需以CubeMX生成的代码为准，AI生成的初始化代码偶尔会有参数不匹配的情况。
- 通用算法代码（如PID、CRC、状态机模板）：中风险，AI生成质量普遍较高，但仍建议自测一遍，特别注意边界条件。
- 外设驱动代码：中高风险，尤其是涉及精确时序的单总线、低速通信，需要结合硬件实测验证。
- 与外部硬件耦合紧密的逻辑代码（如指定的外设芯片特定寄存器配置）：高风险，必须逐行审查，必要时对照数据手册核对。
这套标准的核心其实就是“风险意识”。越靠近硬件底层，AI越不可靠；越靠近纯逻辑抽象，AI越可靠。这个规律在我大量实践之后越来越清晰。
5.2 给AI的提示词技巧和常见“翻车”纠正
用AI写STM32代码时，提示词的质量直接决定输出的质量。我从实践中总结了几个非常实用的提示词编写建议：
第一，项目背景要交代清楚。不要说“帮我写一个串口发送函数”，而是说“在STM32F407上，使用HAL库的USART2，以中断模式发送数据，长度不超过128字节，请提供初始化配置和发送函数”。信息越具体，AI生成的代码越贴近你的场景。
第二，边界条件要写明确。比如“接收缓冲区的最大长度是多少”“如果接收的数据超过缓冲区大小，应该怎么处理”“如果传输超时，返回值应该是什么”。AI如果缺乏这些约束，倾向于写出“理想化”的代码，而嵌入式恰恰不允许“理想化”。
第三，一次让AI完成的任务粒度要适中。你让它“写整个项目”和“写一个UART驱动”是两个极端，前者AI会“偷懒”——生成结构但每个模块都很粗糙；后者AI会做得很好——专注解决问题。我的经验是把任务拆到“一个功能模块”“一个文件”这个粒度，AI的输出质量最稳定。
5.3 AI辅助开发流程中的常见误区
有人觉得“AI编程 = 程序员失业”，也有人觉得“AI编程 = 我什么都不用会”。这两种认知都偏离了实际。
在我实践下来，AI在嵌入式开发中的定位，最贴切的是“效率提升者”而非“替代者”。它让一个熟悉嵌入式开发的工程师如虎添翼，但让一个完全不懂硬件的人从零去用AI开发STM32项目，大概率会卡在“AI生成的代码烧录后没反应，完全不知道哪里出了问题”这一步。
所以我的观念是：AI编程不会降低嵌入式开发的门槛，它降低的是“经验门槛”。以前你需要积累几年才能见过的各种坑，现在AI能帮你快速识别并避开大部分；但当你遇到的问题超出了AI的知识边界，或者问题出在物理世界的电气特性上，真正能依赖的还是你自己的底层能力和调试经验。
另外一个常见误区是把AI当成搜索引擎。搜索引擎给你的是“别人遇到问题的解决方案”，AI给你的是“基于语义推导的合成答案”。这意味AI可能会很自信地告诉你一个从来没真实存在过的API函数或库接口，但如果你不去确认，它会在编译时报错时狠狠扇你一耳光。所以对AI给出的内容，始终保持审慎和验证的习惯，这个态度是玩好AI编程的第一课。
6. 一个完整的实战过程：从需求到联调的全流程演示
6.1 项目目标与AI辅助拆分
我把之前提到过的温湿度+OLED+MQTT上报项目拿出来，完完整整梳理一遍实战流程。
目标是做一个低功耗环境监测节点，用STM32L071芯片——低功耗是选择这颗芯片的原因。硬件上接了SHT30温湿度传感器（I2C接口）、SSD1306的OLED显示屏（I2C接口）、以及一个ESP-01S WiFi模块（USART接口）。采集频率是每30秒一次，通过WiFi模块以MQTT协议上报到本地服务器，OLED显示当前温湿度和设备状态。
拿到需求后，我先让AI基于这个描述生成一份“功能拆分表和硬件资源分配建议”。AI给出的建议把项目拆成了六个模块：I2C驱动、SHT30传感器驱动、OLED显示驱动、USART驱动、ESP-01S AT指令管理、MQTT数据上报逻辑。引脚分配上，AI建议把I2C使用I2C1（PB6/PB7），USART1用于调试（PA9/PA10），USART2用于ESP-01S通信（PA2/PA3）。
我拿到这个分配表后，第一件事是打开原理图核对，确认目标芯片这些引脚没有被其他功能占用。核对了引脚后，发现还需要一个状态指示灯，于是把LED分到了PB1，并确认这个引脚在板子上确实引出来了一个可控亮灭的发光二极管。
6.2 CubeMX生成骨架与AI业务逻辑实现
确定了资源分配后，打开CubeMX，完成以下配置：
- 选择芯片型号STM32L071RBT6
- 在Pinout视图里依次把PB6、PB7设为I2C1的SCL和SDA
- 把PA2、PA3设为USART2的TX和RX，模式选择异步通信，波特率115200
- 把PA9、PA10设为USART1的TX和RX，用于调试输出，同样设成115200
- 把PB1设为GPIO输出，初始电平为低，用于控制LED
- 时钟树选择内部HSI作为系统时钟源，在不使用外部晶振的情况下把系统主频配置到16MHz
- 生成项目，选择MDK-ARM工具链
生成完骨架代码后，我把项目打开确认一下基础编译能通过，然后开始让AI补充各处逻辑。
传感器驱动方面，我让AI基于SHT30芯片资料生成I2C驱动代码。它给出的函数包含：初始化、发送测量命令、读取温湿度数据、CRC校验、异常返回。我把这部分代码放在bme_sht30.c中，并做了一层薄薄的封装，方便上层业务调用。
OLED驱动部分，因为SSD1306是一个非常常见的驱动芯片，AI对它非常熟悉，生成的绘制函数能直接支持显示字符串、数字、简单的进度条效果。
最关键的MQTT上报逻辑，我给了AI明确的报文格式要求，让它生成封包和解析代码。MQTT本身的报文格式是公定的，AI生成的封包函数能正确地拼接固定头、可变头和负载，但在处理“遗嘱消息”和“保留标志”时，它第一版确实有细节问题。我把MQTT协议文档中关于报文格式的章节发给它后，它快速修正了错误。
6.3 联调阶段踩过的坑与排查
整个项目联调过程中，我记录了三个比较典型的坑，这里分享出来供参考。
第一个坑是I2C通信偶发失败。SHT30时不时读取失败，用示波器看波形发现SCL线上有毛刺。排查思路是把I2C速率从400kHz降到100kHz，同时在单片机内部把I2C引脚的上拉电阻使能，毛刺消失。这个问题的本质是硬件设计上外部上拉电阻值偏大，导致上升沿过慢，抗干扰能力下降。这类问题AI很难直接从代码层面定位，必须靠硬件测量辅助判断。
第二个坑是ESP-01S的AT指令返回不稳定。WiFi模块在发送数据时，如果上一次指令的返回值还没读取完就发下一条指令，会出现指令“堆积”导致的响应错乱。AI给的AT指令管理代码很规范，使用了状态机模型来串行处理每条指令，但我在实际使用时发现如果串口接收缓冲区不够大，当模块一次返回了很长的异步事件消息时，缓冲区会被截断，导致状态机卡死。我的解决方式是加大缓冲区到512字节，并增加了指针偏移续读的逻辑。细节修正后，整个通信流程稳定了很多。
第三个坑是低功耗模式下串口唤醒。STM32L071进入停止模式后，UART2配置了外部中断唤醒功能，但初始化顺序如果不对，唤醒后会死机。AI第一版生成的代码把串口初始化和外部中断初始化放到了停止逻辑的后面，导致唤醒后串口状态不对。我把报错现象反馈给AI，它指出可能是唤醒后需要重新初始化外设，我按它的建议修改后，问题解决。
6.4 项目的最终验证与交付
联调完成后的最终验证阶段，我让AI生成了一份自测检查表，里面包含：
- SHT30读取连续100次成功率是否达到100%
- OLED显示内容与温湿度数据是否一致
- MQTT上报的JSON格式是否与服务器端解析代码匹配
- 设备运行24小时后，测量静态功耗是否在低功耗预期范围内
- 模拟WiFi断开、传感器无响应时，设备是否能正确进入异常处理流程而不死机
这些测试用例我逐项执行，记录结果，最终全部通过才把固件定位为可交付版本。这个过程印证了我开头说的观点——AI辅助编程的价值在于让整个流程提速，但最终的测试、验证、确认仍然需要人工完成。而这套验证流程本身，恰恰是嵌入式开发里最容易被新手省略、却最不该省略的部分。
