最近 Codex 又热起来，一个明显变化是：大家不再只把它当“代码生成器”，而是当成可以持续处理工程任务的代理。OpenAI 官方介绍里，Codex 已经覆盖写代码、理解陌生代码库、审查代码、调试修复和自动化开发任务；ChatGPT 的 Codex 页面也把它描述成横跨 App、编辑器和终端的同一个工作助手。

同时，媒体报道也在强调这个趋势：Axios 在 2026 年 6 月 2 日提到，知识工作者已经占 Codex 用户的大约五分之一，且增长速度快于开发者；TechRadar 在 6 月 12 日报道 OpenAI 拟收购 Ona，重点就是强化代理长期运行和持久环境能力。换句话说，热门用法正在从“一问一答”转向“把一件完整工作交给代理，但由人来验收”。

本文的实操目标：拿一个已有项目，让 Codex 完成“项目接手 → 定位问题 → 最小改动修复 → 补测试 → 代码审查 → 输出 PR 说明”的完整闭环。

一、开始前先准备三件事

项目仓库最好是 Git 管理，当前分支干净。
测试命令至少知道 lint / test / build 怎么跑。
任务边界只修一个 bug 或只做一个小功能。
回滚点先提交或创建 Git checkpoint。

官方 Quickstart 建议新手从 App、IDE、CLI 或 Cloud 入口开始。若你用桌面 App，选择项目文件夹后先让 Codex 在本机 Local 模式工作；若用 IDE 插件，Codex 默认以 Agent 模式启动，可以读文件、跑命令并写入改动。对真实项目来说，开始前做 Git checkpoint 很重要，因为 Codex 会实际修改代码。

git status
git checkout -b codex/fix-login-empty-state
npm test

二、先写一个小而硬的 AGENTS.md

很多人使用 Codex 效果不稳定，不是模型不行，而是项目规则没有被讲清楚。官方 Customization 文档建议用 AGENTS.md 放持久项目指导，例如构建命令、测试命令、代码风格、审查预期和目录级规则。官方 AGENTS.md 指南还说明，Codex 会在工作前读取这些文件，并按全局、项目、子目录的层级合并。

1

在仓库根目录放一份最小规则

# AGENTS.md

## Repository expectations
- 修改 JavaScript / TypeScript 后运行 npm test。
- 优先做最小、高置信度改动，不做无关重构。
- 如果需要新增依赖，先说明原因并等待确认。
- 修 bug 时必须补一个能失败再通过的测试。
- 最终回复请包含：改了什么、验证命令、剩余风险。

这份文件不要写成长篇制度。越短，Codex 越容易真正遵守。把你反复纠正它的地方沉淀进去，比如“不要改数据库迁移历史”“不要动老接口返回字段”“支付目录必须跑 make test-payments”。

三、第一条提示词：别急着让它改代码

热门但容易翻车的做法，是一上来就说“帮我修这个 bug”。更稳的做法是让 Codex 先读项目、列计划、指出需要确认的边界。你可以直接复制下面这段：

请先接手这个项目，不要修改代码。

目标：理解当前项目结构、启动方式、测试方式，以及与「登录空状态报错」相关的代码路径。

请输出：
1. 你看过哪些关键文件；
2. 你认为 bug 可能在哪一层；
3. 你建议的最小修改计划；
4. 修改前需要我确认的任何风险。

限制：先不要写文件，不要安装依赖，不要改格式化配置。

这一轮的价值是“让代理显性化它的理解”。如果它找错目录、误会框架、读了太多无关文件，你就趁早纠正，并把重复问题补进 AGENTS.md。

四、第二条提示词：让它小步修复并补测试

2

确认计划后再授权修改

按你刚才的计划执行，但保持改动最小。

要求：
- 只处理登录空状态报错，不重构无关模块；
- 先写或更新一个测试来覆盖这个失败场景；
- 再修改实现，让测试通过；
- 跑相关测试和 lint；
- 如果测试失败，先分析原因，不要扩大修改范围。

这里的关键是“测试先行”和“范围锁定”。Codex 很擅长顺手清理附近代码，但真实项目里，顺手改动往往比 bug 本身更危险。让它把失败用例写出来，再让实现通过，是控制风险的好办法。

五、第三条提示词：让 Codex 自审一遍

修完以后，不要直接发布。让 Codex 从代码审查角度再看一次，尤其检查边界条件、兼容性和测试覆盖。

请以代码审查者身份检查你刚才的改动。

重点看：
1. 是否有行为回归；
2. 是否有未覆盖的边界条件；
3. 是否改动了任务范围外的文件；
4. 测试是否真的能证明 bug 被修复；
5. PR 描述应该如何写。

如果发现问题，请先列出，再征求我确认后修改。

这一步很像把“开发代理”和“审查代理”拆开。你不一定需要真的开两个代理，但提示词角色要切换：前一轮负责实现，这一轮负责挑错。

六、最后让它交付一份可合并说明

3

交付格式要固定

请输出最终交付摘要，格式如下：

## 改动
- ...

## 验证
- 命令：...
- 结果：...

## 风险
- ...

## 建议 PR 标题
...

## 建议 PR 描述
...

固定交付格式的好处是，你可以快速判断是否能合并：改动是否小、验证是否跑过、风险是否透明。对小团队来说，这比“生成一大段解释”更实用。

七、最常见的 5 个坑

  1. 任务太大：“重构整个后台”很容易失控，改成“只修订单列表分页 bug”。
  2. 没有 AGENTS.md：项目规则每次靠聊天重讲，容易遗漏。
  3. 不给验证命令：Codex 会猜测试入口，猜错就浪费时间。
  4. 不看 diff：代理交付后，人仍然要审查差异。
  5. 并行太多任务：Axios 的报道也提到，多代理工作流会带来监督压力。新手先从一个任务一条线开始。

可直接复用的万能模板

你是这个仓库的临时工程代理。

任务：{一句话描述要修的问题或要做的小功能}

工作方式：
1. 先读项目并给计划，不要立刻改代码；
2. 我确认后，再做最小改动；
3. 必须补测试或说明为什么无法补测试；
4. 跑最相关的验证命令；
5. 最后给我改动摘要、验证结果、风险和 PR 描述。

边界：
- 不新增生产依赖，除非我明确同意；
- 不做无关重构；
- 不改格式化配置；
- 遇到权限、登录、外部服务问题先停下来问我。

真正好用的 Codex，不是你一次性写出完美提示词，而是你把项目规则、测试命令和验收标准沉淀下来。它越了解你的仓库，越像一个可靠的工程协作者；你越会限定边界，它越不容易“热心过头”。

参考资料