ChatGPT Plus / Pro 开通后，Codex 才是真正的生产力入口：从零到实战的完整玩法

1. 引言：为什么开通 Plus / Pro 之后，第一件事是打开 Codex

很多人在开通 ChatGPT Plus 或 Pro 之后，第一反应是去聊天窗口里问几个问题、生成几段文案，然后就没有然后了。但如果你订阅的是 Plus 或 Pro，真正拉开差距的其实是那个藏在界面角落里的 Codex——一个能直接操作代码仓库、执行命令、读写文件的 AI 编程代理。

Codex 不是简单的"聊天窗口里写代码"，而是一个运行在云端沙箱里的自主代理。它有自己的文件系统、终端、甚至能访问你的 GitHub 仓库。这意味着你可以把"写代码"这件事从"复制粘贴到本地再手动跑"变成"直接让 AI 在云端把活干完"。

这篇文章面向的是已经熟悉编程、但还没深入用过 Codex 的用户。我们不谈充值、不谈订阅价格，只谈一件事：开通之后，Codex 到底能怎么玩出生产力。

2. Codex 到底是什么：不是聊天窗口，是云端开发环境

2.1 核心架构

Codex 的本质是一个运行在云端容器里的 AI 代理。它和普通 ChatGPT 对话的最大区别在于：

• 有持久化的文件系统：Codex 可以在云端创建、修改、删除文件，这些文件在会话之间保留。
• 有终端执行能力：它可以运行 shell 命令、安装依赖、执行测试、启动服务。
• 有 Git 集成：可以直接 clone 仓库、创建分支、提交代码、甚至发起 Pull Request。
• 有上下文窗口管理：Codex 会自动读取项目结构、搜索相关文件，而不是像聊天窗口那样只能靠你手动粘贴。

2.2 和 ChatGPT 对话的区别

能力	ChatGPT 对话	Codex
生成代码片段	✅	✅
读写本地文件	❌	✅（云端沙箱）
执行命令	❌	✅
运行测试	❌	✅
操作 Git 仓库	❌	✅
自主规划多步任务	有限	✅

简单说：ChatGPT 对话是"顾问"，Codex 是"外包工程师"。

3. 第一次打开 Codex：界面与工作区

3.1 入口

在 ChatGPT 网页端左侧边栏找到 Codex 图标（一个终端样式的图标），点击进入。你会看到一个类似 IDE 的界面，左侧是文件树，中间是对话/任务面板，右侧是终端输出。

3.2 工作区模式

Codex 支持两种工作区：

1. 云端沙箱（默认）：所有操作在云端容器里完成，不占用本地资源。
2. 本地连接（Beta）：通过 CLI 工具连接本地目录，Codex 直接操作你本地的文件。

对于日常开发，云端沙箱足够；对于需要和本地环境联调的项目，用本地连接模式。

3.3 第一个任务

在输入框里输入：

创建一个 Python 项目，包含一个 FastAPI 服务，提供 /health 和 /hello 两个接口，并写好测试。

Codex 会自主完成：

• 创建项目目录结构
• 生成 main.py、requirements.txt、test_main.py
• 安装依赖
• 运行测试并报告结果

整个过程你只需要观察和确认，不需要手动敲一行代码。

4. 实战一：用 Codex 从零搭建一个完整的 Web 服务

4.1 任务描述

我们让 Codex 搭建一个带数据库的待办事项 API，使用 FastAPI + SQLite + SQLAlchemy。

4.2 提示词

创建一个 FastAPI 待办事项应用：
1. 使用 SQLite 数据库，通过 SQLAlchemy ORM 操作
2. 提供 GET /todos、POST /todos、DELETE /todos/{id} 三个接口
3. 数据模型包含 id、title、completed、created_at 字段
4. 使用 Pydantic 做请求体校验
5. 写好 pytest 测试，覆盖三个接口
6. 最后运行测试并展示结果

4.3 Codex 生成的代码（示例）

Codex 会生成类似下面的项目结构：

todo-app/
├── app/
│   ├── __init__.py
│   ├── main.py
│   ├── models.py
│   ├── schemas.py
│   └── database.py
├── tests/
│   └── test_todos.py
├── requirements.txt
└── README.md

核心文件 app/main.py：

from fastapi import FastAPI, Depends, HTTPException
from sqlalchemy.orm import Session
from . import models, schemas
from .database import SessionLocal, engine

models.Base.metadata.create_all(bind=engine)

app = FastAPI(title="Todo API")

def get_db():
    db = SessionLocal()
    try:
        yield db
    finally:
        db.close()

@app.get("/todos", response_model=list[schemas.Todo])
def list_todos(db: Session = Depends(get_db)):
    return db.query(models.Todo).all()

@app.post("/todos", response_model=schemas.Todo)
def create_todo(todo: schemas.TodoCreate, db: Session = Depends(get_db)):
    db_todo = models.Todo(title=todo.title)
    db.add(db_todo)
    db.commit()
    db.refresh(db_todo)
    return db_todo

@app.delete("/todos/{todo_id}")
def delete_todo(todo_id: int, db: Session = Depends(get_db)):
    todo = db.query(models.Todo).filter(models.Todo.id == todo_id).first()
    if not todo:
        raise HTTPException(status_code=404, detail="Todo not found")
    db.delete(todo)
    db.commit()
    return {"ok": True}

4.4 关键点

