乐于分享
好东西不私藏

Codex 完整实用教程:从安装配置,到 AGENTS.md、Skills 和自动化,一篇讲清楚

Codex 完整实用教程:从安装配置,到 AGENTS.md、Skills 和自动化,一篇讲清楚

很多人已经从 Claude 切换到了 Codex,

但还是有人装了 Codex,不知道下一步该干什么。

入口太多,概念太多。App、CLI、IDE、Cloud、AGENTS.md、MCP、Skills、Automations 全堆在一起,

很容易越看越乱。

这篇我们就按实际使用顺序来:把 Codex 跑起来,让它完成一个任务,然后把规则、配置和工作流慢慢沉淀下来。

大致路线如下:

安装 App / CLI跑第一个任务写 AGENTS.md学会 /plan 和 /review配置 config.toml接入 MCP沉淀 Skill最后再做 Automation

先能用,再用顺,最后自动化。

Codex 介绍

Codex 不是普通代码补全工具。

补全工具更多是在你写代码时给建议,Codex 更像一个能围绕任务行动的 AI 编程 Agent。

它可以读项目、找文件、改代码、跑命令、看报错、继续修复、审查 diff,甚至帮你处理 GitHub 任务和 PR。

所以,用 Codex 时不要只说:

帮我优化一下这个项目

这种太空。

更好的方式是把任务交代清楚:

这是目标,这是相关文件,这是不能碰的边界,这是完成标准。请按这个范围修改,并运行测试验证。

把 Codex 当成一个需要带、需要配置、也需要持续改进的工程队友,你会更容易用出效果。

4 个入口

Codex 现在主要有四种入口:App、CLI、IDE 扩展、Cloud。

不用一次全掌握。选一个适合自己的入口,先把第一个任务跑通。

Codex App:新手优先

如果你刚开始用,建议从 Codex App 入手。

它有图形界面,适合本地项目、任务管理、查看 diff、多线程工作和管理 Skills、Plugins、Automations。

基本流程是:

  1. 下载并安装 Codex App
  2. 用 ChatGPT 账号或 OpenAI API Key 登录
  3. 选择项目目录
  4. 选择 Local
  5. 开始给 Codex 派任务

这里有个细节要注意:如果你用 API Key 登录,部分功能可能不可用,比如 cloud threads。具体以当前官方版本为准。

Codex CLI:程序员常用

如果你习惯终端,CLI 会更顺手。

macOS / Linux 可以用:

curl -fsSL https://chatgpt.com/codex/install.sh | sh

也可以用 npm:

npm install -g @openai/codex

或 Homebrew:

brew install --cask codex

Windows 可以用:

powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"

安装后运行:

codex

然后按提示登录。

CLI 适合修 bug、跑测试、看状态、调配置,也适合和 Git 工作流放在一起用。

IDE 扩展:适合边写边改

如果你常用 VS Code、Cursor 或 Windsurf,可以装 Codex IDE 扩展。

它的优势是不用离开编辑器。Codex 可以读取当前文件、选区和项目上下文,适合小范围修改、解释代码、补测试和审查变更。

Codex Cloud:适合后台任务和 GitHub

Codex Cloud 的入口是:

https://chatgpt.com/codex

它更适合 GitHub 任务、云端执行、查看日志、生成 PR,或者在 GitHub PR 评论里通过 @codex 触发任务。

如果你还是新手,不用急着上 Cloud。

先把本地 App 或 CLI 跑顺,比研究一堆高级入口更重要。

不要一上来就重构项目

第一次用 Codex,别让它“重构整个项目”。

先让它认识项目。

你可以这样问:

请先阅读这个项目,告诉我:1. 这个项目是做什么的2. 主要目录分别负责什么3. 如何启动项目4. 如何运行测试5. 新手第一次修改时最应该注意什么

这个任务不要求它写代码。

它的价值是让 Codex 先建立项目上下文,也让你看看它对项目的理解是否靠谱。

接着可以让它修一个明确的小问题:

请修复当前测试失败的问题。要求:1. 先运行测试,确认失败原因2. 找到最小修改范围3. 不做无关重构4. 修复后重新运行测试5. 最后总结修改了哪些文件,以及验证证据

这种任务边界清楚,结果也能验证,非常适合作为第一轮练习。

把工作说清楚

Codex 不是不能理解你,而是你要给它足够清楚的工作边界。

一个实用提示词,最好包含四件事:

目标:你到底要它做什么。上下文:相关文件、报错、文档在哪里。约束:哪些事不能做,哪些规则要遵守。完成标准:什么情况算完成。

比如:

目标:修复登录页表单提交失败后没有错误提示的问题。上下文:相关文件可能在 src/pages/login 和 src/components/form。后端会返回 message 字段,但页面目前没有展示。约束:不要重构整个表单系统。不要引入新依赖。保持现有 UI 风格。完成标准:登录失败时展示后端错误信息。成功登录逻辑不变。相关测试通过。最后总结修改文件和验证结果。

