DevSpace：让 GPT 连接本地代码仓库的开源 MCP 项目

今天介绍一个最近比较值得关注的 GitHub 开源项目：DevSpace。

项目地址：

DevSpace 的一句话定位是：让 GPT 通过 MCP 协议连接你的本地开发环境，从而具备类似 Codex 的本地代码读写、搜索、运行命令和辅助开发能力。

它并不是一个新的大模型，也不是一个新的 IDE，而是一个运行在开发者自己电脑上的 自托管 MCP Server。通过 DevSpace，GPT 可以在你授权的项目目录中读取代码、搜索文件、修改内容、运行测试、执行构建命令，并配合 Git 完成代码检查和变更管理。

简单来说，DevSpace 解决的是一个很实际的问题：过去我们让 GPT 帮忙看代码，通常需要手动复制代码、粘贴报错、描述目录结构。项目稍微复杂一点，上下文就很容易丢失。而 DevSpace 的思路是，既然代码就在本地，那就通过 MCP 把本地 workspace 安全地连接给 GPT，让它不只是“听你描述代码”，而是可以真正进入项目目录中工作。

它的基本工作流可以理解为：

ChatGPT
   ↓ MCP
DevSpace Server
   ↓
本地项目 Workspace
   ↓
文件读写 / 代码搜索 / Shell 命令 / Git / Worktree

使用时，开发者先在本机启动 DevSpace，然后配置允许访问的项目根目录。接着通过 Cloudflare Tunnel、ngrok、Tailscale Funnel 或其他 HTTPS 反向代理，把本地 MCP 服务暴露出来。之后，在支持 MCP 的客户端中连接 /mcp 地址，并使用 Owner Password 完成授权。授权完成后，GPT 就可以打开指定的本地项目目录，并在受控范围内进行编码辅助。

DevSpace 的核心能力主要包括以下几个方面。

第一，本地文件读写与代码编辑。GPT 可以读取项目文件，也可以对代码进行局部修改。比如修复 bug、重构函数、补充类型定义、调整配置文件、修改 README 等。

第二，目录检查与全文搜索。它可以查看项目结构、搜索关键函数、定位依赖关系。相比手动把项目结构复制给 GPT，这种方式更接近真实的 coding agent 工作流。

第三，运行 Shell 命令。DevSpace 可以让 GPT 执行测试、构建、Git、包管理脚本等命令。这样一来，GPT 不只是给出建议，还能根据真实的测试输出继续分析错误原因。

第四，Git Worktree 支持。DevSpace 支持使用 Git worktree 创建隔离的工作区，适合多个任务并行进行，比如一个 worktree 修复 bug，另一个 worktree 做功能实验，降低不同修改互相影响的概率。

第五，项目说明文件支持。它可以读取 AGENTS.md、CLAUDE.md 这类项目指令文件，让 GPT 更好地理解当前项目的代码规范、运行方式、测试要求和开发约束。

第六，本地 Skills 扩展。DevSpace 可以发现本地 skills 目录，把一些固定的开发流程封装成可复用能力，例如代码审查、测试流程、构建检查、文档生成等。

从技术角度看，DevSpace 的价值不在于“模型能力变强了”，而在于它打通了 GPT 与本地开发环境之间的工具调用链路。

过去的 GPT 编程辅助更多是问答式的：开发者提供上下文，GPT 给出建议。DevSpace 则更接近 agent 式工作流：GPT 可以读取项目、修改文件、运行命令、查看结果，然后继续下一步。这种模式更适合真实项目开发，而不是只处理孤立代码片段。

DevSpace 如何与 Codex 搭配使用？

如果只是单独使用 DevSpace，它更像是把 GPT 接入本地项目的桥梁。但如果再搭配 Codex，就可以形成一个更完整的智能编码工作流：

GPT 负责思考和规划，Codex 负责实现和验证，DevSpace 负责让 GPT 看见本地项目。

这三者的关系可以这样理解：

GPT + DevSpace：理解项目、分析架构、拆解任务、制定方案
        ↓
任务说明 / TASK.md / Issue Prompt
        ↓
Codex：修改代码、运行测试、修复报错、生成 diff
        ↓
GPT + DevSpace：复核实现、检查边界、总结问题

这种搭配方式的核心不是让 GPT 和 Codex 互相替代，而是让它们各自做自己更擅长的事情。

GPT 的优势是推理、规划、复杂问题拆解和架构理解。通过 DevSpace，GPT 可以直接读取本地项目结构，理解代码关系，找出相关文件，然后输出更可靠的技术方案。

Codex 的优势是工程执行。它更适合按照明确任务去修改代码、运行测试、修复错误、整理变更，并把结果落实到真实代码仓库中。

