Tech Stack#

• Go
• Gin
• GORM
• MySQL
• Redis

Testing#

Run:

go test ./…

Important#

Do not modify database schemas unless explicitly requested. 以后你再让 Codex 写代码，就不用每次重复告诉它：

这是 Go 项目 使用 GORM 不要随便改数据库 修改以后执行测试 所以我认为：

/init 已经属于 Codex 项目必会命令了。

五、先规划再写代码：/plan#

遇到复杂需求，我不建议直接：

帮我实现订单退款模块。 而是先：

/plan Codex 会切换到 Plan 模式。官方当前的定义就是让当前会话进入多步骤规划模式。

然后告诉它：

分析当前订单系统。

我要增加退款功能。

先不要修改代码。

先分析：

1. 当前订单流程
2. 涉及哪些表
3. 哪些接口需要修改
4. 哪些 Service 会受到影响
5. 是否需要事务
6. 测试应该怎么做 先把整个方案梳理出来。

确认没有问题之后，再让它执行。

对于：

数据库改造 系统重构 跨多个模块开发 老项目修改 复杂 Bug 我都比较推荐先用：

/plan

六、给长任务设置目标：/goal#

2026 年 Codex 一个非常值得注意的命令是：

/goal 比如：

/goal 完成用户模块重构，并确保所有测试通过 之后 Codex 会把这个目标持续关联到当前任务。

官方当前支持：

/goal /goal edit /goal pause /goal resume /goal clear 例如：

/goal Finish the migration and keep tests green 之后查看：

/goal 暂停：

/goal pause 继续：

/goal resume 删除：

/goal clear 官方文档说明，Goal 会持续附着在当前 Chat 上，非常适合长周期任务。

所以如果你让 Codex 连续干几十分钟甚至更长时间：

/goal 会比不断重复总目标更舒服。

七、查看代码修改：/diff#

这个命令我觉得所有程序员都应该养成习惯：

/diff 它会直接查看 Codex 对当前 Git 工作区做了什么修改。

官方说明中，/diff 会展示：

已暂存修改 未暂存修改 未跟踪文件 方便你检查这次修改到底动了什么。

所以不要：

Codex：任务完成了。

你：好的。 然后直接提交。

最好：

/diff 看看。

尤其是你只是让它：

修复登录异常。 最后发现：

20 files changed 这个时候就需要注意了。

八、让 Codex Review 自己写的代码：/review#

这是我非常推荐的另一个命令：

/review 它会进入代码 Review。

例如：

/review 然后你可以继续要求：

重点检查：

1. 是否有潜在 Bug
2. 是否遗漏异常处理
3. 是否存在 SQL 问题
4. 是否引入重复代码
5. 是否存在安全风险
6. 测试是否完整 官方说明里，/review 会重点检查工作区代码修改、行为变化以及缺失测试。

于是一个比较完整的工作流就变成：

写代码 ↓ 运行测试 ↓ /diff ↓ /review ↓ 再修改 ↓ 提交 而不是：

写完就提交

九、不进入 Codex 也能 Review：codex review#

除了：

/review 终端本身还有：

codex review 例如 Review 当前未提交代码：

codex review —uncommitted 你还可以对比某个分支：

codex review —base main 或者 Review 某一个 Commit：

codex review —commit abc123 官方当前把 codex review 定义为稳定命令，支持 Review 未提交修改、指定 Base Branch 或指定 Commit。

这个就特别适合：

Git Hook CI/CD 自动 Code Review 提交前检查 比如：

codex review —uncommitted 检查完再：

git commit

十、恢复上一次任务：codex resume#

有时候你昨天让 Codex 做了一半：

重构用户权限系统 今天还想继续。

不用重新开一个上下文。

直接：

codex resume 它会打开历史 Session。

如果要继续当前目录最近的一次会话：

codex resume —last 官方说明中，—last 默认会优先选择当前工作目录最近的会话。

我个人觉得：

codex resume —last 非常实用。

比如昨天：

分析项目 ↓ 找到问题 ↓ 修改一半 今天：

cd project

codex resume —last 继续干就行。

十一、Codex 自动执行任务：codex exec#

这个命令对于喜欢自动化的人非常重要：

codex exec 它的作用不是打开聊天界面。

而是：

直接执行一次任务，然后结束。

例如：

codex exec “检查当前项目有没有明显的 Go 编译错误” 或者：

codex exec “运行测试，并分析失败原因” 还可以简写：

codex e “运行测试” 官方目前已经将 codex exec 标记为稳定命令，主要用于非交互式任务、脚本和 CI 场景。

这个能力非常适合做自动化。

比如：

#!/bin/bash

codex exec “检查当前项目的 git diff，找出明显 Bug” 甚至放进：

CI/CD 定时任务 Git Hook 自动检查脚本 里面。

这时候 Codex 就不只是一个聊天工具了。

而是：

可以被脚本调用的 AI Agent。

十二、长对话上下文太多：/compact#

用 Codex 时间长了以后，会遇到：

Context 越来越长。 这时候可以：

/compact Codex 会把之前的聊天内容压缩成摘要，把关键内容保留下来。

官方描述是：将早期对话替换成精简摘要，从而释放上下文空间，同时保留重要信息。

比如你已经聊了：

几十轮 几百条命令 几十个文件 再继续做任务之前，可以：

/compact 这个对大型项目非常有用。

十三、临时问一个问题：/side#

这个命令我觉得很多人还不知道：

/side 比如 Codex 正在执行：

重构订单系统 突然你想到：

这个项目 Redis 用的是哪个库？ 你又不想污染当前主上下文。

