背景：claude价格太贵了，换到了codex，两者在使用上有些微妙区别

适用环境：本机 codex-cli 0.125.0，Windows，交互式 TUI。

整理依据：

• codex.cmd --help：确认本机 CLI 版本和启动级命令。
• 本机 Codex TUI 二进制内置提示文本：提取当前版本明确提示的斜杠命令。
• 当前会话行为：结合 Codex 的权限、沙箱、代码审查和文件修改工作流补充使用建议。

注意：斜杠命令属于交互式 TUI 功能，可能随 Codex CLI 版本变化。遇到和本文不一致时，以你当前 TUI 中输入 / 后的候选列表为准。

一、斜杠命令和 CLI 命令的区别

Codex 有两类“命令”：

1. 终端里的 CLI 子命令，例如 codex resume、codex review、codex exec。
2. Codex 交互界面里的斜杠命令，例如 /status、/model、/review。

CLI 子命令用于启动、恢复、非交互执行、管理 MCP 或插件。斜杠命令用于已经进入 Codex TUI 后，快速控制当前会话、模型、权限、上下文和辅助功能。

示例：

codex.cmd --version
codex.cmd resume
codex.cmd review

进入 Codex 后再输入：

/status
/model
/review

二、核心常用命令

/status

用途：查看当前会话状态。

常见信息包括：

• 当前模型。
• 推理强度或模型相关配置。
• 审批策略。
• 沙箱和权限状态。
• token 使用量或上下文占用。
• 账户额度或限制信息。

推荐场景：

• 不确定当前用的是哪个模型时。
• 想确认 Codex 是否可以自动执行命令时。
• 会话变长后想看上下文/token 情况时。
• 遇到账户或额度提示时。

示例：

/status

/model

用途：切换模型或推理强度。

它通常用于快速调整 Codex 的能力、速度和成本取向。当前本机配置默认模型是 gpt-5.5，但可用模型会受账号、组织、版本和配置影响。

推荐场景：

• 简单改动：选择更快或更低推理强度。
• 复杂架构分析、棘手 bug：选择更强模型或更高 reasoning effort。
• 当前模型不支持某些能力时，切换到支持的模型。

示例：

/model

使用建议：

• 不要频繁无目的切换模型。模型切换会影响后续行为和成本/速度。
• 对复杂代码任务，优先让 Codex 读代码、运行测试，而不是只靠换模型。

/permissions

用途：控制 Codex 何时需要向你确认操作。

它影响命令执行、文件修改、网络访问和高风险操作的审批体验。具体可选项会根据当前客户端版本和配置显示。

推荐场景：

• 希望 Codex 更自动化地跑测试、读文件、修改代码。
• 希望 Codex 对每个敏感操作都先确认。
• 想临时放宽或收紧当前会话权限。

常见关联概念：

• read-only：只读沙箱，适合审查和分析。
• workspace-write：允许写当前工作区，适合日常开发。
• danger-full-access：高风险，除非你明确知道后果，否则不建议。
• approval policy：决定哪些命令需要用户批准。

示例：

/permissions

使用建议：

• 日常开发建议保持工作区可写，但保留对网络、删除、越权写入、破坏性 git 操作的确认。
• 不建议长期使用完全绕过审批和沙箱的模式。

/review

用途：对当前改动做代码审查。

Codex 会以 code review 心态检查当前工作区改动，重点关注 bug、回归风险、遗漏测试、安全问题和可维护性问题。

推荐场景：

• 提交前自查。
• PR 前找风险。
• 修改较多但不确定有没有破坏行为。
• 希望 Codex 只指出问题，不直接改代码。

示例：

/review

注意：

• /review 是一次专门的审查任务，运行时不要频繁打断。
• 如果中途打断，当前版本提示建议重新运行 /review 并等待完成。
• 如果你希望审查某个范围，可以先用自然语言说明，再运行或直接要求 Codex 审查，例如“只审查 auth 相关改动”。

