企业官网建设流程全解析

GPT6能把嵌入式的桌子掀翻？说实话，我第一次看到这个说法的时候，正蹲在工位上调一块STM32的I2C时序，示波器探头还夹在引脚上。当时的真实反应是：先把桌子按住，再想想到底谁掀谁。作为一个写了十来年嵌入式代码、从裸机摸到嵌入式Linux、带过项目也校招过人的老油条，我觉得这个话题值得好好掰扯一下。它表面上是聊GPT6这个大模型迭代到“下一代”之后会不会取代嵌入式工程师，但本质上聊的是：AI能力暴涨之后，嵌入式这个常年被认为是“硬骨头”的领域，会不会发生结构性洗牌，以及我们这些靠它吃饭的人，该往哪个方向站。

这篇文章不是焦虑贩卖，也不是“AI永远不行”的安慰剂。它更像是我自己这段时间的观察和复盘：哪些嵌入式的活确实会被AI吃掉了，哪些又成了更值钱的本事，还有我实测下来比较管用的AI辅助开发姿势，希望能给正在做嵌入式、准备转嵌入式、或者已经在带嵌入式团队的朋友一点参考。

1. “掀桌子”背后的真实信号

1.1 GPT6的本事到底长在哪

很多人一听GPT6，第一反应是“又一个大语言模型”，然后觉得和自己无关。我的看法不太一样。从GPT-3到GPT-4，代码生成能力是从“自动补全”进化到“能读懂上下文、生成完整函数”的级别；到了GPT-4之后，它已经能处理跨文件的代码分析和简单的架构建议。如果GPT6真得像传言中那样，具备更强的“项目级理解能力”，能从整个仓库的维度去生成代码、改bug、补测试，那它对嵌入式开发的影响就绝不只是“帮你写个LED闪烁”。

什么概念？以前我们做一个新项目，第一周基本都在干重复劳动：照着手册初始化时钟树、配置GPIO复用、写UART收发缓冲、搭一个跑马灯任务。这些代码模板化程度极高，只要你做过三五个项目，闭着眼睛都能写。而AI最擅长的恰好就是这种“见过很多次、模式明确”的代码生成。所以GPT6真要落地，第一个冲击的绝对不是高端驱动工程师，而是那些长期停留在“复制改”阶段的单片机开发工作。

但我要先说清楚：代码生成只是嵌入式开发的表层。真正值钱的部分，在代码生成之前和之后——在一堆乱七八糟的信号波形里找到那颗偶尔丢失的ACK，在RAM只剩2KB的约束下设计一个可靠的状态机，在现场设备跑飞之后从Map文件和栈回溯里把问题揪出来。这些东西，GPT6不一定能帮你。

1.2 嵌入式岗位的“恐慌圈”在哪里

我觉得现在嵌入式圈子里对AI的恐慌，要分三拨人看。

第一拨是刚入门不久的朋友。他们感觉GPT6写代码比自己快，压力最大。但我的建议很直接：别慌。新手阶段本来学的就是“怎么写代码”，这部分确实会被AI压缩，但新手真正需要积累的“怎么调通代码”并没有减少。我带了几个实习生，发现用AI辅助后，他们写驱动快了很多，但一上板子就原形毕露——不会看波形、不会排查总线冲突、不知道I2C的ACK和NACK在逻辑分析仪上长什么样。这些能力AI给不了，只能靠时间堆。

第二拨是长期做方案开发、但深度不够的工程师。比如一直用某家芯片厂商的SDK做应用层，芯片换了一颗就不会了。这类工作场景里，AI确实有很强的替代潜力。因为SDK封装已经很成熟，代码生成是低风险高收益的活儿，公司完全可以让一位资深工程师带着AI，干出三个人的量。如果你发现自己三年经验但做的事情跟应届生差不多，这才是真正的“桌子被掀”。

第三拨是懂硬件、懂底层、能做系统级调试的人。对他们来说，GPT6更像一台增强版的电机：资料查得更快、脚本写得更好、甚至能帮忙生成Linux设备树的初稿。但这拨人吃饭的本事在于“全链路排错”，从应用层一路追到寄存器级，这个东西AI短期够不着。

1.3 桌子掀翻之前，先看清桌子是什么

我一直觉得，嵌入式开发和纯软件开发的本质区别，是它站在软件和硬件的交点上。很多看似是“写代码”的问题，最后都是“硬件行为”的问题。Python后端写错了顶多报个Exception，嵌入式写错了可能直接让产线停线，甚至烧板子。所以“桌子”到底是什么？不是编辑器里那几行代码，而是你在软硬件交界处定位问题、解决问题的综合能力。

