摘要

本文面向程序员、AI 工具使用者与软件开发团队，系统梳理 ChatGPT Plus、ChatGPT Pro 与 Codex 在真实软件开发流程中的定位与配合方式。文章从工具能力边界出发，给出可落地的 AI 编程工作流，并以一个 FastAPI 任务管理项目为例，演示如何借助 Codex 完成需求分析、代码修改、测试补充与持续集成检查。同时提供多套可直接复用的 Codex 提示词模板，以及常见错误、安全与隐私注意事项。读者可以据此建立一套安全、可控、可验证的 AI 辅助开发流程。

目录

• 一、为什么开发者需要区分 ChatGPT 与 Codex
• 二、ChatGPT Plus、ChatGPT Pro 与 Codex 的技术定位
• 三、一套可控的 AI 编程工作流
• 四、实战项目：使用 Codex 辅助维护一个 Python API 项目
• 五、给 Codex 的高质量任务提示词
• 六、ChatGPT Plus / Pro + Codex 的协同方式
• 七、常见错误与解决方法
• 八、安全与隐私
• 九、总结

一、为什么开发者需要区分 ChatGPT 与 Codex

在日常开发中，很多开发者习惯把“AI 编程”等同于“打开聊天窗口，让 AI 写一段代码”。这种理解在简单脚本场景下可行，但一旦进入真实项目，就会遇到上下文缺失、修改范围失控、测试无法通过等问题。

ChatGPT 与 Codex 是两类不同的工具。ChatGPT 擅长对话式推理，适合需求梳理、方案讨论、代码解释和知识问答。它面对的是对话上下文，而不是完整的代码仓库。Codex 则面向仓库级任务，能够读取项目结构、定位相关文件、在受限范围内修改代码，并执行测试与命令。

两者的核心差异在于“上下文边界”。ChatGPT 的上下文来自对话内容与用户粘贴的代码片段；Codex 的上下文来自整个 Git 仓库、文件树、命令执行结果与测试输出。因此，不能只靠一句“帮我写代码”就期望 Codex 自动完成所有工作。仓库上下文、测试要求和任务边界，决定了 AI 修改的质量与安全性。

二、ChatGPT Plus、ChatGPT Pro 与 Codex 的技术定位

下表从开发场景出发，对比 ChatGPT Plus、ChatGPT Pro 与 Codex 的定位差异。具体可用功能、模型版本与额度以当前官方页面为准，不同账号、地区或版本可能存在差异。

工具或方案	主要定位	适合任务	输入信息	输出结果	使用风险
ChatGPT Plus	通用对话与推理	需求梳理、架构讨论、代码解释、文档撰写	对话文本、粘贴的代码片段	文本回答、代码片段、方案建议	上下文有限，可能遗漏项目细节
ChatGPT Pro	高强度对话与深度推理	复杂问题拆解、长文档分析、多轮技术讨论	对话文本、长文档、多轮上下文	结构化分析、方案对比、详细解释	不直接操作仓库，需人工落地
Codex	仓库级编码代理	阅读项目、定位文件、修改代码、运行测试	Git 仓库、文件树、命令执行结果	代码修改、测试输出、差异汇总	修改范围失控、破坏原有逻辑

需要说明的是，ChatGPT 订阅服务与 OpenAI API 属于不同的使用体系。订阅服务主要面向产品内的对话与工具能力，API 则面向开发者按调用量计费。本文重点讨论技术工作流，不对动态额度作固定承诺。

三、一套可控的 AI 编程工作流

要让 Codex 安全地参与开发，不能直接让它“放开改”。下面是一套经过实践检验的流程。

第一步是明确需求。需求必须具体、可验证，例如“为任务接口增加优先级字段，支持按优先级筛选”。模糊的需求会导致 AI 自行猜测，产生不符合预期的修改。

第二步是阅读项目。让 Codex 先分析目录结构、数据模型、路由与测试文件，理解现有逻辑后再动手。跳过这一步，AI 很可能修改错误的文件。

第三步是制定修改计划。要求 Codex 输出将要修改的文件、改动内容与影响范围，由开发者确认后再执行。

第四步是创建独立 Git 分支。分支隔离了 AI 的改动，便于回滚与审查。

第五步到第七步是修改、测试与验证。Codex 修改代码后，必须补充或更新测试，并运行完整测试套件。测试通过是合并的前提。

第八步是查看代码差异。开发者需要检查 git diff，确认没有无关文件被修改。

第九步是人工审查。AI 的解释不能替代人工判断，开发者要逐行检查逻辑、安全与边界条件。

最后一步是合并代码。合并前确保测试通过、审查完成、无敏感信息泄露。

四、实战项目：使用 Codex 辅助维护一个 Python API 项目

