Codex 实战：把编码任务交给 AI 智能体

Codex 不只是一个“代码补全工具”。它更像一个能读仓库、改文件、跑命令、看测试结果的编码智能体。你给它一个目标，它自己拆步骤、动手改、验证，再根据失败继续修。实战中，关键不是让它写多少代码，而是你如何定义任务和验收标准。

最小实战：一句话启动任务

安装和登录以官方文档为准。启动后，可以直接给 Codex 一个可验证的任务：

codex "为 utils.py 的 parse_date 增加时区支持，并补 pytest 测试"

它通常会先读相关文件，理解现有函数，然后修改实现、添加测试、运行测试。如果测试失败，它会继续调整。这个“读—改—跑—修”的循环，就是 Codex 实战的核心。

给任务，而不是给片段

普通代码助手习惯等你选中一段代码再补全。Codex 更适合接收完整任务，例如：

• “修复登录接口在空密码时返回 500 的问题，并补测试。”
• “把用户列表接口改成分页，参数是 page 和 size。”
• “升级这个依赖，并处理所有破坏性变更。”

任务越像一张工单，Codex 越容易执行。反过来，只说“优化一下代码”，它只能猜。

提供上下文：AGENTS.md 很关键

Codex 会读取仓库里的说明文件。放一个 AGENTS.md，能显著减少来回沟通：

# AGENTS.md
- 测试命令：pytest -q
- 代码检查：ruff check .
- 不要修改 migrations/ 目录
- 提交前必须运行测试

这相当于给智能体一份“团队规范”。它不需要你每次重复，也能按项目习惯工作。

小步快跑，用测试验收

Codex 最容易翻车的时候，是任务太大。比如“重写整个支付模块”这种目标，涉及面太广，结果往往不可控。更好的做法是拆成小步：

1. 先加一个失败测试。
2. 让 Codex 修到测试通过。
3. 审查 diff。
4. 再进入下一步。

示例流程：

codex "先写一个会失败的测试，覆盖空密码登录，然后修复实现直到通过"

测试是 Codex 的“验收器”。没有测试，它只能靠猜；有测试，它就能自我纠正。

审查 diff，不要盲信

Codex 很强，但不是不会犯错。它可能改错文件、引入多余依赖、忽略边界条件，甚至误删代码。实战中必须做三件事：

• 看 diff：每一行改动都要有理由。
• 跑测试：本地或 CI 必须通过。
• 查安全：不要让它接触生产密钥，不要执行危险命令。

把 Codex 当成一个速度很快的实习生：它能干活，但需要你定边界、做验收。

常见坑

任务描述太模糊、缺少测试、一次改太多文件、不审查直接合并，是 Codex 实战最常见的四个坑。另一个坑是权限过大，比如让它直接操作生产数据库。正确做法是：最小权限、沙箱运行、高风险操作人工确认。

结语

Codex 实战的核心不是“让 AI 写代码”，而是“让 AI 完成任务”。你负责定义问题、提供上下文、设定验收；它负责执行、迭代、验证。少量代码就能启动，但真正决定效果的，是工程判断和审查习惯。工具越强，边界越重要。