企业官网建设流程全解析

“当嵌入式工程师染上了AI病”，这个标题我一看就笑出声。因为这说的就是我，估计也是现在大部分嵌入式从业者的真实状态：写代码先问AI，看手册先问AI，调bug第一反应还是把日志丢给AI。我甚至怀疑，再这么下去，哪天我焊板子之前都想让AI预测一下烙铁温度。但玩笑归玩笑，这个“病”背后其实藏着值得认真聊的东西——嵌入式工程师到底该怎么用AI，怎么让这波大模型红利真正落到MCU、Linux驱动、RTOS这些具体场景里，而不是光在朋友圈发一句“AI真强大”然后继续手抄寄存器。

这篇文章我就结合自己最近大半年的实际折腾，把这个“AI病”从症状、病理、治疗方案到康复建议，完整梳理一遍。没有空话套话，全是能直接抄作业的工具链配置、提示词模板和踩坑记录。不管你是刚入行的嵌入式小白，还是带过好几个量产项目的老人，应该都能从里面找到对自己有用的东西。

1. 症状自测：嵌入式工程师的“AI病”到底是什么状态

先说结论，所谓“AI病”，不是指拿AI干坏事，也不是指整天刷AI新闻摸鱼。真正让嵌入式工程师上瘾的，是那种“本来要折腾一下午的破事，现在十分钟搞定了”的爽感。一旦尝到这个甜头，你就回不去了。下面这份日常流水账，就是我这个“病友”的标准一天。

1.1 一份典型的“病友”日常流水账

早上到工位，产品经理丢过来一份需求文档，我第一反应不是逐行读，而是先把文档丢给AI做结构化总结。三分钟后，需求里的功能点、接口约束、时间节点就已经被整理成清单了。虽然偶尔会漏掉一两个隐藏条件，但用来快速进入状态完全够用。

上午写代码，我现在的默认流程是：先跟AI描述我要实现什么功能、跑在什么平台上、有什么约束条件，让它生成一版初稿。比如昨天写一个WiFi断线重连逻辑，我先跟AI说“帮我生成一个适合嵌入式MCU的WiFi断线重连状态机，需要用C语言，不能依赖操作系统，内存占用要小”，它给我的是状态枚举加回调函数的设计，整体思路是对的，但我还需要自己把具体的WiFi驱动接口填进去。下午调bug，串口打的日志一坨浆糊，我直接复制给AI让它找规律，它帮我锁定了几个可疑的时序竞争点，省了我至少俩小时翻代码。

晚上也一样，写周报让AI润色，刷面试题让AI出题，整理技术文档让AI先搭框架。甚至最近我在研究C语言面向对象编程在嵌入式里的落地技巧，也是让AI把封装、继承、多态分别映射成struct加函数指针的组合，再结合《C语言面向对象编程：嵌入式实战》这本书的案例，效率确实比以前自己硬啃快太多了。

1.2 为什么嵌入式开发会成为AI的“重灾区”

我观察下来，嵌入式比纯互联网后端更容易被AI“传染”，核心原因是这行的痛点正好撞在AI的强项上。

第一大痛点是资料又旧又散。芯片参考手册动辄上千页，里面全是寄存器逗号，很多老项目的代码注释早就和现实脱节了。而AI大模型在训练时吃进去的海量技术文档、开源项目、论坛帖子，恰好把碎片化的信息做了个汇总。你问它“某个系列MCU的定时器PWM输出引脚都有哪些”，虽然答案不一定全对，但它能把最常用的配置路径给你列出来，省去你在PDF里翻半天的痛苦。

第二大痛点是老项目代码又乱又没注释。嵌入式项目里经常能见到十年以上的祖传代码，变量名是a1、b2这种，函数几百行没有分节。用AI做代码梳理，让它给函数块加注释、抽取关键逻辑、生成模块调用关系，比人肉读效率高一个数量级。虽然AI不一定能理解硬件时序细节，但帮你理清代码骨架是没问题的。

