摘要

本文面向程序员、AI 工具使用者与软件开发团队,系统介绍 ChatGPT Plus、ChatGPT Pro 与 Codex 在真实软件开发流程中的定位与配合方式。文章从需求分析、项目阅读、代码生成、测试编写、代码审查到持续集成,梳理出一条可落地、可验证的 AI 辅助编程工作流,并通过一个 FastAPI 任务管理 API 的实战案例,演示如何让 Codex 在受限范围内安全地修改代码。读者将获得可直接复用的提示词模板、Git 审查清单与安全实践,从而建立一套可控、可回滚、可验证的 AI 编程流程。具体可用功能以当前官方页面为准,不同账号、地区或版本可能存在差异。

目录

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

在日常开发中,很多开发者习惯把"AI 编程"等同于"打开一个聊天窗口,把需求粘贴进去,然后复制返回的代码"。这种做法在写独立函数或算法片段时勉强可用,但一旦面对真实仓库,就会暴露出严重问题:AI 看不到项目结构,不知道现有接口的签名,也不了解测试约定,于是经常生成风格迥异、无法通过编译或测试的代码。

ChatGPT 与 Codex 的定位差异,本质上对应着两种不同的工作模式。ChatGPT 擅长的是对话式推理:你可以和它讨论业务规则、比较架构方案、解释一段陌生代码的含义,或者让它对一段 Git diff 做二次解读。它适合处理"需要理解、权衡、解释"的任务,输入通常是自然语言加少量代码片段,输出是建议、解释或示例代码。

Codex 则面向仓库级任务。它被设计为能够读取整个项目结构、定位相关文件、在指定范围内修改代码,并运行测试来验证结果。它更适合"需要动手改代码、跑测试、看 diff"的任务。换句话说,ChatGPT 回答"应该怎么改",Codex 负责"在哪个文件里改成什么样,并证明改完能通过测试"。

因此,不能只靠一句"帮我写代码"就期望 AI 完成整个功能。缺少仓库上下文时,AI 只能猜测;缺少测试要求时,AI 无法验证;缺少任务边界时,AI 可能修改无关文件。仓库上下文、测试要求和任务边界,是让 AI 从"聊天助手"升级为"可控协作者"的三个关键前提。

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

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

工具或方案 主要定位 适合任务 输入信息 输出结果 使用风险
ChatGPT Plus 通用对话与推理 需求梳理、架构讨论、代码解释、文档撰写 自然语言、代码片段、文档 建议、解释、示例代码 无仓库上下文,可能给出不匹配项目的建议
ChatGPT Pro 更高强度的对话与推理 长文档分析、复杂问题拆解、大规模代码审查讨论 长文本、多文件片段、复杂问题描述 结构化分析、分步方案、对比结论 输出仍为建议,需人工验证落地
Codex 仓库级编码代理 阅读项目、定位文件、实现功能、补充测试、运行测试 仓库路径、任务说明、允许修改的范围 实际代码修改、测试结果、diff 汇总 可能改错文件、破坏逻辑,需 Git 与测试兜底

从表中可以看出,ChatGPT 系列的价值在于"想清楚",Codex 的价值在于"改到位"。前者降低决策成本,后者降低执行成本。两者配合,才能覆盖从需求到合并的完整链路。

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

下面是一套经过实践检验的 AI 辅助开发流程。它的核心思想是:让 AI 在受限范围内执行,用 Git 分支和自动化测试作为安全边界,最终由开发者做人工审查。

需求说明

分析项目

制定修改计划

创建Git分支

修改代码

运行测试

测试是否通过

人工代码审查

合并代码

第一步,明确需求。把业务目标写成一两句话,并列出验收标准,例如"新增优先级字段,支持按优先级筛选,补充测试"。第二步,阅读项目。让 Codex 先分析目录结构、数据模型和现有接口,而不是直接动手。第三步,制定修改计划。要求 AI 列出涉及的文件、改动点和潜在风险,经你确认后再执行。第四步,创建独立 Git 分支,确保任何修改都可回滚。第五步,修改代码,并严格限定允许改动的目录。第六步,编写并运行测试。第七步,根据测试结果决定是继续修复还是进入审查。第八步,人工查看 Git diff,逐项核对。第九步,确认无误后合并代码。

这套流程的关键在于,每一步都有明确的输入和输出,AI 的自主性被限制在"修改代码"和"运行测试"两个环节,而需求确认、计划审批和最终审查始终由人掌控。

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

下面通过一个真实需求演示完整流程:为现有任务管理 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 -e ".[dev]"
uvicorn app.main:app --reload
pytest -q

4.3 核心业务代码

先定义数据模型。使用 Pydantic 校验优先级字段,只允许 low、medium、high 三个取值。

# 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(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 Task, TaskCreate, Priority
from app.service import TaskService

app = FastAPI(title="Task API")
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(priority)

4.4 自动化测试

测试是使用 Codex 修改代码时最重要的安全边界。没有测试,AI 的修改是否正确只能靠肉眼判断;有了测试,任何破坏原有逻辑的改动都会在合并前被拦截。

# tests/test_tasks.py
from fastapi.testclient import TestClient
from app.main import app

client = TestClient(app)

def setup_function() -> None:
    app.state.service = __import__("app.service", fromlist=["TaskService"]).TaskService()

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

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

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

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

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

