Codex使用最佳实践：别当聊天机器人，当成可配置的工程队友

Codex的关键不是"写一句prompt让它生成代码"，而是把它当成一个可以被配置、被训练工作方式、能持续沉淀经验的工程队友。

原则1：Prompt不用花哨，上下文要完整

一个稳定的任务描述包含四块：

要素	说明	示例
🎯 目标	你到底想改什么、做什么	修复登录后跳回首页的问题
📁 上下文	相关文件、目录、日志在哪	src/auth, src/router, logs/login-error.log
⛔ 约束	不能改什么、边界在哪	不要改数据库结构，不要重写流程
✅ 完成标准	什么情况算完成	测试通过，bug不再复现

❌ 错误示例

帮我修一下登录问题。

✅ 正确示例

目标：修复用户登录后偶尔跳回首页的问题
上下文：登录逻辑在 src/auth，路由守卫在 src/router，最近错误日志见 logs/login-error.log
约束：不要改数据库结构，不要重写登录流程，只修复当前跳转问题
完成标准：补充或更新测试，确认登录后能回到原访问页面

这不是为了"教模型怎么写代码"，而是为了减少它做无谓假设。

原则2：复杂任务先Plan，再动手

如果任务简单（改文案、修小bug），可以直接让Codex做。

但如果涉及以下特征，应该先让它计划：

特征	说明
涉及多个模块	跨文件改动
需求还不清楚	需要澄清
可能影响架构	需要评估风险
需要排查原因	先调查再动手
需要分阶段上线	不能一次性全改

Plan模式

不要急着说"直接改"，先让它：

1. 阅读相关代码
2. 复述对问题的理解
3. 找出可能的风险点
4. 给出修改方案
5. 说明验证方式

确认方案后再执行。

原则3：项目级INSTRUCTIONS配置

在Codex项目的 INSTRUCTIONS 文件中配置：

# 项目上下文
- 技术栈：Next.js + TypeScript + Prisma
- 测试框架：Vitest
- 代码风格：ESLint + Prettier

# 规则
- 所有新功能要有测试
- API路由放在 src/app/api
- 数据库操作通过Prisma Service层

# 常用命令
- npm run dev：启动开发
- npm test：运行测试
- npm run lint：代码检查

这样每次新对话都不需要重新说这些上下文。

原则4：迭代式开发

步骤	说明
小步快跑	每次改动尽量小，方便回滚
频繁验证	每改动一部分就运行测试
及时反馈	有问题立即指出，不要累积
渐进重构	先让功能跑起来，再优化代码

原则5：自动测试

策略	说明
先写测试	定义预期行为后再写实现
自动运行	每次改动后自动跑测试
边界覆盖	不仅测正常情况，也测异常

原则6：经验沉淀

沉淀方式	说明
INSTRUCTIONS	项目级规则持续更新
AGENTS.md	团队级工作方法沉淀
共享Skills	可复用的方法论打包
代码注释	关键决策记录原因

总结

旧方式	新方式
写一句prompt等代码	完整的任务上下文
上来就改	先plan再执行
项目信息反复说	INSTRUCTIONS一次配置
一次改完所有	小步迭代频繁验证
测不测看心情	测试自动化
每次重新开始	经验持续沉淀

把Codex放进工程工作流，它就会从临时助手变成熟悉项目的队友。

---

关键词：Codex, 最佳实践, 工程工作流, prompt框架, Codex配置, 迭代开发, 自动测试