企业官网建设流程全解析

干嵌入式这行，以前大家总默认 Keil MDK 或者 IAR 就是“官方指定”开发环境，哪怕界面停留在上个时代，代码补全约等于没有，也得捏着鼻子用。但这两年情况明显变了：AI 编程助手越来越猛，谁编辑器好用、谁能跟 AI 工具链打通，谁的开发效率就先起飞。VS Code 这套轻量编辑器 + 扩展插件的玩法，正好切中嵌入式开发的痛点——既不用抛弃原有的编译烧录流程，又能换来现代编辑器的补全、跳转、AI 辅助体验。

这篇系列第 07 篇，我只讲一件事：怎么把手上的 VS Code 配成一台顺手的 STM32 开发利器。从下载安装、扩展选型、工程配置到 AI 助手接入，一条龙走完。内容适合刚接触 VS Code 的嵌入式新手，也适合已经从 Keil 迁移到一半、但被各种红波浪线和配置问题卡住的人。你看完不需要再到处翻教程，照着做就能跑通编译、烧录、调试、AI 改代码的完整链路。

1. 为什么嵌入式开发者开始从 Keil 转向 VS Code

1.1 传统 IDE 的两个痛点：编辑器体验和 AI 工具接入

Keil MDK 是老牌 IDE，稳定性确实没得黑，芯片支持也全。但它的编辑器体验，说实话还停留在十几年前的水平。代码补全经常靠猜、跳转定义经常跳到空气、多文件重构基本别想，更别提现代 IDE 里早就标配的 Git 集成、终端面板、远程开发这类能力。很多从互联网转过来的同事，第一反应就是：“这东西能叫 IDE？”

STM32CubeIDE 是好一些，基于 Eclipse 深度定制，免费、集成了 CubeMX 图形化配置，对官方生态的整合度很高。但 Eclipse 系的通病它也躲不掉：启动慢、界面响应肉、插件装多了之后卡到怀疑人生。做小项目没感觉，工程一复杂——代码量大、编译时间长、还开着示波器和多路串口调试——整体操作手感明显跟不上。

比编辑器体验更关键的，是 AI 编程工具的接入。我自己这两年最大的体会是：AI 辅助写代码这件事，已经从“尝鲜”变成了“生产力刚需”。但 Keil 和 CubeIDE 对 AI 助手的支持几乎为零，既拉不进对话窗口，也没有内联代码建议。而 VS Code 的插件机制天然适合承载这些能力，把 AI 助手嵌进编辑器里，选代码、问问题、生成函数、改 bug 都是顺手的操作。对一个嵌入式项目来说，这个效率差距是实打实的。

1.2 VS Code + 扩展工具这套方案的底层逻辑

VS Code 本身不是一个 IDE，它是“编辑器 + 扩展机制”。这个定位放到嵌入式开发里，反而成了最大的优势。它的插件体系覆盖了从代码编辑、智能提示、调试、编译、串口监视到 AI 对话的全链路，开发者可以按需组装，而不是被一个形态固定的 IDE 捆住手脚。

用 VS Code 做 STM32 开发，常见的组合思路是把“编辑代码”和“编译烧录”解耦：VS Code 负责代码编辑、语法提示、AI 辅助、调试界面；编译和烧录则由底层的 arm-gcc 工具链或者 Keil/CubeIDE 的命令行接口来完成。换句话说，VS Code 不会替代你的编译器，它只是把整个开发流程的入口统一到了一个更好用的工具里。

这个方案还有一个很实用的点：你不需要做“二选一”的取舍。Keil 工程可以直接被 VS Code 打开，用扩展插件读取、调用；CubeMX 生成的工程结构也可以被 VS Code 完整识别；项目最终还能保持原有的编译环境不变。对团队协作来说，有人留在 Keil、有人用 VS Code，代码照样能在一个仓库里顺畅流转，没有门禁问题。

1.3 这套方案解决了什么问题，适合谁用

