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 支持两种工作区：
- 云端沙箱（默认）：所有操作在云端容器里完成，不占用本地资源。
- 本地连接（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 的工作流程
- Clone 仓库到云端沙箱
- 阅读项目结构和相关代码
- 定位到
order.py中的竞态条件——一个共享的dict在多个协程间被并发读写 - 用
asyncio.Lock修复 - 写一个用
asyncio.gather模拟 100 个并发请求的测试 - 运行测试，确认修复有效
- 提交代码并推送，甚至可以直接创建 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 开发代理。
给你的行动建议：
- 第一个任务：让 Codex 从零搭建一个你熟悉的小项目，感受它的工作流。
- 第二个任务：把一个你手头真实的、有 Bug 的项目交给它，看它如何定位和修复。
- 第三个任务：在项目里加上
AGENTS.md，让 Codex 成为真正懂你规范的团队成员。
Codex 不会取代程序员，但它会取代"复制粘贴到聊天窗口再手动跑"这种低效工作方式。把它用起来，你会发现 Plus / Pro 的订阅价值远超你的预期。