下面通过一个任务管理 API 项目，演示 Codex 在真实开发流程中的用法。项目需求是：为现有任务管理 API 增加任务优先级字段，并支持按照优先级筛选，同时补充单元测试和持续集成检查。

4.1 项目目录

task-api/
├── app/
│   ├── __init__.py
│   ├── main.py
│   ├── models.py
│   └── service.py
├── tests/
│   └── test_tasks.py
├── pyproject.toml
└── .github/
    └── workflows/
        └── test.yml

4.2 环境准备

以下命令在项目根目录执行。首先创建虚拟环境并激活：

python3.11 -m venv .venv
source .venv/bin/activate

安装依赖：

pip install "fastapi" "uvicorn" "pydantic" "pytest" "httpx"

启动项目：

uvicorn app.main:app --reload

运行测试：

pytest -q

4.3 核心业务代码

数据模型定义在 app/models.py：

from enum import Enum
from pydantic import BaseModel, Field


class Priority(str, Enum):
    low = "low"
    medium = "medium"
    high = "high"


class Task(BaseModel):
    id: int
    title: str
    priority: Priority = Priority.medium


class TaskCreate(BaseModel):
    title: str = Field(..., min_length=1, max_length=200)
    priority: Priority = Priority.medium

业务逻辑放在 app/service.py：

from app.models import Task, TaskCreate, Priority


class TaskService:
    def __init__(self) -> None:
        self._tasks: dict[int, Task] = {}
        self._next_id = 1

    def create(self, payload: TaskCreate) -> Task:
        task = Task(id=self._next_id, title=payload.title, priority=payload.priority)
        self._tasks[task.id] = task
        self._next_id += 1
        return task

    def list_by_priority(self, priority: Priority | None = None) -> list[Task]:
        tasks = list(self._tasks.values())
        if priority is not None:
            tasks = [t for t in tasks if t.priority == priority]
        return tasks

API 路由定义在 app/main.py：

from fastapi import FastAPI, HTTPException, Query

from app.models import Priority, Task, TaskCreate
from app.service import TaskService

app = FastAPI()
service = TaskService()


@app.post("/tasks", response_model=Task, status_code=201)
def create_task(payload: TaskCreate) -> Task:
    return service.create(payload)


@app.get("/tasks", response_model=list[Task])
def list_tasks(priority: Priority | None = Query(default=None)) -> list[Task]:
    return service.list_by_priority(priority)


@app.get("/tasks/{task_id}", response_model=Task)
def get_task(task_id: int) -> Task:
    task = service._tasks.get(task_id)
    if task is None:
        raise HTTPException(status_code=404, detail="task not found")
    return task

4.4 自动化测试

测试文件 tests/test_tasks.py 覆盖正常创建、默认优先级、非法优先级、按优先级筛选、空结果与原有功能：

import pytest
from fastapi.testclient import TestClient

from app.main import app

client = TestClient(app)


def setup_function() -> None:
    from app.main import service
    service._tasks.clear()
    service._next_id = 1


def test_create_task() -> None:
    resp = client.post("/tasks", json={"title": "write report"})
    assert resp.status_code == 201
    data = resp.json()
    assert data["title"] == "write report"
    assert data["priority"] == "medium"


def test_default_priority_is_medium() -> None:
    resp = client.post("/tasks", json={"title": "default"})
    assert resp.json()["priority"] == "medium"


def test_invalid_priority_rejected() -> None:
    resp = client.post("/tasks", json={"title": "bad", "priority": "urgent"})
    assert resp.status_code == 422


def test_filter_by_priority() -> None:
    client.post("/tasks", json={"title": "a", "priority": "high"})
    client.post("/tasks", json={"title": "b", "priority": "low"})
    resp = client.get("/tasks", params={"priority": "high"})
    data = resp.json()
    assert len(data) == 1
    assert data[0]["title"] == "a"


def test_filter_empty_result() -> None:
    resp = client.get("/tasks", params={"priority": "high"})
    assert resp.json() == []


def test_get_missing_task_returns_404() -> None:
    resp = client.get("/tasks/999")
    assert resp.status_code == 404

测试是使用 Codex 修改代码时的重要安全边界。没有测试，AI 的改动是否正确只能靠人工猜测；有了测试，任何破坏原有逻辑的修改都会在合并前被拦截。

4.5 持续集成配置

.github/workflows/test.yml 内容如下：

name: test

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.11"
      - run: pip install "fastapi" "uvicorn" "pydantic" "pytest" "httpx"
      - run: pytest -q

4.6 查看并审查修改

Codex 完成修改后，开发者应执行以下命令：

git status
git diff
git diff --stat
git log --oneline -5
pytest -q

审查时重点检查：是否修改了无关文件、是否删除了原有逻辑、是否引入新的依赖、是否存在硬编码、是否遗漏异常处理、是否存在安全风险、测试是否真正覆盖需求。