第三大痛点是硬件问题难以复现。嵌入式bug发生后，经常是“现象在这台设备出现了，重启又好了，日志还不全”。这时候把能拿到的串口日志、错误码、内存dump丢给AI去猜，往往会给你意想不到的排查方向。它不像搜索引擎那样只给一堆链接，而是直接给你推断路径和验证步骤。

1.3 别把“AI病”当坏病，但要保持清醒

我见过两种极端。一种是对AI嗤之以鼻，觉得机器生成的东西不能碰，这种人会越来越累，因为重复劳动根本消不掉。另一种是完全无脑相信AI输出，连编译都没跑就往下走，这种人早晚会在现场翻车。

我的态度是，把AI当成一个特别聪明但经常说谎的实习生。活可以让它干，干完你必须检查。带着这个心态，才能既享受效率红利，又不会把项目搞崩。后面我会用一个专门章节讲这个“信任但验证”的操作方法，这里先立个锚：AI病的正面作用，是把我们从低价值劳动里解放出来，把省下来的精力投入到真正需要人的判断力的地方去。

2. 病根分析：AI辅助嵌入式的三层信任模型

用了大半年AI之后，我自己总结了一套“三层信任模型”，用来判断什么场景可以放心用AI，什么场景必须保持警惕。这套模型不一定严谨，但很实用，尤其适合嵌入式这种“硬件不可控、错误代价高”的领域。

2.1 第一层：AI生成初稿代码——能用，但必须逐行审

AI最擅长的，是生成那些“结构清晰、套路固定”的代码。比如环形缓冲区、按键消抖、状态机、链表操作这类经典嵌入式模块，AI写得又快又像样。

拿按键消抖状态机举例，提示词这样写效果很好：

请用C语言写一个适合裸机MCU的按键消抖状态机，要求： 1. 使用状态枚举定义空闲、确认按下、等待释放三个状态； 2. 使用定时扫描方式，扫描周期10ms； 3. 不依赖具体硬件，通过函数指针注册按键状态读取函数和事件回调函数； 4. 给出头文件和源文件。

AI给的代码骨架大致是：

typedef enum { KEY_STATE_IDLE, KEY_STATE_CONFIRMED, KEY_STATE_WAIT_RELEASE } key_state_t; typedef uint8_t (*key_read_func_t)(void); typedef void (*key_event_func_t)(uint8_t key_id, uint8_t event); typedef struct { key_state_t state; uint8_t debounce_cnt; uint8_t key_id; key_read_func_t read_func; key_event_func_t event_func; } key_t; void key_scan(key_t *key) { uint8_t level = key->read_func(); switch (key->state) { case KEY_STATE_IDLE: if (level == KEY_PRESSED) { key->state = KEY_STATE_CONFIRMED; key->debounce_cnt = 0; } break; case KEY_STATE_CONFIRMED: if (level == KEY_PRESSED) { key->debounce_cnt++; if (key->debounce_cnt >= 3) { key->event_func(key->key_id, KEY_EVENT_CLICK); key->state = KEY_STATE_WAIT_RELEASE; } } else { key->state = KEY_STATE_IDLE; } break; case KEY_STATE_WAIT_RELEASE: if (level == KEY_RELEASED) { key->state = KEY_STATE_IDLE; } break; } }

这代码能用吗？能，但有几个地方我必须改：第一，我的项目里按键是低有效还是高有效，需要配对read_func实现；第二，这里连续三次确认才触发，实际项目中要权衡消抖时间，10ms扫描三次就是20ms，有些场合会太快；第三，回调函数里面不能做耗时操作，否则会影响扫描周期。这些都是AI不知道、但是嵌入式工程师必须知道的常识。所以AI给你的是“80分的干饭骨架”，剩下20分的佐料必须自己放，而且是最好的佐料。

