VS Code 把資料夾變工作區

我拆 VS Code 的 workspace、Command Palette、terminal 和 extensions，整理成一套可直接複製的工作區設定。

我用 Visual Studio Code 很久了，老實說我一直覺得很多人把它當成「比較會彩色的編輯器」，這用法真的很浪費。問題不是功能少，問題是大家常把它裝成一個雜物抽屜：幾個 extension、朋友推薦的主題、幾個快捷鍵，然後開始抱怨它很忙，但沒有真的幫到你。

我後來才想通，VS Code 比較像是在塑造一個 workspace，不只是打開檔案而已。當我不再期待選單幫我解決一切，整個工具就安靜多了。我可以直接開資料夾、把噪音壓低、快速跳 command，讓 terminal 和 extension 補上缺口。以前我根本像在自己編輯器裡當觀光客，點來點去，慢又煩，完全沒必要。

這篇不是在講官方宣傳，我是把原始材料拆開，然後整理成一套我真的會交給同事的 setup。第一個觸發點是 Visual Studio Code 的 Wikipedia 條目，它把 workspace、command palette、terminal、extensibility、remote development 這些核心概念都擺在一起。再加上 Microsoft 自己的文件和 repo，我才把這套方法論補完整。

VS Code 不是專案系統，這差很多

Instead of a project system, VS Code allows users to open one or more directories, which can then be saved in workspaces for future reuse.

翻譯一下就是：VS Code 要你先想資料夾，不是先想某個重型 IDE 的 project 檔。這看起來只是名詞不同，但你如果同時在處理 monorepo、後端服務、文件資料夾，就會知道差很多。以前我用某些工具時，總覺得是我得把現實「匯入」編輯器；VS Code 比較像是直接說，你把目錄給我，我來看上下文。

我以前很愛從零散檔案開起，結果搜尋、Git、language features 看起來都半殘。當然會半殘，因為 editor 根本不知道你在什麼脈絡裡。後來我固定只開 repo root，真的需要多資料夾再存 workspace，整個就沒那麼煩。

實操寫法很簡單：

• 永遠開 repo root，不要只開單一檔案。
• 如果你常跨多個資料夾工作，就存成 workspace。
• 把產物、cache、generated files 從 tree 裡排掉。
• 一個 workspace 對應一個任務，不要把所有 repo 塞進同一個視窗。

Microsoft 在 VS Code Workspaces guide 把這件事講得很清楚。我的版本更直白：先 folder，後 workspace，project file 不是重點，除非工具硬要你用。

Command Palette 才是主畫面

Many Visual Studio Code features are not exposed through menus or the user interface but can be accessed through the Command Palette.

這句其實把整個 UI 思路講完了。選單不是不能用，只是 VS Code 真正好用的地方，是你把 Command Palette 當主入口。不要先找圖示，不要先翻 menu，先打 command 名稱，這比較像在操作工具，而不是在逛介面。

白話一點，很多功能都藏起來了：切 terminal、換語言模式、格式化文件、開設定、跑 task、切主題。你如果每次都從滑鼠開始，當然會覺得它很多層；但你一旦知道命令名稱，速度差很多。

我看過團隊把編輯器用得很分裂：有人只會點設定，有人背快捷鍵，有人裝一堆 extension 補自己不熟的功能。結果大家看起來都很忙，效率卻不一致。Command Palette 的價值就是把入口統一，讓你不用記一堆 UI 路徑。

實操寫法：

• 先記住你作業系統上的 palette shortcut。
• 用命令名稱找功能，不要用選單掃描。
• 把每天會用的指令練成肌肉記憶。
• 拿它來學 editor，不只是拿來做已知動作。

Microsoft 的 Command Palette 文件 很值得對照著看。這裡我講得更直白：如果你還在靠選單找功能，那你其實只用了 VS Code 的半套。

內建 terminal 讓工作流接回來

Visual Studio Code provides a fully featured integrated terminal that opens at the root of the current workspace.

這就是我覺得 VS Code 真正像工作台的地方。terminal 直接放在編輯器裡，我不用為了跑測試、啟 server、看 log 再切一個視窗。檔案和命令放在同一個 workspace，腦袋比較不會被切碎。

這句話的重點不是「有 terminal」，而是「它知道你在哪」。terminal 會從 workspace root 開起，這種小事其實很救命，因為很多 shell 問題根本不是命令錯，是你在錯的路徑下執行，然後花兩分鐘才發現自己 cd 錯了。

