过去我们使用 ChatGPT 写代码，通常是这样的：

复制代码
↓
粘贴到 ChatGPT
↓
描述报错
↓
ChatGPT 返回修改后的代码
↓
手动替换
↓
运行
↓
发现新问题
↓
继续复制粘贴

这种模式本质上仍然是：

人负责操作，AI 负责回答。

而 Codex 带来的一个重要变化，是把 AI 编程从“代码问答”推进到了“软件工程 Agent”。

现在的 Codex 不仅可以解释一段代码，还可以围绕真实代码仓库执行一系列动作：

• 阅读项目目录
• 搜索相关代码
• 理解调用链
• 修改多个文件
• 执行 Shell 命令
• 运行测试
• 根据错误继续修改
• 检查 Git diff
• 完成一个相对完整的工程任务

OpenAI 当前也已经把 Codex 定位成面向真实软件工程工作的 Coding Agent，而不是单纯的代码生成模型。Codex 可以处理功能开发、重构、迁移以及多个并行工程任务。

这篇文章不讨论 ChatGPT Plus、Pro 哪个“更值”，而是从技术角度拆解：

Codex 到底是怎么工作的，以及怎么让它真正进入开发工作流。

---

一、ChatGPT 写代码和 Codex 写代码，核心区别是什么？

很多人第一次使用 Codex，会直接输入：

帮我写一个登录页面

然后发现：

好像和普通 ChatGPT 写代码区别也没有想象中那么大。

问题就在这里。

如果只是生成一个孤立代码片段，那么 Agent 的优势几乎没有发挥出来。

传统 ChatGPT 编程更接近：

Prompt → Model → Code

而 Codex 的工作流程更接近：

Task
  ↓
理解仓库
  ↓
制定计划
  ↓
搜索文件
  ↓
读取代码
  ↓
修改代码
  ↓
运行命令
  ↓
执行测试
  ↓
观察结果
  ↓
继续修改
  ↓
验证结果

换成一个更工程化的表达，可以抽象成：

Observe
   ↓
Reason
   ↓
Act
   ↓
Observe
   ↓
Reason
   ↓
Act
   ↓
...

这就是典型的 Agent Loop。

AI 不再只是输出一次答案。

而是在：

观察环境 → 做出决策 → 执行动作 → 获得反馈 → 再次决策

这个循环里不断推进任务。

---

二、理解 Agent Loop，是用好 Codex 的第一步

假设现在项目出现一个 Bug：

用户修改头像以后，
个人中心显示新头像，
但是刷新页面以后又恢复成旧头像。

传统使用 ChatGPT 的方式可能是：

把头像上传接口贴进去。

然后问：

为什么头像刷新后没了？

ChatGPT 只能根据你给的代码猜测。

但真实问题可能发生在：

Frontend
   ↓
uploadAvatar()
   ↓
API
   ↓
UserService
   ↓
Database
   ↓
Redis Cache
   ↓
getCurrentUser()

真正的 Bug 可能不是上传失败。

而是：

数据库已经更新
↓
Redis 缓存没有失效
↓
刷新页面
↓
重新读取旧缓存
↓
头像恢复

Codex 更适合处理这种问题，因为它可以先搜索：

avatar
uploadAvatar
updateUser
getCurrentUser
redis
cache

然后逐步寻找调用关系。

它可能最终发现：

def update_avatar(user_id, avatar_url):
    db.user.update(
        user_id,
        avatar_url=avatar_url
    )

数据库更新了。

但是缺少：

redis.delete(f"user:{user_id}")

于是修改为：

def update_avatar(user_id, avatar_url):
    db.user.update(
        user_id,
        avatar_url=avatar_url
    )

    redis.delete(f"user:{user_id}")

然后继续运行：

pytest tests/user/test_avatar.py

如果测试失败，再根据报错继续修改。

这时候你会发现：

Codex 的价值并不只是“会写 Python”。

真正有价值的是：

它能够跨文件寻找问题，并通过执行环境验证自己的判断。

---

三、AI 编程真正的分水岭：有没有环境反馈

LLM 本身存在一个天然问题：

它非常擅长生成“看起来正确”的代码。

但是：

看起来正确 ≠ 可以运行

例如 AI 很容易生成：

result = client.responses.create(...)

代码结构看起来完全正常。

但真实项目可能存在：

• SDK 版本不同
• 参数已经变化
• 方法没有导入
• 环境变量缺失
• 类型不兼容
• 数据库 Schema 不一致
• 某个函数返回值与预期不同