/diff

用途：查看或聚焦当前改动差异。

该命令在本机 Codex 二进制中出现，通常用于查看当前会话或工作区相关 diff。实际展示方式取决于 TUI 版本。

推荐场景：

• 想快速看 Codex 改了什么。
• 在继续修改前确认当前 diff。
• 和 /review 配合，先看改动再审查。

示例：

/diff

使用建议：

• 对代码修改任务，完成后除了看 Codex 总结，也建议用 /diff 或 git diff 自己确认关键改动。

三、上下文和会话管理命令

/compact

用途：压缩当前对话上下文，释放上下文窗口。

当会话很长时，Codex 会保留关键信息摘要，把早期详细上下文压缩掉，以降低上下文压力。

推荐场景：

• 长时间连续开发后。
• token 使用量接近上限。
• 已完成一个阶段，准备进入下一阶段。
• 会话开始变慢或上下文噪音变多。

示例：

/compact

使用建议：

• 在阶段边界使用，例如“完成 bug 定位后”“完成实现后”“开始写测试前”。
• 不要在关键细节尚未总结清楚时直接 compact。你可以先让 Codex 总结当前状态，再运行 /compact。

/new

用途：开启一个新的想法或新会话，之前的 session 仍保留在历史中。

推荐场景：

• 当前任务结束，开始完全不相关的新任务。
• 不想让前一个项目的上下文影响新问题。
• 需要干净上下文，但仍希望历史可恢复。

示例：

/new

和 /compact 的区别：

• /compact：保留当前会话，只压缩上下文。
• /new：开始新的会话/思路，旧会话留在历史中。

/fork

用途：把当前聊天分叉成一个新线程。

它适合从当前上下文出发探索另一条路线，同时保留原线程。

推荐场景：

• 想尝试另一种实现方案。
• 想基于当前状态做实验，但不污染主线会话。
• 当前分析有多个方向，想拆出一条继续追踪。

示例：

/fork

/side

用途：开启一个临时 side conversation，在临时 fork 中讨论，不污染主线程。

推荐场景：

• 临时问一个旁支问题。
• 想让 Codex 解释某个概念，但不想影响主任务上下文。
• 想短暂验证一个想法，然后回到主线。

示例：

/side

和 /fork 的区别：

• /fork 更像正式分支，适合继续推进一条替代路线。
• /side 更像临时旁聊，适合短问题或辅助解释。

/rename

用途：重命名当前 thread，方便之后恢复或查找。

推荐场景：

• 多个项目并行使用 Codex。
• 一个会话很重要，之后可能通过 resume 找回来。
• 当前 thread 默认名称不够清晰。

示例：

/rename

命名建议：

project-auth-login-bug
frontend-mobile-layout
pr-review-payment-refactor

四、项目初始化和工作区命令

/init

用途：创建 AGENTS.md，给 Codex 写入项目级指导信息。

AGENTS.md 用来告诉 Codex 这个项目的约定，例如构建命令、测试命令、代码风格、目录职责和注意事项。

推荐场景：

• 第一次在某个项目中使用 Codex。
• 项目有固定测试命令、lint 命令或代码生成规则。
• 希望 Codex 后续自动遵守团队约定。

示例：

/init

注意：

• 当前版本提示：如果当前位置已经有 AGENTS.md，会跳过 /init，避免覆盖。
• 如果你已经有团队维护的 AGENTS.md，不要让工具随意重写，应该手动审查后再改。

建议包含的信息：

# AGENTS.md

## Build
- npm run build

## Test
- npm test

## Style
- Use existing component patterns.
- Do not introduce new state libraries without approval.

## Notes
- Generated files live in src/generated and should not be edited manually.

/mcp

用途：列出或查看配置的 MCP 工具。

MCP 是 Model Context Protocol，用来给 Codex 接入外部工具、资源、文档、数据库或服务。

推荐场景：

