1. 一个嵌入式老兵的“偷懒”实验让AI重构我的框架嵌入式开发这行干了快十年我最大的感受就是代码写得越久越不敢随便动老项目。尤其是那种跑了三四年的框架里面全是“历史遗留智慧”——有些地方你自己都忘了当初为什么那么写但删掉它系统就崩。我手里就有一个这样的项目一个基于事件驱动的小型嵌入式框架最早是给某款工业采集设备写的后来陆续移植到几个不同的板子上功能越加越多代码越来越乱。这个框架的核心其实不复杂一个任务调度器、一套消息队列、一层硬件抽象接口再加上一些状态机管理。但问题在于它是我在不同时期用不同风格写出来的。早期部分用了大量全局变量和宏定义中期部分开始用结构体封装后期又引入了回调注册机制。结果就是同一个框架里能看到三种完全不同的编程范式维护起来极其痛苦。每次要加一个新功能我都得先花半小时“考古”搞清楚这块代码到底属于哪个时代。所以当AI编程工具开始成熟的时候我脑子里冒出的第一个念头就是能不能让AI帮我把这个框架重构一遍不是让它从零写一个新框架而是让它理解现有代码的逻辑然后按照统一的架构风格重新组织。这个想法听起来有点疯狂但仔细想想重构这件事本质上就是“理解现有逻辑按新规则重新表达”而这恰好是大语言模型擅长的方向。我给自己定了一个目标整个重构过程我尽量不手写业务代码只做架构决策和结果验证。换句话说我负责告诉AI“要什么”AI负责告诉我“怎么写”。这个实验持续了大约两周中间踩了不少坑也总结出了一些真正有用的经验。这篇文章就是把这个过程完整拆开从思路设计到实操细节再到问题排查全部摊开来讲。如果你手里也有那种“想重构但不敢动”的老项目或者你对AI辅助开发这件事持观望态度那这篇内容应该能给你一些参考。2. 重构前的整体设计与思路拆解2.1 为什么选择“AI主导、人工把关”的模式在动手之前我先想清楚了一个问题AI在重构这件事上到底应该扮演什么角色我试过两种极端方式。第一种是“AI全自动”就是把代码扔给AI让它直接输出重构后的版本我只看结果。第二种是“AI辅助”我自己设计架构AI只帮我写具体的实现代码。第一种方式试下来的结果是AI确实能重构但它会“自作主张”。比如它会把你原本用宏定义实现的配置项改成枚举把中断服务函数里的逻辑挪到任务里甚至会把一些你故意保留的冗余代码“优化”掉。这些改动单看都是合理的但放在整个项目里就可能引入新的问题。第二种方式的问题则是效率太低因为大部分时间还是我在写代码AI只是帮我补全一些片段没有真正减轻负担。最后我采用的是一种中间模式我负责定义架构规则和接口边界AI负责在这个边界内重新实现所有模块。具体来说我会先写一份“重构规范”里面明确规定任务调度器用什么数据结构、消息队列怎么管理内存、硬件抽象层怎么定义接口、状态机用什么模式实现。然后我把现有代码按模块拆开一个模块一个模块地交给AI让它按照规范重写。每完成一个模块我会跑一遍单元测试和集成测试确认行为一致后再继续下一个。这个模式的好处是架构决策权在我手里实现细节交给AI。AI不会跑偏因为它只能在给定的框架内发挥我也不会累死因为具体的代码编写工作确实被大幅分担了。2.2 框架重构的核心目标与优先级排序重构最怕的就是“什么都想要”。我一开始列了一堆目标代码要更简洁、性能要更好、可移植性要更强、要支持动态配置、要加单元测试……后来发现这样根本没法推进因为AI不知道先满足哪个。于是我强制自己做了优先级排序优先级目标衡量标准是否必须P0行为一致性所有原有功能测试通过必须P1架构统一消除三种编程范式混用必须P2可读性提升新成员能在半天内理解核心流程必须P3可测试性核心模块能独立跑单元测试尽量P4性能优化任务切换开销降低20%可选P5动态配置支持运行时修改参数暂缓这个排序很关键。P0是底线任何重构都不能改变原有行为。P1和P2是核心价值如果重构完还是三种风格混用那这个实验就失败了。P3是加分项因为嵌入式项目做单元测试本来就麻烦能做好当然好做不好也不强求。P4和P5直接放弃因为一旦引入性能优化和动态配置AI就会开始“发挥创意”风险不可控。这里有个经验重构目标不要超过三个“必须”。超过三个AI就会在多个目标之间摇摆最后每个都做得不彻底。我见过有人让AI同时做“解耦、提速、加功能”结果AI把三个目标都写进了注释里代码一行没动。2.3 模块拆分策略怎么把老代码“喂”给AI老项目的代码结构是这样的一个主文件大概两千行里面混杂了任务调度、消息处理、硬件操作和业务逻辑。直接把这个文件扔给AI它大概率会懵因为上下文太长而且模块之间的耦合关系不清晰。我的做法是先做一轮人工拆分把代码按职责切成独立的模块文件。注意这一步我没有改任何逻辑只是把原来混在一起的东西按功能分到不同文件里。比如scheduler.c只放任务调度相关的函数msg_queue.c只放消息队列的入队、出队、管理逻辑hal.c只放硬件抽象层的接口定义和默认实现state_machine.c只放状态机的状态定义和转移逻辑app_logic.c只放具体的业务逻辑拆分完之后每个文件大概两三百行AI处理起来就轻松多了。而且拆分的过程本身也帮我理清了模块之间的依赖关系。比如我发现原来app_logic.c里直接调用了hal.c的底层寄存器操作这就是典型的耦合问题。在重构规范里我明确规定业务逻辑只能调用硬件抽象层的接口不能直接操作寄存器。拆分完之后我给每个模块写了一份“接口说明”其实就是把该模块对外暴露的函数签名和数据结构列出来然后告诉AI“这是模块A的接口你要在保持接口不变的前提下重写内部实现。”这样AI就不会乱改接口也不会把模块之间的调用关系搞乱。3. 核心细节解析与实操要点3.1 重构规范怎么写才能让AI“听话”重构规范是整个实验的核心文档。我一开始写得很随意结果AI完全按自己的理解来出来的代码跟我想的完全不一样。后来我总结出一个原则规范要写成“约束条件”而不是“建议”。比如不要写“建议使用结构体封装任务”要写“任务必须用结构体表示结构体必须包含任务ID、执行函数指针、周期参数、状态标志四个字段”。不要写“消息队列尽量用静态内存”要写“消息队列必须使用静态数组实现数组大小由宏定义指定禁止使用malloc”。不要写“状态机可以用switch-case”要写“状态机必须使用状态转移表实现转移表为二维数组行表示当前状态列表示触发事件”。这种“必须”式的写法AI执行起来非常准确。我试过用“建议”式的写法AI会挑着执行有些地方按你说的做有些地方按它自己的习惯来最后出来的代码风格还是不统一。另外规范里还要明确命名规则。嵌入式代码的命名风格差异很大有的用驼峰有的用下划线有的加模块前缀。我在规范里统一规定所有函数名用模块名_动作的格式比如scheduler_init、msg_queue_push、hal_gpio_write。所有变量名用下划线分隔的小写字母所有宏定义用全大写。这样AI生成的代码就不会出现风格混乱的问题。3.2 任务调度器的重构从全局变量到结构体封装任务调度器是框架的核心也是重构难度最大的部分。原来的实现是这样的// 旧代码全局变量 宏定义 #define MAX_TASKS 8 uint8_t task_count 0; uint32_t task_period[MAX_TASKS]; void (*task_func[MAX_TASKS])(void); uint8_t task_enabled[MAX_TASKS]; void scheduler_add_task(uint32_t period, void (*func)(void)) { if (task_count MAX_TASKS) { task_period[task_count] period; task_func[task_count] func; task_enabled[task_count] 1; task_count; } }这段代码能跑但问题很明显所有数据都是全局的任何地方都能改。而且task_count、task_period、task_func、task_enabled这四个数组是“平行数组”必须同步维护一旦有一个地方漏了就会出bug。我给AI的规范是任务调度器必须用一个结构体数组来管理所有任务每个任务包含周期、函数指针、使能标志和计数器四个字段。调度器对外只暴露初始化、添加任务、启动、停止四个接口。AI重构后的代码是这样的// 新代码结构体封装 typedef struct { uint32_t period; void (*func)(void); uint8_t enabled; uint32_t counter; } task_t; typedef struct { task_t tasks[MAX_TASKS]; uint8_t count; uint8_t running; } scheduler_t; static scheduler_t sched; void scheduler_init(void) { memset(sched, 0, sizeof(sched)); } int scheduler_add_task(uint32_t period, void (*func)(void)) { if (sched.count MAX_TASKS) return -1; sched.tasks[sched.count].period period; sched.tasks[sched.count].func func; sched.tasks[sched.count].enabled 1; sched.tasks[sched.count].counter 0; sched.count; return 0; }这个改动看起来简单但效果非常明显。所有任务数据被封装在一个结构体里外部只能通过接口访问不能直接改内部字段。而且counter字段的加入让调度器可以在中断里做计数在主循环里做判断避免了在中断里直接调用任务函数的问题。实操心得AI在重构这类“平行数组”代码时表现非常好。你只要告诉它“把平行数组改成结构体数组”它就能自动完成字段映射和接口调整。但要注意AI可能会顺手把MAX_TASKS改成动态分配这时候你必须在规范里明确禁止否则它会引入malloc这在嵌入式里是大忌。3.3 消息队列的重构内存管理是最大的坑消息队列的重构比任务调度器更麻烦因为涉及到内存管理。原来的实现用了动态分配// 旧代码动态分配 typedef struct msg_node { uint8_t *data; uint16_t len; struct msg_node *next; } msg_node_t; msg_node_t *head NULL; void msg_queue_push(uint8_t *data, uint16_t len) { msg_node_t *node malloc(sizeof(msg_node_t)); node-data malloc(len); memcpy(node-data, data, len); node-len len; node-next head; head node; }这段代码在PC上跑没问题但在嵌入式系统里就是灾难。频繁的malloc和free会导致内存碎片跑几天之后系统就崩了。而且中断里调用malloc是极其危险的行为因为malloc不是可重入的。我在规范里明确要求消息队列必须使用静态环形缓冲区实现禁止使用任何动态内存分配。缓冲区大小由宏定义指定消息长度超过缓冲区容量时直接丢弃并返回错误码。AI重构后的代码// 新代码静态环形缓冲区 #define MSG_QUEUE_SIZE 16 #define MSG_MAX_LEN 64 typedef struct { uint8_t data[MSG_MAX_LEN]; uint16_t len; } msg_item_t; typedef struct { msg_item_t items[MSG_QUEUE_SIZE]; uint8_t head; uint8_t tail; uint8_t count; } msg_queue_t; static msg_queue_t msg_q; int msg_queue_push(const uint8_t *data, uint16_t len) { if (len MSG_MAX_LEN) return -1; if (msg_q.count MSG_QUEUE_SIZE) return -2; memcpy(msg_q.items[msg_q.head].data, data, len); msg_q.items[msg_q.head].len len; msg_q.head (msg_q.head 1) % MSG_QUEUE_SIZE; msg_q.count; return 0; }这个改动彻底解决了内存碎片问题。所有内存都是静态分配的队列满时直接返回错误码由上层决定怎么处理。而且环形缓冲区的入队和出队操作都是O(1)复杂度性能比链表好得多。注意事项AI在重构消息队列时最容易犯的错误是忘记处理队列满和队列空的情况。我在规范里专门加了一条“所有队列操作必须检查count字段满时返回-1空时返回-2。”这样AI就不会漏掉边界条件。3.4 硬件抽象层的重构接口与实现分离硬件抽象层HAL的重构目标是让业务逻辑不再直接依赖具体硬件。原来的代码里业务逻辑直接操作寄存器// 旧代码直接操作寄存器 void app_led_on(void) { GPIOA-ODR | (1 5); } void app_led_off(void) { GPIOA-ODR ~(1 5); }这种写法的问题在于换个板子就得改业务代码。如果新板子的LED接在GPIOB的3号引脚那所有调用app_led_on的地方都得改。我在规范里要求HAL层必须定义统一的接口业务逻辑只能调用接口不能直接操作寄存器。接口包括GPIO读写、延时、串口收发、定时器操作等。AI重构后的HAL接口// hal.h typedef enum { HAL_GPIO_LED, HAL_GPIO_BUTTON, HAL_GPIO_RELAY } hal_gpio_id_t; void hal_gpio_write(hal_gpio_id_t id, uint8_t value); uint8_t hal_gpio_read(hal_gpio_id_t id); void hal_delay_ms(uint32_t ms);然后具体的实现放在hal_stm32.c或hal_esp32.c里业务逻辑只包含hal.h。这样换平台时只需要换一个实现文件业务代码一行不用改。实操心得AI在生成HAL接口时会倾向于定义很多“通用”函数比如hal_gpio_toggle、hal_gpio_set_mode之类的。这些函数在初期用不上但会增加代码体积。我的做法是只定义当前用到的接口用不到的让AI删掉。等以后真需要了再加不要提前设计。4. 实操过程与核心环节实现4.1 环境准备与工具链配置在开始重构之前我需要先把开发环境搭好。这个项目原来是在Windows上用Keil MDK开发的但Keil的工程文件格式对AI不友好而且没法做自动化测试。所以我先把工程迁移到了Linux下的GCC工具链用Makefile管理编译。具体步骤安装交叉编译工具链我用的是gcc-arm-none-eabi在Ubuntu下直接apt install gcc-arm-none-eabi就行。编写Makefile把原来的Keil工程文件里的源文件列表、头文件路径、编译选项提取出来写成Makefile。这一步我让AI帮我做了把Keil的.uvprojx文件内容贴给AI让它生成对应的Makefile。搭建测试框架我用的是Unity测试框架配合CMock做硬件模拟。这样我可以在PC上跑单元测试不需要真实硬件。配置AI编程助手我用的是某款支持长上下文的AI编程工具把重构规范、模块接口说明、现有代码一起贴进去让它生成重构后的代码。这里有个坑AI生成的Makefile经常漏掉一些编译选项比如-Wall -Wextra、-Os优化等级、-ffunction-sections等。这些选项对嵌入式项目很重要我后来在规范里加了一条“Makefile必须包含以下编译选项-Wall -Wextra -Os -ffunction-sections -fdata-sections -Wl,--gc-sections。”这样AI就不会漏了。4.2 逐模块重构的完整流程整个重构过程我分了五个阶段每个阶段处理一个模块。每个阶段的流程都是一样的第一步准备输入材料。我把该模块的现有代码、接口说明、重构规范整理成一个文档贴给AI。文档格式如下【模块名称】任务调度器 【现有代码】粘贴代码 【接口说明】列出对外接口 【重构规范】粘贴相关规范条目 【要求】保持接口不变重写内部实现输出完整代码文件第二步AI生成代码。AI会输出重构后的代码通常还会附带一些解释。我一般不看解释直接看代码。第三步人工审查。我重点检查三个方面接口是否一致、边界条件是否处理、是否有动态内存分配。如果发现问题我把问题指出来让AI重新生成。第四步编译测试。把AI生成的代码放到工程里编译跑单元测试。如果测试不通过把错误信息贴给AI让它修复。第五步集成验证。把该模块和其他模块集成跑集成测试。确认行为一致后进入下一个模块。这个流程看起来简单但实际操作中第三步和第四步会反复循环。我统计了一下任务调度器模块改了3轮消息队列改了5轮HAL层改了2轮状态机改了4轮。平均每个模块要改3-4轮才能通过所有测试。4.3 关键参数的计算与选择过程在重构过程中有几个关键参数需要我手动计算和选择不能完全交给AI。第一个是任务调度器的最大任务数。原来的代码里MAX_TASKS是8但实际只用了5个。我重新评估了一下考虑到未来可能增加的功能最终定为12。这个数字不是随便定的每个任务结构体占16字节12个任务就是192字节加上调度器本身的开销总共约220字节。我的目标板有64KB RAM这个开销完全可以接受。第二个是消息队列的缓冲区大小。原来的队列用了动态分配没有固定大小。我根据实际消息的长度分布做了统计大部分消息在16字节以内最长的消息是48字节。所以我定了MSG_MAX_LEN64留了一些余量。队列深度方面我统计了消息产生的峰值速率大约是每秒20条而消费速率是每秒30条所以队列深度定为16就足够了。第三个是状态机的状态转移表大小。原来的状态机用了switch-case有7个状态和12个事件。改成转移表后表的大小是7×1284个条目。每个条目是一个函数指针占4字节总共336字节。这个开销在可接受范围内。经验分享参数选择不要问AI要自己算。AI会给你一个“看起来合理”的数字但它不知道你的RAM有多大、CPU有多快、消息速率是多少。这些只有你自己清楚。4.4 代码审查与行为一致性验证重构完成后我做了一轮完整的代码审查。审查的重点不是“代码写得好不好”而是“行为是否一致”。我用了三种方法来验证方法一单元测试对比。我把旧代码和新代码分别编译成PC上的可执行文件用同一组测试用例跑对比输出结果。这个方法最直接能发现大部分逻辑错误。方法二静态分析。我用cppcheck和clang-tidy对新代码做静态分析检查是否有未初始化变量、数组越界、空指针解引用等问题。AI生成的代码在这方面表现不错但偶尔会有一些“看起来没问题但实际有隐患”的写法比如在中断里调用非可重入函数。方法三运行时监控。我把新代码烧到目标板上跑了一个72小时的稳定性测试。监控指标包括任务执行时间、消息队列深度、CPU利用率、内存使用量。测试期间没有出现死机或异常复位说明重构后的代码在稳定性上没有问题。验证方法发现问题数典型问题单元测试对比12边界条件处理不一致静态分析5中断里调用非可重入函数运行时监控2任务执行时间超预期5. 常见问题与排查技巧实录5.1 AI重构时最容易犯的五个错误在两周的重构过程中我总结了AI最容易犯的五个错误。这些错误不是AI“不会”而是它的“默认习惯”和嵌入式开发的要求不一致。错误一滥用动态内存分配。AI在需要管理可变数量对象时第一反应就是用malloc。比如消息队列、任务列表、状态机状态它都会倾向于动态分配。这在PC上没问题但在嵌入式里是禁忌。我的应对方法是在规范里明确写“禁止使用malloc/free”并且在审查时搜索代码里是否有malloc关键字。错误二在中断里调用非可重入函数。AI经常把一些耗时操作放在中断服务函数里比如memcpy、printf、甚至malloc。这些函数在中断里调用会导致不可预期的问题。我的应对方法是在规范里规定“中断服务函数只能调用可重入函数且执行时间不超过10微秒。”错误三忽略volatile关键字。在嵌入式里硬件寄存器和中断共享变量必须用volatile修饰。AI经常忘记加导致编译器优化后行为异常。我的应对方法是在规范里列出所有需要volatile的场景让AI对照检查。错误四栈空间估算不足。AI生成的代码经常有很深的函数调用层次或者在大函数里定义大数组。这在嵌入式里会导致栈溢出。我的应对方法是让AI在生成代码后输出每个函数的栈使用估算然后我手动检查最坏情况下的栈深度。错误五中断优先级配置错误。AI在生成中断相关代码时经常忽略优先级配置或者配置成不合理的值。我的应对方法是在规范里明确每个中断的优先级范围让AI按规范配置。5.2 行为不一致问题的排查思路重构后最让人头疼的问题就是“行为不一致”。明明逻辑看起来一样但跑出来的结果就是不对。我遇到过几次典型情况情况一任务执行顺序变了。旧代码里任务是从数组末尾开始执行的新代码改成了从头部开始。这导致某些依赖执行顺序的任务出了问题。排查方法是打印每个任务的执行时间戳对比新旧代码的差异。情况二消息队列满了之后的处理不同。旧代码在队列满时直接覆盖最老的消息新代码在队列满时返回错误。这导致上层逻辑的行为发生了变化。排查方法是构造队列满的场景观察新旧代码的行为差异。情况三状态机的默认转移不同。旧代码在遇到未定义的事件时保持当前状态新代码在遇到未定义事件时跳转到默认状态。排查方法是遍历所有状态和事件的组合对比新旧代码的转移结果。排查技巧用“差分测试”的方法。把新旧代码的同一个函数分别跑一遍输入相同的参数对比输出。如果输出不同就逐步缩小输入范围直到找到最小的差异用例。这个方法比看代码快得多。5.3 常见问题速查表问题现象可能原因排查方法解决方案编译报错“undefined reference”AI生成的函数声明和定义不一致检查头文件和源文件的函数签名让AI重新生成确保签名一致运行时死机栈溢出或中断冲突用调试器查看栈指针和中断状态减小栈使用调整中断优先级任务不执行调度器计数器溢出检查计数器的数据类型和溢出条件改用更大的数据类型或调整计数逻辑消息丢失队列满时处理不当打印队列深度和入队出队日志增加队列深度或优化消费速度状态机卡死转移表有遗漏遍历所有状态和事件组合补全转移表增加默认转移硬件不响应HAL接口实现错误用示波器检查引脚电平检查HAL实现确认寄存器操作正确5.4 独家避坑技巧技巧一让AI生成“变更说明”。每次AI重构完一个模块我让它输出一份“变更说明”列出所有改动的函数、改动的原因、可能的影响。这份说明帮我快速定位问题也方便后续回溯。技巧二保留旧代码作为参考。重构过程中我没有删除旧代码而是把它放在一个单独的目录里。当新代码出现问题时我可以随时对比旧代码的行为。重构完成后旧代码又保留了一个月才删除。技巧三用版本控制做“检查点”。每完成一个模块的重构我就提交一次代码。这样如果后续模块的重构引入了问题我可以快速回滚到上一个检查点而不是从头再来。技巧四让AI写测试用例。我让AI为每个模块生成单元测试用例然后我手动补充边界用例。AI生成的测试用例覆盖了大部分正常路径我补充的边界用例覆盖了异常路径。两者结合测试覆盖率能达到90%以上。技巧五不要一次性重构所有模块。我见过有人把整个项目扔给AI让它一次性重构完。结果出来的代码有几百个错误根本没法调试。正确的做法是一个模块一个模块地来每个模块验证通过后再进行下一个。6. 重构后的效果与个人体会重构完成后的框架代码量从原来的约2500行减少到了约1800行但功能完全一致。代码风格统一了所有模块都用了结构体封装和静态内存分配。新加入的同事看了之后说“终于能看懂了。”这句话让我觉得这两周的折腾值了。从性能上看任务切换开销从原来的约8微秒降低到了约5微秒因为去掉了动态内存分配和链表遍历。消息队列的入队出队操作从O(n)变成了O(1)因为用了环形缓冲区。CPU利用率从原来的45%降低到了38%因为去掉了不必要的内存分配和释放。但最大的收获不是这些数字而是我对AI辅助开发这件事有了更清晰的认识。AI确实能大幅减轻重构的工作量但它不是“全自动”的。你需要给它清晰的规范、明确的边界、可验证的目标。你需要审查它的输出、测试它的行为、修正它的错误。你需要做架构决策、参数计算、优先级排序。这些工作AI做不了也不应该让AI做。我个人在实际操作中的体会是AI最好的角色是“高级代码生成器”而不是“架构师”。你告诉它“怎么写”它写得又快又好你让它决定“写什么”它就会跑偏。所以重构这件事核心还是在你手里AI只是帮你把想法变成代码的工具。最后再分享一个小技巧如果你也想让AI重构你的嵌入式项目先从最小的模块开始。找一个只有一两百行、依赖最少的模块让AI重构一遍跑通整个流程。这样你能快速了解AI的能力边界和常见问题然后再逐步扩大范围。不要一上来就搞核心模块那样一旦出问题排查成本会非常高。