因此，更推荐的分工是：

GPT：项目架构分析师 / 任务规划师 / 代码审阅员
Codex：代码执行工程师 / 测试执行器 / PR 生成器
DevSpace：本地项目上下文连接层
开发者：最终决策者 / 合并负责人

也就是说，GPT 不一定要直接承担大量代码修改任务，而是先通过 DevSpace 理解项目，然后生成一个结构化的任务单；Codex 根据任务单完成具体实现；最后再由 GPT 和开发者一起复核 Codex 的修改结果。

这种方式可以避免一个常见问题：让 AI 一边理解需求、一边设计方案、一边修改代码、一边修复报错，最后很容易出现实现跑偏、改动范围过大、测试不完整的问题。

更合理的方式是把任务拆开：

第一步，GPT + DevSpace 做项目理解。

例如你可以让 GPT 通过 DevSpace 打开本地项目，然后要求它先不要修改代码，只分析项目结构：

请通过 DevSpace 打开当前项目，先不要修改代码。

请完成以下分析：
1. 项目的核心目录结构；
2. 与当前需求相关的模块和文件；
3. 当前项目的构建、测试和运行方式；
4. 可能受影响的代码路径；
5. 给出一个最小改动方案；
6. 输出一个 Codex 可以直接执行的任务说明。

这一步的重点是让 GPT 先“看懂项目”，而不是马上动手改。

第二步，GPT 生成 Codex 任务单。

建议在项目中建立一个 .ai/tasks/ 目录，把 GPT 生成的任务计划保存下来，例如：

.ai/tasks/TASK-001-add-login-rate-limit.md

任务单可以写成这种格式：

# TASK-001：为登录接口增加限流能力

## 背景
当前登录接口缺少请求频率控制，可能导致暴力破解风险。需要在不大幅改动现有认证逻辑的前提下增加限流能力。

## 目标
为登录接口增加基于 IP 的限流能力。

## 非目标
- 不重构认证系统
- 不更换数据库结构
- 不引入大型网关组件

## 影响范围
可能涉及：
- src/middleware/
- src/routes/auth.*
- src/config/
- tests/auth.*

## 实现要求
1. 增加可配置的限流中间件；
2. 默认限制为每个 IP 每 5 分钟最多 10 次登录请求；
3. 限流触发时返回 429；
4. 不影响其他接口；
5. 保持现有测试通过。

## 验收标准
1. 正常登录请求不受影响；
2. 超过限制后返回 429；
3. 已有测试全部通过；
4. 新增至少一个限流相关测试；
5. 不引入无关格式化变更。

## 建议测试命令
```bash
npm test
npm run lint

注意事项

• 优先复用项目已有配置方式；

• 不要修改无关模块；

• 如果发现需求与现有架构冲突，先输出说明再修改。

这个任务单就是 GPT 给 Codex 的“工程任务书”。

第三步，**Codex 根据任务单实现代码**。

接下来，在 Codex 中输入：

```text
请阅读 .ai/tasks/TASK-001-add-login-rate-limit.md，并按其中要求实现。

要求：
1. 先查看相关文件，不要直接大范围重构；
2. 只修改与任务相关的文件；
3. 实现后运行任务单中的测试命令；
4. 如果测试失败，先分析原因，再修复；
5. 最后总结修改了哪些文件、为什么这样改、测试结果是什么。

这时 Codex 就不需要再从零开始猜需求，而是根据 GPT 规划好的任务边界去执行。这样可以显著降低任务跑偏的概率。

第四步，GPT + DevSpace 复核 Codex 的修改。

Codex 完成实现后，不建议直接合并。可以再让 GPT 通过 DevSpace 检查修改结果：

请通过 DevSpace 检查 Codex 刚才的修改。

重点检查：
1. 是否严格符合 TASK-001 的目标；
2. 是否修改了无关文件；
3. 是否存在安全问题；
4. 是否存在边界条件遗漏；
5. 测试是否覆盖核心场景；
6. 给出是否建议合并，以及需要继续修改的点。

这一步相当于让 GPT 做代码审阅。它不再是任务执行者，而是复核者和质量把关者。

最终，由开发者自己确认 git diff、测试结果和代码风格，再决定是否提交和合并。

推荐的本地协作目录结构

为了让 GPT、Codex 和开发者之间的交接更加清晰，可以在项目中增加一个 .ai/ 目录：

.ai/
├── tasks/
│   ├── TASK-001-add-login-rate-limit.md
│   └── TASK-002-refactor-config-loader.md
├── reviews/
│   ├── REVIEW-001.md
│   └── REVIEW-002.md
└── prompts/
    ├── codex-implement.md
    └── gpt-review.md