我做过一个很典型的案例：设备偶发性重启，代码review了十几遍都没看出问题，最后用示波器抓到电源芯片的EN引脚在某个瞬间掉了几十毫伏，才定位到是另一个外设启动时的浪涌把电源拉塌了。这种问题，你让GPT6从代码层面分析，它大概率会告诉你“检查空指针、检查栈溢出”，因为它的训练数据里没有你这块板子的电源网络设计，也没有你选的那颗电源芯片的瞬态响应曲线。

所以我把“掀桌子”理解成：AI确实会掀掉“写常规代码”的桌子，但同时把“解决真实嵌入式问题”的桌子垫得更高了。谁在低桌上吃饭，谁就最该动一动；在高桌上吃饭的人，位置反而更稳。

2. 嵌入式真正的护城河，AI暂时够不着

2.1 寄存器、时序、功耗：从文档到代码的鸿沟

外行人看嵌入式开发，觉得不就是操作寄存器嘛——几个位赋值，跟Python写配置差不多。但真上手你会发现，芯片手册动辄上千页，而且不同系列之间寄存器差异极大。AI的训练数据不可能覆盖所有新出的芯片，更不可能覆盖厂家那么多“手册没写清楚”的坑。国产MCU和一些冷门传感器尤其明显，很多时候你手里的资料就是一个几百页的英文数据手册PDF和一张寄存器的勘误表。

我自己试过让大模型写某颗通用MCU的低功耗模式配置代码。它能写出基本框架，知道要设置哪几个寄存器，但当你追问“进入STOP2模式之后，LPUART的时钟源应该选LSI还是LSE，唤醒时间差多少”，它就含糊了。这种细节在手册里可能只占两三段，但恰恰决定你的设备能不能过功耗测试。AI的另一个问题是知识截断时间，它可能掌握的是上一代芯片的规律，拿来做新芯片就容易踩坑。

所以我的结论是：AI是一个很好的“读手册摘要器”，但离“替代工程师读手册”还有距离。在嵌入式里，寄存器、时序、功耗这些跟具体硅片强相关的东西，迟早还是得你自己去啃。你啃得越深，AI对你越像助手，而不是威胁。

2.2 实时系统里，AI生成代码反而容易翻车

嵌入式的另一个硬约束是实时性。很多MCU应用要求中断响应在微秒级，任务调度不能容忍不可预测的延迟。AI生成代码有个毛病：它天然倾向于生成“通用、好读、便于维护”的代码，因为训练数据里大部分是这种代码。但嵌入式现场最怕的就是这种“通用正确”。

说个我踩过的坑。让AI写一个基于FreeRTOS的传感器采集任务，它生成的代码逻辑没问题，但里面有动态内存申请（malloc），还直接在任务里串行做了传感器的多次延时等待。这个代码放到PC上模拟，一点问题没有；烧进MCU之后，内存碎片导致运行几天后任务创建失败，而且单次采集周期过长，直接把后面一个硬实时任务的deadline给挤爆了。这就是典型的“AI看着对、实际不对”。

在裸机环境里更明显。AI生成的中断服务函数经常忘记加volatile，或者把一个耗时的printf直接写进中断里。这些问题编译不一定报错，但跑起来就飘。现实中的嵌入式面试里，最喜欢拿这种“AI写出来的错代码”考人，考察你能不能看出问题。说白了，AI在生成代码时，并不知道你的系统里有哪些角落是不能碰的，它只能基于概率去猜。

2.3 以按键非阻塞扫描为例，看AI容易在哪里露馅

按键扫描是单片机入门必做的功能，也是最能说明问题的一个例子。新手通常的做法是：检测到按键电平变化，然后delay个20ms消抖，再读取一次电平，确认按下就返回。这个做法在简单产品里能跑，但问题在于delay是阻塞的，CPU在消抖的20ms里什么都干不了。如果系统里还有LED刷新、数码管扫描、通信处理，就会发现按键按下去的时候，其他任务全卡顿了。

做得好一点的做法是“非阻塞扫描”：用一个定时器产生1ms或5ms的时基，每隔一定周期采样一次按键电平，通过状态机判断按下、释放和消抖过程。在这种实现里，CPU在主循环里可以继续处理其他事情，按键状态则不断被后台更新。这里的关键不是代码本身，而是“状态机设计思路”：几个状态、每个状态里做什么、什么时候跳转。这个思路你不会的话，就算GPT6给你生成一百遍代码，你改一个按钮布局的逻辑还是得抓瞎。