我用这套组合完成过不止一个 6 位数代码量的量产级项目，刚接触时也是踩了无数坑：路径带空格导致编译失败、头文件找不到、中文注释全乱码、AI 建议的代码在 Keil 里编译不过……但把这些坑逐一填平之后，开发体验是真的回不去了。代码补全快、跳转准、调试看变量直观，写代码时的顺手程度完全是两个维度。

它适合谁？无论你是刚开始学 STM32 的在校生，还是做车载、工控、电机驱动的在职工程师，只要你的项目里有 STM32，这套方案都值得一试。对于正在尝试把 AI 编程融入嵌入式工作流的人来说，VS Code 几乎就是目前最顺手的载体。接下来我就从零开始，把安装和配置全流程拆开讲清楚。

2. 安装 VS Code：从下载到基础配置

2.1 下载安装的几个关键细节

VS Code 的安装本身并不复杂，但有几个细节会影响后续开发体验，这里先交代清楚。

下载请认准官网 code.visualstudio.com，不要去第三方软件站下载来路不明的版本。官方包分为 User Installer（用户级安装）和 System Installer（系统级安装）两种。如果你的电脑是个人自用，建议选 User Installer，不需要管理员权限，升级也方便；如果是开发机需要给多个账户共用，才考虑 System Installer。

安装过程中有一步“选择其他任务”，务必勾选这几项：

• “添加到 PATH”：这样可以在终端里直接用code命令打开文件或目录，后面很多操作依赖这个。
• “通过 Code 打开操作”——“添加到‘打开文件夹’和‘Open Folder’操作”：方便在文件夹右键直接进入 VS Code。
• “注册为 .code 文件关联”：用处不大，但顺手勾上没坏处。

安装完成后，打开 VS Code，按Ctrl+Shift+P打开命令面板，输入about回车，能看到完整的版本号、Commit ID 和运行平台，确认安装正常即可。如果你下载的是 Insider 版，也可以继续用，只是我建议主力环境用稳定版，省得扩展兼容性上出幺蛾子。

2.2 界面语言与编辑器核心设置

VS Code 默认是英文界面。对中文用户来说，装个中文语言包很合理，不过我个人的建议是：作为嵌入式开发者，长期来看尽量保留英文界面。原因是你在搜 bug、找资料时候，遇上 Stack Overflow 和官方文档，术语对得上会少很多认知负担。当然这个纯看个人习惯，装上官方中文语言包（扩展 ID：ms-ceintl.vscode-language-pack-zh-hans）也不影响功能使用，介意英文的直接装。

接下来打开设置（Ctrl+,），说几个嵌入式开发比较关键的选项：

• files.eol设为\n：Windows 默认换行是 CRLF，而 arm-gcc 和 Makefile 体系对换行符极其敏感。先统一成 LF，能少踩很多隐蔽的坑。
• files.autoGuessEncoding打开：Keil 里很多老工程是 GB2312 编码，VS Code 默认 UTF-8 会乱码。打开这个选项，窗口会自动猜编码，减少一大半“中文全变火星文”的困扰。
• editor.formatOnSave建议打开：写完保存时自动格式化，代码风格统一，协作时 diff 也更干净。
• editor.renderWhitespace建议设为all或boundary：C/C++ 里空格和 Tab 混用的后果很严重，直接把空白字符显示出来，一眼定位问题。

2.3 工作区与工程目录规划

VS Code 的工作区（Workspace）比“打开单个文件夹”更强大。以我的习惯为例，一个 STM32 工程的标准目录通常长这样：

my_stm32_project/ ├── .vscode/ # VS Code 配置目录 │ ├── settings.json │ ├── tasks.json │ ├── launch.json │ └── c_cpp_properties.json ├── Core/ # 用户代码（CubeMX 生成） │ ├── Inc/ │ └── Src/ ├── Drivers/ # 官方固件库 ├── Middlewares/ # 中间件 ├── Hardware/ # 自己写的硬件驱动（推荐单独分目录） ├── MDK-ARM/ # Keil 工程文件 ├── Makefile # 如果用 GCC 工具链 └── build/（或 Debug/） # 编译输出

