1. 当我把嵌入式框架的键盘交给 AI 之后嵌入式开发有个老生常谈的尴尬代码量不大但每一行都长在硬件上牵一发动全身。一个跑了三年的老框架里面塞满了各种历史补丁、寄存器魔数、状态机分支想重构又不敢动因为一动就可能炸出一堆时序问题。我这次做的事情就是把这个不敢动的框架交给 AI 去重构自己几乎没手写一行代码。先说清楚这个框架是什么。它是一个典型的裸机嵌入式框架跑在一颗 Cortex-M 系列的 MCU 上核心模块包括一个基于时间片的任务调度器、一套环形缓冲区驱动、一个状态机引擎、以及若干外设的抽象层。代码总量大概在八千行左右C 语言写的风格是那种能跑就行的祖传风格——全局变量满天飞函数职责不清注释和代码对不上。这套东西稳定运行了很久但每次加新功能都像在雷区里跳舞。我为什么要让 AI 来重构它原因很直接我自己重构过两次两次都中途放弃。第一次重构到一半发现调度器和缓冲区之间有隐式耦合改了一处崩了三处第二次重构引入了新的抽象层结果中断响应时间从 2 微秒涨到了 8 微秒实时性直接不达标。手工重构的成本太高而且人的思维容易被现有代码结构绑架很难跳出原来的框。这次我换了个思路把重构拆成AI 能理解的任务让 AI 去执行我只做架构决策和验收。整个过程下来我真正手写的代码不超过五十行其余全部由 AI 生成我再逐块审查和微调。这篇文章就把这套方法完整拆开讲包括我怎么给 AI 描述需求、怎么切分任务、怎么验证 AI 的输出、以及踩过的那些坑。适合读这篇的人手上有历史遗留嵌入式代码、想重构又不敢动的开发者对 AI 辅助编程感兴趣但不知道怎么用在底层开发上的人以及任何想了解人机协作重构这套工作流的人。不需要你是 AI 专家但需要你对 C 语言和嵌入式基础有基本概念。2. 为什么嵌入式框架的重构比普通业务代码更难2.1 硬件耦合让等价重构变成伪命题普通业务代码重构核心目标是行为等价——输入一样输出一样内部结构随便改。但嵌入式框架不一样它的行为不只是逻辑输出还包括时序、内存占用、中断延迟、功耗表现。你把一个函数拆成两个逻辑上完全等价但多了一次函数调用栈深度变了中断里的执行时间就可能超标。我在这次重构里遇到的最典型问题就是调度器的 tick 处理函数。原来的写法是一个大函数里面顺序处理所有任务的时间片递减和就绪判断。AI 第一次重构时很自然地把它拆成了遍历任务列表和判断任务就绪两个函数逻辑上完全正确。但实测下来tick 中断的处理时间从 1.8 微秒涨到了 3.2 微秒因为多了一层函数调用和参数传递。对于 72MHz 的主频来说这多出来的 1.4 微秒意味着每个 tick 多消耗约 100 个时钟周期在高频 tick 场景下会明显影响其他中断的响应。所以嵌入式重构的第一条铁律是逻辑等价不等于系统等价。你必须在重构前就明确哪些指标是不能退化的然后把这些指标作为验收标准交给 AI。我当时的做法是列了一张不可退化清单指标原值允许偏差测量方式tick 中断处理时间1.8us10%示波器翻转 IO最大栈深度512B不增加栈填充法测量静态 RAM 占用4.2KB不增加map 文件任务切换延迟3.5us15%逻辑分析仪这张表后来成了我审查 AI 输出的核心依据。每次 AI 给出一版重构代码我都先跑一遍这几个指标不达标就直接打回根本不看逻辑对不对。这个顺序很重要——先过性能关再过逻辑关能省掉大量无效审查。2.2 祖传代码里的隐式契约AI 看不见老框架里最坑的东西是那些没有写在任何地方的隐式契约。比如某个全局变量g_sys_tick表面上只是个计数器但实际上中断里会读它、主循环会写它、某个外设驱动会在特定条件下清零它。这种跨模块的隐式依赖代码里没有任何注释说明AI 读代码时也看不出来因为它是运行时才成立的约束。我踩的第一个大坑就在这里。AI 重构缓冲区模块时把g_sys_tick的读写全部收敛到了一个 getter 函数里看起来更规范了。但那个外设驱动里的清零操作被 AI 判定为可疑的写操作直接删掉了。结果就是系统跑几个小时后tick 计数器溢出任务调度彻底乱套。这个 bug 极其隐蔽因为前几个小时完全正常。后来我总结出一个方法在让 AI 重构之前先把所有隐式契约显式化。具体做法是我自己花时间把代码里所有全局变量的读写点全部列出来标注每个读写点的意图形成一份契约清单然后把这份清单作为上下文一起交给 AI。这份清单不需要很正式用注释形式贴在代码旁边就行但它是 AI 理解代码真实意图的关键输入。提示隐式契约的挖掘没有捷径只能靠人。AI 能帮你分析代码结构但这个变量为什么在这里被清零这种问题只有写过这段代码的人或者深入调试过的人才知道。重构前花在契约梳理上的时间会在重构后成倍省回来。2.3 没有测试框架AI 的输出无法自动验证业务代码重构有单元测试兜底跑一遍测试就知道有没有改坏。但嵌入式框架通常没有测试框架验证全靠上板实测。这就带来一个问题AI 生成代码很快但你验证的速度跟不上重构效率反而下降。我这次的做法是在重构开始之前先花半天时间搭了一个最小化的验证环境。不是完整的单元测试框架而是几个针对性的验证手段PC 端仿真验证把不依赖硬件的纯逻辑模块比如状态机、环形缓冲区抽出来在 PC 上用 gcc 编译写几个测试用例跑一遍。这部分能覆盖大约 40% 的代码。板上 IO 翻转验证在关键路径的首尾加 IO 翻转用示波器测时间。这部分覆盖时序相关的模块。内存填充验证在栈和堆区域填充特定模式运行一段时间后检查填充被破坏的程度测出实际栈深度。长时间运行验证让系统连续跑 24 小时观察是否有计数器溢出、内存泄漏等问题。这套验证环境搭起来花了半天但后面每次审查 AI 输出时我都能在几分钟内得到反馈整体效率提升非常明显。没有这套东西AI 重构就是生成快、验证慢最后变成瓶颈。3. 把重构任务拆成 AI 能接住的粒度3.1 任务拆分的三个层次模块级、函数级、语句级直接跟 AI 说帮我重构这个框架结果一定是灾难。AI 会给你一版看起来很美但完全跑不起来的代码。正确的做法是把重构拆成不同粒度的任务不同粒度用不同的交互方式。我的拆分是这样的模块级任务比如把环形缓冲区模块重写为无锁版本。这种任务 AI 一次性完成的质量很差因为涉及太多设计决策。我的做法是模块级任务只让 AI 做方案设计不写代码。我会让 AI 输出三套方案每套方案说明数据结构、关键操作、优缺点然后我来选。选定方案后再进入函数级。函数级任务比如实现环形缓冲区的写入函数要求无锁、支持单生产者单消费者。这种粒度 AI 完成得最好因为输入输出明确约束清晰。我会把函数签名、参数含义、返回值约定、性能要求全部写清楚AI 生成的代码通常一次就能用。语句级任务比如把这个 if-else 链改成查表实现。这种任务其实不太需要 AI因为改动太小自己写更快。我一般只在遇到特别绕的逻辑时才用 AI比如复杂的位运算或者状态机跳转表。实际执行下来函数级任务是性价比最高的。模块级太粗AI 容易跑偏语句级太细沟通成本高于收益。函数级刚好卡在AI 能理解完整意图和人能把控质量的平衡点上。3.2 给 AI 写重构需求说明书的模板我发现一个规律AI 重构的质量八成取决于你怎么描述需求。描述得越像一份正式的接口文档输出质量越高。我后来固定用一套模板来写需求效果很稳定。模板包含六个部分背景这个模块是干什么的在系统里的位置被谁调用。现状问题为什么要重构现在有什么具体问题越具体越好比如当前实现在中断里调用了 malloc有重入风险。目标重构后要达到什么状态包括功能目标和性能目标。约束不能改变什么比如函数签名不能变因为有三个调用方、不能引入动态内存分配。接口约定输入输出的格式、边界条件、错误处理方式。验收标准怎么判断重构成功包括功能验证和性能验证。举个例子我重构状态机引擎时的需求描述是这样的背景状态机引擎负责管理设备的工作模式切换当前支持 8 个状态、20 条转移。 现状问题转移表用嵌套 switch 实现新增状态需要改三处代码容易漏改。 目标改为表驱动实现新增状态只需改一处。 约束状态转移的执行时间不能超过 5us不能增加静态 RAM 占用超过 64B。 接口约定保持原有的 state_machine_run() 签名不变。 验收标准8 个状态的所有转移路径实测正确转移执行时间实测 5us。这份描述大概两百字但信息密度很高。AI 拿到之后生成的表驱动实现基本一次到位我只改了两个边界条件的判断。3.3 上下文怎么给全量代码还是按需投喂这是很多人纠结的问题。我的经验是不要一次性把整个框架丢给 AI。原因有两个一是上下文太长AI 的注意力会被稀释容易忽略关键约束二是全量代码里有很多与当前任务无关的部分会干扰 AI 的判断。我的做法是按需投喂 依赖闭包。具体来说重构某个函数时我给它这几样东西这个函数的完整代码这个函数直接调用的其他函数的签名和简要说明这个函数被谁调用调用点的代码片段相关的全局变量定义和契约说明上面说的需求说明书这样一份上下文通常在几百行以内AI 能完整消化。如果某个函数依赖特别复杂我会先把它依赖的部分也重构掉形成自底向上的重构顺序。这样每一步的上下文都是干净的。注意按需投喂的前提是你自己对代码的依赖关系很清楚。如果你自己都不清楚某个函数被谁调用那说明这个框架的耦合已经到了必须重构的程度但同时也意味着你需要先花时间做依赖分析而不是急着让 AI 动手。4. 实战调度器模块的 AI 重构全过程4.1 重构前的调度器长什么样原来的调度器是一个基于时间片的设计核心结构是一个任务数组每个任务有周期、剩余时间片、执行函数三个字段。tick 中断里遍历数组递减剩余时间片减到零就标记任务就绪。主循环里检查就绪标志执行对应函数。代码大概长这样简化版typedef struct { uint16_t period; uint16_t remain; void (*func)(void); uint8_t ready; } task_t; task_t g_tasks[MAX_TASKS]; uint8_t g_task_count 0; void scheduler_tick(void) { for (uint8_t i 0; i g_task_count; i) { if (g_tasks[i].remain 0) { g_tasks[i].remain--; if (g_tasks[i].remain 0) { g_tasks[i].ready 1; g_tasks[i].remain g_tasks[i].period; } } } } void scheduler_run(void) { for (uint8_t i 0; i g_task_count; i) { if (g_tasks[i].ready) { g_tasks[i].ready 0; g_tasks[i].func(); } } }这段代码的问题很明显任务数量固定、没有优先级、tick 里遍历所有任务效率低、ready 标志的读写没有保护。但它跑了很久没出问题因为任务数量少、周期长实际负载很轻。4.2 我给 AI 的重构需求与约束我的重构目标不是推倒重来而是解决三个具体问题支持动态添加任务、支持优先级、降低 tick 开销。需求说明书如下背景调度器是系统的核心负责按周期调度所有任务。当前实现见附件代码。 现状问题 1. 任务数量编译期固定新增任务要改宏定义并重新编译。 2. 无优先级所有任务平等高实时任务可能被低实时任务阻塞。 3. tick 里遍历全部任务任务多时开销线性增长。 目标 1. 支持运行时动态添加任务最多 16 个。 2. 支持 4 级优先级高优先级任务优先执行。 3. tick 开销与就绪任务数相关而非总任务数。 约束 1. tick 中断处理时间不超过 2us原 1.8us。 2. 不引入动态内存分配任务数组静态分配。 3. 保持 scheduler_tick 和 scheduler_run 的调用方式不变。 接口约定 新增 task_add(period, priority, func) 接口返回任务 ID 或 -1。 验收标准 1. 动态添加 16 个任务后系统正常运行。 2. 高优先级任务在低优先级任务之前执行。 3. tick 时间实测 2us。这份需求里最关键的是tick 开销与就绪任务数相关这一条。它直接决定了数据结构的选择——不能用简单的数组遍历得用就绪链表或者位图。AI 拿到这个约束后选择了位图方案我觉得合理。4.3 AI 给出的三版方案与我的取舍AI 第一轮给了三套方案我简单说一下和我的判断方案 A就绪位图 优先级位图。用一个 16 位的就绪位图标记哪些任务就绪再用 4 个位标记哪些优先级有就绪任务。tick 里只更新位图不遍历任务。主循环里用位扫描指令CLZ快速找到最高优先级就绪任务。优点是 tick 开销恒定与任务数无关缺点是需要位操作代码可读性稍差。方案 B多级就绪链表。每个优先级一个链表任务就绪时挂到对应链表。tick 里只操作链表头。优点是逻辑直观缺点是链表操作在中断里做有指针操作风险稍高。方案 C时间轮。用时间轮管理周期任务tick 只推进轮指针。优点是 tick 开销极低缺点是实现复杂且对非周期任务支持不好。我选了方案 A。理由是位图方案在中断里只做位设置没有指针操作最安全位扫描指令在 Cortex-M 上是单周期指令效率最高代码虽然用了位操作但逻辑其实很清晰加好注释就行。方案 B 的链表操作在中断里有风险方案 C 对现有任务模型改动太大。这个取舍过程我没有让 AI 参与因为这是架构决策需要人对系统有整体判断。AI 适合给方案不适合做决策。4.4 代码生成后的逐块审查与微调AI 按方案 A 生成的代码大概两百行我逐块审查了一遍。审查的重点不是逻辑对不对逻辑 AI 基本不会错而是这几个方面第一中断安全。tick 里对位图的写操作和主循环里对位图的读操作会不会有竞争AI 的代码里tick 只做g_ready_bitmap | (1 id)主循环读的时候先关中断再读。这个处理是对的但我发现主循环里关中断的范围太大把任务执行也包进去了。我改成只关中断读位图读完立刻开中断任务执行在中断开启状态下进行。第二边界条件。任务 ID 是 0 到 15AI 的代码里位操作都用1 id当 id 是 15 时没问题但如果将来扩展到 32 个任务1 31在 int 上是未定义行为。我加了显式的(uint32_t)1 id强制转换避免隐患。第三性能实测。改完之后上板测 tick 时间实测 1.6us比原来的 1.8us 还快了一点。原因是原来遍历数组有循环开销现在只做位操作。这个结果符合预期。第四可读性。AI 生成的位操作代码没有注释我加了注释说明每个位图的含义。这部分我手写了几行注释算是整个重构里我唯一手写的代码。整个调度器重构从写需求到验证通过大概花了三个小时。如果手工重构我估计至少要两天而且大概率会引入新 bug。5. 那些 AI 重构翻车的瞬间和我的补救5.1 缓冲区模块AI 把无锁理解成了不用锁环形缓冲区模块的重构是我踩的最大的坑。原实现是单生产者单消费者靠读写指针的原子性天然无锁。我在需求里写了保持无锁特性AI 理解成了不需要任何同步机制于是它把原来用于内存屏障的几行代码删掉了。在 x86 上这代码可能还能跑因为 x86 的内存模型比较强。但在 Cortex-M 上编译器的指令重排和 CPU 的乱序执行虽然 M 系列乱序有限但编译器重排是真实存在的会导致读写指针更新顺序错乱缓冲区数据出现撕裂。这个 bug 在低负载下几乎不出现高负载下才偶发极其难查。我的补救方式是在需求里明确写出需要内存屏障这个约束并且把屏障的位置和原因写清楚。AI 第二次生成的代码就正确了。这件事给我的教训是AI 不懂硬件内存模型所有和硬件相关的约束都必须显式写出来不能指望 AI 自己知道。5.2 状态机模块AI 自作主张加了优化状态机模块重构时AI 在生成表驱动代码的同时自作主张加了一个优化把连续的同目标状态转移合并了。逻辑上这没错但问题是原状态机里有些转移虽然目标状态相同但转移时的副作用不同比如一个会打印日志一个不会。AI 合并之后副作用丢了。这个问题的根源是 AI 只看了状态转移表没看转移动作函数。我在需求里只描述了状态和转移关系没描述动作。补救方式是重新提交需求把每个转移的动作函数也列出来AI 就正确生成了。这件事说明AI 会做它认为合理的优化但这些优化可能破坏你的隐式语义。防御方法是在需求里明确写不要做任何未要求的优化把 AI 的自由度压到最低。5.3 外设抽象层AI 生成的寄存器操作看起来对但时序不对外设抽象层的重构最惊险。AI 把一个外设初始化序列重写了寄存器配置值都对但顺序变了。原来先配时钟再配引脚AI 改成了先配引脚再配时钟。在大多数情况下这没问题但这颗 MCU 的某个引脚在时钟未使能时配置会失败导致外设完全不工作。这个 bug 上板一测就发现了因为外设直接没反应。但如果是个更隐蔽的时序问题可能就要查很久。补救方式是在需求里明确写保持原有寄存器操作顺序并且把顺序的原因也写上。AI 之后就没再动顺序。提示外设初始化序列的顺序很多是芯片手册里明确要求的但也有一些是经验性的。让 AI 重构这部分时最安全的做法是只改结构不改顺序把顺序相关的代码原样保留只重构周边的逻辑。5.4 从翻车中提炼的 AI 重构检查清单踩了这几个坑之后我总结了一份检查清单每次审查 AI 输出时都过一遍检查项检查方法常见问题中断安全看中断和主循环共享的变量缺临界区保护、关中断范围过大内存屏障看多核或中断共享数据的读写顺序屏障被删、顺序被改隐式语义对照契约清单逐条核对副作用丢失、隐式依赖被删寄存器顺序对照原代码逐行比对顺序被优化边界条件看所有数组下标和位操作溢出、未定义行为性能指标上板实测函数调用增多、栈深度增加这份清单后来成了我审查 AI 输出的标准流程每次过一遍大概十分钟能拦下大部分问题。6. 人机协作重构的边界哪些该交给 AI哪些必须自己来6.1 适合交给 AI 的重构任务经过这次完整的重构我对什么任务适合 AI有了比较清晰的认识。适合 AI 的任务有几个共同特征逻辑密集但硬件无关。比如状态机的表驱动改造、缓冲区的索引计算、协议解析的状态跳转。这些任务逻辑复杂但纯软件AI 处理得很好。有明确输入输出的函数级重写。给清楚签名、约束、验收标准AI 生成的代码质量很高通常一次就能用。重复性的模式改造。比如把十个类似的 if-else 改成查表、把散落的魔数提取成宏定义。AI 做这种批量改造又快又准。代码注释和文档生成。AI 读代码生成注释的能力很强而且比人写得快。我这次重构后所有模块的注释都是 AI 生成的我只做了少量修正。6.2 必须自己把控的关键决策反过来有些事 AI 做不了或者做不好必须自己来架构决策。比如调度器用位图还是链表这种决策需要对系统整体有判断AI 给的方案只是参考拍板必须是人。性能取舍。当功能和性能冲突时砍哪个保哪个这是价值判断AI 没有这个能力。隐式契约的梳理。前面说过AI 看不见运行时才成立的约束这部分只能靠人。硬件相关的时序和顺序。AI 不懂硬件所有和硬件时序相关的部分必须人工审查。最终验收。AI 可以帮你验证逻辑但系统级的验收——长时间运行、边界场景、异常恢复——必须人来设计和执行。6.3 我的时间分配AI 干了多少我干了多少最后说一下实际的时间分配给想尝试这套方法的人一个参考。整个重构项目我记录的时间大概是需求梳理和契约清单4 小时纯人工验证环境搭建3 小时纯人工与 AI 交互生成代码约 6 小时含多轮修改代码审查和微调5 小时人工为主上板验证和调试4 小时人工为主总计约 22 小时其中纯人工部分约 16 小时AI 生成部分约 6 小时。对比手工重构我估计纯手工需要 40 小时以上而且质量不一定更好。AI 的价值不在于替你写代码而在于把写代码的时间压缩让你把精力集中在架构和验证上。我手写的代码确实不超过五十行主要是注释、边界条件修正、以及几处性能关键的微调。但没手写代码不等于没干活——需求梳理、契约挖掘、审查验证这些工作量一点没少只是从写代码变成了审代码和想清楚。如果你也想让 AI 重构你的嵌入式框架我的建议是先从一个小模块开始把上面这套流程走一遍感受一下 AI 的能力边界。不要一上来就重构整个框架那样大概率会翻车。等你在小模块上跑通了流程再逐步扩大范围。这套方法的核心不是 AI 有多强而是你能不能把任务拆到 AI 能接住的粒度以及你能不能守住那些 AI 看不见的边界。