VS Code on KnightLi的博客

VS Code 切换界面语言的方法：中文、英文和其他语言

Fri, 08 May 2026 13:28:14 +0800

VS Code 支持多种界面语言。常见做法是先安装对应语言包，再通过命令面板选择显示语言；如果需要固定某种语言，也可以手动修改 argv.json 中的 locale。

这套方法不仅适用于简体中文，也适用于英文、繁体中文、日文、韩文、法文、德文、西班牙文等语言。

安装对应语言包

如果要切换到非英文界面，通常需要先安装语言包。

打开 VS Code 左侧扩展面板，也可以使用快捷键 Ctrl+Shift+X。
在搜索框中输入目标语言，例如 Chinese、Japanese、Korean、French。
选择对应语言包，点击 Install。
安装完成后，按提示重启 VS Code。

简体中文常用语言包是 Chinese (Simplified)，繁体中文常用语言包是 Chinese (Traditional)。

通过命令面板切换语言

这是最推荐的切换方式，适合大多数用户。

打开命令面板：Ctrl+Shift+P。
输入 Configure Display Language。
选择 Configure Display Language 命令。
在列表中选择要使用的语言。
按提示重启 VS Code。

重启后，菜单、设置页和常见提示会切换到所选语言。如果列表里没有目标语言，先到扩展面板安装对应语言包。

通过 argv.json 手动指定语言

如果命令面板切换失败，或者想明确固定显示语言，可以直接修改 VS Code 的运行时参数文件。

打开命令面板：Ctrl+Shift+P。
输入并选择 Preferences: Configure Runtime Arguments。
找到或添加 locale 配置项。
把值改成目标语言代码。
保存后重启 VS Code。

例如切换为英文：

1
2
3

{
  "locale": "en"
}

切换为简体中文：

1
2
3

{
  "locale": "zh-cn"
}

切换为日文：

1
2
3

{
  "locale": "ja"
}

argv.json 是 JSON 文件，修改时要注意逗号和引号。配置写错时，VS Code 可能无法正确读取语言设置。

常用界面语言代码

显示语言	locale
English (US)	`en`
简体中文	`zh-cn`
繁体中文	`zh-tw`
French	`fr`
German	`de`
Italian	`it`
Spanish	`es`
Japanese	`ja`
Korean	`ko`
Russian	`ru`
Portuguese (Brazil)	`pt-br`
Turkish	`tr`
Bulgarian	`bg`
Hungarian	`hu`

语言没有生效怎么办

可以按下面顺序排查：

确认目标语言包已经安装。
确认 locale 写的是正确语言代码，例如简体中文是 zh-cn，不是 zh-CN。
修改语言后完整关闭并重新打开 VS Code。
如果手动改过 argv.json，检查 JSON 语法是否正确。
如果配置混乱，可以删除 locale 项，再通过 Configure Display Language 重新选择。

一般来说，通过 Configure Display Language 切换最省事；只有在需要强制指定语言或命令面板切换不生效时，才建议手动修改 argv.json。

参考资料

VScode：将VScode界面的显示语言改为简体中文，切换VScode界面的显示语言

2026 年嵌入式开发环境怎么选：Keil、STM32CubeIDE、VS Code 与 AI 协作

Wed, 22 Apr 2026 23:05:00 +0800

只要你还在做单片机或者嵌入式开发，很快就会遇到一个很现实的问题：到了 2026 年，在 AI 写代码已经越来越普遍的情况下，开发环境到底应该怎么选？

这个问题表面上像是在比较几个 IDE，实际讨论的却是另一件事：你到底是要一个“能把工程跑起来的工具”，还是一套“兼顾生态、编码体验和 AI 协作能力”的工作流。

如果按这个角度去看，答案往往就不是简单地在 Keil、STM32CubeIDE、VS Code、CLion 里选一个，而是重新组合它们各自最擅长的部分。

先看几个主流选项，各自解决什么问题

嵌入式领域这些年常见的环境，基本还是那几类：

Keil
STM32CubeIDE
VS Code
CLion

