以前做STM32开发，大多数人的第一反应肯定是装个Keil MDK，打开工程直接编译烧录完事。但这两年我越来越觉得，这套传统工作流在代码编辑、版本管理、代码补全，尤其是AI辅助编程方面，太拖后腿了。Keil的编辑器用起来像是2005年的东西，面对复杂一点的工程管理，体验很吃力。所以当VS Code搭配上合适的插件和工具链，嵌入式的开发体验直接提升一个量级，也算是我个人目前最推荐的“嵌入式软件AI编程”落地方式。

这篇文章我会把整套“VS Code + STM32扩展工具”的安装和配置过程，掰开了揉碎了讲清楚。不光告诉你装什么，还会解释为什么这么装，中间有哪些坑是官方文档不会说的。无论你是刚从Keil转过来的老手，还是直接用VS Code入门的新手，照着这篇走一遍，本地环境基本就能跑起来。而且，更关键的是，把AI编程工具（比如Continue、Cline，或者国产的Codex接DeepSeek等）接入进来，你就能在VS Code里直接让AI帮你写寄存器配置、生成初始化代码、检查逻辑错误了。

1. 为什么STM32开发开始转向VS Code

先别急着下载安装，我们先把思路理一理。如果你平时只用Keil，可能觉得“能用就行”。但你把Keil和其他工具放在一起横向比较，差距就会非常明显。

1.1 传统IDE的舒适区与痛点

STM32的经典开发环境无非是Keil MDK、IAR EWARM，或者是ST自家基于Eclipse的STM32CubeIDE。大部分工程师的入门是从Keil开始的，因为它资料多、上手快。可遇到大型工程，痛点就很刺眼：

• 代码编辑体验不佳。补全功能弱，跳转定义有时候还会莫名其妙失灵。代码一多，滚动查找的效率很低。
• 版本管理别扭。虽然Keil有SVN集成选项，但实际操作起来还是习惯到文件系统里右键，总归不够顺手。
• 界面老旧，多窗口分屏支持差。一边看代码一边看手册非常痛苦。
• 对AI插件几乎零支持。这点是最致命的。你没法在一个主流AI编程环境里直接操作Keil工程。

1.2 VS Code凭什么能替代传统工作流

VS Code本质是一个“编辑器加轻量IDE框架”，它通过插件机制把编译、调试、代码补全全部接管过来。它在嵌入式开发中的优势，我自己体会下来主要是这几点：

第一，启动速度快，界面响应流畅。VS Code打开一个STM32工程，体感上比Eclipse系快很多，日常编辑完全不卡顿。

第二，插件生态完善。C/C++插件提供代码补全和定义跳转；Cortex-Debug插件配合OpenOCD或J-Link，提供完整的调试体验；CMake Tools插件解决构建系统问题；Remote SSH插件还能让你直接编辑和编译Linux服务器或树莓派上的交叉编译工程。

第三，Git集成深度好。你在VS Code里能直接看到一行代码是谁在什么时候改的，做代码审查、回退历史，都比在Keil里舒服太多。

第四，AI编程插件的无缝嵌入。比如Continue插件可以自由选择模型商，你可以接DeepSeek的API、通义千问的API，也可以接本地的Ollama模型。Cline插件则可以直接一边对话一边帮你改源码、执行编译命令，甚至能自动修复报错。这套东西，在传统IDE里根本实现不了。

1.3 这套方案的适用人群

如果你属于以下几类人，这套方案非常值得你投入时间：

• 想深入使用AI辅助编程写STM32项目，但又不愿意放弃本地工具链的人。
• 觉得Keil编辑代码体验太差想“搬家”的人。
• 需要用CMake管理跨平台嵌入式工程、或者需要远程开发的人。
• 学生党做课设、毕设，想用一个更现代化的工具内卷。

当然，夸张一点说，任何使用STM32做嵌入式开发的人，都值得花一个下午把环境搭好。

2. 安装VS Code与基础环境配置

这一节会比较像一个手把手教程。先装VS Code本体，再把语言和基础插件配置好。

2.1 VS Code下载安装的关键选项

VS Code直接去官网下载就行。Windows系统下载User Installer 64位版本，安装过程一路Next。但有两个选项尤其注意：

• 在“选择其他任务”页面，务必勾选“添加到PATH（添加至路径）”。这关系到后面命令行中使用 code 命令的便利性。
• 建议勾选“通过Code打开”操作菜单，方便在工程文件夹右键打开VS Code。

