别再手写 CRUD 了！Codex 进阶 6 招，让 AI 帮你写出比同事更优雅的代码

发表于 更新于 分类于 阅读次数： 本文字数： 4.9k 阅读时长 ≈ 4 分钟

cover

你用 Codex 写了一个 CRUD 接口。能跑。测试通过。你提了 PR。

Code Review 的时候，同事指出了 5 个问题：没有错误处理、缺少参数校验、数据库查询没有分页、返回格式不统一、命名不规范。

你看了看同事的 PR——同样用 Codex 写的，同样的功能，但代码干净得像教科书。错误处理、边界检查、类型安全、日志记录，一样不少。

同样的工具，为什么差距这么大？

因为 Codex 生成什么质量的代码，取决于你怎么”指挥”它。大多数人把 Codex 当成一个”快速代码生成器”——能跑就行。但高手把它当成一个”结对编程伙伴”——不只是写代码，而是写好代码。

今天分享 6 个进阶技巧，帮你从”能跑”升级到”优雅”。

第 1 招：AGENTS.md 反馈循环——让 Codex 越用越懂你

大部分人的 AGENTS.md 写完就再也没动过。这浪费了它最大的价值。

AGENTS.md 不应该是一个静态文件，而应该是一个持续更新的反馈循环。OpenAI 官方文档明确建议：

“当 Agent 犯了一个错误，把纠正写进 AGENTS.md，让未来的会话自动继承这个修复。”

具体怎么做？每次 Code Review 发现 Codex 的代码有问题，不要只修代码——同时更新 AGENTS.md。

比如你发现 Codex 总是忘记给 API 接口加请求参数校验。在 AGENTS.md 里加一条：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# API 开发规范
- 所有 API handler 必须在第一行校验请求参数
- 使用 zod schema 定义参数类型
- 校验失败返回 400，包含具体的错误字段
- 示例：
  ```typescript
  const schema = z.object({
    email: z.string().email(),
    name: z.string().min(1).max(100),
  });
  const result = schema.safeParse(req.body);
  if (!result.success) {
    return res.status(400).json({ errors: result.error.flatten() });
  }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

注意这里的关键：**给了代码示例**。Codex 模仿具体示例的准确率，远高于理解抽象规则。

更进阶的做法：你可以让 Codex 自己更新 AGENTS.md。在 PR Review 的时候说：

> "这个 PR 里的参数校验做得不对，帮我把正确的做法加到 AGENTS.md 里，以后所有 API 都按这个规范来。"

一个月下来，你的 AGENTS.md 会变成一份极其精准的团队编码规范。**Codex 相当于一个永远不会忘记规范的同事。**

AGENTS.md 还支持目录级分层。你可以在 `src/api/AGENTS.md` 放 API 相关规范，在 `src/components/AGENTS.md` 放组件规范。Codex 在哪个目录工作，就自动加载对应的规范。

## 第 2 招：Plan Mode——先看蓝图，再动手

这是最被低估的功能。

大多数人直接说"帮我实现 XX 功能"，然后 Codex 就开始写了。写到一半发现方向不对，删掉重来。一来一回，浪费了大量 Token 和时间。

**正确的姿势是：永远先让 Codex 出计划。**

在 CLI 里，输入 `/plan` 或按 `Shift+Tab` 切换到 Plan Mode。在这个模式下，Codex 只会分析和规划，不会修改任何文件。

你说：

> "我需要给用户系统加一个'组织'功能。一个用户可以属于多个组织，每个组织有管理员和普通成员两种角色。请先出实现计划。"

Codex 会给你一份详细的方案：
1. 数据库层：需要哪些新表、字段、关系
2. API 层：需要哪些新接口、权限检查逻辑
3. 业务层：角色判定规则、邀请流程
4. 前端层：哪些页面需要修改
5. 测试：需要哪些测试用例

你审查这份计划，发现它漏掉了"组织之间数据隔离"的问题。你指出来，它修改计划。确认无误后，再说"按计划执行"。

**一次计划审查，可以省掉 3-5 轮返工。**

v0.96+ 版本默认启用了 Plan Mode。如果你还在用旧版本，升级吧——这个功能值回票价。

## 第 3 招：子 Agent 编排——把大任务拆给专家

2026 年 3 月 16 日，Codex 正式 GA（General Availability）了子 Agent 功能。这是从"用 Codex"到"指挥 Codex"的关键跃迁。

子 Agent 的核心思想：**每个子任务有独立的上下文窗口**。认证模块的重构 Agent 不会和写测试的 Agent 共享上下文。每个 Agent 各自专注，互不干扰。

Codex 默认有三种子 Agent：
- **explorer**：专门做代码探索和理解
- **worker**：执行具体的编码任务
- **default**：通用型

但真正强大的是**自定义子 Agent**。你可以在 `.codex/agents/` 目录下创建 TOML 配置文件：

```toml
# .codex/agents/security-reviewer.toml
[agent]
name = "security-reviewer"
model = "gpt-5.4"
instructions = """
你是一个安全审查专家。只关注以下问题：
1. SQL 注入
2. XSS 攻击
3. 敏感数据泄露
4. 权限绕过
5. 不安全的依赖
不要提代码风格建议，只关注安全问题。
"""

然后在 prompt 里显式调用：

“用 security-reviewer 子 Agent 审查 src/api/ 目录下所有接口的安全性。同时用 worker 子 Agent 给所有接口补充单元测试。两个任务并行执行。”

GitHub 上有一个社区项目（VoltAgent/awesome-codex-subagents）收集了 130+ 个专用子 Agent 定义，覆盖搜索、重构、测试、文档、安全审查、性能分析等场景。直接复制 TOML 文件到你的 .codex/agents/ 目录就能用。

