随着 MCP（Model Context Protocol）的普及，我们已经可以不再局限于“把代码复制给 ChatGPT，再把修改后的代码复制回来”这种传统协作方式。
通过 DevSpace，可以让 ChatGPT 在授权范围内直接读取本地项目、搜索源码、修改文件以及执行构建和测试命令；通过 Remote Desktop Commander，则可以进一步让 ChatGPT 操作本机文件系统、终端和运行中的进程。
对于没有公网 IP 的家庭网络或公司内网，还可以使用 花生壳内网穿透，把本机运行的 DevSpace MCP 服务安全地暴露成一个公网 HTTPS 地址。
最终可以形成这样一套开发环境：
Internet
│
│ HTTPS
▼
┌──────────────┐
│ ChatGPT │
└──────┬───────┘
│
MCP / HTTPS
│
▼
┌──────────────────┐
│ 花生壳内网穿透 │
└────────┬─────────┘
│
│ HTTP
▼
127.0.0.1:7676
│
┌──────▼──────┐
│ DevSpace │
│ MCP Server │
└──────┬──────┘
│
▼
D:\release\mall
│
┌───────────┴──────────┐
│ │
Git Maven/npm
│ │
└──────── 本地开发环境 ─┘
另外一条链路则是：
ChatGPT
│
│ Remote MCP
▼
Remote Desktop Commander
│
│ Secure Device Connection
▼
Windows 本地电脑
│
├── 文件系统
├── PowerShell / CMD
├── Git Bash
├── Git
├── Maven
├── Node.js
└── Docker
二者结合之后，ChatGPT 就不只是“代码问答助手”，而更接近一个可以直接参与本地开发工作的 AI Agent。
一、什么是 DevSpace
本文使用的是 npm 包：
@waishnav/devspace
DevSpace 的定位非常直接：
将类似 Codex 的本地编码工作流带到 ChatGPT。
它本质上是一个运行在自己电脑上的 MCP Server。
ChatGPT 连接 DevSpace 后，可以在你明确授权的目录中执行代码开发相关操作，例如读取源码、搜索代码、编辑文件、执行 Git、运行 Maven/npm 测试以及检查项目目录结构。
DevSpace 官方当前要求：
Node.js >= 22.19
Node.js < 27
Windows 环境建议同时安装 Git Bash 或 WSL，单纯依赖 PowerShell/CMD 的兼容性不如 Bash 环境完整。
我个人更推荐：
Windows 11
Node.js 24.x
npm
Git for Windows
Git Bash
DevSpace
花生壳
这样可以同时兼容 DevSpace 和 Remote Desktop Commander。
二、安装 Node.js
首先检查本机版本：
node -v
npm -v
例如：
v24.21.0
11.x.x
对于 DevSpace，不建议继续使用 Node.js 20。
虽然很多 Node 项目在 Node 20 上仍然可以正常运行，但 DevSpace 当前明确要求 Node >=22.19。另外 Remote Desktop Commander Remote 模式在部分 Node 20 环境下也可能碰到：
Node.js 20 detected without native WebSocket support
因此比较省事的方案是直接使用：
Node.js 22 LTS
或者：
Node.js 24
三、安装 DevSpace
使用 npm 全局安装：
npm install -g @waishnav/devspace
安装完成后检查：
devspace --help
如果不想全局安装，也可以直接使用 npx：
npx @waishnav/devspace init
DevSpace 官方同时支持全局 CLI 与 npx 两种运行方式。
四、初始化 DevSpace
执行：
devspace init
或者：
npx @waishnav/devspace init
初始化过程中，DevSpace 会询问使用方式。
如果目标是让 ChatGPT 操作本地项目，就需要选择 ChatGPT 相关模式。
其中一个非常重要的配置是：
Allowed Project Roots
也就是允许 ChatGPT 访问哪些目录。
例如我的项目位于：
D:\release\mall
那么可以把：
D:\release
配置为允许访问的 Root。
这样以后不仅可以打开：
D:\release\mall
也可以打开：
D:\release\payment-demo
D:\release\ai-vocabulary
但从安全角度来看，不建议直接把：
C:\
D:\
整个磁盘加入允许范围。
DevSpace 的安全模型本质上是：
ChatGPT
↓
只能操作 Allowed Roots
↓
具体 Workspace
这样可以把 AI 的操作范围限制在开发目录内。
五、DevSpace 默认端口
DevSpace 默认 MCP 服务通常运行在：
http://127.0.0.1:7676/mcp
初始化完成之后启动：
devspace serve
或者：
npx @waishnav/devspace serve
官方文档给出的默认本地端点同样是：
http://127.0.0.1:7676/mcp
启动后可以先在本机验证 7676：
netstat -ano | findstr 7676
如果看到类似：
TCP 127.0.0.1:7676 0.0.0.0:0 LISTENING
说明 DevSpace 已经正常监听。
六、为什么还需要花生壳
这里有一个非常关键的问题。
DevSpace 在本地的地址是：
http://127.0.0.1:7676/mcp
但：
127.0.0.1
只有你自己的电脑可以访问。
ChatGPT 运行在云端，不可能直接访问：
127.0.0.1:7676
因此需要建立：
公网 HTTPS
↓
内网穿透
↓
127.0.0.1:7676
DevSpace 本身并不会帮你建立公网隧道。官方文档建议使用 Cloudflare Tunnel、ngrok、Pinggy、Tailscale Funnel 或其他 HTTPS Reverse Proxy。
在国内网络环境下，我们也可以使用：
花生壳
完成这一层转换。
七、安装花生壳
安装花生壳 Windows 客户端之后登录贝锐账号。
进入：
花生壳
↓
内网穿透
↓
添加映射
花生壳官方 Windows 客户端支持直接创建内网映射，并生成公网访问地址。
这里不要简单配置成普通 TCP 转发。
对于 DevSpace，我们希望最终提供：
https://xxxxx/mcp
因此推荐使用：
HTTPS 映射
花生壳支持将公网 HTTPS 443 请求转发给内网 HTTP 服务，本地 DevSpace 本身不需要额外部署 SSL 证书。
八、配置 DevSpace 的花生壳映射
例如 DevSpace：
127.0.0.1:7676
那么花生壳可以配置为：
| 配置 | 内容 |
|---|---|
| 应用名称 | DevSpace-MCP |
| 映射协议 | HTTPS |
| 内网主机 | 127.0.0.1 |
| 内网端口 | 7676 |
| 外网协议 | HTTPS |
| 外网端口 | 443 |
| 外网域名 | 花生壳分配或自己的域名 |
例如最终得到：
https://12xxxxxx.vicp.fun
那么这里有一个非常容易搞错的地方。
在执行：
devspace init
配置 Public Base URL 时填写：
https://12xxxxxx.vicp.fun
不要加：
/mcp
而真正配置给 ChatGPT 的 MCP Endpoint 才是：
https://12xxxxxx.vicp.fun/mcp
也就是：
DevSpace publicBaseUrl
https://12xxxxxx.vicp.fun
对应：
ChatGPT MCP Endpoint
https://12xxxxxx.vicp.fun/mcp
DevSpace 官方特别强调 Public Base URL 使用公网 origin，而 MCP 客户端连接时再追加 /mcp。
九、修改 DevSpace 公网地址
如果初始化之后更换了花生壳域名，不需要重新安装 DevSpace。
可以执行：
npx @waishnav/devspace config set publicBaseUrl https://12xxxxxx.vicp.fun
然后重新启动：
npx @waishnav/devspace serve
也可以直接：
devspace serve
DevSpace 会使用新的公网地址。
十、检查 DevSpace 配置
DevSpace 提供了非常实用的诊断命令：
npx @waishnav/devspace doctor
它会检查 Node.js、Git、Bash、平台环境、Public URL、配置以及 SQLite Native Dependency 等项目。
碰到 MCP 无法连接时，不要第一时间怀疑 ChatGPT。
建议先检查：
devspace doctor
再检查：
netstat -ano | findstr 7676
最后测试公网：
curl.exe -vk https://你的花生壳域名/mcp
只要：
DNS 可以解析
TCP 443 可以建立连接
HTTPS 握手正常
请求能够到达 DevSpace
说明最基本的网络链路已经打通。
十一、在 ChatGPT 中连接 DevSpace
接下来进入 ChatGPT。
ChatGPT 对自定义 MCP/App 的支持会根据账号套餐、工作空间类型和当前产品版本有所不同。
在官方目前公布的 Developer Mode 中，可以通过类似：
Settings
↓
Apps
↓
Advanced Settings
↓
Developer Mode
开启 MCP 开发能力，然后创建自己的 MCP App。
创建时填写类似：
Name:
mall
MCP Endpoint：
https://12xxxxxx.vicp.fun/mcp
然后执行：
Scan Tools
ChatGPT 会连接 MCP Server 并读取 DevSpace 暴露出来的 Tools。
需要注意的是，OpenAI 当前对完整 MCP 写入/修改能力的开放范围仍与账号和 Workspace 类型有关，因此如果账号中没有 Create App、Developer Mode 或对应 MCP 功能，应以自己 ChatGPT 设置页面当前实际开放的功能为准。
十二、DevSpace Owner Password 是什么
第一次连接 DevSpace 时，还会遇到一个认证流程。
执行：
devspace init
时，DevSpace 会生成：
Owner Password
它会保存在：
~/.devspace/auth.json
Windows 环境大致对应：
C:\Users\你的用户名\.devspace\auth.json
这个 Password 用来批准新的 MCP Client。
当 ChatGPT 第一次连接 DevSpace 时，DevSpace 会打开授权页面，然后要求输入 Owner Password。
官方特别提醒需要将 auth.json 视为敏感配置，不要提交到 Git 仓库，也不要公开分享。
它和普通意义上的：
Bearer Token
并不是一回事。
不要看到：
{
"ownerToken": "xxxx"
}
就直接尝试：
Authorization: Bearer xxxx
DevSpace 自己有完整的 Owner Approval / OAuth 认证流程，应按照它的认证流程完成连接。
十三、在 ChatGPT 中真正使用 DevSpace
假设我给 DevSpace App 起名：
mall
之后在 ChatGPT 中就可以使用类似：
@mall 打开 D:\release\mall
或者：
@mall 列出这个项目的目录结构
继续：
@mall 帮我分析这个项目的 RabbitMQ 设计
甚至：
@mall 检查这个 Spring Boot 项目能否正常编译
DevSpace 官方提供的能力包括读取/编辑文件、搜索代码、执行 Shell Command、执行测试和构建、Git 操作以及使用 Git Worktree 等。
不过有一个很重要的概念：
Allowed Root ≠ Current Workspace
假设允许：
D:\release
真正开始开发的时候，仍然建议明确告诉 DevSpace：
打开 D:\release\mall 作为 workspace
之后再进行：
列出目录
分析源码
修改代码
运行测试
这样可以避免 AI 操作错误目录。
十四、推荐加入 AGENTS.md
对于真实项目，我强烈建议在项目根目录增加：
AGENTS.md
例如：
D:\release\mall\AGENTS.md
里面定义：
项目技术栈
代码规范
目录结构规范
禁止修改内容
数据库版本
Java版本
构建方式
测试要求
Git规则
这样 DevSpace 打开项目后，AI Agent 可以按照统一工程规范进行修改。
例如：
# AGENTS.md
## 技术栈
- Java 21
- Spring Boot 3.5
- MyBatis-Plus
- MySQL 8
- Redis
- RabbitMQ
- React
- Ant Design
## 构建
后端：
mvn clean test
前端：
npm install
npm run build
## 开发要求
修改代码前必须阅读现有实现。
禁止为了修复问题直接删除现有业务逻辑。
修改完成必须执行测试。
数据库修改必须同时提供 migration SQL。
相比每次在 ChatGPT 中重复解释项目规则，AGENTS.md 更适合作为长期的 AI Coding Contract。
十五、Remote Desktop Commander 是什么
DevSpace 的核心场景主要是：
AI Coding
Remote Desktop Commander 则更加通用。
它可以让 AI 直接操作：
文件
目录
Terminal
Process
Git
Docker
Node
Java
系统命令
官方对它的定位就是让 ChatGPT、Claude 等 AI Assistant 获得本机 File System 与 Terminal 能力。
它既支持 Local MCP，也支持 Remote MCP。
对于 ChatGPT Web，我们重点关注：
Remote Desktop Commander
十六、启动 Remote Desktop Commander
首先确保：
node -v
建议：
Node.js 22+
然后执行：
npx @wonderwhy-er/desktop-commander@latest remote
Remote Desktop Commander 官方 Remote MCP 的标准启动命令就是这一条。
第一次执行时：
Remote Device
↓
打开浏览器
↓
显示 Pairing Code
↓
登录 Desktop Commander
↓
确认设备
↓
Device Ready
最终终端应该看到类似：
Device marked as online
Channel subscribed
Device ready
只要这个终端关闭：
Remote Desktop Commander Device
就会离线。
因此使用过程中需要保持这个进程运行。
十七、ChatGPT 安装 Remote Desktop Commander
Remote Desktop Commander 已经提供面向 ChatGPT 的 Remote MCP 接入方式。
整体流程是：
ChatGPT
↓
Desktop Commander App
↓
Install
↓
Authorize
↓
Add Device
↓
选择刚才配对的 Windows PC
官方 Remote MCP 页面给出的流程同样是先在 ChatGPT 中安装 Desktop Commander，然后完成授权，再添加自己的 Device。
完成后，在 ChatGPT 里就可以直接：
@Remote Desktop Commander
例如：
@Remote Desktop Commander
列出 D:\release\mall 的目录结构
或者：
@Remote Desktop Commander
检查 D:\release\mall 后端项目能否正常编译
甚至：
@Remote Desktop Commander
在 D:\temp 创建一个 React 商城宣传首页
这时候命令实际是在：
自己的 Windows PC
执行，而不是 ChatGPT 的云端 Sandbox。
十八、DevSpace 和 Remote Desktop Commander 有什么区别
很多人第一次使用时会觉得两者功能重复。
实际上可以这样理解：
| 能力 | DevSpace | Remote Desktop Commander |
|---|---|---|
| 项目源码阅读 | ★★★★★ | ★★★★★ |
| AI Coding 工作流 | ★★★★★ | ★★★★ |
| Workspace 隔离 | ★★★★★ | ★★★ |
| Git Worktree | ★★★★★ | ★★★ |
| AGENTS.md | ★★★★★ | ★★★★ |
| 全磁盘文件访问 | 受 Allowed Root 限制 | ★★★★★ |
| Terminal | ★★★★★ | ★★★★★ |
| 系统管理 | ★★★ | ★★★★★ |
| 多项目开发 | ★★★★★ | ★★★★★ |
| Windows 运维 | ★★★ | ★★★★★ |
| Docker 管理 | ★★★★ | ★★★★★ |
我的使用方式是：
写代码
↓
DevSpace
机器管理 / 文件管理 / 环境配置
↓
Remote Desktop Commander
例如：
@mall
分析 mall 项目的 RabbitMQ 设计
比较适合 DevSpace。
而：
@Remote Desktop Commander
帮我检查 Node.js、Java、Maven、Docker 的版本
更适合 Remote Desktop Commander。
十九、两个工具可以同时使用吗？
完全可以。
甚至这是非常舒服的一种组合。
例如：
ChatGPT
│
├──── @mall
│ │
│ └── D:\release\mall
│
└──── @Remote Desktop Commander
│
└── Windows PC
DevSpace 专门负责：
Repository
Remote Desktop Commander 负责：
Machine
这样 ChatGPT 可以完成一条比较完整的链路：
读取项目
↓
分析问题
↓
修改源码
↓
运行 Maven
↓
启动 Docker
↓
检查日志
↓
验证端口
↓
重新修改
↓
再次测试
传统 ChatGPT 只能告诉你：
“请执行 mvn clean test”
接入这些 MCP 后，则有机会变成：
ChatGPT
↓
直接执行
mvn clean test
↓
读取错误
↓
分析错误
↓
修改代码
↓
重新测试
这也是 MCP 对开发流程真正有价值的地方。
二十、Windows 常见问题：npm EPERM
Windows 安装 DevSpace 时，还可能遇到：
npm error code EPERM
npm error syscall open
npm error path C:\Users\Administrator\.npmrc
例如：
EPERM: operation not permitted,
open 'C:\Users\Administrator\.npmrc'
先执行：
Get-Item C:\Users\Administrator\.npmrc |
Format-List FullName,Attributes,Length
如果看到：
Attributes : ReadOnly, Archive
说明：
.npmrc
被设置成只读。
解除只读：
attrib -R C:\Users\Administrator\.npmrc
或者：
Set-ItemProperty `
-Path C:\Users\Administrator\.npmrc `
-Name IsReadOnly `
-Value $false
之后重新执行 npm 命令即可。
如果仍然出现：
EPERM
再检查文件 ACL：
icacls C:\Users\Administrator\.npmrc
二十一、Remote Desktop Commander 的 Node 20 WebSocket 问题
Windows 环境还可能看到：
Device startup failed:
Node.js 20 detected without native WebSocket support
并提示：
import ws from "ws"
对于普通 Node.js 项目当然可以安装：
npm install ws
但对于：
npx @wonderwhy-er/desktop-commander@latest remote
这种 CLI 工具来说，直接升级 Node.js 通常更加干净。
推荐：
Node 22
或者：
Node 24
然后确认：
where node
node -v
防止 Windows 中存在：
Node 20
Node 24
两个版本，但 PATH 实际仍然指向 Node 20。
二十二、DevSpace 无法连接时怎么排查
最有效的排查方法不是不停删除重装，而是按链路逐层检查。
完整路径是：
ChatGPT
↓
公网 DNS
↓
HTTPS 443
↓
花生壳
↓
127.0.0.1:7676
↓
DevSpace
↓
Workspace
本机先执行：
devspace doctor
确认 DevSpace：
netstat -ano | findstr 7676
再测试：
curl.exe http://127.0.0.1:7676/mcp
然后测试公网：
curl.exe -vk https://你的域名/mcp
如果公网：
TCP Connection established
但是 MCP Scan 失败，那么重点检查：
publicBaseUrl
OAuth
Host
/mcp Path
如果公网根本连接不上，则应该先检查：
花生壳映射
Windows 网络
DevSpace 是否运行
而不是修改 MCP 配置。
二十三、推荐的最终配置
如果是在 Windows 上使用，我比较推荐这一套组合：
Windows 11
│
├── Node.js 24
├── Git for Windows
├── Git Bash
├── Java 21
├── Maven
├── Docker Desktop
│
├── DevSpace
│ └── 127.0.0.1:7676
│
├── 花生壳
│ └── HTTPS → 127.0.0.1:7676
│
└── Remote Desktop Commander
└── Remote Device
ChatGPT：
ChatGPT
│
├── @mall
│ └── DevSpace MCP
│
└── @Remote Desktop Commander
└── Windows Device
日常开发：
项目源码开发
↓
DevSpace
操作系统 / 环境 / Docker / 文件
↓
Remote Desktop Commander
这样的职责划分会非常清晰。
二十四、安全问题一定要注意
无论是 DevSpace 还是 Remote Desktop Commander，都不是普通的“聊天插件”。
它们拥有的实际上是：
文件读写权限
+
Shell 执行权限
Remote Desktop Commander 官方也明确说明，它是一个具有较高权限的本地自动化工具，连接的 AI Client 应被视为可信客户端，而不是把它看作安全沙箱。
因此不要把下面这些内容暴露给 AI Workspace：
SSH Private Key
生产环境数据库密码
云服务器 Secret Key
支付平台私钥
.env.production
浏览器 Cookie
密码管理器数据库
DevSpace 应尽量使用：
Allowed Roots
限制访问范围。
Remote Desktop Commander 不使用时则可以直接：
Ctrl + C
关闭 Remote Device。
官方也建议只连接自己拥有的设备，并在不需要时停止 Device Agent。
二十五、总结
完成这些配置之后，我们实际上搭建了一套：
ChatGPT + MCP + Local Development Environment
传统模式：
开发者
↓
复制代码
↓
ChatGPT
↓
复制回答
↓
IDE
↓
运行
↓
发现错误
↓
再次复制
现在则可以变成：
开发者
↓
ChatGPT
↓
MCP
↓
DevSpace / Remote Desktop Commander
↓
本地项目
↓
编译 / 测试 / Git / Docker
↓
结果返回 ChatGPT
其中：
DevSpace
负责把本地代码仓库变成 AI Workspace；
花生壳
负责解决 ChatGPT 无法直接访问局域网 MCP Server 的问题；
Remote Desktop Commander
则进一步把能力从“代码仓库”扩展到了：
整台开发电脑
对于 Java/Spring Boot、React、Node.js、Docker 等全栈开发场景，这套方案最大的价值并不是“AI 可以帮忙写几段代码”，而是让 AI 真正进入：
读取 → 分析 → 修改 → 构建 → 测试 → 验证
这一整套工程闭环。
当 MCP、AGENTS.md、DevSpace 和本地工具链真正组合起来以后，ChatGPT 才开始从传统的“编程问答助手”，逐渐变成能够参与真实项目开发流程的 Coding Agent。
