Codex 使用技巧：从“会聊天”到“真正能干活”

最近一段时间一直在用 Codex 做开发，最大的感受是：Codex 好不好用，和你怎么给任务关系很大。

它不是简单的“代码问答工具”，更像一个能读代码、改文件、运行命令、测试页面、调用 Skill 和 Plugin 的开发智能体。

下面整理一些比较实用的使用技巧。

---

1. 不要只说“帮我改一下”，要把目标说清楚

比较差的说法：

这个页面不好看，帮我优化一下。

更好的说法：

目标：优化用户列表页面。
范围：只修改用户列表，不影响其他页面。
要求：
1. 保持现有技术栈；
2. 搜索区、表格、分页样式统一；
3. 不修改现有接口；
4. 修改完成后自行启动项目并验证页面。

我现在比较习惯把任务写成四部分：

目标
范围
约束
验收标准

这样 Codex 不容易“自由发挥过头”。

---

2. 大任务先规划，再让它动代码

如果任务比较大，例如：

重构后台管理系统
新增完整业务模块
修改一整套部署流程

不要一上来就让 Codex 直接改。

可以先说：

先不要修改代码。

先分析现有项目结构、相关页面、接口和数据流，
给出修改方案和涉及文件，
确认没有遗漏后再开始开发。

也可以使用 Codex 的计划/目标类能力，让它先把任务拆解清楚。

小改动可以直接做，大改动最好“先分析、再执行”。

---

3. 项目长期规则写进 AGENTS.md

如果每次都要重复告诉 Codex：

不要随意换技术栈
不要修改无关页面
修改后必须测试
数据库迁移使用 Alembic
前端保持现有设计风格

就很浪费时间。

这些长期规则更适合放进项目的：

AGENTS.md

可以把它理解成：

给 Codex 的项目说明书。

例如：

# 项目开发要求

- 保持现有技术栈，不随意引入新框架
- 修改范围严格限制在当前任务
- 后端数据库结构修改必须生成迁移文件
- 前端修改完成后必须进行页面验证
- 不删除已有功能
- 完成任务后汇总修改文件和测试结果

这样以后在这个项目中工作，Codex 会持续参考这些规则。

---

4. 会用 Skill，比每次写一大段提示词更方便

Skill 可以理解成一套“专业工作方法”。

例如：

/Frontend App Builder
/Frontend Testing Debugging
/PDF
/Presentations

如果任务非常明确，可以直接选择 Skill。

例如：

/Frontend App Builder

按照我给的原型完成这个页面。

相当于告诉 Codex：

这次任务明确按照前端应用开发这套工作方法执行。

普通任务不一定要手工选择 Skill，让 Codex 自动判断即可。

---

5. Plugin 和 Skill 不要混淆

我现在最简单的理解是：

Skill
= 告诉 Codex“怎么干”

Plugin
= 给 Codex“用什么能力干”

例如：

/Frontend App Builder

是在指定工作方法。

而：

@Presentations

是在明确使用 Presentations 提供的能力。

实际执行时，Skill、Plugin、工具、MCP 可以一起配合使用，并不是二选一。

---

6. 做前端时，截图往往比描述更有效

如果是 UI 修改，与其写几百字：

左边再宽一点
按钮向右
标题往上
卡片高度降低……

不如直接给：

图1：当前效果
图2：期望效果

然后告诉 Codex：

以图2为目标，只修改这个页面。
保持现有业务逻辑不变，尽可能还原布局、间距、字号和交互。
修改完成后启动页面自行验证。

对于页面还原、样式调整、交互问题，这种方式通常效率更高。

---

7. 不要让 Codex“改完就结束”，一定让它验证

一个很实用的习惯是，在任务最后加一句：

修改完成后不要直接结束。

请自行执行编译、测试和页面验证；
如果发现问题，继续修改，直到验证通过后再汇总结果。

尤其是前端任务，可以要求它：

修改
↓
启动项目
↓
打开页面
↓
检查效果
↓
发现问题
↓
继续修改

这比只生成代码可靠得多。

---

8. 一个对话最好围绕一个主要目标

Codex 对话越长，上下文越复杂。

比如一开始在做：

安装计划页面

后来又聊：

数据库设计
Docker
公司官网
另一个项目

虽然 Codex还能继续回答，但上下文会越来越杂。

比较好的习惯是：

一个对话围绕一个项目中的一个主要任务。

如果要尝试另一种方案，可以创建聊天分支；如果任务已经完全变了，直接开新聊天通常更干净。

---

9. 经常用 /status 看上下文

长时间使用同一个 Codex 对话时，可以输入：

/status

重点看当前上下文占用情况，例如：

已使用 200,251 / 共 258K
剩余 23%

这里表示的是当前上下文窗口占用情况，不是这一轮单独消耗的 token。

如果上下文已经非常接近上限，而任务又已经进入新的阶段，可以考虑：

先让 Codex 总结当前进度
↓
记录关键结论
↓
新建对话继续

这样通常比一直把一个对话拖得特别长更清晰。

---

10. 大修改前先留一个“可回退点”

Codex 能一次修改很多文件，这既是优势，也是风险。

所以遇到比较大的任务，我通常会先：

git status
git commit

或者新建分支。

然后再让 Codex 开始大范围修改。

这样即使结果不满意，也能快速回退，不需要人工一点一点找它改了什么。

---

11. 复杂任务用更高推理，简单任务没必要

并不是所有任务都需要最高推理强度。

例如：

改一个按钮文字
调整一个 CSS 间距
修改一个字段名

没有必要让模型进行很长时间的推理。

而下面这些任务：

分析大型项目
设计新模块
定位复杂 Bug
重构核心流程
跨多个模块修改

更适合提高 reasoning effort。

简单任务追求速度，复杂任务再提高推理强度，使用体验会更好。

---

12. 我现在最常用的 Codex 提示词模板

最后给一个比较通用的模板：

目标：
完成 XXX 功能。

修改范围：
只修改 XXX 模块，其他功能不要调整。

要求：
1. 先分析现有代码和调用关系；
2. 保持现有技术栈和项目结构；
3. 不修改无关代码；
4. 前后端接口保持一致；
5. 修改完成后自行执行测试；
6. 如果测试失败，继续定位并修复；
7. 最后汇总修改内容、涉及文件和验证结果。

验收标准：
XXX 可以正常使用，并且原有功能不受影响。

这个模板不一定每次都要完整复制，但“目标 + 范围 + 约束 + 验收”这四个部分非常实用。

---

总结

Codex 真正好用的关键，不是把提示词写得特别长，而是让任务足够清楚。

我现在比较推荐的使用方式可以概括成：

小任务直接做
大任务先规划

长期规则写 AGENTS.md
专业流程交给 Skill

需要外部能力用 Plugin
前端修改多给截图

改完必须验证
大改之前做好 Git 回退

一个对话一个主要目标
长对话及时看 /status

把 Codex 当成一个真正参与项目开发的“智能体”，而不是单纯的代码生成器，使用体验会好很多。