我拿一个很常见的“长按/短按”需求去测试AI：要求短按触发一次，长按连续触发。AI第一次生成的代码用了简单的延时判断，第二次变成状态机，但状态设计得很粗暴——长按和短按的判断是在同一个状态里完成的，结果在按下释放的边界上经常误触发。这就是没有理解输入扫描本质的表现。同样的需求，一个有经验的工程师会先画一个三态图：空闲态、消抖态、按下确认态，再在按下确认态里通过记录持续时长来分流长短按。所以我的建议是：AI生成的代码可以拿来跑，但状态机的“形”是它给的，“神”必须是你自己设计的。

3. AI正在重塑嵌入式开发的日常

3.1 代码分层能力，成了AI时代的分水岭

这段时间和同行交流，大家有一个共识：代码分层清不清楚，决定了你用AI的效率是翻倍还是为零。为什么？因为GPT6这类模型，本质上是在“给定上下文”的情况下做续写。如果你的工程是“一个main.c里三千行、逻辑和寄存器操作全部搅在一起”，那AI根本分不清哪些是应用逻辑、哪些是硬件操作，生成出来的东西自然没法看。

反过来，如果你的工程是干干净净的分层架构——应用层只管业务逻辑，中间层做协议解析和状态管理，驱动层封装具体硬件操作，HAL层抽象芯片差异——那你给AI指定“请修改协议解析函数，增加CRC校验”，它就能精准地只动该动的部分，而且不会碰坏别的模块。我自己现在带团队做新项目，第一件事就是先定代码架构，再让AI去填充各个模块。以前一个驱动工程师一周的工作量，现在一天能出初版，剩下时间全部用来做review和硬件联调。

我理解的嵌入式代码分层，大致是这样的：顶层是业务逻辑（比如“温度超过阈值报警”），中间是服务层（比如“传感器采集、存储、通信协议”），底层是驱动层（比如“I2C读写、GPIO控制、PWM输出”），最底下才是芯片厂商SDK或HAL库。每一层只通过接口向上层提供服务，层与层之间不互相渗透。AI在每一层内生成代码时都非常强悍，但如果你不把“层”的边界划清楚，它生成出来的就是一个混沌代码块。会分层的工程师，等于把AI这个强大的引擎装在了路径清晰的车架上；不会分层的人，就是在泥巴地里开超跑。

3.2 嵌入式Linux与开源项目，是AI的主场也是你的跳板

如果你现在还在纠结“单片机还能干多久”，我建议认真看一下嵌入式Linux的方向。原因很简单：Linux本身就是人类历史上最大的开源项目之一，围绕它的资料、代码、示例多到爆炸。这意味着AI在嵌入式Linux领域的能力远比其他细分领域强得多。写设备树、改内核模块、编译Buildroot根文件系统、调试U-Boot启动流程，这些东西在GitHub和邮件列表里沉淀了几十年，GPT6的训练数据里要多少有多少。

我自己最近在做的项目里，让AI帮忙写了一个触摸屏I2C驱动适配Linux设备树的初始版本，它甚至知道该去查哪个内核版本的binding文档。这在三年前根本不敢想。但同样要注意，Linux驱动的坑往往在“硬件行为不符合常规”的地方：某颗触摸屏控制器的中断脚是低有效，但设备树里写反了；某个传感器在休眠唤醒后需要重新初始化寄存器，代码里没处理。这些AI不知道，因为它没看过你手里这块屏的时序图。

所以我认为，嵌入式Linux是当前和未来几年最值得投入的方向。一方面AI把入门门槛降低了一些，让更多人能快速摸到Linux开发的门；另一方面Linux驱动、内核调优、启动优化这些活的深度依然在，不容易被替代。如果你已经是单片机背景，我的转型路径建议是：裸机RTOS项目做熟之后，先搞清楚Linux的基础操作、交叉编译，再逐步深入设备树和字符设备驱动，不要一上来就啃内核调度器。

3.3 嵌入式学习路线：八股文会缩水，工程素养会涨价

网上各种“嵌入式学习路线图”很多，大致都是单片机→RTOS→Linux→内核这样一条线。这个主线我认为没有过时，但AI确实在改变这条路的三段走法。