def test_existing_feature_not_broken() -> None:
    client.post("/tasks", json={"title": "任务A"})
    resp = client.get("/tasks")
    assert len(resp.json()) == 1

4.5 持续集成配置

GitHub Actions 配置与前面的依赖和测试命令保持一致,确保每次推送都会自动验证。

# .github/workflows/test.yml
name: test

on:
  push:
  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 -e ".[dev]"
      - run: pytest -q

4.6 查看并审查修改

Codex 完成修改后,先用以下命令查看改动范围。

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

审查时应重点核对:是否修改了无关文件;是否删除了原有逻辑;是否引入了新的依赖;是否存在硬编码;是否遗漏异常处理;是否存在安全风险;测试是否真正覆盖需求。任何一项不满足,都应要求 Codex 修正后再合并。

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

下面提供三个可直接复用的提示词模板,并解释每个模板的设计意图。

模板一:分析项目,不修改代码

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

这个模板的关键在于明确"只分析、不改代码"。先让 AI 建立对项目的理解,再要求它输出计划,这样你可以在 AI 动手前纠正方向,避免浪费一次有风险的修改。

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

为任务管理 API 增加优先级字段,取值限定为 low、medium、high,默认值为 medium,并支持通过查询参数按优先级筛选。只允许修改 app/ 和 tests/ 目录下的文件,保持现有接口的向后兼容。请补充覆盖正常创建、默认值、非法值、筛选和空结果的单元测试,运行 pytest 确保全部通过,最后汇总所有修改过的文件。

这个模板包含了功能目标、修改范围、兼容性要求、测试要求和验证方式。其中"只允许修改 app/ 和 tests/"是关键约束,能有效防止 AI 改动无关文件。

模板三:代码审查

请审查当前分支相对主分支的代码差异,重点检查逻辑错误、安全问题、边界条件处理和测试覆盖情况。按严重程度分为高、中、低三类列出问题,每个问题说明所在文件和具体行号。不要直接修改代码,只输出审查报告。

这个模板把 AI 定位为"审查者"而非"修改者"。要求按严重程度分类并给出文件位置,能让审查结果直接指导人工决策,而不是泛泛而谈。

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

在实际开发中,两者不是替代关系,而是分工关系。一个典型场景是这样展开的:先用 ChatGPT 梳理需求和业务规则,把模糊的产品想法转化为明确的验收标准;再用 ChatGPT 讨论架构和技术选型,例如优先级字段应该用枚举还是字符串,筛选逻辑放在 service 层还是路由层;然后交给 Codex 阅读仓库、定位文件,并在受限范围内实现修改;修改完成后,用 pytest 验证行为;如果对某段 diff 不理解,可以把代码差异贴回 ChatGPT,让它做第二次解释;最后,由开发者完成人工审查并合并。

需要强调的是,这套流程不是全自动的。ChatGPT 的建议可能脱离项目实际,Codex 的修改可能引入回归,两者的输出都必须经过测试和人工审查。AI 的价值在于加速"想清楚"和"改到位"两个环节,而决策权和最终责任始终在开发者手中。

七、常见错误与解决方法

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

  1. 提示词只有一句话。改进:补充功能目标、修改范围、兼容性要求和测试要求。
  2. 没有限制修改范围。改进:在提示词中明确"只允许修改哪些目录"。
  3. 没有先让 Codex 阅读项目。改进:先要求分析项目结构和调用关系,再要求修改。
  4. 没有创建独立分支。改进:任何 AI 修改前先创建 Git 分支,确保可回滚。
  5. 没有要求补充测试。改进:在提示词中明确要求编写并运行测试。
  6. 不检查 Git diff。改进:合并前逐项审查 git diff,核对改动范围。
  7. 一次提交过多需求。改进:把大需求拆成多个小任务,逐个验证。
  8. 把密钥写入代码。改进:使用环境变量或密钥管理服务,禁止硬编码。
  9. 直接修改生产环境。改进:所有修改先在本地和 CI 环境验证,再走发布流程。
  10. 完全相信 AI 的解释。改进:用测试结果和代码审查验证 AI 的每一个结论。

八、安全与隐私

使用 AI 编程工具时,安全边界与功能同等重要。首先,API Key 和访问令牌绝不能写入代码或提交到 Git 仓库,应通过环境变量注入。其次,不要向模型提交生产环境密码、数据库连接串或用户隐私数据,日志中也要检查是否泄露敏感信息。第三,遵循最小权限原则,只给工具必要的仓库访问权限,不授予生产环境操作权限。第四,对外部依赖进行审查,AI 可能建议引入不熟悉的第三方库,合并前应确认其维护状态和安全性。最后,AI 生成的代码仍需进行安全测试,包括输入校验、越权访问和注入攻击等场景。

import os

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

九、总结

ChatGPT Plus、ChatGPT Pro 与 Codex 的合理分工,是把对话式推理交给 ChatGPT,把仓库级编码执行交给 Codex,再用 Git 分支、自动化测试和人工审查构成安全边界。本文通过一个 FastAPI 实战案例,演示了从需求分析到持续集成的完整链路,并提供了三个可直接复用的提示词模板。建立这套流程后,AI 不再是不可控的代码生成器,而是可验证、可回滚、可审查的开发协作者。具体功能与额度以当前官方页面为准,不同账号、地区或版本可能存在差异。

Logo

AtomGit AI 社区提供模型库、数据集、Agent、Token等资源

更多推荐