2.2 第二层：AI做知识检索——省时间，但别全信

嵌入式开发一大半时间都在查资料，查寄存器位域、查引脚复用功能、查某颗芯片的启动流程，这些场景AI确实比搜索引擎体验好，因为它直接给你答案而不是给你一堆链接。

但是，“直接给答案”也是最大的坑。AI为了让你满意，会在不确定的时候一本正经地编造。我遇到过最离谱的一次，问AI某个MCU的定时器基地址，它给我回了0x40021000，结果我对着官方头文件一查，实际是0x40011000。这个地址要是用在DMA或者寄存器映射初始化上，程序跑起来直接乱飞，查一晚上都未必能想到源头是AI在这里瞎编了一个数。

所以我现在的做法是，AI给的任何硬件参数，我都要和官方头文件、数据手册做一次交叉验证。具体动作就是：让AI生成代码时，明确要求“寄存器地址、中断号、引脚号等内容以代码仓库中的芯片头文件为准”，并且要求它引用官方文档的章节。如果它推三阻四给不出出处，那这个答案就只当线索，不当依据。

2.3 第三层：AI做工程决策——现阶段只能辅助

最危险的习惯，是拿AI当架构师和军师。让AI选RTOS、选主控芯片、评估功耗、估算Flash占用，这些决策涉及大量项目特有约束，AI的语料是公共的、滞后的、缺少上下文的，它给出的答案常常是“看起来专业但根本不落地”的。

比如我测试过让AI对比几款MCU在低功耗场景下的表现，它能给出个大致对比表，但一到具体型号在某块板子上的真实电流数据，它就现编了。这种数据的出处在芯片手册的电气特性表格里，每个批次还有差异，AI不可能知道。

我的模型总结成一张表格，方便大家对照：

这套模型最大的作用，是帮我在用AI的时候建立一条心理防线：先想清楚我正在让AI干哪一层的活，这层活允许它犯错到什么程度。第一层出错了编译不过能发现，问题不大；第二层出错是比较隐蔽的，可能烧到硬件上才发现；第三层出错，最致命，因为方向就偏了。

3. 主病历：VSCode集成Claude Code开发嵌入式MCU代码工程

聊完了病根，讲讲让我“病”得最重的这个工具组合：VSCode加Claude Code。这俩搭配起来，是真的改变了嵌入式MCU工程的开发节奏。以前写驱动像绣花，现在像批处理，效率完全不在一个量级。

3.1 工具链怎么搭：CLAUDE.md是灵魂

我的环境是Windows加WSL，也可以直接用Windows终端，看个人习惯。核心组件就三个：VSCode、Claude Code CLI、以及配套的C/C++工具链（arm-none-eabi-gcc、CMake、Ninja、cortex-debug）。AI编程工具其实不止Claude Code一种，GitHub Copilot、Cline这些我也试过，但论到对大型代码库的理解和跨文件重构能力，Claude Code在agent类工具里目前还是最能打的。

装完Claude Code之后，最重要的一步是给工程写CLAUDE.md。这个文件相当于给AI的“入职手册”，它会先读这个文件再开始干活。很多人的AI助手不好用，问题就出在没写这个文件。

我一般会在CLAUDE.md里写清楚这几样东西：

# 工程上下文 ## 芯片与平台 - MCU：STM32G474RCT6 - 内核：Cortex-M4，主频170MHz，无FPU - 编译工具链：arm-none-eabi-gcc 12.3 - 构建系统：CMake + Ninja - 调试器：ST-Link，SWD接口 ## 工程结构 - bsp/：板级外设驱动，统一使用HAL库 - app/：业务逻辑，禁止直接操作寄存器 - lib/：第三方库与算法，保持独立 - tests/：单元测试，使用Unity框架 ## 关键约定 - 所有硬件寄存器地址必须引用芯片头文件中的宏定义，禁止硬编码数字 - 中断回调函数中禁止调用阻塞型函数 - 新增外设模块时，需要同步提供头文件的风格注释 - 命名风格：文件全小写，函数名用模块前缀，例如 i2c_master_read()

