爆肝万字！这应该是全网最全的 Codex 实战教程了

最近这段时间我后台被同一个问题问麻了。Codex 到底怎么用CLI、App、VS Code 插件三个入口摆在那儿看起来都能用。plugins、skills、MCP、automations、AGENTS.md、子 agent、权限模式又一个个往外冒。你只是想让它帮你改个代码。结果它先给你塞了一整套新概念。不是哥们我只是想修个 bug怎么突然像在学一门新职业。。。所以我昨天专门花了一下午把 Codex 这套东西重新捋了一遍顺手录了一个比较完整的视频。录完之后我发现这里面其实有很多地方只看视频很容易滑过去。尤其是那些提示词模板、权限边界、版本管理、上下文管理还有什么时候该让 Codex 只读什么时候可以让它动手改代码。这些东西如果不写下来真的很容易看完就忘。所以我干脆把视频对应的文案重新整理成了这篇文章。不敢说多权威。但如果你是程序员或者你正在用 Codex、Claude Code、Cursor 这类东西做项目我觉得这篇应该能帮你少踩不少坑。这篇主要会讲这些内容Codex 的三大入口使用 Codex 的注意事项权限模式Codex 最佳实践提示词与 token 消耗的关系多模态能力版本管理上下文管理长期记忆skillspluginsMCP自动化一个完整案例我常用的 Codex 指令模板彩蛋那么咱们开始Codex 的三大入口回到 Codex 本身。现在 Codex 大概有三个主要入口Codex CLICodex AppCodex IDE 插件咱们一个个来说。第一个是 Codex CLI 。也就是命令行版本。如果你是程序员可以直接通过 npm 安装安装之后在项目根目录里输入就可以启动。如果你想更新也可以用CLI 的优点是轻量、直接、适合终端党。你在哪个项目目录打开它它就基于哪个项目开始工作。当我们让 Codex 第一次接触一个项目时可以先让它读取这个项目。一般我的提示词是这个习惯非常重要。很多人用 Vibe Coding 翻车不是模型不行是自己太着急让它改代码了。这种不翻车才怪。第二个入口是 Codex App这个我觉得更适合新手。直接从官网就可以下载macOS 和 Windows 都有安装包。因为 App 比 CLI 更像一个完整的 AI 编程工作台。你可以开新对话搜索历史管理插件安装 skills配置自动化。官方现在也把 Codex App 定位成多 agent 工作台。也就是说它不是只让你和一个 AI 聊天。而是让你可以同时开多个任务让不同 agent 在不同项目、不同分支、不同 worktree 里工作。如果你第一次用 Codex我更建议从 App 开始。因为 CLI 很爽但它对新手不太友好。目录、权限、命令、上下文、沙盒、git 状态这些东西混在一起很容易给人整懵。App 至少能让你有一个更清楚的工作台视角。第三个入口是 IDE 插件比如在 VS Code、Cursor 里直接用 Codex。这个适合你已经在写代码想让 Codex 在当前工程里辅助你处理某个文件、某个 bug、某个组件的时候使用。咱们以 VS Code 为例。直接在插件市场里搜索Codex安装插件即可。然后打开对应项目就可以在右上角找到 Codex 的图标。点击之后就能直接进入 Codex 的工作台。同时要注意如果你同时安装了 Codex App 和 Codex IDE 插件它们的数据是可以互通的。使用 Codex 的注意事项那第一次用 Codex应该怎么开始我建议你不要一上来就找一个公司核心项目练手。先找一个 demo 项目。或者找一个你自己不怕改坏的小项目。然后确认这个项目已经被 git 管理。如果还没有可以先通过以下指令初始化这样做的目的是保证万一 Codex 把你的代码改错了你还能还原回去。同时要注意当我们使用 Vibe Coding 进行编程时每次 Codex 修改了代码之后最好都做一次 git commit以防万一。所以一定要做好版本管理。另外第一次启动 Codex不要让它写代码。就让它读项目。给大家一个我常用的提示词这一步做完之后你再看它的理解准不准。如果它理解错了就纠正它。不要着急让它动手。你可以继续问这样的方式实测非常好用分享给大家。权限模式接着讲权限模式。这个东西很多人会忽略但我觉得它非常关键所以单独拿出来讲一下。我们知道Codex 是可以读取和修改你本地代码和文件的。这样就会涉及到本地文件安全的问题。比如万一 AI 直接把你电脑里很重要的文件删了那就麻烦了。所以为了避免这个问题Codex 里的权限模式通常可以分成三种。第一种是 默认权限默认权限最安全也可以说最保守。它可以读文件可以给你提出修改建议也可以提出要执行的 shell 命令。但是真正修改文件或者执行命令之前需要你主动批准。好处是安全。坏处是你不能离开。毕竟每一步你都得主动确认。第二种是 自动审查模式它比默认权限稍微激进一点。默认权限是AI 想改文件、想执行命令都要先问你。自动审查的意思是Codex 会先自己判断这个操作是不是安全。如果它只是修改当前项目里的普通代码或者执行一些常见命令比如安装依赖、跑测试、跑构建那它可能就会自动通过不用你每一步都点确认。这样做的好处是效率更高。比如你让 Codex 修一个 bug它可能会先读代码然后改代码然后跑测试再根据报错继续修改。如果每一步都要你确认其实就很打断节奏。但是自动审查也不是完全放开。如果 Codex 要做一些风险比较高的事情比如删除文件、访问项目外目录、读取敏感文件、联网下载东西或者执行一些危险命令它还是会停下来让你确认。所以自动审查更适合什么场景适合你已经比较熟悉这个项目也比较信任当前这次任务。你希望 Codex 能连续多干几步不要每一步都来问你。但你又不想完全放开权限。这个时候用自动审查就比较合适。它其实是一个折中的模式比默认权限更省心但比完全访问权限更安全。第三种是 完全访问权限这个模式就要谨慎了。你可以把它理解为把 Codex 的限制放到最小。在这个模式下Codex 可以更自由地读取文件、修改文件、执行命令甚至访问项目外的目录和网络。好处是执行效率最高。比如你让它做一个比较大的任务迁移项目、批量重构、安装依赖、跑脚本、跨多个目录改代码。它不需要一直停下来等你确认可以更像一个真正的开发助手一样连续把事情往下推进。但是风险也最大。因为一旦它理解错了你的意思或者执行了一个不该执行的命令就可能真的影响你本地的文件。所以我不建议大家日常一直开完全访问权限。尤其是陌生项目、刚 clone 下来的开源项目、公司核心项目或者里面有.env、密钥、token、配置文件的项目都不要随便开。更稳的做法是平时用默认权限。高效率的时候用自动审查。在你非常确定这个项目安全、任务明确而且你知道 Codex 接下来要做什么的时候再临时打开完全访问权限。用完之后最好再切回默认权限或者自动审查。所以这三个模式可以简单总结一下默认权限最安全但是需要你频繁确认。自动审查效率更高适合日常开发里的连续任务。完全访问权限能力最强但风险也最高只适合临时使用。Codex 最佳实践然后咱们来看使用 Codex 进行 Vibe Coding 的最佳实践。这里一共分成 4 步第一步指定范围。第二步指定状态。第三步指定验收标准。第四步随时中断。咱们一个个来看。第一步 指定范围不要让 Codex 在整个项目里瞎逛。尤其是大项目。你如果只想改登录页就把登录页相关文件告诉它。你如果只想查一个 hook就把 hook 文件和调用位置告诉它。在 App 或 IDE 里可以通过指定文件。在 CLI 里也可以直接把路径写清楚。比如这就比一句「帮我看看登录有啥问题」靠谱很多。第二步 指定状态也就是你要明确告诉它现在是只读还是可以修改。比如或者再或者你看这三句话对应的工作状态完全不一样。很多人用 Codex 出问题就是因为没有说清楚边界。第三步 指定验收标准比如这就叫验收标准。你不给验收标准它就只能按自己的理解收工。而 AI 的「我觉得完成了」和工程里的「真的完成了」经常不是一回事。第四步 随时中断如果你发现 Codex 开始往奇怪方向走不要硬等它做完。直接中断。在 AI 执行的过程中点击暂停按钮然后告诉它这就像带实习生一样。方向不对的时候要早纠偏。提示词与 token 消耗的关系然后咱们来看提示词与 token 消耗的关系。很多同学会觉得跟 Codex 说话是不是越短越好说的话越短token 消耗就越低其实不一定。短指令有时候反而更费 token。因为你说得太短Codex 就要自己搜索、自己猜、自己补上下文。你以为省事了。实际上它绕了一大圈token 消耗也就上来了。举个例子。比如你说这样说省事吧。但是 Codex 就会很痛苦。你要优化的是什么是 UI还是性能还是代码可维护性它只能猜。而它猜的这个过程token 消耗可能非常大。所以更靠谱的说法是指定具体的优化事项。比如这个指令就好很多。要记住在 Vibe Coding 的场景下最怕的就是让 AI 自由发挥。Codex 的多模态能力Codex 不只是能看文字。你也可以给它截图、设计图、报错截图、UI 问题截图。比如你看到页面上某个按钮被挤压了或者移动端布局错位了。你可以直接把截图丢进去复制粘贴或者拖拽过去都可以。然后说这个效果会比纯文字描述好很多。毕竟一图胜千言。版本管理再讲版本管理和回滚。Codex 改代码之前先看 git 状态。Git 是一个代码版本管理工具可以直接在官网下载。在每次 Vibe Coding 修改代码之前通过 Git 做好版本管理这是我非常建议大家养成的习惯。你可以直接通过 Git 指令或者可视化工具来做。也可以让 Codex 先看如果工作区已经有你自己写了一半的东西一定要小心。因为 Codex 可能会在这些文件上继续改。不是说不能改。而是你要知道它改了什么。每完成一个小任务就让它总结一次 diff。比如然后你自己看一眼 diff。不要直接闭眼提交。上下文管理接着讲上下文管理。这个也是 AI Agent 里特别关键的东西。Codex 每个对话都有上下文。你前面说过什么它做过什么读过什么文件改过什么东西都会逐渐堆进去。一开始这很爽。因为它记得你刚才干了什么。但时间长了之后上下文会越来越重。回答会变慢甚至开始混淆旧任务和新任务。也就是大家平常说的感觉 AI 变笨了。这时候你就要有意识地管理上下文。我的建议是每个对话只做一类任务。比如这个线程只修登录 bug。那个线程只做组件重构。不要在同一个线程里一会儿让它写页面一会儿让它查 CI一会儿又让它总结会议。这会把上下文搞得很脏。什么时候继续旧对话当这个任务和前面的上下文强相关。比如刚才修了一半测试还没过那就继续。什么时候开新对话当你要处理一个新问题或者旧上下文已经太乱。比如你刚做完登录现在要做支付。那就开新线程开一个新的对话框。同时让它在任务结束的时候做一次收尾总结。比如这个总结以后特别有用。因为你下次搜索历史或者重新打开这个线程的时候不需要从一堆碎片里找线索。你能直接看到这次任务的工程记录。这就是 Codex App 里搜索功能的价值。长期记忆说到长期记忆就要讲AGENTS.md。如果你用过 Claude Code可能会知道CLAUDE.md。在 Codex 里对应更常见的是AGENTS.md。你可以把它理解成写给 AI Agent 的项目说明书。Codex 会读取这些文件把里面的规则当成长期上下文。它可以有几层。全局层面可以放你的个人偏好。比如你希望它回答中文改代码前先给计划测试失败要说明原因。项目根目录可以放项目规范比如技术栈、启动命令、测试命令、代码风格、目录约定。子目录里也可以放某个模块的特殊规则比如这个目录是老代码不要重构公共接口。或者这个模块里所有请求都必须走统一封装。这东西非常有用。因为你不用每次都重复说一遍。比如你可以在项目根目录放一个AGENTS.md写成这样以后 Codex 进入这个项目就会带着这些规则工作。这就是长期记忆。把你的工作标准固化下来。把团队的代码规范、分支规范、测试规范、目录约定都写进去。这会比每次在群里重复提醒靠谱得多。skills然后是 skills。这个东西有多火我就不用多说了。现在几乎所有大模型产品都开始提供 skills 的功能。并且我也觉得这是 Codex 里非常值得研究的部分。很多人会把 skill 和 plugin 混在一起。其实不是一回事。skill 更像一套做事方法。它告诉 Codex遇到某类任务时应该按什么流程做检查什么风险用什么标准输出。比如你可以有一个前端 review skill。里面写清楚每次 review 前端代码要重点看组件边界、状态管理、接口错误处理、移动端适配、性能问题、XSS 风险。以后你让 Codex review它就不是泛泛地看一下。而是按这套标准来。你也可以有一个写作 skill。把你的文章结构、语气、禁用词、案例组织方式都写进去。以后你让 Codex 写稿子它就不需要每次重新适应你的风格。把这些东西写成 skill就变成了可以复用的工作流。Codex 中默认就有一个Skill Creator。利用它可以直接创建你自己的 skills。比如你可以让 Codex 帮你创建一个 skill也可以直接让它安装别人的 skills。比如你可以在 GitHub 上找到一个 skill然后直接跟 Codex 说它就可以帮你完成安装。plugins再讲 plugins。plugin 和 skill 最大的区别是skill 更像方法plugin 更像工具箱。插件可以让 Codex 连接更多外部工具和信息源。比如 GitHub、浏览器、文档、邮件、日历、电脑应用、各种 MCP 服务。一旦这些接上Codex 就不只是一个写代码的助手。它开始进入真实工作流。比如你可以让它看 GitHub PR 的 review comment也可以让它读取某个文档再检查项目里对应模块有没有受影响这就很像一个能在不同工具之间来回跑的 AI 同事。但我还是要强调一遍。能力越大边界越重要。插件不是装得越多越好。权限也不是给得越高越好。尤其是涉及公司仓库、邮件、聊天记录、文档权限的时候一定要注意数据边界。MCP然后是 MCP。这个词最近也很火。MCP 你可以先简单理解成一套让 AI 连接外部工具和数据源的协议。比如数据库、浏览器、知识库、设计工具、内部系统。以前 AI 想用这些东西每个工具都要单独适配。现在通过 MCP就更像有了一套统一的接口。Codex 接上 MCP 之后就能访问更多外部能力。比如查询数据库结构读取内部文档操作浏览器检索知识库当然不同环境支持什么 MCP要看你自己的配置和权限。我这里不建议大家一上来就折腾一堆 MCP。新手先把最基本的项目读写、权限、上下文、AGENTS.md、git 工作流搞明白。这些才是根本。MCP 是扩展。根本没打好扩展越多越容易乱。自动化再讲自动化。这个功能我觉得很多人会低估。自动化就是你给 Codex 一个任务再给它一个时间规则让它自己周期性执行。有点像定时任务。但它不是普通定时任务。因为执行任务的是一个 Agent。比如你可以让它每天早上总结昨天的提交你也可以让它每 30 分钟检查一次 PR 状态还可以让它每天晚上总结今天的 diff这类任务特别适合 Codex。因为它们重复、明确、有固定判断标准。自动化我也建议从只读任务开始。先让它汇报不要让它自动改。等你确认它的判断稳定再慢慢扩大权限。这里可以分两类理解。一种是 跟当前对话绑定的自动化比如你正在等部署结果。你可以让 Codex 10 分钟后回到这个线程继续检查。这种适合短周期、强上下文任务。另一种是 独立自动化比如每天早上检查项目提交。每周五生成项目周报。每天晚上总结错误日志。这种任务每次都是独立巡检不一定依赖当前对话。你可以这样判断如果任务需要接着当前对话继续就用当前线程自动化。如果任务每次都是固定巡检就用独立自动化。这样就比较好理解了。一个完整案例接下来我们用一个具体案例串起来。假设我要做一个番茄钟应用。先看看最后的实现效果一套完整的工程实践总共可以分成 6 步。很多人可能会说这么麻烦直接说一句不就行了吗这样能实现出来吗能。但效果大概率一般。更靠谱的方式是把 Codex 编程变成一套完整的工程实践。第一步先拆需求这一步你可以用 GPT也可以用 Codex。如果你还没想清楚我更建议先用 GPT。因为 GPT 更适合讨论和拆解。第二步让 Codex 读项目这一步很关键。因为同样是番茄钟在不同项目里写法不一样。有的项目用 React。有的用 Vue。有的用 Next.js。有的有自己的组件库。有的有自己的状态管理。Codex 必须先读项目才能按项目风格做。第三步让它小步实现第一版注意我这里没有让它一次性做一堆东西。没有历史统计。没有通知提醒。没有音效。没有复杂主题。先做核心功能。因为 Codex 做大任务最怕一口吃太多。第四步让它检查自己这一步非常有价值。让 Codex 写代码是一回事。让 Codex 站在 reviewer 角度再看一遍是另一回事。第五步再让它修第六步沉淀经验你看这一整套下来Codex 的工作质量会稳定很多。我常用的 Codex 指令模板这里我再给大家一套我自己比较常用的 Codex 指令模板。第一个读项目模板第二个修 bug 模板第三个执行修改模板第四个review 模板第五个任务收尾模板这几个模板你不用背。你只要记住背后的逻辑先读。再计划。再执行。再验证。再总结。这就是最朴素也最稳定的 Codex 工作流。彩蛋打开之后长这样里面包含了非常多的 Codex 配置。比如个性化、MCP、浏览器使用等等。这些配置后面可以慢慢研究。不过这里有个非常好玩的小功能就是之前Claude Code也弄过的宠物。只不过之前Claude Code的宠物有点虎头蛇尾。而 Codex 这个虽然没怎么宣传但我觉得做得还挺完整。选择「外观」拉到最后有一个宠物模块。里面包含了一大堆宠物同时也可以自定义宠物。只需要点击「唤醒宠物」你的宠物就会出现在电脑桌面上。有一种之前用电脑管家小篮球的即视感。如果你感觉 Codex 默认提供的宠物太丑了现在也有很多Codex 宠物市场。比如https://codex-pets.net/是不是感觉比官方的好看多了。。。安装也非常简单。比如安装我最喜欢的鸡哥。直接通过右侧的指令即可完成安装npx codex-pets add ikun当然了这块就是一个彩蛋。好玩归好玩。真正决定 Codex 好不好用的还是前面那些东西。新对话、搜索、插件、skills、自动化。这些才是 Codex APP 真正的工作流核心。总结今天的内容挺长了我看了下有 一万六千字 。当然视频也挺长的剪完之后也有 40 分钟。最后总结下AI 不是神。它是一个非常强的工具。但越是这种工具越需要你会用。新手最容易犯的错误就是给一个模糊任务然后期待它一次性做完。这是非常不靠谱的。真正靠谱的方式是先只读。再计划。再小步修改。再测试验证。再总结沉淀。把常用规则写进AGENTS.md。把重复标准做成 skills。把外部工具通过 plugins 和 MCP 接进来。把重复巡检交给自动化模块。复杂任务再拆给多个 agent 并行做。然后你自己负责方向、判断和验收。我觉得这才是 Codex 最有价值的地方。资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习