我在 container 專案裡特別有感。只要 terminal 跟 code 沒對齊，你就會一直手動 cd、一直懷疑 script、一直浪費注意力。VS Code 的 integrated terminal，加上 shell integration，至少把這種低級摩擦壓下來。

實操寫法：

• 把 integrated terminal 當預設 shell。
• 同時開 app、test、watcher 三個 terminal 沒問題。
• 把 terminal 改名，不要靠猜。
• 需要並排看輸出時就 split panes。

官方文件可以看 Integrated Terminal guide，如果你想把 shell 互動做得更順，再看 shell integration docs。這兩頁比很多教學文更有用。

Extensions 不是裝飾，是缺的器官

Users may install extensions from the VS Code Marketplace to add language support, editor themes, debuggers, and additional utilities.

翻譯一下就是：VS Code 故意不把所有東西內建好。這不是缺點，這是設計。它先給你一個夠穩的 base editor，再讓 extension 去補你真正需要的語言支援、除錯、主題、工具。

我以前也犯過錯，把 extension 當裝潢在裝。結果就是 formatter 打架、language server 重複、啟動速度像在受刑。比較好的做法是照功能分類：一個 formatter、一條 lint 路徑、一條 debugger 路徑、一個主題，然後停手。

這裡還有一個很重要的差別：有些 extension 只是方便，有些 extension 是核心語言能力。Wikipedia 裡提到 Language Server Protocol，這才是重點。它讓語言支援、靜態分析、code actions 這些能力，不用每個工具自己重造一套 editor 整合。

實操寫法：

• 只裝真的支援你 stack 的 extension。
• 優先選廣泛使用的語言 extension。
• 避免重疊 formatter，不然 save 時很容易怪怪的。
• 每隔幾個月清一次 extension，刪掉你早就忘了裝什麼的東西。

你可以從 VS Code Marketplace 找生態，microsoft/vscode repo 則能看出這個 editor 到底有多依賴 extension hook。這不是裝飾品，是它的肌肉。

Debugging 之所以順，是因為它沒離開 code

VS Code features a built-in debugger designed to enhance the development process.

這句話聽起來很普通，但你如果用過那種除錯像外掛的工具，就知道差在哪。VS Code 的 debugger 不是額外開一個宇宙，而是直接跟編輯、執行、檢視綁在一起。你設 breakpoint、step through、看 variable、開 Debug Console，都還在同一個視窗裡。

這代表什麼？代表除錯本來就很吃上下文，你不需要再多一層切換成本。Wikipedia 也提到 Node.js support、conditional breakpoints、Debug Console 這些細節，這些才是日常會碰到的東西。不是炫技，是少猜很多。

我有不少次以為是邏輯寫錯，最後發現是 input shape 跟我想的不一樣。能直接在 source 旁邊看 live values，真的省掉一堆瞎猜。更別說 pair debugging 的時候，證據直接攤在那裡，不用一直口頭描述你覺得哪裡怪。

實操寫法：

• 先設 breakpoint，不要等 bug 變大才找。
• loop 或 callback 很吵時，用 conditional breakpoint。
• 常 debug 的 app 先存 launch config。
• 用 Debug Console 試 expression，不要為了印值一直改 code。

可以配著看 debugging docs。如果你主要寫 JavaScript 或 TypeScript，通常先把內建流程吃熟，就夠你少走很多冤枉路。

Remote development 是在承認機器不是重點

VS Code supports remote development through extensions such as Remote–SSH, Remote–Containers, and Remote–WSL.

這是我很喜歡 VS Code 的地方，因為它很誠實：程式碼不一定要跟 UI 跑在同一台機器上。這對容器、遠端主機、WSL 工作流都很重要。你不是非得把所有東西硬塞進本機，才算在開發。

白話就是 editor 變成 client，真正執行環境可以在別處。這比很多工具硬要你本機全包合理太多，尤其當你的 app 依賴一堆服務、Linux 環境，或本機設定本來就很亂的時候。

我之前碰過一個專案，本機依賴亂到不行。後來改成 remote setup，整個 workflow 才穩下來。直接進 container、attach 到 server、在那邊編輯和執行，少掉的不是一點點時間，是一堆無謂的環境爭執。

實操寫法：

• 環境比筆電重，就用 Remote Development。
• 需要可重現依賴時，優先用 containers。
• Windows 上想要 Linux-like workflow，就用 WSL。
• remote config 盡量放 repo，讓團隊能共用。