项目根目录放一个这样的文件之后，AI对工程的“理解能力”会上升一大截。它会用约定的风格生成代码，而不是每次给你一套全新的命名和架构。我把这理解为：AI病也是可以分型的，给AI立好了规矩，它就是这个团队里最听话的新人。

3.2 真实加速场景：给老项目补I2C驱动骨架

前阵子接手一个老项目，跑的是裸机，需要外挂一颗MEMS传感器，接口是I2C。老项目里I2C驱动是个半成品，之前同事只写了个探测函数，这次要用起来就得补全读写函数和中断处理。

我的做法是，直接在VSCode里选中老代码文件，然后让Claude Code分析现有工程的HAL使用习惯，再按照同样的风格补出I2C Master读写函数。我给的提示词大致是：

请阅读工程里 bsp/i2c/ 下面的已有代码，理解它当前的初始化方式和中断使用方式。 然后按照同样的命名风格和HAL库调用方式，实现 i2c_master_write_reg 和 i2c_master_read_reg 两个函数。 要求：支持超时机制，代码中加详细注释，并把函数声明补充到头文件里。不要改动其他模块代码。

AI做得比我期待的要好。它不仅按已有的风格补全了函数，还主动加了一个超时重试逻辑，因为它在工程上下文里发现这个I2C外设在低功耗模式下会偶发NACK。虽然它加的初始超时参数我没直接用，但思路启发了我。这种“AI读代码、补代码、顺便提建议”的体验，在以前是完全不可想象的。

不过也有翻车的地方，它生成的一个结构体字段命名跟我在另一处定义的结构体冲突了，编译直接挂。我让AI自己看编译报错信息自己修，来回两轮就解决了。这说明AI也能“调试”自己的bug，但前提是你要把编译器的报错原封不动地转给AI看。

3.3 让AI生成单元测试和代码审查

嵌入式工程写单元测试的人不算多，因为桩函数和硬件依赖太麻烦了。但AI能把门槛拉低。我之前写了一个环形缓冲区模块，让AI配套生成Unity测试文件，提示词是：

基于 tests/ 目录下现有的Unity配置，为 ring_buffer.c 生成单元测试。 覆盖：空缓冲读取、写满、写溢出保护、读空保护、跨边界读写、单字节读写。 需要先设计桩函数来模拟内存分配失败。

生成出来的测试文件包含十几个测试用例，而且它自己知道要从被测试模块暴露的API入手，不去碰内部实现。跑完之后，还真帮我发现了一个在“缓冲区满再写一个字节”场景下的索引越界问题。这bug藏了两个礼拜了，手写测试用例的时候我压根没往这个边界想。

代码审查也一样。我写完一个模块后，会选中整个diff，然后对AI说“请站在资深嵌入式工程师的角度，审查这个改动，重点看内存泄漏、中断安全、可移植性，只用中文列出真实问题，不要夸我”。AI给的问题列表里经常有几条是我确实没想到的，但也会有过度担忧的条目，比如“建议增加重组保护”这种在裸机上根本不存在的概念，所以审查结果也要自己再过一遍。

3.4 踩坑实录：AI一本正经编出来的“寄存器地址”

上面那套流程用久了，人会飘，觉得AI不会错。结果上周它就给我表演了一波什么叫“自信地胡说”。

当时我在配一个DMA多通道搬运，问Claude Code某一个外设的DMA请求映射关系。它回答得非常详细，中断号、请求通道、外设基地址一应俱全。我图省事，没跟头文件核对，直接按它给的地址改了寄存器配置。烧录之后功能完全不对，逻辑分析仪一看DMA压根没启动，最后查了芯片头文件，发现它把外设基地址写错了，而且那个中断请求通道号也对不上。

