Codex额度紧？DevSpace把网页额度接进项目
如果你已经开了ChatGPT Plus或Pro，又在Codex里不够用，DevSpace这个项目第一眼就该看。
它最吸引人的地方很直接，ChatGPT网页端那份能力可以进本地项目了。
直接说重点：
1、网页上的额度次数可以使用。
2、网页上的Pro模型可以使用，5x，20x不白开。
它是一个自托管MCP服务器，它能通过MCP直接读你允许的项目目录，必要时还能改文件、跑命令、看Git状态。
你可以理解成在自己电脑上跑一个小服务，只把你允许的项目目录开放给ChatGPT。
ChatGPT通过MCP连进来以后，可以打开这个项目，读文件、搜代码、改文件、跑测试、看Git状态，还能按项目里的AGENTS.md或CLAUDE.md做事。
手把手教你装
路径很短，先确认三件事。
你本机要有Node、npm、Git和Bash兼容shell。
Windows上不要只靠PowerShell，至少准备Git Bash、WSL、MSYS2或Cygwin这类环境。
DevSpace官方README要求Node版本大于等于22.19且小于27。
然后在终端里跑两步。
npx @waishnav/devspace init
npx @waishnav/devspace serve
如果你更喜欢全局安装，也可以先跑npm install -g @waishnav/devspace，后面再用devspace init和devspace serve。
跑起来以后，你还需要一个公网HTTPS地址把本地DevSpace服务转出去。Cloudflare Tunnel、ngrok、Tailscale Funnel这类工具都属于这一层。最后去ChatGPT网页端打开Developer mode，创建一个自定义MCP app，把DevSpace给你的MCP地址填进去，再用Owner password批准连接。
这里别贪快。第一次只开一个测试项目目录，别把整个D盘或用户目录丢进去。能读项目、跑一次测试、改一个小bug，再考虑接真实项目。
网页端次数也能进开发流程
老金我现在看AI编程工具，越来越不只看它能不能改文件。我更关心它能不能把我已经付费的能力用起来。
有些活，Codex本机体验更顺。比如连续改几个文件、跑测试、看diff、收尾提交，这种现场感Codex很强。但也有些活，我会更想用网页端强模型先想一遍。比如架构取舍、复杂bug定位、迁移方案、长文档理解、多个方案互相挑刺。
以前这两边中间隔着一堵墙。网页端能想，但看不到项目。Codex能进项目，但额度按Codex自己的口径走。你开了ChatGPT Plus或Pro，也不等于这份网页端权益可以直接变成Codex里的使用量。
DevSpace把这堵墙打薄了一点。
你可以让Codex继续做本地开发主力，也可以在ChatGPT网页端开一个DevSpace连接，让网页端可用的强模型看同一个项目。Codex跑改动，网页端读项目、给审查清单、迁移方案和风险点。额度紧的时候，至少不用把所有代码问题都排队交给Codex。
这里要说清楚边界。
这条边界要直接说清。DevSpace不给Codex加额度，也不改变OpenAI限制。Codex有自己的使用限制和计费口径，ChatGPT网页端也有自己的账号、模型和连接能力。DevSpace能做的事更朴素，它给网页端一个能看项目的通道。
Plus也可以写进去，但不能写满。OpenAI的ChatGPT计划页把Developer mode列在Plus和Pro里，说明Plus不该被漏掉。OpenAI Help Center对完整MCP支持又有更保守的Business、Enterprise、Edu口径。你自己判断时看三步就行：网页端有没有Developer mode，能不能创建自定义MCP app，连上以后模型会不会真的调用DevSpace工具。三步都过，DevSpace消耗的就是ChatGPT网页端这边的可用次数，不是Codex额度。
还有一个细节要压住。DevSpace项目Issue里有人测到，ChatGPT不同模型通道拿到MCP工具的情况不一样。能调用的通道，可以打开项目、读文件、跑工具。拿不到工具的通道，页面上可能看得到DevSpace入口，但你让它读本地README时，不会出现read、edit、bash这类工具调用，只会继续让你复制内容。所以第一次连接后要让它读一个文件、跑一个只读命令，看工具调用记录。跑不起来，就别把它写成稳定可用。
账号入口能跑通以后，舒服的地方就很具体了。网页端可以直接读项目，直接看报错，直接给下一步建议。Codex在跑一个长任务时，ChatGPT网页端还可以从另一个角度做代码审查、方案比较、错误归因。
这个差别很关键。
它比普通MCP多一点编码味
DevSpace暴露的是一个轻量工作区。
它的设计更像一个给ChatGPT准备的轻量工作区。打开项目时会返回workspaceId，后续读文件、搜内容、改文件、跑shell都复用这个工作区。它还支持checkout模式和worktree模式，后者会在~/.devspace/worktrees下面建一个隔离工作区，适合并行开任务。
这个设计很像Codex里常见的安全习惯。
你不想让AI直接碰当前工作区，就让它进worktree。你想让它遵守项目规则，就让它读AGENTS.md。你有本地Skill目录，它也能发现相关Skill，再按SKILL.md做事。
对普通读者来说，这些词可能有点绕。你可以把worktree理解成项目的临时分身，把AGENTS.md理解成写给AI看的项目说明，把Skill理解成一套AI可以调用的工作方法。
这些东西放在一起，DevSpace更像一个给ChatGPT准备的项目工位。网页端ChatGPT打开以后，能按项目规则读、改、跑、复盘，离Codex那种协作现场更近。
先别急着全盘开放，本地权限这块要敬畏
这工具好用的地方，也正是它危险的地方。
DevSpace官方文档说得很直白，它相当于把本地开发能力通过MCP暴露出去。你选了哪些目录，ChatGPT就可能在这些目录里读写文件。它还可以跑shell命令，而shell命令本质上是在你本机执行。
所以老金我不建议一上来就把整个用户目录、整个D盘、整个工作盘都开放。
第一次试，目录越小越好。最好新建一个测试项目，只放能丢的代码。Owner password不要外传，隧道URL也别当秘密本身。公网隧道外面最好再加Cloudflare Access、Tailscale身份控制这类保护。
Windows用户还要注意一个细节。DevSpace目前要求Bash兼容shell，Git Bash、WSL、MSYS2、Cygwin这类可以，只有PowerShell或cmd还不行。这个点别忽略，不然你会卡在命令执行那里。
还有一个边界也要记住。
Worktree能减少误改当前目录，但它挡不住越权命令。它管的是工作区隔离，不是权限隔离。最该盯住的，还是你允许了哪些目录、信不信这个MCP客户端、有没有保护好Owner password。
谁最适合先上车
我觉得DevSpace最适合三类人。
第一类，是已经在重度用Codex和ChatGPT Plus或Pro的人。你本来就两边都付费，平时也会把复杂问题丢给网页端想一遍。DevSpace能让网页端少听你复述项目背景，直接进项目看材料。
第二类，是经常做代码审查和方案判断的人。很多时候你不一定要它马上改代码，你只是想让强模型读一遍项目，告诉你这次改动会不会埋坑，测试该从哪补，哪个方案更稳。
第三类，是喜欢多Agent工作流的人。Codex跑主任务，ChatGPT网页端通过DevSpace做旁路审查，另一个窗口整理文档或写测试计划。你自己在中间做判断和验收。
这里老金我更看重的是人机协作。
AI不能替你把整个项目接管过去。你仍然要决定开放哪个目录，要确认它改了什么，要看测试结果，要判断这次改动是否符合你的真实目标。DevSpace只是让网页端强模型离现场更近，最后该拍板的人还是你。
我会怎么用它
如果我今天开始试DevSpace，我不会一上来让它改大项目。
我会先建一个小仓库，里面放一段有测试的代码，再让ChatGPT打开这个项目。第一轮只问它读项目、跑测试、解释结构。第二轮再让它改一个很小的bug。第三轮看它能不能给出清楚的diff和风险说明。
能跑通这三步，再接真实项目。
这套节奏很朴素，但能避开很多AI工具刚上手时的幻觉。不要一开始就把生产项目交出去，也不要因为网页端模型很强，就默认它懂你的所有上下文。
DevSpace最值得期待的地方，是把ChatGPT网页端从一个问答框，往本地项目现场推了一步。
这一步不夸张，但很实用。
当Codex额度紧、ChatGPT网页端那份次数还在时，它能让你少搬上下文，多用一次强推理。对重度AI编程用户来说，这个组合已经够有吸引力了。
工具越来越多，到头来拼的可能是一个很朴素的东西。
谁能少让人绕一步。