如果再往前追，当然还会有人提 IAR。只是从今天的讨论出发，更值得看的已经不是“谁资格最老”，而是谁更适合当前这套开发现实。

Keil：生态强、上手稳，但编辑体验已经明显落后

Keil 到今天仍然很难绕开，原因不复杂：它用得实在太广了。

无论是公司里留下来的老工程，还是网上大量教程、资料、示例工程，很多都还是围绕 Keil 组织的。它在编译、下载、调试这一整套流程上依然成熟，尤其是你真的要把板子跑起来时，它的路径非常短。

它的问题也同样明显：

界面老
编辑体验一般
不擅长承担 AI 辅助编码的主场

所以 Keil 更像是一个“工程入口和调试底座”，而不是一个面向 2026 年编码体验的理想编辑环境。

STM32CubeIDE：对 STM32 友好，但更多是学习和快速起步工具

如果你主要在 STM32 生态里活动，STM32CubeIDE 很容易成为第一个接触到的环境。

它的优点很明确：

上手友好
外设配置和工程生成方便
调试链路相对完整

对学生、新手和刚起步的项目来说，这套体验确实足够直接。

但一旦进入更长期、更多协作、更多定制的工程环境，它的局限也会慢慢暴露出来。尤其是在商业项目或者更复杂的团队工作流里，它未必是那个最舒服的主环境。

所以它更适合“快速启动”和“STM32 生态内的一体化体验”，不一定适合作为长期主力编辑器。

VS Code：严格说不是 IDE，但在 AI 时代优势越来越明显

VS Code 严格来说并不是传统意义上的 IDE，更准确地说，它是一个可扩展的代码编辑器。

这也意味着它天然有两面性。

它的弱点是：

需要插件和配置
对新手不够友好
不能开箱即用地替代嵌入式 IDE 全流程

但它真正强的地方，恰恰也在这里：

可扩展性强
编码体验明显更现代
语法高亮、跳转、搜索、重构体验更好
对 AI 工具和 Agent 工作流支持更积极

在今天这个阶段，很多人真正需要的已经不只是“能写代码”，而是“写代码时能不能顺手把 AI 协作接进来”。从这个角度看，VS Code 的优势几乎是肉眼可见的。

CLion：体验不错，但在嵌入式场景里不够主流

CLion 经常会被提到，因为它的 C/C++ 编码体验一直不差。

但对很多嵌入式开发者来说，它的问题不一定出在“好不好用”，而是“值不值得切过去”：

用的人相对少
与现有嵌入式工程生态连接不如 Keil 直接
在 AI 协作这件事上，也未必比 VS Code 更有现实优势

所以它更像是一个“理论上也能做得不错”的选项，但在今天的嵌入式主流工作流里，并不是最自然的那个核心。

更现实的答案：Keil 负责编译调试，VS Code 负责写代码

如果把上面这些工具拆开看，很容易得到一个更务实的结论：

用 Keil 保留现有工程生态、编译、下载和调试能力
用 VS Code 承担日常编码、搜索、跳转和 AI 协作

这套组合的价值在于，它不是试图用一个工具包打天下，而是让每个工具回到自己最擅长的位置。

对很多嵌入式工程来说，Keil 的生态根本绕不开。既然如此，与其强行把所有工作都塞回 Keil，不如承认它更适合作为后端编译调试入口；而真正的编辑体验，则交给 VS Code。

为什么这套组合在 AI 时代更有优势

到了今天，开发环境的分界线已经不只是“编辑器顺不顺手”，而是“它能不能自然接入 AI”。

VS Code 在这件事上有几个很现实的优势：

AI 插件和 Agent 支持更活跃
代码浏览体验更适合让 AI 读工程、改工程
更容易和现代插件生态结合

这意味着你可以把嵌入式开发里最痛苦的一部分工作，开始交给 AI 帮你分担：

在现有工程里找函数和调用链
快速生成一段初始化代码
帮你补一个串口打印
解释旧工程结构
在已有文件里做小范围修改

这些事情过去不是不能做，而是做起来不顺。VS Code 的意义不只是“更好看”，而是它更容易成为 AI 协作的工作台。

