讓網頁版 ChatGPT 調度本地專案的 DevSpace
上次介紹過一個做法：在 Codex 裡用內建瀏覽器打開 ChatGPT，讓 Codex 把任務整理好，再叫 ChatGPT 幫忙研究、寫 code 或產 patch。
那條路線的感覺是：本地的 coding agent 主導流程，網頁版 ChatGPT 比較像被叫來協作的外部工程師。
今天看到另一個方向，剛好反過來。
不是從 Codex 去叫 ChatGPT。
而是讓網頁版 ChatGPT 有能力調度你的本地專案。
這個工具叫 DevSpace。
DevSpace 在做什麼
我一開始看到它的時候，還以為裡面有什麼黑魔法。
例如可以讓使用者偷偷用到 ChatGPT 網頁版的額度，或是繞過某些 coding agent 的限制。
但看完 README 之後，發現它其實沒有那麼神祕。
說穿了，DevSpace 做的事情是：把你的本地專案變成一個 ChatGPT 可以連上的 connector。
更白話一點：它把你的本機變成一個 MCP server。
ChatGPT 原本在網頁上只能聊天。就算你貼 code 給它，它也只是看你貼進去的內容，不能真的去你的專案裡找檔案、跑測試、查 git 狀態。
DevSpace 補的就是這個缺口。
它是一個 self-hosted MCP server / CLI。你在本機啟動它，指定哪些 local roots 可以被存取，然後讓支援 MCP 的聊天端連進來。
預設的本機 MCP endpoint 是：
http://127.0.0.1:7676/mcp
基本安裝方式是：
npm install -g @waishnav/devspace
devspace init
devspace serve
也可以不用全域安裝：
npx @waishnav/devspace init
npx @waishnav/devspace serve
所以它不是「ChatGPT 自己突然變成本地 IDE」。
比較準確的說法是：你在本地開了一個受控的 MCP server，讓網頁版 ChatGPT 可以透過 connector 的形式調度它。
這跟上次那套流程剛好相反
上次那套 Codex × ChatGPT Pro 的流程，是 Codex 主導。
Codex 讀 repo、整理需求、打包檔案、交給 ChatGPT Pro，等 ChatGPT 回 patch 之後，再由 Codex 回本地套用、跑測試、做驗收。
那個流程的核心是：本地 agent 負責管理上下文和驗證，ChatGPT Pro 負責研究與產出。
DevSpace 的方向比較像反過來。
它讓 ChatGPT 從網頁端往本地伸手。
如果設定得起來，ChatGPT 就不一定只能等你貼 code 給它，而是可以自己去核准的 workspace 裡讀檔、搜尋、跑 command，甚至操作 git worktree。
也就是說，ChatGPT 比較有機會變成「會碰到專案環境的 coding agent」。
這是我覺得它值得看的地方。
但安全邊界要先想清楚
這種東西不能只看「哇，可以讓 ChatGPT 操作本地專案」。
因為另一面就是：你把本地檔案讀寫和 shell 權限，透過 MCP 開給聊天端使用。
這件事的風險不小。
DevSpace 有 owner password approval flow，也要求你選擇允許的 local roots。
但實際安全邊界還是要自己負責。
我會至少先限制幾件事：
- 只開 sandbox repo，不開真專案
- 不讓它讀
.env、token、cookie、private key - 不讓它 commit、push 或碰 production 資料
- 每次讓它跑 shell command 前，都要看清楚它要做什麼
你可以把它想成：你不是裝了一個聊天外掛，而是在本機旁邊多開了一個工程師座位。
你不會把所有公司 repo、production secret、database credential 全部交給一個剛來的外包工程師。
那也不應該這樣交給 Agent。
我目前還沒玩很深
因為我現在主要還是習慣用 CLI。
Claude Code、Codex 這種從終端機出發的工作流，對我來說比較直接：看 git diff、跑測試、改檔案、驗收，都在同一個地方。
所以 DevSpace 這條路，我現在還只是把它定位成一個值得測的方向。
它真正有趣的問題不是「它能不能讓 ChatGPT 寫 code」。
而是：如果網頁版 ChatGPT 可以安全地碰到本地專案，它適合扮演哪個角色？
是主寫 code 的 agent？
是讀 repo、整理資訊、產 patch 的 assistant？
還是只能放在 sandbox 裡做實驗？
這些都還要實測。
我會怎麼測
如果要試，我不會一開始就丟真專案。
我會先開一個小 repo，放一個有測試的簡單任務，例如：
- 新增一個 CLI flag
- 補一個單元測試
- 跑一次 typecheck
- 故意留一個 failing test，看它能不能根據 log 修回來
然後觀察四件事：
- 它有沒有遵守指定的 workspace 邊界
- 它會不會真的跑測試
- 它遇到錯誤時，能不能回到正確檔案修
- 人需要介入幾次
這比單純問「ChatGPT coding 強不強」更有意義。
因為 coding agent 的重點，從來不只是會不會產 code。
而是它能不能在一個受控環境裡，把需求、修改、測試、失敗修正這幾件事接起來。
一句話總結
DevSpace 不是讓你偷用什麼神祕額度的黑魔法。
它比較像是把你的本地專案變成 MCP server，讓網頁版 ChatGPT 可以透過 connector 形式調度。
我現在還沒玩很深，因為我仍然比較習慣 CLI 工作流。
但這個方向值得留意：未來的 AI coding，不一定都是「本地 agent 去叫網頁版模型」，也可能反過來，讓網頁版 ChatGPT 直接接進受控的本地 workspace。
最近開始做免費的一對一諮詢，幫你把 AI 接進自己的工作流——有需要的話可以約：https://www.dawsonwang.com/
DevSpace GitHub：https://github.com/Waishnav/devspace Codex × ChatGPT Pro 雙 Agent 工作流：https://ai-coding.wiselychen.com/codex-chatgpt-pro-dual-agent-workflow/