装完之后打开VS Code，左侧栏像个“神灯”一样的图标就是扩展市场。快捷键是 Ctrl+Shift+X 。

2.2 必装基础插件清单

在搜索框里搜索并安装以下几个插件，这是后续所有操作的地基：

• 中文（简体）语言包：搜索“Chinese”，安装这个插件后右下角会提示重启，重启后界面变成中文。
• C/C++（ms-vscode.cpptools）：这是微软官方的C/C++扩展，提供语法高亮、智能感知、代码跳转和调试。必装，不装的话看代码等于看纯文本。
• CMake Tools：STM32CubeMX生成的工程可以选CMake工具链，装这个插件后可以直接在VS Code里配置、编译、烧录。
• Cortex-Debug：这是嵌入式调试的利器。配合OpenOCD、J-Link、ST-Link等调试服务器，能在VS Code里做断点调试、查看寄存器、监测变量。
• Serial Monitor：串口监视插件。嵌入式开发频率最高的调试手段就是串口打印，有这个插件就不用另开串口工具了。
• Remote-SSH：如果你后续要远程编译或调试，这个插件可以让你像操作本地一样编辑远程代码。

安装完后，可以在扩展搜索框下面看到“已启用”标签，确认这些插件没有报错。

2.3 工作区和用户设置

VS Code的配置分为“用户设置”和“工作区设置”。用户设置是全局的，建议把以下这些基础项配上：

打开设置快捷键 Ctrl+, ，在右上角切换到 settings.json 编辑模式，加入以下内容：

{
    "editor.fontSize": 16,
    "editor.formatOnSave": true,
    "editor.renderWhitespace": "all",
    "files.encoding": "utf8",
    "files.eol": "\n",
    "C_Cpp.default.compilerPath": "C:/ST/STM32CubeIDE_1.15.0/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.win32_1.1.0/tools/bin/arm-none-eabi-gcc.exe",
    "cmake.configureOnOpen": true
}

注意， C_Cpp.default.compilerPath 要填你自己电脑上arm-none-eabi-gcc.exe的绝对路径，这个路径在下一节装完工具链后就有了。这一步配置的意义在于：VS Code需要知道用什么编译器来解析代码里的宏定义和头文件，配置正确后，代码下方那些红色波浪线就会大面积消失。

3. STM32扩展工具套件安装与工具链剖析

VS Code本身只是一副骨架，它要能编译STM32工程，必须依赖外部工具链。很多人装完VS Code兴冲冲打开工程，结果一编译全是“arm-none-eabi-gcc: not found”，这就是因为你还没装ARM交叉编译工具链。

3.1 装齐三大件：编译器、构建工具、调试服务器

**ARM GNU Toolchain（arm-none-eabi-gcc）**是必须的第一件工具，它负责把C代码编译成ARM Cortex-M处理器的机器码。有三种获取方式：

第一种是装STM32CubeIDE时自带的工具链。如果你之前装过CubeIDE，那你机器上大概率已经有ARM GCC了。去这个路径找一下： C:\ST\STM32CubeIDE_xxx\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.xxx\tools\bin 把它加入系统环境变量PATH即可。

第二种是直接到Arm官网下载“Arm GNU Toolchain”的Windows安装包。装完后也会自带bin目录。

第三种是如果你使用的是MSYS2或MinGW，可以在MSYS2的包管理器里安装 arm-none-eabi-gcc 。但新手我不推荐这么做，路径和依赖关系容易出问题。

验证是否装好，打开一个新的CMD窗口（注意装完要新开窗口才能刷新PATH），输入：

arm-none-eabi-gcc --version

能打印出版本号就说明工具链就绪。

CMake与Make工具 是第二件。STM32CubeMX生成的工程可以选“CMake”或“Makefile”两种构建方式。我用CMake比较多，因为CMake Tools插件在VS Code里集成度最好，所以建议装CMake。CMake在Windows下装好后要确保 cmake 命令在PATH里。如果你生成的工程是Makefile类型，那Windows下还需要装一个GNU Make，一般是MinGW或MSYS2提供的。

OpenOCD 是第三件，它是开源的调试与烧录服务器。VS Code里Cortex-Debug插件本身不直接控制ST-Link或J-Link硬件，而是通过OpenOCD作为中间桥梁。你可以从GitHub上OpenOCD的发布页面下载Windows版解压即可，解压后的bin目录同样加入PATH。

