企业官网建设流程全解析

1. 为什么我把STM32开发从Keil搬到了VS Code

如果你点进这篇文章，大概率和我之前遇到的情况一样：习惯用VS Code写代码，但一碰STM32就被拉回Keil MDK的“舒适区”——工程模板现成、编译按钮就在工具栏上、下载调试一键完成。可随着工程越写越大，函数跳转越来越卡，代码补全时灵时不灵，Git版本管理几乎没法用，AI编程助手更是装都装不上，那种割裂感实在让人崩溃。

这篇文章就围绕一套完整的VS Code嵌入式开发环境展开，从工具链选型、编译调试流程、常见报错排查到给AI编程工具腾出位置，把STM32从“能用”做到“好用”。适合两类人看：一是被Keil/IAR的编辑体验折磨已久、想整体迁移到VS Code的开发者；二是已经开始用VS Code，但对工具链原理一知半解，遇到报错只能复制粘贴到搜索引擎的初学者。我不会只给你一堆安装命令，而是把每个环节背后的逻辑讲清楚，这样就算芯片换成了GD32、APM32或者K210这类非典型STM32，你也能自己把环境搭起来。

先说结论：VS Code本身不做编译，也不管理芯片寄存器，它只是一个外壳。真正干活的是GCC编译器、OpenOCD调试器、CMake构建系统、ST-Link驱动这一整套工具链。搞清楚它们之间的协作关系，比记住一百个快捷键重要得多。

我最早入坑STM32是用Keil MDK，后来装了VS Code的C/C++插件，把Keil的工程目录直接丢进去，结果发现只解决了“编辑”这一件事，编译烧录还得切回Keil。折腾了一阵子，试过用Keil的编译器命令行接口配合VS Code的tasks，也试过在VS Code里调Keil的 UV4.exe，方案能用但总感觉隔了一层，模块化不够干净。真正让我下定决心迁移的，是ST官方推出的STM32CubeCLT——它把GCC工具链、OpenOCD、ST-LINK GDB Server这些核心工具打包到一起，让VS Code这条路彻底走通了。

如果你现在还在纠结“要不要换”，我的建议很直接：如果只是点个灯、复现个例程、参加个不需要复杂调试的比赛，Keil完全够用，别折腾。但如果你要写超过10个文件的项目，要引入RTOS，要做单元测试，要用AI辅助写驱动，要把CI/CD流水线拉起来，VS Code这条路线带来的收益远超初期那几天的学习成本。

2. 工具链全家桶：编译器、构建系统、调试器到底谁负责干什么

很多人一听到“工具链”三个字就头大，其实它就是一组各司其职的命令行程序。对于STM32开发来说，核心成员就四位：编译器负责把C代码变成机器码，构建系统负责决定“先编译哪个文件、链接哪些库”，调试器负责把程序烧进去并跟芯片对话，硬件驱动负责让电脑识别ST-Link。

2.1 四个核心组件的分工与选型

先看一张我平时给新手讲的对应关系表：

编译器我这里选的是arm-none-eabi-gcc，这是ARM官方推荐的GNU工具链，GCC的降级替代选择几乎没有——它开源、跨平台、文档齐全，ST的CubeCLT里就打包了它。为什么不用ARM自家新的armclang？因为arm-none-eabi-gcc在STM32生态里资料最多，出问题你能搜到大把解决方案，armclang的社群讨论相对少很多。

构建系统我推荐CMake。它的学习曲线稍陡，但换来的是跨平台能力——同一份CMakeLists.txt在Windows、Linux、macOS上都能跑，而且VS Code的CMake Tools插件支持得非常成熟，能自动帮你做Target选择、编译参数切换。Ninja则是比Make更快的底层构建器，CMake可以生成Ninja的构建文件，实测大工程的增量编译速度比Makefile快不少。

调试与烧录用OpenOCD。它是开源片上调试器，支持ST-Link、J-Link、CMSIS-DAP等多种调试探头。用它配合ST-Link，既可以下载固件，也可以启动GDB Server让VS Code的Cortex-Debug插件接管实现断点调试。还有一条路线是用ST官方的 ST-LINK GDB Server，但我更推荐OpenOCD——它不绑定ST生态，以后你更换调试器或者芯片，配置文件的改动量小得多。

2.2 用STM32CubeCLT一份装齐

