嵌入式软件开发和AI编程这两个领域单独拎出来都不算新鲜但把它们捏在一起做协同开发真正跑通一个完整项目的人其实并不多。我接触过不少做MCU固件、RTOS驱动、BSP移植的工程师大家用AI辅助编程的姿势差别很大——有人只拿它当高级搜索引擎有人用它生成整段HAL初始化代码还有人干脆让AI从需求文档直接吐出一个可编译的工程骨架。这几种用法我都试过踩过的坑也不少。这篇内容围绕第一个AI协同开发项目的第三部分展开重点聊的是当项目从能跑进入要交付阶段时AI协同开发到底该怎么组织、怎么验证、怎么收尾。如果你正在做嵌入式方向的工作或者想搞清楚AI编程在资源受限环境里到底能帮上多少忙接下来的内容应该对你有用。我会把工具选型、提示词设计、代码审查、硬件联调、回归验证这几个环节拆开讲尽量把每一步背后的判断逻辑说清楚而不是只丢一堆结论。1. 从能编译到能交付之间隔着什么很多人对AI协同开发的期待停留在帮我写个驱动这个层面但真正做过完整项目的人知道代码能编译通过只是万里长征第一步。嵌入式项目的交付标准比纯软件苛刻得多它要在真实的板子上跑起来要在中断和主循环之间保持时序正确要在有限的RAM和Flash里不越界还要在断电重启、外设异常、通信丢包这些边界条件下不崩。AI生成的代码往往在语法和逻辑层面看起来没问题但一旦落到具体硬件上问题就会集中暴露。1.1 为什么AI生成的嵌入式代码容易看起来对这里要先说清楚一个底层原因。大语言模型在生成代码时本质是在做概率预测它见过大量开源项目和教程代码所以能写出结构规整、命名规范、注释齐全的函数。但嵌入式代码有一个特点它的正确性高度依赖具体的硬件手册、时钟树配置、寄存器位定义和外设时序。这些信息在训练数据里往往是碎片化的、版本混杂的模型很难精确记住某一颗具体芯片在某个主频下的分频系数。我举个实际例子。之前让AI生成一段STM32的UART初始化代码它给出的波特率寄存器值是基于72MHz主频算的但我手上的板子实际跑在64MHz。代码编译没问题烧进去串口就是乱码。这种错误AI自己是发现不了的因为它不知道你的实际时钟配置。类似的还有SPI的CPOL/CPHA极性、I2C的上拉电阻阻值、ADC的采样时间设置这些参数一旦和硬件不匹配表现就是功能时好时坏或者完全没反应。所以第一个认知必须建立AI负责的是代码结构和逻辑框架硬件相关的具体参数必须由人来核对和填充。把AI当成一个写代码很快但不懂你手上这块板子的实习生这个定位最准确。1.2 交付阶段真正要盯住的四类问题在项目从开发转向交付的过程中我习惯把问题分成四类来盯这个分类方式对AI协同开发特别有用因为它能帮你判断哪些环节可以让AI多承担哪些必须人工介入。问题类型典型表现AI可承担程度人工必须介入的点语法与结构编译报错、头文件缺失高基本可自动修复确认修复未引入新依赖逻辑正确性状态机跳转错误、边界漏判中需明确描述需求审查分支覆盖和异常路径硬件适配寄存器值错误、时序不符低模型缺硬件上下文对照手册逐项核对资源占用RAM溢出、栈溢出、Flash超限中可辅助分析实测map文件确认这张表我建议每个做AI协同开发的人都存一份。它的价值在于当你拿到AI生成的一大段代码时能快速判断这段代码的风险等级。语法结构类的问题放心交给AI迭代硬件适配类的问题必须自己上手逻辑和资源类的问题则需要AI辅助加人工确认。1.3 本阶段项目的实际状态盘点回到这个第一个AI协同开发项目的第三部分此时项目通常已经过了原型验证功能基本跑通但离交付还有距离。具体来说这个阶段一般要处理的事情包括把AI生成的零散函数整合成模块化的驱动层、补充错误处理和异常恢复逻辑、做资源占用的实测和优化、编写可复现的测试用例、整理接口文档。这些事情里模块化整合和文档整理AI能帮大忙错误处理和资源优化则需要人来主导。我自己的做法是先让AI把现有代码按功能重新组织一遍生成模块划分建议然后我根据实际硬件资源情况调整。这个过程里AI最大的价值不是写新代码而是帮你把散落各处的代码理出一个结构相当于一个不知疲倦的重构助手。2. 提示词怎么写才能让AI产出可用的嵌入式代码提示词这件事网上讲的人很多但大部分讲的是通用场景。嵌入式有它的特殊性你需要让AI知道芯片型号、编译器、RTOS、外设配置这些上下文否则它给的东西就是通用但不可用。我在这个项目里摸索出一套提示词结构实测下来能显著提高一次通过率。2.1 嵌入式提示词的四个必备要素一个能让AI产出可用嵌入式代码的提示词至少要包含四个要素目标平台、功能需求、约束条件、输出格式。缺了任何一个产出质量都会明显下降。目标平台要具体到芯片系列和开发环境。比如STM32F407使用STM32CubeIDEHAL库版本1.27就比STM32有用得多。功能需求要描述清楚输入输出和触发条件比如按键按下后通过UART发送一帧数据帧格式为...。约束条件包括RAM限制、实时性要求、是否允许阻塞等。输出格式则决定AI给你的是完整文件还是函数片段。我常用的提示词模板大概是这样平台STM32F407ZGT6主频168MHz使用HAL库FreeRTOS 需求实现一个Modbus RTU从机支持功能码03和06 约束 - 串口波特率96008N1 - 接收使用中断空闲检测不用DMA - 寄存器区大小不超过256字节 - 响应时间要求小于10ms 输出给出完整的.c和.h文件包含初始化函数和任务函数这个模板的关键在于把约束写清楚。很多人写提示词只写需求不写约束结果AI给一个用DMA加双缓冲的复杂方案功能是对的但和你现有的代码架构完全不兼容改起来比自己写还累。2.2 让AI先出接口再出实现这是我踩过坑之后总结出来的一个技巧。直接让AI写完整实现它容易在细节上跑偏而且一旦方向错了整段代码都要重来。更好的做法是分两步先让AI输出接口定义你确认接口合理之后再让它填充实现。接口定义包括函数签名、数据结构、错误码。这一步AI做得很快你审查起来也快。比如让它设计一个环形缓冲区先看它给的接口typedef struct { uint8_t *buffer; uint16_t size; volatile uint16_t head; volatile uint16_t tail; } ringbuf_t; int ringbuf_init(ringbuf_t *rb, uint8_t *mem, uint16_t size); int ringbuf_put(ringbuf_t *rb, uint8_t data); int ringbuf_get(ringbuf_t *rb, uint8_t *data); uint16_t ringbuf_count(const ringbuf_t *rb);看到这个接口我立刻能判断出几个问题head和tail用了volatile说明考虑了中断场景但没有提供线程安全的批量读写接口count函数在中断里调用可能有竞态。这些判断在接口阶段就能做比等实现写完再改省事得多。2.3 提示词里必须明确的不要做什么这一点特别重要但很多人会忽略。AI有过度设计的倾向你让它写个简单的LED闪烁它可能给你整出一个带状态机、支持呼吸灯、可配置闪烁模式的大模块。在嵌入式环境里过度设计意味着浪费Flash和RAM还增加维护成本。所以提示词里要明确写不要做什么。比如不要使用动态内存分配、不要引入额外的第三方库、不要使用递归、中断服务函数内不要调用阻塞API。这些约束能有效收敛AI的输出范围。我整理了一份常用的负面约束清单基本每个嵌入式项目的提示词里都会带上几条不使用malloc/free所有内存静态分配中断服务函数保持简短不调用printf等重函数不使用浮点运算无FPU的芯片不依赖编译器特定扩展全局变量加static限制作用域2.4 迭代式对话比一次性长提示更有效我一开始也喜欢写超长的提示词想把所有要求一次说清楚。但实际用下来迭代式对话效果更好。原因是AI在长上下文里容易丢失中间信息而且一次性给太多约束它可能顾此失彼。更好的节奏是第一轮给平台和核心需求拿到框架第二轮针对具体函数提优化要求第三轮处理边界条件和错误处理。每一轮都基于上一轮的产出这样AI的注意力始终集中在当前要解决的问题上。比如做UART接收第一轮先让它给出中断接收的基本框架第二轮再要求加空闲检测和帧解析第三轮补充校验失败和超时的处理。这样一步步来每步都能审查出问题也容易定位。3. AI生成代码的审查重点与实测验证方法代码审查这个环节在AI协同开发里比传统开发更重要因为AI生成的代码有一种迷惑性——它写得很规范注释很全看起来特别专业但可能藏着一些隐蔽的问题。我在这部分项目里形成了一套审查流程重点盯几个高风险区域。3.1 中断相关的代码必须逐行看中断是嵌入式里最容易出问题的地方也是AI最容易写错的地方。常见的问题包括中断服务函数里调用了不可重入函数、共享变量没有加volatile、临界区保护缺失、中断优先级配置冲突。我审查中断代码时有个固定动作把所有在中断和主循环之间共享的变量列出来逐个确认是否有volatile修饰是否在访问时做了临界区保护。AI经常忘记加volatile因为它不理解编译器优化和硬件异步修改之间的关系。还有一个隐蔽的坑是中断标志清除的时机。有些AI生成的代码在中断服务函数开头就清标志有些在结尾清这两种写法在不同芯片上的行为可能不一样。这个必须对照具体芯片的手册确认不能想当然。3.2 用静态分析工具做第一道过滤人工审查之前先跑一遍静态分析工具能省很多事。我用得比较多的是编译器自带的警告开-Wall -Wextra、cppcheck、还有芯片厂商提供的配置检查工具。这些工具能抓出未初始化变量、数组越界、类型不匹配这类问题。AI生成的代码在静态分析下经常暴露的问题有几类变量声明了没用、隐式类型转换、switch语句缺少default分支、函数声明和定义参数不一致。这些问题人工看容易漏工具一扫就出来。我一般会把这些工具的检查集成到构建流程里每次AI生成新代码编译时自动跑一遍。这样问题在早期就暴露不会积累到联调阶段。3.3 硬件联调时的分步验证策略代码审查通过不代表硬件上就能跑。我的做法是把功能拆成最小的可验证单元一个一个上板测试。比如一个通信模块先验证初始化是否成功读芯片ID再验证发送是否正常示波器看波形再验证接收是否正常回环测试最后验证协议解析。这个分步策略在AI协同开发里特别重要因为AI生成的代码往往是整体正确但局部有错。如果一上来就测完整功能出了问题很难定位是哪个环节的错。分步验证能把问题范围缩小到单个函数甚至单行代码。实测中我遇到过一个典型情况AI生成的SPI驱动单独测试读写寄存器都正常但一加上DMA传输就出错。分步验证让我很快定位到是DMA配置里的数据宽度设置和SPI的数据帧格式不匹配。如果直接测完整功能这个bug可能要查很久。3.4 建立可复现的回归测试集项目进入交付阶段回归测试就变得关键。每次修改代码都要确认没有破坏已有功能。AI协同开发里代码改动频繁回归测试能帮你守住底线。我的做法是维护一个测试用例集每个用例对应一个功能点用脚本自动跑。嵌入式环境里做自动化测试比纯软件麻烦但也不是做不到。串口命令、GPIO翻转、ADC采样这些都可以通过脚本控制。关键是测试用例要能自动判断通过与否而不是靠人眼看。对于AI生成的代码我还会额外加一类测试边界值测试。因为AI对边界条件的处理经常不到位比如缓冲区满、计数溢出、超时归零这些情况。专门针对边界写测试用例能抓出不少隐藏问题。4. 资源受限环境下的优化与取舍嵌入式项目绕不开资源问题。Flash和RAM就那么大AI生成的代码如果不加控制很容易超标。这部分我讲讲在资源受限环境下怎么和AI配合做优化。4.1 先测量再优化别凭感觉优化的第一步永远是测量。我见过太多人凭感觉优化结果改了半天占用的资源没降多少代码可读性还变差了。正确的做法是先看map文件搞清楚Flash和RAM到底被谁占了。map文件里重点看几个东西各个目标文件的大小、栈和堆的分配、最大的几个函数。AI可以帮你分析map文件把占用大的模块列出来。有了这个数据优化才有方向。我一般会关注这几个指标代码段大小、只读数据段大小、已初始化数据段大小、未初始化数据段大小、栈使用峰值。栈使用峰值这个尤其重要AI生成的代码如果有深层调用或者大局部数组很容易栈溢出而且这种问题往往在运行时才暴露很难查。4.2 让AI做优化建议人来拍板测量出问题之后可以让AI给优化建议。AI在这方面的价值是能快速给出多种方案比如把查表改成计算、把浮点改成定点、把大数组改成压缩存储。但具体选哪个方案要人来判断因为涉及精度、可读性、维护成本的权衡。举个例子一个三角函数计算AI可能给出三种方案查表法、泰勒展开、CORDIC算法。查表法快但占Flash泰勒展开精度可控但慢CORDIC适合无FPU的芯片但代码复杂。选哪个取决于你的具体约束。这种决策AI做不了它不知道你的项目更看重什么。4.3 常见的资源优化手段及适用场景我把常用的优化手段整理成一张表方便对照使用。这些手段AI都能帮你实现但用不用、用哪个需要你根据实际情况判断。优化手段节省的资源代价适用场景查表代替计算CPU时间Flash空间计算密集且输入范围有限定点代替浮点CPU时间、代码量精度无FPU的芯片位域压缩存储RAM空间访问速度大量布尔标志函数内联调用开销代码量短小频繁调用的函数常量放FlashRAM空间访问速度大块只读数据动态内存改静态确定性灵活性实时性要求高的场景这张表里的每一行背后都有具体的取舍逻辑。比如常量放Flash这一条在有些架构上访问Flash比访问RAM慢如果这个常量在热路径上频繁访问放Flash反而拖慢性能。所以优化从来不是无脑套用要结合访问模式来判断。4.4 优化后的验证不能省优化改完代码必须重新跑一遍完整测试。因为优化很容易引入新bug尤其是涉及数据类型转换、边界处理、内存布局的改动。AI帮你做的优化你更要仔细验证因为它可能没考虑到你项目里的特殊约束。我的习惯是每次优化后对比优化前后的测试结果确保功能行为完全一致。如果优化涉及精度变化还要额外做精度测试确认在可接受范围内。这一步不能省省了就是给自己埋雷。5. 文档、接口与团队协作的收尾工作项目做到最后代码本身可能只占交付内容的一半另一半是文档和接口说明。这部分工作枯燥但重要AI在这块能帮上大忙因为它擅长把代码转成文字描述。5.1 让AI从代码反向生成接口文档手写接口文档费时费力还容易和代码不同步。我的做法是让AI读代码生成接口文档初稿然后人工校对。AI生成的文档在格式和完整性上通常不错但可能对某些参数的含义理解有偏差需要人确认。具体操作上我会把相关的头文件和源文件一起给AI让它输出每个函数的用途、参数说明、返回值、注意事项。然后我对照代码逐个核对重点看参数的单位、取值范围、特殊值含义这些容易出错的地方。5.2 模块划分与依赖关系的梳理项目大了之后模块之间的依赖关系容易乱。AI可以帮你分析代码里的include关系和函数调用关系画出模块依赖图用文字描述不用图形找出循环依赖和不该有的耦合。这个分析在交付前做一遍很有价值。我遇到过好几次某个底层驱动模块莫名其妙依赖了上层应用的头文件导致移植时很麻烦。这种问题人工排查费时让AI扫一遍调用关系很快就能发现。5.3 版本管理与变更记录的规范AI协同开发的一个特点是代码变更频繁所以版本管理和变更记录要格外规范。我的做法是每次AI生成或修改代码都单独提交一次提交信息里写清楚这次改了什么、为什么改、由AI生成还是人工修改。这样做的好处是出问题的时候能快速定位到是哪次改动引入的。而且从变更记录里能看出哪些地方AI改得多、哪些地方人工介入多对后续优化协作流程有帮助。变更记录我建议包含这几个字段变更日期、变更内容、变更原因、验证结果、变更人AI或人工。这个记录不用很正式但要坚持写时间长了就是项目的宝贵资料。5.4 交付前的最终检查清单项目交付前我有一份固定的检查清单逐项过一遍才放心。这份清单在AI协同开发里尤其重要因为AI不会主动提醒你这些事。所有AI生成的代码是否都经过人工审查硬件相关参数是否都对照手册核对过中断和临界区保护是否完整资源占用是否在预算内栈峰值是否安全边界条件和异常路径是否有测试覆盖接口文档是否和代码一致版本记录是否完整是否有遗留的调试代码和临时改动这份清单看起来简单但每一条背后都是踩过的坑。比如遗留的调试代码这一条AI生成的代码里经常带着printf调试语句在资源紧张的芯片上这些语句可能占不少Flash交付前必须清理。6. 这套协作方式跑下来的一些真实体会项目做完回过头看AI协同开发在嵌入式领域确实能提效但提效的前提是你知道怎么用它、用在哪。我最大的体会是AI最擅长的是有明确规则的重复劳动和结构化的代码生成最不擅长的是需要硬件上下文判断和涉及具体参数决策的事情。把这两类事情分开让AI做它擅长的人做必须人做的协作就顺畅。另一个体会是提示词的质量直接决定产出质量。花十分钟写一个清晰的提示词比花一小时改AI生成的烂代码划算得多。而且好的提示词可以复用形成自己的提示词库之后后面做类似项目效率会越来越高。还有一点AI生成的代码一定要当成别人的代码来审查不能因为它写得规范就放松警惕。我见过太多因为信任AI而漏掉关键bug的案例。审查的标准要和审查同事代码一样严格甚至更严格因为AI不会为它的错误负责。最后说个实际的这套协作方式不是一蹴而就的我前几个项目也是各种踩坑提示词写得不好、审查不到位、优化改出问题都是经历过的。但每踩一次坑流程就完善一点到现在基本形成了一套稳定的工作方式。如果你刚开始尝试AI协同开发嵌入式项目建议从小模块开始跑通一个完整流程之后再扩大范围这样风险可控经验也能积累起来。
嵌入式软件开发和AI编程这两个领域单独拎出来都不算新鲜但把它们捏在一起做协同开发真正跑通一个完整项目的人其实并不多。我接触过不少做MCU固件、RTOS驱动、BSP移植的工程师大家用AI辅助编程的姿势差别很大——有人只拿它当高级搜索引擎有人用它生成整段HAL初始化代码还有人干脆让AI从需求文档直接吐出一个可编译的工程骨架。这几种用法我都试过踩过的坑也不少。这篇内容围绕第一个AI协同开发项目的第三部分展开重点聊的是当项目从能跑进入要交付阶段时AI协同开发到底该怎么组织、怎么验证、怎么收尾。如果你正在做嵌入式方向的工作或者想搞清楚AI编程在资源受限环境里到底能帮上多少忙接下来的内容应该对你有用。我会把工具选型、提示词设计、代码审查、硬件联调、回归验证这几个环节拆开讲尽量把每一步背后的判断逻辑说清楚而不是只丢一堆结论。1. 从能编译到能交付之间隔着什么很多人对AI协同开发的期待停留在帮我写个驱动这个层面但真正做过完整项目的人知道代码能编译通过只是万里长征第一步。嵌入式项目的交付标准比纯软件苛刻得多它要在真实的板子上跑起来要在中断和主循环之间保持时序正确要在有限的RAM和Flash里不越界还要在断电重启、外设异常、通信丢包这些边界条件下不崩。AI生成的代码往往在语法和逻辑层面看起来没问题但一旦落到具体硬件上问题就会集中暴露。1.1 为什么AI生成的嵌入式代码容易看起来对这里要先说清楚一个底层原因。大语言模型在生成代码时本质是在做概率预测它见过大量开源项目和教程代码所以能写出结构规整、命名规范、注释齐全的函数。但嵌入式代码有一个特点它的正确性高度依赖具体的硬件手册、时钟树配置、寄存器位定义和外设时序。这些信息在训练数据里往往是碎片化的、版本混杂的模型很难精确记住某一颗具体芯片在某个主频下的分频系数。我举个实际例子。之前让AI生成一段STM32的UART初始化代码它给出的波特率寄存器值是基于72MHz主频算的但我手上的板子实际跑在64MHz。代码编译没问题烧进去串口就是乱码。这种错误AI自己是发现不了的因为它不知道你的实际时钟配置。类似的还有SPI的CPOL/CPHA极性、I2C的上拉电阻阻值、ADC的采样时间设置这些参数一旦和硬件不匹配表现就是功能时好时坏或者完全没反应。所以第一个认知必须建立AI负责的是代码结构和逻辑框架硬件相关的具体参数必须由人来核对和填充。把AI当成一个写代码很快但不懂你手上这块板子的实习生这个定位最准确。1.2 交付阶段真正要盯住的四类问题在项目从开发转向交付的过程中我习惯把问题分成四类来盯这个分类方式对AI协同开发特别有用因为它能帮你判断哪些环节可以让AI多承担哪些必须人工介入。问题类型典型表现AI可承担程度人工必须介入的点语法与结构编译报错、头文件缺失高基本可自动修复确认修复未引入新依赖逻辑正确性状态机跳转错误、边界漏判中需明确描述需求审查分支覆盖和异常路径硬件适配寄存器值错误、时序不符低模型缺硬件上下文对照手册逐项核对资源占用RAM溢出、栈溢出、Flash超限中可辅助分析实测map文件确认这张表我建议每个做AI协同开发的人都存一份。它的价值在于当你拿到AI生成的一大段代码时能快速判断这段代码的风险等级。语法结构类的问题放心交给AI迭代硬件适配类的问题必须自己上手逻辑和资源类的问题则需要AI辅助加人工确认。1.3 本阶段项目的实际状态盘点回到这个第一个AI协同开发项目的第三部分此时项目通常已经过了原型验证功能基本跑通但离交付还有距离。具体来说这个阶段一般要处理的事情包括把AI生成的零散函数整合成模块化的驱动层、补充错误处理和异常恢复逻辑、做资源占用的实测和优化、编写可复现的测试用例、整理接口文档。这些事情里模块化整合和文档整理AI能帮大忙错误处理和资源优化则需要人来主导。我自己的做法是先让AI把现有代码按功能重新组织一遍生成模块划分建议然后我根据实际硬件资源情况调整。这个过程里AI最大的价值不是写新代码而是帮你把散落各处的代码理出一个结构相当于一个不知疲倦的重构助手。2. 提示词怎么写才能让AI产出可用的嵌入式代码提示词这件事网上讲的人很多但大部分讲的是通用场景。嵌入式有它的特殊性你需要让AI知道芯片型号、编译器、RTOS、外设配置这些上下文否则它给的东西就是通用但不可用。我在这个项目里摸索出一套提示词结构实测下来能显著提高一次通过率。2.1 嵌入式提示词的四个必备要素一个能让AI产出可用嵌入式代码的提示词至少要包含四个要素目标平台、功能需求、约束条件、输出格式。缺了任何一个产出质量都会明显下降。目标平台要具体到芯片系列和开发环境。比如STM32F407使用STM32CubeIDEHAL库版本1.27就比STM32有用得多。功能需求要描述清楚输入输出和触发条件比如按键按下后通过UART发送一帧数据帧格式为...。约束条件包括RAM限制、实时性要求、是否允许阻塞等。输出格式则决定AI给你的是完整文件还是函数片段。我常用的提示词模板大概是这样平台STM32F407ZGT6主频168MHz使用HAL库FreeRTOS 需求实现一个Modbus RTU从机支持功能码03和06 约束 - 串口波特率96008N1 - 接收使用中断空闲检测不用DMA - 寄存器区大小不超过256字节 - 响应时间要求小于10ms 输出给出完整的.c和.h文件包含初始化函数和任务函数这个模板的关键在于把约束写清楚。很多人写提示词只写需求不写约束结果AI给一个用DMA加双缓冲的复杂方案功能是对的但和你现有的代码架构完全不兼容改起来比自己写还累。2.2 让AI先出接口再出实现这是我踩过坑之后总结出来的一个技巧。直接让AI写完整实现它容易在细节上跑偏而且一旦方向错了整段代码都要重来。更好的做法是分两步先让AI输出接口定义你确认接口合理之后再让它填充实现。接口定义包括函数签名、数据结构、错误码。这一步AI做得很快你审查起来也快。比如让它设计一个环形缓冲区先看它给的接口typedef struct { uint8_t *buffer; uint16_t size; volatile uint16_t head; volatile uint16_t tail; } ringbuf_t; int ringbuf_init(ringbuf_t *rb, uint8_t *mem, uint16_t size); int ringbuf_put(ringbuf_t *rb, uint8_t data); int ringbuf_get(ringbuf_t *rb, uint8_t *data); uint16_t ringbuf_count(const ringbuf_t *rb);看到这个接口我立刻能判断出几个问题head和tail用了volatile说明考虑了中断场景但没有提供线程安全的批量读写接口count函数在中断里调用可能有竞态。这些判断在接口阶段就能做比等实现写完再改省事得多。2.3 提示词里必须明确的不要做什么这一点特别重要但很多人会忽略。AI有过度设计的倾向你让它写个简单的LED闪烁它可能给你整出一个带状态机、支持呼吸灯、可配置闪烁模式的大模块。在嵌入式环境里过度设计意味着浪费Flash和RAM还增加维护成本。所以提示词里要明确写不要做什么。比如不要使用动态内存分配、不要引入额外的第三方库、不要使用递归、中断服务函数内不要调用阻塞API。这些约束能有效收敛AI的输出范围。我整理了一份常用的负面约束清单基本每个嵌入式项目的提示词里都会带上几条不使用malloc/free所有内存静态分配中断服务函数保持简短不调用printf等重函数不使用浮点运算无FPU的芯片不依赖编译器特定扩展全局变量加static限制作用域2.4 迭代式对话比一次性长提示更有效我一开始也喜欢写超长的提示词想把所有要求一次说清楚。但实际用下来迭代式对话效果更好。原因是AI在长上下文里容易丢失中间信息而且一次性给太多约束它可能顾此失彼。更好的节奏是第一轮给平台和核心需求拿到框架第二轮针对具体函数提优化要求第三轮处理边界条件和错误处理。每一轮都基于上一轮的产出这样AI的注意力始终集中在当前要解决的问题上。比如做UART接收第一轮先让它给出中断接收的基本框架第二轮再要求加空闲检测和帧解析第三轮补充校验失败和超时的处理。这样一步步来每步都能审查出问题也容易定位。3. AI生成代码的审查重点与实测验证方法代码审查这个环节在AI协同开发里比传统开发更重要因为AI生成的代码有一种迷惑性——它写得很规范注释很全看起来特别专业但可能藏着一些隐蔽的问题。我在这部分项目里形成了一套审查流程重点盯几个高风险区域。3.1 中断相关的代码必须逐行看中断是嵌入式里最容易出问题的地方也是AI最容易写错的地方。常见的问题包括中断服务函数里调用了不可重入函数、共享变量没有加volatile、临界区保护缺失、中断优先级配置冲突。我审查中断代码时有个固定动作把所有在中断和主循环之间共享的变量列出来逐个确认是否有volatile修饰是否在访问时做了临界区保护。AI经常忘记加volatile因为它不理解编译器优化和硬件异步修改之间的关系。还有一个隐蔽的坑是中断标志清除的时机。有些AI生成的代码在中断服务函数开头就清标志有些在结尾清这两种写法在不同芯片上的行为可能不一样。这个必须对照具体芯片的手册确认不能想当然。3.2 用静态分析工具做第一道过滤人工审查之前先跑一遍静态分析工具能省很多事。我用得比较多的是编译器自带的警告开-Wall -Wextra、cppcheck、还有芯片厂商提供的配置检查工具。这些工具能抓出未初始化变量、数组越界、类型不匹配这类问题。AI生成的代码在静态分析下经常暴露的问题有几类变量声明了没用、隐式类型转换、switch语句缺少default分支、函数声明和定义参数不一致。这些问题人工看容易漏工具一扫就出来。我一般会把这些工具的检查集成到构建流程里每次AI生成新代码编译时自动跑一遍。这样问题在早期就暴露不会积累到联调阶段。3.3 硬件联调时的分步验证策略代码审查通过不代表硬件上就能跑。我的做法是把功能拆成最小的可验证单元一个一个上板测试。比如一个通信模块先验证初始化是否成功读芯片ID再验证发送是否正常示波器看波形再验证接收是否正常回环测试最后验证协议解析。这个分步策略在AI协同开发里特别重要因为AI生成的代码往往是整体正确但局部有错。如果一上来就测完整功能出了问题很难定位是哪个环节的错。分步验证能把问题范围缩小到单个函数甚至单行代码。实测中我遇到过一个典型情况AI生成的SPI驱动单独测试读写寄存器都正常但一加上DMA传输就出错。分步验证让我很快定位到是DMA配置里的数据宽度设置和SPI的数据帧格式不匹配。如果直接测完整功能这个bug可能要查很久。3.4 建立可复现的回归测试集项目进入交付阶段回归测试就变得关键。每次修改代码都要确认没有破坏已有功能。AI协同开发里代码改动频繁回归测试能帮你守住底线。我的做法是维护一个测试用例集每个用例对应一个功能点用脚本自动跑。嵌入式环境里做自动化测试比纯软件麻烦但也不是做不到。串口命令、GPIO翻转、ADC采样这些都可以通过脚本控制。关键是测试用例要能自动判断通过与否而不是靠人眼看。对于AI生成的代码我还会额外加一类测试边界值测试。因为AI对边界条件的处理经常不到位比如缓冲区满、计数溢出、超时归零这些情况。专门针对边界写测试用例能抓出不少隐藏问题。4. 资源受限环境下的优化与取舍嵌入式项目绕不开资源问题。Flash和RAM就那么大AI生成的代码如果不加控制很容易超标。这部分我讲讲在资源受限环境下怎么和AI配合做优化。4.1 先测量再优化别凭感觉优化的第一步永远是测量。我见过太多人凭感觉优化结果改了半天占用的资源没降多少代码可读性还变差了。正确的做法是先看map文件搞清楚Flash和RAM到底被谁占了。map文件里重点看几个东西各个目标文件的大小、栈和堆的分配、最大的几个函数。AI可以帮你分析map文件把占用大的模块列出来。有了这个数据优化才有方向。我一般会关注这几个指标代码段大小、只读数据段大小、已初始化数据段大小、未初始化数据段大小、栈使用峰值。栈使用峰值这个尤其重要AI生成的代码如果有深层调用或者大局部数组很容易栈溢出而且这种问题往往在运行时才暴露很难查。4.2 让AI做优化建议人来拍板测量出问题之后可以让AI给优化建议。AI在这方面的价值是能快速给出多种方案比如把查表改成计算、把浮点改成定点、把大数组改成压缩存储。但具体选哪个方案要人来判断因为涉及精度、可读性、维护成本的权衡。举个例子一个三角函数计算AI可能给出三种方案查表法、泰勒展开、CORDIC算法。查表法快但占Flash泰勒展开精度可控但慢CORDIC适合无FPU的芯片但代码复杂。选哪个取决于你的具体约束。这种决策AI做不了它不知道你的项目更看重什么。4.3 常见的资源优化手段及适用场景我把常用的优化手段整理成一张表方便对照使用。这些手段AI都能帮你实现但用不用、用哪个需要你根据实际情况判断。优化手段节省的资源代价适用场景查表代替计算CPU时间Flash空间计算密集且输入范围有限定点代替浮点CPU时间、代码量精度无FPU的芯片位域压缩存储RAM空间访问速度大量布尔标志函数内联调用开销代码量短小频繁调用的函数常量放FlashRAM空间访问速度大块只读数据动态内存改静态确定性灵活性实时性要求高的场景这张表里的每一行背后都有具体的取舍逻辑。比如常量放Flash这一条在有些架构上访问Flash比访问RAM慢如果这个常量在热路径上频繁访问放Flash反而拖慢性能。所以优化从来不是无脑套用要结合访问模式来判断。4.4 优化后的验证不能省优化改完代码必须重新跑一遍完整测试。因为优化很容易引入新bug尤其是涉及数据类型转换、边界处理、内存布局的改动。AI帮你做的优化你更要仔细验证因为它可能没考虑到你项目里的特殊约束。我的习惯是每次优化后对比优化前后的测试结果确保功能行为完全一致。如果优化涉及精度变化还要额外做精度测试确认在可接受范围内。这一步不能省省了就是给自己埋雷。5. 文档、接口与团队协作的收尾工作项目做到最后代码本身可能只占交付内容的一半另一半是文档和接口说明。这部分工作枯燥但重要AI在这块能帮上大忙因为它擅长把代码转成文字描述。5.1 让AI从代码反向生成接口文档手写接口文档费时费力还容易和代码不同步。我的做法是让AI读代码生成接口文档初稿然后人工校对。AI生成的文档在格式和完整性上通常不错但可能对某些参数的含义理解有偏差需要人确认。具体操作上我会把相关的头文件和源文件一起给AI让它输出每个函数的用途、参数说明、返回值、注意事项。然后我对照代码逐个核对重点看参数的单位、取值范围、特殊值含义这些容易出错的地方。5.2 模块划分与依赖关系的梳理项目大了之后模块之间的依赖关系容易乱。AI可以帮你分析代码里的include关系和函数调用关系画出模块依赖图用文字描述不用图形找出循环依赖和不该有的耦合。这个分析在交付前做一遍很有价值。我遇到过好几次某个底层驱动模块莫名其妙依赖了上层应用的头文件导致移植时很麻烦。这种问题人工排查费时让AI扫一遍调用关系很快就能发现。5.3 版本管理与变更记录的规范AI协同开发的一个特点是代码变更频繁所以版本管理和变更记录要格外规范。我的做法是每次AI生成或修改代码都单独提交一次提交信息里写清楚这次改了什么、为什么改、由AI生成还是人工修改。这样做的好处是出问题的时候能快速定位到是哪次改动引入的。而且从变更记录里能看出哪些地方AI改得多、哪些地方人工介入多对后续优化协作流程有帮助。变更记录我建议包含这几个字段变更日期、变更内容、变更原因、验证结果、变更人AI或人工。这个记录不用很正式但要坚持写时间长了就是项目的宝贵资料。5.4 交付前的最终检查清单项目交付前我有一份固定的检查清单逐项过一遍才放心。这份清单在AI协同开发里尤其重要因为AI不会主动提醒你这些事。所有AI生成的代码是否都经过人工审查硬件相关参数是否都对照手册核对过中断和临界区保护是否完整资源占用是否在预算内栈峰值是否安全边界条件和异常路径是否有测试覆盖接口文档是否和代码一致版本记录是否完整是否有遗留的调试代码和临时改动这份清单看起来简单但每一条背后都是踩过的坑。比如遗留的调试代码这一条AI生成的代码里经常带着printf调试语句在资源紧张的芯片上这些语句可能占不少Flash交付前必须清理。6. 这套协作方式跑下来的一些真实体会项目做完回过头看AI协同开发在嵌入式领域确实能提效但提效的前提是你知道怎么用它、用在哪。我最大的体会是AI最擅长的是有明确规则的重复劳动和结构化的代码生成最不擅长的是需要硬件上下文判断和涉及具体参数决策的事情。把这两类事情分开让AI做它擅长的人做必须人做的协作就顺畅。另一个体会是提示词的质量直接决定产出质量。花十分钟写一个清晰的提示词比花一小时改AI生成的烂代码划算得多。而且好的提示词可以复用形成自己的提示词库之后后面做类似项目效率会越来越高。还有一点AI生成的代码一定要当成别人的代码来审查不能因为它写得规范就放松警惕。我见过太多因为信任AI而漏掉关键bug的案例。审查的标准要和审查同事代码一样严格甚至更严格因为AI不会为它的错误负责。最后说个实际的这套协作方式不是一蹴而就的我前几个项目也是各种踩坑提示词写得不好、审查不到位、优化改出问题都是经历过的。但每踩一次坑流程就完善一点到现在基本形成了一套稳定的工作方式。如果你刚开始尝试AI协同开发嵌入式项目建议从小模块开始跑通一个完整流程之后再扩大范围这样风险可控经验也能积累起来。
