ChatGPT Codex 选用指南：理解代码用 ChatGPT，修改项目用 Codex

ChatGPT Codex 怎么选？先看任务要交付什么

如果答案还需要落实成项目里的代码修改，用 Codex；如果把问题弄明白就算完成任务，用 ChatGPT。 代码仓库保存着应用的源文件和项目历史。任务一旦涉及这些文件、项目依赖和测试，Codex 能直接操作项目的工作环境，就成了选择它的关键。

对于独立开发者，如果只是解释报错，或讨论一个能完整看懂的函数，ChatGPT 就够用。如果修复错误需要查找调用方、修改关联文件，再运行项目检查，就该选 Codex。

对于想把 Bug 修复交出去的创始人，只要能说清当前哪里出错、预期应该怎样，就可以交给 Codex。但发布前仍需审查修改。对于正在评估技术方案的 CTO 或资深业务负责人，可以先在 ChatGPT 里讨论；有了代码仓库和明确的实现任务，再转到 Codex。

这些建议依据四个维度：任务需要多少上下文、是否要改文件、是否要执行代码，以及最后还有什么需要你验证。它们判断的是工作流程是否合适，不是基准测试排名。

对于已有 Plus、Pro 或 Business 的订阅用户，1 份订阅即可使用 ChatGPT，以及套餐内包含的 Codex 用量。套餐详情见 Codex 价格指南和 OpenAI 的登录与计费说明。

上表涉及的能力可查阅 OpenAI 的 Codex CLI 指南、worktree 指南、GitHub 连接指南和 ChatGPT 代码块指南。

现在的 Codex 和 ChatGPT，分别是什么？

ChatGPT 是用途更广的助手；Codex 则围绕软件开发组织工作流程。 OpenAI 目前在 ChatGPT 桌面应用中为 Codex 提供了独立视图。菜单里也有 ChatGPT 入口，可以在普通 Chat 和 Work 之间切换。Work 是用于较长任务和交付成果的智能体，因此，把所有 ChatGPT 使用方式都说成只能被动回答的文本框，并不准确。OpenAI 的使用模式指南区分了这三种模式。

本文以普通 Chat 模式为比较基准。Work 可以使用文件和工具，在权限允许时也能访问本地资源。如果任务是把文档整理成报告，可以考虑 Work；如果要修改代码库，则应选择 Codex 的仓库工作流程。

解释代码、处理独立的小问题，ChatGPT 更方便

ChatGPT 是对话式助手，可通过网页、手机应用和桌面应用使用。把函数、错误信息或设计选项交给它，就能围绕需要理解的部分提问。OpenAI 分别介绍了 Web、iOS 和 Android 端的使用方式及桌面端体验。

它的能力不止生成文字。受支持的代码块可以编辑、预览，其中受支持的 Python 代码还可以在沙箱中执行；沙箱就是隔离的代码运行环境。具体可用功能取决于设备、模型、套餐和工作区。OpenAI 的代码块文档介绍了这些操作。

对于要检查陌生脚本的业务负责人，这些能力可能已经够用。可以问它：脚本会改动什么、需要哪些输入、哪些失败情况值得留意。如果你需要的只是一个能直接判断是否合理的解释，就不必先配置仓库环境。

局限在于上下文由谁来选。一段对粘贴函数的解释即使听起来很有道理，也可能漏掉某个传入异常值的调用方。补充更多代码会有帮助，但提供的信息是否足够，仍需要你来判断。

修改仓库并验证结果，Codex 更合适

OpenAI Codex 是能够检查项目、编辑文件和运行命令的编程智能体。不同入口决定了这些工作在哪里进行：

