VS Code on KnightLi的博客

VS Code 切換介面語言的方法：中文、英文和其他語言

Fri, 08 May 2026 13:18:57 +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 後端。
建置失敗顯示找不到檔案：確認執行目錄是專案根目錄，且檔案在建置上下文內。
VS Code 看不到 Docker 資源：重啟 VS Code，並確認 Docker CLI 可用（docker version）。

小結

在 Windows 上用 VS Code 建置 Docker 映像並不困難。先完成 Docker Desktop 與擴充套件安裝，再用命令面板產生 Dockerfile，最後透過 UI 或 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 佔用與卡頓是否重現，並依提示選擇 Good now 或 This is bad。
重複幾輪後，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`