OpenAI取消ChatGPT无限对话，作者称其开发方式受影响

好吧，大概不是我。但看完我最近拿 ChatGPT 干的事，他们想动手我完全能理解。

OpenAI 最近宣布了改动，将取消 ChatGPT 的不限量对话，并把它和 Codex 的用量合并。我此前一直用来做开发的那种不限量对话，以后不会照旧了。

过去几个月，我基本上把全部软件开发都放在不限量的 ChatGPT 对话里完成，完全没消耗 Codex 的额度。

ChatGPT 对自定义 MCP 服务器的支持，加上 OpenAI 的 Secure MCP Tunnel，让我可以把跑在自己机器上的工具直接暴露给普通的 ChatGPT 对话。

我搭了一个统一的 MCP 服务器，跑在我的 Windows 笔记本上，VPS 上也有一套类似的配置，还集成了几个开源项目：

突然间，普通的 ChatGPT 对话就能完成我以前用 Codex 做的绝大部分实际开发工作了。

它们可以查看仓库、改代码、执行命令、调试报错，还能通过视觉确认改动效果。

下一个难题是让本地 MCP 服务器能被 ChatGPT 访问。

OpenAI 提供了 Secure MCP Tunnel，结果这正好就是我需要的东西。

我把统一的 MCP 网关接到隧道上，用 API key 完成认证，把 MCP 工具直接暴露给 ChatGPT。

不需要为把 ChatGPT 接到我的笔记本上而专门搭一套云端基础设施。

隧道和 MCP 集成都不需要额外付费的 API 推理调用。我用的是开源工具、OpenAI 提供的隧道工具、我已有的 ChatGPT 订阅，以及我本来就有的电脑。

01 / 连接架构

一条私有 MCP 连接，多种本地能力。ChatGPT 普通对话 Secure MCP Tunnel OpenAI 托管的 tunnel-client 运行在我的电脑上 工具调用 HTTPS 本地 MCP 进程 统一 MCP 网关 Node.js 路由 / 工具聚合 Desktop Commander 文件 · 代码 · 终端 · 测试 Enhanced TryCua 屏幕 · 鼠标 · 浏览器 · UI 本地后端工具也可以托管在我的 VPS 上。连接架构。

我改进了这套集成

当然，等一切跑通之后，我忍不住又开始折腾这些工具本身。

我对 CUA 集成做了几处增强，改善 ChatGPT 与我的电脑交互的方式，以及结果在对话里呈现的效果。

一个例子是让真实的截图直接渲染在 ChatGPT 里。

以前截图工具返回的结果 ChatGPT 能看，我自己却不容易看到；于是我加了对自定义 MCP App 查看器的支持，把抓到的截图直接显示出来。

我还改进了工具调用结果的处理方式，让它们在 ChatGPT 对话里更容易阅读。

03 / 我的改进 一些让底层工具更实用的小改动。基础 MCP 工具 Desktop Commander · CUA 截图查看器 抓取的屏幕在 ChatGPT 内可见 可靠的工具结果 图像边界 · 一致的错误 监控与控制 实时日志 · 健康状态 · CPU / 内存 更好的体验 真实工作流 自定义工具集成。

我那好玩的 AI 开发小工作流

因为 ChatGPT 对话没法派生或控制子对话、子代理，所以我得稍微动点脑筋，才能做多智能体开发和编排。

02 / 工作流 高级规划。独立的 GitHub issue。多个 Sol High 干活的。Astra / Pro 模型 系统设计与规划 GitHub issue 小而明确的任务 并行 worker 池 独立的 ChatGPT 对话 Sol High · 对话 A Issue 1 Sol High · 对话 B Issue 2 Sol High · 对话 C Issue 3 Sol High · 对话 D Issue 4 共享 MCP 访问 读取 · 编辑 · 跑测试 · 查看结果 规划与并行执行。

我会先用一个推理能力更强的模型，比如 Codex 里的 Astra，或者 ChatGPT 里额度有限的 Pro 模型，让它制定一份详细的实现方案。

接着让它把方案拆成若干个更小的、定义清晰的 GitHub issue。每个 issue 都包含足够的上下文、要求和验收标准，好让另一个 AI agent 能独立接手。

本质上，我是把一个大的开发任务变成了一队小任务。

然后我会开好几个独立的 ChatGPT 对话，每个都跑 Sol 6 High，分别指派不同的 issue。

因为这些对话都能访问我的 MCP 服务器，它们真的能动手改代码。

它们可以读取项目、编辑文件、跑测试、看报错，反复迭代，直到完成各自被分配的任务。

而且在当时，我用 Sol High 对话不会撞上在 Codex 里遇到的那种用量限制。

当然，Sol High 比那些高级模型慢。但当用量实际上不限的时候，谁还在乎这个？

我会让多个对话同时处理不同任务，把额度更有限的高级模型留给架构设计、难做的决定和代码审查。

它并不完美。并行 agent 共享同一个文件系统需要协调，偶尔某个 issue 还得更强的模型介入。

但对于定义明确的编码任务，它效果好得惊人。

我实际上是把 ChatGPT 当成一池编码 agent，让 GitHub issue 充当任务队列。

我还做了一个非常轻量的界面，可以启停整个 MCP 连接、监控服务器健康状态、跟踪 CPU 和内存占用，并查看工具调用的实时信息流。

我能看到 ChatGPT 什么时候读文件、执行命令，或者调用 computer-use 工具。

这个面板还会记录失败，让我可以查看最近的活动。

天下没有不散的筵席，这事也要到头了。它要没了，我挺难过。

不限量对话是唯一让我还留着 OpenAI 订阅的理由。我个人大大偏爱 Claude 的模型，我打算跳船了。尤其 Claude Opus 在我的用例里似乎聪明得多，而且一个 Claude 订阅比一个 Codex 订阅能让我用得更多。

说清楚一点，我没有违反任何规则。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）