• Codex 应用视图： 在 ChatGPT 桌面应用中选择 Codex，打开相关项目或文件夹。如果希望在专门的视图中跟进进行中的工作，可以用这个入口。当前的应用文档介绍了桌面应用的整体界面。
• Codex CLI： 通过终端，在指定项目目录中运行命令行界面。如果所需工具已经在本地开发环境中，适合选择它。CLI 文档。
• Codex IDE 扩展： 集成开发环境扩展就在编辑器旁边工作，能够利用已打开的文件和选中内容，并展示改动供你审查。如果你正在查看代码，希望与它紧密协作，可以选这个入口。IDE 文档。
• Codex Cloud： 为任务提供由 OpenAI 管理的环境，里面包含所需的仓库、工具和访问权限。各个任务拥有独立工作区，即使电脑进入睡眠状态也能继续运行。你可以审查代码改动和测试结果，再提交代码或发起拉取请求。Cloud 文档。

拉取请求（pull request）是一份待审查的修改提案，通过审查后才会并入共享代码库。委派 Bug 修复时，真正有用的交付物就是这样一份可审查的修改，其中应包含受影响的文件、已执行的检查，以及尚未解决的问题。

Codex 的限制来自你提供的环境。如果测试依赖的数据库无法访问，再好的提示词也不能让这项集成测试通过。应要求 Codex 明确区分“测试失败”和“测试无法运行”。

桌面端配置可参考 Codex 应用指南。如果想通过手机处理云端任务，需要先在桌面端或网页端准备并发布环境，之后才能在手机上启动或继续该环境中的任务。OpenAI 对这一点有明确说明。

同一个 Bug，两种工作流程怎么修？

两种流程可能得到相同的代码修正，区别在于谁把修改应用到项目里，并验证它确实有效。 例如下面这个 JavaScript 列表辅助函数：调用方希望不返回任何元素，却拿到了默认数量的元素。

function take(items, limit) {
  return items.slice(0, limit || 25);
}

预期行为很明确：0 表示不返回任何元素；null 或省略 limit 时，使用默认值 25。问题出在 ||，它把零也当成了应该使用默认值的情况。修复方式是改用空值合并运算符 ??，只有遇到 null 或 undefined 才采用默认值：

function take(items, limit) {
  return items.slice(0, limit ?? 25);
}

这是一段用于讲解流程的示例，并非记录在案的产品对照实测。本文已在本地检查原始行为和修正后的用例。这里的数字只是示例输入，不代表产品限制。

用 ChatGPT 修复

把函数和行为约定交给 ChatGPT：“传入零时必须返回空列表。省略 limit 或传入 null 时，应返回默认数量的元素。请解释错误，并给出回归测试。”回归测试用于防止同样的错误再次出现。

借助对话完成的修正，就是上面的函数，再加上下面这组可以在 Node.js 模块中运行的检查：

import assert from 'node:assert/strict';

function take(items, limit) {
  return items.slice(0, limit ?? 25);
}

const items = Array.from({ length: 30 }, (_, index) => index);
assert.deepEqual(take(items, 0), []);
assert.equal(take(items, undefined).length, 25);
assert.equal(take(items, null).length, 25);
assert.deepEqual(take(items, 2), [0, 1]);

还需要人来做的事： 找到生产代码中的辅助函数、应用修改、将检查接入现有测试框架、运行相关测试套件、检查调用方，并准备提交或拉取请求。如果另一个文件会把未提供的 limit 转成零，那么发布修改前，还需要重新确认这里的行为约定。

如果只是一个你已经熟悉的小脚本，这些后续步骤可能很简单。当难点在于理解问题，而应用修正很直接时，ChatGPT 更合适。

用 Codex 修复

在 Codex 中打开仓库，给出相同的行为约定，再补上明确的完成条件：

预期修正仍然是 limit ?? 25。但现在交出去的工作还包括定位实现、检查周边代码的假设、编辑测试文件，以及运行可用的检查。这些是文档明确列出的 Codex 仓库操作与命令执行能力，并不意味着这段提示词每次都能成功。

