很多开发者第一次在 ChatGPT Plus / Pro 中接触 Codex，使用方式其实和以前用 ChatGPT 写代码没有太大区别：

帮我写一个登录接口

或者：

这个报错怎么解决？

这种方式当然可以用，但如果只是这样使用，实际上并没有真正发挥 Codex 的能力。

Codex 更适合的场景不是：

Prompt → 生成一段代码

而是：

任务
↓
阅读项目
↓
搜索代码
↓
理解调用链
↓
制定方案
↓
修改代码
↓
运行测试
↓
读取错误
↓
继续修改
↓
Review Diff
↓
完成

也就是说，Codex 的核心价值是从“代码生成”进入“软件工程执行”。

本文就从实际项目出发，介绍如何给 ChatGPT Plus / Pro 中的 Codex 建立一套更稳定的开发工作流。

---

一、为什么很多人觉得 Codex 不够稳定？

最常见的原因不是模型不够强，而是任务描述太模糊。

比如：

优化一下订单模块

这句话对于人类开发者来说都很模糊。

所谓优化可能包括：

• 性能优化
• SQL 优化
• 代码结构优化
• 并发优化
• API 优化
• 缓存优化
• 重构
• 测试补充

Codex 只能自己猜。

一旦开始猜，就很容易出现：

本来只需要修改 3 个文件
↓
AI 修改了 20 个文件
↓
顺手重构
↓
增加新依赖
↓
破坏已有逻辑

所以第一原则是：

给 Codex 的不是一句需求，而是一份 Task Spec。

---

二、推荐使用 Task Spec，而不是一句 Prompt

例如不要这样写：

修复库存超卖。

建议写成：

# Goal

修复库存超卖。

# Current Behavior

库存为 1 时，
两个并发订单可能同时创建成功。

# Expected Behavior

只能有一个订单成功。

另一个请求返回：

OUT_OF_STOCK

# Constraints

- 不增加 Redis。
- 不修改 API Response。
- 使用 PostgreSQL。
- 遵循现有 Transaction 设计。
- 不重构无关模块。

# Investigation

先调查：

- OrderService
- InventoryService
- Repository
- Transaction
- Inventory Tests

先告诉我 Root Cause。

不要立刻修改代码。

# Validation

增加并发测试。

要求：

stock = 1

两个请求同时下单

最终：

一个成功
一个失败
stock = 0

# Final Output

输出：

- 根因
- 修改文件
- 实现方案
- 测试结果
- 潜在风险

这类 Prompt 和一句：

修一下库存问题

实际效果差距非常大。

---

三、Codex 最适合采用 Investigation First

对于复杂 Bug，不建议第一句话就让 Codex 修改代码。

建议：

Investigation
↓
Plan
↓
Implementation
↓
Validation
↓
Review

例如：

先不要修改代码。

调查为什么用户修改头像后，
当前页面正常，
刷新以后又恢复旧头像。

请找到：

1. 上传接口
2. UserService
3. Database Update
4. Cache
5. getCurrentUser
6. 相关测试

最后输出完整调用链。

Codex 可能搜索出：

uploadAvatar()
↓
UserService.updateAvatar()
↓
UserRepository.update()
↓
Database

但是刷新时：

getCurrentUser()
↓
Redis
↓
旧头像

这样就能发现：

数据库已经更新
但缓存没有清除

真实修复可能只是：

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

如果一开始直接：

修头像刷新 Bug

AI 很可能跑去修改前端缓存。

这就是为什么：

先建立正确的项目模型，再修改代码。

---

四、AGENTS.md 是 Codex 项目的核心配置之一

大型项目最常见的问题是：

每次都要重新告诉 AI：

项目使用 TypeScript。

不要使用 any。

数据库只能从 Repository 层访问。

Service 才能写业务逻辑。

修改以后必须跑测试。

这类长期规则不应该反复写在 Prompt 里。

可以直接放进：

AGENTS.md

例如：

# Project

This is a Next.js + FastAPI project.

# Architecture

Frontend:
frontend/

Backend:
backend/

Business logic:
backend/services/

Database access:
backend/repositories/

# Rules