五、给 Codex 的高质量任务提示词

模板一：分析项目，不修改代码

请阅读当前仓库的项目结构，找出与任务管理 API 相关的文件，说明数据模型、路由与业务逻辑之间的调用关系。基于现有代码，给出为任务增加优先级字段并支持按优先级筛选的修改计划。列出将涉及的文件与改动点。暂时不要修改任何代码。

这样写的原因：明确要求“不修改代码”，让 Codex 先建立对项目的理解，避免盲目改动。可以根据项目情况替换“任务管理 API”为实际模块名。

模板二：实现功能并补充测试

请为任务管理 API 增加优先级字段，支持按优先级筛选。只允许修改 app/ 和 tests/ 目录下的文件。保持现有接口的向后兼容性，默认优先级为 medium。补充 pytest 测试，覆盖正常创建、默认优先级、非法优先级、按优先级筛选与空结果。运行 pytest -q 确保全部通过。完成后汇总修改的文件列表。

这样写的原因：限定了修改目录、明确了兼容性要求、指定了测试覆盖范围，并要求运行测试。开发者可根据项目替换目录名与功能描述。

模板三：代码审查

请审查当前分支相对 main 分支的代码差异。检查逻辑错误、安全问题、边界条件与测试覆盖情况。按严重程度分为高、中、低三类列出问题，并给出修改建议。不要直接修改代码。

这样写的原因：审查任务要求 Codex 只读不改，输出结构化问题清单，便于开发者按优先级处理。可以替换分支名称与审查范围。

六、ChatGPT Plus / Pro + Codex 的协同方式

在实际开发中，ChatGPT 与 Codex 可以形成互补。一个典型的分工如下：

使用 ChatGPT 梳理需求和业务规则。例如，在开始编码前，用 ChatGPT 讨论“优先级字段应该支持哪些取值”“筛选接口的默认行为是什么”。

使用 ChatGPT 讨论架构与技术选型。例如，比较 Pydantic 的枚举校验与自定义校验器，评估不同方案的维护成本。

使用 Codex 阅读仓库并定位文件。Codex 可以直接分析项目结构，找出数据模型、路由与测试文件。

使用 Codex 执行受限范围内的修改。通过提示词限定目录与功能范围，降低误改风险。

使用测试验证修改。Codex 运行测试后，开发者查看测试输出确认结果。

使用 ChatGPT 对代码差异进行第二次解释。开发者可以把 git diff 粘贴给 ChatGPT，请它解释改动的影响，作为审查的辅助参考。

最终由开发者完成人工审查。AI 的解释可能存在盲区，合并代码前必须由人确认逻辑、安全与兼容性。

七、常见错误与解决方法

1. 提示词只有一句话。改进：提供项目背景、修改范围、测试要求与验收标准。

2. 没有限制修改范围。改进：在提示词中明确允许修改的目录与文件。

3. 没有先让 Codex 阅读项目。改进：先要求分析结构，再要求修改。

4. 没有创建独立分支。改进：修改前创建功能分支，便于回滚与审查。

5. 没有要求补充测试。改进：提示词中明确要求新增或更新测试。

6. 不检查 Git diff。改进：合并前逐项检查 git diff，确认无无关改动。

7. 一次提交过多需求。改进：拆分为多个小任务，逐个验证。

8. 把密钥写入代码。改进：使用环境变量或密钥管理服务。

9. 直接修改生产环境。改进：在本地或隔离环境验证后再部署。

10. 完全相信 AI 的解释。改进：以测试结果与代码审查为准，AI 解释仅作参考。

八、安全与隐私

使用 AI 编程工具时，安全与隐私必须放在首位。

API Key 和访问令牌不能直接写入代码。应通过环境变量注入，例如：

import os

api_key = os.environ.get("OPENAI_API_KEY")
if not api_key:
    raise RuntimeError("OPENAI_API_KEY is not set")

不向模型提交生产环境密码、数据库连接串或用户隐私数据。检查日志输出，避免打印敏感信息。限制工具权限，遵循最小权限原则，只授予任务所需的仓库与命令权限。对外部依赖进行审查，确认来源可信。AI 生成的代码仍需进行安全测试，不能因为来源是 AI 就跳过检查。

九、总结

ChatGPT Plus、ChatGPT Pro 与 Codex 在软件开发中各有定位。ChatGPT 适合需求梳理、方案讨论与代码解释，Codex 适合仓库级阅读、修改与测试。两者配合，可以形成一套需求分析、编码、测试、审查的完整闭环。关键在于：明确需求、限定范围、补充测试、检查差异、人工审查。AI 是开发者的辅助工具，最终的质量责任仍在开发者手中。