• 想确认当前有哪些 MCP server 可用。
• 某个外部工具调用失败，想检查配置。
• 需要知道 Codex 是否能访问特定文档、资源或内部系统。

示例：

/mcp

使用建议：

• MCP 工具可能需要登录、OAuth 或额外配置。
• 不同 workspace 或 profile 下 MCP 可用性可能不同。

五、能力扩展和个性化命令

/skills

用途：列出可用 skills，或提示 Codex 使用某个 skill。

Skill 是一组本地说明和资源，能让 Codex 在特定任务中遵循专门流程。例如图片生成、OpenAI 文档查询、创建 skill、安装 skill 等。

推荐场景：

• 想知道当前 Codex 有哪些内置能力扩展。
• 任务明显需要某个专用流程。
• 你希望 Codex 按某个 skill 的规则执行。

示例：

/skills

自然语言配合示例：

使用 openai-docs skill，查一下最新 Responses API 文档。

/personality

用途：自定义 Codex 的沟通风格。

它影响 Codex 如何和你汇报、解释、提问和总结。不会直接改变代码能力，但会影响协作体验。

推荐场景：

• 希望 Codex 更简洁。
• 希望 Codex 更严格审查风险。
• 希望 Codex 以中文沟通。
• 希望 Codex 少解释、多执行，或反过来。

示例：

/personality

使用建议：

• 对代码质量要求、沟通语言、汇报粒度可以明确写。
• 不要把项目规则只写进 personality。项目规则更适合放 AGENTS.md。

/statusline

用途：配置状态栏显示哪些项目。

推荐场景：

• 希望 TUI 底部持续显示模型、权限或 token 信息。
• 想减少状态栏噪音。
• 长时间工作时需要更清晰的会话状态。

示例：

/statusline

常见可关注项：

• 模型。
• 当前目录。
• 权限/审批模式。
• token 或上下文占用。
• git 状态。

六、复制、反馈和维护命令

/copy

用途：复制最新一条 agent 回复为 Markdown。

当前版本提示也支持快捷键 Ctrl+O。

推荐场景：

• 想把 Codex 的解释粘贴到文档、issue、PR 或聊天工具。
• 想保存某次分析结果。
• 想复用 Codex 生成的命令、说明或总结。

示例：

/copy

快捷键：

Ctrl+O

/feedback

用途：向维护者发送日志或反馈。

推荐场景：

• Codex 行为异常。
• TUI 卡死、渲染异常、命令失败但原因不像项目问题。
• 模型输出明显不符合工具状态。
• 需要附带日志给维护者排查。

示例：

/feedback

注意：

• 反馈可能包含日志。发送前应注意是否有敏感路径、文件名或错误输出。
• 涉及公司代码或机密项目时，先确认组织政策。

七、推荐工作流

新项目第一次使用

/status
/init
/permissions
阅读项目结构，告诉我技术栈、入口、启动命令和测试命令，不要改代码。

目的：

• 先确认模型和权限。
• 建立 AGENTS.md 项目约定。
• 让 Codex 先理解项目，不急着改。

日常修 bug

/status
运行相关测试，定位失败原因，能修就直接修，最后再跑测试。
/diff
/review

目的：

• 先确认当前会话配置。
• 让 Codex 端到端定位、修改、验证。
• 用 /diff 看改动。
• 用 /review 做提交前审查。

长会话持续开发

/status
/compact
继续实现下一个阶段，先基于当前状态列出待办。

目的：

• 查看上下文占用。
• 压缩历史。
• 让 Codex 在压缩后重建短计划。

探索替代方案

/fork
尝试另一种实现方案，不要影响主线程判断。

或：

/side
临时解释一下这个库的设计思路，不要污染主任务上下文。

目的：

• /fork 用于正式分支探索。
• /side 用于临时旁支问题。

提交前检查

/diff
/review
根据 review 结果修复高风险问题，然后运行相关测试。

目的：

• 先看当前改动。
• 再让 Codex 按 code review 标准找问题。
• 最后只修真正有风险的问题。