STM32CubeCLT是ST官方专门为命令行开发出的工具包，里面集成了：

• arm-none-eabi-gcc，用于编译
• OpenOCD，用于调试和烧录
• ST-LINK GDB Server，作为另一种调试选择
• STM32CubeProgrammer的命令行版本，用于固件烧写和芯片选项字节配置

它极大降低了VS Code路线的前期成本。以前这套东西需要分别去四个网站下载、手动配置环境变量，现在直接去ST官网搜STM32CubeCLT下载安装包，一路按默认安装即可。装完后要把安装目录下的GNU Tools路径、OpenOCD路径手动加到系统PATH里，因为安装器不会自动加。

Windows下我建议把路径加进用户级PATH，而不是系统级，减少权限问题。加完以后在终端里验证：

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

如果两个命令都能输出版本信息，说明路径配置成功。我没有在Windows上实测过Linux的路径差异，但如果你是macOS，还是用Homebrew装GNU ARM工具链，再单独装OpenOCD比较省事。

2.3 CubeMX的取舍：用它的图形配置，但别用它的代码风格

STM32CubeMX是ST官方的初始化代码生成器，它可以根据你用图形化方式配置的时钟树、外设、引脚，生成一套完整的工程代码。用VS Code开发，完全绕不开CubeMX——因为芯片的时钟配置、GPIO模式、外设初始化这些代码手写又累又容易出错，图形化配置是最高效的。

最常见的做法是让CubeMX生成Makefile工程，然后自己在外面套一层CMake；或者在新版本CubeMX里直接生成CMake工程（需要安装STM32CubeCLT），它会在工程根目录生成CMakeLists.txt和对应的cmake目录，VS Code打开后CMake Tools插件能直接识别。

这里我想澄清一个常见误解：CubeMX生成的初始化代码质量很高，可以直接用于生产，但它的分层设计比较“模板化”——所有外设初始化都堆在main.c和对应的外设驱动文件里。如果你要写复杂业务逻辑，建议初始化代码和业务代码分开目录，避免CubeMX再次生成时覆盖你的改动。CubeMX在你点击“重新生成代码”时会保留用户代码区（就是注释标记了USER CODE BEGIN/END的部分），但文件结构层面的改动它不认。我见过有人硬把业务代码写进main.c的用户代码区，结果工程大了以后维护成本爆炸，这个坑一定避开。

2.4 环境变量验证与芯片包安装问题

工具链装好后，最常见的两类问题都出在“ST-Link驱动”和“芯片支持包”上。

Windows上ST-Link驱动出问题，最典型的现象是设备管理器里看到“ST-Link Virtual COM Port”或“ST-Link Debug”带黄色感叹号。这是驱动版本和固件不匹配导致的，解决方法是用ST官网的STM32CubeProgrammer安装目录下自带的驱动安装工具，或者单独下载ST-Link USB Driver重新安装。先插拔一次ST-Link，再刷新设备管理器，感叹号还在的话就用驱动工具“Remove”后重新装一遍。

芯片包安装则要注意：Keil有Keil.STM32F1xx_DFP这种设备家族包，CubeMX有STM32CubeF1这种固件包，VS Code工具链本身不需要装芯片包——它只需要你指定芯片型号并链接对应的CMSIS设备头文件和启动文件，这些都可以从CubeMX生成的工程里自动提供。所以如果你看到“芯片包安装”的说法，先搞清楚说的到底是谁的包，浏览器下错是很常见的事。

3. 最小可运行工程：从CubeMX到VS Code编译烧录全流程

3.1 CubeMX端配置三个关键点

第一步先装好STM32CubeMX本身，然后新建工程、选芯片型号。以最经典的STM32F103C8T6为例，我把配置过程分成三个容易漏的环节：

第一，时钟配置。默认配置下HCLK只有8MHz，GitHub上的手写例程和AI生成的代码经常默认跑在72MHz上，但实际上外部晶振、PLL倍频、Flash等待周期任何一个不匹配，程序可能直接卡死在时钟初始化上。最好在CubeMX的Clock Configuration窗口里把HSE设为8MHz晶振，PLL倍频到72MHz，再把系统时钟源切到PLL，最后Ctrl+S保存并生成代码。

