loading image

想少走弯路?一文帮你从零上手Codex

Posted by Enovace on June 25, 2026

想少走弯路?一文帮你从零上手Codex

Banner

如果你刚开始用 AI 写代码,我不建议你一上来就追 Hermes,也不建议你直接冲 Claude Code。

我更推荐你先用 Codex。

不是因为 Codex 永远最强,也不是因为另外两个不好。Claude Code 很强,Hermes 也有自己的爽感。但对 AI 编程小白来说,第一问题不是“哪个工具天花板最高”,而是:

你能不能看懂它在干什么?

你能不能控制它?

它做错时,你能不能把它拉回来?

这才是入门门槛。

很多人第一次用 coding agent,会被一堆名词劝退:CLI、IDE、Cloud、Worktree、Sandbox、Skill、Plugin、MCP、Plan、Goal、Diff。看起来都重要,但不知道先学哪个。

Codex 的好处是,它更像一个完整的 AI 工作台。它把入口、权限、过程、改动、验证和扩展都摆在你面前。你可以从一个可视化 App 开始,再慢慢进入 IDE、CLI、Cloud 和插件生态。

对小白来说,最重要的不是马上用上最猛的 agent,而是先建立正确的 AI 协作习惯。这篇只讲一件事:从 0 开始,怎么理解 Codex,怎么用它,什么时候用 /plan、/goal、skill 和插件。

图像


一、为什么 AI 小白最容易被 coding agent 劝退

普通 AI 聊天是“你问,它答”。

Coding agent 不是。它会进入项目,读文件,改文件,运行命令,查看报错,再继续修改。

所以你面对的不是一个答案,而是一连串动作。

小白最容易卡在五个地方:1. 入口太多:App、IDE、CLI、Cloud,不知道从哪开始。 2. 名词太多:Agent、MCP、Plugin、Skill、Worktree、Diff,全都挤在一起。 3. 风险感太强:担心它乱改项目、乱装依赖、乱跑命令。 4. 反馈太专业:终端日志、报错堆栈、diff 对新手不友好。 5. 需求说不清:只会说“帮我优化一下”“帮我做个网站”。

所以小白真正需要的,不是一个“看起来最强”的工具,而是一个能帮你建立秩序的工具

Codex 的优势就在这里:它把很多关键动作拆开了,让你能看见、能理解、能介入。


二、为什么我更推荐小白先用 Codex

我推荐 Codex,不是因为它在所有场景都压过 Hermes 和 Claude Code。

工具强弱会变。今天这个更新,明天那个追上。新手没必要一开始就卷到这个层面。

我更看重五件事。第一,入口完整。

你可以从桌面 App 开始,看见项目、线程、终端、diff、权限和插件。熟悉后再进 IDE 插件、CLI、Cloud。这个路径符合新手学习顺序。

第二,过程可见。

Codex 不只是给答案。它读了什么、改了什么、跑了什么命令,你都能追踪。可见,才有控制感。

第三,权限边界清楚。

Codex 能读文件、改文件、跑命令,也可能联网或连接外部工具。它通过权限和 sandbox 限制范围。新手不需要一上来开最大权限,先让它在小范围里做对。

第四,/plan 和 /goal 很适合新手。

/plan 适合任务还没想清楚时使用。先让 Codex 读上下文、问问题、拆步骤,不要急着开工。

/goal 适合长任务。你给它一个明确目标,它持续围绕这个目标推进。

记住一句话:/plan 是开工前的地图,/goal 是长任务里的方向盘。第五,skill 和插件让能力可以逐步打开。

你不用一开始理解全部扩展机制。先会做一次任务,再把重复任务沉淀成 skill,最后再用插件、MCP、App 连接外部工具。


三、Codex 到底是什么

Codex 是 OpenAI 的 AI coding agent。

人话版:它不是只会聊天的 AI,而是一个能进入项目现场做事的 AI 助手。

它可以:

  • 解释陌生项目;
  • 找 bug;
  • 改代码;
  • 补测试;
  • 跑 lint、test、build;
  • 看 diff;
  • 做 code review;
  • 写文档;
  • 处理表格、PPT、PDF、图片等非代码产物;
  • 通过插件连接外部工具。

但不要把它理解成“自动程序员”。

Codex 很强,但你仍然要负责三件事:

  • 目标是什么;
  • 边界在哪里;
  • 怎样算完成。

你说“帮我优化一下”,它很容易跑偏。

你说“把首页首屏加载时间降到 1 秒以内,不改 API,优先最小改动,改完跑检查并报告结果”,质量就完全不同。

Codex 不怕任务难,怕的是任务又大又空。---

四、先安装:App、IDE、CLI、Cloud 怎么选

新手推荐顺序:

Codex App → IDE 插件 → CLI → Cloud。

图像

  1. Codex App:最适合新手第一站

Codex App 支持 macOS 和 Windows。安装后可以用 ChatGPT 账号登录,也可以用 OpenAI API key 登录。用 API key 时,部分和 ChatGPT 计划绑定的功能可能不可用。