一个重要的注意事项：不要让子 Agent 在同一个文件上并行工作。它们会互相冲突。把任务按文件/模块拆开，效果最好。

第 4 招：Context Engineering——管理上下文比写 prompt 更重要

2026 年有一个新概念在开发者社区爆火：Context Engineering（上下文工程）。

核心观点：AI 编程工具的输出质量，80% 取决于你给它的上下文，20% 取决于 prompt。

Codex 的上下文来源有四层：

层级 来源 作用
第 1 层 你的代码仓库本身 Codex 自动读取文件、理解结构
第 2 层 AGENTS.md（全局 + 仓库 + 目录级） 持久化的项目规范和偏好
第 3 层 Skills 可复用的工作流程和领域知识
第 4 层 MCP 连接的外部系统 数据库 schema、设计稿、Issue 内容

大多数人只用了第 1 层和简单的 prompt。高手四层全用。

一个实际案例：你要重构一个支付模块。普通做法是直接说”帮我重构 payment 模块”。

进阶做法：

  1. AGENTS.md 里已经写好了支付模块的架构约定和安全要求
  2. 创建一个 Skill，定义重构的标准流程（分析 → 计划 → 实现 → 测试 → 文档）
  3. 通过 MCP 连接 Linear，让 Codex 读取相关的 Issue 和讨论
  4. 用 子 Agent 分工：explorer 分析现有代码，worker 实现重构，security-reviewer 审查安全性

这样给出的上下文足够丰富，Codex 生成的代码质量会有质的飞跃。

还有一个反面的教训：避免上下文污染。当一个对话进行了太多轮次，早期的上下文会干扰后续的输出。Codex 官方的建议是——上下文窗口用到 80% 就开新线程。对于大型重构和多文件修改，尤其要注意这一点。

第 5 招：Skills + 代码审查闭环——把”写得好”变成习惯

写好代码不是一次性的事，而是一个需要固化的流程。Skills 是最好的固化工具。

创建一个”代码质量审查”Skill：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
---
name: quality-review
description: 审查代码变更的质量。当用户说"审查"、"review"、"检查代码"时触发。
---

# 代码质量审查清单

对当前变更进行以下检查：

## 可读性
- 函数是否小于 30 行
- 变量名是否清晰表达意图
- 是否有不必要的嵌套（超过 3 层）
- 注释是否解释了"为什么"而不是"是什么"

## 健壮性
- 所有外部输入是否有校验
- 错误处理是否完整（不吞异常）
- 边界条件是否覆盖（空数组、null、超长字符串）

## 性能
- 是否有 N+1 查询
- 是否有不必要的内存分配
- 循环内是否有可以提到外面的操作

## 测试
- 新代码是否有对应的测试
- 边界条件是否在测试中覆盖
- 测试是否真的验证了行为而不只是覆盖率

输出格式：按严重程度列出问题（🔴 必须修复 / 🟡 建议优化 / 🟢 良好实践）

每次写完代码，直接说 /quality-review。Codex 会按这个清单逐一检查，输出一份结构化的审查报告。

你还可以把这个 Skill 绑定到 Automations 里——每次提 PR 自动触发审查。代码质量从”靠自觉”变成了”靠系统”。

第 6 招：用 Claude 规划 + Codex 执行——双 Agent 协作

这是社区里最火的进阶玩法之一。

社区高手的总结：”Claude 做实现设计，Codex 做执行实现。两者之间的 Token 分配是最优的。”

具体流程：

  1. 用 Claude（Opus/Sonnet）做架构规划：输入需求，让它输出详细的实现方案——文件结构、接口定义、数据模型、核心算法
  2. 把方案喂给 Codex：让 Codex 按照方案逐步实现
  3. 遇到复杂 Bug：切回 Claude 分析根因，再让 Codex 修复

为什么这样做？因为两个工具擅长的事情不同：

能力 Claude Codex
架构规划 强 中
深度推理 强 中
代码生成速度 中 强
多任务并行 中 强（子 Agent）
长时间任务 强 强
复杂 Bug 分析 强 中

一位开发者在社区分享了他的实践：”我用 Claude 生成 PRD（产品需求文档）、架构方案、Epic 拆分。这些文档格式是我和 Claude 一起设计的，专门优化过给 Codex 读。然后把这些文档喂给 Codex 执行。效果比单用任何一个都好。”

不要把鸡蛋放在一个篮子里。每个 Agent 做它最擅长的事。

优雅代码的本质

回到开头的问题：为什么同样用 Codex，代码质量差别这么大？

答案很简单：优雅的代码不是”写”出来的，是”约束”出来的。

AGENTS.md 约束了规范。Plan Mode 约束了方向。子 Agent 约束了专注度。Context Engineering 约束了上下文质量。Skills 约束了流程。Code Review 约束了最终产出。

你给 Codex 的约束越精确，它给你的代码越优雅。

这其实和管理团队是一样的道理。一个好的技术 Leader，不是自己写最多代码的人，而是能定义最清晰规范、给出最精确反馈的人。

Codex 就是你团队里那个能力最强但最需要明确指引的工程师。给它清晰的目标、严格的约束、及时的反馈——它会回报你一份让人赏心悦目的代码。

你在用 Codex 的时候，有没有发现什么提升代码质量的技巧？有没有写过自定义的子 Agent 或 Skill？你觉得 AI 生成的代码最大的质量短板是什么？评论区聊聊——你的经验，可能正好是别人需要的那块拼图。