第一段，入门速度会变快。以前学STM32，光是配一个串口就要对着手册抄半天代码，很多人就是在这里劝退的。现在你用AI辅助，几分钟就能生成一个能跑通串口回显的工程。这样学习的乐趣大大增加，但也带来了一个风险：太容易得到代码，就不去理解时钟树是怎么配出来的，GPIO复用是怎么查的。而这些东西恰恰是后面排查问题的底子。

第二段，RTOS和工程能力越来越重要。十年前一个单片机工程师可能只需要会裸机编程，现在岗位要求里“精通FreeRTOS或RT-Thread”已经成了标配。AI可以帮你生成任务函数、消息队列的收发逻辑，但它不会告诉你为什么在高优先级任务里不能做阻塞延时，不会告诉你信号量优先级反转怎么解决。如果你没有亲手调过几次优先级反转导致的诡异问题，你根本不知道AI生成的代码里哪个if分支是坑。

第三段，面试和考核方式正在变化。以前嵌入式面试八股文问“static关键字的作用”“volatile什么时候用”，这一类题现在AI都能轻松回答，再问就显得没水平。我观察到，现在一些团队面试已经开始换打法：给你一段明显由AI生成的、看起来没问题但实际上有bug的驱动代码，让你找问题并说出理由；或者给你一个新芯片的英文手册，让你现场用AI辅助写启动代码，然后当场烧录跑通。也就是说，未来的面试更考验“工程素养”——你的调试思路、代码审查能力、对硬件的感知，而不是单纯背八股文。

4. AI辅助嵌入式开发实操：从提示词到板级调试

4.1 高质量提示词的写法：给AI一个“需求闭环”

最近网上有个热搜词是“使用GPT6生成的3A游戏用的什么提示词”，大家都想知道AI是怎么被调教出那么高质量结果的。其实放在嵌入式领域，逻辑完全一样：AI输出的质量，直接取决于你给它的提示词是否形成了“需求闭环”。

什么叫需求闭环？就是你的提示词里必须包含：角色、目标、约束条件、输入输出接口、测试标准。比如让AI写一个按键扫描模块，光是说“帮我写个按键扫描代码”，它给你的东西大概率是玩具级的。但如果你说“我是一个使用STM32F103的嵌入式工程师，请用C语言写一个基于定时器时基的非阻塞按键扫描模块，要求：支持短按和长按，短按单击触发一次，长按每200ms连续触发；接口设计为按键扫描函数在定时器中断或主循环中周期调用，并提供按键事件查询接口；不可以使用阻塞延时，不使用动态内存分配，编译环境为Keil MDK”，它输出的代码才算有可用性。

我写提示词还有一个习惯：先让AI“复述需求”。在正式让它写代码之前，先问一句“请说明你理解的输入输出逻辑和状态机设计”。这一步基本不花时间，但能避免一半以上的返工。很多AI翻车不是因为模型笨，而是因为需求文本里有歧义，它选了一条你不想走的分支。让AI先复述，你就能在生成代码前把歧义消掉。

另外建议把硬件环境写进提示词：主控型号、开发板、外设连接引脚、时钟主频。这些信息看似琐碎，但直接决定了代码生成质量。主频你不告诉它，它生成的定时器初值就是随便填的；引脚不告诉它，它只能写一个抽象的HAL接口，还是不能直接上手用。

4.2 大模型生成按键扫描代码的一次真实实测

我把上面那段“非阻塞按键扫描”的提示词丢给一个大模型，下面是它第一版生成结果的关键逻辑（简化版）：

// 按键消抖状态机 #define KEY_SCAN_PERIOD_MS 2 #define KEY_DEBOUNCE_MS 20 #define KEY_LONG_PRESS_MS 1000 #define KEY_REPEAT_MS 200

它确实写出了定时器时基、消抖计数和长短按判断框架。但仔细看，问题来了：这个AI在第一版里把“长按连续触发”实现成了“按下1000ms后，只要不松开就每200ms触发一次”，这个思路是对的；可它的状态机里只有一个“按下计数”变量，没有明确的“空闲→检测→确认→释放”状态划分。结果就是，当你在短按释放的瞬间如果又有抖动，或者新一次按下发生在上一轮长按的repeat周期内，变量会互相干扰，导致事件丢失。

我把这个问题反馈给它，要求“状态机最小三态：空闲态、按下确认态、长按重复态”，并给出了按键扫描函数需要返回的事件类型枚举。第二版就好很多了：