关键补丁：用插件把 VS Code 和 Keil 工程接起来

这套工作流能不能成立，核心不在口号，而在你能不能把 VS Code 和 Keil 工程接起来。

比较实用的一类插件思路，是让 VS Code 直接读取 Keil 工程结构，并在编辑器内部调用 Keil 后台程序完成：

打开工程
编译
下载

这样一来，你日常写代码不用频繁在两个界面之间来回切，只有到了更重的调试环节，再回到 Keil 里做单步、断点和寄存器观察。

这类插件真正有价值的地方，不只是“少切几个窗口”，而是它让工作流连续起来了。

不要忽视 C/C++ 基础插件配置

如果你打算把 VS Code 当作嵌入式主编辑器，一个非常基础但常被忽略的点是：一定要把 C/C++ 基础插件和工程索引配置好。

否则你会遇到一系列很影响体验的问题：

跳转不到定义
红线误报
补全不准
头文件关系混乱

很多人会误以为是 VS Code 不适合嵌入式，实际上往往只是工程索引和插件配置没接好。

一旦这部分配置完整，VS Code 才能真正发挥出它在阅读大型工程、搜索符号、配合 AI 辅助修改代码上的优势。

这套工作流最适合谁

我觉得下面这几类人，会特别适合这种组合式环境：

1. 已经有大量 Keil 工程的人

如果你公司项目、课程资料或者历史代码都围绕 Keil 展开，那就没必要为了“现代化”硬切掉原有生态。保留 Keil，再补一个 VS Code 前端，是迁移成本最低的做法。

2. 想用 AI 辅助写嵌入式代码的人

如果你已经习惯让 AI 帮你解释函数、补样板代码、改局部逻辑，那么 VS Code 会比传统嵌入式 IDE 更自然地承接这件事。

3. 想同时兼顾学习资料和真实项目的人

很多学习资料仍然建立在 Keil 上，但你自己的工作流未必要停留在那个年代。把 Keil 作为工程兼容层，把 VS Code 作为生产力层，会更平衡。

结语

到了 2026 年，嵌入式开发环境的关键问题，已经不再只是“哪个 IDE 功能更多”，而是“哪种组合最符合今天的工作方式”。

如果你只想快速起步，STM32CubeIDE 依然有它的位置；如果你要稳定接住大量既有工程，Keil 依然绕不开；但如果你还想把现代编辑体验和 AI 协作一起接进来，那么更现实的答案，往往是：

Keil 负责编译和调试，VS Code 负责写代码。

这不一定是唯一答案，但很可能是当下最不拧巴的一种答案。

在 VS Code 里接入 Claude：从 API 配置到网页生成

Thu, 16 Apr 2026 17:47:17 +0800

如果你已经开始把大模型带进日常开发，最直接的感受通常不是“会不会写代码”，而是“能不能把很多零碎工作一次性推进起来”。

这类工具真正有价值的地方，不只是补全几行代码，而是能在编辑器里同时完成对话、改文件、预览结果和继续迭代。对于简单页面、原型验证、样式调整和功能补齐，这种工作方式往往比传统的手动来回切换更顺手。

这篇就整理一下，一个比较实用的思路：在 VS Code 里接入 Claude 一类模型之后，怎么把它用在真实的页面生成和小功能迭代上。

一、先把工具链接通

这类 AI 编程插件的核心流程其实都差不多：

在 VS Code 里安装支持对话式改代码的插件
在插件设置里填入模型服务的 Base URL
配置自己的 API Key
选择要使用的模型名称

完成这几步之后，编辑器里的 AI 能力才算真正可用。后面的体验差异，大多不在“能不能用”，而在“模型质量怎么样、插件交互是否顺手、生成结果是否稳定”。

如果你之前没有配过这类插件，可以把它理解成这样：

插件负责把你的自然语言请求变成编辑器里的操作流程
API 负责把请求发送给模型服务
模型负责理解你的需求并返回代码、修改建议或结构化结果

所以真正要配对的，其实就是三件事：插件、接口地址、模型名。

二、适合先从小任务开始