如果 AI 没有执行环境，它只能：

猜。

有了执行环境以后，就可以形成：

生成代码
↓
运行
↓
失败
↓
读取错误
↓
修改
↓
再次运行

例如：

TypeError
↓
定位调用位置
↓
查看函数定义
↓
修改参数
↓
重新测试

这也是 Agent 编程比单纯代码生成更重要的一点：

Compiler、Runtime、Test、Linter，本质上都可以成为 AI 的反馈信号。

---

四、为什么 Test 对 Codex 特别重要？

假设让 Codex 修改：

def calculate_discount(price, level):
    ...

需求是：

VIP 用户 9 折
SVIP 用户 8 折
普通用户不打折

AI 很容易修改成功。

但是如果业务还有一条隐藏规则：

商品价格低于 10 元不能参加会员折扣

而 Prompt 没有告诉它。

AI 很可能直接破坏业务逻辑。

如果项目有测试：

def test_normal_user():
    assert calculate_discount(100, "normal") == 100


def test_vip_user():
    assert calculate_discount(100, "vip") == 90


def test_svip_user():
    assert calculate_discount(100, "svip") == 80


def test_low_price_product():
    assert calculate_discount(8, "svip") == 8

Codex 修改完成以后运行：

pytest

最后一个测试就会失败。

于是 Agent 获得一个非常重要的信息：

原来还有最低价格限制。

这就是为什么 AI Coding 时代：

测试的重要性反而会提高，而不是降低。

以前测试主要防止：

程序员修改代码
→ 引入 Regression

以后测试还要防止：

Agent 修改代码
→ 误解业务
→ 引入 Regression

---

五、未来好的代码仓库，其实是“AI 可读仓库”

过去我们经常讨论：

代码是不是 Human Readable？

以后还要多一个问题：

代码是不是 Agent Readable？

也就是说：

一个 AI Agent 第一次进入你的项目，能不能快速知道这个项目应该怎么开发？

这时候 AGENTS.md 就很重要。

OpenAI 官方文档已经明确支持通过 AGENTS.md 为 Codex 提供持久化的仓库级说明，包括项目结构、测试命令、编码习惯以及工程约束。

例如项目根目录：

my-project/
│
├── AGENTS.md
├── README.md
├── package.json
├── src/
├── tests/
└── docs/

可以创建：

# AGENTS.md

## Project

This is a Next.js 16 e-commerce project.

## Architecture

- src/app: routes
- src/components: UI components
- src/services: API clients
- src/lib: shared utilities
- src/server: server-side business logic

## Commands

Install dependencies:

npm install

Run development server:

npm run dev

Run tests:

npm test

Run lint:

npm run lint

Run typecheck:

npm run typecheck

## Rules

- Use TypeScript.
- Do not use `any`.
- Prefer Server Components unless client state is required.
- API requests must go through src/services.
- Database access must remain inside src/server.
- Do not introduce new dependencies unless necessary.

## Before finishing

Run:

npm test
npm run lint
npm run typecheck

这样以后每一次任务都不需要重复告诉 Agent：

我们项目使用 TypeScript。

不要用 any。

数据库只能从 server 层访问。

修改完成以后记得跑 lint。

记得跑 test。

记得跑 typecheck。

这些信息直接沉淀进代码仓库。

---

六、AGENTS.md 本质上是什么？

可以把它理解成：

README.md
    ↓
写给人看的项目说明

AGENTS.md
    ↓
写给 Coding Agent 看的项目说明

但真正有价值的 AGENTS.md，不应该写成几十页文档。

最重要的是四类信息。

---

1. 项目结构

告诉 Agent：

什么代码在哪里。

例如：

## Architecture

Frontend:
src/web

Backend:
src/api

Database:
src/db

Shared types:
src/types

---

2. 验证方式

告诉 Agent：

怎么判断修改正确。

例如：

## Validation

Unit tests:

pytest

Lint:

ruff check .

Type check:

mypy app

这是非常重要的一部分。

因为没有 Validation：

完成 = AI 觉得自己写完了

有 Validation：

完成 =
代码修改完成
+
测试通过
+
Lint 通过
+
Type Check 通过

完全是两个标准。

---

七、不要只告诉 Codex“做什么”，还要告诉它“完成标准”

很多人写 Prompt：

给这个项目增加搜索功能。

从人的角度看没有问题。

但是对 Agent 来说，“完成”非常模糊。