第一次打开 App,建议这样做:

  1. 选一个不太重要、最好有 Git 的项目;
  2. 选择 Local;
  3. 第一条 prompt 只让它解释项目,不要改文件;
  4. 打开 diff 和终端,观察它怎么工作;
  5. 熟悉后再让它做小改动。

第一条 prompt 可以这样写:

请先不要修改文件。
帮我理解这个项目:它做什么,入口文件在哪,启动/测试/构建命令是什么,如果我要改首页应该先看哪些文件。
  1. IDE 插件:适合边看代码边协作

如果你常用 VS Code、Cursor、Windsurf,IDE 插件更自然。

你可以把正在看的文件、选中的代码直接作为上下文,也可以用 @文件名 引用文件。

适合这种任务:

看一下 @LoginForm.tsx 和 @auth.ts。
先解释当前登录流程,再给一个最小修改方案。
  1. CLI:适合终端用户

Codex CLI 适合习惯终端的人。

进入项目目录后运行:

codex

CLI 信息密度高。新手不是不能用,但我不建议第一站就从 CLI 开始。

  1. Cloud:适合更长、更并行的任务

Cloud 适合远程运行、后台执行、并行任务。

但先理解本地 Local、Worktree、diff、权限,再用 Cloud,会顺很多。


五、Codex App 里最重要的几个板块

不用一开始看懂所有按钮,先抓住这几个。

  1. Project

项目就是 Codex 当前工作的文件夹。

打开错目录,Codex 就会缺上下文。第一次用,先确认它是不是在正确项目里。

  1. Thread

线程是一组围绕同一任务的对话和操作。

不要把所有需求塞进一个线程。解释项目、修 bug、写文章、重构模块,最好分开。

一个线程解决一个主要目标。3. Local、Worktree、Cloud

Local:直接在当前项目里工作,适合小改动和解释类任务。

Worktree:在独立 Git 工作区里改,适合大改动和试错。

Cloud:远程跑任务,适合更长、更并行的工作。

新手记住:小任务 Local,大改动 Worktree,熟悉后再 Cloud。

  1. Diff

Diff 是你验收 AI 工作的地方。

不要只看 Codex 的总结。总结是它说的,diff 才是它实际改的。

你至少要看:

  • 改了哪些文件;
  • 有没有越界;
  • 有没有删掉不该删的东西;
  • 有没有把小问题改成大工程。
  1. 终端

终端用来验证结果。

比如:

npm test
npm run lint
npm run build

你不需要马上看懂所有日志。先看命令是否成功,有没有 error,Codex 有没有根据错误继续修。

  1. 浏览器、Computer Use、artifact 预览

内置浏览器适合检查网页。Computer Use 适合操作桌面 App。artifact 预览适合 PDF、表格、PPT、图片等产物。

这些能力有用,但权限更敏感。新手先用窄任务试,不要一上来全开。

  1. 权限和 sandbox

Approval 决定 Codex 什么时候问你。

Sandbox 决定它能读写哪里、能不能联网。

默认原则很简单:

权限够用就别开大。需要联网、写项目外文件、操作桌面 App 时,再按任务授权。


六、一次 Codex 任务是怎么发生的

一次 Codex 任务通常是这个循环:

图像

  1. 你给目标;
  2. 它读上下文;
  3. 它制定动作;
  4. 它调用工具;
  5. 它修改文件;
  6. 它运行检查;
  7. 它总结结果;
  8. 你看 diff 和验证结果,再决定下一步。

所以不要把 Codex 当成“更会回答的 ChatGPT”。

更好的用法是:

你给目标,它给方案;你给约束,它执行;它给 diff,你验收;它跑检查,你看结果;它出错,你让它解释和修正。

这才是 agent 协作。


七、最重要的提示词公式

只记一个公式:

目标 + 上下文 + 约束 + 完成标准。

也就是:

  • 目标:你要改变什么;
  • 上下文:哪些文件、报错、截图、背景重要;
  • 约束:不能改什么,要遵守什么;
  • 完成标准:怎样算做完。

模板 1:解释项目

请先不要修改任何文件。

目标:帮我理解这个项目。
上下文:你可以读取当前项目目录。
约束:用新手能听懂的话解释。
完成标准:说明项目做什么、主要目录、入口文件、启动/测试/构建命令,以及我要改首页应该先看哪些文件。

模板 2:修 bug

目标:修复登录后刷新页面又回到未登录状态的问题。

上下文:复现步骤是打开 /login,登录成功后刷新页面,页面又回到未登录。
约束:不要改 API 返回结构,优先最小改动,新增依赖前先解释原因。
完成标准:找到根因,给出修复,补回归测试,运行最小相关测试并报告结果。

模板 3:写资料或文章

写资料也一样。不要只说“帮我写一篇文章”,而是说清楚读者、标题、角度、风格、字数、事实来源和必须覆盖的模块。