很多人第一次上手，会希望它直接帮自己“做一个完整项目”。这不是不行，但对新手来说，最容易建立正确预期的方式，反而是先从非常小的任务开始。

比如：

生成一个简单的前端页面
给现有页面补一个公告区域
增加注册表单
调整界面，让样式更正式一些

这种任务有几个好处：

指令足够清楚，模型更容易理解
结果可以立刻预览，反馈很快
你能明显看到“对话”和“改代码”是如何联动的

当需求比较明确时，插件通常会一边在侧边栏里和你对话，一边直接修改右侧文件。等到任务完成之后，你再看生成结果、预览页面、决定要不要继续追加需求，这个节奏会比纯聊天自然很多。

三、真正提效的不是一次生成，而是连续迭代

AI 编程最容易被误解的一点，是大家总把注意力放在“第一次生成得像不像”。

但在实际使用里，更重要的往往是第二轮、第三轮还能不能顺着改下去。

一个比较常见的过程是：

先让它快速生成一个能跑的页面骨架
再追加一两个明确功能
然后观察代码和界面是否一起变得更完整

如果工具体验比较顺，整个过程会很像你在带一个执行速度很快的初级开发同事：

你提需求
它先做出一版
你指出哪里不够
它继续修改

这种“连续对话式迭代”比单次生成更接近日常开发场景，也是它最容易拉开效率差距的地方。

四、要学会区分“适合交给 AI 的部分”和“自己顺手改更快的部分”

这也是非常关键的一点。

像页面布局、组件初稿、表单骨架、样式润色、文案占位、重复性代码补齐，这些通常都很适合交给 AI 先做。

但如果只是：

改一行按钮文字
调整一个页脚说明
换一个很小的样式细节

很多时候自己直接改会更快。因为这种修改的成本已经低到，不值得再发起一次完整的模型交互。

真正高效的使用方式，不是“什么都交给 AI”，而是知道什么时候该让它一口气做完大块工作，什么时候自己收尾更省时间。

五、API 配置是门槛，但不是难点

不少人卡住，其实不是卡在写代码，而是卡在插件配置。

常见需要确认的内容通常包括：

接口地址是不是填对了
密钥是不是有效
模型名称是不是和服务端一致
插件是否要求特定格式的 Base URL

只要这几项有一项不对，插件表面上可能还能打开，但真正发请求时就会失败。

所以如果你发现插件没有正常工作，排查顺序通常可以很简单：

先看接口地址
再看密钥
最后看模型名和插件要求的格式

把这三项核对清楚，大多数接入问题都能快速定位。

六、怎么看生成结果值不值得继续用

一个比较实用的判断标准，不是看它“惊不惊艳”，而是看下面这几件事：

生成出来的页面能不能直接跑起来
结构是不是基本清楚
追加需求后有没有明显跑偏
改动量变大时，是否还能保持一致性

如果一两轮对话之后，它已经能把页面从空白推进到一个可继续修改的状态，那这个工具基本就有实用价值了。

反过来说，如果每次生成都需要你大面积返工，那它带来的就不是提效，而只是把“写代码”换成了“审代码”。

结语

在 VS Code 里接入 Claude 一类模型，最值得期待的不是“从此不写代码了”，而是很多原本零散、重复、容易打断思路的工作，可以被一次性打包推进。

更现实的用法是：

让它先搭页面和功能骨架
用连续对话完成两三轮迭代
自己处理最后那些细小但确定的修改

这样配合下来，AI 更像一个加速器，而不是一个必须完全接管开发流程的替代者。

Windows 上在 VS Code 里构建 Docker 镜像：从环境准备到一键构建

Thu, 16 Apr 2026 10:20:00 +0800

如果你想在 Windows 上直接用 VS Code 管理并构建 Docker 镜像，流程其实很短。核心就是三步：先把环境装好，再准备 Dockerfile，最后执行构建。

01 前置准备

先确认两项基础条件：

安装并启动 Docker Desktop。
在 VS Code 里安装 Microsoft 官方 Docker 扩展。

在 Windows 上，建议把 Docker Desktop 切到 WSL 2 后端（Settings > Resources > WSL Integration），一般会更稳定、性能也更好。

