Star Star的日记

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

记录时间：2026-07-08 14:33:36

这篇笔记整理自 SakuAI（@JackQi82772） 的一篇文章《想少走弯路？一文帮你从零上手 Codex》。核心观点很实在：对 AI 编程小白来说，第一问题不是「哪个工具天花板最高」，而是你能不能看懂它、控制它、在它做错时把它拉回来。所以作者更推荐先用 Codex 建立正确的协作习惯，而不是一上来就追最猛的演示。

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

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

  • 你能不能看懂它在干什么？
  • 你能不能控制它？
  • 它做错时，你能不能把它拉回来？

这才是入门门槛。很多人第一次用 coding agent，会被一堆名词劝退：CLI、IDE、Cloud、Worktree、Sandbox、Skill、Plugin、MCP、Plan、Goal、Diff——看起来都重要，但不知道先学哪个。

Codex 的好处是，它更像一个完整的 AI 工作台：把入口、权限、过程、改动、验证和扩展都摆在你面前。你可以从一个可视化 App 开始，再慢慢进入 IDE、CLI、Cloud 和插件生态。对小白来说，最重要的不是马上用上最猛的 agent，而是先建立正确的 AI 协作习惯。

一、为什么 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：最适合新手第一站。 支持 macOS 和 Windows，可以用 ChatGPT 账号登录，也可以用 OpenAI API key 登录（用 API key 时，部分和 ChatGPT 计划绑定的功能可能不可用）。第一次打开建议这样做：

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

2. IDE 插件：适合边看代码边协作。 如果你常用 VS Code、Cursor、Windsurf，IDE 插件更自然。你可以把正在看的文件、选中的代码直接作为上下文，也可以用 @文件名 引用文件。

3. CLI：适合终端用户。 Codex CLI 信息密度高，新手不是不能用，但不建议第一站就从 CLI 开始。

4. Cloud：适合更长、更并行的任务。 Cloud 适合远程运行、后台执行、并行任务。但先理解本地 Local、Worktree、diff、权限，再用 Cloud，会顺很多。

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

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

1. Project（项目）：Codex 当前工作的文件夹。打开错目录，它就会缺上下文。第一次用，先确认它是不是在正确项目里。

2. Thread（线程）：一组围绕同一任务的对话和操作。不要把所有需求塞进一个线程——解释项目、修 bug、写文章、重构模块，最好分开。一个线程解决一个主要目标。

3. Local / Worktree / Cloud：

  • Local：直接在当前项目里工作，适合小改动和解释类任务。
  • Worktree：在独立 Git 工作区里改，适合大改动和试错。
  • Cloud：远程跑任务，适合更长、更并行的工作。
  • 一句话记住：小任务 Local，大改动 Worktree，熟悉后再 Cloud。

4. Diff：你验收 AI 工作的地方。不要只看 Codex 的总结——总结是它说的，diff 才是它实际改的。你至少要看：改了哪些文件、有没有越界、有没有删掉不该删的东西、有没有把小问题改成大工程。

5. 终端：用来验证结果。你不需要马上看懂所有日志，先看命令是否成功、有没有 error、Codex 有没有根据错误继续修。

6. 浏览器、Computer Use、artifact 预览：内置浏览器适合检查网页，Computer Use 适合操作桌面 App，artifact 预览适合 PDF / 表格 / PPT / 图片等产物。这些能力有用，但权限更敏感，新手先用窄任务试，不要一上来全开。

7. 权限和 sandbox：Approval 决定 Codex 什么时候问你，Sandbox 决定它能读写哪里、能不能联网。默认原则很简单——权限够用就别开大；需要联网、写项目外文件、操作桌面 App 时，再按任务授权。

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

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

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

所以不要把 Codex 当成「更会回答的 ChatGPT」。更好的用法是：你给目标，它给方案；你给约束，它执行；它给 diff，你验收；它跑检查，你看结果；它出错，你让它解释和修正。 这才是 agent 协作。

七、最重要的提示词公式

只记一个公式：

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

也就是：

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

无论是解释项目、修 bug，还是写资料或文章，都是同一套。写资料时不要只说「帮我写一篇文章」，而要说清楚读者、标题、角度、风格、字数、事实来源和必须覆盖的模块。

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

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

/plan 适合四种情况：任务复杂、需求模糊、风险较高、你还不懂当前项目。

一份好的 plan 应该包含：当前状态、目标、关键文件、修改步骤、风险点、验证方式、需要你确认的问题。如果计划太空，就继续追问。

/plan 的本质，是把「我想让 AI 帮忙」变成「我和 AI 一起定义任务」。

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

/goal 适合长任务：修一组测试、做一次迁移、优化一个性能指标、整理一批文档、持续推进一个多步骤修复。

普通 prompt 是一次请求，goal 是一个持续目标。如果 goal 写不出来，先用 /plan 让 Codex 采访你。

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

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

Skill 可以理解成：一套教 Codex 怎么做某类任务的工作说明书。写长文有写长文的流程，做 code review 有 review 的流程，生成图片、处理飞书 / GitHub / 文档 / 表格，也可以有各自流程。如果你每次都手动告诉 Codex 同一套要求，就该考虑把它沉淀成 skill。

Skill 通常是一个包含 SKILL.md 的目录，可以带脚本、参考资料和资源。Codex 会先看到 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——不是因为它永远最强，而是因为它更适合新手建立正确的 AI 协作习惯。

你可以从 App 开始，看见项目、线程、diff、终端和权限；再进入 IDE、CLI、Cloud；用 Worktree 隔离大改动；用 /plan 处理模糊任务；用 /goal 推进长任务；用 skill 和插件沉淀重复工作。这套东西看起来多，但不是为了炫技——它真正教你的，是怎么设计一个可执行、可观察、可验证的 AI 工作流。

所以如果你现在还在 AI 编程工具门口犹豫，建议很简单：别先追最猛的演示，先找一个你能控制、能看懂、能逐步加深的入口。从 Codex App 开始——打开一个真实项目，让它先解释，不要改；然后做一个小改动，看 diff，跑测试；再试 /plan，再试 /goal。

等这几个动作跑顺，你再回头看 Hermes、Claude Code、Cursor 和各种 agent 框架，会清楚很多。那时你不会只问「哪个更强」，而会问：它能不能理解上下文、暴露过程、控制权限、规划复杂任务、推进长期目标，并把重复工作沉淀下来？

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

最后留一个问题：如果你现在要让 Codex 接管一个重复工作，你最想交给它什么？