到这里，工具链三件套齐了。打开CMD依次验证：

arm-none-eabi-gcc --version
cmake --version
openocd --version

三条命令都能输出版本，才算把基础环境打结实。

3.2 STM32专属扩展插件作用详解

在扩展市场搜索“STM32”，会看到一个名为“STM32 VS Code Extensions”的官方扩展包。装这个收益很高，它不是一个插件，而是一个集合包，里面包含了：

• STM32CubeMX集成：安装后可以在VS Code内部直接点击生成CubeMX工程，不用在CubeMX和VS Code之间来回切换。
• STM32的工程导入工具：可以导入.ioc文件、生成的CMake工程等。
• 一些代码辅助功能：如寄存器定义跳转、外设初始化代码片段。

同时我建议再搜索安装一个“LinkerScript”插件，它能让链接脚本（.ld文件）高亮和语法检查，这个文件是STM32内存布局的关键，语法错误排查起来很痛苦，有这个插件能省不少眼睛。

3.3 环境变量配置与路径管理经验

Windows下配置环境变量有一处容易踩坑：系统变量里的PATH是有长度上限的，如果你额外装了很多工具链，建议新建一个用户级别的变量，比如 STM32_TOOLCHAIN_PATH ，然后把这个变量指向工具链的公共父目录，再把 %STM32_TOOLCHAIN_PATH%\bin 等子目录逐个加入PATH。

还有个经验：在配置OpenOCD和STM32CubeMX的路径时，千万不要用中文目录，也尽量不要带空格。比如 C:\Users\张三\OpenOCD 就很容易在调试时出现莫名其妙找不到路径的错误。原则上，整个工具链安装目录最好统一放在类似 D:\EmbeddedTools 这种简单英文路径下。

4. 从CubeMX到VS Code：首个示例工程编译烧录

工具链都装齐了，接下来最核心的一步：把CubeMX生成的工程在VS Code里完整跑一遍，从编译到烧录到调试，整个过程走通。

4.1 用STM32CubeMX生成CMake工程

打开STM32CubeMX，我们以一个最常见的芯片STM32F103C8T6为例。新建工程，选好芯片型号，在“System Core”里配置一下RCC（高速外部时钟HSE选择Crystal/Ceramic Resonator），在“PC13”引脚上配置一个GPIO为输出模式，用来控制板载LED。其他配置先用默认值，生成的工程只求能跑。

关键的步骤在“Project Manager”选项卡：

• Toolchain / IDE这一项，选择“CMake”。这是VS Code生态最顺滑的构建系统。
• 项目名称建议用英文，不要有空格。
• 项目位置，同样建议英文路径。

点击GENERATE CODE生成工程。

4.2 在VS Code中导入并配置编译

用VS Code打开刚才生成的工程文件夹。如果CMake Tools插件正常工作，左下角状态栏会出现一个CMake相关的按钮（通常显示当前编译器或构建类型）。

第一次打开工程，CMake Tools会提示你选择Kit（编译器工具链）。如果你安装的ARM GCC和CMake都是标准路径，通常会自动检测到一个类似“GCC for arm-none-eabi”的选项，选中它即可。

如果没自动检测到，手动点击状态栏的Kit按钮，在弹出的列表里选择“扫描工具链”，让VS Code重新搜索。再不行，就需要手动指定工具链文件。在.vscode目录下新建一个settings.json，内容：

{
    "cmake.configureEnvironment": {
        "CMAKE_MAKE_PROGRAM": "D:/EmbeddedTools/CMake/bin/cmake.exe"
    },
    "cmake.cmakePath": "D:/EmbeddedTools/CMake/bin/cmake.exe",
    "cmake.generator": "Ninja"
}

注意如果你用的生成器是Ninja，Windows下需要额外下载Ninja并加入PATH。不想装Ninja的话，可以把generator改成“Unix Makefiles”，然后用系统里的GNU Make。我的建议是直接装Ninja，它在Windows下的编译并行度最高，速度最快。

配置好Kit和生成器后，按 Ctrl+Shift+P ，输入“CMake: Configure”，让插件读取CMakeLists.txt生成构建系统。然后按 Ctrl+Shift+P ，输入“CMake: Build”，即可开始编译。

正常编译结束后，在 build 目录下会生成 .elf 、 .bin 、 .hex 文件，这就说明编译链路完全打通了。