02 准备 Dockerfile

如果项目里还没有 Dockerfile，可以直接让 VS Code 生成：

在 VS Code 打开你的项目目录。
按 F1 或 Ctrl+Shift+P 打开命令面板。
运行 Docker: Add Docker Files to Workspace。
选择你的平台（例如 Node.js、Python、.NET），按提示完成。

执行后通常会得到至少两个文件：

Dockerfile
.dockerignore

这一步的价值是先有一个可工作的基础版本，后面再按项目需求微调。

03 构建镜像的三种方式

方式 A：右键 Dockerfile

在资源管理器中右键 Dockerfile，选择 Build Image...，然后输入镜像标签（tag）。

方式 B：命令面板

按 F1 运行 Docker: Build Image，再按提示选择上下文和标签。

方式 C：集成终端命令

`1`	`docker build -t your-image-name .`

这条命令表示用当前目录作为构建上下文，生成名为 your-image-name 的镜像。

04 常见问题快速检查

Docker Desktop 没启动：先确认托盘图标显示为运行状态。
构建很慢：优先检查是否启用 WSL 2 后端。
构建失败提示找不到文件：确认执行目录是项目根目录，且 Dockerfile 在上下文内。
扩展看不到 Docker 资源：重启一次 VS Code，或确认 Docker CLI 可用（docker version）。

小结

在 Windows 上用 VS Code 构建 Docker 镜像并不复杂。先安装 Docker Desktop 和 Docker 扩展，再用命令面板生成 Dockerfile，最后用右键或 docker build 即可完成日常构建流程。

使用 Agent Skills 取代 VS Code 中 Copilot 的“生成提交消息”的功能

Mon, 06 Apr 2026 13:09:49 +0800

VS Code 的 GitHub Copilot “生成提交消息” 是一个非常实用的功能。配额用尽以后重置周期会非常长。本文是使用本地 Agent Skills，取代这个功能的一个尝试。

问题与目标

本文目标是提供一套可直接落地的替代方案：使用 git-commit-push-zh skill agents 完成标准化提交与推送。

替代方案：`git-commit-push-zh`

该 skill 将“当前改动”收敛为固定流程：

查看变更状态。
确认当前分支。
暂存改动。
生成中文提交信息。
执行 commit。
推送到远端分支。

对应命令如下：

git status --short
git branch --show-current
git add -A
git commit -m "<中文提交信息>"
git push origin <当前分支>

提交信息建议规范

建议统一格式：

`1`	`<类型>(<范围>): <中文摘要>`

类型示例：

feat：新增功能
fix：修复问题
docs：文档更新
refactor：代码重构
chore：维护性改动

示例：

feat(site): 新增全站 head 广告脚本注入
fix(i18n): 修正 relref 相关文章链接路径
chore(content): 合并 AI 工作流分类到 AI工具

常见失败场景

nothing to commit：当前无可提交改动，停止推送即可。
push 失败：优先检查权限、远端分支状态、冲突。
SSH/权限异常：确认凭据与权限后再重试。

附录：原始 `SKILL.md`

以下内容为 git-commit-push-zh 的原始文档，原样保留，便于后续复用与维护。

---
name: git-commit-push-zh
description: 在当前 Git 仓库中将“当前更改”完成一次标准提交流程：检查状态、暂存变更、生成中文提交信息、执行 commit 并 push 到当前分支对应远端。用户提出“提交代码”“提交当前更改”“生成中文提交信息并推送”“git commit push 中文说明”等请求时使用。
---

# 中文提交并推送

使用此技能将当前仓库改动一次性提交并推送到远端。

## 工作流程

1. 查看变更状态：`git status --short`。
2. 确认当前分支：`git branch --show-current`。
3. 暂存当前变更：`git add -A`。
4. 生成中文提交信息（简洁、可检索）。
5. 执行提交：`git commit -m "<中文提交信息>"`。
6. 执行推送：`git push origin <当前分支>`。

## 提交信息规范（中文）