• Codex 会自动安装依赖并运行 pytest，把测试结果直接展示给你。
• 如果测试失败，它会读取错误信息、修复代码、重新运行，直到通过。
• 你不需要把代码复制到本地，云端沙箱里已经跑通了。

5. 实战二：让 Codex 修复一个真实 Bug

5.1 场景

你有一个本地项目，某个接口在并发请求下会偶发 500 错误。你把项目推送到 GitHub，然后让 Codex 分析。

5.2 提示词

clone 这个仓库：https://github.com/yourname/your-repo.git
然后分析为什么 /api/order 接口在并发下会偶发 500 错误。
找到根因，修复它，并写一个并发测试来验证修复有效。

5.3 Codex 的工作流程

1. Clone 仓库到云端沙箱
2. 阅读项目结构和相关代码
3. 定位到 order.py 中的竞态条件——一个共享的 dict 在多个协程间被并发读写
4. 用 asyncio.Lock 修复
5. 写一个用 asyncio.gather 模拟 100 个并发请求的测试
6. 运行测试，确认修复有效
7. 提交代码并推送，甚至可以直接创建 PR

修复后的代码片段：

import asyncio
from fastapi import APIRouter

router = APIRouter()
_order_lock = asyncio.Lock()
_order_store = {}

@router.post("/api/order")
async def create_order(order_id: str):
    async with _order_lock:
        # 原来的并发写操作现在被锁保护
        _order_store[order_id] = {"status": "created"}
        await asyncio.sleep(0.01)  # 模拟耗时操作
        return _order_store[order_id]

5.4 价值

这个场景的价值在于：Codex 不只是"写代码"，它能理解项目上下文、定位问题、修复并验证。这已经接近一个初级工程师的完整工作流。

6. 实战三：用 Codex 做代码重构与迁移

6.1 场景

你有一个用 Python 写的脚本，需要迁移到 TypeScript，并且要拆分模块、补充类型定义。

6.2 提示词

把当前项目里的 utils.py 迁移到 TypeScript：
1. 保持原有函数逻辑不变
2. 拆分成多个模块文件
3. 补充完整的 TypeScript 类型定义
4. 写单元测试
5. 用 tsc 编译验证没有类型错误

6.3 结果

Codex 会生成：

src/
├── types.ts
├── stringUtils.ts
├── arrayUtils.ts
├── dateUtils.ts
└── index.ts
tests/
├── stringUtils.test.ts
└── arrayUtils.test.ts

并自动运行 tsc --noEmit 和测试，确保迁移后代码质量达标。

7. 进阶技巧：让 Codex 更懂你的项目

7.1 使用 AGENTS.md 项目说明文件

在项目根目录创建 AGENTS.md，Codex 会自动读取它来理解项目约定：

# 项目约定

- 使用 Python 3.11+
- 代码风格遵循 Black + isort
- 所有接口必须返回统一格式：{"code": 0, "data": ..., "msg": "ok"}
- 测试使用 pytest，覆盖率不低于 80%
- 数据库迁移使用 Alembic

这样 Codex 生成的代码会自动符合你的团队规范。

7.2 分步确认模式

对于复杂任务，不要一次给太多指令。分步进行：

第一步：先分析项目结构，列出你理解的模块职责。
第二步：基于分析结果，给出重构方案。
第三步：确认方案后，再开始改代码。

7.3 让 Codex 先写测试再写实现

先为这个函数写完整的单元测试，覆盖正常、边界、异常三种情况。
测试写好后，再实现函数让测试通过。

这种 TDD 模式能让 Codex 产出更可靠的代码。

7.4 善用 /commands 快捷指令

Codex 内置了一些快捷指令：

• /fix：让 Codex 修复当前选中的代码问题
• /explain：解释当前代码的逻辑
• /review：对当前改动做代码审查
• /test：为当前代码生成测试

8. 常见坑与避坑指南

8.1 云端沙箱的局限性

• 沙箱有资源限制，超大项目（几十 GB）可能跑不动。
• 网络受限，某些内网服务无法访问。
• 沙箱环境是临时的，虽然文件会保留，但建议重要成果推送到 Git 仓库。

8.2 提示词太模糊

❌ 错误示范：

帮我优化这个项目

✅ 正确示范：

优化 src/utils.py 中的 parse_date 函数：
1. 当前实现用正则解析，性能差
2. 改用 datetime.fromisoformat
3. 保持对 "2024-01-01" 和 "2024-01-01T10:30:00" 两种格式的兼容
4. 补充边界测试

8.3 不要让它直接操作生产环境

Codex 的本地连接模式可以操作你的本地文件，但不要让它直接连接生产数据库或执行生产环境的破坏性命令。把它当作"开发环境助手"，而不是"运维机器人"。

9. 总结：Codex 的正确打开方式

开通 Plus / Pro 之后，Codex 才是那个真正把订阅价值放大的功能。它不是聊天窗口的替代品，而是一个能自主完成"理解需求 → 写代码 → 跑测试 → 修 Bug → 提交"完整闭环的 AI 开发代理。

给你的行动建议：

1. 第一个任务：让 Codex 从零搭建一个你熟悉的小项目，感受它的工作流。
2. 第二个任务：把一个你手头真实的、有 Bug 的项目交给它，看它如何定位和修复。
3. 第三个任务：在项目里加上 AGENTS.md，让 Codex 成为真正懂你规范的团队成员。

Codex 不会取代程序员，但它会取代"复制粘贴到聊天窗口再手动跑"这种低效工作方式。把它用起来，你会发现 Plus / Pro 的订阅价值远超你的预期。