1. 引言：为什么要把 ChatGPT Plus / Pro 与 Codex 组合使用

2026 年，AI 辅助编程已经不再是「能不能用」的问题，而是「怎么用得更好」的问题。ChatGPT Plus 与 Pro 订阅提供了强大的对话式推理能力，而 Codex 则把这种能力延伸到真实的代码仓库与终端环境之中。两者组合，构成了一条从需求分析、架构设计、代码生成、自动测试到部署运维的完整 AI 工作流。

本文不讨论任何充值或账号获取相关内容，而是聚焦于技术本身：如何利用 ChatGPT Plus / Pro 的模型能力（包括 GPT-5 系列、高级数据分析、联网检索、自定义 GPTs），配合 Codex 的云端沙箱与本地 CLI，搭建一套可复用的 AI 辅助开发流水线。

在开始之前，先明确本文的适用读者：

• 已经拥有 ChatGPT Plus 或 Pro 订阅的开发者；
• 希望用 Codex 处理真实工程任务（而非玩具示例）的工程师；
• 对 MCP（模型上下文协议）、自动化测试、CI/CD 集成感兴趣的技术爱好者。

2. 环境准备：ChatGPT 订阅层级与 Codex 的对应关系

2.1 Plus 与 Pro 的能力边界

ChatGPT Plus 与 Pro 在模型访问权限上存在差异，这直接影响 Codex 的使用体验。Plus 用户通常可以访问标准版 GPT-5 模型，并享有中等额度的 Codex 使用配额；Pro 用户则能解锁更高频次的 Codex 任务执行、更长的上下文窗口以及优先访问实验性功能的权利。

需要强调的是，这里的「额度」指的是 API 或 Codex 平台上的任务执行次数限制，而非充值概念。作为技术作者，我们更应关注的是：不同层级下，Codex 的「任务复杂度上限」有何不同。

2.2 Codex 的两种使用形态

Codex 目前主要有两种使用方式：

1. 云端 Codex 界面：在 ChatGPT 网页端或桌面端直接打开 Codex，它会创建一个独立的云端沙箱环境，可以访问你授权的 GitHub 仓库，并在沙箱中执行命令、读写文件。
2. 本地 Codex CLI：通过命令行工具 codex 在本地终端中运行，Codex 会读取本地文件系统，并调用云端模型进行推理。这种方式更适合与现有的 Git 工作流、IDE 深度集成。

两种形态共享底层的模型推理能力，但权限模型不同。云端沙箱默认隔离，本地 CLI 则拥有你当前用户权限下的文件访问能力，因此使用时需要格外注意安全边界。

2.3 安装 Codex CLI

如果你选择本地 CLI 方式，安装过程非常简单。假设你的开发机是 macOS 或 Linux，可以使用以下命令：

# 安装 Codex CLI（假设使用 npm 全局安装）
npm install -g @openai/codex

# 验证安装
codex --version

# 登录（会打开浏览器完成 OAuth 授权）
codex login

安装完成后，你可以通过 codex init 在当前目录生成配置文件，指定要使用的模型、是否允许 Codex 自动执行命令等。

3. 核心工作流：从需求到 Pull Request 的完整闭环

3.1 工作流总览

将 ChatGPT Plus / Pro 与 Codex 组合使用的核心价值，在于把「对话式需求分析」与「自动化代码执行」衔接起来。下面用一张 Mermaid 流程图展示推荐的工作流：

3.2 需求澄清阶段（ChatGPT Plus / Pro）

在实际编码之前，先用 ChatGPT 进行需求澄清是提高成功率的关键。你可以把原始需求粘贴给 ChatGPT，并要求它输出结构化的需求文档。下面是一个提示词模板：

你是一位资深技术负责人。请根据以下原始需求，输出一份结构化的开发任务书，包含：
1. 功能需求列表（用 Markdown 表格列出优先级）
2. 非功能需求（性能、安全、可维护性）
3. 技术选型建议（结合当前主流方案）
4. 潜在的边界情况与异常处理点
5. 建议的 Git 分支策略

原始需求如下：
[在这里粘贴你的原始需求]

3.3 代码生成阶段（Codex）

当需求文档就绪后，切换到 Codex 执行编码任务。在本地 CLI 中，你可以这样启动一个编码会话：

# 进入项目目录
cd ~/projects/my-awesome-app

# 启动 Codex 交互式会话
codex

在 Codex 的交互提示符中，你可以输入类似下面的指令：

请根据 docs/requirements.md 中的需求文档，实现用户认证模块。
要求：
1. 使用 Python 3.12 + FastAPI
2. 使用 SQLAlchemy 2.0 异步模式
3. 密码使用 bcrypt 哈希存储
4. 实现 JWT 访问令牌与刷新令牌
5. 编写 pytest 单元测试，覆盖率不低于 85%
6. 遵循项目现有的代码风格（参考 src/ 目录下的现有模块）