1. 建议格式：`<类型>(<范围>): <中文摘要>`。
2. 类型示例：`feat`、`fix`、`chore`、`docs`、`refactor`。
3. 摘要要求：准确描述本次改动，不写空话。
4. 若仅少量变更，也保持可读性与可检索性。

示例：

- `feat(site): 新增全站 head 广告脚本注入`
- `fix(i18n): 修正 relref 相关文章链接路径`
- `chore(content): 合并 AI 工作流分类到 AI工具`

## 错误处理

1. 若无可提交变更（nothing to commit），明确告知并停止 push。
2. 若 push 失败，先回报关键错误（权限、远端不存在、冲突等）。
3. 常见 SSH/权限问题可在用户确认后重试高权限环境。

## 输出约定

1. 汇报提交哈希、分支名、提交信息。
2. 汇报 push 结果（成功或失败原因）。
3. 仅在确有失败时提供下一步最小操作建议。

如何排查由插件引起的 VS Code CPU 占用过高

Wed, 01 Apr 2026 00:00:00 +0000

VS Code 突然变卡、风扇狂转、CPU 长时间高占用时，最常见原因通常不是编辑器本体，而是扩展插件冲突或插件行为异常。

这篇文章给你一套可以立即执行的排查路径，优先用最省时间的方法定位问题。

先做最快的定位：Start Extension Bisect

Start Extension Bisect 的核心思路是二分法：每一轮临时禁用一半扩展并重启，通过你反馈“问题是否仍存在”，快速缩小范围，直到定位到可疑插件。

操作步骤：

按 Ctrl+Shift+P（macOS 为 Cmd+Shift+P）打开命令面板。
输入并执行 Start Extension Bisect。
每次重启后观察 CPU 占用和卡顿是否复现。
重复几轮后，VS Code 会给出可疑扩展列表。

定位后怎么处理

找到可疑插件后，建议按这个顺序处理：

先更新插件到最新版本。
若无改善，临时禁用该插件 1-2 天观察。
对于功能可替代的插件，优先换成更轻量方案。
若必须使用该插件，检查它的高级配置，关闭不必要的实时分析、索引或监听功能。

两个容易被忽略的“放大器”

即使主因是插件，以下配置也会放大 CPU 问题：

搜索范围过大
例如把构建产物、依赖目录、日志目录也纳入全局搜索，会让插件和文件索引持续高负载。
文件监控包含大目录或软链接
软链接、缓存目录、自动生成目录容易触发大量文件事件，导致扩展反复工作。

可以在 settings.json 中适当排除目录，例如：

{
  "search.exclude": {
    "**/node_modules": true,
    "**/dist": true,
    "**/build": true
  },
  "files.watcherExclude": {
    "**/.git/objects/**": true,
    "**/node_modules/**": true,
    "**/dist/**": true
  }
}

复盘建议

如果你已经定位到问题插件，建议记录三件事：插件名称、触发场景、最终处理方式。
这样下次迁移环境或重装系统时，可以快速避开同类问题。

总结

VS Code 高 CPU 占用的排查，最有效路径是先用 Start Extension Bisect 快速定位，再结合搜索和文件监控范围做收敛。
先定位，再优化，比“盲目禁用一堆插件”更省时间，也更稳定。

如何在 VS Code 中使用 Codex（从安装到高效实战）

Fri, 20 Mar 2026 00:00:00 +0000

Codex 可以直接在 VS Code 侧边栏中协助你写代码、改 Bug、解释项目和执行命令。

1. 准备工作

开始前请确认：

VS Code 已更新到较新的稳定版本。
你可以正常访问OpenAi网站
项目代码已在本地打开（建议使用 Git 仓库）。

2. 安装扩展

打开 VS Code 的扩展市场（Extensions）。
搜索并安装：Codex - Codex - OpenAI's coding agent。
安装完成后，按提示完成登录授权。

3. 打开 Codex 侧边栏

你可以通过任一方式打开：

在编辑器右上角点击 Open Codex Sidebar。
使用命令面板（Ctrl + Shift + P）搜索 Codex 并打开。

打开后，Codex 会读取当前工作区上下文，进入可对话状态。

4. 常见使用方式

4.1 让它解释代码

