嵌入式软件工程师和AI结对写代码这件事真正上手之后你会发现最难的既不是配环境也不是写提示词而是怎么让AI理解一个它根本看不见的硬件世界。前两篇里我们已经把工具链搭起来了也跑通了第一个最简单的代码生成闭环。到了这第三个项目情况开始变得有意思了——我们要让AI参与一个带中断、带寄存器操作、带时序约束的完整功能模块开发。这跟让它写个排序算法完全是两码事。如果你也是做嵌入式出身想搞清楚AI协同开发到底能帮到什么程度、哪些环节必须自己兜底那这篇内容应该能给你一些实在的参考。1. 为什么第三个项目才是真正的分水岭1.1 前两个项目为什么太顺了回顾一下前两个项目做了什么。第一个项目基本就是让AI帮忙生成一个GPIO点灯的初始化代码第二个项目稍微复杂一点是一个串口收发的基础框架。这两个项目的共同特点是逻辑自包含、硬件依赖浅、验证路径短。AI在这类任务上表现确实不错因为训练数据里有大量类似的代码模式它本质上是在做高质量的模式匹配参数填充。但这里有个容易被忽略的问题前两个项目跑通之后很多人会产生一种错觉觉得AI已经懂嵌入式了。实际上它懂的只是代码的语法结构和常见写法它对时序、电气特性、中断优先级、寄存器副作用这些东西没有任何直觉。你让它写一个延时函数它会给你一个for循环空转至于这个循环在72MHz主频下到底延时多少微秒它算得对不对完全取决于你有没有把编译器优化等级、流水线行为这些信息告诉它。所以前两个项目更像是热身让你熟悉工具的操作方式和人机交互的节奏。真正考验协同开发能力的是当需求开始涉及硬件行为约束的时候。1.2 第三个项目的需求长什么样这个项目的目标是实现一个基于定时器中断的按键消抖与长短按识别模块。听起来不复杂对吧但拆开来看它涉及的东西一点都不少定时器配置需要精确的定时周期中断服务函数的编写要求执行时间尽可能短按键状态机的设计要区分短按、长按、双击消抖逻辑要处理机械按键的抖动特性与主循环的数据交互涉及volatile变量和临界区保护我选择这个需求作为第三个项目恰恰是因为它处在一个AI能帮上大忙但又不能完全放手的甜蜜点上。状态机的逻辑框架、代码结构的组织、注释的编写这些AI做得很好但定时器分频系数的计算、中断优先级的安排、volatile关键字的取舍这些必须由人来把关。1.3 协同开发的分工边界在哪里经过这个项目的完整实践我总结出一条比较清晰的分工线工作内容适合AI主导需要人工把关状态机框架搭建是否寄存器配置代码部分是时序参数计算否是中断服务函数结构是部分临界区保护部分是注释与文档是否边界条件处理部分是这张表不是绝对的但大方向就是这样。AI擅长的是结构和模式人擅长的是约束和权衡。你把约束条件喂给AI它能给你一个结构漂亮的实现但约束条件本身对不对、全不全得你自己想清楚。2. 把硬件约束翻译成AI能吃的提示词2.1 为什么直接描述需求AI会翻车我一开始的做法很直接就跟AI说帮我写一个按键消抖程序用定时器中断实现支持短按和长按。结果它给我的代码是这样的void TIM3_IRQHandler(void) { if (TIM_GetITStatus(TIM3, TIM_IT_Update) ! RESET) { TIM_ClearITPendingBit(TIM3, TIM_IT_Update); if (GPIO_ReadInputDataBit(GPIOA, GPIO_Pin_0) 0) { key_count; if (key_count 200) { key_long_press 1; } } else { if (key_count 5 key_count 200) { key_short_press 1; } key_count 0; } } }这段代码逻辑上能跑但问题一大堆。首先它没有做真正的消抖只是在计数其次它把按键判断直接放在中断里如果按键抖动导致频繁进中断CPU会被拖垮再者它没有处理按键释放的边沿检测长按判断的阈值也是拍脑袋定的。这就是典型的AI不懂硬件约束的翻车现场。它给你的是一段看起来合理的代码但放在真实的嵌入式环境里处处是坑。2.2 提示词里必须包含的五类信息后来我调整了策略在提示词里系统性地补充了五类信息效果立刻不一样了第一类硬件平台信息。具体到MCU型号、主频、定时器时钟源。比如STM32F103系统时钟72MHzTIM3挂载在APB1总线上时钟为36MHz。这些信息决定了分频系数和重装载值怎么算。第二类时序约束。定时器中断周期要求是多少按键消抖时间窗口是多少长按判定阈值是多少。比如中断周期1ms消抖窗口20ms长按阈值1秒。第三类电气特性。按键是上拉还是下拉按下时电平是高还是低有没有外部硬件消抖电路。这些决定了边沿检测的逻辑方向。第四类系统约束。中断服务函数的执行时间上限是否有其他中断会抢占主循环的实时性要求。这些决定了代码结构的取舍。第五类代码风格要求。用不用HAL库变量命名规范是否要求可重入要不要加详细注释。把这五类信息组织成一段结构化的提示词AI的输出质量会有质的飞跃。我实际用的提示词大概长这样平台STM32F103C8T6系统时钟72MHzTIM3时钟36MHz 需求基于TIM3定时器中断实现按键消抖与长短按识别 时序中断周期1ms消抖窗口20ms长按阈值1000ms 硬件按键接PA0内部上拉按下为低电平 约束中断服务函数执行时间不超过10us主循环通过标志位读取按键事件 风格使用标准外设库变量加模块前缀key_关键逻辑加注释2.3 一个反直觉的经验约束要给死很多人写提示词喜欢留余地说大概1ms左右就行、消抖时间你看着办。这在嵌入式场景里是大忌。AI对模糊描述的处理方式是取一个它见过的常见值而不是帮你分析最优值。你说看着办它就真的随便给你一个数而且不会告诉你为什么选这个数。正确的做法是把约束给死哪怕这个值是你暂时拍脑袋定的也要明确写出来。因为一旦写死了AI就会围绕这个确定的值去推导其他参数比如分频系数、重装载值、计数阈值。这些推导过程它做得很好前提是你给了它一个确定的起点。如果某个参数你确实不确定那就分两步走先让AI帮你分析这个参数的影响因素和取值范围你拍板之后再让它基于确定值生成代码。不要指望它一步到位。3. 定时器参数计算AI算得对但你得会验3.1 分频系数和重装载值的推导过程这是这个项目里最典型的AI能算但你要会验的环节。我把平台信息给AI之后它给出的计算过程是这样的TIM3挂载在APB1总线上APB1预分频系数为2所以TIM3的时钟频率是36MHz。要得到1ms的中断周期需要让计数器每1ms溢出一次。定时器溢出周期公式T (PSC1) × (ARR1) / TIM_CLK代入已知条件0.001 (PSC1) × (ARR1) / 36000000为了让计数器在16位范围内工作先确定PSC。取PSC35则(PSC1)36此时(ARR1) 0.001 × 36000000 / 36 1000所以ARR 999。这个推导过程是对的。36MHz经过36分频变成1MHz也就是每个计数周期1微秒计数1000次正好1毫秒。PSC35、ARR999这组参数是合理的。3.2 为什么我坚持自己再算一遍即便AI算对了我还是建议你自己动手验算一遍。原因有三个第一AI可能搞错时钟树。不同型号的MCUAPB1预分频系数和定时器时钟倍频关系不一样。有些型号APB1分频系数为1时定时器时钟等于APB1时钟分频系数大于1时定时器时钟是APB1的两倍。这个规则AI不一定每次都记得准。第二计算过程可能被简化。有时候AI会跳过中间步骤直接给结果你没法判断它是不是真的算对了还是从训练数据里背了一个常见值出来。第三你需要理解参数背后的物理意义。PSC决定了计数器的刻度ARR决定了量程。理解了这个你才能在需要调整中断周期时快速重新计算而不是每次都去问AI。我自己的验算习惯是先确认定时器时钟频率然后反推。要1ms中断如果PSC136那ARR1必须是1000因为36×100036000而36000000/360001000Hz周期正好1ms。这个反推过程比正推更快也更不容易出错。3.3 中断周期选择的权衡1ms的中断周期不是随便定的。这里有个权衡中断周期太短比如100微秒CPU会频繁进出中断上下文切换的开销占比过高影响主循环的执行。而且按键消抖根本不需要这么高的采样率。中断周期太长比如10ms消抖窗口20ms就只能采样两次判断不够可靠。而且长按判定的精度会下降1秒的长按阈值误差可能达到10ms。1ms是一个比较折中的选择消抖窗口20ms对应20次采样足够可靠长按阈值1000ms对应1000次计数精度1ms中断开销在可接受范围内。这个权衡过程AI不会主动帮你做它只会按你给的周期去算参数。所以中断周期的选择必须由人来决策这是系统级的设计问题不是代码生成问题。4. 状态机设计AI的高光时刻与暗坑4.1 让AI生成状态机框架的正确姿势状态机设计是AI表现最好的环节。我把按键的几种状态和转换条件描述清楚之后它给出的状态机框架相当规整typedef enum { KEY_STATE_IDLE 0, // 空闲等待按下 KEY_STATE_DEBOUNCE, // 消抖确认中 KEY_STATE_PRESSED, // 已确认按下 KEY_STATE_LONG_PRESS, // 长按已触发 KEY_STATE_RELEASE // 等待释放确认 } key_state_t;状态划分是合理的。IDLE是初始状态检测到低电平后进入DEBOUNCE持续20ms仍然是低电平就进入PRESSED在PRESSED状态持续超过1000ms就进入LONG_PRESS检测到高电平后进入RELEASE等待确认。AI还自动补充了状态转换表把每个状态下遇到不同输入时的行为列得清清楚楚。这部分我基本没改直接用。4.2 状态机里AI容易忽略的边界情况但框架规整不代表逻辑完整。我在review的时候发现了几个AI没考虑到的情况情况一长按之后松开应该触发什么事件AI的初始版本里长按触发后松开只是回到IDLE没有产生长按释放事件。但实际应用中长按释放往往需要单独处理比如长按调节音量时松开意味着停止调节。情况二消抖过程中按键又松开了怎么办AI的版本里DEBOUNCE状态下如果检测到高电平直接回IDLE。这看起来对但如果抖动导致在20ms窗口内电平反复变化状态机会在DEBOUNCE和IDLE之间来回跳计数逻辑会乱。情况三连续快速点击怎么处理如果用户在短按之后立刻又按下状态机能不能正确识别为两次短按AI的初始版本会漏掉这种情况因为它在RELEASE状态停留时间太短。这些边界情况AI不会主动帮你考虑因为它的训练数据里大部分示例代码都是happy path只处理正常流程。边界情况的枚举必须由人来完成你可以列一个清单然后让AI逐个补充处理逻辑。4.3 用表格驱动状态转换的写法补充完边界情况之后我让AI把状态转换逻辑改成了表格驱动的写法这样可读性和可维护性都更好当前状态输入条件下一状态动作IDLE低电平DEBOUNCE清零计数器DEBOUNCE低电平且计数20DEBOUNCE计数1DEBOUNCE低电平且计数≥20PRESSED记录按下时刻DEBOUNCE高电平IDLE清零计数器PRESSED低电平且持续1000msPRESSED无PRESSED低电平且持续≥1000msLONG_PRESS触发长按事件PRESSED高电平RELEASE触发短按事件LONG_PRESS低电平LONG_PRESS无LONG_PRESS高电平RELEASE触发长按释放事件RELEASE高电平且计数20RELEASE计数1RELEASE高电平且计数≥20IDLE清零计数器RELEASE低电平DEBOUNCE清零计数器这张表是AI根据我的描述生成的我只做了少量修正。表格驱动的好处是状态转换逻辑一目了然后续要加新状态或者改转换条件改表格比改if-else清晰得多。5. 中断服务函数的瘦身与临界区保护5.1 中断里到底该放多少逻辑这是嵌入式开发的一个经典话题在AI协同开发场景下尤其重要。AI生成的初始版本把整个状态机都塞进了中断服务函数里。逻辑上没错但违反了中断要短的原则。我的处理方式是中断里只做最必要的操作状态机的复杂判断放到主循环里。具体来说中断服务函数只负责三件事清除中断标志采样按键电平存入一个volatile变量递增一个毫秒计数器状态机的状态转换、消抖判断、长短按识别全部放到主循环里基于中断采样的数据来处理。这样中断服务函数的执行时间可以控制在几微秒以内。我把这个思路告诉AI之后它很快给出了重构后的代码。中断服务函数变得非常简洁void TIM3_IRQHandler(void) { if (TIM_GetITStatus(TIM3, TIM_IT_Update) ! RESET) { TIM_ClearITPendingBit(TIM3, TIM_IT_Update); key_raw_level GPIO_ReadInputDataBit(GPIOA, GPIO_Pin_0); key_tick; } }主循环里再基于key_raw_level和key_tick做状态机处理。这个分工是合理的也是嵌入式开发里常见的做法。5.2 volatile关键字AI有时会忘有时会多volatile是嵌入式开发里绕不开的关键字AI对它的处理时好时坏。在这个项目里key_raw_level和key_tick这两个变量在中断里被修改、在主循环里被读取必须加volatile。AI这次记得加了但在另一个地方它又加多了——它给状态机的状态变量也加了volatile而那个变量只在主循环里访问加volatile是多余的还会阻止编译器优化。我的经验是判断一个变量要不要加volatile就看它是否可能被意料之外的执行流修改。中断服务函数、DMA、多线程这些都是意料之外的执行流。只在主循环里访问的变量不需要volatile。这个判断逻辑你可以教给AI在提示词里明确说明哪些变量会被中断访问让它只给这些变量加volatile。但最终还是要自己过一遍因为AI有时候会过度保护。5.3 多字节变量的原子性问题key_tick是一个32位的计数器在中断里递增在主循环里读取。在32位MCU上32位变量的读写通常是原子的但这不是绝对的。如果编译器生成的代码需要多条指令来完成读写就可能出现读到半更新值的情况。这个问题AI基本不会主动提。我在review的时候想到了让AI分析了一下。它的结论是在Cortex-M3内核上对齐的32位变量读写是单指令操作是原子的不需要额外保护。这个结论是对的但前提是变量地址对齐。如果key_tick是16位或者8位情况又不一样。而且如果主循环里需要读取key_tick并基于它做判断最好还是用临界区保护一下或者读取到一个局部变量再使用避免在判断过程中值被中断修改。提示涉及中断与主循环共享的变量除了加volatile还要考虑原子性。32位对齐变量在Cortex-M内核上通常是安全的但养成读一次存局部变量的习惯总没错。6. 实测中暴露的三个问题及修复过程6.1 问题一按键响应偶尔卡死代码烧进去之后大部分时候工作正常但偶尔会出现按键没反应的情况要等好几秒才恢复。这个问题不是必现的大概按几十次会出现一次。排查过程是这样的首先怀疑是中断没进用示波器测了定时器中断的引脚翻转发现中断一直在正常进。然后怀疑是状态机卡在某个状态出不来加了一个调试变量记录当前状态发现卡在DEBOUNCE状态。DEBOUNCE状态的退出条件是计数达到20或者检测到高电平。卡在这里说明计数没有正常递增。检查计数逻辑发现计数变量是在主循环里递增的而主循环里还有其他任务如果其他任务执行时间过长计数递增的节奏就会被打乱。根本原因是我把消抖计数放在了主循环里但主循环的执行周期不固定。中断是1ms一次但主循环可能几毫秒才跑一圈导致消抖计数的时间基准不准。修复方案是把消抖计数也放到中断里或者用key_tick的差值来计算消抖时间而不是用计数次数。我选择了后者因为这样中断服务函数还是保持简洁。修改后的消抖判断变成记录进入DEBOUNCE状态时的key_tick值每次主循环检查时用当前key_tick减去记录值超过20就认为消抖完成。这个问题的教训是任何依赖次数的计时逻辑都要确认计数的节奏是否稳定。如果计数发生在主循环里而主循环周期不固定计数就不能代表时间。6.2 问题二长按阈值不准长按阈值设定的是1000ms但实测下来有时候800多毫秒就触发了有时候1100毫秒才触发。误差超过了可接受范围。这个问题的根源和上面类似也是计时基准的问题。AI最初生成的代码里长按判断用的是进入PRESSED状态后经过了多少次主循环而不是经过了多少毫秒。主循环周期不稳定导致长按判断的时间不准。修复方案同样是改用key_tick的差值来判断。记录进入PRESSED状态时的key_tick值每次检查时用当前值减去记录值超过1000就触发长按。这样时间基准就是定时器中断的1ms准确得多。修复之后实测长按触发的误差在±2ms以内完全满足要求。6.3 问题三双击被识别成两次短按这个其实不算bug因为需求里没有明确要求支持双击。但测试的时候发现快速双击会触发两次短按事件如果上层逻辑对短按的处理是切换开关状态那双击就会导致状态切换两次等于没切换。解决这个问题有两个方向一是增加双击识别逻辑在短按之后等待一段时间如果期间又有按下就判定为双击二是要求上层逻辑自己做去重处理。我选择了第一个方向让AI在状态机里增加了DOUBLE_CLICK相关的状态。增加的逻辑是短按触发后不立即上报事件而是进入一个等待窗口比如300ms如果窗口内没有再次按下才上报短按事件如果窗口内有按下则上报双击事件。这个改动让状态机复杂了不少但AI处理得很好。它自动调整了状态转换表补充了新的状态和转换条件。这也说明只要需求描述清楚AI处理复杂状态机的能力是够用的。7. 这个项目跑通之后的一些体会7.1 AI协同开发的效率提升到底有多少客观地说这个项目如果完全手写我大概需要一天半的时间。用AI协同实际花了大概半天。效率提升是明显的但提升主要来自几个特定环节代码框架搭建、状态机结构设计、注释编写、边界情况的代码实现这些环节AI帮了大忙。但需求分析、参数计算验证、问题排查、硬件调试这些环节AI基本帮不上忙还是得自己来。所以整体效率提升大概在40%到50%之间没有想象中那么夸张。AI是加速器不是替代品。它加速的是把想法变成代码的过程但想清楚要做什么和验证做得对不对这两头还是得人来。7.2 哪些能力在AI时代反而更重要了这个项目让我意识到有几项能力在AI协同开发场景下变得比以前更重要第一是需求拆解能力。你得能把一个模糊的需求拆成AI能理解的、结构化的约束条件。拆得越细AI的输出越靠谱。第二是代码审查能力。AI生成的代码看起来往往很顺眼但顺眼不等于正确。你得有能力快速识别出哪里可能有问题尤其是那些AI容易忽略的边界情况。第三是硬件直觉。对时序、电气特性、中断行为的直觉这些是AI给不了你的。你越懂硬件越能判断AI的输出是否合理。第四是调试能力。AI生成的代码出了问题它自己不会调试。排查问题的思路、定位问题的手段这些还是得靠人。7.3 关于提示词的一点心得最后分享一个关于提示词的心得。我发现把约束条件写成检查清单的形式比写成段落描述效果更好。比如不要写中断要尽量短不要放太多逻辑而是写中断服务函数执行时间不超过10us只允许包含清标志、采样、计数三个操作。清单式的提示词有两个好处一是AI更容易解析输出更精准二是你自己在写清单的时候也会被迫把需求想得更清楚。很多时候写提示词的过程本身就是一次需求梳理。另外提示词不是一次性的。第一轮生成之后根据输出质量调整提示词再生成一轮往往比在第一轮结果上修修补补更高效。我一般会预留两到三轮的迭代空间第一轮看结构第二轮补细节第三轮做优化。这个按键消抖模块现在已经稳定运行在我的一个测试板上了连续跑了一周没有出现异常。下一步我打算把这个协同开发的流程用到更复杂的项目上比如带DMA的数据采集模块到时候再分享新的踩坑经验。