可以：

/side 这个项目 Redis 使用的是哪个 Go 库？ Codex 会创建一个临时 Side Chat。

问完之后返回主任务。

官方把 /side 定义成一个独立的临时分支，不会直接打断当前主聊天上下文。

这个特别适合：

顺便问一下 临时查一个东西 验证一个想法 让 AI 检查当前方案 而不想把主线程搞乱。

十四、分叉当前方案：/fork#

如果你想尝试两套方案：

方案 A： 继续现在的架构。

方案 B： 换一种实现方式。 可以：

/fork 它会复制当前聊天历史，然后创建一个新的 Chat。

原来的会话不会消失。

例如：

当前：

JWT 登录方案 你想尝试：

Session + Redis 可以：

/fork 然后在新分支里：

改成 Redis Session 方案重新设计一版。 如果效果不好，原来的上下文还在。

十五、指定某个文件：/mention#

项目一大，千万不要什么都让 Codex 自己猜。

可以直接：

/mention src/service/user.go 或者：

/mention internal/auth/login.go 这样可以明确告诉 Codex：

重点看这个文件。

官方当前的 /mention 会把指定文件加入 Chat 上下文，让后续请求直接引用它。

例如：

/mention internal/service/user.go

分析这个文件为什么可能出现空指针。 比：

你找一下项目哪里有问题。 精准很多。

十六、调整权限：/permissions#

Codex 能不能：

修改文件 运行命令 访问目录 和它当前的权限策略有关系。

可以使用：

/permissions 调整。

比如选择：

Read Only 只让 Codex 分析，不允许它乱改。

或者根据需要使用更自动化的运行模式。

官方目前通过 /permissions 提供审批策略选择，并允许切换不同权限配置。

比如第一次接触一个陌生项目，我反而推荐：

Read Only 先让它：

读项目 分析架构 找问题 确定方案以后再开放写权限。

十七、查看 MCP：/mcp#

如果你给 Codex 接入了 MCP：

GitHub 数据库 浏览器 内部系统 其他工具 可以输入：

/mcp 查看当前可用 MCP。

想看详细状态：

/mcp verbose 官方当前也提供了终端级 MCP 管理：

codex mcp list 查看所有 MCP：

codex mcp list 查看一个：

codex mcp get xxx Codex 的 MCP 配置默认存放在：

~/.codex/config.toml 这些 MCP 管理能力已经属于稳定命令。

十八、调用 Skill：/skills#

如果你已经给 Codex 安装了一些 Skill：

/skills 可以直接打开 Skill 列表。

选择以后，Codex 会把 Skill 对应的指令加载到下一次任务中。

比如：

图片生成 Skill 代码审计 Skill 软著生成 Skill 文章写作 Skill 部署 Skill 现在 Skill 已经成为 Codex 扩展能力非常重要的一部分。

所以如果你平时自己做 Skill：

/skills 也值得记住。

十九、查看子 Agent：/agent#

现在 Codex 也支持多个 Agent Thread。

可以：

/agent 或者：

/subagents 查看并切换不同 Agent。

例如主 Agent：

负责实现功能 另一个 Agent：

运行测试 另一个：

分析日志 通过：

/agent 就可以查看不同线程的工作情况。

这个对复杂任务非常有意思。

二十、Codex 出问题先跑：codex doctor#

如果 Codex 突然：

启动失败 配置异常 认证异常 Git 不正常 Terminal 有问题 App Server 异常 不要第一时间重装。

先：

codex doctor 官方当前提供的 codex doctor 会检查：

安装情况 配置 认证 运行环境 Git Terminal App Server Session 等信息。

所以以后碰到 Codex 莫名其妙的问题，可以先记住：

codex doctor 它有点像 Codex 自带的：

一键体检。

二十一、检查登录状态#

查看 Codex 当前是不是已经登录：

codex login status 官方说明中，如果当前存在有效凭证，它会返回成功状态，因此也可以用于自动化脚本。

重新登录：

codex login 退出：

codex logout 如果你遇到：

401 认证失败 Token 异常 账号切换 这一组命令很有用。

二十二、我最推荐记住的其实只有这 12 个#

如果上面命令太多，不需要全部背。

日常开发先记这些：

codex 启动 Codex。

/init 生成 AGENTS.md。

/status 看当前状态。

/model 切模型。

/plan 复杂任务先做规划。

/goal 长任务设置目标。

/mention 指定文件。

/diff 检查修改。

/review Review 代码。

/compact 压缩上下文。

codex resume —last 继续上一次任务。

codex doctor Codex 出问题时排查。

基本把这几个掌握，你已经可以覆盖绝大多数 Codex 日常开发场景。

最后 很多新手刚使用 Codex 时，操作流程是：

codex

↓

帮我写代码

↓

完成 但真正把 Codex 当开发 Agent 使用以后，流程其实更像：

/init ↓ 建立项目规则

/plan ↓ 规划任务

/goal ↓ 锁定目标

/mention ↓ 提供关键上下文

开始开发 ↓

/diff ↓ 检查修改

/review ↓ 代码审查

运行测试 ↓

提交代码 再遇到一个大项目的时候：

codex resume —last 继续昨天的工作。

长时间对话上下文太多：

/compact 临时想问一个不相关的问题：

/side Codex 出问题：

codex doctor 你会发现：

到了 2026 年，Codex 真正值得学的已经不只是“怎么写 Prompt”。

更重要的是学会：

怎么管理一个 AI 程序员的工作流。

而这些命令，本质上就是你在管理这个 AI 程序员。