第二，调试接口。新建工程后第一件事是去System Core -> SYS，把Debug选项从No Debug改成Serial Wire。这个配置对Keil用户来说没那么显眼，但如果不改，烧录一次之后SWD引脚被释放成普通GPIO，ST-Link就再也连不上芯片了，只能按住复位键抢时间窗口烧录，非常痛苦。

第三，生成工具的设置。在Project Manager -> Project里，Toolchain/IDE选择CMake，如果你已经把CubeCLT装好了，它会在生成时自动调用GCC进行首次编译。如果你只是想让CubeMX生成Makefile工程再自己转，也可以先选Makefile，但我实测用CMake最顺——省的自己编译生成compile_commands.json（这个文件后面讲clangd的时候会再次用到）。

等CubeMX生成完毕，你会得到一个包含Core、Drivers、CMakeLists.txt的工程目录。最后再提醒一句：生成的工程默认不使用动态内存分配，也不启用assert，跑复杂逻辑时这些地方要注意，别到时候代码一复杂就莫名重启。

3.2 VS Code里打开工程并完成首次构建

用VS Code打开CubeMX生成的工程根目录，系统会提示你安装推荐的扩展，其中CMake Tools和Cortex-Debug是必须的。我列一个最小插件清单：

装好后，CMake Tools插件会在底部状态栏显示一个“Kit: 未选择”的提示，点击它，选择arm-none-eabi-gcc对应的工具链名称。这一步很关键——如果你不选Kit而是直接用默认的VS Code内置编译器，CMake配置阶段会直接报错找不到编译器。

接下来先点一次CMake: Delete Cache and Reconfigure，把缓存清掉，让插件重新生成构建文件。然后在终端运行：

cmake --build build

首次构建会有点慢，因为ST的HAL库文件挺大的。构建成功后，在build目录下能看到一个后缀为.elf和.hex的固件文件。到这为止，工具链的“编译”环节已经打通。

3.3 为什么生成一份compile_commands.json对开发体验影响巨大

很多人在VS Code里做STM32开发，遇到的头号问题是“明明工程能编译通过，但代码一堆红色波浪线，函数跳转不过去”。

原因很简单：索引器不知道你的头文件路径、宏定义和编译选项。修复办法就是生成compile_commands.json。文件记录了每个源文件的精确编译命令，clangd或者微软的IntelliSense拿到它以后，就能基于真实编译参数提供精准的代码分析。

如果用CMake，生成这个文件只需要在CMakeLists.txt里加一行：

set(CMAKE_EXPORT_COMPILE_COMMANDS ON)

或者更简单的方式——在CMake配置后，直接把build目录下的compile_commands.json软链接到工程根目录。clangd默认会在根目录找这个文件。我用CMake Tools配置好后它会自动生成到build里，我习惯在.vscode/settings.json里设置clangd的--compile-commands-dir参数指向build目录，这样不用每次拷文件。

{ "clangd.arguments": [ "--compile-commands-dir=${workspaceFolder}/build", "--background-index", "--clang-tidy" ] }

上面的配置是把编译数据库路径告诉clangd，让它自己去build目录读取。设置完后，函数跳转、自动补全、引用查找会流畅很多，这个体验是Keil根本给不了的。

3.4 原生任务系统：把编译、烧录、打开串口绑定到快捷键

VS Code的任务系统允许你把命令封装成一个Task，用快捷键一键触发。对嵌入式日常开发，我建议配置三个Task：build、flash、monitor。

在.vscode/tasks.json里，我用的是这样的结构：

{ "version": "2.0.0", "tasks": [ { "label": "Build STM32", "type": "shell", "command": "cmake --build build", "group": { "kind": "build", "isDefault": true }, "problemMatcher": ["$gcc"] }, { "label": "Flash via OpenOCD", "type": "shell", "command": "openocd -f interface/stlink.cfg -f target/stm32f1x.cfg -c \"program build/your_project.elf verify reset exit\"", "dependsOn": "Build STM32" } ] }

问题匹配器（problemMatcher）填$gcc是为了让VS Code能解析GCC编译错误，这样编译出错后点击错误信息能直接跳到对应代码行。OpenOCD的Flash任务我放在紧接着的调试章节详细讲，因为这里最容易踩到“找不到目标”的坑。

如果你还想看串口日志，可以用VS Code的Serial Monitor插件，不用每次折腾putty或者sscom。选波特率的时候注意和CubeMX里配置的串口波特率保持一致，默认115200。