这次经历让我定了一条铁律：凡是涉及芯片物理资源的答案，必须引用代码仓库里的官方头文件或者官方文档原文，否则一律视为编造。随后我又让Claude Code重新读一遍芯片头文件再回答同一个问题，这次给的是对的。同一套对话，加不加“先读官方文件再回答”的约束，效果天差地别。这条经验我建议所有用AI搞嵌入式的兄弟都记下，能省你一整周的排查时间。

4. 并发症：嵌入式Linux与RTOS项目里的AI应用

MCU裸机项目只是嵌入式的一半。这几年嵌入式Linux和RTOS项目的比例越来越高，AI在这些场景里也同样能帮上大忙，但玩法不太一样。

4.1 设备树折腾指南：AI辅助内核源码阅读

嵌入式Linux开发里，设备树是新人最容易摔跟头的地方。一个dts文件几百行，里面的属性到底是“必须的”还是“可选的”，芯片手册上写得往往很隐晦。有次我在调试一个GPIO按键功能，现象是按键中断永远不触发。我用AI辅助排查，先把相关dts节点贴给它，再附上一段内核日志，让它排查可能原因，它给出了几个方向，其中之一是“检查interrupt属性里是否忘记指定trigger类型”。

结果还真是这里的问题。我原来只写了interrupt-parent和interrupts，但没写触发类型，中断号也不对。AI帮我改成了这样：

gpio-key { compatible = "gpio-keys"; pinctrl-names = "default"; pinctrl-0 = <&key_pin>; key-gpio = <&gpio0 5 GPIO_ACTIVE_LOW>; interrupt-parent = <&gpio0>; interrupts = <5 IRQ_TYPE_EDGE_FALLING>; linux,code = <KEY_ENTER>; };

改动虽小，却是触发条件识别的关键。不过我也没全拿AI的答案直接改，还要去翻了芯片厂商的binding文档确认了irq类型数值，跨型号芯片的dts写法确实有静态差异。

还有一次是在Xilinx Zynq这种PS加PL的异构平台上，有人私下让我看怎么开发。我之前没怎么碰过Zynq，就让AI帮我梳理PS端和PL端的通信框架、AXI接口映射关系。AI能给出一个大的知识骨架，但细节上还得去查官方UG文档。这种场景我用AI的定位是“快速让人上手一门不熟的技术”，而不是“让AI直接写生产代码”。大差不差的意思是它能帮你把术语、概念、基础框图理清楚，让你去查手册时心里有底。

4.2 RTOS环境下的任务关系梳理与死锁排查

RTOS项目比裸机复杂在于并发，任务一多，状态就乱了。信号量、队列、互斥锁这些机制用起来不难，难的是在设计阶段把所有任务之间的依赖关系捋清楚。

我的习惯是，让AI读工程里所有任务的入口函数，然后让它输出一张任务调度关系表：每个任务的优先级、用到了哪些IPC机制、等待条件是什么、哪里可能发生阻塞。AI分析完之后，我还让它专门找“死锁风险点”。

有次它还真找出来一个：任务A持有一个互斥锁，然后又去等待任务B发的队列消息，而任务B处理消息前需要获取同一个互斥锁，两个任务互相等着对方，典型的ABBA死锁。AI不仅标出了风险，还解释了为什么嵌套等待在这里是危险的。后来我改了设计，把需要两个资源的操作拆成两个阶段，死锁风险就消掉了。这说明AI做“代码静态分析”这个方向确实值得多用。

4.3 嵌入式Linux外设调试：一个U盘测速方案的AI辅助设计

有人后台问我嵌入式Linux下U盘测速方案怎么搞，这其实是个挺典型的场景。移植好的Linux系统，挂载U盘后读写速度上不去，你需要一套标准测速方法来定位瓶颈是USB协议、文件系统还是存储芯片本身。

我让AI设计了一套测速方案，它给的思路是：先分场景测，再用不同工具交叉验证。具体如表所示：