另外，vscode.dev 也很值得知道。它不是拿來取代全部工作，但臨時改檔、看遠端 repo、處理簡單任務時，真的方便。

Insiders 是給想驗證的人，不是給每天賭運氣的人

VS Code Insiders is a nightly build version of this code editor.

我喜歡這個設計，因為它把「日常穩定」和「願意承擔風險」切開了。這比把實驗性功能硬塞進你每天賺錢的環境裡好多了，然後出事再怪工具，這種事我看太多。

白話一點，Insiders 是夜間版，讓你可以提早看到新功能、修補、預覽行為，而且可以跟穩定版並存。這點很實際，因為你要測 extension 相容性、看 editor 行為變化，總不能每次都拿主力環境去賭。

我以前在團隊裡用 preview build，目的不是追新，而是先確認某個變動會不會害我們的 extension 或工作流出問題。這樣做的價值很單純：先知道，總比正式發生後才補救好。

實操寫法：

• 日常工作用 Stable。
• 要測新行為才開 Insiders。
• 先確認你的 extension 在兩邊都正常。
• 不要讓不穩定版本變成你唯一的 editor。

Microsoft 在 VS Code FAQ 有把 Stable 和 Insiders 的差異講清楚。我只補一句：別把自己的主力工作流綁在 beta 行為上，除非你很愛被驚喜打臉。

我最後留下的不是設定，是規矩

拆到最後，我發現 VS Code 真正有價值的地方，不是它能不能客製，而是它讓我把工作流程收斂成幾條規矩。開對資料夾、用 Command Palette、把 terminal 留在 workspace 裡、extension 只留必要的、debug 早點做、環境亂就 remote、要測試再碰 Insiders。這些事情看起來很普通，但普通才是真的省心。

我現在不太把 VS Code 當成「編輯器」，我把它當成一個工作區容器。你一旦這樣想，很多以前覺得「功能很多所以很亂」的感覺，會變成「我只是還沒把規矩訂好」。

如果你也覺得自己的 VS Code 很忙，但不夠好用，我建議不要先去找更多 extension。先把工作區整理好，真的差很多。

可抄的模板

# VS Code 工作區模板：把資料夾變成可工作的 workspace

## 1) 開啟方式
- 打開 repo root，不要只開單一檔案。
- 多資料夾專案就存成 `.code-workspace`。
- 把 build、cache、generated files 排除掉。

## 2) Command Palette 當主入口
- 用 Command Palette 做：開 terminal、改 language mode、format document、開 settings、跑 task。
- 先記住快捷鍵，再談效率。
- 先搜 command 名稱，不要先翻選單。

## 3) Terminal 預設就在 workspace 裡
- 預設使用 integrated terminal。
- 開三個常用終端：app、test、watcher。
- 把 terminal 改名，避免猜測。
- 需要時用 split panes。

## 4) Extensions 只留必要的
- 一個 formatter。
- 一條 lint 路徑。
- 一條 debugger 路徑。
- 一個主題。
- 只裝你 stack 真正需要的語言支援。

## 5) Debugging 早一點開始
- 先建 launch config。
- 先設 breakpoint，再追 bug。
- noisy loop 用 conditional breakpoint。
- 用 Debug Console 看值，不要一直加暫時性印字。

## 6) 環境複雜就用 remote development
- Remote-SSH：連遠端主機。
- Remote-Containers：跑在容器裡。
- Remote-WSL：Windows 上用 Linux-like workflow。
- remote config 盡量放進 repo。

## 7) Insiders 和 Stable 分開
- Stable 給日常工作。
- Insiders 只拿來測新行為。
- 不要讓 beta 版成為唯一工作環境。

## 最小 extension 清單
- 主要語言支援
- Formatter
- Linter
- 必要時的 Git helper
- Remote development extension（如果你常用容器或 SSH）

## 我的規矩
- 每個 extension 都要能每週省時間。
- 每個每天用的 shortcut 都值得背起來。
- 每個靠滑鼠點很多次的流程，都應該搬進 Command Palette。

這版我會直接丟給同事用，目的不是把 VS Code 變得很炫，而是讓它不要再像雜物抽屜。它本來就該是工作區，不是裝飾品。

原始來源：Visual Studio Code - Wikipedia。這篇的結構、拆解方式和工作流建議是我自己整理的；概念錨點來自原始條目，補充連結則來自 Microsoft 文件、Marketplace、repo 與相關工具頁面。