做嵌入式的人应该都有体会这两年AI编程工具铺天盖地身边不少做Web、做App的朋友早就用上了写代码效率翻倍。但我们搞单片机、搞STM32的总有一种AI好用是好用就是用不到刀刃上的感觉。语法它懂、逻辑它也能编可一旦涉及寄存器配置、时钟树、外设中断这些硬件强相关的东西AI给出的答案就经常让人心里没底。我最近一段时间把AI协同开发STM32的流程整个捋了一遍从一个单纯让AI帮我写个驱动函数的零散用法整理成了一整套从需求拆分、代码生成、交叉验证到硬件联调的流程。这套流程跑通之后我自己的固件开发效率提升非常明显尤其是那些重复性高的外设初始化、HAL库样板代码、状态机模板AI分担掉之后我真正可以腾出精力去做硬件调优和异常排查。这篇文章就围绕AI协同开发STM32程序的流程来写把我在实际项目里沉淀下来的思路、提示词模板、踩坑经历和验证方法一次性讲清楚。适合正在用或准备用AI工具做嵌入式开发的朋友无论你是主用HAL库还是LL库这套流程的基本逻辑都通用。1. AI在嵌入式领域能帮到什么程度先泼一盆冷水在谈流程之前先把我踩过几个月的坑拿出来说。很多人第一次用AI写STM32代码时体验两极分化让它写一个串口发送字符串的HAL库函数它会写得又快又对让它写一个带DMA乒乓缓冲的ADC多通道采集它给出的代码看着没问题烧进去就是不出数据。问题不在于AI笨而在于嵌入式开发的特殊性。1.1 AI擅长的是通用逻辑不是具体硬件AI大模型训练时见过海量的STM32代码对HAL库、标准外设库的API调用方式非常熟悉。你问它用HAL库配置USART1并发送数据它几乎不会出错因为这类代码在github、博客、论坛上太常见了训练样本充足。但一旦你问的是某个冷门芯片型号的特定外设特性比如某个国产替代型号的ADC采样保持时间差异、某款板子的引脚复用冲突AI就开始一本正经地胡编。它不会告诉你它没见过这个芯片的手册它会按照STM32通用知识给你编一段代码看着合理实际上完全跑不通。这就是AI辅助嵌入式开发的第一条铁律AI提供的代码本质上是一个高度可信的初稿而不是可直接烧录的最终版。你需要把它当成一个很聪明但没看过你原理图的实习生而不是一个十年经验的硬件工程师。1.2 嵌入式开发的信息差恰恰是AI的盲区做Web开发AI生成代码后浏览器里一眼就能看出对不对。做嵌入式代码要经过编译、烧录、硬件运行才能验证而且一旦有问题可能是代码问题、配置问题、接线问题、电源问题甚至晶振起振慢这种玄学问题。传统开发流程里这些排查靠的就是经验积累和对芯片手册的熟悉程度。AI恰恰缺乏这种现场感它不知道你的板子用的是8MHz外部晶振还是内部HSI不知道你的LED是低电平点亮还是高电平点亮不知道你的中断优先级分组是几。所以AI协同开发STM32的流程核心不是让AI写代码而是把AI纳入到一套有硬件验证环节的完整开发流程中。AI只负责产出候选方案真正的决策者和验证者始终是人。1.3 那AI到底能帮上什么忙把话说回来AI在嵌入式领域能帮的忙其实很多重点在于选对任务外设驱动的样板初始化代码USART、I2C、SPI、TIM等HAL库初始化流程通用算法逻辑环形缓冲区、PID控制器、滤波算法、CRC校验、状态机框架寄存器含义的查询和解释把手册里的英文描述翻译成通俗中文编译报错信息的分析尤其是HAL库内部报错AI往往能直接指明参数问题代码风格统一和注释补全对老项目维护很有用这些任务的共同点是答案是相对确定的而且训练数据足够多。而那些不确定的部分——时钟树怎么分频、DMA通道怎么映射、中断服务函数里要做什么——必须由人来把关。2. 准备工作搭建一个AI友好的STM32工作环境很多人在AI协同开发中翻车不是提示词写得不好而是工作环境压根没准备好。AI生成的代码没法快速验证改一处要重新手工配置半天来回几次耐心就没了。我建议在开始之前把环境搭成AI生成代码 → 一键编译烧录 → 快速验证的闭环。2.1 工具链的选型思路我目前的主力环境是STM32CubeIDE配合命令行工具链再辅以Git做版本管理。选这套组合的原因有三个第一STM32CubeMX的代码生成器是AI最好的脚手架供应商。让AI直接从头写一个完整工程远不如用CubeMX生成工程框架再让AI在生成好的框架里填充逻辑代码来得靠谱。这样时钟树、引脚复用、外设初始化全部由CubeMX保证正确AI只需要专注业务逻辑。第二STM32CubeIDE自带编译器和调试器集成了OpenOCD可以做到F10单步调试、变量实时观察。AI写出来的代码逻辑对不对单步一跑就知道。第三Git是整个AI协同工作流里不可或缺的一环。AI生成的代码有概率引入隐蔽的问题有了Git你可以随时把改动回滚到上一个确定能跑的版本这在硬件调试中能节省大量时间。2.2 把硬件约束上下文提前整理好跟AI协作之前我强烈建议把你自己板子的硬件约束整理成一份文档每次对话时直接粘贴给AI。这样AI给出的代码就不会出现使用了不存在的引脚或配置了错误的外设时钟这种低级错误。我自己的约束文档模板大概长这样芯片型号STM32F103C8T6主频72MHz外部晶振8MHz关键引脚PA5-板载LED低电平点亮PA9/PA10-USART11152008N1PB0-外部按键按下为低电平接上拉电阻使用HAL库固件包版本STM32Cube FW_F1 V1.8.5编译环境STM32CubeIDE 1.15.0ARM GCC工具链默认优化等级别小看这几行信息。我实测过把这段上下文贴在对话开头之后AI生成代码的引脚正确率从大概七成直接提升到接近九成。原因很简单大模型的幻觉往往是因为缺乏约束条件你把约束条件喂给它它就只能在这个框架里寻找答案。2.3 确定人机分工边界这个听起来有点虚但实际是流程里最关键的一步。我总结了一个简单的分工原则AI负责单个函数的实现、算法逻辑、报错分析、代码注释、库函数用法查询人负责需求分析、系统架构、外设选择、时钟配置、中断优先级、功耗策略、硬件验证不是说人不能做AI做的事而是说在AI擅长的领域放权给它在高风险的领域必须亲自把关。比如中断服务函数里放什么代码这种直接影响系统稳定性的核心逻辑我建议永远不要交给AI全权决定。你可以让AI写一个参考版本但最终合入主线的代码必须经过自己的理解和确认。3. 核心流程拆解从需求到代码的五步闭环有了前面的准备就可以正式进入AI协同开发STM32的流程了。我把它拆成五个步骤形成一个闭环需求拆解、方案确认、代码生成、交叉验证、硬件联调。3.1 需求拆解把一句话需求变成可执行的开发任务大多数人在让AI写代码时给的是这样一句帮我写一个STM32的PWM呼吸灯程序。这个需求对AI来说太模糊了。它不知道你用哪个定时器、哪个通道、输出极性是什么、频率和占空比范围是多少、呼吸周期要多长。AI只能按照最常见的默认配置去猜猜中的概率自然不高。正确的做法是先自己拆解需求把大任务分解成AI能理解的原子任务。比如上面的呼吸灯程序可以拆成配置TIM2通道1为PWM输出模式输出引脚PA0PWM频率设定为1kHz初始占空比0用定时器更新中断实现占空比从0到100再到0的循环变化每步变化间隔5ms占空比步进值1%这样拆解之后AI写出来的代码就非常明确几乎不会跑偏。我在实际项目中花在需求拆解上的时间通常占整个开发周期的三成以上但很值得因为后面的生成和调试都会因此变快。3.2 方案确认让AI先回答怎么做而不是写什么这个步骤很多人会跳过但我强烈建议保留。在让AI直接写代码之前先让它描述实现方案。比如你可以问我准备用STM32F103C8T6TIM2_CH1输出1kHz PWM控制LED亮度请给我两种实现PWM占空比渐变的方法分别说明优缺点。AI这时候会给出基于查询中断、直接修改CCR寄存器、使用DMA等不同思路的方案。你可以在这些方案里选择一个最适合当前项目的。这个先讨论方案、再生成代码的过程能避免很多因为实现思路不同而导致的返工。而且你会发现当你让AI解释为什么这个方案可行的时候它给出的解释往往会暴露一些细节问题比如此方案需要占用TIM2的更新中断你可能需要考虑与其它中断的优先级冲突。这些问题在纯代码生成阶段是看不到的。3.3 代码生成一次生成一小块还要附上约束条件这是大家最熟悉的环节也是最容易犯错的环节。我的经验是三个原则。第一一次只生成一个功能模块。不要试图让AI一次性完成串口通信按键扫描LED状态控制看门狗喂狗这么庞大的任务。模块越小AI生成代码的准确率越高你也越容易验证。第二不要用聊天式长对话。很多AI工具会记住前文内容但嵌入式开发中前面前提很容易被后续讨论覆盖掉。我建议一次对话里聚焦一个小目标搞定之后开新对话写下一个模块。这样每个对话都干净利落不会因为上下文太长而互相干扰。第三明确要求AI给出可编译的完整代码块。有时候AI会偷懒只给出关键片段比如然后在中断服务函数里添加以下代码却不告诉你要不要使能中断。我的提示词模板会在末尾加上一句请给出完整可编译的代码片段包括所有需要包含的头文件和需要调用的初始化函数。实战中我这句提示词至少减少了三成回头再去追问细节的时间。3.4 交叉验证不急着烧录先做桌面推演AI生成完代码大多数人的第一反应就是编译烧录。我的建议是先做一个两分钟的桌面推演把AI生成代码里的关键逻辑过一遍。举个例子AI生成了一段PWM初始化代码void PWM_Init(void) { TIM_HandleTypeDef htim2; TIM_OC_InitTypeDef sConfigOC; __HAL_RCC_TIM2_CLK_ENABLE(); htim2.Instance TIM2; htim2.Init.Prescaler 71; htim2.Init.CounterMode TIM_COUNTERMODE_UP; htim2.Init.Period 999; htim2.Init.ClockDivision TIM_CLOCKDIVISION_DIV1; if (HAL_TIM_PWM_Init(htim2) ! HAL_OK) { Error_Handler(); } sConfigOC.OCMode TIM_OCMODE_PWM1; sConfigOC.Pulse 0; sConfigOC.OCPolarity TIM_OCPOLARITY_HIGH; sConfigOC.OCFastMode TIM_OCFAST_DISABLE; if (HAL_TIM_PWM_ConfigChannel(htim2, sConfigOC, TIM_CHANNEL_1) ! HAL_OK) { Error_Handler(); } HAL_TIM_PWM_Start(htim2, TIM_CHANNEL_1); }这里就有两个桌面推演能看出来的问题htim2是局部变量虽然HAL库内部会把它复制到CORE的句柄数组里但如果你在后面其他函数里还想用htim2配置别的通道那就拿不到同步另外Pulse 0意味着初始占空比为0如果业务逻辑里期望一开始就有50%占空比那肯定不对。这类问题编译阶段完全不会报错但运行起来就是不符合预期。花两分钟推演一遍关键参数远比烧录后再反复调试要高效。3.5 硬件联调确认烧进去能跑只是起点最后一步也是AI协同流程和纯AI编程最不一样的地方硬件联调。AI代码烧进板子功能正常不代表就结束了。我习惯在联调阶段做三个验证功能验证、边界验证、稳定性验证。功能验证核心功能是否正常LED亮灭、串口收发数据是否符合预期。边界验证输入极端参数是否会导致异常。比如串口连续发送大数据包会不会丢数据按键快速连按会不会导致状态机错乱稳定性验证让板子跑一段时间看是否出现偶发死机或数据异常。这三个验证里AI能帮上忙的是分析异常出现时的日志和现象。比如连按按键时LED状态错乱你可以把状态机代码和现象描述一起发给AI让它分析可能的原因。AI往往会给出几个排查方向——去抖时间不足、中断嵌套问题、状态翻转条件冲突——这些方向参考价值很高但最终确认根因还是得靠你在硬件上复现和排查。4. 一个完整的实战案例AI协作完成LED呼吸灯串口日志聊完理论用我最近做过的一个小项目把流程完整串一遍。这个项目的需求很简单板子上一个LED呼吸灯同时通过串口打印当前占空比。4.1 第一步CubeMX生成工程骨架我先在STM32CubeMX里配置好TIM2_CH1输出PWM到PA0频率1kHzUSART1115200-8-N-1发送到PA9生成工程代码基础框架使用HAL库这个步骤里时钟树、引脚复用、外设底层初始化全部由CubeMX搞定AI在后面只需要面对业务逻辑不用碰这些配置雷区。注意在CubeMX工程里把TIM2的NVIC Settings里Update中断勾选上因为呼吸灯的渐变逻辑我打算用更新中断实现。这个勾选如果漏了后面AI怎么加中断服务函数都白搭因为中断根本不会触发。4.2 第二步让AI生成核心渐变逻辑工程骨架准备好之后我开了一个新的AI对话粘贴上前面说的硬件约束上下文然后给出了明确任务使用STM32F103C8T6的TIM2更新中断实现PWM占空比渐变。要求1kHz的PWM频率下Period999每次更新中断把占空比增加1%也就是Pulse加10达到100%后反向递减到0再回到渐增循环。串口每100ms打印一次当前占空比。请用HAL库实现。AI给出的核心代码大致这样volatile uint32_t pwm_pulse_target 0; volatile uint8_t pwm_direction 1; void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) { static uint32_t step_counter 0; static uint8_t pwm_pulse_current 0; if (htim-Instance ! TIM2) return; step_counter; if (step_counter % 100 0) { // 每隔100次更新中断约100ms改变一次占空比步进 if (pwm_direction) { pwm_pulse_current 10; if (pwm_pulse_current 999) { pwm_pulse_current 999; pwm_direction 0; } } else { pwm_pulse_current - 10; if (pwm_pulse_current 0) { pwm_pulse_current 0; pwm_direction 1; } } __HAL_TIM_SET_COMPARE(htim2, TIM_CHANNEL_1, pwm_pulse_current); pwm_pulse_target pwm_pulse_current; } }这段代码逻辑是通的但我做桌面推演时发现了两个问题。第一个问题__HAL_TIM_SET_COMPARE(htim2, ...)这里用到了htim2这个句柄变量但在CubeMX生成的代码里句柄名通常是htim2没错但这个变量默认是static定义的在main.c里作用域受限于文件。如果HAL_TIM_PeriodElapsedCallback写在stm32f1xx_it.c文件里直接引用htim2会编译报错未定义。AI显然没考虑这个文件跨引用的问题。我直接用htim指针改掉了这行因为回调函数本身就拿到了当前触发中断的定时器句柄用它就能正确操作__HAL_TIM_SET_COMPARE(htim, TIM_CHANNEL_1, pwm_pulse_current);第二个问题占空比变化速度。AI按照每100次更新中断才步进一次的方式设计算下来从0到100%要走大约10秒呼吸节奏偏慢。我实际想要的是2-3秒一个周期。这个参数跟需求有关AI无法知道只能人根据自己的需要调整步进频率。我把条件改为step_counter % 20让1kHz的中断里每20次约20ms步进一次整体呼吸周期大约4秒观感比较舒服。4.3 第三步AI辅助排查串口打印的怪现象呼吸灯跑起来之后我发现串口打印的占空比数据有规律性跳变每次打印的数值不是连续递增的而是会周期性出现跳变回小数值的情况。我最初怀疑是串口发送和中断之间的竞争问题。但仔细推演后意识到串口打印用的是查询阻塞发送一次发送大约不到1ms而占空比更新频率是50Hz20ms一次按理说不应该冲突。我把这个现象和代码发给AI让它分析可能的根因。AI给了一个很有价值的猜测你的pwm_pulse_target是全局变量中断里修改主循环串口打印读取。由于这里没有加volatile之外的保护主循环读取时可能拿到的是中断修改前的旧值也可能是修改后的新值但正常情况下这只会造成轻微的不一致不会出现周期性跳回。这个猜测没有直接解决问题但它提示我问题可能不在打印逻辑而在占空比本身的更新逻辑。我重新检查AI生成代码里的渐变步进逻辑发现一个藏在细节里的bug当占空比达到999后方向切换为递减但递减时pwm_pulse_current - 10降到0后方向又切换为递增。表面看着没问题问题是这个切换逻辑放在step_counter % 20的条件里也就是说只有每20次中断才判断一次。如果在这20次间隔里占空比已经到顶或者触底了方向切换要等到下一次判断才执行中间这段时间占空比会保持不变。这不是串口的问题是渐变逻辑的阶梯效应。我一直在串口数据里找规律看到跳回小数值其实是因为打印间隔恰好错开了占空比步进的节奏看起来像跳变。AI的这个错误猜测反而提醒我去关注真正出问题的那部分逻辑。这个案例很好地说明了AI协同开发的一个核心价值AI不是替你找出所有问题而是给你提供一种换个角度看问题的能力。它猜的方向不一定对但它的分析思路能打开你的排查思路让你不再盯着表面现象不放。4.4 这个案例沉淀下来的通用结论整个项目做完之后我最大的体会是AI帮你把70%的常规代码工作做完剩下的30%也就是硬件适配、时序优化、边界处理恰好是嵌入式工程师的护城河。同样一个需求普通AI用户的流程是让AI改代码 → 烧录 → 不行再让AI改而我的流程是需求拆解 → CubeMX定型 → AI生成逻辑 → 桌面推演 → 烧录验证 → 边界测试。前者运气成分大后者每一步都有确定性的验证环节。耗时上前者看起来启动快但反复烧录调试的时间会把优势全部吃掉后者看起来步骤多实际上每个步骤都有明确输出整体节奏反而是稳定的。5. 踩坑记录AI生成STM32代码的常见翻车点做AI协同开发大半年我把翻车最多的情况整理成一份清单分享出来给大家做个参考。5.1 翻车点一时钟树配置被AI带偏HAL库工程里时钟树配置代码在SystemClock_Config()函数里。AI很爱在这个函数上出错尤其是RCC_OscInitStruct里PLL倍频系数、RCC_ClkInitStruct里AHB/APB分频系数这些参数AI经常给出一套看着合理但实际跑起来就是72MHz变36MHz甚至直接Hang住的配置。我的建议是时钟树代码永不接受AI修改。CubeMX生成的时钟配置版本你怎么改都不如它直观安全。如果AI给你的代码里包含了SystemClock_Config()的完整实现直接删除它保留CubeMX生成的版本。5.2 翻车点二HAL库句柄的生命周期这个坑我前面案例里已经踩过一次这里再单独强调一遍。AI喜欢在函数内部定义TIM_HandleTypeDef、UART_HandleTypeDef这类句柄变量用完就丢。这在简单场景里没问题因为HAL库初始化时会把句柄内容复制到内部的CORE数组里。但如果你后续的代码还要复用这个句柄比如查询状态、修改参数就必须用CubeMX生成的全局句柄或者自己定义全局句柄。判断标准很简单如果这个外设只在初始化函数里用到一次局部句柄可以接受如果后续有任何函数要继续操作这个外设一律使用全局句柄。5.3 翻车点三中断服务函数的位置AI生成代码时经常省略这段代码应该放哪个文件哪一段的信息。它给了你HAL_TIM_PeriodElapsedCallback的函数体但没说这个函数在HAL库里已经有__Weak弱定义你在任意.c文件里定义一个同名函数就能覆盖它。我见过不少同事把中断回调函数写在初始化外设的模块文件里功能正常也有人把它硬塞进main.c也没问题。但如果main.c本身没有加分号导致编译错乱AI是看不见的。所以我的建议是让AI代码保持文件独立新建一个app_timer.c专门放回调逻辑不要和主程序杂糅在一起。关于中断的另一个常见问题是AI给的代码里总是忘记提这个回调函数的调用者是哪个中断。比如TIM2的更新中断回调它不仅是TIM2触发TIM3的更新中断也会共用HAL_TIM_PeriodElapsedCallback。如果芯片里同时用了多个定时器回调函数里必须加一个if (htim-Instance ! TIM2) return;这样的前置判断。AI生成的代码十有八九不会自带这个判断你得自己补上。5.4 翻车点四编译报错信息里的假线索AI分析编译报错时有一种情况特别迷惑它会把报告的第某行错误当作唯一的线索然后围绕那行代码给出大段分析。但实际上很多编译错误是由于头文件冲突或者宏定义不匹配引起的报错行只是受害现场不是案发现场。比如有一次我明明已经#include stm32f1xx_hal.h但编译却说GPIO_PIN_5未定义。AI分析半天说可能头文件路径不对让我检查include路径。其实真正的原因是我在main.h里重复定义了一个叫GPIO_PIN_5的宏把HAL库的宏给覆盖了。这种项目特有的坑AI不知道上下文再分析也是隔靴搔痒。所以遇到编译报错我建议你先自己看完整报错信息——尤其是编译器实际在哪个文件哪一行报错——把这段原样发给AI而不是只发一句我的代码编译错了。信息越完整AI的定位越准。5.5 如何让AI避开这些坑一个非常有效的技巧在对话开始就把避坑规则写进提示词里。比如我的通用提示词模板里就有这样一段请注意不需要修改时钟树配置不要使用局部句柄配置全局外设中断服务函数统一放在app_it.c中所有回调函数内需要先判断外设实例来源。请严格按照这些规则生成代码。实测效果立竿见影。AI不是不知道这些规则而是默认情况下不会主动遵守它倾向于在最省事的路径上生成答案。你在提示词里把约束条件列清楚就等于给它套上了缰绳。6. 进阶技巧如何让AI成为你的芯片手册翻译官和调试伙伴前面讲的都是AI生成代码的场景其实AI在嵌入式开发里的价值远不止于此。我最近用得越来越顺手的是另外两个角色手册翻译和调试辅助。6.1 让AI帮你读数据手册STM32芯片手册动辄上千页纯英文。我以前遇到不熟悉的寄存器或者外设功能都要花大半天去翻手册、找例程、看论坛。现在我的做法是直接把手册中的相关章节页面摘录文字版让AI帮我提炼关键信息。比如我最近用到一个不那么常用的外设——高级定时器TIM1的互补PWM输出和死区插入功能。我直接把手册里关于死区配置的寄存器描述和相关配置代码片段发给AI问它我要生成2us死区时间且输出极性为高有效应该如何配置寄存器AI几分钟内就给出一段带详细注释的代码比我以前翻手册快了一个量级。需要注意的是AI说根据手册描述时不要完全信任它的归纳。我一般会让它同时给出寄存器原始描述中提到的那句话然后我再对照手册原文确认。这样既快又不失准确性。6.2 把运行现象描述给AI让它给排查建议硬件调试时有时候问题看起来很诡异——板子重启后大概率正常偶尔起不来串口中断接收数据偶尔丢字节电机一启动ADC采到的数据就出现周期性抖动。这种软硬件交叉的问题AI也能帮上忙。我通常会把以下内容打包发给AI芯片型号、主频、关键外设配置具体现象正常时什么样、异常时什么样已做的排查改过什么、测过什么相关代码片段只贴关键部分不要贴整个工程AI会基于自己的知识库给出可能的排查方向。这些方向不一定每条都命中但往往会包含你还没想到但确实值得检查的盲区。比如之前遇到过的一个I2C死锁问题AI给出的排查建议里有检查SDA/SCL是否被拉低超过一定时间导致总线锁定这个思路我一开始完全没想到实际测了一下发现正是这个原因——总线被一个外部上拉不足的设备拉死了。6.3 让AI帮你重构老代码嵌入式项目常常是能用就行积累几年的工程代码读起来很痛苦。这种场景我用AI做渐进式重构效果比人肉重构稳得多。我的做法是把某个模块的函数列表和每个函数的作用用文字描述给AI让它生成一个结构更清晰、命名更规范的版本。然后我对比新旧代码行为逐函数替换。注意这里是逐函数替换不是整体替换。整体替换的风险太大尤其当函数之间存在隐式依赖时。用这个方法我把一个历史项目里的一个800行散装C文件拆成了四个职责清晰的模块文件编译零报错功能测试也全部通过。整个过程大概用了半天时间比纯手工维护高效很多。7. 我总结的一套AI协同开发STM32的最终工作流最后把这些经验整合成一套我自己现在每天都在用的标准工作流给大家一个可以直接落地的参考。第一步固化硬件上下文。把芯片型号、主频、晶振、引脚分配、HAL版本、编译环境整理成一份文档每次新对话时粘贴。这是所有步骤里性价比最高的一个。第二步CubeMX先行。所有外设初始化、时钟树、引脚复用一律在CubeMX里配置好生成工程骨架。这个步骤不允许AI参与。第三步需求拆解再拆解。把每个功能需求拆成输入、处理、输出三个要素明确参数和边界条件。拆解结果以文字形式记录既作为后续提示词的素材也作为验证标准。第四步方案对话。先让AI描述实现思路确认无重大漏洞后再进入代码生成环节。第五步代码生成与桌面推演。一次生成一个模块AI给出代码后我亲自推演关键路径外设句柄是否有效、中断回调是否被正确调用、参数边界是否覆盖到。推演通过后再编译烧录。第六步硬件验证三件套。功能验证、边界验证、稳定性验证。任何一个环节出问题把现象和代码发给AI分析但根因确认和修复方案必须由人来拍板。第七步Git提交归档。每个功能模块验证通过后立即提交到Gitcommit message写清楚改动内容和验证情况。后面如果AI引入新问题随时回滚。这套流程跑下来我最大的感触是AI协同开发不是AI取代人而是AI放大人。它把重复性劳动压缩掉之后人的精力可以集中到真正需要判断力的地方——硬件适配、边界处理、异常排查、性能优化。如果你现在还在拿到需求就让AI直接生成整个工程的阶段听我一句劝退一步先把这个流程建立起来。刚开始可能觉得步骤繁琐但跑完三五个模块之后你会明显感觉到节奏变得从容了。AI生成代码的速度永远比你审查代码的速度快与其让它一次性生成一大堆再返工不如让它一块块生成你一块块确认稳扎稳打地推进。我在实际使用中还发现一个小技巧每次AI给的代码如果有值得保留的写法我会专门存到一个prompt片段库里下次遇到类似需求时直接把这段代码作为参考示例贴给AI让它模仿风格而不是重新发明。这样迭代几轮之后AI生成代码的性格会越来越贴近你自己的书写习惯后续维护成本会进一步降低。这个经验对长期做同一个平台产品的人来说尤其有价值。