AI给的这个框架没问题，但轮到实际操作，有些细节还得人工修正。比如某些板卡的USB驱动内核配置没开启usbtop依赖的debugfs，fio在busybox环境里没有预编译包，需要自己交叉编译。这类平台差异AI永远猜不到，只能由实际跑板子的人临场处理。所以我把AI给的方案当“第一版布置图”，后面七七八八的问题全是自己在现场填的。

5. 治愈指南：AI辅助下的嵌入式学习路线与面试准备

说完了工作，再聊聊学习。很多嵌入式新人问我学习路线，我现在的建议已经变成了：把AI当成一个24小时在线的私教。这比我当年一个人啃视频、翻帖子，效率高太多了。

5.1 把AI当“一对一陪练”和“面试官”

嵌入式学习有个问题是反馈太慢。你看了视频、抄了代码，但不知道自己的理解对不对。AI可以解决这个问题。我经常用一个提示词：

你是一位资深的嵌入式软件工程师面试官。现在请你模拟一场嵌入式岗位的面试，从“C语言基础、操作系统原理、驱动开发、项目深挖”四个方向随机出题。每当我回答完，你要先点评我的回答哪里对、哪里错，再追问一个问题。不要提前给出正确答案。

这种模式下，AI就是一个“苏格拉底式”面试官，能逼着我把脑子里模糊的概念说出来。比如它问“volatile关键字在嵌入式里的三种典型使用场景”，我回答完之后它追问“原子操作和volatile有没有关系”，这一问就击中了我的盲区——原来volatile不能保证原子性，读改写操作在多线程或中断里还是要靠临界区保护。

嵌入式八股文现在网上到处都是，但很多人背了答案却不懂原理。用AI复盘八股文有个优势：你可以针对一个题目无限追问，问到你真懂为止。比如二叉平衡树AVL树，这个概念在嵌入式面试里经常被问到，但工作里根本用不到，光靠背代码很容易忘。我让AI生成一个带旋转操作注释的AVL实现，再让AI扮演面试官，一步步追问左旋右旋的时机、平衡因子的更新逻辑。搞懂之后，我在简历上写“熟悉常用数据结构”的时候才真正有底气。

5.2 手撕代码怎么练：从二叉树到环形队列

嵌入式面试的手撕代码，范围相对固定：链表、二叉树、环形队列、状态机、简单的排序查找。让AI帮你生成题目和测试用例，比自己瞎写好用太多。

我现在的练法是，先让AI出题：

给我出一道嵌入式笔试常见的手撕代码题，要求： 1. 题目贴近嵌入式场景； 2. 需要手写完整可编译的C代码； 3. 附上两个测试用例； 4. 先不要给答案。

AI出了个“数组实现环形缓冲区，支持覆盖写和溢出保护”的题，我当场写代码，写完再跟AI的参考答案对。过程中我发现自己在判断“读指针追上写指针”时容易漏掉缓冲区满和空的区分，这个细节就是靠AI的参考答案才补上的。

二叉树相关的题目也不用自己找。让AI按“层序遍历、中序遍历、AVL旋转”分难度出题，每道题都让它准备测试用例和错误提示。AI出的题质量不低，因为它能记住嵌入式方向的高频考点。不过也要提醒一句：AI给的答案偶尔还有想当然的bug，我自己遇到过给出的中序遍历代码在递归返回条件上写错的情况。所以每次拿到AI代码，最好自己先在编译器里跑一遍，别直接背。

5.3 自测实操：AI写的答案骗过了我，差点翻车

说到AI答案的坑，讲个更实际的。有一次我让AI解释嵌入式里的中断延迟，它的回答非常工整，从硬件响应到软件压栈、从关中断到上下文切换，逻辑严丝合缝。读完之后我觉得自己懂了，结果在板子上实测却发现，我按照它描述的流程去算中断响应时间，和示波器量的差了将近三倍。

