面向日常开发、重构、排查问题、写轮子、读源码的实战型指南
适合 Java / 后端 / 架构向开发者
1️⃣ 安装 / 升级
请以 官方文档 为准，避免踩过期方案：
👉 官方仓库
常见方式
-
首次安装
-
CLI 升级
-
登录 / Token 配置
⚠️ 建议：
-
优先使用官方 CLI
-
不要参考零散博客，CLI 变化非常快
2️⃣ 工作模式说明
Codex 主要有两种核心工作模式：
✅ CLI 模式
-
在项目根目录执行
-
可直接 读代码 / 改代码 / 新增文件
-
支持 git diff 查看改动
-
非常适合：
-
写业务代码
-
重构
-
修 bug
-
写测试
-
✅ 聊天模式
-
更偏向 解释 / 设计 / 讨论
-
适合：
-
阅读代码
-
讲解复杂逻辑
-
讨论架构方案
-
先出设计再决定是否执行
-
👉 最佳实践：
聊天里定方案，CLI 里落代码
3️⃣/init与AGENTS.md
/init
会做什么？
在项目根目录执行：
/init
会生成一个核心文件：
AGENTS.md
AGENTS.md的作用（非常重要）
AGENTS.md ≈ 给 Codex 的“项目说明书”
它通常用于描述：
-
项目背景
-
技术栈
-
代码风格
-
目录结构
-
约定规范
-
你希望它如何写代码
举例说明
你可以在 AGENTS.md 中告诉它：
-
使用 Spring Boot + MyBatis-Plus
-
Service 分层规则
-
Controller 返回统一结构
-
不要生成 Lombok / 要生成 Lombok
-
异常如何处理
-
命名风格
👉 一句话总结：
AGENTS.md 决定了它写出来的代码「像不像你」
4️⃣ 访问权限设置
/approvals
在 CLI 中可以配置 哪些操作需要你确认。
例如：
-
是否允许修改文件
-
是否允许删除文件
-
是否允许批量改动
常见用法：
/approvals
你可以根据场景：
-
开发时放宽
-
重构 / 大改时收紧
👉 建议：
重构、自动改代码时，一定开审批，防止“手滑改炸”
5️⃣ 模型选择
/model
使用命令查看 / 切换模型：
/model
⚠️ 强烈建议
-
选择 Chat 5.0 以上模型
-
太老的模型：
-
代码风格老
-
对现代框架理解差
-
重构能力弱
-
浪费时间 ❌
-
👉 一句话建议：
模型宁愿新一点，也别省 token 折腾老模型
6️⃣ 它能帮你干什么？
你可以通过 git diff 清楚看到它改了什么，这是 Codex 非常适合工程场景的核心原因。
6.1 写业务代码（强项）
典型流程：
DB 设计
→ Mapper
→ DB Service
→ Biz Service
→ Controller
你可以：
-
让它 按你现有代码风格写
-
指定参考类 / 包
-
明确分层职责
👉 实战建议：
先让它参考你已完成的模块，再写新模块
6.2 阅读代码 / 读源码
非常适合用来：
-
解释 冗长复杂逻辑
-
说明某个类的职责
-
拆解方法的真实意图
-
解析源码设计思路
例如：
- 这个类是干嘛的？
- 这个方法为什么这么写？
- 有没有更合理的抽象？
6.3 代码重构（高级用法）
适合场景：
-
早期代码偏“过程式”
-
想升级为 面向对象设计
-
想引入设计模式
你可以这样用：
-
先让它给架构方案
-
再确认是否执行重构
-
最后让它落代码
常见模式：
-
策略模式
-
模板方法
-
责任链
-
工厂模式
👉 不要一上来就让它直接改，先看方案
6.4 写轮子 / 基础设施代码
例如可以写：
-
基于注解的分布式锁
-
Web 包装器
-
请求拦截
-
鉴权
-
日志记录
-
requestId
-
统一返回
-
全局异常拦截
-
👉 尤其适合：
- Starter
- 中间件
- 通用组件
6.5 测试用例
-
单元测试
-
Service 测试
-
边界条件补充
-
Mock 场景
可以直接让它：
- 按你项目的测试框架写
- 覆盖指定方法
6.6 修复 Bug / 分析问题
你可以直接：
-
贴 异常栈
-
贴 日志
-
贴 相关代码
它可以：
-
帮你定位问题
-
分析根因
-
给修改方案
-
甚至直接改代码
👉 对线上问题排查非常友好
6.7 当普通 AI 聊天工具
当然也可以：
-
问任何问题
-
讨论技术
-
问设计
-
问方案
只是 它在代码场景下的价值更大
✅ 总结一句话
Codex ≠ 聊天机器人
它更像一个：
👉 能读你项目
👉 能理解你风格
👉 能帮你写 / 改 / 重构代码的
👉 工程级协作者