这样做的好处是，AI 之间的协作不是靠聊天记录临时传递，而是通过仓库中的结构化文件交接。

其中：

.ai/tasks/    用来存放 GPT 生成的任务说明
.ai/reviews/  用来存放 GPT 对 Codex 修改结果的复核意见
.ai/prompts/  用来存放固定提示词模板

这种方式非常适合做技术分享，因为它能把整个流程讲清楚：

需求输入
  ↓
GPT + DevSpace 分析项目
  ↓
生成结构化任务单
  ↓
Codex 执行代码实现
  ↓
运行测试并修复错误
  ↓
GPT + DevSpace 复核
  ↓
开发者确认并合并

一个适合演示的 Demo 场景

如果要做技术分享，可以设计一个非常直观的 Demo：

给一个 Node.js 项目的登录接口增加限流功能。

演示步骤如下。

第一步，让 GPT 通过 DevSpace 分析项目：

请打开当前项目，只分析不修改。

我要为登录接口增加限流能力。
请找出认证相关代码、路由入口、中间件机制、测试命令，并输出一个 Codex 可执行的任务单。

第二步，让 GPT 生成任务单：

请将任务单写入 .ai/tasks/TASK-001-add-login-rate-limit.md

第三步，让 Codex 执行任务：

请根据 .ai/tasks/TASK-001-add-login-rate-limit.md 实现功能。
完成后运行测试，并总结修改文件和测试结果。

第四步，让 GPT 通过 DevSpace 复核：

请检查 Codex 的修改是否符合任务单。
重点看：
- 是否有无关修改；
- 是否覆盖限流测试；
- 是否存在安全边界问题；
- 是否符合项目原有风格；
- 是否建议合并。

第五步，开发者最终确认：

git diff
git status
npm test
git commit -m "feat: add login rate limiting"

这套 Demo 的好处是非常清晰：观众可以看到 GPT 如何理解项目、Codex 如何执行代码修改、DevSpace 如何提供本地项目上下文，以及开发者如何保留最终控制权。

使用 DevSpace + Codex 时的注意事项

虽然这个组合很强，但也不能把控制权完全交给 AI。

第一，DevSpace 的 allowlist 必须控制得很窄。不要把 ~、/、C:\、整个桌面或者整个用户目录加入允许访问范围。建议只允许访问当前 demo 项目或测试项目。

第二，Shell 权限要谨慎。DevSpace 允许执行本地命令，而这些命令通常会以当前系统用户权限运行。因此，必须确保连接 DevSpace 的 MCP 客户端可信。

第三，GPT 和 Codex 不要同时修改同一个工作目录。更稳妥的方式是 GPT 主要负责分析和写任务单，Codex 负责实际代码修改。如果要并行处理多个任务，可以使用 Git worktree 隔离不同工作区。

第四，首次演示不要使用真实生产仓库。建议准备一个结构清晰、依赖简单、测试可运行的示例项目。这样演示过程更稳定，也更容易控制风险。

第五，AI 输出的代码必须经过人工确认。无论 GPT 规划得多完整，Codex 实现得多顺利，最终合并前都应该由开发者检查 diff、测试结果和安全边界。

总结

DevSpace 的核心价值，是让 GPT 可以通过 MCP 连接本地项目，从而获得真实的项目上下文。Codex 的核心价值，是把明确的开发任务落实到代码实现、测试运行和变更提交中。把二者搭配起来，就可以形成一个更清晰的智能编码协作模式：

GPT 负责想清楚：要做什么、为什么做、怎么验收；
DevSpace 负责看清楚：项目在哪、代码结构是什么、上下文有哪些；
Codex 负责做出来：改哪些文件、怎么实现、测试是否通过；
开发者负责最终判断：是否接受、是否合并、是否发布。

因此，DevSpace 并不是 Codex 的替代品，而是 GPT 与本地项目之间的连接层。它更适合承担“项目上下文入口”和“任务规划辅助”的角色。而 Codex 更适合承担“工程执行”和“代码落地”的角色。如果把它们组合起来，比较理想的模式就是：

GPT + DevSpace = 项目架构分析师 / 任务规划师 / 代码审阅员
Codex = 代码执行工程师 / 测试执行器 / PR 生成器
开发者 = 技术负责人 / 最终合并者

一句话总结：DevSpace 让 GPT 看见本地项目，Codex 负责把任务真正实现，开发者掌握最终控制权。对于想探索 MCP、本地智能编码工作流、多 Agent 协作开发的个人开发者来说，DevSpace 值得了解和实践。项目地址：