4.3 配置烧录与调试：tasks.json与launch.json

编译能过，只算成功了一半。真正嵌入式开发最关键的是烧录和调试。VS Code通过两个文件完成这个任务：

• tasks.json ：定义一些外部命令任务，比如调用OpenOCD进行烧录。
• launch.json ：定义调试会话，Cortex-Debug插件按照这个配置启动调试器。

在 .vscode 目录下新建 tasks.json ，加入一个烧录任务：

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "stm32-flash",
            "type": "shell",
            "command": "openocd",
            "args": [
                "-f", "interface/stlink.cfg",
                "-f", "target/stm32f1x.cfg",
                "-c", "program build/YourProject.elf verify reset exit"
            ],
            "group": {
                "kind": "build",
                "isDefault": true
            }
        }
    ]
}

这段配置的意思是：用ST-Link接口驱动，目标芯片配置是STM32F1系列，把编译生成的ELF文件烧进去，校验后复位运行。你如果用的是J-Link，把interface配置文件换成 jlink.cfg 即可。注意 program 后面跟的程序路径要和你工程里生成的文件名一致。

调试配置 launch.json 这样写：

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Cortex Debug",
            "cwd": "${workspaceFolder}",
            "executable": "${workspaceFolder}/build/YourProject.elf",
            "request": "launch",
            "type": "cortex-debug",
            "servertype": "openocd",
            "configFiles": [
                "interface/stlink.cfg",
                "target/stm32f1x.cfg"
            ],
            "searchDir": [],
            "showDevDebugOutput": "none",
            "svdFile": "${workspaceFolder}/STM32F103C8Tx.svd"
        }
    ]
}

svdFile 对应STM32芯片的系统视图描述文件（SVD），有它之后，调试时外设寄存器值就能直接以可读格式显示，在“外设寄存器”窗口里看懂寄存器位非常方便。CubeMX生成的工程里通常不自动带SVD文件，需要自己从ST官网或SDK里拷贝到工程目录。

配好以后，按 Ctrl+Shift+B 执行烧录任务，按 F5 启动调试会话。看到代码在main函数入口处停下来，说明整套环境彻底跑通。

4.4 解决C/C++插件头文件红色波浪线问题

很多人从Keil转过来，遇到的第一大障碍就是整个工程全是红色波浪线，到处都是include路径找不到的错误。这其实是C/C++插件不知道你的头文件在哪。

在 .vscode 目录下新建 c_cpp_properties.json ，内容如下：

{
    "configurations": [
        {
            "name": "STM32",
            "includePath": [
                "${workspaceFolder}/Core/Inc",
                "${workspaceFolder}/Drivers/STM32F1xx_HAL_Driver/Inc",
                "${workspaceFolder}/Drivers/STM32F1xx_HAL_Driver/Inc/Legacy",
                "${workspaceFolder}/Drivers/CMSIS/Device/ST/STM32F1xx/Include",
                "${workspaceFolder}/Drivers/CMSIS/Include"
            ],
            "defines": [
                "USE_HAL_DRIVER",
                "STM32F103xB"
            ],
            "compilerPath": "C:/.../arm-none-eabi-gcc.exe",
            "cStandard": "c11",
            "intelliSenseMode": "linux-gcc-arm"
        }
    ],
    "version": 4
}

这里的关键是： includePath 要覆盖CubeMX生成工程中Core和Drivers目录下的所有头文件路径； defines 里要加上 USE_HAL_DRIVER 和 STM32F103xB 这种芯片型号宏，否则HAL库源码里的条件编译会被跳过，各种函数都标红。配置好之后重载窗口（ Ctrl+Shift+P ，输入Reload Window），红色波浪线就会大幅减少。

如果你用的是自定义的库，只需要把自己库的头文件目录也加进来就行。这里有一个进阶技巧：把C/C++插件设置里的“C_Cpp.intelliSenseEngine”改成“Tag Parser”，它对大型工程的解析速度更快，但代价是精度略低。我自己的经验是，如果工程特别大，用Tag Parser体验反而好。

5. 让AI编程介入STM32开发流程

标题里带着“AI编程”，这才是很多人关注的重点。工具链搭好了、编译烧录调试都通了，接下来就是让AI成为你的“结对编程搭子”。

5.1 AI在嵌入式开发里到底能帮什么忙

很多人觉得AI写代码只适用于Python或Web前端，跟单片机不搭边。实际上AI在嵌入式领域我能用到的场景非常多：

