摘要

本文面向程序员、AI 工具使用者与软件开发团队，系统介绍 ChatGPT Plus、ChatGPT Pro 与 Codex 在真实软件开发流程中的定位与配合方式。文章从工具能力边界出发，给出需求分析、项目理解、代码生成、测试、调试与代码审查的完整工作流，并通过一个 FastAPI 任务管理项目的实战案例，演示如何把 Codex 接入可控的开发流程。读者将获得可直接复用的提示词模板、Git 审查方法与持续集成配置，从而建立安全、可验证的 AI 编程实践。具体可用功能以当前官方页面为准，不同账号、地区或版本可能存在差异。

目录

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

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

在日常开发中，很多开发者习惯把"问 ChatGPT"和"让 AI 写代码"混为一谈。实际上，这两类交互面对的问题空间完全不同。ChatGPT 擅长对话式推理，适合讨论需求、解释概念、对比方案；而 Codex 面向仓库级任务，能够读取项目文件、定位相关代码、执行受限修改并运行测试。理解这个区别，是建立可控 AI 编程流程的第一步。

"帮我写代码"这类一句话指令之所以低效，是因为它缺少任务边界。真实项目里，一个功能往往涉及数据模型、路由、服务层、测试与配置文件，AI 需要知道改哪些文件、不能碰哪些文件、如何验证结果。仓库上下文、测试要求和任务边界，决定了 AI 输出是可用补丁还是破坏性改动。

因此，正确做法是把 ChatGPT 当作"讨论伙伴"，把 Codex 当作"受控执行者"。前者帮你把模糊想法整理成清晰需求，后者在明确约束下完成具体修改。两者配合，才能既发挥 AI 的效率，又守住代码质量底线。

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

下表从开发场景出发，对比 ChatGPT Plus、ChatGPT Pro 与 Codex 的定位差异。需要说明的是，订阅服务与 API 服务通常属于独立使用体系，具体权益以官方页面为准，本文不讨论价格与购买渠道。

工具或方案	主要定位	适合任务	输入信息	输出结果	使用风险
ChatGPT Plus	通用对话与推理	需求梳理、方案讨论、代码解释、文档撰写	自然语言问题、代码片段、文档	文本回答、示例代码、解释说明	无仓库上下文，可能给出脱离项目的建议
ChatGPT Pro	高强度推理与深度分析	复杂架构讨论、长文档分析、多轮技术推演	长文本、多文件代码片段、复杂问题描述	深度分析、对比方案、详细设计说明	输出仍为建议，需开发者自行落地验证
Codex	仓库级编码代理	阅读项目、定位文件、实现功能、补充测试、运行验证	仓库文件、Git 状态、任务说明、测试命令	代码修改、测试结果、修改文件汇总	可能误改文件、破坏逻辑，需人工审查

从表中可以看出，ChatGPT 系列擅长"想清楚"，Codex 擅长"做出来"。前者不直接操作你的仓库，后者会真实改动文件，因此使用 Codex 时必须配套 Git 分支、测试与审查流程。

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

要让 AI 安全地参与编码，需要一套固定流程。下面用 Mermaid 展示完整工作流：

第一步是明确需求。把业务目标写成可验证的验收标准，例如"新增优先级字段，支持按优先级筛选，默认值为普通"。第二步是阅读项目，让 Codex 先分析目录结构、数据模型与现有测试，而不是直接动手。第三步制定修改计划，明确涉及文件、改动范围与风险点。

第四步创建独立 Git 分支，这是最重要的安全边界。分支让所有 AI 修改都可回退、可对比。第五步修改代码时，应限定允许改动的目录。第六步编写测试，覆盖正常路径、边界条件与异常输入。第七步运行测试，确保修改没有破坏原有功能。

测试通过后，第八步查看代码差异，重点检查是否改动了无关文件。第九步由开发者进行人工审查，确认逻辑、安全与风格。最后一步合并代码，并触发持续集成流水线。这套流程把 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 环境准备

以下命令创建虚拟环境、安装依赖并运行测试：

cd task-api
python3.11 -m venv .venv
source .venv/bin/activate
pip install -e ".[dev]"
uvicorn app.main:app --reload
pytest -q

4.3 核心业务代码