它可能认为：

写一个搜索输入框

就完成了。

你真正需要的可能是：

UI
+
API
+
数据库查询
+
分页
+
Loading
+
Error
+
Empty State
+
测试

所以更好的 Prompt 应该是：

给商品列表增加关键词搜索。

要求：

1. 搜索 title 和 description。
2. 搜索参数使用 q。
3. 保留现有分页。
4. q 为空时返回全部商品。
5. 搜索接口增加测试。
6. 前端增加 loading 状态。
7. 没有结果时显示 empty state。
8. 不新增第三方依赖。

完成以后运行：

npm test
npm run lint
npm run typecheck

最后告诉我：
- 修改了哪些文件
- 核心实现方式
- 测试结果

两者最大的区别不是 Prompt 长短。

而是第二种方式定义了：

Definition of Done

也就是：

什么叫真正完成。

---

八、一个非常实用的 Codex Prompt 结构

我比较推荐把复杂任务写成五部分：

Context
Task
Constraints
Validation
Output

例如：

Context:

这是一个 FastAPI 项目。
用户模块位于 app/users。
数据库使用 PostgreSQL + SQLAlchemy。

Task:

增加用户注销接口：

POST /api/users/logout

Constraints:

1. 不修改登录逻辑。
2. 不增加新的 dependency。
3. 保持现有 API response 格式。
4. Session 失效逻辑放在 service 层。
5. Controller 不直接操作数据库。

Validation:

运行：

pytest tests/users
ruff check app
mypy app

Output:

完成以后输出：

1. 修改文件
2. 实现逻辑
3. 测试结果
4. 可能存在的风险

这种 Prompt 对复杂代码仓库特别有效。

---

九、不要一上来让 Codex 写代码，先让它调查

这是我认为 Agent 编程最重要的技巧之一。

很多任务可以拆成两个阶段。

第一阶段：

只调查，不修改。

例如：

先不要修改任何代码。

调查当前订单取消流程。

请找出：

1. API 入口
2. service 层
3. 数据库操作
4. 库存恢复逻辑
5. 支付退款逻辑
6. 相关测试

然后告诉我当前调用链。

Codex 可能得到：

POST /orders/:id/cancel
        ↓
OrderController.cancel()
        ↓
OrderService.cancelOrder()
        ↓
PaymentService.refund()
        ↓
InventoryService.restore()
        ↓
OrderRepository.updateStatus()

这个时候你再说：

现在增加：

已发货订单不能取消。

要求返回 ORDER_ALREADY_SHIPPED。

这样通常比直接说：

帮我增加已发货不能取消。

稳定得多。

原因是：

先建立正确的世界模型，再修改世界。

---

十、复杂任务应该拆成 Plan → Implement → Verify

推荐工作流：

Step 1
Explore

Step 2
Plan

Step 3
Implement

Step 4
Test

Step 5
Review

例如：

先分析整个权限系统，不修改代码。

然后：

给出实现 RBAC 的最小修改方案。

确认方案以后：

按照方案实现。

完成以后：

运行相关测试，并检查是否存在权限绕过。

最后：

重新 review 本次 diff，
重点检查：

- 权限漏洞
- 空值
- 并发问题
- backward compatibility
- 未覆盖的测试

这实际上已经很接近真实的软件开发流程：

Research
↓
Design
↓
Coding
↓
Testing
↓
Code Review

---

十一、Codex 为什么特别适合处理“陌生代码库”？

程序员接手陌生项目，最耗时间的一件事情不是写代码。

而是：

建立 Mental Model。

比如你第一次进入：

src/
├── api/
├── core/
├── domain/
├── infrastructure/
├── models/
├── repositories/
├── services/
├── shared/
└── utils/

最大的困难不是：

Python 会不会写？

而是：

业务逻辑到底在哪？

repository 和 service 怎么分？

DTO 在哪里？

数据库事务在哪处理？

异常怎么统一返回？

以前可能需要读半天甚至几天。

现在可以先让 Codex：

分析这个仓库。

不要修改任何代码。

请告诉我：

1. 项目使用什么架构
2. 请求从 router 到 database 的调用链
3. Authentication 在哪里
4. 全局异常处理在哪里
5. 数据库 transaction 如何管理
6. 最核心的 10 个文件

然后进一步：

画出用户登录的数据流。

得到：

HTTP Request
     ↓
AuthRouter
     ↓
AuthService
     ↓
UserRepository
     ↓