4. 调试与烧录：OpenOCD常见报错的完整排查链路

4.1 一份能用的launch.json配置

在VS Code里调试STM32，核心是安装Cortex-Debug插件，然后配置.vscode/launch.json。我这里给一份可以直接套用的配置：

{ "version": "0.2.0", "configurations": [ { "name": "STM32 Debug", "cwd": "${workspaceFolder}", "executable": "${workspaceFolder}/build/your_project.elf", "request": "launch", "type": "cortex-debug", "servertype": "openocd", "configFiles": [ "interface/stlink.cfg", "target/stm32f1x.cfg" ], "searchDir": [], "runToEntryPoint": "main", "svdFile": "${workspaceFolder}/STM32F103.svd" } ] }

解释几个关键字段：

• configFiles：OpenOCD的接口和芯片配置。interface/stlink.cfg代表使用ST-Link作为调试器，target/stm32f1x.cfg代表目标芯片是STM32F1系列。不同系列换不同的target文件。
• runToEntryPoint：让调试器在main函数入口暂停。不填的话默认在Reset_Handler处断住，新手会觉得很懵，因为看到的都是汇编而非C代码。
• svdFile：芯片的外设寄存器描述文件。有了这个文件，Cortex-Debug才能在调试时以可视化方式显示外设寄存器的值和位域含义。你可以从ST官网下载对应型号的SVD文件，也可以去nxp、cmsis-svd项目的GitHub仓库找现成资源。

4.2 “error: no stm32 target found”——最经典的烧录失败

所有OpenOCD报错里，这句“error: no stm32 target found! if your product embeds debug authentication, please perform a device mass erase before connecting”出现频率最高，几乎每周都有人在小群里问。

它本质上是说OpenOCD无法通过调试口与芯片建立连接。原因有几类，我按排查顺序列出来：

1. 接线或供电问题。SWD接口只需要四条线：SWDIO、SWCLK、GND、3V3，但很多人只接了前三条，忘记共地，或者ST-Link和板子用的是不同电源，通信波形没参考电平，时好时坏。检查办法很简单：用万用表量ST-Link的3V3和板子VCC之间是否连通，或者干脆直接共地。

2. 芯片进入了低功耗模式或已禁用调试接口。CubeMX里把SYS Debug改成Disable的话，芯片内部调试接口会被关掉，OpenOCD自然找不到目标。解决办法是用ST-Link Utility或者STM32CubeProgrammer执行Connect Under Reset——在复位信号拉低的瞬间连接，抢在用户代码执行之前把调试口重新打开。OpenOCD也支持在连接时加-c "reset_config srst_only"之类的参数，但更直接的是按住板上复位键不放，在OpenOCD启动的同时松开。

3. 目标芯片型号配置不对。很多人拿F103的板子去用target/stm32f4x.cfg，OpenOCD在遍历SWD设备时对不上号，就会报这个错。核对一下CubeMX里选的芯片型号和target配置是否一致。

4. 芯片有读保护或调试认证。带读保护（RDP Level 1以上）的芯片，OpenOCD默认连接不上。需要先用STM32CubeProgrammer做一次Full Flash Erase，把保护等级降下来，但注意这也会清空芯片内部所有数据。

5. ST-Link固件太旧或clone版。有个用户问过我“为什么公司电脑能烧录，我自己的电脑就不行”——其实就是不同版本的ST-Link固件对OpenOCD的协议支持不一致。升级ST-Link固件用STM32CubeProgrammer的Firmware Update功能即可。

4.3 一次真实排查：USB驱动、设备管理器与权限

我说一个项目里真实遇到过的案例。有段时间用公司配的笔记本，VS Code点调试，OpenOCD输出“STLink USB communication error”，但同一个ST-Link，插到同事电脑上一切正常。

我先查设备管理器，发现ST-Link Debug出现感叹号——这属于常见问题，驱动si有问题，重新安装ST-Link USB Driver后恢复了，但第二天开机又变回去。我后来发现是Windows更新把驱动版本回退了，最后在设备管理器里定位到ST-Link设备，右键“更新驱动程序”，选择“从计算机中查找”，手动指定到STM32CubeProgrammer安装目录下的drivers文件夹，问题解决。