原因在于AI讲的是理想流程，而真实硬件要区分的细节太多了：中断仲裁周期、flash等待周期、CPU流水线状态、以及与主时钟配置的关系。AI把这些“不怎么通用”的细节全给简化掉，给了一个“教学级”答案。那之后我养成一个习惯：AI讲原理我可以听，但凡是涉及“性能数字”的，必须自己实测，或者找官方文档里的典型值做参考。AI负责把抽象概念翻译成人话，实测数据负责把人话变回真实世界。

6. 长期处方：AI在文档、专利与知识管理中的价值

嵌入式工程师的死穴除了调试，还有两件看起来很“软”的事：写设计和搞专利。这俩事情以前我不爱做，但后面发现AI能把它们变成“半自动”的活，这大概就是我对AI病最不后悔的部分。

6.1 把陈年代码变成设计文档

很多嵌入式项目活了好几年，代码堆得比字典还厚，可文档却停留在立项那天。接手的人只能靠读代码硬猜。让AI写设计文档，是有固定套路的。

我的默认工作流是三步走。第一步，让AI遍历模块源码，生成模块清单和文件依赖关系；第二步，让AI按照“初始化流程、主循环流程、中断处理流程、低功耗流程”来梳理关键路径，生成文字版的时序描述；第三步，让AI输出接口文档，包括每个函数的入参、返回值、内存要求、调用注意点。

提示词模板我放在这里：

你现在是嵌入式文档工程师。请阅读 src/ 下面的源代码，输出该模块的设计文档，结构如下： 1. 模块概述和职责边界 2. 对外接口列表 3. 关键数据结构和内存布局 4. 运行时序描述（完整初始化、主循环、中断上下文） 5. 已知限制和潜在风险 要求：所有结论必须引用源码中的函数名或行号，不要猜测没有依据的内容。

这个流程跑完之后，我一般还会让AI给开源协议的嵌入式架构设计项目做对比分析。比如在GitHub上看到一个入式的架构设计项目，我让AI把它和自己的老项目对比，找差异点和可借鉴点。这个用法特别适合想提升自己架构能力的工程师，相当于免费拥有了一个“架构分析助理”。

6.2 专利交底书素材整理

专利这件事，很多工程师一听就头大，觉得写起来太抽象。AI能帮上忙的地方，是帮你的技术方案整理“发明点逻辑链”。专利交底书的核心结构通常是“技术问题-技术方案-技术效果”，AI特别擅长把零散的技术描述拉进这个框架。

我的做法是，先把项目里那个创新点相关的代码和设计思路丢给AI，然后说：

请阅读下面这段技术描述，帮我把技术交底书需要的关键要素提取出来： 1. 现有技术的缺陷是什么 2. 本方案解决的核心技术问题 3. 技术方案的实施步骤，尽量细化到流程和模块 4. 本方案带来的技术效果，要有可对比的量化指标 注意：只整理素材，不要直接生成完成版交底书，我需要自己确认每个细节。

生成完素材之后，再逐条人工核实。AI会把语言组织得又专业又顺，但你得把里面的每个技术细节都对一遍，否则分分钟把“可能”写成了“肯定”。

6.3 数据安全红线：代码不能随便喂给云端AI

这是整个AI辅助流程里最重要的一条，必须单独拿出来说。嵌入式项目很多涉及供应商协议、硬件设计、内部通信协议，这些代码一旦放进云端AI，就有数据出境和泄露风险。我在团队里明确规定了三条红线：

第一，未经审批的公司核心代码、未公开的硬件设计资料，严禁上传到任何云端AI工具。第二，需要AI分析的时候，先脱敏处理，把芯片型号、寄存器地址、协议细节等敏感信息替换成代码里的占位符。第三，有条件的团队，优先尝试在内部服务器上部署本地大模型，开发环境通过内网访问，数据不出厂区。

