最近嵌入式这个圈子聊 AI 编程的人明显多起来我一开始也以为是热度炒作直到在自己的 STM32 项目里把 Claude Code 接进工作流才发现这次真不一样。以前用 AI 辅助写代码主要图的是自动补全、查函数签名到了 Claude Code 这种能直接读文件、改代码、跑命令的 Agent 形态它已经不是一个“给你补全代码的编辑器插件”而是一个能参与整个嵌入式工程编译、烧录、调试闭环的搭档。这篇文章是“嵌入式软件 AI 编程”系列的第一篇主题很明确以 STM32 为起点把 Claude Code 当成一个能干活、但需要你管住节奏的开发助手。我会从环境搭建讲起到 CLAUDE.md 工程上下文的写法、外设驱动生成、状态机落地、常见烧录报错排查最后整理出一套可以直接套用的工作流。想试试 AI 写嵌入式代码的人或者已经在用聊天式 AI 但不满意于“只能复制粘贴改小片段”的人照着做就行。硬件程序员看不上 AI 抄代码很正常但这次工具的工作方式确实变了——它开始参与真实工程不再是问答玩具。1. 先想清楚Claude Code 在嵌入式开发里到底能干嘛1.1 嵌入式开发者的真正痛点嵌入式软件开发和其他方向最大的区别在于你面对的不只是代码还有芯片手册、寄存器、外部中断时序、晶振参数、电源噪声、调试器连接这些“看不见的墙”。我见过不少从 Web 转过来的同事一上来就习惯“报错就搜搜完就往代码里填”结果在 STM32 上栽了跟头——同一个错误可能来自接线、时钟配置、启动文件、链接脚本四个地方根本不是搜索能解决的。传统 AI 聊天框能帮你解释一段代码但有几个天然短板第一它看不到你的工程结构不知道你用的是 HAL 还是 LL 库也不知道你的 CMakeLists 里链接了哪些源文件第二它不能执行命令给出的建议往往是“猜”的一旦遇到编译错误、链接错误、烧录失败你还要自己复制粘贴回去第三它没有“记忆”每次都要重新描述一遍工程背景。这些痛点正好是 Claude Code 这类 Agent 形态工具擅长的方向。它不是被动回答问题而是被允许在当前工程目录里看文件、改代码、执行构建命令再根据命令输出决定下一步动作。对嵌入式开发来说这意味着 AI 能真正参与“读芯片手册—写驱动—编译—烧录—看报错—改代码”的循环而不是停在一个孤立的对话框里。1.2 为什么是 Claude Code 而不是普通 AI 聊天框我没有要神话 Claude Code 的意思但它确实有几个针对工程场景的设计是聊天框替代不了的。一是它面向“项目目录”工作打开一个嵌入式工程后它会去读 .c、.h、CMakeLists、README、甚至 git log 里的历史提交基于真实代码上下文做判断二是它可以调用工具链我要它“编译一下看看报错”它会真的去跑 cmake然后把报错日志抓回来分析三是它能连续做多步操作比如先搜代码里所有 GPIOB 的用法再批量改成正确的引脚模式最后统一编译验证。对 STM32 开发而言这种能力非常契合实际需求。一个典型工程动辄几十个源文件外设初始化代码又高度模板化如果每次都要人工翻库函数签名、查寄存器位定义非常消耗精力。Claude Code 能在给定上下文的前提下自动完成这些“体力活”而我要做的是把工程约束讲清楚。1.3 别踩的边AI 编程不能替你做的三件事但这不代表它能全包。我自己用下来有三件事绝不交给 AI第一硬件原理图和 PCB 设计AI 环节对电源、时钟、信号完整性的理解还是太理想化让它拍板会出事第二安全关键逻辑比如电机控制保护、电池充电管理这类代码的时序和容错必须人来审第三芯片选型和整体架构Claude Code 可以给你建议但没有经过真机验证前不能仅凭它的“自信”定方案。AI 编程在嵌入式里的正确打开方式是“人定边界、AI 填细节”。边界就是芯片型号、引脚分配、实时性要求、哪些文件是编译生成不可改这些必须提前写清楚否则 AI 会像刚入职不懂规矩的实习生一样到处乱改。2. 准备环境把 AI 接进 STM32 开发工作流2.1 一套能跑的嵌入式工具链既然要把 Claude Code 变成工程助理第一步是保证本机有一条完整的 STM32 开发链路。我目前的推荐组合是STM32CubeMX 负责生成初始化和引脚配置CMake 做构建arm-none-eabi-gcc 做编译OpenOCD 或 STM32CubeProgrammer 做烧录和调试。Windows 上如果不想折腾直接用 STM32CubeIDE 也可以但要注意 Claude Code 在终端里更习惯操作命令行工具所以我建议至少把编译器、OpenOCD、CMake 装齐路径全部加入系统 PATH。这里有两个容易忽略的点。第一STM32CubeMX 生成的 Makefile 我一般不用默认的而是让它生成 CMake 工程后续加文件更方便第二OpenOCD 的配置文件要提前测通最好手写一遍烧录命令确认板子能连上再考虑让 AI 接管。否则 AI 一执行命令就报“找不到目标芯片”你会分不清是 AI 的问题还是自己环境的问题。2.2 安装 Claude Code 并进入项目目录安装方式我这里只说常见做法Anthropic 官方提供命令行安装包一般通过 node/npm 环境全局安装装完在终端里输入claude就能进入交互界面。没有 Node 环境的先装 LTS 版本这一步没什么捷径。桌面版我也试过对纯命令行习惯的人不是必须很多嵌入式用户最终还是会回到 VS Code 自带的终端里跑 CLI因为这样所有编译、烧录输出都在同一个窗口。进入项目后有一个容易被忽略的动作让 Claude Code 知道当前这是一个嵌入式工程。我习惯在工程根目录启动claude然后立刻新建或更新 CLAUDE.md把芯片型号、工具链、构建方式写进去。不要指望 AI 能自动读懂所有工程上下文喂得越明确它后面干活越稳。2.3 让 AI 找得到编译器和烧录器Claude Code 执行命令时用的是系统 PATH 里的工具所以我们必须确认三件事都在arm-none-eabi-gcc能在任意目录下直接调用、cmake和ninja能直接用、openocd或STM32_Programmer_CLI能直接用。如果某个命令没在 PATH 里AI 执行时会报 “command not found”然后它大概率会自作主张帮你装东西这可不是我们想看到的。我踩过一次坑是在 Windows 上装完 STM32CubeProgrammer命令行工具没有默认加入 PATH导致 AI 烧录时一直找不到命令甚至尝试用管理员权限改环境变量。后来我明确在 CLAUDE.md 里写了工具的绝对路径才消停。所以要么配好 PATH要么把绝对路径写死在工程上下文里二选一。提示不要轻易让 AI 自己安装编译工具链或修改 PATH这是它最容易失控的场景之一。人先把环境弄好AI 只负责用。3. 教规矩给 Claude Code 写一份工程“入职手册”3.1 CLAUDE.md 应该包含哪些内容如果你把 Claude Code 当临时工用不给任何背景就问问题它也能回答但答案会很泛。真正让它变成项目老手的关键是写好 CLAUDE.md。这不是格式上的仪式感而是给 AI 一个最低成本的“入职培训”。我自己的 CLAUDE.md 会包含六块信息芯片型号与核心频率、工程目录结构说明、构建和烧录命令、代码风格约定、哪些文件绝对不能改、以及常见硬件环境描述。举个例子# 项目smart-light-fw - 芯片STM32F103C8T6主频最高 72MHz - 构建CMake arm-none-eabi-gcc构建目录为 build/ - 编译命令cmake --build build -j - 烧录命令openocd -f interface/stlink.cfg -f target/stm32f1x.cfg -c program build/smart-light-fw.elf verify reset exit - 初始化代码由 STM32CubeMX 生成不要手工修改 MX 生成文件 - 编码风格函数名小写加下划线宏定义大写缩进 4 空格注释用中文 - 注意HAL_Delay 只允许在主线程或非中断上下文使用中断里用标志位有了这个文件Claude Code 在处理具体任务时就不再是凭空发挥而是先读规则再动手。比如我让它新增一个 PWM 驱动它会自然避开修改 CubeMX 生成的文件并在提交编译前先跑一遍 build 命令。3.2 嵌入式任务的提示词拆法很多人在 AI 编程上失望不是工具不行是任务拆得太粗。你让它“帮我写个智能台灯固件”它当然给你铺一大堆模板代码但这不是工程思路。嵌入式开发讲究模块化我一般把任务拆成几类写新驱动、改现有逻辑、查问题、做移植、优化功耗。针对每一类提示词结构也不一样。写新驱动时我会说清楚接口、外设、引脚、约束排查问题时我先把现象、日志、最近改动描述完整再让 AI 给假设。下面是一个我常用的写驱动模板现有工程是 STM32F103 的智能台灯固件请在 app_layer/ 下新增 led_effect.c 和 led_effect.h 实现 3 种呼吸灯效果对外接口为 led_effect_start(effect_id) 和 led_effect_stop()。 约束 1. 不修改 CubeMX 生成的 main.c 初始化逻辑 2. 使用 TIM2 的 PWM 输出频率 1kHz 3. 状态转换用 EffectState 枚举描述禁止阻塞等待 4. 完成后说明硬件上需要接到哪个 GPIO。这种拆法让 AI 的工作边界非常清楚生成结果也更接近真实工程需求。它不需要“发挥想象力”只需要在一个明确的接口框架里填实现这才是正确用法。3.3 入口示例用状态机收敛按键逻辑嵌入式软件架构里有一个反复被提起的话题用状态机收敛复杂度。很多新人写按键逻辑会写成 if-else 堆叠按键多了以后代码根本没法看。Claude Code 在这类重构任务上表现还不错因为它能快速识别人工写的状态枚举、状态转移表并按一致的风格扩展。我当时让它做的是一个按键短按、长按、双击识别。关键不是让它从零写而是先给它现有代码里的状态定义再让它基于新需求画转移条件。以下是它生成的典型骨架typedef enum { KEY_STATE_IDLE, KEY_STATE_PRESSED, KEY_STATE_CONFIRMED } KeyState; typedef struct { KeyState state; uint32_t press_start_tick; uint32_t last_press_tick; } KeyFsm; void key_fsm_run(KeyFsm *fsm, uint8_t key_level, uint32_t now_tick) { switch (fsm-state) { case KEY_STATE_IDLE: if (key_level 0) { fsm-state KEY_STATE_PRESSED; fsm-press_start_tick now_tick; } break; case KEY_STATE_PRESSED: if (key_level 1) { /* 处理短按逻辑 */ fsm-state KEY_STATE_IDLE; } else if (now_tick - fsm-press_start_tick 1000) { /* 处理长按逻辑 */ fsm-state KEY_STATE_CONFIRMED; } break; default: fsm-state KEY_STATE_IDLE; break; } }这段代码并不复杂但 Clulde Code 生成时的价值在于“理解了我要的转移条件”并且按现有工程风格延续而不是另起炉灶。实际落地时我只需要补充消抖去了哪里、什么时候调用 key_fsm_run就能用。这种“半成品→微调”的工作模式比让它一口气生成整个应用真实得多。4. 实战环节从驱动生成到编译烧录的闭环4.1 让 AI 生成外设驱动并核对库函数驱动代码是 Claude Code 在嵌入式场景里最实用的输出之一。STM32 生态最大的特点是 HAL 和 LL 库已经封装好了大部分外设操作对 AI 来说这些 API 模式高度相似它完全有能力生成可用的 UART、I2C、SPI 驱动。但我必须提醒一点AI 生成的驱动寄存器位和函数名可能混淆。比如 I2C 的速率配置有的芯片 HAL 里用I2C_CLOCK_SPEED有的用I2C_TIMINGR不同系列差距很大。我遇到过 AI 给我生成 STM32F4 的 I2C 初始化用的却是 F1 的时序参数编译虽然能过但总线速率完全不对。所以每次生成完至少要人工核对一遍时钟是否使能、引脚复用是否正确、外设时钟源是否匹配。一个加分做法是让 AI 在生成驱动后同时在工程里搜索一下现有代码有没有相同外设的初始化让它顺着旧代码的风格写。比如我之前在做 K210 与 STM32 的 UART 通信时就让 AI 先读工程里已有的usart.c再基于同样的风格写一版 DMA 收发驱动最终代码很快就合进去了。4.2 用 AI 修编译错误和逻辑问题对嵌入式开发来说编译错误有两类语法和类型错误这类让 AI 处理非常高效因为信息都在编译器输出里另一类是链接错误和内存布局问题比如 undefined symbol、Flash 溢出、RAM 溢出这类需要结合链接脚本分析AI 也能给思路但人要盯得更紧。我通常的闭环是自己改完代码后让 AI 执行编译把报错抓回来让它按警告逐条修并要求它解释每个修改原因。这个过程中最重要的一点是——不要让 AI 绕过警告。比如一个变量未使用的 warningAI 有时会直接删掉代码来消警告表面问题没了实际功能却坏了。我后来会在 CLAUDE.md 里明确写未使用的变量优先用(void)var;规避不要随意删除逻辑。4.3 烧录与调试把重复工作交给脚本Claude Code 能执行命令所以烧录这个环节它完全能接管。前提是你要给出一个可以重复执行的烧录命令并且命令已经人工验证过至少一次。我自己的做法是把烧录写成一个脚本然后让 AI 按脚本调用而不是让它在终端里自由发挥否则它可能会加一堆没必要的参数。调试方面目前比较顺的场景是让它看 OpenOCD 的输出、分析 HardFault 的调用栈。有一次程序进 HardFault我把 GDB backtrace 发给它它很快定位到是我在中断里调用了HAL_Delay导致优先级反转和死锁。这种问题从汇编和 backtrace 里人工找也能找但 AI 翻代码、理解上下文的速度确实快能减少我在代码里跳来跳去的时间。但烧录阶段必须有人兜底。我给自己定的规矩是AI 可以执行烧录但不能自动执行“擦除整片 Flash”这种不可逆操作凡是涉及读保护、调试认证、批量擦除的命令全部由人工单独执行。原因很简单AI 对“后果”没有直觉也不了解这块板子对你有多重要。5. 踩过的坑问题排查与避坑实录5.1 烧录报错 “no stm32 target found!” 怎么查这个报错几乎所有玩过 STM32 的人都会遇到。用 Claude Code 或命令行工具烧录时它跳出一句error: no stm32 target found! if your product embedsdebug authentication...后面再接一串提示。看到这个报错先别慌绝大多数情况不是芯片坏了而是连接或保护没解除。我整理了一个排查顺序按概率从高到低排报错现象可能原因排查方向no stm32 target foundST-Link 驱动未安装或连接松动重装驱动换 USB 口检查调试线可以识别但无法连接目标板供电不足单独外部供电检查 3.3V 电压连接成功但烧录失败芯片读保护等级过高先用 STM32CubeProgrammer 解除 RDP提示 debug authentication高端型号启用了调试认证检查 option bytes 和工程里的认证配置虚拟 COM 口黄色感叹号驱动缺失或被占用重装 VCP 驱动换数据线如果是国产兼容型号比如 APM32、GD32 这类直接拿 STM32 的程序烧录理论上可行但要注意烧录时的 IDCODE 和调试配置可能不同建议先用厂商自己的工具测一遍再谈 AI 接管。5.2 别信 AI 的“自信”嵌入式幻觉重灾区Claude Code 最大的优点是能动手最大的风险也是能动手——它会“基于想象”修改代码然后告诉你成功了。我在实际使用里遇到几次典型幻觉第一个是芯片型号幻觉。我明明是 STM32F407它在某个外设配置里用了 F103 的启动文件相关路径编译报错后它还会尝试“修复”结果越改越乱。解决办法是在 CLAUDE.md 里写死“芯片型号是 STM32F407VET6不允许按其他型号修改启动文件或链接脚本”。第二个是库函数幻觉。HAL 库的 API 在不同版本里有些差异AI 训练数据可能包含各种版本有时生成的句柄结构体和当前库不匹配。解决办法是要求它“先查看Drivers/STM32F4xx_HAL_Driver/Inc下的实际定义再写代码”。第三个是时序幻觉。AI 对硬件时序的理解经常过于理想化比如让它优化一个传感器读取流程它可能建议“加个 1 微秒延时”来解决总线不稳但在主频 72MHz 下这个延时根本不够。这种情况下只有真机示波器或逻辑分析仪能验证AI 的“自信”不可作为依据。5.3 在团队项目里用 AI 的协作边界把 Claude Code 引入团队项目除了技术问题协作边界也一定要先聊清楚。第一是代码审查不能省AI 改过的代码同样要走 PR review而且 reviewer 要更仔细地看“AI 为什么这么改”不能因为 AI 自动完成了就放松第二是安全合规涉及公司核心算法、未公开硬件设计、客户相关的代码尽量不要直接丢给云端 AI 工具第三是 git 提交纪律不要允许 AI 顺手做大规模重构。我自己的节奏是AI 在本地做任务拆分和代码生成但我严格限制它的操作范围只允许改它负责的那几个文件不允许动.git目录不允许强制提交。如果它尝试修改超出范围的文件我会立刻中断并纠正。长期用下来Claude Code 更像一个高速但需要不断纠偏的初级工程师不是无人驾驶。提示在 CLAUDE.md 里写清操作边界不仅是为了避免 AI 破坏代码也是为了让团队 review 时知道“哪些改动来自人、哪些来自 AI”责任边界清晰很重要。6. 一点个人的经验收尾写到这里我不打算再总结“本文讲了什么”因为真正有用的东西只有在你打开工程跑通一遍之后才会浮现。我自己的体会是Claude Code 在嵌入式开发里的定位不是替代思考而是把“敲代码、查文档、跑编译”这些占用时间又不需要创造力的环节压缩掉把我有限的精力留给系统设计、边界条件、硬件调测这些 AI 还不太可靠的事情上。有一个小技巧值得分享我会在每周五把这一周里让 AI 干活时踩过的坑以及后来人工修正的内容追加到 CLAUDE.md 的“本周约束”里。一周后看看AI 的坑会明显变少。这就是 Agent 类工具和聊天式 AI 最大的区别——它真的会读你写的规则并把规则执行到下一次任务里。工具在进步我们的工作方式也得跟着变保持谨慎但别拒绝尝试。最后如果你刚开始尝试建议从一个小而完整的模块入手比如一个按键状态机、一个 UART 日志驱动等摸清了 Claude Code 的风格和脾气再逐步扩大到更大的任务。它的上限不低但真正决定工程质量上限的还是你自己那双手。