如果你在Linux或者macOS上开发，遇到的是Permission denied，一般是udev规则没配。给ST-Link设备建一条udev规则，把当前用户加入plugdev组，再重插设备即可。这个我通常建议直接抄OpenOCD官方文档里的50-stlink.rules文件。

4.4 烧录成功但串口不输出：虚拟串口驱动和波特率之谜

调试能连上了，也烧录成功了，但串口调试助手什么都收不到，这个坑也很典型。

先排查ST-Link的虚拟串口：如果你用的是板载ST-Link，那它还会虚拟出一个COM口，设备管理器里能看见“STMicroelectronics Virtual COM Port”，如果这里带感叹号，就需要重装驱动。还需要确认你打开串口用的是这个虚拟COM口，而不是CH340或CP2102对应的物理串口——两者可能在你的电脑上同时存在，选错就收不到数据。

再说波特率问题。STM32的HAL库代码里，波特率由CubeMX根据时钟树自动计算。有时候你觉得是115200，但实际APB总线时钟配置和预期不同，实际波特率可能偏了。我调试时喜欢用开机引脚翻转的方法验证时钟是否正常，再进串口——如果时钟都不对，串口必然乱码。

5. clangd与AI编程：让代码索引和补全不再卡顿

5.1 IntelliSense与clangd之争：我为什么选clangd

VS Code里做C/C++有两条路：微软官方的C/C++插件提供IntelliSense，clangd插件提供基于clang引擎的LSP能力。对嵌入式开发，我强烈推荐clangd。

原因是微软的IntelliSense处理嵌入式工程时，需要你手动配置c_cpp_properties.json里的includePath和defines，而这个配置非常容易过时，工程一改头文件路径，它就开始乱报错，误导性极强。而clangd直接读取compile_commands.json，每个文件都用真实编译参数分析，准确率不是一个量级的。

另外一个客观因素是性能。STM32的HAL库文件TL;DR非常多，微软的IntelliSense在大型工程里索引起来很吃力，VS Code会频繁卡顿。clangd采用后台索引机制，首次构建完数据库后，后面的跳转补全几乎瞬时响应。

唯一要注意的坑是：两个插件不要在同一个工作区同时启用，否则会互相抢占文本悬停提示，出现“半个VS Code卡死”的体验。我通常禁用微软的C/C++插件，保留clangd。

5.2 AI编程助手的接入与“幻觉”防御

好多朋友问我，VS Code里怎么用AI帮我写STM32代码，直接装GitHub Copilot或者通义灵码就行了吗？答案是：装倒是简单，关键在于你怎么用。

合理的姿势是：把VS Code的文字补全和对话能力当成“编码搭档”，让AI完成样板代码、HAL库API调用、日志打印、结构体定义这些模式化工作，但不要让它替你决定“选哪颗芯片、用哪个外设、时钟怎么配”。

嵌入式开发有个特殊性：AI训练语料里STM32的资料非常充足，但它可能混入了F1和F4的HAL函数版本差异，有时候给出的寄存器地址和位定义是完全不存在的。你要是直接复制，编译报错倒是小事，编过了烧进去跑飞才麻烦。

我的建议是配一个.clangd文件，把它当成给AI的“软约束”：

CompileFlags: Add: [-Wall, -Wextra, -Werror=implicit-function-declaration]

这样代码有隐式函数声明时直接编译失败，AI生成的代码要经过这道关卡，不合格的直接在编译阶段暴露，而不是让错误潜伏到运行期。

再分享一个实操技巧：在VS Code的Inline Chat里选中一段寄存器操作代码，直接问“这个寄存器的RCC时钟使能是否遗漏”，AI会基于上下文给出提醒，但你一定要去对照芯片参考手册确认。我在实际测试中发现，AI在时钟使能和外设初始化顺序上的建议偶有遗漏，但GPIO模式的配置（输入输出、推挽开漏、上下拉）给出错的概率很低。它的可靠程度和你提供的上下文丰富度强相关——多把CubeMX生成的初始化代码贴进去，AI的判断就准很多。

5.3 调试阶段的AI提效：异常分析与中断排查

调试嵌入式代码比写代码更耗时间，而AI在调试阶段的帮助被很多人忽略了。一个很实用的场景是：当程序进入HardFault_Handler时，在Cortex-Debug的调用栈里看PC指针和LR寄存器的值，复制到VS Code对话窗口，让AI帮你定位是哪一行触发了异常。