有人觉得本地模型能力不如云端大模型，实测下来，如果任务只是“读老代码、提炼模块关系、生成代码框架”，本地模型完全够用。至于最聪明的大模型，拿来做非涉密的技术调研和通用知识问答就好。安全和控制，永远排在效率前面。这一条，我不接受任何反驳。

7. 病友扩列：AI进入硬件选型与边缘模型部署

最后聊聊AI在嵌入式偏硬件侧和边缘AI场景里的应用。这两个方向看着跟“写代码”没关系，但同样能被AI病“感染”。

7.1 用AI做硬件选型咨询，但要长个心眼

前几天有个朋友让我帮忙看看，一个低功耗传感器节点的主控选什么合适。我照例让AI做了个候选对比，它给了几个主流方案的对比，涵盖内核、主频、低功耗模式、外设丰富度、价格区间、生态成熟度。这个表用来做初筛确实挺好用，但真到了拍板阶段，还得拿到开发板实测。

因为AI的对比数据来源是公开文档和社区评测，它不会知道你公司库里哪种芯片有替代料、供应商的交期是多少、团队对哪款芯片最熟、现有产线烧录器能不能兼容。这些硬约束才是选型的决定因素。所以我对AI在选型上的定位是“帮你拓宽视野，不替你做决定”。

7.2 边缘AI模型部署：猫狗识别是怎么跑到MCU上的

“宠物检测AI模型——嵌入式设备上的猫狗实时识别”是我最近看到很有意思的一个方向。把AI模型跑在MCU或嵌入式Linux小盒子上，属于边缘AI部署。这活儿需要两类知识：模型压缩知识和嵌入式移植知识，恰好都是AI能帮上忙的。

一个典型的流程是：先用现成的分类模型，比如MobileNetV3或者SqueezeNet，在自己电脑上训练猫狗分类，然后做剪枝和int8量化，把模型从float32压缩到几百KB以内，再用TFLite Micro或者厂商的AI部署工具链生成C数组，集成到MCU工程里。AI在这种场景里能帮你解决的是“步骤性问题”，比如让你不用把入门教程每个字都读完才能开始。

我让AI帮我规划过一个部署流程，它直接给出了逐步清单：准备数据集、微调模型、评估精度、量化、生成头文件、在板端推理、调优内存。过程中它还提醒我，量化后精度如果有轻微下降，先做校准集数据增强，再考虑换更大模型。这类经验性的提醒还是挺值钱的。

真正跑起来之后，AI的作用就减弱了。板子上内存不够、算子不支持、摄像头数据格式不对，这些都是AI教不了的，只能靠自己的硬件调试能力慢慢磨。别指望AI能帮你把模型部署的坑全填上，它顶多是给你一张地图，路还得自己走。

7.3 AI辅助硬件调试的尝试

除了写代码和跑模型，我还试过用AI辅助硬件调试。最常用的场景是把串口日志导出来，让AI做日志分类和异常定位。比如WiFi模块反复断开重连时候的日志，AI能按时间线把事件梳理出来，标出哪些是正常断开、哪些是异常复位。还有个场景，是把逻辑分析仪导出的时序数据转成文本描述，让AI帮忙分析是否符合协议规范。这两个用法都有效果，但都只适合“省时间”，不适合“下结论”。协议时序这种强硬件相关的问题，最终还是要拿示波器复核。

最后再分享一个小经验。AI病没什么可怕的，真正可怕的是停掉自己的人肉思考。我现在每天的工作方式已经彻底变了，AI负责初稿、检索和结构化，我负责决策、验证和兜底。每个AI给的结论，我都默认它“可能对，也可能错”，只有经过测试和交叉验证的内容，才会放进代码库和文档里。这套习惯建立起来之后，AI病在我这里已经转成了“增强体质”的慢性病，工作效率提高了，学习能力也没落下，反而比以前更清楚自己要往哪个方向使劲。