Codex 会读取仓库中的相关文件，理解现有代码风格，然后生成实现代码。它会自动创建新文件、修改现有文件，并运行测试验证结果。

4. 实战案例：用 Codex 构建一个异步任务队列服务

4.1 项目背景

假设我们要为现有的 Web 服务增加一个异步任务队列，用于处理邮件发送、图片缩略图生成等耗时操作。技术栈选定为：

• Python 3.12
• FastAPI（Web 框架）
• Celery（任务队列）
• Redis（Broker 与结果后端）
• Docker Compose（本地开发环境）

4.2 让 Codex 生成项目骨架

在 Codex 中执行以下指令：

在当前目录下初始化一个异步任务队列服务项目，结构如下：
- app/main.py：FastAPI 入口，提供 /health 健康检查接口
- app/tasks.py：Celery 任务定义，包含 send_email 和 generate_thumbnail 两个任务
- app/celery_app.py：Celery 实例配置
- tests/test_tasks.py：针对任务的单元测试
- docker-compose.yml：包含 redis 与 worker 服务
- requirements.txt：项目依赖
- README.md：简要说明如何启动项目

Codex 会生成如下所示的文件结构：

.
├── app
│   ├── __init__.py
│   ├── celery_app.py
│   ├── main.py
│   └── tasks.py
├── tests
│   ├── __init__.py
│   └── test_tasks.py
├── docker-compose.yml
├── README.md
└── requirements.txt

4.3 关键代码解读

Codex 生成的 app/celery_app.py 可能如下所示：

# app/celery_app.py
from celery import Celery

celery_app = Celery(
    "worker",
    broker="redis://localhost:6379/0",
    backend="redis://localhost:6379/0",
    include=["app.tasks"],
)

celery_app.conf.update(
    task_serializer="json",
    accept_content=["json"],
    result_serializer="json",
    timezone="Asia/Shanghai",
    enable_utc=True,
    task_track_started=True,
    task_time_limit=30 * 60,
    task_soft_time_limit=25 * 60,
)

而 app/tasks.py 中定义了具体的异步任务：

# app/tasks.py
import time
from typing import Dict

from app.celery_app import celery_app


@celery_app.task(bind=True, max_retries=3, default_retry_delay=5)
def send_email(self, recipient: str, subject: str, body: str) -> Dict[str, str]:
    """模拟发送邮件，失败时自动重试。"""
    try:
        # 实际项目中这里会调用真实的邮件服务
        time.sleep(2)
        if "fail" in recipient:
            raise ValueError("模拟发送失败")
        return {"status": "sent", "recipient": recipient}
    except Exception as exc:
        raise self.retry(exc=exc)


@celery_app.task
def generate_thumbnail(image_path: str, size: tuple = (128, 128)) -> str:
    """生成图片缩略图（示意实现）。"""
    # 实际项目中这里会调用 Pillow 等图像库
    thumbnail_path = f"{image_path}.thumb_{size[0]}x{size[1]}.jpg"
    return thumbnail_path

4.4 测试与验证

Codex 还会生成对应的测试文件：

# tests/test_tasks.py
from app.tasks import generate_thumbnail, send_email


def test_send_email_success():
    result = send_email.run("user@example.com", "Hello", "World")
    assert result["status"] == "sent"


def test_generate_thumbnail():
    result = generate_thumbnail.run("/tmp/photo.jpg", (64, 64))
    assert result.endswith("thumb_64x64.jpg")

在 Codex 中继续输入：

请运行 pytest 执行测试，并修复所有失败用例。

Codex 会自动执行 pytest，读取失败信息，定位问题并修复代码，直到测试全部通过。

5. 进阶技巧：让 ChatGPT 与 Codex 协同处理复杂重构

5.1 跨文件重构的策略

当重构涉及多个文件、且需要保持行为一致时，纯靠 Codex 单轮生成容易遗漏边界情况。此时推荐的做法是：

1. 用 ChatGPT 分析依赖关系：把关键文件的代码粘贴给 ChatGPT，要求它输出「影响面分析」，列出所有引用点。
2. 用 Codex 分步执行：将重构拆分为多个小步骤，每一步都让 Codex 执行并运行测试。
3. 人工 Code Review：最后用 git diff 检查所有改动，确认没有意外修改。

5.2 利用自定义 GPTs 固化团队规范

如果你所在团队有特定的代码规范（如提交信息格式、异常处理方式），可以在 ChatGPT Plus / Pro 中创建一个自定义 GPT，把规范写入 Instructions。然后在 Codex 中引用该 GPT 的输出来指导编码。