- Do not use `any`.
- Do not modify generated files.
- Do not introduce dependencies unless required.
- Controllers cannot directly access the database.
- Business logic belongs in services.
- Database queries belong in repositories.

# Before Editing

1. Locate relevant files.
2. Read nearby tests.
3. Find similar implementations.
4. Understand the current behavior.
5. Make the smallest correct change.

# Validation

After changes:

npm run lint
npm run typecheck
npm test

# Final Response

Report:

1. Files changed
2. Implementation
3. Tests
4. Remaining risks

这个文件相当于：

Codex 项目开发规范

---

五、为什么 AGENTS.md 不应该写得太长？

很多人看到 AGENTS.md 有用，就开始不断往里面加内容。

最后：

AGENTS.md
12000 行

这并不是最好的方式。

因为 AI 每次进入项目都需要读取大量无关信息。

更好的设计是：

AGENTS.md
↓
文档索引

docs/
↓
详细知识

例如：

docs/
├── architecture.md
├── order.md
├── payment.md
├── inventory.md
└── database.md

AGENTS.md 中只写：

# Documentation

Architecture:
docs/architecture.md

Order rules:
docs/order.md

Payment rules:
docs/payment.md

Inventory rules:
docs/inventory.md

任务是库存问题时，Agent 再读取：

docs/inventory.md

这就是 Context Engineering。

---

六、Codex 的重点不是 Prompt Engineering，而是 Context Engineering

传统 ChatGPT 使用中，大家经常研究：

Prompt 应该怎么写？

但 Coding Agent 更关键的问题变成：

模型现在应该看到什么？

比如修支付 Bug。

高价值 Context：

PaymentController
PaymentService
PaymentRepository
Webhook
Payment Tests
Error Log
Git Diff

低价值 Context：

Landing Page
Blog CSS
Admin UI
Image Upload
SEO Config

不是上下文越多越好。

而是：

Relevant Context 越精准越好。

---

七、一定要让 Codex 跑测试

AI 写代码最大的风险是：

看起来正确
≠
真的正确

例如 AI 修改：

function calculateDiscount(
  price: number,
  level: string
) {
  if (level === "vip") {
    return price * 0.9;
  }

  return price;
}

看起来没问题。

但真实业务还有：

10 元以下商品不参与折扣

如果没有测试，AI 不会知道。

如果项目存在：

expect(
  calculateDiscount(8, "vip")
).toBe(8);

Agent 执行：

npm test

结果：

Expected: 8
Received: 7.2

测试立刻告诉 AI：

还有一个隐藏业务规则。

这就是自动化验证的价值。

---

八、推荐建立统一 verify 命令

最好不要让 Codex 自己猜项目应该跑什么。

Node.js：

{
  "scripts": {
    "lint": "eslint .",
    "typecheck": "tsc --noEmit",
    "test": "vitest run",
    "verify": "npm run lint && npm run typecheck && npm test"
  }
}

Python：

verify:
	ruff check .
	mypy app
	pytest

然后 AGENTS.md：

# Validation

Before completing a task, run:

npm run verify

Do not claim completion if validation fails.

这句非常重要：

Do not claim completion if validation fails.

---

九、Bug Fix 最适合采用 Regression Test First

修 Bug 时可以要求 Codex：

1. 先复现
2. 增加 Regression Test
3. 确认测试失败
4. 修复代码
5. 确认测试通过

Prompt：

先写一个可以稳定复现 Bug 的测试。

确认修改前测试失败。

然后修复 Root Cause。

修复后重新运行测试。

不要删除测试，
不要降低 assertion，
不要通过修改测试来隐藏问题。

这样比：

修复一下这个 Bug

可靠很多。

---

十、为什么 Test 对 AI Coding 比过去更重要？

以前：

Developer 修改代码
↓
Test 防止 Regression

现在：

Agent 高频修改代码
↓
代码变化速度更快
↓
Test 更重要

未来甚至可以理解为：

Agent Code Generation Speed ↑
↓
Automated Verification ↑

一个没有测试的项目，对 Coding Agent 来说实际上非常危险。

---

十一、Codex 实现完成后，不要马上结束