一是硬件寄存器配置代码的生成。你告诉它“使用TIM2输出PWM，频率20kHz，占空比50%”，它能直接生成对应时基和比较寄存器的配置值。而且会提醒你注意预分频器和自动重装载值的计算是否溢出。

二是HAL库函数的接口查询。HAL库函数参数多、命名长，频繁翻手册和头文件很耗时。直接问AI“怎么用HAL_TIM_PWM_Start_DMA启动定时器PWM并配置DMA”，它基本能给出可用代码。

三是代码错误排查。把编译报错信息粘贴进AI对话框，它能解释错误的可能原因，并给出修改建议。尤其是链接错误（undefined reference）这类，AI分析符号命名和链接脚本也挺在行。

四是为代码写注释和文档。嵌入式工程的可读性通常较差，让AI帮你给函数加注释、说明入参出参含义，非常省时间。

5.2 主流的AI插件接入方式

目前VS Code里常用的AI编码插件有几个流派，我实际使用后的区别如下：

• Continue（推荐入门）：开源免费，支持配置多种模型，比如本地Ollama、云端DeepSeek API、Kimi API等。它是“问答式”的，选中代码后可以和AI讨论、让它改代码或补注释，你确认后再手动应用。
• Cline（半自动/全自动）：它的特点是能直接读写工程文件、执行终端命令。也就是说，你告诉它“去编译，报错就自动修”，它真的会自己编译、看报错、改代码，再重新编译。对嵌入式工程，能自动执行cmake和build任务，效率很高。
• GitHub Copilot：目前体验最好的代码补全工具，但没法自定义模型，而且需要付费。国内访问问题也麻烦，不太建议作为主力。
• 国产平台的AI插件：比如通义灵码、CodeGeeX等，对中文和国内模型支持很好，注册就送额度，搭配STM32开发完全够用。

以Continue插件为例，安装后在设置里填入一个兼容OpenAI接口的模型API。打开扩展设置，在 ~/.continue/config.json 里配置模型厂商和Key：

{
    "models": [
        {
            "title": "DeepSeek Coder",
            "provider": "openai",
            "model": "deepseek-coder",
            "apiBase": "https://api.deepseek.com/v1",
            "apiKey": "你的APIKey"
        }
    ]
}

配置完成后，选中一段代码，按 Ctrl+I 呼出对话框，直接问它：“这段代码的HAL_TIM_PWM_Start在哪里调用合适？”它就会基于当前代码上下文回答。

5.3 实操案例：让AI帮你扩展一个功能

我用一个实际场景演示一下完整闭环。假设你已经有了一个CubeMX生成的基础工程，现在想加一个“长按按键3秒进入低功耗模式”的功能。

传统做法是：打开按键GPIO配置、手动配置EXTI中断、写消抖逻辑、配置进入STOP模式的寄存器……这一套流程至少需要看手册翻代码半小时。

用AI辅助的做法是这样：

1. 在Continue对话框里告诉AI左右上下文：“我在STM32F103C8T6上，使用HAL库，工程是CubeMX生成的。帮我实现一个按键长按3秒进入STOP模式的函数。按键接在PA0引脚，低电平有效。请给出完整的按键中断回调函数和进入STOP模式的代码。”

2. AI会给出建议代码，包括 HAL_GPIO_EXTI_Callback 的实现、 HAL_PWR_EnterSTOPMode 的调用方式，甚至提示你需要提前配置 PWR 时钟使能。

3. 你手动在CubeMX里把PA0配置为外部中断，生成代码后，把AI提供的逻辑放到合适的位置。

4. 编译烧录。如果中途报错，直接把报错信息粘给AI，它能帮你修正。

这个过程，我实际做下来，从需求到可运行代码，基本在10分钟以内。而这种需求在传统的Keil工作流里，至少需要研究寄存器手册大半天。

不过在享受AI带来的便利时，有几个原则要记住：

• AI生成的代码一定要自己check一遍。寄存器配置的误差很容易被忽略，比如预分频算错、时钟源选错、忘记使能中断等。
• 涉及安全关键的系统，比如电机控制、电源管理，不要在无人review的情况下直接使用AI生成代码。
• 给AI喂需求时，尽量提供完整的上下文：芯片型号、HAL库还是标准外设库、你当前工程的引脚分配、期望的时钟频率。信息越全，AI的答案越准。

6. 常见问题与排查技巧：我的避坑实录