推荐在项目根目录放一个.vscode文件夹，里面保存所有个性化配置。这样项目给到别人或者换电脑，配置跟着走，不依赖本机环境。用 VS Code 打开项目根目录后，Ctrl+Shift+P执行 “File: Save Workspace As…”，生成.code-workspace文件，把多个关联子目录纳入同一个工程视图，后面操作多目录项目会更顺。

3. STM32 开发必装的扩展工具盘点

3.1 核心必备：C/C++ 与调试扩展

扩展是 VS Code 的灵魂，但也不是装得越多越好。装多了，插件之间抢占语言服务、拖慢启动速度，反而影响体验。这里按优先级给你排好，先装最核心的。

C/C++（扩展 ID：ms-vscode.cpptools）：微软官方扩展，给 VS Code 提供 C/C++ 智能感知、代码补全、调试支持。这是整个嵌入式开发体验的地基，必须第一个装。装完它，.c/.h文件才会被正确识别，Ctrl+点击跳转定义、F12 跳转声明这些功能才可用。

Cortex-Debug（扩展 ID：marus25.cortex-debug）：基于 OpenOCD 和 ST-LINK 的调试扩展，在 VS Code 里做 STM32 的断点调试、变量查看、外设寄存器查看都靠它。如果你之前只在 Keil 里用过仿真调试，到这里会发现 VS Code 的调试界面直观得多。

Keil Assistant（扩展 ID：zhang-renyang.vscode-keil-assistant）：这个扩展对还在用 Keil 工程的人来说几乎是刚需。它能直接识别 Keil 的.uvprojx文件，在 VS Code 里完成编译、烧录和打开调试器。安装后需要在设置里指定 Keil 的安装路径，然后左侧会出现 KEIL 面板，把工程文件拖进去就能用。这是很多人从 Keil 迁到 VS Code 的第一步，保留了原有编译链路，体验却提升一大截。

3.2 ST 官方扩展：STMicroelectronics 系列

这几年 ST 官方也在推 VS Code，陆续发布了几个官方扩展，值得关注：

• STM32 VS Code Extensions（扩展 ID：stmicroelectronics.stm32-vscode-extension-pack）：合集包，整合了 STM32CubeProgrammer、STM32CubeMX 和 ST-LINK 相关功能。装完可以在 VS Code 里直接调用 STM32CubeMX 生成初始化代码，也可以通过 STM32CubeProgrammer 查看芯片信息、烧录程序。
• STM32CubeMX（扩展 ID：stmicroelectronics.stm32-cube-mx）：把 CubeMX 的图形化配置入口集成到 VS Code 内部，生成代码后自动刷新生工程结构。
• Embedded Tools（扩展 ID：ms-vscode.embedded-tools）：微软官方的嵌入式工具扩展，提供跨平台的工具链管理和调试配置。如果你用 Makefile 工程，它能把编译、烧录、调试的按钮直接整合到 VS Code 的状态栏和命令面板里。

不过要说清楚：ST 官方扩展目前更适合配合 CubeIDE 或是 GCC 工具链的 Makefile 工程使用。如果你的搭档项目还是 Keil.uvprojx主导，Keil Assistant 仍然是同时存在的最优选择。

3.3 AI 编程助手集成：Kimi、Codex、Continue 等

这可能是 VS Code 相比传统 IDE 最吸引人的部分。目前主流的 AI 编程插件有好几个流派，我挨个说下它们在嵌入式场景的实际表现。

