嵌入式软件开发和AI编程这两个词放在一起很多人第一反应是让AI帮我写驱动代码或者用Copilot补全寄存器配置。但真正做过几个协同项目之后你会发现AI在嵌入式开发里最能发挥价值的地方往往不是替你写代码而是帮你做那些你明知道该做但一直没时间做的脏活——比如整理寄存器映射表、比对两份数据手册的差异、把散落在注释里的硬件约束提取成结构化文档。这一篇接着上一回的进度聊聊我在第一个AI协同开发项目里踩过的具体坑以及后来怎么调整协作方式的。1. 为什么第一个AI协同项目容易做成AI写代码我复制1.1 初始设想的偏差我最初启动这个项目的想法很朴素手头有一块基于Cortex-M4的板子需要把一套传感器采集逻辑从裸机迁移到RTOS上顺便把原来写得比较随意的状态机重构一下。既然现在AI编程工具这么成熟那不如让AI直接生成大部分代码我来做review和调试。这个设想在第一个下午就被现实打脸了。AI生成的RTOS任务框架看起来结构完整但里面有几个致命问题任务优先级设置和实际中断优先级冲突、队列深度没有考虑最坏情况下的突发数据量、还有一个信号量的初始计数值给错了。这些问题不是语法错误编译器不会报但跑起来就是会偶发死锁。我后来复盘根本原因在于嵌入式开发的约束条件大部分不在代码里而在代码之外。芯片手册的时序要求、硬件的电气特性、中断响应的实时性预算这些东西AI看不到我也没在prompt里说清楚。AI只能基于通用RTOS编程最佳实践来生成而通用最佳实践在具体硬件上经常是错的。1.2 协同模式的实际转变意识到这个问题之后我把协作方式调了个方向。不再让AI从零生成模块而是改成三种具体模式模式一约束提取。我把数据手册的相关章节贴给AI让它提取出所有和软件相关的时序参数、寄存器位定义、状态转换条件输出成结构化表格。这个工作我自己做要花两三个小时AI几分钟就能给出初稿我只需要核对。模式二代码审查。我写核心逻辑AI做review重点让它检查资源竞争、边界条件、错误处理路径。它查不出硬件相关的问题但纯软件逻辑的漏洞查得比我仔细。模式三文档生成。把代码里的状态机、任务间通信关系整理成文档这个AI做得又快又好而且格式统一。这三种模式跑下来效率提升比AI写代码明显得多而且出问题的概率大幅下降。1.3 一个具体的对比数据拿传感器数据采集任务来说两种方式的对比大概是这样的对比项AI直接生成代码约束提取人工编码AI审查初版完成时间约40分钟约2.5小时编译通过率高高首次上板运行成功率低需反复调试较高调试到稳定耗时约6小时约1.5小时总耗时约7小时约4小时代码可维护性一般注释与实际不符较好约束有文档支撑这个数据不是说AI生成代码不行而是说在嵌入式场景下前期多花时间把约束喂给AI后期调试时间会成倍省回来。这个账我算了不止一次每次都是同样的结论。2. 约束提取这一步具体怎么做才不白费功夫2.1 喂给AI的资料要经过筛选数据手册动辄几百页全贴进去不现实AI的上下文窗口也吃不消。我的做法是先定位到和当前模块相关的章节通常包括外设的寄存器描述、时序图对应的参数表、中断向量表、时钟树配置说明。把这些章节单独截出来一般控制在20页以内。这里有个细节时序图一定要转成文字描述再喂。AI对图片里的时序图理解能力有限但对tSU ≥ 5nstH ≥ 3nsCS拉低到第一个时钟沿至少等待2个周期这种文字描述理解得很准。我一般会自己先把关键时序参数抄成文字再让AI整理。2.2 让AI输出的格式要固定如果每次让AI自由发挥输出格式都不一样后续没法用。我固定了一套输出模板每次都在prompt里明确要求请按以下格式输出 1. 寄存器名称 | 地址偏移 | 位域 | 功能 | 复位值 | 访问权限 2. 时序参数名称 | 最小值 | 典型值 | 最大值 | 单位 | 条件 3. 状态机状态 | 进入条件 | 退出条件 | 可执行操作这样输出的表格可以直接贴进项目文档也可以直接转成代码里的宏定义或枚举。我甚至写了个小脚本把AI输出的表格转成C语言的头文件省去了手工录入的环节。2.3 核对环节不能省AI提取的约束我至少会核对三类内容地址偏移是否和手册一致、位域的起止位是否搞反、时序参数的单位是否弄错。这三类错误我全遇到过。特别是位域AI有时候会把bit 7:4理解成第7位到第4位正确还是第4位到第7位错误不同表述下它理解不一样。核对的方法很简单挑几个关键寄存器手工对照手册检查一遍。如果这几个都对剩下的通常问题不大。如果发现一个错那整批都要重新核对。提示AI提取的寄存器信息建议在代码里用静态断言static_assert做一次编译期校验比如寄存器结构体的大小是否和手册一致。这样即使提取有误编译阶段就能发现。3. AI代码审查在嵌入式场景下能查出什么、查不出什么3.1 查得出的问题类型跑了一段时间之后我总结出AI代码审查在嵌入式场景下比较擅长的几类问题资源竞争多个任务访问共享变量没有加保护、中断和任务之间共享数据没有用临界区、信号量和互斥量的使用场景搞混。边界条件数组越界、缓冲区满/空时的处理、计数器溢出、状态机没有处理非法输入。错误处理路径函数返回值没检查、错误分支里资源没释放、异常情况下任务卡死。初始化顺序外设初始化依赖关系搞错、时钟没使能就配置外设、中断没配置就使能。这些问题有个共同点都是纯软件逻辑层面的不依赖具体硬件知识。AI在这方面的审查能力确实比我强因为它不会疲劳不会因为这段代码是我写的而手下留情。3.2 查不出的问题类型反过来以下几类问题AI基本查不出来或者说查出来也不可信硬件时序违规比如某个操作需要等待至少N个时钟周期代码里没等。AI不知道这个N是多少。电气特性相关比如上拉电阻配置、驱动能力设置、引脚复用冲突。这些信息不在代码里。实时性预算某个中断服务函数执行时间是否超过预算、任务切换延迟是否满足要求。AI没有时间概念。芯片特定的坑某些芯片的某个外设有勘误表errata需要特定规避措施。AI的训练数据里可能没有这些冷门信息。所以我的做法是AI审查纯逻辑硬件相关的问题我自己过一遍检查清单。这个检查清单是根据具体芯片和板子整理的每次项目开始前更新一次。3.3 审查prompt的写法让AI做代码审查prompt的写法很关键。我试过几种最后固定成这个结构背景这是运行在Cortex-M4上的FreeRTOS任务代码系统主频168MHz 有一个1kHz的定时器中断一个UART接收中断波特率115200 两个任务通过队列通信。 请审查以下代码重点关注 1. 任务间共享数据的保护 2. 中断和任务之间的数据传递 3. 队列操作失败时的处理 4. 可能的死锁场景 不要关注硬件寄存器配置、具体外设时序。把背景和关注点说清楚AI的审查质量会高很多。如果不给背景它容易泛泛而谈说一些建议增加错误处理之类的废话。4. 文档生成这个环节被严重低估了4.1 嵌入式项目的文档欠债做嵌入式的人大概都有这个体会代码写得再烂只要能跑就行文档嘛等有空再补。结果就是项目做完除了代码本身什么文档都没有。过三个月自己都忘了当时为什么这么设计。AI在文档生成这块的价值我觉得比写代码还大。因为写文档是典型的重要但不紧急的事人总是往后拖而AI不会拖你让它写它马上就写。4.2 我实际生成的几类文档在这个项目里我用AI生成了这几类文档任务关系图把每个RTOS任务的功能、优先级、栈大小、使用的IPC机制整理成表格。这个表格在调试优先级反转问题时特别有用。状态机说明把代码里的状态机提取出来列出所有状态、转换条件、每个状态下执行的动作。AI能从switch-case代码里准确提取这些信息。中断处理清单列出所有中断源、优先级、服务函数、执行时间估算、和任务的交互方式。这个清单在排查偶发问题时是必备的。寄存器配置说明把初始化代码里的寄存器配置反向整理成配置了什么、为什么这么配的说明。这个对后续维护帮助很大。4.3 生成文档的prompt技巧让AI生成文档关键是给它足够的上下文。我一般会把相关代码文件一起贴进去然后明确要求输出格式。比如生成任务关系表以下是FreeRTOS的初始化和任务创建代码请提取所有任务的信息 输出成Markdown表格列包括任务名、优先级、栈大小、功能描述、 使用的队列/信号量、与其他任务的交互关系。 [贴代码]生成出来的表格我核对一遍改掉个别描述不准的地方直接就能放进项目文档。整个过程十分钟以内比自己从头写快太多了。5. 协同流程跑顺之后的一些经验5.1 把AI当成一个需要明确指令的初级工程师这个比喻我觉得很贴切。AI的能力很强但它不知道你的项目背景、硬件约束、团队规范。你给它的信息越具体它的输出越有用。你指望它猜你的意图结果通常不理想。所以我现在养成了一个习惯每次让AI做一件事之前先花两分钟想清楚我需要它输出什么格式、基于什么背景、关注什么重点然后把这些写进prompt。这两分钟的投入能省掉后面大量的返工。5.2 建立自己的prompt模板库项目做多了之后常用的prompt可以固化下来。我目前积累了这么几类模板约束提取、代码审查、文档生成、代码重构、问题排查。每类模板里都包含了固定的背景描述和输出格式要求用的时候只需要替换具体内容。这个模板库的价值在于保证输出质量的下限。即使某次prompt写得不够细致有模板兜底输出也不会太离谱。5.3 版本管理要跟上AI参与开发之后代码和文档的变更频率都提高了。这时候版本管理就很重要。我的做法是每次AI生成的代码或文档先提交到一个单独的分支人工核对修改后再合并到主分支。这样既能追溯哪些内容是AI生成的也方便出问题时回退。另外prompt本身也值得版本管理。同一个任务不同版本的prompt输出质量可能差很多。把好用的prompt存下来下次直接复用比重新想要快得多。5.4 不要指望AI解决最后一公里的问题嵌入式开发最耗时的往往是最后那点调试偶发的通信错误、特定条件下的死机、时序上的临界问题。这些问题AI基本帮不上忙因为它看不到示波器波形也没法在线调试。这部分工作还是得靠人靠逻辑分析仪、靠调试器、靠经验。我的心态是AI负责把项目从0推到80%剩下的20%我自己来。这20%才是嵌入式工程师真正的价值所在也是AI短期内替代不了的。6. 这个项目后续可以怎么扩展第一个协同项目跑通之后我开始想怎么把这套方法用到更复杂的场景里。目前有几个方向在尝试一是多芯片平台的约束库建设。把常用芯片的寄存器信息、时序参数、勘误表整理成结构化数据让AI基于这些数据做代码生成和审查。这样AI的输出就能带上具体芯片的约束而不是泛泛的通用建议。二是自动化测试用例生成。让AI根据状态机说明和接口定义生成单元测试用例覆盖各种边界条件。这个在纯软件逻辑部分效果不错硬件相关的部分还需要配合硬件在环测试。三是代码和文档的同步更新。代码改了之后让AI自动更新对应的文档保持两者一致。这个目前还在摸索主要是怎么让AI准确识别哪些文档需要更新。这些方向都还在早期阶段等有比较成熟的结果了再单独写一篇聊聊。眼下这个项目给我的最大收获不是学会了用某个AI工具而是想清楚了在嵌入式开发这个领域人和AI各自擅长什么、怎么配合效率最高。这个认知比任何具体工具都重要因为工具会变但这个配合的逻辑短期内不会变。