环境装多了，遇到的各种幺蛾子也就多了。这一节把我踩过的坑和排查经验整理成一个速查表，希望能帮你少走弯路。

6.1 环境配置与插件使用问题速查

现象	可能原因	我的排查方法与解决方案
编译时报“无法将‘arm-none-eabi-gcc’识别为cmdlet…”	工具链未加入PATH	检查PATH中是否包含工具链bin目录，新开CMD验证arm-none-eabi-gcc --version
CMake配置时报“No CMAKE_C_COMPILER could be found”	CMake没找到交叉编译器	重新选择CMake Kit，或者在settings.json中指定CMAKE_C_COMPILER为arm-none-eabi-gcc路径
点击烧录任务没反应	tasks.json路径或文件名错误	检查tasks.json中program参数指定的ELF文件名是否跟build目录下生成的一致
调试启动后连接不上目标板	ST-Link驱动问题或线路连接问题	先看OpenOCD日志，确认USB设备是否被识别；更新ST-Link驱动；确认接线无误
头文件满屏红色波浪线	includePath未正确配置	按4.4节方法配置c_cpp_properties.json，确认defines中包含USE_HAL_DRIVER和芯片型号宏
中文路径编译报错	工具链不支持中文路径	将整个工程和工具链移动到纯英文路径下
调试时外设寄存器窗口不显示	缺少SVD文件	在launch.json中配置svdFile路径
串口监视器乱码	波特率不匹配	确保VS Code串口插件设置的波特率与单片机端代码一致

6.2 我强烈建议你踩一下的“环境排雷”顺序

按照我的经验，新手最容易在“先装什么后装什么”上糊涂，导致最后配置非常混乱。建议的安装顺序是：

1. 先装VS Code，基础配置好。
2. 再装ARM GCC工具链，验证 arm-none-eabi-gcc --version 。
3. 再装CMake和Ninja（或Make），验证 cmake --version 。
4. 再装OpenOCD，并确认它与ST-Link能正常通信。
5. 然后在VS Code扩展市场安装C/C++、CMake Tools、Cortex-Debug等插件。
6. 最后再打开CubeMX生成的工程，进行编译烧录调试验证。
7. 调试稳定后，再按需接入AI插件。

这个顺序的原因是：VS Code扩展插件的安装不依赖外部工具，但插件的配置验证依赖编译和调试顺利跑通。如果你是倒着装，一旦出问题就很难判断是VS Code的问题还是外部工具的问题。

6.3 几个容易被忽略的细节

第一，开机后如果你用任务管理器看到VS Code后台有多个进程，别急着杀掉，那是它正常的多进程架构。但如果你安装了太多不必要的扩展，确实会影响启动速度，建议在“已启用”里定期清理不常用的。

第二，打开工程时留意VS Code底部状态栏的CMake工具是否显示当前是“Debug”构建类型。想编译优化后的release固件，切换构建类型即可。

第三，新版OpenOCD的配置文件路径和旧版有细微差异，如果你用的配置文件失效，检查一下interface目录下是 stlink.cfg 还是 stlink-v2.cfg 。我遇到过老教程写stlink-v2.cfg，而新版OpenOCD只提供了stlink.cfg的情况。

第四，如果需要开发STM32，但电脑上只有一块J-Link OB板，在OpenOCD配置文件里使用的是 interface/jlink.cfg ，同时注意J-Link需要驱动支持才能被OpenOCD正确识别，一般需要单独装一个SEGGER J-Link软件套件。

最后关于AI插件，有人说“AI写嵌入式代码不可靠”，我用下来的感受是：不可靠的是不干活的人，以及没有给AI足够上下文的人。你能把工程的芯片型号、HAL库版本、当前引脚分配、期望行为讲清楚，AI生成代码的可参考性非常高。这个时代，嵌入式工程师完全可以不改变原来的开发习惯，但最好学会在VS Code这个现代编辑器里，跟AI配合着写代码。

这套环境我已经用了快两年，从最初的抗拒到现在的离不开，本质上是因为它把嵌入式开发从“能用”提升到了“好用”的层次。按这篇教程操作完，你的VS Code就不再只是一个代码查看器了，而是一个真正的STM32开发平台。后续我还会继续分享在VS Code里集成各种AI插件做嵌入式编程的细节，比如怎么让AI自动处理编译报错、怎么用自然语言生成芯片初始化代码等，欢迎持续关注。