# Claude Code / Codex 新手 50 问
**作者**: 老爸的AI联萌
**日期**: 2026-05-14T05:33:34.000Z
**来源**: [https://x.com/ChrisWangwy/status/2054797246709833952](https://x.com/ChrisWangwy/status/2054797246709833952)
---
这篇不是命令大全，而是给第一次认真上手的人看的路线图。
Claude Code 和 Codex 这类工具真正难的地方，不是会不会打开终端，而是你能不能让它稳定理解项目、知道边界、按你的方式改代码、改完自己验证，还能在长任务里不跑偏。
所以这 50 问按真实上手顺序写：先讲怎么选，再讲 Claude Code，再讲 Codex，最后讲两者共同的工作方法。每一问都尽量回答到“新手下一步应该做什么”。
还有一句放在前面：这类工具更新很快，尤其是安装方式、斜杠命令、权限模式和集成入口。本文按我在 2026 年 5 月 13 日能核到的官方文档和本机版本来写；你实际操作时，仍然要以 Claude Code 的 /help、两者的 /status、codex --help、claude --help 和官方文档为准。
## 一、先把概念摆正
## 1. Claude Code 和 Codex 到底是什么？
Claude Code 是 Anthropic 的编码代理。它可以在终端、IDE、桌面、Web、Slack、CI 等环境里工作，核心思路是让 Claude 进入你的项目目录，读取文件、理解结构、修改代码、运行命令、做代码审查。
Codex 是 OpenAI 的编码代理体系。它有 CLI、IDE 扩展、Codex app、Web、GitHub/Slack/Linear 等集成。你可以把它当成本地终端里的开发搭档，也可以把它当成能在独立工作区里跑任务的异步代理。
真实工作里，它们经常不是二选一，而是一起合作。Claude Code 可以在本地终端里快速读项目、改代码、跑验证；Codex 可以在 CLI、IDE、app 或远程工作区里接着做 review、补测试、处理另一个分支。把它们当成两名会用同一套工程语言的代理，比把它们当成两个互斥产品更接近实际。
两者都不是单纯的聊天机器人。聊天机器人只能回答你说的话；编码代理会看文件、改文件、跑命令、检查 diff。新手要先记住这一点：你不是在问“AI 知不知道答案”，你是在安排一个能动你项目的执行者。
## 2. 我是零基础，应该先学一个，还是两个一起学？
可以两个一起学。Claude Code 和 Codex 的很多核心动作是一样的：读项目、写规则文件、申请权限、改文件、看 diff、跑测试、做 review、压缩上下文。你学的不是两个完全不同的软件，而是一套“编码代理工作流”在两个工具里的落地方式。
Claude Code 这边重点记 CLAUDE.md、/init、/memory、/permissions、/doctor、/cost、/review、.claude/skills/。Codex 这边重点记 AGENTS.md、沙盒、审批、工作区、/diff、/review、/status、/debug-config。
更好的学习方式是用同一个小任务做对照，也把它们当成能经常合作的两名代理：让 Claude Code 先读项目并给计划，再让 Codex 看同一份需求和 diff 做 review；下一次反过来，让 Codex 实现，Claude Code 审查。这样你很快会发现两者的共同语言，也能看出各自更顺手的地方。
## 3. Claude Code 和 Codex 最大的差异是什么？
Claude Code 更像一个围绕 Claude 生态设计的本地/远程编码代理，CLAUDE.md、.claude/skills/、subagents、hooks、MCP、权限模式都围绕 Anthropic 的工具链展开。
Codex 更像 OpenAI 的跨界面工作系统，同一套思路可以落在 CLI、IDE、Codex app、Web、GitHub 等地方。它的长期规则通常写在 AGENTS.md，配置写在 config.toml，权限和沙盒决定它能碰什么。
一个粗略判断：你想围绕 Claude Code 打造项目工作流，就从 CLAUDE.md 开始；你想让 OpenAI 的 Codex 在多个界面里持续做事，就从 AGENTS.md 和权限配置开始。
## 4. 它们和 Cursor、Copilot 有什么区别？
Cursor、Copilot 更容易被理解成“编辑器里的辅助驾驶”。它们擅长补全、解释、局部编辑、在 IDE 里帮你改当前文件。
Claude Code 和 Codex 更接近“项目级代理”。它们会跨文件找入口、读测试、跑命令、改多个模块、生成计划、做代码审查。你给它们的任务不应该是“把这一行写完”，而应该是“找出登录失败原因，修复并跑相关测试”。
实际使用里不冲突。很多人会用 Copilot/Cursor 做轻量补全，用 Claude Code 或 Codex 做跨文件任务、重构、审查和自动化。
## 5. 新手最容易误解的点是什么？
第一，以为安装成功就等于会用。其实安装只是拿到工具，真正的学习从“怎么给上下文”开始。
第二，以为提示词越长越好。长提示词会污染上下文，真正有用的是短、准、可验证的指令。
第三，以为斜杠命令是“魔法咒语”。不是。斜杠命令是工具内置操作，例如清上下文、看状态、改权限、生成规则文件、审查代码。它们解决的是工作流问题，不是让模型突然变聪明。
第四，看到工具要权限就害怕，或者反过来一上来全放开。正确做法是知道它为什么要权限，先保守，确认任务可信后再放宽。
## 二、Claude Code：安装、启动、环境
先检查四件事。
第一，你在哪个终端里操作。Windows PowerShell、Windows CMD、WSL、macOS Terminal、Linux shell 是不同环境，命令不能混着抄。
第二，终端是否能访问外网。浏览器能打开 Claude，不代表 PowerShell 或 WSL 也能联网。很多安装失败、登录失败、TLS 报错，本质是终端没走代理。
第三，你有没有一个项目目录。Claude Code 不是只能在空目录聊天，它的强项是在项目目录里读文件、改文件、跑命令。
第四，你准备用哪种账号登录。Claude 订阅、Console/API、企业云供应商都可能是入口，文章里要把“账号登录”和“安装命令”分开讲。
## 7. Claude Code 怎么安装？
Claude Code 先用 Native Install。它会自动后台更新，最适合新手。
macOS、Linux、WSL 输入：
irm https://claude.ai/install.ps1 | iex
Windows PowerShell 输入：
irm https://claude.ai/install.ps1 | iex
Windows CMD 输入：
curl -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmd
macOS 也可以用 Homebrew：
brew install --cask claude-code
Windows 也可以用 WinGet：
winget install Anthropic.ClaudeCode
新手优先按系统选择上面对应的一条命令。npm 现在仍然是官方支持的安装方式，但它不是新手最省心的入口；如果你确实用 npm，至少不要用 sudo npm install -g，权限问题会变得很难排。
PowerShell 和 CMD 不能混用：提示符是 PS C:\ 就用 PowerShell 命令；提示符是普通 C:\ 就用 CMD 命令。
## 8. Windows 用户应该用 PowerShell、CMD 还是 WSL？
只做普通项目，PowerShell 能用。想更接近 Linux/macOS 开发环境，WSL 更舒服。已经有 Node、Python、Git、Docker 等开发环境的人，可以按自己项目常用环境来选。
关键原则是不要混。你在 WSL 里装，就在 WSL 里进项目、跑命令、改文件；你在 Windows 原生终端里装，就不要突然拿 Linux 路径去让它找。
如果你用 Windows 原生环境，建议装 Git for Windows。Claude Code 在 Windows 上需要 shell 工具，Git for Windows 能提供更稳定的 Bash 环境；没有它时，也可能退回 PowerShell。
## 9. 安装失败应该怎么排查？
先不要换十个教程。把报错分成四类。
如果是 command not found、not recognized，重点查 PATH 和终端类型。
如果是 timeout、ECONNRESET、TLS、证书错误，重点查终端网络和代理。
如果是权限错误，先看你是不是用了管理员/root 安装，或者把某个全局目录权限弄乱了。
如果是登录后不可用，先查账号类型、订阅状态、组织限制，再查工具本身。
进 Claude Code 后，/doctor 是很重要的健康检查命令。新手写教程时应该把 /doctor 放进“安装成功后的第一步”，而不是只放一个“安装完成”截图。
## 10. 安装成功后第一条命令应该输入什么？
进入项目目录，然后运行：
claude
首次进入会提示登录。登录后，不要马上让它写一堆代码。先问：
请先阅读这个项目，告诉我它的目录结构、主要技术栈、启动命令和测试命令。先不要修改文件。
这样做的目的不是让它表演总结，而是确认它看到了正确目录。如果它答非所问，很可能你进错了目录，或者项目文件没在当前工作区。
## 11. claude、claude "任务"、claude -p 有什么区别？
claude 是进入交互会话，适合连续协作。
claude "解释这个项目" 是带着第一句话进入会话，适合快速启动一个上下文。
claude -p "问题" 更像一次性查询，回答完退出，适合脚本化、管道输入、快速解释日志。
新手先掌握 claude 就够。等你开始批量处理文件、解释日志、接入自动化，再学 claude -p。
## 12. Claude Code 为什么老是要我批准？
因为它能改文件、跑命令。批准机制不是麻烦，是安全带。
Claude Code 改文件前会展示变更，运行命令前可能会请求授权。新手不要一上来就全部放开，也不要每次看到权限弹窗就慌。你要学会看它要做什么：是读文件、改文件、装依赖、删文件、访问网络，还是运行测试。
常用命令是 /permissions。它能让你查看或调整权限。文章里应该提醒读者：权限不是越宽越高级，权限越宽，越需要你明确知道当前任务的边界。
## 13. /status 和 /cost 有什么用？
/status 用来看当前账号、系统、会话状态。你怀疑自己登录错账号、模型不对、环境不对时，先看 /status。
/cost 用来看 token 或使用成本相关统计。新手常常不知道一次长任务到底消耗了多少，上下文满了也没有感觉。/cost 至少能让你对“这次让它读了多少、跑了多久、贵不贵”有基本感知。
写教程时，不要把成本问题放到最后。新手最应该早知道：长上下文、反复让它读大文件、无目标地循环修改，都会增加消耗。
## 14. /clear 和 /compact 有什么区别？
/clear 是清掉当前对话历史，适合任务彻底结束、换一个无关任务。
/compact 是把当前对话压缩成摘要，释放上下文空间，适合长任务继续做。
一个实用判断：如果你要换话题，用 /clear；如果你还在同一个任务里，只是上下文太长，用 /compact。压缩时最好带一句重点，例如：
/compact 保留目标、已修改文件、已运行测试、剩余问题，丢掉闲聊和失败尝试。
## 15. Claude Code 里上下文为什么会变差？
因为上下文窗口不是无限的。你让它读了很多文件、聊了很多轮、反复试错，早期信息会被挤压、摘要或遗忘。
新手常见错误是把所有东西一次性塞给它：项目背景、需求、截图、日志、代码、历史讨论，全都丢进去。更好的做法是让它按任务读取：先理解结构，再锁定相关文件，再改，再测。
有三个习惯很有用：任务之间 /clear，长任务中段 /compact，长期规则写进 CLAUDE.md，不要每轮重复粘贴。
## 三、Claude Code：CLAUDE.md、斜杠命令、工作流
## 16. CLAUDE.md 是什么？
CLAUDE.md 是给 Claude Code 的项目说明书。它不是给人看的 README，而是给代理看的工作规则。
里面应该写：项目结构、启动方式、测试方式、代码风格、不要碰的目录、常见坑、PR 要求、完成定义。示例不要写成可以直接复制的具体命令，因为每个项目的包管理器和脚本都不一样。更稳的写法是这样：
# Project Instructions
## 项目运行方式
- 安装依赖：先查看 README、package.json、pyproject.toml 或项目文档，不要猜。
- 本地启动：只使用项目里真实存在的启动命令。
- 测试检查：优先运行和本次改动相关的最小测试。
- 格式/类型检查：按项目现有脚本执行，不新增工具链。
## Rules
- 不要改生成文件、构建产物、锁文件，除非任务明确要求。
- 修改范围要贴合当前任务，不做顺手重构。
- 最终回复前说明改了什么、跑了什么检查、还有什么风险。
一份短而准的 CLAUDE.md 比一份几千字的空话有用。你可以先用 /init 生成，再人工删改。
## 17. /init 什么时候用？
第一次在项目里使用 Claude Code 时用。
/init 会帮你初始化项目说明，通常会生成或更新 CLAUDE.md。但它生成的东西只是草稿，不应该不看就提交。
你要重点检查四项：命令是否真实可用，目录理解是否正确，禁区是否写清楚，完成标准是否具体。比如“保持代码质量”太虚，“修改后运行项目实际存在的最小相关测试，如果失败解释原因”更有用。
## 18. /memory 和 CLAUDE.md 是一回事吗？
不完全一样。
CLAUDE.md 是文件本身，/memory 是编辑记忆文件的入口。你可以用 /memory 打开相关记忆文件，把长期规则补进去。
记忆适合写稳定内容：项目命令、命名习惯、目录职责、你反复纠正过的偏好。不要把临时任务写进记忆，比如“今天帮我改按钮颜色”。临时信息应该留在当前对话，长期信息才进记忆。
## 19. CLAUDE.md 应该写多长？
新手可以先控制在 100 到 200 行以内。太短，代理不知道项目习惯；太长，代理每次都要背一堆不一定相关的内容。
一个好结构是：
## Project Map
## 项目运行方式
## Coding Style
## Testing Rules
## Security / Do Not Touch
## Definition of Done
写作原则很简单：只写会影响它行为的内容。愿景、口号、长篇背景故事，放到人类文档里，不要塞进代理说明书。
## 20. Claude Code 有哪些新手必须知道的斜杠命令？
先记这几个：
/help：查看当前可用命令。
/status：看账号、模型、系统状态。
/doctor：检查安装健康状态。
/init：初始化 CLAUDE.md。
/memory：编辑记忆文件。
/permissions：查看或调整权限。
/config：查看或修改配置。
/plan：让这一轮进入计划模式。也可以用 Shift+Tab 切换到 plan mode，或者启动时用 claude --permission-mode plan。
/clear：清空当前对话历史。
/compact：压缩上下文。
/model：切换模型。
/mcp：管理 MCP 连接。
/review：让它审查代码。
/cost：查看使用成本或 token 统计。
这些比“高级提示词”更重要，因为它们决定你能否稳定地工作。
## 21. /model 应该怎么用？
不要把模型切换当成炫技。一般任务用默认模型就好。复杂架构、难以定位的 bug、跨模块重构，可以考虑切到更强的模型。重复、机械、低风险的修改，可以用更快更便宜的模型。
新手最应该避免的是：任务没说清楚，就怪模型不行。模型再强，也需要明确目标、正确上下文和可验证标准。
## 22. /review 适合什么时候用？
当你或 Claude Code 已经改完一轮代码时，用 /review 做第二视角。
它适合找行为回归、遗漏测试、边界条件、安全风险、无关改动。你可以这样用：
/review 请重点看这次改动有没有破坏登录流程，是否缺少测试，不要纠结命名小问题。
不要把 /review 当成“夸我写得好”。审查命令最好带重点，让它像代码审查员，而不是像总结助手。
## 23. /pr_comments 是做什么的？
/pr_comments 用来查看 pull request 相关评论，适合修 PR review 意见时使用。这里最容易写错的是符号：当前官方写法是下划线，不是 /pr-comments。
不过 Claude Code 的命令变化很快，如果你本机 /help 里没有这个命令，也不必卡住。可以直接让 Claude 读取当前 PR 评论，或者结合 GitHub CLI、GitHub MCP 获取评论。
一个典型流程是：先让 Claude 读取当前 PR 评论，再让它总结需要处理的事项，然后逐条修改，最后 /review 检查是否真的覆盖了评论。
如果你的项目没有接 GitHub 或没有 PR 场景，这个命令可以先不用。
## 24. /mcp 是不是新手必须学？
不是第一天必须学，但很快会用到。
MCP 是让代理连接外部工具和系统的协议。比如 GitHub、数据库、浏览器、文件系统、内部工具，都可以通过 MCP 暴露给 Claude Code。
新手先理解一句话：当信息不在当前项目目录里，而在外部系统里，就可能需要 MCP。不要为了“看起来高级”装一堆 MCP。每多一个外部工具，就多一份权限和安全责任。
## 25. Claude Code 的 MCP 斜杠命令是什么？
如果某个 MCP 服务器暴露了 prompt，Claude Code 里可能会出现类似这样的命令：
/mcp__github__list_prs
/mcp__jira__create_issue
格式大致是 /mcp服务器名prompt名。这些命令不是你手写魔法，而是 MCP 服务器动态提供的能力。
新手要注意两点：先用 /mcp 看当前连接和授权状态；不要对未知 MCP 服务器一次性放开所有工具权限。
## 26. 什么是 Claude Code 自定义斜杠命令？
自定义斜杠命令就是把你常用的提示词保存成可复用文件。新版 Claude Code 更推荐用 skill，也就是 .claude/skills/命令名/SKILL.md；旧的 .claude/commands/ 仍然可用，并且会生成同名斜杠命令。
项目级命令放在：
.claude/skills/
个人级命令放在：
~/.claude/skills/
例如你创建 .claude/skills/review-api/SKILL.md，以后就可以在项目里输入：
/review-api
它适合沉淀重复工作，比如“按我的文章风格改稿”“按团队规范做安全审查”“检查 API 兼容性”。如果你已经有 .claude/commands/review-api.md，不用急着迁移，它仍然能工作；新写内容优先用 skill。
## 27. 自定义斜杠命令应该怎么写？
先从一条具体、可执行的 skill 开始，不要一上来做万能命令。
例子：
---
argument-hint: "[file-or-directory]"
allowed-tools: Read, Grep, Glob
---
请审查 $ARGUMENTS 里的代码，只关注三件事：
1. 是否有明显的安全风险
2. 是否有缺失的错误处理
3. 是否有应该补的测试
输出按严重程度排序，只给可执行建议。
$ARGUMENTS 代表你调用命令时传入的参数。新手先掌握这个就够。等命令稳定后，再考虑位置参数、文件引用、允许工具等高级写法。
## 28. Claude Code 的 subagents 是什么？
Subagents 是专门处理某类任务的子代理。它们有自己的上下文窗口、系统提示和工具权限。
你可以把主会话理解成项目经理，把 subagent 理解成专门的审查员、测试员、文档员、安全分析员。主会话把任务分出去，子代理完成后汇报结果。
它的价值是上下文隔离。比如主会话在做实现，不想把大量测试日志塞进来，就可以让测试子代理单独查。Claude Code 里可以用 /agents 管理这些子代理。
## 29. hooks、skills、subagents 应该先学哪个？
新手顺序建议是：先 CLAUDE.md，再自定义 slash commands，再 subagents，再 hooks。
CLAUDE.md 解决“每次都要重复交代”的问题。
自定义 slash commands 解决“同一类任务反复输入”的问题。
Subagents 解决“复杂任务需要不同角色和上下文隔离”的问题。
Hooks 解决“某些动作前后自动触发脚本”的问题，比如改完自动 lint、提交前检查格式。
不要一开始就全装。系统是用出来的，不是一次性设计出来的。
## 30. Claude Code 最推荐的新手工作流是什么？
一个稳妥流程是：
1. 进入项目目录，运行 claude
2. /status 确认环境
3. /init 生成或更新 CLAUDE.md
4. 让它先阅读项目，不改文件
5. 大任务先用 /plan 或 Shift+Tab 进入 plan mode，让它列计划
6. 批准小范围修改
7. 让它跑测试或解释为什么不能跑
8. /review 做代码审查
9. 让它总结改了什么、怎么验证
10. 任务结束后 /clear
这套流程看起来慢，但新手最需要的不是快，而是可控。等你熟悉以后，再放宽权限、接 MCP、加 subagents、写自定义命令。
## 四、Codex：安装、形态、规则文件
## 31. Codex 有哪些形态？
Codex 不只是一个 CLI。
CLI 适合在终端里直接和项目协作。
IDE 扩展适合在编辑器里看代码、改文件、管理 diff。
Codex app 适合更完整的本地工作体验，包括任务、工作区、浏览器、计算机使用等能力。
Web 和集成适合把任务交给远程环境，或者从 GitHub、Slack、Linear 等地方触发。
新手可以先从 CLI 或 IDE 扩展开始，少开几个入口，重点是让每个代理都在同一个 git 工作区里留下可检查的 diff。Claude Code 和 Codex 可以合作，但不要让两个代理同时改同一批文件；更稳的方式是一个负责实现，一个负责 review，或者用不同分支/工作区隔离。
## 32. Codex CLI 怎么安装？
Codex CLI 支持 macOS、Windows、Linux。最通用的安装方式是 npm：
npm i -g @openai/codex
macOS 也可以用 Homebrew：
brew install --cask codex
安装后在项目目录里运行：
codex
安装后运行 codex，用 ChatGPT 账号或 API key 登录。和 Claude Code 一样，新手第一步不是立刻改代码，而是确认当前目录、权限、模型和配置都对。
Windows 可以在 PowerShell 里原生运行，也可以用 WSL2。你平时项目在哪个环境里跑，Codex 就尽量也放在同一个环境里，少跨一层路径转换，少一半麻烦。
## 33. Codex 安装后第一件事是什么？
进入项目目录后运行 codex，然后让它先解释项目。比如：
请先阅读当前项目，告诉我目录结构、启动命令、测试命令、主要风险点。不要修改文件。
接着输入：
/status
看当前模型、审批策略、可写目录、token 使用情况等。很多新手的事故来自“以为它在 A 目录，实际在 B 目录工作”。
## 34. AGENTS.md 是什么？
AGENTS.md 是 Codex 的代理说明文件。你可以把它理解成“给 Codex 看的 README”。
它应该写：仓库结构、运行方式、测试方式、代码风格、PR 规范、禁止事项、完成标准。这里也不要放能误导读者照抄的具体命令，更适合写成“先确认、再执行”的规则：
# AGENTS.md
## 项目运行方式
- 安装依赖：读取项目文档和配置文件后确认，不能凭经验猜包管理器。
- 本地启动：使用本项目真实存在的命令。
- 测试检查：优先选择与本次改动相关的最小测试集。
- 质量检查：如果项目已有 lint、typecheck 或格式化脚本，按现有脚本执行。
## Working Rules
- 保持修改范围小。
- 不重写无关文件。
- 最终回复前说明验证结果；不能验证时说明原因。
Codex 会自动读取相关层级的 AGENTS.md。更靠近当前目录的文件规则更具体，也更优先。
## 35. Codex 的 /init 是做什么的？
Codex CLI 的 /init 用来生成 AGENTS.md 草稿。
新手应该这样用：
/init
然后打开生成的 AGENTS.md，检查它有没有写错命令、漏掉测试、误解目录。/init 是起点，不是终点。
真正有用的 AGENTS.md 往往来自反复修正：Codex 犯同一个错第二次，就把规则写进去。
## 36. CLAUDE.md 和 AGENTS.md 能不能共用，怎么支持合作？
可以，但要谨慎。
同时用 Claude Code 和 Codex 时，建议维护一份通用代理说明，再分别让 CLAUDE.md 和 AGENTS.md 引用或同步它。常见做法是把真正规则写在一个共享文件里，再让不同工具读取。
但不要为了“统一”牺牲清晰度。Claude Code 有 .claude/、commands、agents；Codex 有 .codex/、config、AGENTS.md。通用规则可以共享，工具专属配置要分开。
合作时可以按角色分工：Claude Code 负责本地交互式探索和第一轮实现，Codex 负责 /diff、/review、补测试或在另一个工作区继续推进；也可以反过来。关键是让它们共享同一份项目规则、同一份需求说明、同一套验证标准，并通过 git diff 交接，而不是靠口头描述互相转述。
一个简单流程是：A 代理实现，提交或保留清晰 diff；B 代理只看需求、规则文件和 diff，做审查；人类确认后再让其中一个代理修复 review 意见。这样合作不会乱。
## 37. Codex 的沙盒和审批是什么？
沙盒决定 Codex 能访问和修改哪些文件、能不能联网、能不能跑某些命令。
审批决定它什么时候要问你。比如读文件可能不问，写文件或运行高风险命令可能要问。
新手默认应该保守。等你知道它会怎么工作、项目有 git 保护、测试能跑，再逐步放宽。不要一上来给全盘写权限，也不要在有真实密钥、生产配置、私密资料的目录里乱试。
如果你在 Linux 或 WSL2 里用 Codex，还要知道一个很实际的点：沙盒通常依赖 bubblewrap。遇到沙盒启动失败、命令莫名跑不起来，别急着怪模型，先确认系统里有没有 bwrap，Ubuntu/Debian 可以从 sudo apt install bubblewrap 查起，Fedora/RHEL 则查 dnf install bubblewrap。
## 38. Codex 的 config.toml 是干什么的？
config.toml 是 Codex 的配置文件。它可以设置模型、推理强度、沙盒、审批策略、MCP、profiles、特性开关等。
个人默认配置通常在用户目录，项目配置可以放在项目里。新手不用第一天就手写复杂配置，但要知道：如果 Codex 行为和你预期不一致，可能不是模型问题，而是配置层级覆盖了你的设置。
还有一个容易被旧教程误导的点：on-failure 这类审批策略在当前 Codex CLI 帮助里已经标为 deprecated。交互式使用优先通过 /permissions 调整，或使用 on-request 这类当前推荐的策略；非交互批处理才考虑更激进的 never，而且要确定环境本身已经隔离好。
这时 /debug-config 很有用。
## 39. /debug-config 应该什么时候用？
当你发现 Codex 的行为“怎么和我设置的不一样”时用。
比如你以为它不能联网，实际能；你以为它能写某个目录，实际不能；你以为当前模型是 A，实际是 B。/debug-config 会帮助你看配置来源、优先级、策略限制。
新手教程里讲 /debug-config 会显得专业，因为很多真实问题都不是“AI 不聪明”，而是配置层错了。
## 40. Codex 的 /status 应该怎么看？
/status 是确认当前会话状态的入口。
你要看四类信息：当前模型、审批策略、沙盒/可写根目录、token 或上下文使用情况。
每次进入重要项目，先 /status，就像开车前看仪表盘。尤其是在多个仓库、多工作区、多模型之间切换时，这个习惯能少出很多事故。
## 五、Codex：斜杠命令和日常协作
[[IMAGE_PLACEHOLDER_9]]
## 41. Codex CLI 新手必须知道哪些斜杠命令？
先记这些。Codex CLI 现在更推荐你直接输入 / 打开命令列表，所以不要死背一份过期清单。
/permissions：调整它什么时候可以自己做、什么时候必须问你。
/status：看会话状态。
/model：切换模型和推理强度。
/init：生成 AGENTS.md。
/diff：查看本次改动。
/review：审查工作区或改动。
/compact：压缩对话，释放上下文。
/mention：把指定文件放入对话。
/plan：进入计划模式。
/new：开新会话。
/resume：恢复历史会话。
/fork：从当前会话分叉一条新线。
/side：开一个临时侧线对话。
/mcp：查看 MCP 工具。
/debug-config：诊断配置层。
这些命令比“提示词模板大全”更值得新手先学。
## 42. Codex 的 /diff 什么时候用？
每次让 Codex 改完文件后都应该用。
/diff 会展示 Git diff，包括未跟踪文件。你可以用它确认三件事：它是否改了正确文件，是否有无关改动，是否新增了你没意识到的文件。
不要只看 Codex 最后的文字总结。文字总结可能漏，diff 才是事实。
## 43. Codex 的 /review 和 Claude Code 的 /review 有什么不同？
目的类似，都是让代理以代码审查视角看改动。
在 Codex CLI 里，/review 主要用于审查当前 working tree 的改动。你可以先 /diff 看事实，再 /review 让它从风险、遗漏测试、行为回归的角度扫一遍。
在 Claude Code 里，/review 更像会话内的代码审查入口，也可以配合 GitHub CLI、GitHub MCP 或 PR 评论上下文使用。
新手不用纠结名字差异。核心原则是：生成代码和审查代码不要混成同一个动作。先让代理实现，再让它换一个视角审查。
## 44. Codex 的 /mention 有什么用？
当你明确知道某个文件很重要时，用 /mention 把它加入上下文。
例如：
/mention src/auth/session.ts
然后再问：
请只基于这个文件和它直接依赖的模块分析登录过期逻辑。
这比“你自己去整个项目找吧”更可控。尤其是大项目里，明确给入口文件能节省上下文，也能减少跑偏。
## 45. /new、/resume、/fork、/side 分别怎么用？
/new 用于同一个 CLI 里开新任务。任务无关时用它。
/resume 用于恢复以前的会话。你昨天做到一半，今天继续，可以用它。
/fork 用于从当前对话分出一条新线。比如你想尝试另一个实现方案，但不想污染主线。
/side 用于临时旁路提问。比如主任务还在跑，你想让 Codex 顺手检查计划有没有风险，可以开侧线。
这些命令解决的是“多任务和上下文管理”问题。新手一旦开始做长任务，就应该学。
## 46. Codex app 的 /plan-mode 和 CLI 的计划能力怎么理解？
Codex 最重要的习惯之一是复杂任务先计划。
Codex app 里用 /plan-mode。Codex CLI 里用 /plan。复杂任务先进入计划模式，再开始改文件。
什么时候该计划？跨多个文件、需求不清、会影响数据、要迁移架构、要改测试框架、要动权限和部署，都应该先计划。
什么时候不用？改一个文案、修一个明显 typo、加一行配置，不必把流程搞重。
## 47. Codex 的 /compact 和 Claude Code 的 /compact 思路一样吗？
思路相同：长对话压缩，保留关键上下文。
区别在于具体界面和行为可能不同，但新手记住一个原则就够：不要等模型已经明显忘事才压缩。长任务中间主动 /compact，并要求保留：
目标、约束、已改文件、关键决策、已运行测试、未解决问题。
压缩不是失败，是长任务的正常维护动作。
## 六、共同问题：怎么真的用好它们
## 48. 这 50 问应该怎么读，才不会越学越乱？
不要把 50 个问题当成命令大全背。新手最容易乱，是因为安装、规则文件、权限、上下文、代码审查、MCP、自动化全部混在一起学。
更好的读法是分三遍。
第一遍只看安装、登录、两边的 /status、Claude Code 的 /doctor、两边的 /init，目标是把工具稳定跑起来。
第二遍看 CLAUDE.md、AGENTS.md、权限、/diff、/review，目标是能让它在一个小任务里安全改代码。
第三遍再看 /compact、MCP、自定义命令、subagents、hooks，目标是把重复流程沉淀下来。
学这类工具不要贪快。先跑通一个小闭环，比同时收藏几十个命令更有用。
## 49. 新手写第一个任务，应该怎么描述？
用这个结构：
目标：我要实现什么。
范围：只允许改哪些文件或模块。
背景：为什么要改，当前问题是什么。
约束：不要做什么，不要碰什么。
验证：改完要跑什么测试，或者怎么人工检查。
输出：最后告诉我改了什么、怎么验证、还有什么风险。
例子：
请修复登录页空密码也能提交的问题。
范围只限 src/pages/login 和相关测试。
不要改后端接口。
改完运行登录相关测试；如果测试跑不了，说明原因。
最后用 diff 级别总结改动。
这种写法比“帮我优化登录”强很多。
## 50. 第一周应该练什么？
第一天，只练安装、登录、进项目、/status、让它读项目。
第二天，练 /init，把 CLAUDE.md 或 AGENTS.md 改成真正有用的项目说明。
第三天，练一个小修改：先计划，再改，再 /diff，再跑测试。
第四天，练 /review，学会让它找风险，而不是只让它总结。
第五天，练 /clear 和 /compact，理解任务边界和上下文维护。
第六天，给一个重复任务写自定义命令。Claude Code 可以从 .claude/skills/ 开始；Codex 可以先沉淀到 AGENTS.md 或 skill/工作流里。
第七天，回看这一周代理犯过的错，把真正重复的规则写进长期文件。到这里，你才算开始从“会用工具”变成“会管理工具”。
最后再提醒一句：别把代理当神，也别把它当搜索框。它更像一个会动手的同事。你给它边界、上下文和验收标准，它就能稳定产出；你只给它一句“帮我优化”，它也只能按自己的理解去猜。新手第一周真正要练的，不是背命令，而是学会把一件事交代清楚、看懂它做了什么，并且敢于用 diff 和测试把结果收回来。
## 相关链接
- [老爸的AI联萌](https://x.com/ChrisWangwy)
- [@ChrisWangwy](https://x.com/ChrisWangwy)
- [479](https://x.com/ChrisWangwy/status/2054797246709833952/analytics)
- [https://claude.ai/install.ps1](https://claude.ai/install.ps1)
- [https://claude.ai/install.ps1](https://claude.ai/install.ps1)
- [https://claude.ai/install.cmd](https://claude.ai/install.cmd)
- [$ARGUMENTS](https://x.com/search?q=%24ARGUMENTS&src=cashtag_click)
- [$ARGUMENTS](https://x.com/search?q=%24ARGUMENTS&src=cashtag_click)
- [@openai/codex](https://x.com/@openai/codex)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [1:33 PM · May 14, 2026](https://x.com/ChrisWangwy/status/2054797246709833952)
- [479 Views](https://x.com/ChrisWangwy/status/2054797246709833952/analytics)
---
*导出时间: 2026/5/14 16:32:18*