不知不觉这个系列已经写到第7篇了。前面几篇聊了嵌入式软件怎么融入AI工作流、AI编程的基本思路但一直有个问题绕不开工具链。你想让AI帮你写STM32代码、查Bug、生成初始化函数总得先有个能跑起来的环境而且要是一个AI工具能伸得进手的环境。我用Keil用了好多年但这两年越来越觉得传统IDE在AI编程时代有点跟不上节奏插件体系封闭想接入代码补全和智能对话都很费劲界面和终端也割裂。VS Code就不一样它本质上是一个开放的编辑器底座几乎所有主流的AI编程工具都优先做VS Code插件再加上它本身对嵌入式开发的支持已经成熟到可以日常干活的程度所以这个系列从这一篇开始正式切换到VS Code工作流。这篇文章会把安装VS Code、配置STM32扩展工具链的完整过程写清楚包括为什么这么选、哪些地方容易踩坑、装完之后怎么验证能不能用。适合正在从Keil往VS Code迁移的人也适合刚入行想直接走现代工具链的嵌入式新手。1. 先想清楚为什么嵌入式AI开发绕不开VS Code1.1 传统IDE的困境AI插件根本进不来你可能要说Keil MDK和STM32CubeIDE也是IDE为什么非要折腾VS Code我理解这种想法因为我以前也这么想。但问题在于AI编程这件事本质上是AI工具需要理解你的工程、你的代码、你的编译错误然后给出修改建议这要求IDE必须对外提供足够开放的接口。Keil的插件体系很封闭虽然新版本也支持AC6和部分扩展但跟VS Code的插件生态完全不是一个量级。STM32CubeIDE基于Eclipse理论上能装插件但Eclipse那套体系又重又旧很多AI工具压根不提供Eclipse版本。而VS Code这边GitHub Copilot、通义灵码、Codex、Kimi助手这些全都优先出VS Code插件。你要是用传统IDE等于把AI编程这条路基本堵死了。所以我对这个阶段嵌入式开发者的建议是传统IDE可以继续用来做产线维护、看老工程但新项目和个人技术提升尽量往VS Code这边靠。这不是说传统IDE一无是处而是AI时代的工作流跑在开放生态上这是趋势不是个人偏好。1.2 VS Code对嵌入式的价值不止是好看很多人觉得VS Code只是漂亮、启动快其实对嵌入式开发来说它的核心价值在几个非常实在的点上第一任务系统Tasks可以让你在VS Code里直接编译工程。不管是Makefile工程还是CMake工程配一个tasks.json就能一键编译编译输出直接显示在终端面板里点一下就能跳转到报错的那一行。这个体验比Keil那种双击错误信息才能跳转的方式舒服太多了。第二调试适配器协议DAP配合Cortex-Debug扩展可以直接通过ST-Link/J-Link调试STM32支持查看寄存器、外设、变量、调用栈甚至SVD外设寄存器可视化。它的调试功能和传统IDE相比完全不落下风而且界面更现代化。第三Git集成开箱即用。嵌入式工程这两年也慢慢开始用Git做版本管理了VS Code的源代码管理面板让你的提交、分支、变更对比非常直观AI工具也能基于变更内容帮你写commit信息或者review代码这在传统IDE里很难实现。第四也是最重要的一点命令面板和终端集成的开放性。AI插件可以直接调用你的终端、读取编译诊断信息、读取当前打开的文件内容甚至帮你执行命令并解析输出。这意味着AI不是悬浮在IDE外面而是真正融入了开发流程。1.3 这套方案最终长什么样先说一下这套工具链的整体拓扑后面每一步都是围绕这个架构来的STM32CubeMX生成Makefile形式的GCC工程在VS Code里用tasks.json调用make和arm-none-eabi-gcc完成编译通过Cortex-Debug连接ST-Link做烧录和调试再通过C/C插件的IntelliSense配置让代码提示和语法检查正常工作最后叠加AI编程插件让AI能基于这个环境给出代码建议和修复方案。VS Code是整个流程的枢纽。所有工具、AI插件、调试器、编译器都围绕它工作所以装好VS Code、配好扩展工具是你后面所有AI开发操作的地基。2. VS Code本体安装避开这几个很常见的坑2.1 下载和安装模式的选择VS Code安装本身不复杂但有几个决策点容易被忽略后面会造成麻烦。首先是下载地址去官网code.visualstudio.com即可。安装包里有两个版本User Installer和System Installer。很多人图省事下User Installer但如果你后面要装OpenOCD、ARM工具链这类需要写系统路径的外部工具User Installer在某些环境下会碰到权限不足或者扩展找不到外部程序的情况。我实际遇到过一次User模式下Cortex-Debug调用OpenOCD总是提示找不到文件重装了System Installer才解决。所以我的建议是直接下载System Installer版本避免这种诡异的权限问题。其次是安装路径。VS Code默认装在用户目录下System版本会装在Program Files这个无所谓但要切记路径不要带中文和空格。Windows下如果路径里有空格很多老牌嵌入式工具链的命令行解析会出问题VS Code本身没事但它调用的make和gcc会踩坑所以安装路径尽量控制在纯英文目录。再有一个容易被忽略的点安装完成后VS Code会问你要不要加入PATH。建议勾上添加到PATH没勾的话后面在终端里输入code命令会提示找不到。这个我后面还会再说因为PATH不生效是超高频问题。2.2 安装后的三个基础调整VS Code装好以后先别急着装STM32扩展先把下面几个基础项搞定。第一个是中文界面。虽然英文界面也可以但对中文用户来说VS Code里那些配置项、错误提示的中文化能显著降低心理负担。在扩展面板搜索Chinese (Simplified) Language Pack安装后右下角会提示切换语言重启即可。第二个是开启设置同步。点击左下角齿轮图标选择打开设置同步登录账号后可以把你所有的配置、插件列表、快捷键同步到云端。这个对经常换电脑、或者公司家里两台电脑的人来说非常实用新机器装完VS Code登录账号所有环境自动恢复。AI编程插件的配置也会同步省了再配一遍的时间。第三个是关闭一些不必要的默认行为。比如VS Code默认会检测你的文件编码而STM32的老工程很多是GB2312编码的VS Code默认用UTF-8读取会乱码。我一般会在设置里搜索files.autoGuessEncoding把它勾上这样VS Code会尝试自动猜测编码老工程的注释就不会乱码了。另外在设置里搜files.associations把.s、.inc这些文件关联到对应语言避免语法高亮缺失。2.3 把code命令安装到PATH里这一步很多人不看但实际使用中特别重要。按CtrlShiftP打开命令面板输入Shell Command找到Shell Command: Install code command in PATH执行一次。这之后你就可以在任意终端窗口里输入code .直接打开当前目录对应的VS Code窗口。为什么这个重要因为后面你用AI编程工具的时候很多时候AI会建议你在终端里执行code 某个路径来打开工程或者你自己想快速在VS Code里查看某个源码文件。如果没装这个命令你就得先打开VS Code再手动去文件菜单里找目录效率差很多。而且有些AI插件执行外部命令时依赖这个命令行入口。3. STM32扩展工具链把编辑器变成真正的IDE3.1 先装编译器和调试器再装扩展很多人装VS Code的扩展时特别积极但忽略了VS Code本身不包含编译器和调试器这些是外部工具。你得先把这些工具装好扩展才有东西可以调用。第一个是ARM编译工具链。STM32开发离不开arm-none-eabi-gcc这是GCC针对ARM Cortex-M系列的交叉编译器。去Arm官方下载页面搜Arm GNU Toolchain下载Windows版本安装时建议使用默认路径。这里有个细节新版工具链的路径里可能会带版本号比如C:\Arm GNU Toolchain arm-none-eabi\12.2 rel1\bin这个路径里有空格后面配置的时候一定要处理得当。装完之后务必在终端里验证一下。打开一个新的PowerShell窗口输入arm-none-eabi-gcc --version如果显示版本信息说明安装成功。如果提示无法识别说明PATH没配好需要手动把工具链bin目录添加到系统环境变量PATH里然后重启终端。很多人在VS Code终端里编译找不到编译器都是这个原因。第二个是OpenOCD。OpenOCD是一个开源的片上调试器支持ST-Link、J-Link等多种调试器它负责把你的电脑和STM32芯片连接起来。VS Code的Cortex-Debug扩展通过调用OpenOCD来实现烧录和调试。下载方式有两个一是从xPack社区下载预编译版二是从OpenOCD官网的构建页面找Windows版本。我个人推荐xPack的版本更新及时而且配置简单。第三个是make工具。如果你走CubeMX生成Makefile工程的路线系统里必须要有make。Windows下没有原生make一般通过安装GNU Arm工具链的时候一起带或者单独安装MSYS2/GnuWin32。如果你装的是较新版Arm GNU Toolchain它自带的bin目录里通常会包含make没有就再装一个反正这个工具必须存在于PATH里。3.2 扩展选型官方扩展和第三方扩展怎么选工具链就绪之后再回到VS Code的扩展市场装插件。下面这几个是我实际用了一段时间后觉得必要的分开说明一下各自的定位。第一个是C/C这是微软官方的扩展提供IntelliSense、代码导航、调试支持。IntelliSense的作用是当你输入代码时自动弹出成员列表、参数提示和语法检查。很多嵌入式开发者用VS Code时代码里的宏定义、寄存器定义不识别就是没配好这个扩展的includePath这个后面单独说。第二个是Cortex-Debug这是嵌入式ARM调试的利器负责对接OpenOCD和ST-Link提供启动调试、断点、变量监视、SVD外设寄存器查看等功能。没有了它VS Code就直接失去调试STM32的能力。第三个是STM32 VS Code Extension这是ST官方出的扩展可以用来浏览STM32CubeMX生成的工程、跳转到外设初始化代码、甚至直接以图形化方式查看芯片引脚和时钟树。它的设计思路是让STM32CubeMX和VS Code形成配合。实际使用中它和C/C扩展需要配合好不然会出现加载慢、跳转延迟的问题。第四个是Embedded IDE这是国内开发者写的一个第三方扩展功能非常强大。它最大的特点是能直接导入Keil工程和IAR工程不需要你手动配置一大堆JSON文件自动解析工程里的源文件列表、头文件路径和编译选项。如果你手中有一堆老掉牙的Keil工程想直接让VS Code能看代码、能补全、能编译Embedded IDE是最快的路径。怎么选我的建议是如果你要处理现有Keil工程优先装Embedded IDE如果你是从CubeMX的新项目开始走GCC和CMake路线那官方STM32扩展加上C/C就够了。两者也不冲突可以同时装但要注意新手容易混淆这边提示一下Embedded IDE对Keil工程的支持是它最大的价值而官方扩展对CubeMX生成工程的支持更好。另外还有两个辅助扩展CMake Tools和串口监视器。CMake Tools用来处理用CMake组织代码的工程串口监视器用来跟开发板的串口打印交互。AI编程时串口输出就是你的调试信息很重要。3.3 扩展安装后的关键配置扩展装完之后不建议立刻开始写代码先把配置文件理清楚。VS Code的嵌入式开发配置主要集中在三个文件settings.json全局或工作区设置、c_cpp_properties.jsonC/C插件的头文件搜索路径、tasks.json编译任务配置。其中settings.json可以先配置一部分通用项目。打开VS Code设置Ctrl搜索compilerPath到C/C扩展配置页面里把编译器的完整路径填进去示例{ C_Cpp.default.compilerPath: C:/Arm GNU Toolchain arm-none-eabi/12.2 rel1/bin/arm-none-eabi-gcc.exe, C_Cpp.default.cStandard: c11, C_Cpp.default.cppStandard: c17, C_Cpp.default.intelliSenseMode: gcc-arm, C_Cpp.default.includePath: [ ${workspaceFolder}/**, ${workspaceFolder}/Core/Inc, ${workspaceFolder}/Drivers/STM32F4xx_HAL_Driver/Inc ], C_Cpp.errorSquiggles: enabled }注意几个关键点。compilerPath填的是编译器可执行文件的完整路径需要带.exe后缀路径里的右斜杠要改成左斜杠这是Windows下JSON配置里常见的格式要求。intelliSenseMode设置成gcc-arm告诉C/C扩展这是ARM GCC交叉编译环境。includePath里的路径决定了代码提示和语法检查能识别哪些头文件。如果这里路径不写全那你代码里的一大堆#include都会画红色波浪线。另外我建议在settings.json中把editor.formatOnSave设置为true这样代码保存时自动格式化AI生成的代码尤其需要否则AI写出来的代码缩进风格乱到没法看。4. 导入STM32CubeMX工程让代码能编译能调试4.1 CubeMX端要勾选的选项前面的准备工作都是为了这一刻把一个真实的STM32工程放进VS Code里能编译能调试。我先说CubeMX侧需要怎么设置。在STM32CubeMX中正常配置引脚、时钟、外设之后到Project Manager页签找到Project在Toolchain/IDE下拉框里选择Makefile。这里必须选Makefile因为后面我们在VS Code里以make作为编译驱动。如果你选的是TrueSTUDIO或者Keil那生成出来的工程结构就不是GCC友好的VS Code这边会很别扭。还有一个选项值得注意在Project Manager的Code Generator页签里把Generate peripheral initialization as a pair of .c/.h files per peripheral打开这样每个外设的初始化代码会拆成独立的.c和.h文件VS Code里的文件树更清晰AI插件也能更方便地定位到具体的初始化代码修改点。生成完工程后用VS Code直接打开这个目录。这里就用得上前面说的code命令了你在CubeMX的输出目录里打开终端输入code .VS Code就会以这个工程为工作区启动。4.2 配置c_cpp_properties.json让头文件不再画红线打开工程后你可能立刻被满屏的红色波浪线吓到。不用慌这是因为C/C插件还不知道你的头文件路径和编译参数。新建/编辑.vscode目录下的c_cpp_properties.json配上合适的includePath。下面是一个针对STM32F407工程的实际例子{ configurations: [ { name: STM32, includePath: [ ${workspaceFolder}/Core/Inc, ${workspaceFolder}/Drivers/STM32F4xx_HAL_Driver/Inc, ${workspaceFolder}/Drivers/STM32F4xx_HAL_Driver/Inc/Legacy, ${workspaceFolder}/Drivers/CMSIS/Device/ST/STM32F4xx/Include, ${workspaceFolder}/Drivers/CMSIS/Include ], defines: [ USE_HAL_DRIVER, STM32F407xx ], compilerPath: C:/Arm GNU Toolchain arm-none-eabi/12.2 rel1/bin/arm-none-eabi-gcc.exe, cStandard: c11, intelliSenseMode: gcc-arm } ], version: 4 }define里的USE_HAL_DRIVER和STM32F407xx是根据工程配置里的宏定义来的。如果你的芯片是F103那就是STM32F103xx具体值在CubeMX生成的Makefile里能看到一般形如-DSTM32F407xx这样的宏定义去掉前面的-D填到这里的defines数组里就行。这里我踩过一个大坑includePath区分大小写。Windows文件系统不区分但IntelliSense的引擎在某些版本里是区分路径大小写的之前遇到过驱动目录写成stm32f4xx_hal_driver结果怎么都识别不了改回大写的Drivers/STM32F4xx_HAL_Driver之后立马正常。4.3 用tasks.json配置编译任务一键编译头文件路径解决了接下来要解决工程编译的问题。VS Code里的编译动作是通过任务Task执行的。配置好tasks.json按CtrlShiftB就能自动编译。在.vscode目录下新建tasks.json参考下面这个示例{ version: 2.0.0, tasks: [ { label: STM32 Build, type: shell, command: make, args: [], options: { cwd: ${workspaceFolder} }, problemMatcher: { owner: cpp, fileLocation: [relative, ${workspaceFolder}], pattern: { regexp: ^(.*):(\\d):(\\d):\\s(warning|error):\\s(.*)$, file: 1, line: 2, column: 3, severity: 4, message: 5 } }, group: { kind: build, isDefault: true } } ] }这个配置文件干了三件事第一告诉VS Code在工程根目录执行make命令第二通过problemMatcher把make输出的编译错误信息解析成VS Code里可点击跳转的问题列表第三把编译任务绑定到CtrlShiftB快捷键上。如果make命令提示找不到先检查PATH里是否包含make的路径再重启VS Code。有些Windows环境需要在command里写绝对路径例如C:\Program Files\GNU Arm Embedded Toolchain\bin\make.exe这种情况根据你自己的安装路径调整。编译过程中如果报错少头文件、少宏定义优先回到c_cpp_properties.json里检查。这类报错不是编译链的问题是makefile变量没有传递到VS Code的IntelliSense里需要在c_cpp_properties.json中把对应的宏和头文件路径补全。4.4 用launch.json配置调试连接ST-Link编译能过了烧录调试也得安排上。在.vscode目录下新建launch.json用Cortex-Debug来管控调试会话。参考配置{ version: 0.2.0, configurations: [ { name: Cortex Debug, cwd: ${workspaceFolder}, executable: build/stm32f407.elf, request: launch, type: cortex-debug, servertype: openocd, device: STM32F407VGTx, configFiles: [ interface/stlink.cfg, target/stm32f4x.cfg ], svdFile: STM32F407.svd } ] }executable指向编译生成的ELF文件这个路径要跟你的Makefile输出路径对上如果Makefile把ELF输出到build目录就按上面的写法如果直接输出到根目录改成根目录下的文件名即可。device字段对应芯片型号configFiles里的两个cfg文件是OpenOCD的配置文件针对不同调试器ST-Link、J-Link和不同芯片系列会有不同写法。比如J-Link用户servertype就要换成jlinkconfigFiles可以省略。svdFile是系统视图描述文件用来在调试时以人类可读的方式显示外设寄存器可以从ST官网或者芯片包中获取找不到就不填不影响调试功能只是寄存器查看体验差一些。配置完成后按F5启动调试。如果顺利VS Code下方调试控制台会输出OpenOCD的连接信息然后停在程序的入口处。能走到这一步说明你的VS Code嵌入式开发环境已经真正完整了。5. 接入AI编程能力Copilot、Codex与通义灵码怎么选5.1 环境铺好之后AI插件才是重头戏前面那些配置本质上都是为了把VS Code变成一个AI可以理解和操作的开发环境。传统IDE的问题不是不能写代码而是AI插件没有入口。VS Code装好后接下来要解决的是选哪个AI编程工具来用。现在市面上主流的AI编程插件分两大类。一类是通用代码补全和对话助手代表有GitHub Copilot、通义灵码、Codex、Kimi助手和Codeium等。它们能实现自动补全、根据注释生成代码、选中代码解释、针对编译报错提出建议等功能。另一类是可自定义Skill策略的AI Agent类工具典型代表是Claude Code、Codex的AGENTS.md机制、以及一些支持自定义规则和MCP协议的插件这类工具能深度介入项目修改文件、执行命令、跑编译、看输出形成一个闭环。对嵌入式开发来说我目前实际使用下来的感受是补全类助手适合写外设初始化、协议解析、寄存器操作这类相对模板化的代码Agent类工具适合做跨文件的修改和问题排查比如你让它帮你把整个温度传感器驱动从模拟实现改成数字I2C实现它能自动修改头文件、源文件、Makefile然后编译验证。5.2 嵌入式场景下AI编程的两种典型用法先说说补全和对话助手的用法。STM32开发中有大量重复代码初始化GPIO、配置UART、写定时器PWM输出、处理中断回调。这些代码模式固定AI补全的准确率非常高。我经常做的是在CubeMX里配置好外设生成代码后对某个外设的回调函数不熟悉就直接在VS Code里用对话侧边栏问AI请它解释这个函数的作用甚至让它生成一个基于这个外设的数据处理示例。再比如编译报错以前拿到错误信息要自己逐行看。现在直接复制错误信息给AI它基本能告诉你问题出在哪个宏定义、哪个类型的长度不匹配、哪个外设句柄未定义以及对应的修改方案。这对嵌入式新手来说可以说是降维打击。另一种是Agent类工具里的Skill机制。以Claude Agent为例你可以给项目配置一个STM32专项的Skill目录把相关的参考手册、STM32官方库的要点整理成markdown文档放进去然后定义规则让AI在回答寄存器级问题或生成底层代码时优先查这些材料确保给出的代码符合实际芯片寄存器定义。我自己建的一个最小化Skill结构是这样的skills/stm32-expert/ SKILL.md docs/stm32f4_reference_manual_fragments.mdSKILL.md里写清楚了职责范围和查询规则docs目录下的文档是从STM32参考手册里摘录的寄存器描述和关键时序参数。这样AI在回答问题时会先查看该目录里的手册内容再生成代码而不是凭空编造寄存器名称。实测下来生成的底层代码可靠度明显提高至少不会再出现寄存器名写错这种低级问题。5.3 给AI编程插件的几个关键建议第一AI只是辅助代码审查还得靠你自己。AI生成的HAL库调用经常引入错误的外设句柄比如明明是UART4它能给你用成huart1这种必须在代码审查时抓出来。第二建议给工作区配置一个AI规则文件。Copilot支持项目级规则Claude支持CLAUDE.mdCodex支持AGENTS.md。你可以在里面写清楚这个项目的芯片型号、编译器路径、编码风格、禁止使用某些不存在的库函数等AI每次操作都会自动读取这些规则。嵌入式项目的规则文件尤其重要因为芯片型号错了AI生成的代码可能完全没法用。第三串口日志的解析也可以交给AI。串口监视器插件输出到VS Code终端后你可以把一段串口乱码或者异常日志复制给AI插件让它帮你分析可能的原因。设备初始化失败、DMA超时这类常见问题AI基于经验给出排查方向的速度比你自己翻手册快得多。6. 高频问题排查与实用技巧6.1 include文件红色波浪线怎么彻底消除这个可以说是VS CodeC/C里最高频的问题了。通常分两步排查。第一步检查c_cpp_properties.json中的includePath是否覆盖了所有头文件所在目录尤其是CMSIS的Include目录和芯片相关的Device头文件目录。第二步检查defines是否配置完整少了USE_HAL_DRIVER这个宏HAL库所有的条件编译代码都会失效头文件路径配对了照样满屏报错。如果这两步都检查了还是报错试试CtrlShiftP输入Restart IntelliSense Server重启一下C/C扩展的IntelliSense进程有时候是缓存问题。6.2 VS Code终端里编译提示make不是内部或外部命令这个问题的根源在于PATH没有生效但很多人不知道的是修改Windows环境变量PATH之后已经打开的VS Code终端是读不到新路径的必须重启VS Code。所以修改完PATH后的固定操作顺序是关闭VS Code重新打开终端窗口验证make或arm-none-eabi-gcc能正常执行再重新打开VS Code工作区。还有一种情况是PATH里有工具链路径但VS Code终端用的是PowerShell而PATH格式不正确。可以在PowerShell里执行echo $env:Path查看实际生效的路径列表确认工具链路径真的在里面。6.3 调试器连接不上芯片Cortex-Debug启动后如果报Error: open failed大概率是OpenOCD的配置文件不对或者ST-Link的驱动没有安装好。解决方法是先用ST官方工具ST-Link Utility或者STM32CubeProgrammer确认ST-Link能识别芯片能识别再回来调VS Code。再不行就把launch.json里的configFiles换成更基础的配置比如只保留interface/stlink.cfg和target/stm32f4x.cfg。另外调试模式千万不要在复位引脚上接外部电路否则OpenOCD可能刚启动就报连接失败我因为这个查了好几个小时最后发现是杜邦线短路。6.4 关于AI补全内容不准确时的处理小技巧AI补全崩了不要直接改代码先看它引用的头文件和库函数的上下文。比如AI补全了一个PWM相关API但编译报undefined reference那大概率是CubeMX里没有使能TIM的PWM输出模式。让AI看到错误信息后它会回去改正。我自己用的窍门是每次编译报错就把错误信息完整复制给AI对话插件并附带一句话请根据这个错误修改对应的源代码让AI自动改改完了我再编译验证。来回几次它基本能自己搞定大部分编译错误。7. 最后分享一点自己的体会折腾完这一整套环境我最大的感受是工具链的每一个坑本质上都来自版本不匹配四个字。Arm工具链、OpenOCD、CubeMX生成的工程、Cortex-Debug扩展这些组件彼此之间存在版本兼容关系比如某些新版Arm工具链移除了旧版的一些选项老CubeMX工程可能就编译不过。所以当你遇到奇怪问题时第一反应不是怀疑配置写错而是去检查各组件版本是否匹配。我会在工程里放一个readme记录当前用的工具链版本和环境变量路径方便下次重新部署时直接参考。另外如果你还是觉得VS Code里配置工程太繁琐想省事的话直接从Embedded IDE导入Keil工程或者用ST官方扩展配合CubeMX生成的工程能省掉手动配置JSON的绝大部分工作。工具链搭建本来就是一个越用越顺手的过程第一遍折腾下来第二遍再配其他芯片型号就轻车熟路了。这篇文章把环境这一关过了下一篇我会接着聊怎么把AI编程真正用在STM32的开发流程里包括项目级规则怎么定、AI辅助调试的具体方法到时候我们拿一个实际的STM32工程来练手。
从Keil迁移到VS Code：STM32嵌入式AI开发工具链完整搭建指南
不知不觉这个系列已经写到第7篇了。前面几篇聊了嵌入式软件怎么融入AI工作流、AI编程的基本思路但一直有个问题绕不开工具链。你想让AI帮你写STM32代码、查Bug、生成初始化函数总得先有个能跑起来的环境而且要是一个AI工具能伸得进手的环境。我用Keil用了好多年但这两年越来越觉得传统IDE在AI编程时代有点跟不上节奏插件体系封闭想接入代码补全和智能对话都很费劲界面和终端也割裂。VS Code就不一样它本质上是一个开放的编辑器底座几乎所有主流的AI编程工具都优先做VS Code插件再加上它本身对嵌入式开发的支持已经成熟到可以日常干活的程度所以这个系列从这一篇开始正式切换到VS Code工作流。这篇文章会把安装VS Code、配置STM32扩展工具链的完整过程写清楚包括为什么这么选、哪些地方容易踩坑、装完之后怎么验证能不能用。适合正在从Keil往VS Code迁移的人也适合刚入行想直接走现代工具链的嵌入式新手。1. 先想清楚为什么嵌入式AI开发绕不开VS Code1.1 传统IDE的困境AI插件根本进不来你可能要说Keil MDK和STM32CubeIDE也是IDE为什么非要折腾VS Code我理解这种想法因为我以前也这么想。但问题在于AI编程这件事本质上是AI工具需要理解你的工程、你的代码、你的编译错误然后给出修改建议这要求IDE必须对外提供足够开放的接口。Keil的插件体系很封闭虽然新版本也支持AC6和部分扩展但跟VS Code的插件生态完全不是一个量级。STM32CubeIDE基于Eclipse理论上能装插件但Eclipse那套体系又重又旧很多AI工具压根不提供Eclipse版本。而VS Code这边GitHub Copilot、通义灵码、Codex、Kimi助手这些全都优先出VS Code插件。你要是用传统IDE等于把AI编程这条路基本堵死了。所以我对这个阶段嵌入式开发者的建议是传统IDE可以继续用来做产线维护、看老工程但新项目和个人技术提升尽量往VS Code这边靠。这不是说传统IDE一无是处而是AI时代的工作流跑在开放生态上这是趋势不是个人偏好。1.2 VS Code对嵌入式的价值不止是好看很多人觉得VS Code只是漂亮、启动快其实对嵌入式开发来说它的核心价值在几个非常实在的点上第一任务系统Tasks可以让你在VS Code里直接编译工程。不管是Makefile工程还是CMake工程配一个tasks.json就能一键编译编译输出直接显示在终端面板里点一下就能跳转到报错的那一行。这个体验比Keil那种双击错误信息才能跳转的方式舒服太多了。第二调试适配器协议DAP配合Cortex-Debug扩展可以直接通过ST-Link/J-Link调试STM32支持查看寄存器、外设、变量、调用栈甚至SVD外设寄存器可视化。它的调试功能和传统IDE相比完全不落下风而且界面更现代化。第三Git集成开箱即用。嵌入式工程这两年也慢慢开始用Git做版本管理了VS Code的源代码管理面板让你的提交、分支、变更对比非常直观AI工具也能基于变更内容帮你写commit信息或者review代码这在传统IDE里很难实现。第四也是最重要的一点命令面板和终端集成的开放性。AI插件可以直接调用你的终端、读取编译诊断信息、读取当前打开的文件内容甚至帮你执行命令并解析输出。这意味着AI不是悬浮在IDE外面而是真正融入了开发流程。1.3 这套方案最终长什么样先说一下这套工具链的整体拓扑后面每一步都是围绕这个架构来的STM32CubeMX生成Makefile形式的GCC工程在VS Code里用tasks.json调用make和arm-none-eabi-gcc完成编译通过Cortex-Debug连接ST-Link做烧录和调试再通过C/C插件的IntelliSense配置让代码提示和语法检查正常工作最后叠加AI编程插件让AI能基于这个环境给出代码建议和修复方案。VS Code是整个流程的枢纽。所有工具、AI插件、调试器、编译器都围绕它工作所以装好VS Code、配好扩展工具是你后面所有AI开发操作的地基。2. VS Code本体安装避开这几个很常见的坑2.1 下载和安装模式的选择VS Code安装本身不复杂但有几个决策点容易被忽略后面会造成麻烦。首先是下载地址去官网code.visualstudio.com即可。安装包里有两个版本User Installer和System Installer。很多人图省事下User Installer但如果你后面要装OpenOCD、ARM工具链这类需要写系统路径的外部工具User Installer在某些环境下会碰到权限不足或者扩展找不到外部程序的情况。我实际遇到过一次User模式下Cortex-Debug调用OpenOCD总是提示找不到文件重装了System Installer才解决。所以我的建议是直接下载System Installer版本避免这种诡异的权限问题。其次是安装路径。VS Code默认装在用户目录下System版本会装在Program Files这个无所谓但要切记路径不要带中文和空格。Windows下如果路径里有空格很多老牌嵌入式工具链的命令行解析会出问题VS Code本身没事但它调用的make和gcc会踩坑所以安装路径尽量控制在纯英文目录。再有一个容易被忽略的点安装完成后VS Code会问你要不要加入PATH。建议勾上添加到PATH没勾的话后面在终端里输入code命令会提示找不到。这个我后面还会再说因为PATH不生效是超高频问题。2.2 安装后的三个基础调整VS Code装好以后先别急着装STM32扩展先把下面几个基础项搞定。第一个是中文界面。虽然英文界面也可以但对中文用户来说VS Code里那些配置项、错误提示的中文化能显著降低心理负担。在扩展面板搜索Chinese (Simplified) Language Pack安装后右下角会提示切换语言重启即可。第二个是开启设置同步。点击左下角齿轮图标选择打开设置同步登录账号后可以把你所有的配置、插件列表、快捷键同步到云端。这个对经常换电脑、或者公司家里两台电脑的人来说非常实用新机器装完VS Code登录账号所有环境自动恢复。AI编程插件的配置也会同步省了再配一遍的时间。第三个是关闭一些不必要的默认行为。比如VS Code默认会检测你的文件编码而STM32的老工程很多是GB2312编码的VS Code默认用UTF-8读取会乱码。我一般会在设置里搜索files.autoGuessEncoding把它勾上这样VS Code会尝试自动猜测编码老工程的注释就不会乱码了。另外在设置里搜files.associations把.s、.inc这些文件关联到对应语言避免语法高亮缺失。2.3 把code命令安装到PATH里这一步很多人不看但实际使用中特别重要。按CtrlShiftP打开命令面板输入Shell Command找到Shell Command: Install code command in PATH执行一次。这之后你就可以在任意终端窗口里输入code .直接打开当前目录对应的VS Code窗口。为什么这个重要因为后面你用AI编程工具的时候很多时候AI会建议你在终端里执行code 某个路径来打开工程或者你自己想快速在VS Code里查看某个源码文件。如果没装这个命令你就得先打开VS Code再手动去文件菜单里找目录效率差很多。而且有些AI插件执行外部命令时依赖这个命令行入口。3. STM32扩展工具链把编辑器变成真正的IDE3.1 先装编译器和调试器再装扩展很多人装VS Code的扩展时特别积极但忽略了VS Code本身不包含编译器和调试器这些是外部工具。你得先把这些工具装好扩展才有东西可以调用。第一个是ARM编译工具链。STM32开发离不开arm-none-eabi-gcc这是GCC针对ARM Cortex-M系列的交叉编译器。去Arm官方下载页面搜Arm GNU Toolchain下载Windows版本安装时建议使用默认路径。这里有个细节新版工具链的路径里可能会带版本号比如C:\Arm GNU Toolchain arm-none-eabi\12.2 rel1\bin这个路径里有空格后面配置的时候一定要处理得当。装完之后务必在终端里验证一下。打开一个新的PowerShell窗口输入arm-none-eabi-gcc --version如果显示版本信息说明安装成功。如果提示无法识别说明PATH没配好需要手动把工具链bin目录添加到系统环境变量PATH里然后重启终端。很多人在VS Code终端里编译找不到编译器都是这个原因。第二个是OpenOCD。OpenOCD是一个开源的片上调试器支持ST-Link、J-Link等多种调试器它负责把你的电脑和STM32芯片连接起来。VS Code的Cortex-Debug扩展通过调用OpenOCD来实现烧录和调试。下载方式有两个一是从xPack社区下载预编译版二是从OpenOCD官网的构建页面找Windows版本。我个人推荐xPack的版本更新及时而且配置简单。第三个是make工具。如果你走CubeMX生成Makefile工程的路线系统里必须要有make。Windows下没有原生make一般通过安装GNU Arm工具链的时候一起带或者单独安装MSYS2/GnuWin32。如果你装的是较新版Arm GNU Toolchain它自带的bin目录里通常会包含make没有就再装一个反正这个工具必须存在于PATH里。3.2 扩展选型官方扩展和第三方扩展怎么选工具链就绪之后再回到VS Code的扩展市场装插件。下面这几个是我实际用了一段时间后觉得必要的分开说明一下各自的定位。第一个是C/C这是微软官方的扩展提供IntelliSense、代码导航、调试支持。IntelliSense的作用是当你输入代码时自动弹出成员列表、参数提示和语法检查。很多嵌入式开发者用VS Code时代码里的宏定义、寄存器定义不识别就是没配好这个扩展的includePath这个后面单独说。第二个是Cortex-Debug这是嵌入式ARM调试的利器负责对接OpenOCD和ST-Link提供启动调试、断点、变量监视、SVD外设寄存器查看等功能。没有了它VS Code就直接失去调试STM32的能力。第三个是STM32 VS Code Extension这是ST官方出的扩展可以用来浏览STM32CubeMX生成的工程、跳转到外设初始化代码、甚至直接以图形化方式查看芯片引脚和时钟树。它的设计思路是让STM32CubeMX和VS Code形成配合。实际使用中它和C/C扩展需要配合好不然会出现加载慢、跳转延迟的问题。第四个是Embedded IDE这是国内开发者写的一个第三方扩展功能非常强大。它最大的特点是能直接导入Keil工程和IAR工程不需要你手动配置一大堆JSON文件自动解析工程里的源文件列表、头文件路径和编译选项。如果你手中有一堆老掉牙的Keil工程想直接让VS Code能看代码、能补全、能编译Embedded IDE是最快的路径。怎么选我的建议是如果你要处理现有Keil工程优先装Embedded IDE如果你是从CubeMX的新项目开始走GCC和CMake路线那官方STM32扩展加上C/C就够了。两者也不冲突可以同时装但要注意新手容易混淆这边提示一下Embedded IDE对Keil工程的支持是它最大的价值而官方扩展对CubeMX生成工程的支持更好。另外还有两个辅助扩展CMake Tools和串口监视器。CMake Tools用来处理用CMake组织代码的工程串口监视器用来跟开发板的串口打印交互。AI编程时串口输出就是你的调试信息很重要。3.3 扩展安装后的关键配置扩展装完之后不建议立刻开始写代码先把配置文件理清楚。VS Code的嵌入式开发配置主要集中在三个文件settings.json全局或工作区设置、c_cpp_properties.jsonC/C插件的头文件搜索路径、tasks.json编译任务配置。其中settings.json可以先配置一部分通用项目。打开VS Code设置Ctrl搜索compilerPath到C/C扩展配置页面里把编译器的完整路径填进去示例{ C_Cpp.default.compilerPath: C:/Arm GNU Toolchain arm-none-eabi/12.2 rel1/bin/arm-none-eabi-gcc.exe, C_Cpp.default.cStandard: c11, C_Cpp.default.cppStandard: c17, C_Cpp.default.intelliSenseMode: gcc-arm, C_Cpp.default.includePath: [ ${workspaceFolder}/**, ${workspaceFolder}/Core/Inc, ${workspaceFolder}/Drivers/STM32F4xx_HAL_Driver/Inc ], C_Cpp.errorSquiggles: enabled }注意几个关键点。compilerPath填的是编译器可执行文件的完整路径需要带.exe后缀路径里的右斜杠要改成左斜杠这是Windows下JSON配置里常见的格式要求。intelliSenseMode设置成gcc-arm告诉C/C扩展这是ARM GCC交叉编译环境。includePath里的路径决定了代码提示和语法检查能识别哪些头文件。如果这里路径不写全那你代码里的一大堆#include都会画红色波浪线。另外我建议在settings.json中把editor.formatOnSave设置为true这样代码保存时自动格式化AI生成的代码尤其需要否则AI写出来的代码缩进风格乱到没法看。4. 导入STM32CubeMX工程让代码能编译能调试4.1 CubeMX端要勾选的选项前面的准备工作都是为了这一刻把一个真实的STM32工程放进VS Code里能编译能调试。我先说CubeMX侧需要怎么设置。在STM32CubeMX中正常配置引脚、时钟、外设之后到Project Manager页签找到Project在Toolchain/IDE下拉框里选择Makefile。这里必须选Makefile因为后面我们在VS Code里以make作为编译驱动。如果你选的是TrueSTUDIO或者Keil那生成出来的工程结构就不是GCC友好的VS Code这边会很别扭。还有一个选项值得注意在Project Manager的Code Generator页签里把Generate peripheral initialization as a pair of .c/.h files per peripheral打开这样每个外设的初始化代码会拆成独立的.c和.h文件VS Code里的文件树更清晰AI插件也能更方便地定位到具体的初始化代码修改点。生成完工程后用VS Code直接打开这个目录。这里就用得上前面说的code命令了你在CubeMX的输出目录里打开终端输入code .VS Code就会以这个工程为工作区启动。4.2 配置c_cpp_properties.json让头文件不再画红线打开工程后你可能立刻被满屏的红色波浪线吓到。不用慌这是因为C/C插件还不知道你的头文件路径和编译参数。新建/编辑.vscode目录下的c_cpp_properties.json配上合适的includePath。下面是一个针对STM32F407工程的实际例子{ configurations: [ { name: STM32, includePath: [ ${workspaceFolder}/Core/Inc, ${workspaceFolder}/Drivers/STM32F4xx_HAL_Driver/Inc, ${workspaceFolder}/Drivers/STM32F4xx_HAL_Driver/Inc/Legacy, ${workspaceFolder}/Drivers/CMSIS/Device/ST/STM32F4xx/Include, ${workspaceFolder}/Drivers/CMSIS/Include ], defines: [ USE_HAL_DRIVER, STM32F407xx ], compilerPath: C:/Arm GNU Toolchain arm-none-eabi/12.2 rel1/bin/arm-none-eabi-gcc.exe, cStandard: c11, intelliSenseMode: gcc-arm } ], version: 4 }define里的USE_HAL_DRIVER和STM32F407xx是根据工程配置里的宏定义来的。如果你的芯片是F103那就是STM32F103xx具体值在CubeMX生成的Makefile里能看到一般形如-DSTM32F407xx这样的宏定义去掉前面的-D填到这里的defines数组里就行。这里我踩过一个大坑includePath区分大小写。Windows文件系统不区分但IntelliSense的引擎在某些版本里是区分路径大小写的之前遇到过驱动目录写成stm32f4xx_hal_driver结果怎么都识别不了改回大写的Drivers/STM32F4xx_HAL_Driver之后立马正常。4.3 用tasks.json配置编译任务一键编译头文件路径解决了接下来要解决工程编译的问题。VS Code里的编译动作是通过任务Task执行的。配置好tasks.json按CtrlShiftB就能自动编译。在.vscode目录下新建tasks.json参考下面这个示例{ version: 2.0.0, tasks: [ { label: STM32 Build, type: shell, command: make, args: [], options: { cwd: ${workspaceFolder} }, problemMatcher: { owner: cpp, fileLocation: [relative, ${workspaceFolder}], pattern: { regexp: ^(.*):(\\d):(\\d):\\s(warning|error):\\s(.*)$, file: 1, line: 2, column: 3, severity: 4, message: 5 } }, group: { kind: build, isDefault: true } } ] }这个配置文件干了三件事第一告诉VS Code在工程根目录执行make命令第二通过problemMatcher把make输出的编译错误信息解析成VS Code里可点击跳转的问题列表第三把编译任务绑定到CtrlShiftB快捷键上。如果make命令提示找不到先检查PATH里是否包含make的路径再重启VS Code。有些Windows环境需要在command里写绝对路径例如C:\Program Files\GNU Arm Embedded Toolchain\bin\make.exe这种情况根据你自己的安装路径调整。编译过程中如果报错少头文件、少宏定义优先回到c_cpp_properties.json里检查。这类报错不是编译链的问题是makefile变量没有传递到VS Code的IntelliSense里需要在c_cpp_properties.json中把对应的宏和头文件路径补全。4.4 用launch.json配置调试连接ST-Link编译能过了烧录调试也得安排上。在.vscode目录下新建launch.json用Cortex-Debug来管控调试会话。参考配置{ version: 0.2.0, configurations: [ { name: Cortex Debug, cwd: ${workspaceFolder}, executable: build/stm32f407.elf, request: launch, type: cortex-debug, servertype: openocd, device: STM32F407VGTx, configFiles: [ interface/stlink.cfg, target/stm32f4x.cfg ], svdFile: STM32F407.svd } ] }executable指向编译生成的ELF文件这个路径要跟你的Makefile输出路径对上如果Makefile把ELF输出到build目录就按上面的写法如果直接输出到根目录改成根目录下的文件名即可。device字段对应芯片型号configFiles里的两个cfg文件是OpenOCD的配置文件针对不同调试器ST-Link、J-Link和不同芯片系列会有不同写法。比如J-Link用户servertype就要换成jlinkconfigFiles可以省略。svdFile是系统视图描述文件用来在调试时以人类可读的方式显示外设寄存器可以从ST官网或者芯片包中获取找不到就不填不影响调试功能只是寄存器查看体验差一些。配置完成后按F5启动调试。如果顺利VS Code下方调试控制台会输出OpenOCD的连接信息然后停在程序的入口处。能走到这一步说明你的VS Code嵌入式开发环境已经真正完整了。5. 接入AI编程能力Copilot、Codex与通义灵码怎么选5.1 环境铺好之后AI插件才是重头戏前面那些配置本质上都是为了把VS Code变成一个AI可以理解和操作的开发环境。传统IDE的问题不是不能写代码而是AI插件没有入口。VS Code装好后接下来要解决的是选哪个AI编程工具来用。现在市面上主流的AI编程插件分两大类。一类是通用代码补全和对话助手代表有GitHub Copilot、通义灵码、Codex、Kimi助手和Codeium等。它们能实现自动补全、根据注释生成代码、选中代码解释、针对编译报错提出建议等功能。另一类是可自定义Skill策略的AI Agent类工具典型代表是Claude Code、Codex的AGENTS.md机制、以及一些支持自定义规则和MCP协议的插件这类工具能深度介入项目修改文件、执行命令、跑编译、看输出形成一个闭环。对嵌入式开发来说我目前实际使用下来的感受是补全类助手适合写外设初始化、协议解析、寄存器操作这类相对模板化的代码Agent类工具适合做跨文件的修改和问题排查比如你让它帮你把整个温度传感器驱动从模拟实现改成数字I2C实现它能自动修改头文件、源文件、Makefile然后编译验证。5.2 嵌入式场景下AI编程的两种典型用法先说说补全和对话助手的用法。STM32开发中有大量重复代码初始化GPIO、配置UART、写定时器PWM输出、处理中断回调。这些代码模式固定AI补全的准确率非常高。我经常做的是在CubeMX里配置好外设生成代码后对某个外设的回调函数不熟悉就直接在VS Code里用对话侧边栏问AI请它解释这个函数的作用甚至让它生成一个基于这个外设的数据处理示例。再比如编译报错以前拿到错误信息要自己逐行看。现在直接复制错误信息给AI它基本能告诉你问题出在哪个宏定义、哪个类型的长度不匹配、哪个外设句柄未定义以及对应的修改方案。这对嵌入式新手来说可以说是降维打击。另一种是Agent类工具里的Skill机制。以Claude Agent为例你可以给项目配置一个STM32专项的Skill目录把相关的参考手册、STM32官方库的要点整理成markdown文档放进去然后定义规则让AI在回答寄存器级问题或生成底层代码时优先查这些材料确保给出的代码符合实际芯片寄存器定义。我自己建的一个最小化Skill结构是这样的skills/stm32-expert/ SKILL.md docs/stm32f4_reference_manual_fragments.mdSKILL.md里写清楚了职责范围和查询规则docs目录下的文档是从STM32参考手册里摘录的寄存器描述和关键时序参数。这样AI在回答问题时会先查看该目录里的手册内容再生成代码而不是凭空编造寄存器名称。实测下来生成的底层代码可靠度明显提高至少不会再出现寄存器名写错这种低级问题。5.3 给AI编程插件的几个关键建议第一AI只是辅助代码审查还得靠你自己。AI生成的HAL库调用经常引入错误的外设句柄比如明明是UART4它能给你用成huart1这种必须在代码审查时抓出来。第二建议给工作区配置一个AI规则文件。Copilot支持项目级规则Claude支持CLAUDE.mdCodex支持AGENTS.md。你可以在里面写清楚这个项目的芯片型号、编译器路径、编码风格、禁止使用某些不存在的库函数等AI每次操作都会自动读取这些规则。嵌入式项目的规则文件尤其重要因为芯片型号错了AI生成的代码可能完全没法用。第三串口日志的解析也可以交给AI。串口监视器插件输出到VS Code终端后你可以把一段串口乱码或者异常日志复制给AI插件让它帮你分析可能的原因。设备初始化失败、DMA超时这类常见问题AI基于经验给出排查方向的速度比你自己翻手册快得多。6. 高频问题排查与实用技巧6.1 include文件红色波浪线怎么彻底消除这个可以说是VS CodeC/C里最高频的问题了。通常分两步排查。第一步检查c_cpp_properties.json中的includePath是否覆盖了所有头文件所在目录尤其是CMSIS的Include目录和芯片相关的Device头文件目录。第二步检查defines是否配置完整少了USE_HAL_DRIVER这个宏HAL库所有的条件编译代码都会失效头文件路径配对了照样满屏报错。如果这两步都检查了还是报错试试CtrlShiftP输入Restart IntelliSense Server重启一下C/C扩展的IntelliSense进程有时候是缓存问题。6.2 VS Code终端里编译提示make不是内部或外部命令这个问题的根源在于PATH没有生效但很多人不知道的是修改Windows环境变量PATH之后已经打开的VS Code终端是读不到新路径的必须重启VS Code。所以修改完PATH后的固定操作顺序是关闭VS Code重新打开终端窗口验证make或arm-none-eabi-gcc能正常执行再重新打开VS Code工作区。还有一种情况是PATH里有工具链路径但VS Code终端用的是PowerShell而PATH格式不正确。可以在PowerShell里执行echo $env:Path查看实际生效的路径列表确认工具链路径真的在里面。6.3 调试器连接不上芯片Cortex-Debug启动后如果报Error: open failed大概率是OpenOCD的配置文件不对或者ST-Link的驱动没有安装好。解决方法是先用ST官方工具ST-Link Utility或者STM32CubeProgrammer确认ST-Link能识别芯片能识别再回来调VS Code。再不行就把launch.json里的configFiles换成更基础的配置比如只保留interface/stlink.cfg和target/stm32f4x.cfg。另外调试模式千万不要在复位引脚上接外部电路否则OpenOCD可能刚启动就报连接失败我因为这个查了好几个小时最后发现是杜邦线短路。6.4 关于AI补全内容不准确时的处理小技巧AI补全崩了不要直接改代码先看它引用的头文件和库函数的上下文。比如AI补全了一个PWM相关API但编译报undefined reference那大概率是CubeMX里没有使能TIM的PWM输出模式。让AI看到错误信息后它会回去改正。我自己用的窍门是每次编译报错就把错误信息完整复制给AI对话插件并附带一句话请根据这个错误修改对应的源代码让AI自动改改完了我再编译验证。来回几次它基本能自己搞定大部分编译错误。7. 最后分享一点自己的体会折腾完这一整套环境我最大的感受是工具链的每一个坑本质上都来自版本不匹配四个字。Arm工具链、OpenOCD、CubeMX生成的工程、Cortex-Debug扩展这些组件彼此之间存在版本兼容关系比如某些新版Arm工具链移除了旧版的一些选项老CubeMX工程可能就编译不过。所以当你遇到奇怪问题时第一反应不是怀疑配置写错而是去检查各组件版本是否匹配。我会在工程里放一个readme记录当前用的工具链版本和环境变量路径方便下次重新部署时直接参考。另外如果你还是觉得VS Code里配置工程太繁琐想省事的话直接从Embedded IDE导入Keil工程或者用ST官方扩展配合CubeMX生成的工程能省掉手动配置JSON的绝大部分工作。工具链搭建本来就是一个越用越顺手的过程第一遍折腾下来第二遍再配其他芯片型号就轻车熟路了。这篇文章把环境这一关过了下一篇我会接着聊怎么把AI编程真正用在STM32的开发流程里包括项目级规则怎么定、AI辅助调试的具体方法到时候我们拿一个实际的STM32工程来练手。