Kimi 的 VS Code 扩展：在应用市场搜索 “Kimi” 就能找到。装上后会在侧栏打开 AI 对话窗口，也支持内联代码建议。它的优势是对中文用户友好，能理解“帮我写一个 STM32 的 GPIO 初始化函数，PA5 输出高电平”这种中文直白指令，生成代码时还会带上注释结构。在我实测过的嵌入式场景里，Kimi 对 STM32 HAL 库和 LL 库的掌握已经到了相当可用的程度。

Codex 或 Claude Code 这类 CLI 型助手：它们以命令行模式运行，在 VS Code 集成终端里调用。这类工具适合做整文件生成、跨文件重构，但需要你自己有 API Key 或服务订阅。用它们时注意一点：生成代码后务必仔细 review，因为它们对项目上下文的理解有时不如纯对话型插件强。

Continue 等开源插件：支持自定义模型接入，比如接入 DeepSeek、本地模型等。这类插件灵活，适合对隐私和数据安全有要求的环境。如果你公司要求代码不能出内网，就用这种方案，配合本地模型跑嵌入式代码补全，体验也不差。

不管选哪个，建议先只装一个 AI 插件，跑通一个完整的小项目后再叠加。插件之间抢焦点的问题很烦人，尤其是在嵌入式单步调试场景里，断点被抢走会让你怀疑人生。

3.4 辅助工具类扩展：串口监视、Hex 查看、图标主题

除了核心编译调试插件，还有几个“小却不废”的扩展值得装：

• Serial Monitor（扩展 ID：ms-vscode.vscode-serial-monitor）：在 VS Code 内部直接查看串口输出。做 STM32 调试的时候，printf 是最常用的调试手段，不用单独开串口助手，直接在编辑器底部看输出，配合正则过滤还能高亮关键日志，效率高不少。
• Hex Editor（扩展 ID：ms-vscode.hexeditor）：查看 bin/hex 文件时必备。烧录前检查固件开头几个字节是不是正确的向量表，非常方便。
• C/C++ Include Guard（扩展 ID：danielpinto8zz6.c-cpp-project-generator也有类似能力，但这个最经典）：自动管理头文件的#ifndef保护宏，杜绝头文件重复包含的问题。
• GitLens（扩展 ID：eamodio.gitlens）：如果你的项目有 Git 管理，这个扩展能把每行代码的提交记录、作者、提交时间直接显示在行内。排查“这个改动是谁提的、当时为什么这么写”的时候，效率极高。

图标主题这类纯视觉插件，可用可不用，装上也不碍事。但你要是建议团队统一开发环境，最好定下一个公共插件清单，文档化告知，免得每个人装的扩展参差不齐、配置互相打架。

4. 实操：用 VS Code 打开 STM32 工程并打通智能提示

环境准备就绪，下面进入核心实操环节。我按“完整跑通一个小项目”的流程走一遍，从新建工程到 AI 接入，每步都给出实际可用的配置。

4.1 准备一个干净的 STM32 工程

先准备一个 STM32 工程。有两个入口可选：

1. 用 STM32CubeMX 生成一个 Makefile 工程（选好芯片型号，配置时钟、GPIO、USART，然后 Project Manager 里 Toolchain/IDE 选 Makefile）。这样会自动生成一套干净的 GCC 工程结构。
2. 如果你手头有一个现成的 Keil 工程，直接用也可以，配合 Keil Assistant 扩展继续用 Keil 的编译链路。

我强烈建议新手第一次走方案 1：Makefile 工程结构最简单，没有 IDE 依赖，arm-gcc 工具链通用性也最强。Git 管理起来也干净。

用 CubeMX 生成工程后，用 VS Code 打开项目根目录，第一件事是确认强项识别：左侧资源管理器能看到Core、Drivers这些目录，右下角没有弹出“检测到 C/C++ 项目需要配置”的提示。如果没反应，按Ctrl+Shift+P执行 “C/C++: Edit Configurations (UI)”，进入配置界面。

4.2 配置 IntelliSense：c_cpp_properties.json