AI会分析出常见原因，比如空指针、数组越界、栈溢出，但这些分析依赖你提供的上下文。你可以把HardFault_Handler的具体代码也贴进去，再告诉AI“我的栈大小配置是2KB”，它就能帮你推断是不是中断嵌套过深导致栈溢出。这类问题让我写的话要翻半天手册，AI确实能提不少速。

不过这类AI辅助还是离不开基本的定位思路：先看PC指针落在哪个函数的哪一行，再把这一行对应的汇编指令和C代码对应起来。建议在你的VS Code里配好“Disassembly”视图，调试时能随时看汇编。AI给你关键线索，你自己做决策，双方的配合才最有效。

5.4 从STM32到其他MCU：这套环境的可迁移性

这套环境的最终价值在于可迁移性。工具链层面和具体芯片无关，你换GD32时CubeMX不支持，就手动配一个相应的target文件给OpenOCD，或者用GD32自家的调试器配置。换K210这种RISC-V核心的芯片时，编译器从arm-none-eabi-gcc换成riscv-none-embed-gcc，OpenOCD的target配置文件也换成k210对应的——但VS Code的工作流、编译数据库机制、clangd配置、AI工具接入方式完全不用变。

我日常也维护着ESP32的开发环境，它和STM32走的是两条完全不同的工具链（ESP-IDF自带构建系统），但在VS Code里它们的开发体验已经无限趋同了。这几年嵌入式工具链的发展方向很明显，就是“慢性子Keil”逐渐被“快节奏命令行+现代编辑器”取代，越早适应这套工作流，之后换平台的学习成本就越低。

6. 从一开始就避开的五个坑

环境搭建本身不难，难的是排错。我把这几年给同事、学员排雷的高频问题汇总成一张表，你在动手之前先扫一眼，能省不少时间：

再强调一遍CubeMX里的Debug Configuration：“Serial Wire”这步一定要在生成代码之前完成，别问我为什么这么执着，我至少见过三个工程师因为这个问题返工。原则上生成完成后SWD接口默认也是好的，但一旦你改了引脚分配把SWCLK/SWDIO挪走，再想恢复就只能靠运气。

还有个小细节，很多人在Windows下用OpenOCD，命令里的路径分隔符和引号容易出问题，尤其是路径里有空格时。最稳的做法是把整个workspace路径做成全英文且无空格，比如D:\stm32\led_demo而不是D:\我的文档\LED实验板工程，能避掉很多莫名其妙的坑。

7. 我个人的一点使用心得

这套环境我用了大概两年，从最初的“VS Code + Makefile + arm-none-eabi-gcc”一步步演进到现在的“VS Code + CMake + clangd + Cortex-Debug + AI插件”。最有体会的一点是：别一次性全上。先把编译从Keil迁到命令行，确认能生成固件，再迁调试，最后再优化代码补全体验。一步到位往往会把“环境搭建问题”和“工程本身的问题”混在一起，很难排查。

还有一个特别实用的小技巧：把OpenOCD的烧录命令配置成一个特定的Task，绑定快捷键，比如Shift+F7烧录、F7编译。这看起来只是省了一次鼠标点击，但实际上它改变了你的心流——每次修改完代码、编译、烧录、看结果，整个循环可以一气呵成。Keil时代那种“等窗口唤起、等编译完成、点下载按钮、看进度条”的割裂感，会让你在迭代时下意识地放慢频率，而在嵌入式开发中，迭代速度就是生产力。

最后再分享一个收尾的经验。利用这套环境配合AI编程，最容易养成的坏习惯是“生成什么就信什么”。我在实战中测试过不少AI代码补全工具，在STM32这类文档丰富的领域，它们给出的GPIO初始化、UART发送函数、I2C读取EEPROM这类代码基本都是可用的，但只要你涉及具体的芯片版本差异、HAL库的API变更，它就经常会给出似是而非的方案。所以在工具链里保留-Wall -Wextra这些严格告警开关，保持编译器的“唠叨”，是抵御AI幻觉最有效的一层防线。

工程上的事，环境顺了，后面一切都会快起来。这套东西花一两天时间搭建好，之后你每次新建一个STM32项目，花五分钟就能进入状态，这个时间成本绝对值得投入。