typedef enum { KEY_EVENT_NONE, KEY_EVENT_SHORT_PRESS, KEY_EVENT_LONG_PRESS_REPEAT } key_event_t; key_event_t key_scan(void) { static uint8_t state = KEY_STATE_IDLE; static uint32_t press_tick = 0; uint8_t level = key_read(); switch (state) { case KEY_STATE_IDLE: if (level == KEY_PRESSED_LEVEL) { state = KEY_STATE_DEBOUNCE; press_tick = get_tick_ms(); } break; case KEY_STATE_DEBOUNCE: if (level == KEY_PRESSED_LEVEL) { if (get_tick_ms() - press_tick > KEY_DEBOUNCE_MS) { state = KEY_STATE_REPEAT; return KEY_EVENT_SHORT_PRESS; } } else { state = KEY_STATE_IDLE; } break; case KEY_STATE_REPEAT: if (level == KEY_PRESSED_LEVEL) { if (get_tick_ms() - press_tick > KEY_LONG_PRESS_MS) { press_tick = get_tick_ms(); return KEY_EVENT_LONG_PRESS_REPEAT; } } else { state = KEY_STATE_IDLE; } break; default: state = KEY_STATE_IDLE; break; } return KEY_EVENT_NONE; }

这版能用，但如果你直接拿到项目里，还是要做几处调整：第一，key_read()需要加引脚配置；第二，短按和长按是互斥触发的，这个逻辑是否符合产品需求要自己确认；第三，状态机里没提处理“在消抖阶段就松开又马上按下”的极端情况。这就是我前面说的：AI能给骨架，血肉和细节得自己补。

4.3 AI生成代码的三道审查关卡

用AI生成嵌入式代码，我给自己定了三道铁的纪律，你也可以直接抄作业。

第一关是编译关。任何AI生成的代码，没有经过编译直接上板子，都是耍流氓。我会加上-Wall -Wextra -Werror把所有警告变成错误，特别是未初始化变量、符号隐式声明、悬空指针这类。很多嵌入式老手对警告不以为然，但AI生成的代码尤其要严查。它偶尔会写出来“变量定义了但没用”这种无害警告，但更多时候是“类型隐式转换可能丢数据”这类在MCU环境里会真炸雷的隐患。

第二关是代码走查关。重点看三件事：有没有动态内存分配（MCU环境里能不用就不用）；有没有在临界区或中断里调用阻塞函数；有没有正确处理错误返回值。我建议把AI生成的代码和一份你自己手写的“参考实现”做对比，各做一分钟自我讲解，讲不清楚的代码就是有问题的代码。

第三关是硬件实测关。代码上板子跑只是最基础的。你需要用工具去验证时序：逻辑分析仪抓按键事件的时间戳，比较它和理论值差多少；示波器看GPIO波形是否干净，有没有因为消抖时长过长导致快速按键漏识别。我自己的习惯是，AI生成的驱动代码，必须通过一个连续24小时的压力测试才允许合并到主分支。按键模块就让它模拟每分钟按一百次，跑一晚上，第二天看事件统计。AI写不出这样的测试程序？可以让它写测试脚本，但跑测试、看数据、做判断的人必须是你。

5. 面试、机考、项目实战：AI时代的嵌入式生存指南

5.1 面试题不会消失，但“八股文”的权重会下降

先说结论：嵌入式面试不会没有题目，但题目类型正在变化。以前面的经典八股文——static、volatile、const修饰指针的区别、结构体字节对齐、大小端、中断和轮询的差别——这些东西AI现在回答得比大多数应届生还标准。所以一些大厂的嵌入式校招机考和面试，已经开始往“能力验证”方向倾斜。

我听到的、也自己在面试中采用的模式是：给候选人一个小需求，比如“用状态机实现一个按键短按/长按检测，要求不能阻塞”，允许他现场用AI辅助完成，然后让他讲解这段代码为什么这么设计，边界情况怎么覆盖，如果按键接到两种不同电平等效电路上要怎么改。这样一来，AI只是工具，真正考察的是候选人有没有能力定义问题、审查代码和做出工程决策。

所以我给准备面试的朋友一个很切实的建议：刷八股文的时间可以适当压缩，但一定要练“AI辅助开发+代码走查”的组合能力。具体做法是，拿到一个嵌入式题目，先用AI生成一版答案，然后自己去挑三个问题出来并修复。你试过几次就会发现，AI很容易在中断安全、延时函数、内存使用、状态机边界这几类问题上犯低级错误。面试官问“你怎么保证AI生成的代码在硬件上没问题”，你能给出一套审查流程和实测方法，这就是亮点。

