Codex 工作方法

Codex 用得好不好，关键不在“会不会提问”，而在你能不能把一个模糊需求变成可执行、可检查、可回滚的工作单元。

一个成熟的 Codex 工作流通常包括五件事：

1. 先建立上下文，让它知道项目结构和约束。
2. 再写清任务，限定目标、范围和验证方式。
3. 对复杂任务使用 Goals，让它围绕结果持续迭代。
4. 完成后审查 diff、测试结果和剩余风险。
5. 把反复出现的规则写进 AGENTS.md 或配置文件。

工作方法地图

任务设计

把模糊需求改写成目标、范围、限制、验证和交付

上下文管理

控制 Codex 读取什么、忽略什么，以及如何避免任务跑偏

Goals 模式

让 Codex 围绕可验证目标自动迭代

交付审查

看 diff、看测试、看风险，再决定是否合并

推荐闭环

只读建图
→ 写任务合同
→ 小步修改
→ 运行验证
→ 审查 diff
→ 总结风险
→ 把规则沉淀回项目

如果你发现 Codex 总是“改得太多”“答非所问”“测试没跑”“做完不知道能不能用”，通常不是模型能力问题，而是这个闭环里有一环没写清。

三种工作粒度

粒度	适合场景	推荐做法
一次性任务	改文案、补链接、解释文件	普通五段式任务即可
多步任务	修 Bug、补测试、整理模块	先计划，再按步骤执行，每步看 diff
目标任务	性能优化、迁移、复杂调试	用 Goals 模式写清成功和停止条件

老手习惯

• 每次让 Codex 改代码前，先让它复述范围。
• 不把“分析”和“修改”混在第一轮里。
• 要求它说明为什么改这些文件，而不是只列文件名。
• 让它运行最小必要验证，不要动不动跑全量高成本任务。
• 结束时要求它列出“没有验证的部分”和“需要人工确认的部分”。

Codex 不是替你省掉判断，而是把重复执行、搜索、试错和整理交给代理。真正的质量来自你给它的边界和验收方式。