Day 1：為什麼老手要用 VS Code ＋ Claude，它多了什麼？以及 Open Folder 與 Workspace 的真正差別
Vibe Coding 日誌 Day 1——把 AI 從「會講」變成「會做」，再把「一顆資料夾」變成「一張工作台」
Vibe Coding 日誌 Day 1。今天不寫功能，寫環境——因為環境決定 AI 能幫你做到哪一層。
Vibe Coding 日誌 Day 1。今天不寫功能，寫環境——因為環境決定 AI 能幫你做到哪一層。
兩個問題其實是同一個問題的兩個尺度： VS Code ＋ Claude vs 純 Claude → AI 能不能碰到你的「真實檔案」 Open Folder vs Workspace → AI 一次能碰到「幾顆 repo」 一、純 Claude 的天花板：它看不到你的硬碟
在聊天視窗裡用 AI 寫程式，流程長這樣：
每一個箭頭都是你在當人肉 USB。而且這條鏈有三個結構性漏洞： 你只貼了你以為相關的部分。真正的 bug 常常在你沒貼的那個檔案裡。 AI 的答案沒有被驗證過。它沒跑過、沒看過錯誤、沒看過型別檢查，只是「看起來對」。 每開一個新對話，你的專案規則就歸零。「我們的部署要跑哪個指令」「這個資料夾不能碰」——每次重講。
VS Code ＋ Claude 補的就是這三件事。 二、VS Code ＋ Claude 實際多出來的七件事 它自己讀檔，所以不會「漏看」
不用貼。你說「訂餐送出會逾時，查一下」，它自己去搜、自己開檔、自己往上追呼叫端。
差別不在省了複製貼上，在於它讀得到你沒想到要貼的那個檔。實際踩過的例子：訂餐送出交易逾時，症狀在送出的 API，根因在一段跟送出無關的迴圈查詢——純聊天模式下，你不會想到要貼那段。 改動是 diff，不是「整段貼回去」
AI 的修改直接以編輯器的 diff 呈現，一段一段看、一段一段收。
這個差別在大檔案特別致命：聊天視窗給你「完整檔案」時，你很難確認它有沒有在重寫的過程中默默弄丟一個你上週才加的欄位。diff 會把那一行標成刪除，你一眼看得到。 反白 = 上下文
在編輯器裡選一段程式碼，直接問「這裡為什麼慢」。不用說「在 XXX.tsx 大概第 300 行那個 useEffect」——它知道你指的是哪個檔、哪幾行。 它能跑，所以會形成閉環
這個迴圈 AI 自己走完，你只驗收結果。純聊天模式的迴圈永遠要繞經你的鍵盤，所以實務上你只會走一圈就放棄。 專案規則長在 repo 裡，每次自動載入
這是最被低估的一項。在 repo 根目錄放一份 CLAUDE.md，寫下這個專案的血淚知識： 這個產品的前端不能用 git push 部署，要跑某支腳本 那個 deploy 指令會回報「成功」但線上一個位元組都讀不到 提到時間之前先跑 date，不要猜
這些是查程式碼查不出來的知識，只存在於「上次踩過」。寫進去之後，每一個新對話都自帶這些規則。純聊天視窗做不到——它每次都是新的實習生。
再往上還有兩層：Skill（把重複的 SOP 包成 /ship、/onboard 這種指令）和 Hook（例如每次開新對話自動提醒「你現在在共用主分支，要改程式先開 worktree」）。 檔案引用可以點
回覆裡的 apps/enterprise-admin/src/App.tsx:42 是連結，點下去直接跳到那一行。討論不會停在「你說的是哪個檔」。 Git 在同一個畫面
分支、commit、worktree、看 diff，跟寫程式在同一個視窗。AI 提議的改動、你的 review、最後的 commit 是連續動作。 ⚠️ 代價：它是真的會動你的硬碟
這不是沙盒。AI 執行的刪除、送出的 API、寫進去的資料庫，全部是真的。
所以本機開發環境要先想清楚一件事：你連的是正式資料庫還是本機資料庫？如果是正式的，那在本機按下「刪除」，客戶那邊就真的少一筆。
我的做法是在畫面上放一個常駐角標——紅色代表正在打正式後端，綠色代表本機——而且只在開發模式出現，正式版本會被打包工具整段移除。
便利性和破壞力是同一件事的兩面。 這是 VS Code ＋ Claude 唯一真正的成本。 三、Open Folder vs Workspace Open Folder ＝ 一顆根目錄
File → Open Folder，選一個資料夾。這個資料夾就是你的全世界： 全域搜尋只搜這一顆 Git 面板只管這一顆 AI 的工作範圍也只有這一顆
單一 repo 的日常開發，這就夠了，不要過度設計。 Workspace ＝ 一份設定檔，裡面掛好幾顆根目錄
.code-workspace 就是一個 JSON：
存起來，下次雙擊這個檔，四顆 repo 同時在側邊欄展開。 差別具體長什麼樣
Open Folder Workspace --- --- --- 搜尋 只搜一顆 ⇧⌘F 一次掃過所有 repo Git 一個 repo 每顆 repo 各自一個區塊，各自 commit 設定 跟著使用者或該 repo 只在這個 workspace 生效，不汙染單開時 AI 工作範圍 一顆 多顆——它能同時讀 A repo 的規格、改 B repo 的程式 索引成本 低 每多一顆就多一份索引，搜尋變慢
第四列是真正的分水嶺。舉個實際場景：某個功能的規格文件寫在 A repo，實作在 B repo（因為那個產品已經切出去獨立了）。Open Folder 模式下，AI 只看得到其中一半，你得自己搬運。Workspace 模式下它兩邊都在手上。 什麼時候值得開 Workspace
值得： 一件事要同時動到兩顆以上的 repo（共用的 util、同一套 SOP、規格與實作分家） 你要把某個設定綁在「這組專案」上，而不是綁在全域
不值得： 只是想快速切換專案——用 ⌃R（最近開啟）就好 把全部十幾顆 repo 都掛上去「以備不時之需」——搜尋結果會變成雜訊，索引也慢
判準：這些 repo 會不會在同一件工作裡被一起改？ 會 → Workspace；不會 → 分開開。 四、三個真的會踩到的 Workspace 陷阱 陷阱 1：把「自己 ＋ 父目錄」一起掛上（重複出現）
看起來很聰明——「我要目前的 repo，順便也要看得到隔壁」。實際結果是：同一份檔案在檔案樹裡出現兩次，全域搜尋每一筆結果都重複，AI 也可能拿到指向同一個檔的兩條不同路徑。
正確做法：平列出兄弟目錄，不要掛父層。
陷阱 2：worktree 目錄一起掛進來
如果你像我一樣，多條開發線各自開 git worktree 放在 /Projects/<repo>-worktrees/ 底下——不要把它們加進 Workspace。每一份 worktree 都是完整的一份原始碼，搜一個函式名會跳出 N 份幾乎一樣的結果，你會分不出哪一份才是你要改的。
要加的話，至少在 workspace 的 settings 裡把它們排除在搜尋之外。 陷阱 3：兩份 .code-workspace 並存
一份放在 repo 裡面、一份放在上層目錄，兩份都能開、內容不一樣——過幾天你就不知道自己現在開的是哪一份。
選一份，刪掉另一份。 我的建議：放在上層（/Projects/），用相對路徑列出兄弟 repo。理由是「哪幾顆 repo 要一起開」是你這台電腦的事，不是這個 repo 的事，不該進版控去影響其他人。 順帶一提，這三個陷阱我今天全中——我的 workspace 檔正好就是「自己 ＋ 父目錄」，而且同時存在兩份。這篇是現場除錯記錄，不是事後整理的教學。 收束
尺度 問題 答案 --- --- --- AI 的手 它碰得到真實檔案嗎？ VS Code ＋ Claude：能讀、能改、能跑、能記住專案規則 AI 的視野 它一次看得到幾顆 repo？ 一顆 → Open Folder；會一起改的多顆 → Workspace 代價 它動的是真的東西 分清楚本機／正式，在畫面上做出可視的區隔
Day 1 的結論其實只有一句：先把桌面鋪好，AI 才有東西可以動手。 本篇由 claude-code（claude-opus-5） 於開發過程中產生。 repo：makeclass 標籤：claude-code vscode workspace monorepo workflow