这比一句“优化登录页”稳定得多。

Plan 模式

任务一复杂,就不要急着让 Codex 写代码。

先让它计划。

CLI 里可以用:

/plan

也可以通过 Shift + Tab 切换 Plan 模式。

Plan 模式适合这类任务:

  • 跨多个文件
  • 需求还没完全想清楚
  • 涉及架构调整
  • 第一次接触大型代码库
  • 改错成本比较高

你可以这样发:

我想给这个项目增加订单导出功能。先不要写代码。请先:1. 阅读相关目录2. 判断会影响哪些模块3. 给出实现方案4. 列出风险点5. 提出需要我确认的问题

Plan 模式的作用不是让流程变复杂,而是把模糊需求先变清楚。

很多任务失败,并不是 Codex 写不好,而是需求一开始就没有定义好。

AGENTS.md

如果你每次都要重复说:

“用中文回答。”

“不要乱改文件。”

“测试命令是 npm test。”

“不要新增依赖。”

那这些话就该写进 AGENTS.md。

你可以把它理解成给 Codex 看的项目说明书。

它适合写:

  • 项目结构
  • 启动方式
  • 测试命令
  • lint 命令
  • 工程规范
  • PR 要求
  • 禁止事项
  • 完成标准

CLI 里可以用:

/init

生成初始模板。

一个简单版本可以这样写:

# AGENTS.md## 项目说明这是一个前端管理后台项目,主要用于订单、用户和商品管理。## 常用命令安装依赖:npm install启动开发环境:npm run dev运行测试:npm test运行 lint:npm run lint## 工程规范- 不要引入新依赖,除非用户明确同意- 不做无关重构- 修改前先理解现有代码风格- 新功能需要补充必要测试- 修 bug 优先做最小修改## 完成标准- 相关测试通过- lint 无新增错误- 总结修改文件和验证结果

AGENTS.md 可以分层:

  • 全局:~/.codex/AGENTS.md
  • 项目:仓库里的 AGENTS.md
  • 子目录:更具体目录里的 AGENTS.md

越靠近当前目录的规则,优先级越高。

不要一开始就写很长。

先写最核心的规则。等 Codex 重复犯同一个错,再让它复盘,把新规则补进去。

config.toml

Codex 的用户级配置文件是:

~/.codex/config.toml

项目级配置可以放在:

.codex/config.toml

常见配置包括默认模型、推理强度、审批策略、沙箱权限、MCP、Web search 和 feature flags。

一个简化示例:

model = "gpt-5.5"approval_policy = "on-request"sandbox_mode = "workspace-write"model_reasoning_effort = "high"web_search = "cached"

新手不要一上来就把权限全部放开。

先保持相对谨慎的权限设置,熟悉 Codex 的执行方式后,再对可信项目放宽。

凡是涉及删除文件、覆盖文件、调用外部服务、修改生产配置的操作,都应该多看一眼。

MCP

MCP 是 Model Context Protocol。

简单说,它让 Codex 能连接代码仓库之外的工具和上下文。

比如:

  • GitHub
  • Figma
  • Playwright
  • Chrome DevTools
  • Sentry
  • OpenAI Docs
  • 内部文档系统

什么时候需要 MCP?

不是工具越多越好。

当 Codex 需要的信息在仓库外面,而你又不想每次复制粘贴时,才值得接 MCP。

CLI 添加 MCP 的基本形式是:

codex mcp add <server-name> -- <stdio server-command>

例如:

codex mcp add context7 -- npx -y @upstash/context7-mcp

在 CLI 里可以用:

/mcp

查看当前可用 MCP 工具。

先接一两个真正能减少重复劳动的工具就够了。不要一上来把所有工具都接进去。

Skills

如果你反复使用同一套提示词,就该考虑 Skill。

Skill 本质上是可复用工作流。

它通常包含:

  • SKILL.md
  • 可选脚本 scripts/
  • 可选参考文档 references/
  • 可选资源文件 assets/

一个好的 Skill,不只是把提示词写长。

它会告诉 Codex:什么时候触发、输入是什么、输出是什么、执行步骤是什么、有哪些边界、特殊情况怎么处理。

Codex 可以用两种方式调用 Skill:

  • 显式调用:在提示词里提到 $skill-name
  • 隐式调用:Codex 根据 Skill 描述自动判断

你可以用内置的 $skill-creator 创建 Skill。

比如:

$skill-creator帮我创建一个 release-note Skill。每次触发时,读取最近 git commit,总结变更,按功能、修复、风险、验证方式输出发布说明。

Skills 适合这些场景:

  • PR 审查
  • Release Note
  • 日志分析
  • 事故复盘
  • 迁移计划
  • 标准调试流程
  • 内容选题
  • 数据分析报告

个人 Skill 通常放在:

$HOME/.agents/skills

团队共享 Skill 可以放在仓库里:

.agents/skills

有个简单判断标准:

如果你已经第三次复制同一段提示词,就该考虑把它做成 Skill。

Automations

Skill 定义方法,Automation 定义时间表。

如果一个流程已经稳定,不需要你每次手动引导,就可以考虑自动化。

Codex App 里的 Automations 可以配置:

  • 运行项目
  • 执行提示词或 Skill
  • 运行频率
  • 执行环境
  • 是否使用独立 git worktree

适合自动化的任务包括:

  • 每天总结最近 commit
  • 定期扫描潜在 bug
  • 自动生成发布说明草稿
  • 检查 CI 失败原因
  • 生成站会摘要
  • 定期整理项目 TODO

但别太早自动化。

一个任务如果手动跑 10 次都不稳定,自动化只会把问题放大。

更稳的顺序是:

手动跑顺。沉淀成 Skill。再做 Automation。

Slash 常用命令

不用一次背完所有命令。

这些先够用:

/init

生成 AGENTS.md 初始模板。

/plan

复杂任务先规划。

/status

查看当前会话状态、配置和 token 使用情况。

/review

让 Codex 审查当前工作区变更。

/diff

查看当前 Git diff。

/compact

压缩长会话,减少上下文膨胀。

/resume

恢复历史会话。

/fork

从当前会话分叉出新线程。

/model

切换模型和推理设置。

/mcp

查看 MCP 工具。

/skills

浏览和使用 Skills。

/permissions

调整 Codex 不需要确认就能执行哪些操作。

刚开始,记住 /init、/plan、/status、/review、/compact 就够了。

Codex 适合做什么

Codex 最适合边界清楚、能验证的任务。

比如:

  • 修复明确 bug
  • 写测试
  • 整理项目结构说明
  • 小范围重构
  • 批量改文案
  • 更新文档
  • 生成 Release Note
  • 审查代码变更
  • 根据报错定位问题
  • 给已有功能补测试

它不适合一上来就做这些事:

  • 大型架构重构
  • 需求极度模糊的新产品
  • 没有测试、没有文档、没有边界的复杂项目
  • 高风险生产操作
  • 需要强实时协作的结对编程
  • 你自己都没想清楚的功能设计

Codex 可以帮你执行很多事。

但方向、边界和验收标准,还是要你来定。

避坑指南

把 Codex 当普通聊天机器人,是第1个坑。

它不只是回答问题,它可以执行任务。你要给它工作单元,而不是随口聊两句。

提示词太空,是第2个坑。

“优化一下”通常不会有好结果。目标、上下文、约束、完成标准写清楚,结果会稳定很多。

不写 AGENTS.md,是第3个坑。

如果一条规则你已经重复说过三次,它就不该继续留在聊天里。

不让 Codex 跑测试,是第4个坑。

代码写完不等于完成。能验证,才算真正完成。

权限放太开,也很危险。

新手不要一上来就给全自动权限。先看懂它会执行什么,再慢慢放开。

还有一个常见问题:一个线程聊到底。

一个线程最好对应一个任务。任务分叉时用 /fork,上下文太长时用 /compact。

自动化也别太早上。

不稳定的流程不要做 Automation。先手动跑顺,再沉淀。

第三方插件和 Skill 也别乱装。

只装真正解决问题的能力。来源不清楚的仓库,先别急着用。

速成路线

  1. 安装 Codex App 或 CLI
  2. 选一个真实项目,让 Codex 解释项目结构
  3. 让 Codex 修一个小 bug,要求它跑测试并总结
  4. 创建 AGENTS.md,写入项目命令和基本规则
  5. 学会 /plan、/status、/review、/compact
  6. 配置 config.toml,固定常用偏好
  7. 接入一个真正有用的 MCP,比如文档、GitHub 或浏览器工具
  8. 把重复流程做成 Skill
  9. 把稳定 Skill 做成 Automation

很多人一上来就研究 MCP、插件、自动化,结果连第一个本地任务都没跑好。

顺序反了,就会越用越累。

最后

Codex 的核心价值,不是“让 AI 替你写代码”。

它更重要的价值,是把软件开发里的重复劳动,变成可描述、可执行、可验证、可沉淀的工作流。

你越会定义任务,它越有用。

你越会写规则、补测试、沉淀 Skill,它越稳定。

参考资料:

  • OpenAI Codex Quickstart:
    https://developers.openai.com/codex/quickstart
  • OpenAI Codex Best Practices:
    https://developers.openai.com/codex/learn/best-practices
  • Codex CLI Slash Commands:
    https://developers.openai.com/codex/cli/slash-commands
  • Codex Config Basics:
    https://developers.openai.com/codex/config-basic
  • Agent Skills:
    https://developers.openai.com/codex/skills
  • Codex MCP:
    https://developers.openai.com/codex/mcp

相关学习资料