1. 从 Keil 到 VS Code嵌入式 AI 编程的开发环境为什么非换不可老生常谈的问题先放前面嵌入式软件 AI 编程听起来很高大上但落到实操层面第一道坎永远是开发环境。如果你还在用 Keil uVision 写 STM32近几年一定有一种很强烈的“割裂感”——编辑器里没有智能补全、没有 Git 集成、没有代码格式化更别提像 Kimi、DeepSeek、通义灵码这类 AI 编程助手接入 VS Code 后带来的效率跃升。我并不是说 Keil 一无是处而是面对“AI 编程”这个新时代需求VS Code 几乎是为它量身打造的容器。回到标题本身——【嵌入式软件AI编程】第 7 篇安装 VS Code 与 STM32 扩展工具。这篇文章的目标非常明确就是带你从 0 到 1 搭好一套能用 AI 辅助撸 STM32 代码的开发环境。我会从下载 VS Code 开始一直讲到编译、烧录、调试全链路跑通中间穿插我在实际迁移过程中踩过的坑和总结出来的经验尤其是那些常规教程里不会告诉你、但几乎每个新手都会栽进去的细节。先说一个被很多人忽略的结论VS Code 本质上不是一个 IDE而是一个编辑器框架。它本身不认识 STM32、不懂 C 语言更不会编译固件。但它提供了三样 Keil 给不了的东西——低延迟的代码索引能力、丰富的远程开发支持、以及能接入各类大模型 API 的 AI 插件生态。STM32 扩展工具在其中的角色是把编译器、调试器、烧录工具这些传统 IDE 的“内置能力”拆解成一个个可替换、可配置的积木让编辑器本身专注于最擅长的“文本编辑与语义理解”。理解了这一点下面每一步安装都是为了把这些积木精准拼装到位。在开始动手之前我再多嘴一句无论你是准备搞 STM32 车载以太网还是业余时间做个智能鱼缸甚至只是完成一个毕设这套环境搭建思路完全通用。不要被网上那些零散教程劝退跟着本文的节奏走大概 40 分钟就能全部搞定。2. 破冰第一步VS Code 安装与适合嵌入式的环境配置2.1 下载安装包时的两个关键选项VS Code 官网的下载地址并不难找但我建议你用系统安装包System Installer而不是用户安装包User Installer。原因在于嵌入式开发经常需要把 VS Code 的命令行工具加入系统 PATH系统安装包在这方面更稳而且后续调用code命令时会少很多权限上的麻烦。安装过程中有三个勾选一定不要漏勾选“添加到 PATH”这一步决定你后续能不能直接在终端输入code打开项目。勾选“支持 UTF-8 编码”日常写代码可能感觉不到但一旦你打开带有中文注释的 STM32 工程编码问题会导致编辑器里满屏乱码非常影响心情。勾选“通过 Code 打开操作”方便你在资源管理器里右键直接打开项目文件夹。安装路径可以自定义我个人的习惯是D:\VSCode避免放到C:\Program Files下。倒不是说会出什么大问题只是切换到 WSL 或远程开发时路径里的空格偶尔会引发一些莫名其妙的环境变量解析错误。2.2 首次启动应当立即调整的三种设置安装完成后首次启动新手最容易犯的错误是直接开写代码结果发现代码提示慢、终端编码乱、文件目录树不显示。我在实际使用中整理出三个值得第一时间改掉的配置打开设置面板Ctrl ,搜索files.encoding将编码改为utf8。Windows 默认的中文环境是 GBKSTM32 工程里如果有老代码用 GBK 注释VS Code 可能识别异常。改成 UTF-8 后新的工程和主流的 CubeMX 生成代码都能完美兼容。搜索editor.acceptSuggestionOnCommit将这个选项关闭。原因在于在使用 AI 编程插件时补全弹窗和 AI 生成代码经常打架关闭回车接受建议能避免误操作导致 AI 生成内容被直接覆盖。这个设置极其重要算是我们电子工程师转向 AI 编程时的一个防误伤策略。搜索files.exclude把.git、Debug、Release目录加入到排除列表。STM32 工程编译一次会生成大量中间文件不让它们在资源管理器里出现查找源码时才会眼不花、心不烦。2.3 安装中文语言包的取舍这个问题见仁见智。我自己的主观感受是VS Code 的英文界面配合 AI 编程工具使用时上下文语义更清晰尤其当你准备把项目描述喂给 AI 大模型时英文界面能减少模型对 UI 文字的干扰。不过如果你没有英文界面需求直接安装Chinese (Simplified) (简体中文)语言包即可——安装后右下角会提示重启重启之后界面全部变为中文学习成本会低很多。3. 解锁 STM32 核心扩展CubeMX 工程与 VS Code 的无缝对接3.1 必装的四款扩展少一个都会踩坑VS Code 的扩展市场里和 STM32 相关的插件数量并不少但真正稳定可靠、值得长期使用的我认为只有四款扩展名发布者核心作用是否必装C/CMicrosoft提供 IntelliSense 代码提示、调试支持必装Cortex-Debugmarus25支持 ST-Link / J-Link 调试查看寄存器必装STM32 VS Code ExtensionSTMicroelectronics官方出品直接导入 CubeMX 工程必装ARMMicrosoft提供 ARM 汇编语法高亮和反汇编支持推荐具体安装方法很简单左侧扩展面板Ctrl Shift X搜索名称点击安装即可。这里特别说明一下网上很多教程会让你安装 “Embedded Tools” 或 “CMake Tools”这些不是必须的。如果使用 STM32 官方扩展配合 CubeMX 生成的 Makefile 工程完全可以绕开 CMake减少配置环节。我后面会解释为什么这样选择。3.2 STM32CubeMX 生成工程时的一个四两拨千斤勾选很多人在 VS Code 里打开 CubeMX 生成的工程后发现头文件路径全部飘红IntelliSense 完全失灵。根本原因是在生成工程时工具链Toolchain选错了。正确的做法是在 CubeMX 里完成芯片型号选择、外设配置和时钟树配置后点击Project Manager - Project其中Toolchain / IDE这一项如果你打算用 VS Code 且不想折腾 CMake就选Makefile如果你打算体验现代构建流程选CMake也可以但不推荐新手一开始就这么干。选好 Makefile 后在Code Generator选项卡里勾选Generate peripheral initialization as a pair of .c/.h files per peripheral。这个选项的作用是让每个外设的初始化代码单独生成一个.c/.h文件而不是全部堆在main.c里。别小看这个设置它直接决定了后续 AI 编程工具能否精准定位到你需要的初始化函数。将外设代码模块化之后AI 插件在理解项目结构时可以更准确地根据文件路径寻找上下文。生成完工程后用 VS Code 直接打开这个工程文件夹接下来就到了最关键的一步——配置c_cpp_properties.json让 IntelliSense 正确找到 STM32 的寄存器定义和 HAL 库头文件。3.3 手把手配置 c_cpp_properties.json告别红色波浪线在命令面板Ctrl Shift P中输入C/C: Edit Configurations (JSON)会生成一个.vscode/c_cpp_properties.json文件。对于 STM32 工程核心配置如下{ configurations: [ { name: STM32, includePath: [ ${workspaceFolder}/**, ${workspaceFolder}/Core/Inc, ${workspaceFolder}/Drivers/STM32F1xx_HAL_Driver/Inc, ${workspaceFolder}/Drivers/CMSIS/Device/ST/STM32F1xx/Include, ${workspaceFolder}/Drivers/CMSIS/Include ], defines: [ USE_HAL_DRIVER, STM32F103xB ], cStandard: c11, intelliSenseMode: gcc-arm, compilerPath: C:/STM32CubeIDE/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.*/tools/bin/arm-none-eabi-gcc.exe } ], version: 4 }这里有一个关键点大家容易含糊defines中的USE_HAL_DRIVER一定不能少它是 HAL 库源码中使用条件编译的核心开关STM32F103xB则要根据你实际的芯片型号来写F103C8T6 写STM32F103xBF103ZET6 写STM32F103xE。写错了 HAL 库中很大一部分代码会被直接排除在编译之外编辑器里看不出来但编译时错误铺天盖地。关于compilerPath如果你的电脑上安装了 STM32CubeIDE可以直接复用它的内置编译器路径。这样做的好处是版本与固件包完全匹配避免因编译器版本升级带来的不兼容问题。如果你的电脑上没有 STM32CubeIDE也可以用arm-none-eabi-gcc的独立安装包稍后我会详细讲解工具链的安装方式。4. 是骡子是马拉出来遛遛从编译烧录到断点调试4.1 Windows 下安装 GNU ARM 工具链的细节编译 STM32 工程离不开arm-none-eabi-gcc工具链。官网下载地址是 Arm Developer下载.exe安装包后一路 Next 即可。但我建议你在安装时将安装路径简化比如C:\arm-gcc避免默认路径中带空格和长目录名。工具链安装完成之后打开 VS Code 终端Ctrl 输入arm-none-eabi-gcc --version如果显示版本号且不是“无法识别”的提示说明 PATH 设置成功。如果提示命令不存在则需要把C:\arm-gcc\bin手动加入系统环境变量 PATH然后重启 VS Code。这个环节在 CSDN 上被问爆了的问题“arm-none-eabi-gcc 不是内部或外部命令”基本都是因为改完环境变量没有重启 VS Code 造成的。VS Code 的终端环境变量快照不是实时更新的这一点跟 Keil 很不一样——Keil 的编译器路径全写在工具链配置里VS Code 则依赖系统环境变量。一个小经验改完环境变量之后务必完全关闭 VS Code 再重新打开而不是只关终端窗口。4.2 用 tasks.json 让 F7 一键编译STM32 的工程编译本质上就是在终端执行make命令。VS Code 里的“任务Tasks”机制可以把这条命令绑定到一个快捷键上。在.vscode目录下创建tasks.json填入下面的配置{ version: 2.0.0, tasks: [ { label: Build STM32, type: shell, command: make, args: [-j8], options: { cwd: ${workspaceFolder} }, group: { kind: build, isDefault: true }, problemMatcher: [$gcc] } ] }这里的-j8表示 8 线程并行编译具体数字根据电脑 CPU 核数调整。problemMatcher: [$gcc]的作用是让 VS Code 能自动解析编译输出中的错误信息把具体报错行号直接标在源码编辑器中点击错误即可跳转到对应代码行。这个体验比 Keil 的 Build Output 窗口好得多也是很多工程师迁移之后回不去的重要原因之一。配置完成后按Ctrl Shift B即可触发编译。正常情况下终端会滚动输出编译信息最后显示没有错误。如果有错误VS Code 的“问题面板”会直接推出红色的错误列表。4.3 ST-Link 烧录有两种路径各有利弊编译通过之后就是烧录。烧录工具我推荐两个第一种是 STM32CubeProgrammer 的命令行模式。安装 STM32CubeProgrammer 后会自带命令行工具STM32_Programmer_CLI在 VS Code 的tasks.json里新增一个烧录任务{ label: Flash STM32, type: shell, command: STM32_Programmer_CLI, args: [-c, portSWD, -w, ${workspaceFolder}/build/*.elf, -v, hard] }这种方式不需要额外安装调试服务器适合只需要快速烧录、不看调试信息的场景。第二种是使用cortex-debug扩展自带的烧录功能。我习惯直接把烧录和调试合并在一起处理运行调试会话F5时调试器连接 ST-Link 后会自动加载固件省去单独烧录的步骤。4.4 调试器配置 launch.json 才是真正头疼的地方ST-Link 调试是 VS Code 里配置难度最高的一步也是劝退最多人的一步。我这里直接给出一份验证可用的配置{ version: 0.2.0, configurations: [ { name: Cortex Debug STM32, cwd: ${workspaceFolder}, executable: ${workspaceFolder}/build/*.elf, request: launch, type: cortex-debug, servertype: stlink, device: STM32F103C8, interface: swd, runToEntryPoint: main, svdFile: ${workspaceFolder}/STM32F103C8.svd } ] }其中最容易被忽略的是svdFile。SVDSystem View Description文件是 ARM 官方对芯片外设寄存器地址的一种描述文件如果你不配置它在调试窗口的“外设”面板里就看不到GPIOA-ODR、USART1-BRR这类寄存器名只能看一串裸地址非常不利于排查问题。SVD 文件可以从 ST 官网下载也可以从 STM32CubeMX 的安装路径中找到一般位于db/mcu目录下。runToEntryPoint设置为main可以让调试器自动跳过启动文件直接在 main 函数处停下。这一点比 Keil 的默认行为更人性化——用 Keil 调试时经常一按 F5 就全速运行还得手动断点。配置好后按F5如果一切正常VS Code 窗口底部会连接 ST-Link左侧出现调用栈和变量面板代码行出现黄色断点指示。看到这一步恭喜你开发环境已经完成九成了。5. 绕过传统 Keil 用户的迁移深坑编译脚本与驱动预备5.1 从 .uvprojx 到 Makefile别指望一键转换很多人的第一个 STM32 工程是用 Keil 创建或生成的现在要迁移到 VS Code第一步就是处理工程文件格式。Keil 的.uvprojx是 XML 格式里面记录了源文件列表、宏定义、头文件路径、芯片型号等信息。VS Code 和 GCC 工具链并不认识.uvprojx。网上有人写了 Keil 工程转 Makefile 的工具但我实际体验下来复杂工程转换后问题太多路径分隔符、宏定义转义、不同编译器的语法差异都会带来大量编译错误。我的建议是除非你的工程非常小否则不要尝试转换直接用 STM32CubeMX 重新生成一个新工程再把你自己写的业务代码文件拷进去。重新生成工程时注意一个坑CubeMX 默认会重新生成main.c如果你不小心把自己写的代码放到main.c的 USER CODE 标记之外重新生成时会被全部清除。所以刚才代码生成选项里的“外设代码按外设拆分”就显得尤为重要你必须把自己写的逻辑尽量放在独立.c文件里而不是依赖 CubeMX 的 USER CODE 区域——AI 编程时代这种坏习惯会让你在代码协作中吃大亏。5.2 头文件路径批量添加的技巧在 Keil 里添加头文件路径是在魔法棒Options for Target的 C/C 选项卡里一个个添加的。到了 VS Code如果工程包含几十个文件夹手工在c_cpp_properties.json里写路径也不现实。一个高效的替代方案是在工程根目录打开终端利用命令行生成路径清单。find . -type d -not -path */\.* | sed s/^\.\/// | sed s/^/ ${workspaceFolder}\// | sed s/$/\/,/把输出的结果复制到c_cpp_properties.json的includePath数组中即可。这个命令在 Windows 上需要用 Git Bash 或 WSL 环境运行如果实在不方便也可以用 VS Code 的C/C扩展的“快速修复”功能它会在你点击红色波浪线时直接提示添加对应头文件路径适合少量路径的场景。5.3 驱动安装的经典问题重新插拔策略烧录前如果发现 VS Code 报“No ST-LINK detected”大概率是驱动问题。STM32 ST-LINK Utility 或 STM32CubeProgrammer 安装后都会附带 ST-Link USB 驱动。但有时候驱动装好之后连接仍然不稳定我见过的情况十有八九是 ST-Link 的固件版本太老。解决办法打开 STM32CubeProgrammer在固件升级界面选择升级 ST-Link 固件。升级完成后拔掉 ST-Link 重新插上。这一步之后绝大数连接问题都能解决。切记先升级固件再排查引脚接线不要反过来在硬件上浪费半天时间。6. 让 AI 真正懂 STM32代码生成与调试的私人心得6.1 VS Code 要接入哪种 AI 助手我的首选与理由既然标题是“嵌入式软件AI编程”那 AI 工具的选择就是重头戏。VS Code 的 AI 插件生态目前呈百花齐放状态有微软自家的 GitHub Copilot、国产的通义灵码、商汤的 CodeGeeX以及各种接入 ChatGPT/DeepSeek/Kimi 的通用插件。我个人的选择是通义灵码 本地 DeepSeek API 双通道搭配。原因很简单通义灵码对中文嵌入式上下文的理解在国产工具中属于第一梯队而且它在免费版中对 STM32 相关的代码库做了专门训练DeepSeek 则适合比较复杂的逻辑推理比如让 AI 分析一段定时器中断代码的时序问题。如果你愿意折腾也可以选用 Continue 插件自由配置多种模型后端。这里要注意一个概念AI 编程插件的效果上限不取决于模型有多聪明而取决于编辑器的“上下文工程”做得好不好。什么意思呢就是 AI 需要准确知道你当前工程的芯片型号、外设配置、HAL 库版本和你个人编程风格才能生成真正能编译通过的代码。VS Code 里配置好 STM32 扩展和 IntelliSense 后AI 插件能通过读取这些配置文件获取上下文生成质量会有明显提升。6.2 让 AI 精准生成 STM32 代码的提示词模板虽然本文主要讲环境安装但既然涉及 AI 编程我分享一个自己调试出来的提示词模板能大大降低 AI 生成代码的返工率你是资深的 STM32 固件工程师。 工程路径xxx 芯片型号STM32F103C8T6 使用的库STM32Cube_FW_F1 V1.8.5 开发环境VS Code arm-none-eabi-gcc STM32CubeMX 生成的 Makefile 任务使用 HAL 库完成 USART1 的 115200-8-N-1 初始化PA9 为 TXPA10 为 RX 使用 DMA 接收空闲中断代码风格要求简洁并给出使用方法说明。 约束不能修改 CubeMX 自动生成的代码区域新增函数写在独立文件中。对比一下很多人随手发的“帮我写一个串口接收程序”这个模板明确了芯片型号、外设引脚、库版本、代码风格和约束条件。AI 生成出来的代码基本就是可编译的成品不需要反复纠错。这就是 VS Code 这套环境的威力——工程结构规范AI 才能精准理解。6.3 关于“AI 生成代码不可控”的防呆建议最后聊一聊 AI 生成的嵌入式代码可靠性的问题。实测下来AI 在生成单个外设初始化函数、中断处理、状态机这类代码时正确率很高但在涉及多线程、RTOS 任务同步、中断优先级嵌套和低功耗状态切换时经常出现逻辑上看似完整但实际带病运行的情况。我的经验是每次让 AI 生成代码后至少在 VS Code 里全量编译一次然后下载到板子上跑一轮基础功能自测。AI 编程工具不是替代你去思考也不是替代你去测试而是帮你把“从芯片手册到代码实现”的链路大幅缩短——毕竟拿到一份能跑的代码再调试总比从零写要快得多。另外代码格式化这一个习惯容易被忽略。VS Code 里装好 C/C 扩展后可以设置保存时自动格式化Format On Save配合.clang-format文件统一代码风格。人工智能时代代码的可读性就是协作的效率不要让 AI 生成的天书代码把你的工程变成屎山。这套 VS Code 与 STM32 扩展工具的环境配置是我目前在嵌入式 AI 编程方向上的主力工作流。刚开始迁移时可能会因为一些配置问题觉得麻烦但习惯之后你会明显感受到在代码补全、调试体验、AI 辅助效率上的提升远远不是 Keil 能给到的。希望这篇文章能帮你少走点弯路把时间花在真正有技术含量的固件逻辑上。