还需要人来做的事： 判断行为约定是否正确、审查 diff、检查测试证据、解决访问权限或环境障碍，并按正常发布流程批准修改。diff 就是逐行展示代码改动的差异记录。

如果从修正代码走到拿出项目级验证结果，需要反复在聊天窗口、编辑器和终端之间复制内容，那么 Codex 更合适。你留下来的主要工作，是判断修改是否合理、是否已经具备交付条件。

能读取仓库，不代表能完成代码修改

如果访问仓库之后还要编辑和执行代码，Codex 更合适；如果只是调查已连接的代码，ChatGPT 也能帮忙。 OpenAI 的 GitHub 连接功能可以按需获取有权访问的仓库内容，具体可用性取决于套餐和产品入口。文档明确说明，它仅提供用于分析和搜索的只读访问。连接 GitHub，并不会赋予该应用推送代码或发起拉取请求的权限。OpenAI 的 GitHub 指南建议将这类工作交给 Codex。

假设 CTO 想知道某个服务为什么会重试失败请求，这个区别就很重要。查找并解释重试逻辑，ChatGPT 可能已经够用；修改重试策略并检查受影响的行为，则应交给 Codex。

并行任务与拉取请求：边界清楚，Codex 才好发挥

彼此独立、修改可以分别审查的编程任务，适合交给 Codex。 worktree 是同一 Git 仓库的另一个检出目录，让任务拥有自己的一组文件，同时共享仓库历史。OpenAI 的文档明确将 worktree 用于并行工作，以免干扰本地已有的检出目录。参见 Codex worktree 文档。

对于小型软件公司，可以把工作拆成一个范围明确的 Bug 修复、一项失败测试调查，以及另一个模块的文档编写。每项任务都要限定范围，说明预期结果。Codex Cloud 同样为每个任务提供独立工作区，同时允许不同任务复用已配置好的环境。参见云端任务文档。

最容易让并行方案失效的，是任务职责重叠。两个任务同时修改同一份 API 契约，各自的改动可能都看似合理，合在一起却互不兼容。独立工作区能避免任务意外干扰同一份文件，但不能解决设计分歧，也不能保证合并时没有冲突。

合并之前，先分别审查每项结果，再在合并后的分支上运行相应检查。并行工作让你同时获得更多修改方案，但仍需要把它们整合成一个一致的结果。

哪些套餐包含 Codex？用量限制怎么算？

Plus、Pro 和 Business 已经包含 Codex，但套餐内可用不等于任务数量无限。 OpenAI 也在 Free、Go、Enterprise 和教育类方案中列出了 Codex，其中 Free 和 Go 的访问额度有限。Codex Cloud 的适用范围更窄：符合条件的 Plus 账号、所有 Pro 档位，以及 Business、Enterprise、Healthcare 和 Education，具体受开放进度及工作区设置影响；Free 和 Go 不包含 Codex Cloud。参见 OpenAI 套餐访问指南。

ChatGPT Codex 订阅怎么用？先选对登录账号

使用 Sign in with ChatGPT 登录，才会消耗订阅内的用量。如果使用自己的 API 密钥，则走 API 计费。在受管理的工作区中，要确认你的角色已获准使用 Codex Local 和 Codex Cloud；两者的访问控制相互独立。参见 OpenAI 账号与工作区说明。

OpenAI 的价格页面将 Plus 描述为提供更多 Codex 用量，将 Pro 描述为支持更长的会话。页面所说的日常文字聊天不限量，并不等于编程智能体工作不限量。完整的订阅档位可查阅本站的 ChatGPT 价格指南。

Codex 的用量消耗取决于所选模型、任务复杂度、上下文、推理强度、速度、工具，以及任务在哪里运行。在适用套餐中，Work 和其他符合条件的智能体功能可能共享额度或积分池。可在设置或用量面板中查看额度、积分和重置时间；CLI 中可以使用 /status。符合条件的 Plus 和 Pro 用户可以购买额外积分。参见 Codex 用量说明。