例如，你可以创建一个「代码规范审查员」GPT，它的 Instructions 包含：

你是一位严格的代码审查员。当收到代码片段时，请检查：
1. 是否所有函数都有类型注解？
2. 是否所有外部输入都经过校验？
3. 是否有重复代码可以抽取为公共函数？
4. 日志是否包含足够的上下文信息（如 request_id）？
5. 是否有明显的性能问题（如 N+1 查询）？

请以 Markdown 表格输出审查结果，并给出修改建议。

5.3 处理长上下文任务

当任务涉及大量文件时，Codex 的上下文窗口可能不够用。此时可以先用 ChatGPT 的「高级数据分析」功能对代码库进行预处理，生成一份精简的「代码地图」，再交给 Codex 执行。

下面是一个生成代码地图的提示词：

请分析以下项目文件列表与核心模块的职责，输出一份 Markdown 格式的代码地图。
要求：
- 按模块分组
- 标注每个模块的入口文件与主要函数
- 标注模块之间的依赖关系（用箭头表示）
- 标注可能的扩展点

项目文件列表：
[在这里粘贴文件树]

6. 自动化集成：把 Codex 接入 CI/CD 流水线

6.1 使用 Codex CLI 的非交互模式

除了交互式会话，Codex CLI 还支持非交互模式，适合在 CI 中调用。基本用法如下：

# 非交互模式执行单个任务
codex exec "修复 tests/test_api.py 中所有失败的测试，并确保不破坏其他测试"

# 指定输出文件
codex exec "为 src/utils.py 中的 parse_date 函数补充完整的 docstring" --output docstring_result.md

6.2 GitHub Actions 集成示例

下面是一个将 Codex 集成到 GitHub Actions 的示例工作流，当 PR 被标记为 codex-review 时自动触发代码审查：

# .github/workflows/codex-review.yml
name: Codex Auto Review

on:
  pull_request:
    types: [labeled]

jobs:
  codex-review:
    if: contains(github.event.pull_request.labels.*.name, 'codex-review')
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: "20"

      - name: Install Codex CLI
        run: npm install -g @openai/codex

      - name: Run Codex Review
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
        run: |
          codex exec "请审查本次 PR 的代码改动，重点关注：
          1. 是否存在安全漏洞（SQL 注入、XSS、硬编码密钥）
          2. 是否有明显的逻辑错误
          3. 测试覆盖是否充分
          4. 代码风格是否与项目一致
          请输出 Markdown 格式的审查报告。" > review_report.md

      - name: Upload Review Report
        uses: actions/upload-artifact@v4
        with:
          name: codex-review-report
          path: review_report.md

6.3 安全注意事项

将 Codex 接入 CI 时，务必注意：

• 使用最小权限的 API Key，仅授予当前仓库的读取权限；
• 在沙箱环境中运行 Codex，避免其访问敏感的生产环境变量；
• 对 Codex 生成的代码进行人工审查后再合并；
• 设置任务超时时间，避免 Codex 陷入无限循环。

7. 常见问题与排查技巧

7.1 Codex 无法访问本地文件

如果你在本地 CLI 中发现 Codex 无法读取某些文件，请检查：

# 查看当前 Codex 的权限配置
codex config list

# 检查是否在项目根目录启动
pwd

# 检查 .gitignore 是否忽略了相关目录
cat .gitignore

7.2 模型输出与预期不符

当 Codex 生成的代码偏离需求时，不要直接否定，而是尝试：

1. 在对话中补充更多约束条件；
2. 提供「反例」——明确指出你不想要什么；
3. 把大任务拆分为小任务，逐步确认。

7.3 测试一直失败

如果 Codex 反复修复但测试仍然失败，可能是测试本身存在问题。此时可以让 ChatGPT 分析测试代码：

以下测试用例反复失败，请分析是测试代码的问题还是被测代码的问题。
如果是测试代码的问题，请指出具体哪一行断言不合理；
如果是被测代码的问题，请指出可能的逻辑缺陷。

[粘贴测试代码与失败日志]

8. 总结与展望

ChatGPT Plus / Pro 与 Codex 的组合，本质上是一种「人机协同」的新的工程范式。ChatGPT 负责深度推理与方案设计，Codex 负责在真实环境中执行与验证，而开发者则站在更高维度进行决策与审查。

随着模型能力的持续进化，这种工作流的边界会不断扩展。但有一点不会改变：清晰的需求表达、合理的任务拆解、严格的验证闭环，始终是高质量 AI 辅助开发的核心。希望本文的实战案例与技巧能帮助你构建属于自己的高效工作流。