示例提示词：

`1`	`请解释这个文件的核心逻辑，并指出最可能出错的 3 个地方。`

适合你刚接手旧项目时快速建立全局理解。

4.2 让它实现功能

示例提示词：

1
2

在现有 API 里新增一个 /healthz 健康检查接口，
要求返回版本号和数据库连接状态，并补上基础测试。

建议把“输入约束”和“验收标准”一起写清楚，生成结果会稳定很多。

4.3 让它修复问题

示例提示词：

1
2

这个接口在并发下偶发 500，请先定位根因，再给出最小改动修复方案，
最后列出回归测试点。

先“定位”再“修复”，能减少误改和过度重构。

5. 高质量提示词模板

你可以直接复用下面这个结构：

背景：这是一个 <技术栈> 项目，当前目标是 <目标>
约束：不改动 <模块/接口>，兼容 <版本/平台>
输出：
1) 修改文件列表
2) 关键代码说明
3) 验证步骤
4) 风险与回滚方案

这个模板对“多人协作 + 大项目”非常有帮助。

6. 常见问题

6.1 关于免费额度

在对话框输入 ‘' 然后选择状态会出现额度重置时间等相关信息

6.2 改动不符合预期

修改完成后查看审核按钮，查看修改细节，不满意选择撤销按钮，可撤销修改。在后面的步骤中可以把需求拆小，分成多个步骤分别执行。使用git等代码管理工具，保持小步提交（small commits），方便回滚。

VS Code on KnightLi的博客

VS Code 切换界面语言的方法：中文、英文和其他语言

安装对应语言包

通过命令面板切换语言

通过 argv.json 手动指定语言

常用界面语言代码

语言没有生效怎么办

参考资料

2026 年嵌入式开发环境怎么选：Keil、STM32CubeIDE、VS Code 与 AI 协作

先看几个主流选项，各自解决什么问题

Keil：生态强、上手稳，但编辑体验已经明显落后

STM32CubeIDE：对 STM32 友好，但更多是学习和快速起步工具

VS Code：严格说不是 IDE，但在 AI 时代优势越来越明显

CLion：体验不错，但在嵌入式场景里不够主流

更现实的答案：Keil 负责编译调试，VS Code 负责写代码

为什么这套组合在 AI 时代更有优势

关键补丁：用插件把 VS Code 和 Keil 工程接起来

不要忽视 C/C++ 基础插件配置

这套工作流最适合谁

1. 已经有大量 Keil 工程的人

2. 想用 AI 辅助写嵌入式代码的人

3. 想同时兼顾学习资料和真实项目的人

结语

在 VS Code 里接入 Claude：从 API 配置到网页生成

一、先把工具链接通

二、适合先从小任务开始

三、真正提效的不是一次生成，而是连续迭代

四、要学会区分“适合交给 AI 的部分”和“自己顺手改更快的部分”

五、API 配置是门槛，但不是难点

六、怎么看生成结果值不值得继续用

结语

Windows 上在 VS Code 里构建 Docker 镜像：从环境准备到一键构建

01 前置准备

02 准备 Dockerfile

03 构建镜像的三种方式

方式 A：右键 Dockerfile

方式 B：命令面板

方式 C：集成终端命令

04 常见问题快速检查

小结

使用 Agent Skills 取代 VS Code 中 Copilot 的“生成提交消息”的功能

问题与目标

替代方案：git-commit-push-zh

提交信息建议规范

常见失败场景

附录：原始 SKILL.md

如何排查由插件引起的 VS Code CPU 占用过高

先做最快的定位：Start Extension Bisect

定位后怎么处理

两个容易被忽略的“放大器”

复盘建议

总结

如何在 VS Code 中使用 Codex（从安装到高效实战）

1. 准备工作

2. 安装扩展

3. 打开 Codex 侧边栏

4. 常见使用方式

4.1 让它解释代码

4.2 让它实现功能

4.3 让它修复问题

5. 高质量提示词模板

6. 常见问题

6.1 关于免费额度

6.2 改动不符合预期

替代方案：`git-commit-push-zh`

附录：原始 `SKILL.md`