智能提示是整个 VS Code 嵌入式体验的重中之重。C/C++ 扩展靠c_cpp_properties.json决定它能“看到”哪些头文件，能“认识”哪些宏定义。我拿一个 STM32F407 的工程举例，直接在.vscode/c_cpp_properties.json里配置：

{ "env": { "armGccPath": "C:/ST/STM32CubeCLT_1.15.0/GNU-tools-for-STM32/bin" }, "configurations": [ { "name": "STM32", "includePath": [ "${workspaceFolder}/**", "${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": "${armGccPath}/arm-none-eabi-gcc.exe", "cStandard": "c11", "intelliSenseMode": "linux-gcc-arm" } ], "version": 4 }

这里几个字段的含义和配置要点：

• includePath：告诉扩展去哪找头文件。直接把工程根目录${workspaceFolder}/**加进去是最省事的做法，但工程大了之后搜索会变慢。建议按实际用到的子目录一项项列出来，性能好很多。
• defines：把 CubeMX 生成的宏定义照抄过来。USE_HAL_DRIVER和STM32F407xx这两行决定了 HAL 库代码能否正确展开，漏掉任何一个都会产生大片的红色波浪线。
• compilerPath：指向 arm-none-eabi-gcc 的实际位置。装了 STM32CubeCLT 或者 arm-gcc 工具链后，把路径填进去，这部分的语法解析才能精准匹配。
• cStandard：C11 是当前主流默认值，如果你的项目用了更老的 C99 语法，改成c99也行。

配置完保存，VS Code 会自动重新扫描索引。这会儿再去打开main.c，你会发现#include "main.h"的红色波浪线消失了，鼠标悬停能看到 HAL 库的类型定义，Ctrl+点击能直接跳到库函数源码。到这一步，VS Code 的代码浏览体验就已经超过 Keil 一个身位了。

4.3 编译任务配置：tasks.json

编译是另一个必须打通的环节。如果你的工程是 CubeMX 生成的 Makefile 工程，装好 Embedded Tools 扩展后，可以直接在命令面板里执行 “Embedded Tools: Build” 来编译。但如果想编译完顺手把错误报错也在“问题”面板里高亮出来，还是要写一个tasks.json。

我常用的配置如下（用的是 STM32CubeCLT 里自带的 make）：

{ "version": "2.0.0", "tasks": [ { "label": "STM32 Build", "type": "shell", "command": "make", "args": ["-j8"], "options": { "cwd": "${workspaceFolder}" }, "group": { "kind": "build", "isDefault": true }, "problemMatcher": ["$gcc"] } ] }

关键点解析：

• command用make，前提是系统环境变量里已经加入 make 的路径。如果用的是 STM32CubeCLT 或者 XPack 的 arm-gcc 工具链，还需要确保make也在同一套工具链路径下，不然找不到命令。
• -j8是并行编译参数，数字跟 CPU 核心数匹配能显著缩短编译时间。我八核机器开-j12，实测比单线程快 70% 左右。
• problemMatcher设为$gcc，这样编译报错会直接出现在“问题”面板，点击错误信息还能跳转到对应代码行，省去了在终端里翻滚动条的痛苦。

如果你的工程还是 Keil 体系，而是在用 Keil Assistant 扩展，那不需要写 tasks.json，直接在 Keil 面板点编译按钮即可，扩展会调用 Keil 的 UV4.exe 完成编译，并把结果信息回传到 VS Code。

4.4 调试配置：launch.json

调试配置是很多人的盲区，但一旦配好，开发效率提升非常明显。用 VS Code 调 STM32，目前最稳定的方案是 Cortex-Debug + ST-LINK + OpenOCD（或 STM32CubeProgrammer 的 GDB Server）。

先确保电脑上安装了：

• STM32CubeProgrammer（内含 GDB Server 和烧录工具）
• OpenOCD（可选，如果不想用 CubeProgrammer 可以用它）

然后在.vscode/launch.json里写如下配置：

{ "version": "0.2.0", "configurations": [ { "name": "STM32 Debug (ST-LINK)", "cwd": "${workspaceFolder}", "executable": "./build/my_stm32_project.elf", "request": "launch", "type": "cortex-debug", "servertype": "stlink", "device": "STM32F407VG", "interface": "swd", "runToEntryPoint": "main", "svdFile": "${workspaceFolder}/.vscode/STM32F407.svd" } ] }

几个需要注意的地方：

• executable指向编译输出的.elf文件路径。如果你用 Keil，Keil 输出的是.axf文件，Cortex-Debug 也支持，但要确认路径正确。
• servertype有stlink、openocd、jlink、pyocd可选，按你的调试器选择。
• device填写芯片型号，要和工程里的一致。
• svdFile指向芯片外设描述文件.svd。这个文件可以在 MCU 厂商官网下载，也可以从 CubeMX 安装目录里找到。填上之后，调试时可以实时查看寄存器的位域含义，比对着数据手册一个个查方便太多。

调试配置一旦跑通，按F5就能直接进入调试界面，设置断点、单步执行、查看变量和寄存器，体验完全不输给正经 IDE。配合接下来的 AI 编程能力，整个工作流就很顺了。

4.5 接入 AI 编程助手：Kimi 实操示例

环境打好之后，接入 AI 编程助手是最后一步。以 Kimi 的 VS Code 扩展为例，安装后在侧栏就能打开对话窗口。首次使用需要登录账号，之后就能开始对话。

我实际使用中比较顺手的几个场景：

场景一：向 AI 解释代码。

选中stm32f4xx_hal_msp.c里的一整个函数，右键选择 “Kimi: 解释所选代码”，它能直接输出函数职责、每个段落的含义、涉及的寄存器和外设。这个功能对快速上手不熟悉的 HAL 库或第三方驱动代码特别有用。

场景二：让 AI 生成指定功能代码。

在对话窗口输入类似：

“用 STM32F407 的 TIM2 产生 PWM 输出，频率 20kHz，占空比 30%，CH1 输出到 PA0，使用 HAL 库初始化。”

它会返回可以直接粘贴进工程里的代码。我建议把对话内容中的初始化和业务逻辑分开，初始化代码跟 CubeMX 的MX_TIM2_Init()对照检查，看有没有冲突；业务逻辑部分则放在while(1)里，看会不会影响主循环节奏。

场景三：让 AI 修复编译报错。

把终端里的编译错误信息直接复制粘贴给 AI，让它分析原因并给出修复建议。实测下来，对 undefined reference、implicit declaration 这类嵌入式高频错误，AI 给出的答案大部分是靠谱的，但有一个前提：需要把出错的代码片段一起发过去，只发错误信息的话它经常瞎猜。

关于 AI 编程有一个必须强调的纪律：任何 AI 生成的代码，放进工程前先过一遍对硬件寄存器的描述。HAL 库的逻辑错误未必能靠编译发现，跑起来可能直接 HardFault。我自己的习惯是，AI 生成代码之后至少做一次全量git diff，看清每一处修改再合入。用 AI 是提效，不是省掉 review。

5. 常见问题排查实录

5.1 红色波浪线：IntelliSense 不识别 STM32 头文件

这是被问得最多的问题。现象很典型：用 VS Code 直接打开 Keil 工程，#include "stm32f4xx_hal.h"下面一片红，但 Keil 里编译完全正常。

排查顺序如下：

1. 打开.vscode/c_cpp_properties.json，确认 includePath 是否覆盖了 HAL 库和 CMSIS 头文件目录。
2. 查看 defines 里是否定义了USE_HAL_DRIVER和你所用芯片的型号宏。
3. 确认 compilerPath 指向的是 arm-none-eabi-gcc 的路径，如果填成了系统自带的 x86 gcc，很多 ARM 特有语法会识别失败。

最常见的坑是 Keil 工程目录里没有 Makefile，VS Code 不知道编译参数怎么传，includePath 只能靠手动维护。如果你项目里既有 Keil 也用了 VS Code，我建议在配置维护上以c_cpp_properties.json为唯一基准，不要同时依赖 C/C++ 扩展的“从编译数据库自动解析”功能，因为.uvprojx里的头文件路径和编译参数格式，C/C++ 扩展不一定能完全解析，反而容易产生误导信息。

5.2 Keil Assistant 点击编译没反应或报 UV4.exe 不存在

这个问题的原因基本都是 Keil 路径没配对。打开设置，搜索 “Keil Assistant”，把Keil Assistant > Keil.UV4.Path配置成C:\Keil_v5\UV4\UV4.exe这样的完整路径。

另一个常见的隐藏坑：Keil 安装目录包含中文或空格。VS Code 的扩展插件在调用外部命令时，空格路径处理不当就会失败。遇到这种情况，不需要重装 Keil，直接在系统层面给 Keil 安装目录创建一个不带空格符号的目录链接（比如C:\Keil_v5指向实际安装路径），就能简单解决。

5.3 编译报错“make: command not found”

说明 make 命令不在系统 PATH 里。用 STM32CubeCLT 或 XPack 工具链的小伙伴，需要在系统环境变量里手动把 make 所在的目录加入 PATH。Windows 下打开“系统属性 -> 环境变量”，找到Path变量，把类似C:\ST\STM32CubeCLT_1.15.0\GNU-tools-for-STM32\bin和C:\ST\STM32CubeCLT_1.15.0\MakeTools\bin追加进去。这是嵌入式工具链环境变量配置最基础的通过项。

Linux/macOS 下如果没装 make，直接sudo apt install make（或者对应包管理器）即可。

5.4 编码问题：中文注释变乱码

老 Keil 工程最常见的毛病就是编码。新工程的默认编码是 UTF-8，而老 Keil 工程往往是 GB2312，VS Code 默认按 UTF-8 解码自然就乱了。解决方式是两步：

1. 点击右下角的编码按钮，手动选择 “GB2312（Simplified Chinese）” 重新打开文件。
2. 在settings.json中把files.autoGuessEncoding设为true，以后新文件打开时自动猜编码，省得每次手动切换。

如果要彻底根治，建议在工程里统一：把所有源文件重新保存为 UTF-8 编码。注意这个操作要在确认编译没问题之后再做，不然转换过程可能会破坏文件，那是相当折腾的。

5.5 AI 生成的代码编译通过但运行异常

这个现象在嵌入式里太典型了。AI 生成代码能编译过，不代表它对你的硬件配置是正确的。最典型的例子：AI 让我配置过 SPI，它给的是软件模拟 SPI 的代码，而我硬件上接的是 SPI1 外设，两者寄存器完全不同。这种逻辑错编译根本发现不了。

我的经验是：AI 代码进工程后，先在关键初始化后面加几个 GPIO 翻转或串口打印，跟踪执行流程；遇到异常中断，直接看 SVD 里的寄存器实时值，跟数据手册逐项比一遍。将这套“验证套路”养成习惯之后，你踩的坑会大幅减少。

6. 顺手养成的一些小习惯

环境搭好只是开始，真正的效率来自日常使用中的习惯沉淀。分享几个我自己实践下来觉得特别有用的操作。

用 Git 做“AI 代码安全垫”。每次让 AI 改代码之前，先git add . && git commit -m "before AI changes"，改完如果翻车直接git checkout -- .回复原状。这个习惯帮我避免过很多次“AI 一顿操作猛如虎，改完发现坏得离谱”的尴尬场景。

快捷键优先。VS Code 里Ctrl+P快速打开文件、Ctrl+Shift+O跳转符号、F12跳转定义、Alt+←返回。这几个快捷键用熟之后，写大工程时双手基本不离键盘，效率比鼠标流高非常多。

终端面板常驻。编译命令、串口日志、Git