好的 prompt 不是长,而是边界清楚。


八、计划模式 /plan:先让 Codex 想清楚

/plan 适合四种情况:

  1. 任务复杂;
  2. 需求模糊;
  3. 风险较高;
  4. 你还不懂当前项目。

比如:

/plan
我想优化登录体验,但还没想清楚改哪里。
请先阅读相关代码,问我必要问题,然后给出分阶段计划。现在不要修改文件。

好的 plan 应该包含:

  • 当前状态;
  • 目标;
  • 关键文件;
  • 修改步骤;
  • 风险点;
  • 验证方式;
  • 需要你确认的问题。

如果计划太空,就追问:

这个计划太泛了。请具体到文件、组件、数据流和验证方式。哪些是你确认过的,哪些只是推测?

/plan 的本质,是把“我想让 AI 帮忙”变成“我和 AI 一起定义任务”。


九、目标模式 /goal:让 Codex 持续盯着终点

/goal 适合长任务。

比如:

  • 修一组测试;
  • 做一次迁移;
  • 优化一个性能指标;
  • 整理一批文档;
  • 持续推进一个多步骤修复。

普通 prompt 是一次请求。

Goal 是一个持续目标

不好的 goal:

帮我把项目优化一下。

好的 goal:

把首页首屏加载时间优化到 1 秒以内。
完成标准:找到瓶颈,做最小必要改动,不改变 API,运行性能检查并报告前后差异。

如果 goal 写不出来,先用 /plan 让 Codex 采访你。

先 /plan,再 /goal,这是新手处理复杂任务最稳的顺序。


十、Skills:把重复工作变成可调用流程

Skill 可以理解成:

一套教 Codex 怎么做某类任务的工作说明书。写长文有写长文的流程。

做 code review 有 review 的流程。

生成图片有图片的流程。

处理飞书、GitHub、文档、表格,也可以有各自流程。

如果你每次都手动告诉 Codex 同一套要求,就该考虑把它沉淀成 skill。

Skill 通常是一个包含 SKILL.md 的目录,可以带脚本、参考资料和资源。Codex 会先看到 skill 的名称、描述和路径;只有决定使用时,才读取完整说明。

使用 skill 有两种方式:

  1. 显式调用:在 prompt 里写 $skill-name
  2. 隐式触发:任务和 skill 描述匹配时,Codex 自动选择。

一句话:

Prompt 是一次性要求,skill 是可复用工作流。---

十一、Plugins、MCP、Apps:Codex 怎么连接外部世界

图像

这几个词容易混,直接看表。

图像

选择方式也简单:

  • 一次任务:写进 prompt;
  • 项目长期规则:写进 AGENTS.md;
  • 重复流程:做成 skill;
  • 一组能力要分发:做成 plugin;
  • 要连外部系统:用 MCP 或 App;
  • 要定时重复:用 automation。

插件和外部连接涉及账号、权限和隐私。

只给当前任务需要的连接,只授权你看得懂的范围。


十二、AI 小白最该养成的 10 个习惯

  1. 一次只交一个主要任务。
  2. 不懂项目时,先让它解释,不要让它修改。
  3. 复杂任务先 /plan。
  4. 长任务用 /goal。
  5. Prompt 里一定写完成标准。
  6. 改完让它跑测试、lint 或 build。
  7. 看 diff 再接受。
  8. 权限从窄到宽。
  9. 重要任务先让它复述目标和限制。
  10. 反复出现的要求,沉淀成 AGENTS.md、skill 或模板 prompt。

这 10 条比任何神奇提示词都重要。


十三、真正推荐 Codex 的原因

相比于 Hermes 和 Claude Code,我更推荐 AI 小白先用 Codex。

不是因为 Codex 永远最强。而是因为它更适合新手建立正确的 AI 协作习惯。你可以从 App 开始,看见项目、线程、diff、终端和权限;再进入 IDE、CLI、Cloud;用 Worktree 隔离大改动;用 /plan 处理模糊任务;用 /goal 推进长任务;用 skill 和插件沉淀重复工作。

这套东西看起来多,但不是为了炫技。

它真正教你的,是怎么设计一个可执行、可观察、可验证的 AI 工作流。

所以如果你现在还在 AI 编程工具门口犹豫,我的建议很简单:

别先追最猛的演示。

先找一个你能控制、能看懂、能逐步加深的入口。

从 Codex App 开始。打开一个真实项目,让它先解释,不要改。然后做一个小改动,看 diff,跑测试。再试 /plan,再试 /goal。

等这几个动作跑顺,你再回头看 Hermes、Claude Code、Cursor 和各种 agent 框架,会清楚很多。

那时你不会只问“哪个更强”。

你会问:它能不能理解上下文、暴露过程、控制权限、规划复杂任务、推进长期目标,并把重复工作沉淀下来?

这才是 AI 小白真正跨过门槛的时刻。

最后留一个问题:

如果你现在要让 Codex 接管一个重复工作,你最想交给它什么?