PostgreSQL
     ↓
Password Verify
     ↓
TokenService
     ↓
JWT

这时候 AI 已经不只是 Coding 工具。

还是：

Codebase Explorer。

---

十二、Codex 的另一个变化：并行 Agent

传统开发有一个天然限制：

一个开发者同一时间通常只能专注做一件事情。

Agent 可以把独立任务并行化。

例如：

Agent A
修复登录 Bug

Agent B
增加订单测试

Agent C
重构日志模块

Agent D
分析数据库慢查询

OpenAI 当前的 Codex 产品也已经开始围绕多 Agent 工作流设计，包括独立 worktree 和云端环境，让多个 Agent 可以并行处理不同工程任务。

这会产生一个非常有意思的变化。

以前工程效率是：

Developer
↓
Task A
↓
Task B
↓
Task C

以后可能变成：

Developer
        ↓
   Task Router
   /    |    \
  /     |     \
 A      B      C
 ↓      ↓      ↓
Agent  Agent  Agent
  \     |     /
   \    |    /
    Developer
      Review

开发者的角色开始从：

Code Writer

向：

Task Designer
+
Architecture Reviewer
+
Agent Supervisor

转变。

---

十三、但是不要误解：Agent 越多，不代表效率一定越高

如果任务之间高度耦合：

Agent A 修改 User schema

Agent B 同时修改 User API

Agent C 同时修改 User service

三个 Agent 很容易产生冲突。

所以并行最适合：

低耦合任务。

例如：

A：补订单模块测试

B：优化 README

C：修复独立 UI Bug

D：调查慢查询

而不是：

四个 Agent 同时重构同一个核心模块。

换句话说：

多 Agent 的核心能力不是“开更多 Agent”，而是任务切分。

---

十四、AI Coding 时代，程序员最需要提升的可能是 Task Decomposition

假设需求是：

做一个后台管理系统。

这是一个非常差的 Agent Task。

因为范围过大。

应该拆成：

1. Authentication
2. User CRUD
3. Role
4. Permission
5. Dashboard
6. Audit Log
7. API
8. Tests

继续拆：

Authentication
├── Login API
├── Logout API
├── Password Hash
├── JWT
├── Refresh Token
├── Middleware
└── Tests

最后每个任务都应该满足：

边界明确
+
输入明确
+
输出明确
+
验证明确

Agent 的成功率通常会明显提高。

---

十五、为什么大项目不要一句“帮我重构整个项目”？

因为 Agent 会面临巨大的搜索空间。

假设项目有：

500 files
100,000 LOC

Prompt：

优化一下这个项目。

“优化”意味着什么？

可能是：

性能
代码质量
架构
安全
可读性
数据库
缓存
API
测试
依赖

Agent 根本不知道优先级。

更好的方法是：

分析 app/services/order_service.py。

目标：

降低 cancel_order() 的复杂度。

要求：

1. 保持 API 行为不变。
2. 不修改数据库 schema。
3. 将 payment、inventory、notification 拆分为独立步骤。
4. 所有现有测试必须通过。
5. 为失败回滚增加测试。

Agent 的搜索空间瞬间缩小。

---

十六、Context 并不是越多越好

很多人认为：

给 AI 整个项目
=
结果一定更好

不完全正确。

真正重要的是：

Relevant Context

假设修复支付 Bug。

真正需要：

PaymentController
PaymentService
PaymentRepository
PaymentProvider
Payment tests

并不一定需要：

Admin CSS
Blog
Marketing page
Image component
Analytics dashboard

上下文越杂：

Noise ↑

Agent 判断错误的可能性也会上升。

所以高质量 Agent 工作流其实有一个核心能力：

Context Engineering。

---

十七、Prompt Engineering 正在逐渐变成 Context Engineering

以前大家研究：

Prompt 应该怎么写？

以后可能更多研究：

AI 应该看到什么？

一个优秀 Coding Agent 的输入，实际上可能包含：

User Task
+
AGENTS.md
+
Repository
+
Git Diff
+
Test Result
+
Compiler Error
+
Runtime Log
+
Issue
+
Documentation
+
Previous Decisions

模型本身只是其中一个组件。