数据模型使用 Pydantic 定义，包含优先级字段与校验逻辑：

# app/models.py
from enum import Enum
from pydantic import BaseModel, Field, field_validator


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


class Task(BaseModel):
    id: int
    title: str = Field(..., min_length=1, max_length=100)
    priority: Priority = Priority.normal
    done: bool = False

    @field_validator("title")
    @classmethod
    def title_not_blank(cls, v: str) -> str:
        if not v.strip():
            raise ValueError("title cannot be blank")
        return v.strip()

服务层负责任务存储与筛选逻辑：

# app/service.py
from app.models import Task, Priority


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

    def create_task(self, title: str, priority: Priority = Priority.normal) -> Task:
        task = Task(id=self._next_id, title=title, priority=priority)
        self._tasks[task.id] = task
        self._next_id += 1
        return task

    def list_tasks(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

    def get_task(self, task_id: int) -> Task | None:
        return self._tasks.get(task_id)

API 路由使用 FastAPI 暴露接口，包含参数校验与错误处理：

# app/main.py
from fastapi import FastAPI, HTTPException, Query

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

app = FastAPI(title="Task API")
service = TaskService()


@app.post("/tasks", response_model=Task, status_code=201)
def create_task(title: str, priority: Priority = Priority.normal) -> Task:
    return service.create_task(title, priority)


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


@app.get("/tasks/{task_id}", response_model=Task)
def get_task(task_id: int) -> Task:
    task = service.get_task(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
from app.models import Priority

client = TestClient(app)


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


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


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


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


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


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

测试是使用 Codex 修改代码时的重要安全边界。没有测试，AI 的修改是否正确只能靠肉眼判断；有了测试，任何回归都会在合并前暴露。因此，要求 Codex 补充测试，本质上是把验证责任从"信任 AI"转移到"信任测试"。

4.5 持续集成配置

GitHub Actions 配置与项目依赖保持一致：

# .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"
      - name: Install dependencies
        run: |
          pip install -e ".[dev]"
      - name: Run tests
        run: pytest -q

4.6 查看并审查修改

Codex 完成修改后，使用以下命令检查改动：

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

审查时应重点检查：是否修改了无关文件、是否删除了原有逻辑、是否引入新的依赖、是否存在硬编码、是否遗漏异常处理、是否存在安全风险、测试是否真正覆盖需求。这些检查项应写入团队的代码审查清单，而不是依赖个人经验。

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

以下三个提示词模板可直接复用，方括号内容根据项目替换。

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

请阅读当前仓库的项目结构，找出与[任务优先级功能]相关的文件。
说明这些文件之间的调用关系，以及数据模型、路由和服务层的职责划分。
基于现有代码，给出实现[任务优先级字段]的修改计划，列出涉及的文件和改动要点。
本次任务只做分析，不要修改任何代码。

这样写的原因：先让 Codex 建立项目认知，再要求输出计划，最后明确禁止修改。这能避免 AI 在理解不足时贸然改动代码。可替换部分为具体功能名称、相关模块或目标文件。

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

在[app/]目录内实现[任务优先级字段]功能，保持现有 API 的向后兼容。
要求：新增字段使用[Priority]枚举，默认值为[normal]；支持按优先级筛选；
补充 pytest 测试，覆盖正常创建、默认值、非法输入、筛选和空结果；
运行 pytest 确保全部通过；最后汇总修改的文件列表和测试结果。
不要修改 tests/ 以外的测试文件，不要改动 pyproject.toml 中的依赖版本。

这样写的原因：明确功能目标、限定修改目录、要求向后兼容、强制补充测试并运行验证，最后要求汇总。可替换部分为功能描述、目录范围、枚举类型与默认值。

模板三：代码审查

请审查[git diff 或指定文件]中的代码修改，重点检查：
逻辑错误、边界条件、安全问题、异常处理、测试覆盖是否充分。
按严重程度分为高、中、低三类列出问题，每条给出具体位置和改进建议。
本次任务只做审查，不要修改代码。

这样写的原因：审查任务必须限定"只读"，否则 AI 可能边审查边改代码，难以追踪。按严重程度分类便于开发者优先处理高风险问题。可替换部分为审查范围、关注重点或输出格式。

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

在实际开发中，两者分工明确。需求阶段，使用 ChatGPT 梳理业务规则，把模糊想法转化为可验证的验收标准。架构阶段，使用 ChatGPT 讨论技术选型，对比不同方案的权衡。进入编码阶段后，使用 Codex 阅读仓库、定位文件，并在受限范围内执行修改。

修改完成后，测试是验证的第一道关卡。Codex 运行测试并反馈结果，开发者查看 Git diff 确认改动范围。对于复杂的代码差异，可以再次使用 ChatGPT 进行第二次解释，帮助理解 AI 的修改意图。但最终的人工审查不可省略，开发者必须对合并到主分支的代码负责。

需要强调的是，这套协同方式不是全自动流水线。ChatGPT 提供推理与解释，Codex 提供执行与验证，但决策权始终在开发者手中。任何 AI 生成的代码，都必须经过测试、审查与持续集成验证后才能进入生产环境。

七、常见错误与解决方法

以下是使用 AI 编程时最常见的错误及改进方法。

1. 提示词只有一句话。 例如"帮我加个优先级字段"。改进：补充功能目标、涉及文件、默认值、筛选逻辑与测试要求。

2. 没有限制修改范围。 AI 可能改动无关文件。改进：在提示词中明确允许修改的目录，例如"只在 app/ 目录内修改"。

3. 没有先让 Codex 阅读项目。 直接要求改代码，AI 缺乏上下文。改进：先使用模板一让 Codex 分析项目结构，再要求实现。

4. 没有创建独立分支。 修改直接落在主分支，难以回退。改进：任何 AI 修改前先创建功能分支。

5. 没有要求补充测试。 修改是否正确无法验证。改进：提示词中强制要求补充 pytest 测试并运行。

6. 不检查 Git diff。 盲目信任 AI 的修改。改进：使用 git diff 逐项审查，重点检查无关文件与逻辑删除。

7. 一次提交过多需求。 多个功能混在一起，出错难定位。改进：每次只让 Codex 完成一个独立功能。

8. 把密钥写入代码。 硬编码 API Key 会泄露敏感信息。改进：使用环境变量，并检查 diff 中是否出现密钥。

9. 直接修改生产环境。 AI 修改未经测试直接上线。改进：所有修改先经过本地测试、审查与持续集成。

10. 完全相信 AI 的解释。 AI 可能自信地给出错误结论。改进：用测试结果和代码审查验证 AI 的说明，而不是直接采信。

八、安全与隐私

使用 AI 编程工具时，安全与隐私必须放在首位。API Key 和访问令牌绝不能写入代码或提交到 Git 仓库，应通过环境变量注入。向模型提交内容时，不要包含生产环境密码、数据库连接串或客户敏感数据。

日志是另一个容易忽视的泄露点。AI 生成的代码可能在日志中打印请求参数或响应体，其中可能包含敏感信息。审查时应检查日志语句，避免输出令牌、密码或个人数据。

工具权限应遵循最小权限原则。Codex 只需要读写当前仓库的权限，不应授予生产环境访问权或云平台管理权限。对外部依赖要进行审查，AI 可能建议引入不熟悉的第三方库，合并前应确认其维护状态与安全性。

最后，AI 生成的代码仍需进行安全测试。自动化测试只能验证功能正确性，不能替代安全审查。对于涉及认证、授权、输入校验的代码，应进行额外的安全评估，确保没有引入注入、越权或数据泄露风险。

九、总结

ChatGPT Plus、ChatGPT Pro 与 Codex 是互补的工具，而不是互相替代的关系。ChatGPT 系列擅长需求梳理、方案讨论与代码解释，Codex 擅长在仓库上下文中执行受限修改并运行验证。把两者纳入标准开发流程，配合 Git 分支、自动化测试、代码审查与持续集成，就能建立安全可控的 AI 编程实践。

本文通过任务管理 API 的实战案例，演示了从需求分析到合并代码的完整链路，并提供了三个可直接复用的提示词模板。核心原则是：AI 负责执行，开发者负责决策；测试负责验证，审查负责把关。只有把 AI 的产出纳入工程规范，才能真正提升开发效率，而不是引入新的风险。