Codex 斜杠命令（四）：代码审查——提 PR 前的最后一道防线

CodexAI工具教程斜杠命令OpenAI代码审查

系列目录

  1. （一）快速入门——最常用的基础命令
  2. （二）对话管理——让你的会话有条不紊
  3. （三）权限与安全——精确控制 Codex 能做什么
  4. （四）代码审查——提 PR 前的最后一道防线（本文）
  5. （五）模型与推理——为任务选择合适的大脑
  6. （六）并行工作与后台——让 Codex 同时处理多个任务
  7. （七）个性化与配置——打造你的专属 Codex
  8. （八）生态集成：插件、技能与 MCP

延伸阅读 · 插件商店完全指南 · Codex vs Claude Code 对比 · 2026 高级模式对比

# 代码审查体系 ## 工作区审查 - /review 审查未提交改动 - 对比 base 分支 - 专用 reviewer 模型 ## Diff 查看 - /diff 交互式 diff - 包含未跟踪文件 - 对话内追问改动原因 ## 项目引导 - /init 生成 AGENTS.md - 持久化项目级指令 - 团队共享审查标准 ## 审查模型 - review_model 配置项 - 独立于主会话模型 - 确保审查质量

AI 代码审查能做什么、不能做什么

AI 代码审查不是人工 review 的替代品，而是一道在提 PR 前的自动过滤网。它擅长发现逻辑漏洞、冗余代码、常见错误模式，但对业务规则的正确性、团队约定的风格细节，以及"这段逻辑是否符合产品需求"这类问题，仍需人工判断。把 AI 审查定位成"让人工 review 更聚焦"的工具，而不是"省掉人工 review"，你才能从这套工具链里获得最大价值。

命令速查表

命令 参数 用途 适用场景
/review 无 审查工作区未提交改动 功能开发完成后，提交前
/diff 无 显示当前 Git diff 快速确认改动范围
/init 无 生成 AGENTS.md 脚手架 新项目或新目录初始化

/review —— 工作区深度审查

/review

/review 是 Codex 代码审查能力的入口。在 CLI 中运行后，Codex 会启动一个专用的审查会话，分析当前工作区相对于基准分支的所有未提交改动。

审查输出是结构化的：按优先级排列的发现列表，每个发现包含问题描述、影响分析、建议修复。与直接把 diff 贴给模型不同，/review 模式下的审查更系统——Codex 会追踪符号引用、检查调用链、评估改动对上下游模块的连锁影响。

实际场景：完成一个涉及 5 个文件的功能后，先 /review 跑一次审查。Codex 发现一处边界条件处理遗漏、两个地方可以提取公共函数。修复后提交 PR，人工 reviewer 可以聚焦在业务逻辑上，不需要在这些基础问题上花时间。

review_model —— 用最好的模型做审查

默认情况下，/review 使用当前会话的模型。但你可以在 config.toml 中指定专用的审查模型：

review_model = "gpt-5.5"

审查是质量相关的操作，建议使用你可用范围内推理能力最强的模型。审查结果直接写入对话，不会修改工作区文件。

/diff —— 审查前的第一步

/diff

/diff 显示当前工作区的 Git diff，包括 Git 未跟踪的新文件。不同于直接运行 git diff：

  • 可以在对话中追问每处改动的原因
  • 可以针对特定文件深入分析
  • Codex 会结合上下文解释改动意图

实际场景：Codex 完成重构后，先 /diff 浏览改动，发现 src/utils/cache.ts 被意外修改了。直接在对话中说"还原 cache.ts"，Codex 处理 revert 不需要你切换到终端手动操作。

/init —— 告诉 Codex 你的团队怎么做事

/init

/init 在 CLI 中运行，会在当前目录生成一个 AGENTS.md 脚手架文件。这个文件的作用是向 Codex 传达持久化的项目级指令——你的构建命令、测试命令、代码风格约定、审查标准。

一个典型的 AGENTS.md 可能包含：

# Project Guidelines

## Build & Test
- Build: bun run build
- Lint: bun run lint
- Test: bun run test
- Type check: bun run typecheck

## Code Style
- Use TypeScript strict mode
- Prefer async/await over raw promises
- No default exports; use named exports

## Review Checklist
- All new functions must have unit tests
- API changes require OpenAPI spec updates

AGENTS.md 随仓库版本控制，整个团队共享。它配合 /review 使用效果更好——Codex 在审查时会参照 AGENTS.md 中的约定来判断代码是否符合团队标准。

注意：/init 生成的是脚手架，你需要根据实际项目编辑。AGENTS.md 也支持嵌套——子目录中的 AGENTS.md 会覆盖上级目录的规则，适合 monorepo 场景。

审查工作流：从修改到提交的完整链路

推荐的标准流程：

  1. 让 Codex 完成功能开发
  2. 运行 /diff，确认改动范围符合预期
  3. 运行 /review，得到结构化的审查报告
  4. 根据审查结果修复问题
  5. 再次 /diff 确认修复正确
  6. 提交并创建 PR

对于复杂改动，在 /review 之前先用 /plan 让 Codex 审查改动方案本身——在写代码之前就发现设计问题，比写完之后再改要高效得多。

实操清单

  • 在项目根目录执行 /init，生成 AGENTS.md 脚手架文件
  • 编辑 AGENTS.md，填入项目实际的构建命令（Build、Lint、Test、Type check）
  • 在 AGENTS.md 中补充团队代码风格约定（如命名规则、export 方式）
  • 在 AGENTS.md 的 Review Checklist 中列出团队审查标准（如单元测试覆盖要求、API 变更规范）
  • 打开 ~/.config/codex/config.toml，配置 review_model 为推理能力较强的模型
  • 完成一个功能开发后，运行 /diff 浏览当前工作区改动范围
  • 确认 /diff 输出中无意外修改的文件，如有则在对话中告知 Codex 还原
  • 运行 /review，等待 Codex 生成结构化审查报告
  • 逐条阅读审查报告，优先处理高优先级发现（边界条件、调用链问题）
  • 根据审查建议修复代码，再次运行 /diff 确认修复结果符合预期
  • 提交修复后的代码并创建 PR，将审查报告中的发现作为 PR 描述补充