八、从 Claude Code 迁移时的命令映射

Claude Code 习惯	Codex 对应方式
/model	/model
/review	/review
/compact	/compact
新话题/清上下文	/new
分支探索	/fork 或 /side
查看状态	/status
权限控制	/permissions
项目说明文件	/init 生成或维护 AGENTS.md
外部工具/MCP	/mcp
复制回复	/copy 或 Ctrl+O

最大差异：

• Claude Code 用户常依赖斜杠命令驱动流程。
• Codex 中也有斜杠命令，但更推荐“自然语言目标 + 必要约束 + 斜杠命令控制状态”的组合。

例如，不必把所有动作都拆成命令。可以直接说：

修复登录失败问题，保持现有 API 不变，修改后运行相关测试。

需要控制边界时再加：

先不要改代码，只分析原因。

九、命令速查表

命令	主要用途	高频程度
/status	查看模型、权限、token、额度等状态	高
/model	切换模型或 reasoning effort	高
/permissions	调整审批和权限	高
/review	审查当前改动	高
/diff	查看当前改动差异	高
/compact	压缩长会话上下文	中高
/new	开启新会话/新想法	中
/fork	从当前线程分叉	中
/side	临时旁支对话	中
/init	创建 AGENTS.md 项目指导	中
/skills	查看或使用 skills	中
/mcp	查看 MCP 工具	中
/statusline	配置状态栏	低中
/personality	调整沟通风格	低中
/rename	重命名 thread	低中
/copy	复制最新回复为 Markdown	低中
/feedback	发送日志/反馈	低

十、实用建议

1. 开工先看 /status，避免在错误模型或错误权限下工作。
2. 改代码前明确边界，例如“不要改 API”“不要重构无关文件”“只改测试失败相关代码”。
3. 长会话分阶段使用 /compact，不要等上下文快满才处理。
4. 提交前使用 /diff 和 /review，不要只相信自然语言总结。
5. 项目长期使用 Codex 时维护好 AGENTS.md，这比每次口头重复规则更稳定。
6. 高风险操作保持审批，不要为了省一次确认长期放开所有权限。
7. 用 /fork 探索替代方案，用 /side 处理临时问题，避免主会话被旁支污染。
8. 注意codex沙箱用户建立的git仓库无法被ide识别，需要执行命令 git config --global --add safe.directory D:/example

十一、（自用）AGENTS.md 模板

# 仓库指南

## 工作约定

* 默认使用中文沟通；项目文档与注释优先中文。涉及外部接口、开源协作或国际化内容时保持原语言
* 优先将搜索、批量修改、测试、构建、排查等执行任务交给 subagent
* 主会话负责需求澄清、方案讨论、结果审查与最终决策
* 简单直接的小任务可由主会话直接完成，避免过度调度
* 复杂任务先给出实施计划，再执行

## 质量约定

* 修改前先阅读相关文件，避免盲改；优先最小改动
* 保持结构清晰；文件、函数或组件过长时，如有必要应拆分，避免单体膨胀
* 任何修改后，必须执行对应测试、lint、构建或运行验证
* 能自动执行的验证直接执行，不把测试步骤转交给用户
* 若无法执行验证，明确说明原因与最小人工验证步骤
* 同一错误连续失败两次后，先分析根因并调整策略，避免机械重试

## Git 约定

* 完成一个可验证的最小任务单元后及时 git commit，保持可回滚
* 提交时仅暂存本次任务相关文件
* 禁止提交缓存、日志、构建产物、wheel、临时文件及无关资源

## 输出约定

* 汇报结果聚焦变更内容、验证结果与后续建议，避免冗长过程描述

## 文件产物约定

* 测试输出、临时文件、调试产物、生成文件等默认仅允许写入当前项目目录范围内
* 禁止默认写入用户主目录、系统临时目录、全局缓存目录或项目外路径，除非用户明确要求

## 项目结构与模块组织

......