完整系统更接近：

           ┌──────────────┐
           │ User Request │
           └──────┬───────┘
                  ↓
           ┌──────────────┐
           │ Agent Policy │
           └──────┬───────┘
                  ↓
       ┌───────────────────────┐
       │ Repository Context    │
       │ AGENTS.md             │
       │ Docs                  │
       │ Git                   │
       └──────────┬────────────┘
                  ↓
           ┌──────────────┐
           │     LLM      │
           └──────┬───────┘
                  ↓
        ┌──────────────────┐
        │ Tool Execution   │
        │ shell / edit     │
        │ test / git       │
        └────────┬─────────┘
                 ↓
           Environment
              Feedback
                 ↓
                LLM

这才是今天 Agent Coding 更完整的技术形态。

---

十八、一个值得实践的 Codex 项目结构

如果希望项目更适合 AI Agent，可以考虑：

project/
│
├── AGENTS.md
├── README.md
├── docs/
│   ├── architecture.md
│   ├── database.md
│   └── api.md
│
├── src/
│   └── ...
│
├── tests/
│   └── ...
│
├── scripts/
│   └── ...
│
└── package.json

其中：

README.md

告诉人：

项目是什么。

AGENTS.md

告诉 Agent：

应该怎么工作。

architecture.md

告诉 Agent：

为什么项目这样设计。

tests/

告诉 Agent：

什么叫正确。

这四个东西结合起来，对 AI Coding 的帮助可能比单纯升级模型还大。

---

十九、给 Codex 一个真正适合工程开发的任务模板

最后给一个我认为比较实用的通用模板。

# Context

这是一个已有生产项目。

Tech Stack:

- Next.js
- TypeScript
- PostgreSQL
- Prisma
- Redis

# Goal

实现用户收藏商品功能。

# Requirements

1. 用户可以收藏商品。
2. 用户可以取消收藏。
3. 用户可以查询自己的收藏列表。
4. 同一个商品不能重复收藏。
5. 商品删除后收藏记录同时处理。

# API

POST /api/favorites/:productId

DELETE /api/favorites/:productId

GET /api/favorites

# Constraints

- 不修改现有 Authentication。
- 不引入新的第三方依赖。
- 使用现有 Response 格式。
- Database 操作放在 repository 层。
- Business Logic 放在 service 层。
- API route 不直接访问 Prisma。

# Workflow

首先调查：

- User model
- Product model
- Authentication
- Repository pattern
- Existing API conventions

然后给出实现计划。

确认结构以后再修改。

# Validation

运行：

npm test
npm run lint
npm run typecheck

# Definition of Done

完成必须满足：

- API 完成
- Database migration 完成
- Unit tests 完成
- Existing tests 不受影响
- lint 通过
- typecheck 通过

# Final Response

告诉我：

1. 修改了哪些文件
2. 数据库如何设计
3. API 如何实现
4. 跑了哪些测试
5. 是否存在潜在风险

这种 Prompt 和：

帮我写一个收藏功能

得到的结果通常不是一个级别。

---

二十、ChatGPT Plus、Pro、Codex 真正值得关注的，不只是模型参数

很多人在讨论 AI 编程时，会一直关注：

哪个模型 Coding Benchmark 更高？

Benchmark 当然重要。

但真实软件工程的效果还取决于：

Model
×
Context
×
Tools
×
Environment
×
Tests
×
Prompt
×
Repository Quality

可以简单写成：

Agent Effectiveness
=
Model Capability
×
Context Quality
×
Feedback Quality

如果代码仓库：

没有测试
没有文档
没有类型
没有规范
没有清晰目录

即使模型很强，也只能不断猜。

反过来，一个：

结构清晰
测试完整
AGENTS.md 明确
类型严格
Lint 完整

的项目，会非常适合 Agent。

---

二十一、总结：Codex 真正改变的是软件开发的交互方式

ChatGPT 最初改变的是：

人 → AI → 答案

Codex 正在改变的是：

人
↓
描述目标
↓
Agent
↓
理解代码
↓
操作环境
↓
执行测试
↓
修改代码
↓
验证结果
↓
人 Review

这两种模式之间最大的区别，是 AI 有没有真正进入软件工程闭环。

未来开发者可能不会停止写代码。

但“写代码”在整个工作中的比例可能会下降。

更多时间会放在：

需求定义
任务拆解
架构设计
上下文管理
测试设计
Agent 调度
Code Review

所以从技术角度看，ChatGPT、Plus、Pro、Codex 最值得关注的，并不是简单的“AI 能生成多少代码”。

真正值得关注的是：

软件工程正在从 Human writes code，逐渐走向 Human defines intent，Agent executes，Human verifies。

理解这一点以后，再去使用 Codex，体验会完全不同。