普通 Chat 有自己的模型和工具限制。Thinking 是否可用、触限后如何回退，取决于套餐和模型；订阅 Pro 也不代表可以无限使用 Pro 模型。参见 Chat 模型限制。

实际选择时，应先决定工作流程，再关注它的真实可用额度。一次简短解释和一项需要反复运行测试的仓库任务，工作量完全不同。用“每天能修多少个 Bug”这样的固定数字来承诺用量，会掩盖这种差异。

Codex 和 ChatGPT 分别用什么模型？

两款产品都不对应某个固定模型，而且选了某个模型，并不会自动获得仓库操作工具。 模型是否可用，还取决于账号、客户端、工作区设置和开放进度。

在普通 ChatGPT 中，OpenAI 文档列出的 GPT-6 选项面向符合条件的付费账号；在可用的情况下，从 Instant 到 Extra High 的各个思考档位由 GPT-6 Sol 支撑。Pro 推理档位使用 GPT-6 Pro，底层由 GPT-6 Astra 驱动。符合条件的账号仍可选择 GPT-5.6 Sol 和 GPT-5.6 Sol Pro。这些都是 Chat 中的名称和控制选项。参见 ChatGPT 模型文档。

对于 Codex，当前文档列出了 GPT-6.1 Sol、GPT-6 Astra、GPT-6 Sol 和 GPT-6 Luna，以及在逐步开放期间提供的 GPT-5.6 Sol、GPT-5.6 Terra 和 GPT-5.6 Luna。文档建议在可用时选择 GPT-6.1 Sol 处理复杂编程，选择 Luna 处理范围集中的任务。CLI 中可通过 /model 选择模型和推理强度；默认设置取决于客户端版本和配置。参见 Codex 模型文档。

这些名称容易让人混淆：Chat 中的 GPT-6 可以由 Sol 驱动，而 Codex 则直接列出带有 Sol 名称的模型，供智能体使用。GPT-6.1 Sol 是 Work/Codex 的选项，与普通 Chat 中的 GPT-6 选项分开。不要以为切换使用模式后，模型菜单也会完全相同。

回到前面的 Bug 示例，决定性能力是能否访问实现代码及其测试。对话里的模型即使更强，也仍然需要合适的工具和环境，才能真正修改仓库。

要从 ChatGPT 转到 Codex 吗？

当实现代码成了瓶颈，就把 Codex 加入工作流程；只需理解问题的任务，继续用 ChatGPT。 不必迁移每一段对话，也不必放弃已经适合部分工作的助手。

前期准备很具体：选定项目、配置依赖、确认测试命令，并决定任务需要哪些访问权限。云端工作则需要先准备环境，再委派问题。这些步骤能把一句“修好这个 Bug”变成可以检查结果的工作。

Codex 和 ChatGPT 的历史记录是分开的。应把重要决定整理成简短的任务说明，包括预期行为、约束条件、相关文件和验收检查。不要假定换一个使用模式，之前的讨论就会自动出现在那里。参见 OpenAI 关于历史记录与使用模式的说明。

把需要长期保留的知识放进仓库：测试、行为说明，以及审查后的修改。这样，其他开发者或工具就有可靠的接手起点，无需依赖某一段聊天记录。

如果还没确定软件应该做什么、无法提供可用的项目环境，或没有办法评估结果，先别把任务转到 Codex。先说清预期行为。如果你要比较的是 Codex 与另一款编程智能体，而不是普通聊天，可以阅读 Codex 与 Claude Code 对比。

下次遇到 Bug，在打开任何工具之前，先写下出错的输入和预期输出。如果解释清楚就能完成任务，用 ChatGPT；如果接下来需要查找、修改和检查项目文件，用 Codex。

常见问题

获取 Claude Code 与 Codex 配置清单，按一套可复用的步骤准备首个任务。