5.2 嵌入式开源项目：最能证明你能力的简历

现在很多简历写得千篇一律，“熟悉STM32”“了解FreeRTOS”“做过智能小车”，这种描述在AI时代越来越没有说服力。面试官比你更清楚，这些项目大概率是在教学视频的下一步下一步里做出来的。真正能在AI时代帮你拉开差距的，是你有没有在嵌入式开源项目中真实提交过代码。

我推荐三条参与路径。第一条，从修文档开始。很多嵌入式开源项目的文档写得比较散，尤其是驱动库、BSP、构建系统的README。你花一个周末把某个外设驱动的使用方法梳理清楚，提一个Pull Request，就能让项目维护者看到你。这个门槛很低，但能逼你真正读懂代码。第二条，为某个开源RTOS或驱动库增加一个小功能，比如给RT-Thread的一个传感器驱动包增加“低功耗自动唤醒”选项，或者给某个开源Bootloader增加一个串口通信协议。这类功能改动不大，但涉及对原有架构的理解，成果展示时很能打。第三条，自己开源一个小项目，哪怕是“一个支持多按键矩阵的非阻塞扫描库”，只要代码分层清晰、有单元测试和文档，就比简历里写十个“基于STM32的智能XXX”都有说服力。

我自己招人的时候，看到“有开源项目维护经验”，会在心里加不少分。因为这意味着这个人能看懂别人的代码、能写文档、能接受代码评审。这些素养，在AI生成代码满天飞之后，会比“写代码快”更重要。

5.3 不同阶段开发者的应对建议

如果你的工作经验在三年以内，我的建议是：别沉浸在“AI能帮我写代码”的舒适区。我见过一些刚入行的朋友，依赖AI完成了整个项目，但你真的问他某个引脚为什么复用成这个功能，UART波特率误差怎么算，DMA和中断两种方式的差别是什么，他答不上来。新人阶段最重要的是积累“为什么”，而不是“怎么实现”。所以尽量用AI提速，但关键代码建议先自己手写一遍，再拿AI的版本对比，这样成长最快。

如果你的经验是三年到八年，正在从单片机向Linux或者更复杂的系统方向转型，那AI是你的加速器。它的项目建设能力和代码生成可以帮你把大量“昨天就能写完”的活快速消化，把时间留出来啃更难的问题：设备树怎么适配不存在的硬件节点、内核模块怎么处理并发访问、Yocto构建依赖怎么解。这个阶段千万别再花太多时间在“改几个LED流水灯”上。

如果你已经是资深工程师或技术负责人，你的战场应该在“架构设计”和“工程流程”层面。用AI快速把原型搭出来给团队评审，把团队从“写代码”里解放出来去做测试、文档和硬件验证。我带项目时的体会是：人机协作的团队里，定义“验收标准”的人最值钱。AI负责出活，你负责出标准，桌子不但没有被掀，反而变得更高了。

6. 写在最后：桌子没翻，但餐桌变了

回头再看那个问题，GPT6到底能不能把嵌入式的桌子掀翻了？我的判断是：它真的掀掉了一些人的桌子——那些长期停留在代码搬运层、缺少硬件感知和系统思维的岗位，确实会被大幅压缩。但它更大的作用是提升了整张餐桌的高度：调试能力、架构能力、软硬协同意识、审查AI输出质量的能力，成了更稀缺的东西。

我自己的做法也在悄悄调整。以前写驱动要先查半天手册，现在我会先让AI把框架拉出来，再拿手册一项项核对寄存器，省下来的时间全部花在硬件验证上。另外我给自己定了一个小规矩：AI生成的关键代码，必须能在一张白纸上徒手画出它的状态图或时序图，画不出来就说明我没理解，没理解就直接改到理解为止。这个方法我用了半年多，帮我和团队拦下了不少“AI觉得对、板子觉得不对”的问题。

最后分享一个很实际的技巧：做嵌入式AI辅助开发，一定要让AI帮你写测试代码，而不是只写功能代码。比如写完按键扫描模块后，顺手让AI生成一份“模拟按键抖动序列”的测试用例脚本，把各种边界时序都覆盖一遍。这样AI才是真正成了你的帮手，而不仅仅是一个代码生成器。桌子还在，菜也还热，只是坐下来的规矩变了。能适应的人，会吃得比以前更饱。