再增加一个阶段：

AI Code Review

Prompt：

重新检查当前 Git Diff。

不要继续添加功能。

重点检查：

1. Logic Bug
2. Regression
3. Security
4. Race Condition
5. Null Handling
6. Error Handling
7. Backward Compatibility
8. Missing Tests

发现明确问题后直接修复，
然后重新运行验证。

很多时候第二遍 Review 会找到第一遍 Implementation 遗漏的问题。

---

十二、Git Diff 是非常高价值的 Context

Codex Review 时，可以执行：

git status
git diff --stat
git diff

它能直接看到：

本次到底修改了什么

例如：

-if (!user) {
+if (!user && user.active) {

这种 Diff 很容易让 Reviewer 发现：

user 为 null 时还读取 user.active

所以：

git diff

本身就是非常高价值的 AI Review Context。

---

十三、复杂项目建议分 Developer Agent 和 Reviewer Agent

重要任务可以采用：

Agent A
↓
Implementation

Agent B
↓
Review

Reviewer Prompt：

只 Review 当前 Diff。

不要重新设计功能。

本次需求：
防止订单重复创建。

重点检查：

- Idempotency
- Transaction
- Race Condition
- Duplicate Insert
- Missing Test
- Error Handling

然后：

Reviewer Findings
↓
Developer Fix
↓
Test

这种方式通常比一个 Agent 从头做到尾更稳。

---

十四、控制 Codex 的修改范围

大型项目经常遇到：

Bug 很小
↓
Diff 很大

所以 Prompt 中应该明确：

只允许修改：

backend/order/
backend/tests/order/

如果必须修改其他目录，
先说明原因。

不要顺手重构无关模块。

核心原则：

Small Diff
>
Beautiful Rewrite

尤其是生产环境 Bug。

---

十五、不要让 Codex 顺手升级依赖

例如本来修一个：

User API Bug

结果 Agent：

升级 React
升级 Next.js
升级 ORM
修改 package-lock

这是非常危险的。

AGENTS.md 可以明确：

# Dependency Rules

Do not upgrade or add dependencies
unless the task explicitly requires it.

Prefer existing libraries and utilities.

---

十六、把 Architecture Rules 写成机器能理解的约束

例如：

HTTP
↓
Controller
↓
Service
↓
Repository
↓
Database

那就写：

# Architecture

Controllers:
HTTP concerns only.

Services:
Business logic.

Repositories:
Database access.

Never:

Controller → Database

Never:

UI → Database

这样当 Agent 生成：

await prisma.user.findMany()

在 Controller 中时，它就更容易意识到违反规范。

---

十七、项目真正有价值的是隐性业务规则

例如：

users.balance

看起来是余额字段。

但实际规则可能是：

这个字段只是缓存。

真实余额必须通过 Ledger 计算。

这种知识必须写下来：

# Balance Rules

Never directly mutate:

users.balance

All balance changes must go through:

LedgerService

users.balance is a derived cache.

否则 Agent 很可能直接：

UPDATE users
SET balance = balance + 100

然后制造严重问题。

---

十八、最终推荐的 Codex 工作流

完整流程：

Human Requirement
↓
Task Spec
↓
AGENTS.md
↓
Investigation
↓
Plan
↓
Implementation
↓
Type Check
↓
Lint
↓
Unit Test
↓
Integration Test
↓
Git Diff
↓
AI Review
↓
Human Review

可以简单记成：

Explore
Plan
Implement
Verify
Review

---

十九、总结

真正用好 ChatGPT Plus / Pro 中的 Codex，并不是不断研究：

哪一句 Prompt 最神？

而是建立一套稳定的软件工程系统：

AGENTS.md
+
Task Spec
+
Context
+
Tests
+
Git
+
Review
+
Validation

Codex 真正强大的地方，不是：

一次性生成更多代码。

而是：

它可以在真实项目中持续读取、执行、观察、修改和验证。

未来开发者需要优化的，也不只是模型。

还包括：

Repository Quality
Context Quality
Test Quality
Task Quality

一个真正适合 Codex 的项目，本质上也是一个更加规范、更加容易维护的软件工程项目。