在實際開發環境中，一套系統通常不會只有一個程式專案。
隨著系統持續發展，常常會拆成：
- Web 專案
- API 專案
- Batch / Console Job
- SQL Script
- 共用 Library
- 開發文件
- OpenSpec 規格
- AI Skill
- 團隊共用 Skill
而這些專案也不一定放在同一個資料夾底下。
例如：
D:\
├─ Projects\
│ └─ WebApp\
│
├─ DatabaseScripts\
│
E:\
├─ Tools\
│ └─ BackgroundJob\
│
└─ SharedAI\
└─ TeamSkills\
對一般 IDE 而言，這不一定是問題。
但當主要開發流程逐漸改成透過 Codex 協助時，就會遇到另一個需求：
如何讓 Codex 在同一個工作範圍內，同時理解並操作這些分散在不同位置的專案？
這篇文章記錄我最後使用 Windows mklink 建立整合 Workspace 的做法。
一、需求背景
目前我的開發流程中，已經有相當大的比例透過 Codex 協助完成。
除了讓 Codex 撰寫程式之外，也會讓它處理：
- 搜尋既有程式
- 分析程式流程
- 修改多個專案
- 查看 SQL
- 追蹤 API 呼叫關係
- 執行 OpenSpec
- 使用專案 Skill
- 使用團隊共用 Skill
- 跨專案進行重構
- 分析不同 Repository 之間的相依關係
但原本的程式目錄並不是按照「給 AI 使用」的方式規劃。
多年累積下來，不同專案通常散落在不同位置。
例如：
D:\Projects\MainWeb
D:\Database\Scripts
E:\Projects\WorkerService
E:\AI\SharedSkills
而且每一個專案原本都有自己的 AI 開發規則。
例如：
D:\Projects\MainWeb
├─ AGENTS.md
├─ skills\
└─ src\
另外一個專案可能是：
E:\Projects\WorkerService
├─ AGENTS.md
├─ skills\
└─ src\
團隊另外還有一份共用 Skill：
E:\AI\SharedSkills
這就會產生一個問題。
每次 Codex 開啟不同專案時，主要能處理的還是目前這個專案範圍內的內容。
如果今天一個需求同時牽涉：
Web
↓
Service
↓
Database
↓
Background Job
就很容易變成需要在多個專案之間來回切換。
二、問題分析
真正需要解決的，其實不是「把所有 Repository 合併成一個」。
因為原本的資料夾配置通常有它存在的理由。
例如某個 Web 專案可能已經：
- 綁定 Git Repository
- 被 Visual Studio 或 VS Code 使用
- 被 CI/CD 流程使用
- 有既有 Build Script
- 有其他程式依賴固定路徑
如果只是為了 Codex，把所有專案真的搬到：
D:\CodexWorkspace
反而可能造成更多問題。
真正需要的是「邏輯上的整合」
希望最後 Codex 看到的是：
D:\CodexWorkspace
│
├─ WebApp
├─ Database
├─ WorkerService
├─ SharedSkills
└─ AGENTS.md
但是實際資料仍然維持：
D:\Projects\MainWeb
D:\Database\Scripts
E:\Projects\WorkerService
E:\AI\SharedSkills
也就是：
Codex 看起來像是在操作一個大型專案，但實際上每個 Repository 仍然放在原本的位置。
這就是 Symbolic Link / Junction 很適合處理的場景。
三、解決方式：建立 Codex Workspace
最後採用的方式，是額外建立一個專門給 Codex 使用的 Workspace。
例如：
D:\CodexWorkspace
這個資料夾本身不需要真的存放所有 Source Code。
它只是負責把其他資料夾「連接」進來。
最後可能形成：
D:\CodexWorkspace
│
├─ WebApp
├─ Database
├─ WorkerService
├─ SharedSkills
└─ AGENTS.md
實際對應關係則是：
D:\CodexWorkspace\WebApp
↓
D:\Projects\MainWeb
D:\CodexWorkspace\Database
↓
D:\Database\Scripts
D:\CodexWorkspace\WorkerService
↓
E:\Projects\WorkerService
D:\CodexWorkspace\SharedSkills
↓
E:\AI\SharedSkills
如此一來，Codex 只需要開啟：
D:\CodexWorkspace
就能從同一個專案根目錄往下存取所有相關程式。
四、Windows mklink 是什麼？
Windows 本身提供 mklink 指令，可以建立檔案或目錄的連結。
概念上可以理解成：
A 資料夾
↓
指向
↓
B 資料夾
但它和 Windows 一般的「捷徑 .lnk」不同。
一般桌面捷徑比較像：
捷徑
→ 開啟另外一個位置
對很多程式來說，它仍然只是一個捷徑檔案。
而 Junction / Symbolic Link 則直接出現在檔案系統結構裡。
因此程式存取：
D:\CodexWorkspace\Database
實際上可以讀到：
D:\Database\Scripts
裡面的內容。
五、使用 Junction 建立連結
如果目標是 Windows 本機上的資料夾，我會優先使用：
mklink /J
基本語法：
mklink /J [連結位置] [實際資料夾]
例如：
mklink /J D:\CodexWorkspace\WebApp D:\Projects\MainWeb
意思是建立：
D:\CodexWorkspace\WebApp
但實際內容來自：
D:\Projects\MainWeb
接著加入資料庫腳本：
mklink /J D:\CodexWorkspace\Database D:\Database\Scripts
加入背景服務：
mklink /J D:\CodexWorkspace\WorkerService E:\Projects\WorkerService
加入共用 Skill：
mklink /J D:\CodexWorkspace\SharedSkills E:\AI\SharedSkills
完成後：
D:\CodexWorkspace
│
├─ WebApp
├─ Database
├─ WorkerService
└─ SharedSkills
看起來就像一般資料夾結構。
六、這些檔案並沒有被複製
這一點非常重要。
假設：
D:\CodexWorkspace\WebApp
是一個 Junction，指向：
D:\Projects\MainWeb
那麼修改：
D:\CodexWorkspace\WebApp\Controllers\OrderController.cs
實際修改的就是：
D:\Projects\MainWeb\Controllers\OrderController.cs
並不存在兩份資料。
也就是不會變成：
原始檔
+
Codex 複製檔
它們實際上仍然是同一份內容。
因此：
- Git 不需要重新設定
- IDE 不需要改專案位置
- CI/CD 不需要改
- 原本 Repository 不需要搬家
- Codex 又可以從統一 Workspace 存取
這正是這種架構最大的優點。
七、實際操作時常見的錯誤
第一次使用 mklink 時，很容易直接寫成：
mklink D:\CodexWorkspace\WebApp D:\Projects\MainWeb
如果目標是「資料夾」，這樣的寫法並不適合。
建立 Directory Symbolic Link 應該使用：
mklink /D D:\CodexWorkspace\WebApp D:\Projects\MainWeb
或是建立 Junction：
mklink /J D:\CodexWorkspace\WebApp D:\Projects\MainWeb
如果只是本機資料夾整合，我會優先考慮：
mklink /J
八、「當檔案已存在時，無法建立該檔案」
另一個很常見的錯誤是：
當檔案已存在時，無法建立該檔案。
例如：
mklink /J D:\CodexWorkspace\WebApp D:\Projects\MainWeb
如果：
D:\CodexWorkspace\WebApp
原本就已經存在，mklink 就無法建立。
也就是說，不可以先手動建立：
D:\CodexWorkspace\WebApp
再執行：
mklink /J ...
因為 mklink 本身就是要建立這個目錄項目。
如果原本只是空資料夾，可以先移除：
rmdir D:\CodexWorkspace\WebApp
再重新建立：
mklink /J D:\CodexWorkspace\WebApp D:\Projects\MainWeb
九、推薦的 Workspace 結構
如果要整合很多專案，我會保留一層真正存在的 Workspace。
例如：
D:\CodexWorkspace
這個資料夾本身是真實存在的。
接著在裡面建立多個 Junction：
mklink /J D:\CodexWorkspace\WebApp D:\Projects\MainWeb
mklink /J D:\CodexWorkspace\Database D:\Database\Scripts
mklink /J D:\CodexWorkspace\WorkerService E:\Projects\WorkerService
mklink /J D:\CodexWorkspace\SharedSkills E:\AI\SharedSkills
最後形成：
D:\CodexWorkspace
│
├─ WebApp
│ ↓
│ D:\Projects\MainWeb
│
├─ Database
│ ↓
│ D:\Database\Scripts
│
├─ WorkerService
│ ↓
│ E:\Projects\WorkerService
│
└─ SharedSkills
↓
E:\AI\SharedSkills
Codex 則直接開：
D:\CodexWorkspace
這樣會比把整個 Workspace 本身直接做成一個 Junction 更清楚。
十、再加入 Workspace 層級的 AGENTS.md
做到這裡之後，其實還只是把「檔案」接在一起。
如果希望 Codex 真正理解：
這幾個資料夾其實屬於同一套系統。
還可以在 Workspace 根目錄新增：
D:\CodexWorkspace\AGENTS.md
例如：
## Application Workspace
這個 Workspace 包含多個彼此相關的 Repository。
## 專案結構
### WebApp
主要 Web Application。
路徑：
`./WebApp`
### Database
SQL Script、Stored Procedure 與資料庫相關內容。
路徑：
`./Database`
### WorkerService
背景 Job、Worker 或 Console Application。
路徑：
`./WorkerService`
### SharedSkills
團隊共用的 Codex Skill 與開發規範。
路徑：
`./SharedSkills`
### 開發規則
進行需求分析時，不要只搜尋目前修改的 Repository。
如果需求涉及：
- API
- SQL
- Batch
- Background Job
- 共用 Library
請同時確認其他相關 Repository。
修改 SQL 前，先確認呼叫該 SQL 的 Application。
修改 API 前，也要確認是否有背景 Job、其他 Service 或資料庫相依關係。
這樣 Codex 取得的不只是：
很多資料夾
而是一個具有「系統關係」的 Workspace。
十一、專案 Skill 與共用 Skill 的整合
這也是建立統一 Workspace 很實用的一個原因。
原本可能是：
WebApp
└─ skills
├─ web
└─ security
另外：
WorkerService
└─ skills
└─ background-job
團隊又有：
SharedSkills
├─ coding-standard
├─ database-standard
└─ security-standard
如果每次只開一個 Repository，Codex 能看到的知識很容易被切割。
整合 Workspace 後：
CodexWorkspace
│
├─ WebApp
│ └─ skills
│
├─ WorkerService
│ └─ skills
│
└─ SharedSkills
├─ coding-standard
├─ database-standard
└─ security-standard
就可以再透過 Workspace 的 AGENTS.md 告訴 Codex：
專案自己的 Skill 優先處理該專案特定規則。
SharedSkills 為團隊共用規範，所有 Repository 均需遵守。
這比每個 Repository 各自複製一份共用 Skill 更容易維護。
因為共用 Skill 只需要維護一份。
十二、最後形成的 Codex 開發架構
整體概念最後會變成：
Codex
│
▼
D:\CodexWorkspace
│
┌─────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
WebApp Database WorkerService
│ │ │
▼ ▼ ▼
原始專案位置 原始 SQL 位置 原始服務位置
│
▼
SharedSkills
│
▼
共用 Skill 位置
Codex 的視角是：
一個 Workspace
但實際上的程式仍然是：
多個獨立 Repository
+
多個不同實體路徑
+
獨立 Git
+
獨立 Build / Deploy
這兩件事情並不衝突。
十三、這個方式真正解決的是 AI 開發的 Context 問題
一開始看起來，這只是一個 Windows 資料夾技巧。
但實際上解決的問題更接近：
AI 能不能看到完整的系統上下文。
以前 Codex 如果只開：
WebApp
它看到的主要就是：
Web 專案
如果某個 Bug 真正原因在：
Stored Procedure
或者：
Background Job
Codex 就比較難直接沿著整個系統追下去。
現在則可以變成：
CodexWorkspace
│
├─ WebApp
├─ Database
├─ WorkerService
├─ Docs
├─ OpenSpec
└─ SharedSkills
因此可以直接要求：
分析這個功能流程。
從 Controller 開始追蹤 Service、Database，
並確認 Background Job 是否有使用相同資料表。
先分析完整影響範圍，再提出修改方案。
這時 Codex 才真正有條件進行「系統層級」的分析，而不是只做單一 Repository 裡面的程式碼生成。
十四、結論
如果所有程式本來就在：
D:\Projects
├─ ProjectA
├─ ProjectB
└─ ProjectC
那直接把：
D:\Projects
當成 Workspace 就可以。
但真實世界的專案通常沒那麼整齊。
更常見的是：
D:\Projects\WebApp
D:\Database\Scripts
E:\Services\Worker
E:\AI\SharedSkills
這時候沒有必要為了 Codex：
- 搬 Repository
- 改 CI/CD
- 改 IDE 設定
- 改 Git
- 複製程式碼
- 複製團隊 Skill
比較乾淨的方法，是另外建立一個：
CodexWorkspace
再利用 Windows：
mklink /J
將原本散落在不同位置的專案掛進來。
最後形成：
實體架構：
多 Repo、多路徑、各自獨立
↓
Codex 視角：
一個統一 Workspace
這樣既保留原本成熟的開發與部署環境，又能讓 Codex 跨 Repository 搜尋、分析、修改與理解整個系統。
對開始大量使用 AI Agent 進行開發的團隊而言，這類 Workspace 的整理其實很重要。
因為 AI 能不能寫程式，只是第一層。
更重要的是：
AI 到底能看到多少完整的系統 Context。
當 Web、Database、Background Job、文件、規格與 Skill 都能在同一個 Workspace 被找到之後，Codex 才真正從「單一程式碼助手」，開始變成可以理解整套系統的開發工具。
