文章目录
-
- 前言
- [一、Codex 是什么，适合谁用](#一、Codex 是什么，适合谁用)
- 二、开始前需要准备什么
- [三、先理解 Codex 的工作方式](#三、先理解 Codex 的工作方式)
- 四、常用命令：先记住这几个就够了
- [五、Codex 的四种常见入口](#五、Codex 的四种常见入口)
- [六、MCP 是什么，为什么它能把 Codex 从"会写代码"变成"会做事情"](#六、MCP 是什么，为什么它能把 Codex 从“会写代码”变成“会做事情”)
- [七、Skills：让 Codex 具备可复用的专长](#七、Skills：让 Codex 具备可复用的专长)
- 八、从"会用"到"用好"：几个很有价值的进阶工作流
- [九、生态扩展：OpenSpec 与社区 Superpowers](#九、生态扩展：OpenSpec 与社区 Superpowers)
-
- [1. OpenSpec：适合把 AI 开发流程做得更规范](#1. OpenSpec：适合把 AI 开发流程做得更规范)
- [2. Superpowers：适合强化工作流纪律](#2. Superpowers：适合强化工作流纪律)
- [十、使用 Codex 时最容易踩的坑](#十、使用 Codex 时最容易踩的坑)
- 十一、总结
- 参考链接
前言
这两年 AI 编程工具很多，但真正能进入开发流程、而不是只停留在聊天窗口里的并不多，Codex 算是其中一个。它不只是补全代码，也不只是回答问题，而是可以在项目上下文里读文件、改代码、执行命令、做审查，并通过外部工具把任务继续往前推进。
第一次上手 Codex，通常会卡在两个地方：不知道从哪里开始，以及不知道哪些能力值得优先学。更实际的学习顺序其实很简单，先跑通 安装 和 启动，再熟悉 常用命令、AGENTS.md 和审批机制，最后再去理解 MCP、Skills、Codex App 和多智能体协作。文中涉及的时效性信息，已经结合截至 2026 年 4 月 12 日 的公开资料做了校验；模型列表、权限策略和部分入口后续仍可能继续更新，实际使用时请以官方页面为准。
一、Codex 是什么，适合谁用
OpenAI 对 Codex 的定位，已经不只是"能写代码的模型"，而是一个覆盖 CLI、IDE、App 和 Cloud 的编码代理。它更适合下面这些场景：
- 你要快速理解一个陌生项目，想让 AI 先帮你读结构、找入口、梳理依赖。
- 你要做小到中等规模的开发任务，希望 AI 不只是给建议，而是真的去修改文件、执行命令、补测试。
- 你要做代码审查、排查问题、整理工作流，希望 AI 能参与工程化步骤，而不是只停留在聊天窗口里。
- 你希望把
GitHub、Figma、Vercel、Supabase等外部系统接进同一套开发流程。
如果你只是偶尔问几个语法问题，那么普通聊天模型已经够用；但如果你想让 AI 更像一个"会干活的开发搭子"，Codex 才更值得花时间了解。
二、开始前需要准备什么
对新手来说，先把下面 4 件事准备好：
- 一个可用的
OpenAI/ChatGPT账号。 - 本地
Node.js环境。 - 基本的
Git使用能力。 - 一个准备让 Codex 操作的项目目录。
- 安装 Node.js
Codex CLI 依赖 Node.js 运行，所以第一步是安装 Node.js。
- 下载地址：Node.js 官网
- 安装完成后，在终端执行：
bash
node -v如果能够正常返回版本号，例如 v18.x 或更高版本，说明运行环境已经就绪。
- 安装 Codex CLI
Codex 的官方开源仓库地址如下：
CLI 安装命令非常直接：
bash
npm install -g @openai/codex安装完成后，执行下面的命令验证：
bash
codex --version如果能看到版本号，就说明 CLI 已经安装成功。
- 首次启动 Codex
进入任意一个项目目录，在终端执行：
bash
codex首次启动时，通常会引导你登录 ChatGPT 账号或按当前配置完成鉴权。登录成功后，Codex 就能在当前目录中工作。
这里有一个很重要的认知：Codex 默认不是"无脑全权限"运行。它会根据当前会话模式、沙箱规则和审批策略来决定哪些操作可以直接执行，哪些操作需要你确认。这一点在后面讲权限和 MCP 时尤其关键。
三、先理解 Codex 的工作方式
很多人第一次用 Codex，会把它当成"更强一点的聊天窗口"。这是最容易低估它的地方。
Codex 的核心不是单轮回答，而是 基于上下文持续执行任务。它会结合下面几类信息来工作：
- 当前项目目录下的文件和代码。
- 你的对话指令。
- 项目约束文件，例如
AGENTS.md。 - 当前审批模式、沙箱权限和规则配置。
- 已接入的 MCP 工具、skills、插件或自动化工作流。
换句话说，Codex 不是只回答"怎么写"，而是会进入"怎么做"。
权限与审批为什么重要
截至 2026 年 4 月 12 日，官方对 Codex 的一个强调点就是"默认安全、可配置扩展"。默认情况下，Codex 会受限于当前项目目录和权限策略；像联网、安装依赖、访问系统敏感目录之类的动作，通常需要审批。
这套机制的意义非常实际：
- 你可以放心让它先读项目、分析问题，而不是一上来就给完全权限。
- 当它需要执行高风险命令时，你能明确看到它想做什么。
- 团队协作时，你可以通过规则和约束统一代理行为。
对于初学者，一个稳妥建议是：
先用保守权限模式熟悉，再逐步放开。不要一开始就追求"全自动"，否则容易把试用阶段变成踩坑阶段。
为什么建议尽早使用 AGENTS.md
AGENTS.md 可以理解为"项目级使用说明书"。你可以通过 /init 让 Codex 先通读当前目录，再把关键约束写入这个文件，后续会话都会把它当作上下文的一部分。
它特别适合写这些内容：
- 项目结构和关键目录说明。
- 代码风格约束。
- 测试、构建、发布命令。
- 哪些文件不要乱改。
- 团队协作习惯和命名约定。
如果你用 Codex 处理的是一个持续维护的项目，而不是一次性试验项目，那么
AGENTS.md基本属于越早建越划算。
四、常用命令：先记住这几个就够了
Codex 的斜杠命令会随着版本演进而调整，但对日常使用来说，下面这几个最值得优先掌握。部分版本里会看到 /approvals，也有版本会把相关概念进一步归并到更明确的权限配置中，所以以你当前客户端实际显示为准。
| 命令 | 作用 | 典型用法 |
|---|---|---|
/model |
切换模型与推理强度 | 在速度优先和质量优先之间切换 |
/approvals |
调整审批和权限模式 | 控制只读、自动编辑、完全访问等模式 |
/review |
审查当前代码改动 | 提交前做一次 AI 自查 |
/new |
开新对话 | 切换任务、避免旧上下文干扰 |
/resume |
恢复历史会话 | 接着之前未完成的任务继续做 |
/init |
生成或更新 AGENTS.md |
让 Codex 更懂你的项目 |
/compact |
压缩上下文 | 长会话里减少上下文膨胀 |
/mcp |
查看或管理 MCP 工具 | 检查当前可用外部能力 |
如果你只打算先掌握最实用的三项，我建议从这三个开始：
/init：把项目规则讲清楚。/review：让 Codex 参与代码自查。/compact：避免长对话越聊越"跑偏"。
和模型相关的界面也会随着版本更新不断变化，所以这里更建议你记住"会切换、会查看、会根据任务选推理强度"这个使用思路，而不是死记某个时刻的模型列表。
五、Codex 的四种常见入口
截至 2026 年 4 月 12 日，Codex 已经不只是一个命令行工具，而是逐步形成了多入口协同的使用方式。
CLI：最适合开发者的核心入口
CLI 仍然是最推荐的入口，因为它最接近真实开发流程：
- 能直接操作本地项目。
- 能结合终端命令、Git、测试和构建流程。
- 对权限、规则、MCP、skills 的控制更细。
如果你习惯在终端里工作，CLI 基本就是最自然的选择。
IDE：更适合减少上下文切换
如果你更喜欢在编辑器中完成大部分工作，那么 IDE 集成会更舒服。官方资料已经明确覆盖 VS Code、Cursor、Windsurf 等入口，相关资源里也持续扩展到更多 IDE 场景。
它的价值在于：
- 边看代码边与 Codex 协作。
- 减少"终端 + 编辑器 + 浏览器"来回切换。
- 更适合逐文件、逐模块的小步迭代。
Codex App：适合管理更长、更复杂的任务
OpenAI 在 2026 年 2 月 2 日 正式发布了 Codex App，并在 2026 年 3 月 4 日 更新中宣布 Windows 版本可用。这个入口的重点不是"把 CLI 套个壳"，而是更偏向一个 agent command center：
- 可以同时管理多个代理。
- 可以并行运行任务。
- 能配合隔离 worktree 和可审阅 diff 工作。
- 更适合长周期、多步骤、多人协作的开发任务。
如果你只是写一点小功能，CLI 足够；但如果你开始进入多任务并行、长期上下文维护、批量代码审查，App 的价值会明显放大。
下面这些界面截图，能更直观看到 Codex App 在设置、任务规划和运行视图上的风格：
Codex App 的价值不只是把命令行做成图形界面，而是让它成为任务规划和执行协同的入口。下面这张图是一次实际项目流程的拼接示意：顶部是 Codex App 中的需求拆解与任务推进，中间是 Navicat 里的 MySQL 商品表，底部是本地浏览器中的页面结果。它更适合用来说明一次小项目从需求生成、数据落库到页面联调的完整链路，而不是展示 Codex App 的单一界面能力。
Cloud / Web：适合跨设备和轻量协作
Codex 也可以通过云端入口使用：
云端入口的好处是：
- 不依赖固定设备。
- 适合快速发起任务或查看历史任务。
- 和 App、CLI、IDE 形成联动。
如果你想看使用量或额度信息，也可以在相关设置页面查看：
六、MCP 是什么，为什么它能把 Codex 从"会写代码"变成"会做事情"
MCP，全称 Model Context Protocol，可以把它理解成一套让 AI 安全调用外部工具和服务的标准接口。对 Codex 来说，MCP 的价值非常直接：它不再只依赖本地文件，而是可以连接外部系统，把"分析"推进到"操作"。
典型例子包括：
GitHub：查看仓库、PR、Issue、提交记录。Figma：获取设计稿和视觉参考。Vercel：连接部署流程。Supabase：接入数据库、后端服务和开发环境。
这也是为什么很多人会感觉 Codex 在"工程化场景"里明显强于普通聊天机器人。它不只是会解释，而是开始能串联工作流。
不过这里一定要强调一个原则：MCP 接得越多，越要重视权限边界。新手最容易犯的错误，就是一看到能接很多系统，就把权限一次性全开。更稳妥的做法是：
- 先接最刚需的 1 到 2 个系统。
- 优先只开只读或低风险操作。
- 确认工作流稳定后，再逐步放开写操作。
七、Skills：让 Codex 具备可复用的专长
如果说 AGENTS.md 是项目级规则，那么 skills 更像"可复用的专业工作流模块"。
OpenAI 已经开源了官方技能目录：
截至当前版本，官方的几个要点值得记住：
.system目录下的 skills 会随新版 Codex 自动安装。- 你可以在 Codex 中通过
$skill-installer安装 curated 或 experimental skills。 - skills 不只是提示词，还可以包含脚本、资源文件和工作流程说明。
这类能力对下面几种任务尤其有帮助：
- 前端页面生成与视觉对齐。
- 文档生成与规划拆解。
- 图像处理。
- 项目管理、部署、测试等固定流程。
如果你需要额外能力，也可以安装社区 skills。例如你笔记里提到的 pptx 类技能，就很适合处理演示文稿、模板和自动化生成任务。
bash
$skill-installer https://github.com/anthropics/skills/tree/main/skills/pptx需要注意的是：官方 skills 和 社区 skills 是两件事。官方技能更强调兼容性和持续维护；社区技能往往更灵活，但最好先确认适配情况，再放进长期工作流。
如果你主要用 Codex 做前端、文档和专项任务，skills 的使用体验会非常明显，因为它本质上是在给代理增加"现成的方法论"。下面两张图，分别对应技能搜索安装和显式调用的典型界面：
八、从"会用"到"用好"：几个很有价值的进阶工作流
用 /review 让 Codex 参与代码审查
这是最容易马上提升效率的用法。很多人把 AI 主要用在"写代码"，但在实际开发中，发现问题 往往比 生成代码 更值钱。你可以在修改完成后，让 Codex 先做一轮检查：
- 有没有明显的语法问题。
- 有没有逻辑缺陷或边界条件遗漏。
- 有没有测试缺口。
- 有没有潜在的权限、安全、并发风险。
先让 AI 做第一轮筛查，再进入人工 Review，会明显更高效。
用 Worktree 和多代理并行处理任务
Codex App 的一个重要方向，就是让多个代理在隔离工作区中并行推进任务。这个思路很适合下面这些场景：
- 一个代理负责实现功能。
- 一个代理负责代码审查。
- 一个代理负责测试或回归检查。
- 一个代理负责文档整理。
本质上，它把"一个人同时切很多上下文"的痛苦，改造成"多个代理各做各的，再统一收口"。对复杂项目来说，这会比单线程聊天高效得多。
把设计、开发、部署串成一条链路
当你把 Figma skill、MCP、部署平台 和 项目规则 接起来之后，Codex 的价值会进一步放大。一个完整工作流通常会变成：
设计输入 -> 生成实现方案 -> 修改代码 -> 运行验证 -> 代码审查 -> 部署或提交 PR
这也是为什么现在很多团队不再把 Codex 当"辅助答题工具"，而是把它看作开发流程中的一个协作者。
九、生态扩展：OpenSpec 与社区 Superpowers
这一部分不是 Codex 的"必装项"，但如果你已经不满足于基础使用，它们会很值得关注。
1. OpenSpec：适合把 AI 开发流程做得更规范
OpenSpec 更像一个 spec-driven development 工作流工具。它把一次改动拆成更清晰的几个工件：
proposal.md：为什么要做这次改动。specs/：需求增量说明。design.md：技术设计。tasks.md：执行清单。
它的价值不在于"替代 Codex"，而在于给 Codex 这样的代理提供更清晰的结构化输入。尤其是在多人协作、需求频繁变化、老项目维护场景里，这种结构化方法会比"想到哪改到哪"稳很多。
2. Superpowers：适合强化工作流纪律
superpowers本质上是一套强调流程纪律的社区技能体系，例如：
- brainstorming
- writing-plans
- systematic-debugging
- using-git-worktrees
- verification-before-completion
这类工具的优势是：它不只是让 AI 更能干，而是让 AI 更"守流程"。比如先做需求澄清、再写计划、再实施、最后验证，这种方式对复杂任务尤其有帮助。
但同样要注意：Superpowers 属于社区扩展，不是 Codex 官方默认能力。如果你打算长期使用，建议先挑最符合自己习惯的几个，再逐步纳入工作流。
bash
Fetch and follow instructions from https://raw.githubusercontent.com/obra/superpowers/refs/heads/main/.codex/INSTALL.md
十、使用 Codex 时最容易踩的坑
一上来就开完全权限
很多人为了"省一次确认"，直接把权限开到很高，最后反而因为误操作、错误安装或无关改动把项目搞乱。更好的方式是先从保守模式开始，等你摸清自己的使用节奏后再逐步放开。
指令太泛，目标太虚
像"帮我优化一下这个项目""帮我重构一下"这种指令，对人都不够清楚，对代理更不清楚。更有效的说法应该包含：
- 目标是什么。
- 不要动什么。
- 验收标准是什么。
- 是否允许运行命令、联网或安装依赖。
把官方功能和社区扩展混为一谈
这里最容易混淆的是边界。Codex CLI、Codex App、MCP、openai/skills 这些属于官方能力；而 Superpowers、部分第三方 skills、OpenSpec 等更适合作为生态扩展来看。把这层关系理清后，很多配置和使用决策都会简单很多。
盯着模型列表不放，忽略工作流
模型当然重要，但对多数开发者来说，真正决定体验上限的，通常不是"今天又多了哪个模型"，而是：
- 你的项目规则是否清楚。
- 你的审批策略是否合理。
- 你的技能和工具链是否接好了。
- 你的任务是不是拆得足够清晰。
换句话说，工作流往往比模型名字更重要。
十一、总结
Codex 值得投入时间，不是因为它会写代码，而是因为它开始具备"进入工程流程"的能力。它可以理解项目上下文，接受规则约束，连接外部工具，并在审批边界内持续推进任务。这和传统的代码补全工具已经不是一个层级的问题。
如果是第一次系统使用 Codex，比较稳的路径是：
- 先用
CLI跑通安装、登录和基础项目操作。 - 把
/init、/review、/compact这几个高频命令用熟。 - 把
AGENTS.md、审批模式和权限边界理顺。 - 再逐步接入
MCP、skills、Codex App 和多代理协作。
真正拉开差距的，通常不是模型名称本身，而是你有没有把规则、权限、工具链和任务拆解配合起来。把这几件事做好之后，Codex 才会从一个"能回答问题的 AI"，变成一个真正能参与开发的工程代理。