很多人开始使用 AI 工具时，会很快遇到几个问题：

很多人刚开始使用 AI 工具时，常常会撞上这样几堵墙：明明模型能力很强，跑出来的结果却忽好忽坏；同一个任务，换个说法效果天差地别；对话越长，AI 越容易跑偏；工具功能堆了一堆，却不知道该怎么组织成自己的工作流；看过无数零散教程，真正动手时依然不知道从哪里开始。

这门课会围绕这些问题，把 Agent 的能力边界、Codex 的定位、模型选择、上下文管理、对话习惯、内置工具、Skill 机制、自动化能力和实战场景串成一条完整的学习线。学完之后，你会更清楚什么任务适合交给 AI Agent、什么任务应该拆小；怎样表达需求才能让 AI 稳定输出；怎样管理上下文减少越聊越乱的问题；以及怎样把 Codex 的项目、话题、工具、Skill 和自动化能力真正用起来。

---

前言：为什么要写这门课

大家好，我是 oil 欧呦，一个在小红书上分享 AI 编程和 Agent 使用经验的前端开发者。

我从 2024 年开始接触 AI 编程工具，到 2025 年完全转成 Vibe Coding 的工作方式，再到现在把 AI Agent 融入到日常工作的方方面面。这门课的内容来源于过去一年多的实际使用经验，不是从官方文档搬运的教程，也不是付费课程之后的二手整理。里面的每一个方法、每一个坑、每一个心得，都是自己真实花了时间和钱跑出来的。

我不希望这门课只是教会你怎么操作某一个软件。更希望你看完之后，能够对整个 AI 的世界有一个高维度的理解。当你足够了解 AI，就可以主动过滤掉大量垃圾信息和贩卖焦虑的内容，建立自己的判断，分清楚什么是真正有价值的能力提升，什么只是博主的流量密码。

更重要的是，你能把 AI 真正用到自己的工作和生活里去。不管你是程序员、产品经理、设计师、自媒体，还是其他任何职业，Agent 能做的事情远比写代码多得多。只要理解了它的能力边界和正确的使用方式，AI 就能成为你真正的生产力杠杆。

关于我

我没有大厂背景，但在 AI 这个方向上的经历还算丰富。最开始做前端开发，后来转产品经理，原因是发现自己真正感兴趣的是"这个东西应该做成什么样"。再后来 AI 出来了，我在工作中开始接触 AI 编程工具，发现它能让一个人做到以前一个团队才能做的事情。这个认知促使我加入了一家做通用 AI Agent 的公司做产品经理。之后又先后在两家 AI 初创做过产品和前端开发，在这些经历里，我接触了 Agent 的设计、模型的选型、上下文的管理、MCP 的开发、SEO 的落地，这些都是实际工作中跑出来的经验。

自媒体方面，我在小红书做原创内容，一个多月时间做到了一万多粉丝，几乎每周更新四到五个视频。而且自媒体只是副业，我不需要特别在意数据，不需要讲人云亦云的热门话题，也不需要为了流量去散播焦虑。我只分享自己真正用过觉得好的东西，这也是为什么我的内容几乎全是原创。

产品方面，我自己 Vibe Coding 做过 Text-Well（AI 文本纠错工具，三天从零到上线）、Wolfcha（AI 狼人杀游戏，黑客松作品）、还有一个 AI 创作平台（两个月把 SEO 日曝光从 500 做到 15000+）。

开源方面，我做了不少 Skill 和工具：draw-ui（UI 设计稿生成）、screen-studio-editor（视频剪辑+字幕）、codex-explore-skill（代码库探索）、my-browser（本地浏览器自动化）、oiloil-ui-ux-guide（UI/UX 设计规范）等等。

这门课里所有的内容，都是基于我实实在在用过、花过钱、踩过坑的经验。

---

第 1 章：Agent 与普通 AI Chat 的区别

很多人其实不太了解 Agent 和普通 AI 对话在本质上的区别，也不清楚它们分别能够完成什么样的事情。而弄清楚它们能做什么，是大家充分利用 AI 最重要的前提条件。

我的很多有趣想法都是基于 Agent 能够做到的事情去想象它可以覆盖我的哪些场景。我一般不先带着问题再去琢磨 Agent 能不能解决，因为许多问题的解决方向有很多种。比如给视频添加字幕，我最开始用剪映，后面也试过一些第三方产品。再到后来，我突然发现使用 Agent 来处理这件事可以达到高度定制化的效果。我必须首先了解 Agent 能够帮我给视频添加字幕，并且理解它具体如何操作，才能够想到它在这个场景里其实会比其他产品处理得更好。

1.1 先分清产品和模型

很多人第一次接触这些工具，听到的产品名可能有：通义千问、腾讯元宝、豆包、DeepSeek、ChatGPT、Gemini、OpenClaw、Claude Code、Codex 和 Cursor。如果不了解 AI 的人，可能认为它们就是 AI 本身。但它们是不同厂商推出的产品，而且这里面有一些属于 AI 对话产品，有一些属于 Agent 产品。很多人对它们的理解可能仅限于国内和国外的区别，下意识地觉得国外的产品比国内更好使用。

这里要强调产品和模型其实是两回事。比如 Gemini 这个名字，在不同的语境下代表的其实是完全不同的东西：

第一，AI 对话产品。这是我们在手机应用商店或者网页上直接使用的软件，有聊天输入框和各种按钮。我们平时说使用 Gemini 查个资料，指的就是它的 AI 对话产品。

第二，大语言模型。就是背后真正在思考的那个东西。我们通过软件或者接口调用的 Gemini 3.5 Flash，就是大语言模型。模型本身没有界面，它只是一个运行在云端服务器上的计算程序。

第三，Agent 产品。这是利用模型智力、配上本地工具的自动化系统。比如 Google 官方推出的 Gemini Spark，或者本课程的主角 Codex。

这三者的区别在于：我们在使用 Codex 或者 Cursor 这样的 Agent 产品时，我们是在使用一个 Agent 的外壳，去挑选一个大语言模型作为它的智力大脑。Agent 产品的运行上限，取决于你给它配置了什么模型。

1.2 AI 对话产品的能力边界

像通义千问、腾讯元宝、豆包、DeepSeek、ChatGPT、Gemini 都属于 AI 对话产品。网络上有些 AI 对话产品也支持联网搜索功能，但是它们和真正的 Agent 产品在能力上有着巨大的鸿沟。

AI 对话产品的联网搜索功能本质上是文本提取。当我们输入问题之后，它在后台通过搜索引擎获取一些网页的内容摘要，然后在大模型的窗口里进行信息整理，把答案回复在对话框里。在这个过程里，它无法与网页进行交互，不能点击网页里的各种按钮，不能登录我们自己的账号，更没有办法把获取的信息保存到我们电脑本地的文件夹里。

而 Agent 产品的联网则是真正的控制和操作。它可以接管一个真实的浏览器，像人类一样去模拟点击、输入、翻页，甚至可以登录我们自己的账号来执行操作，并且把获取到的各种资料自动下载到本地。

1.3 什么是 AI Agent

大家平时应该都用过豆包，它就是非常经典的 AI 对话产品。我们在对话框里输入一行问题，它在窗口里回复一段文字，这种一问一答的方式非常适合进行日常咨询或者文字撰写。但是，如果我们想让它帮我们去处理具体的电脑操作，就会发现它根本做不到。比如我们让它把某个文件夹里的所有图片重命名，它没有办法直接控制我们的电脑去修改文件名，只能给我们提供一段 Python 代码。我们必须自己把代码复制出来，新建文件，自己在终端里运行。如果运行报错了，我们还要把报错信息复制回去向它提问。这中间需要手动进行大量的复制和粘贴操作。

而 Agent 就是用来解决这种繁琐步骤的。在使用 Agent 时，我们不需要自己去复制运行代码。我们只需要提供一个整体目标，它自己就会去进行任务拆分，选择合适的工具，然后一步步运行到结束。

传统的 AI 对话产品只是在浏览器窗口里回复文字，而 Agent 产品可以在终端里执行命令、修改文件、甚至控制浏览器，直接帮我们把这些零碎的操作全部运行完毕。

Anthropic 官方在文章里把系统分成了工作流和 Agent 产品两类：

工作流是把大模型和各种工具用固定的代码串联起来。比如我们编写一段程序，第一步调用接口获取数据，第二步翻译文字，第三步保存到数据库。在这个过程里，大模型只是一个计算节点。模型自己没有决定权，只能跟着程序设计好的路线运行。

Agent 产品则是把过程控制权完全交给了大模型，让模型自己动态决定接下来的步骤和工具。比如我们分配给它一个修改 Bug 的目标，它会自己决定先使用搜索工具寻找相关文件，自己阅读代码并定位问题，接着自己修改文件，最后运行测试来验证。如果测试报错，它还会自己分析报错原因并且重新修改，直到任务完成。

在整个过程里，我们没有给它设定死板的代码路线。每一步要使用什么工具、接下来怎么执行，全是由模型在运行中根据返回的实际结果自己决定的。这种拥有动态决定权的系统，才是真正的 Agent 产品。

1.4 普通 AI 对话产品的工作限制

当我们使用普通的 AI 对话产品时，往往会发现它的工作限制非常明显。除了无法直接操作电脑之外，网页版 AI 对话产品的上下文额度也是有限的。当我们对话时间长了，它就会忘记前面的对话内容。它也没有办法直接读取我们电脑上的本地文件，更没有办法知道我们本地的实际测试结果。

因为普通的 AI 对话产品本质上是一个静态的沙盒环境，它和我们的本地计算机、真实的外部互联网是彻底断开的。它所有的输出都只能停留在文本框里，无法对真实世界产生任何反馈。

1.5 真实场景下的功能对比

场景一：整理旅游攻略

要求查询西湖、西溪湿地、灵隐寺的最新门票价格和开放时间，然后制作一个表格文件放置到电脑桌面上。

普通 AI 对话产品通常只能进行单次的联网查询，在聊天的文本框里为你绘制一个由字符拼接而成的排版表格，或者打包生成一个可以供你下载的表格文件链接。但是，它没有办法直接打通你本地电脑的操作系统，无法将制作好的表格文件写进你的电脑桌面路径里。

Agent 产品则可以自主利用浏览器自动化工具，逐个访问景点的官方网站，主动点击门票预订或公告页面，获取到当天的最新数据。随后它会直接调用本地操作系统的文件写入接口，在你的电脑桌面上新建一个真正的表格文件，将数据填写并保存，完成后直接提示运行成功。

场景二：整理本地的照片

桌面上有一个叫做"待整理照片"的文件夹，里面有一百张照片。需要把拍模糊了的照片以及重复的照片挑选并删除，剩下的按照拍摄日期，新建不同的文件夹进行分类存放。

普通 AI 对话产品会直接告知无法访问本地电脑桌面，更没有权限修改文件。随后它会提供一段长长的 Python 代码，让我们自己去安装运行环境、配置各种依赖库。如果是不懂代码的非专业用户，面对这些代码只会觉得无从下手。

Agent 产品则直接读取本地的文件夹。它自己调用图像查看工具，逐张对比照片的清晰度和内容，挑出不合格的照片并移入垃圾箱。同时调用系统的文件管理工具，创建具体日期的分类文件夹，把合格的照片自动移动进去。

场景三：制作每日工作简报

希望每天早上九点钟，自动去一些技术社区和社交平台收集关于大模型的热门帖子，整理好标题和链接，通过办公软件发送给自己。

普通 AI 对话产品会表示自己无法在后台自发启动，也无法控制其他软件。它只能作为一个被动的工具，在我们主动发送消息提问时给予回复。

Agent 产品可以利用其自身自带的定时自动化运行机制（例如 Codex 的 Automation 自动化任务面板）。我们在产品里直接为它配置好定时任务的目标和时间规则，它就会在每天早上九点钟自动在后台启动，控制浏览器并登录我们的社交账号抓取帖子，整理完毕之后直接调用办公软件的发送接口，将简报弹窗发送出来。

1.6 Agent 的自主循环与工具调用机制

Agent 能够帮我们完成这些事情，是因为它的运行逻辑是一个自主循环。在学术上这个机制叫作 ReAct 循环，也就是思考、行动、观察三个步骤的不断重复。

我们可以通过重命名图片这个场景来理解：

思考：Agent 会先分析我们给它的整体任务，决定先查看文件夹里有哪些文件。

行动：它调用了文件搜索工具，去读取文件夹的内容。

观察：它看到了搜索工具返回的文件列表，发现里面有五张图片。

思考：它根据拿到的图片列表，决定调用文件重命名工具。

行动：它运行了重命名工具，修改了文件名。

观察：它确认重命名工具返回修改成功的消息，确认任务已经完成。

在这个循环里，最重要的就是工具调用机制。Agent 自己不具备修改文件或者控制电脑的能力。它是通过调用我们提供给它的工具，比如运行终端命令的工具、读取文件的工具，来间接控制电脑的。如果工具运行报错了，它在观察这一步会获取报错信息，然后在下一步的思考中自己去寻找解决办法，不需要我们去干预。

1.7 为什么文件系统和命令执行是 Agent 的核心

在所有 Agent 能调用的工具里面，有两个是最基础的：文件读写和终端命令执行。

为什么这两个这么重要？因为我们电脑上几乎所有的操作，最终都可以拆解成"读写文件"和"运行命令"这两件事。写代码是在写文件，装软件是在运行命令，改配置是在写文件，跑测试是在运行命令，做表格是在写文件，压缩图片是在运行命令。

只要一个 Agent 拥有了文件读写和命令执行这两个能力，它理论上就能做我们在电脑上能做的任何事情。任何复杂的操作，都可以被它分解成一连串的文件操作和命令执行。

这也解释了一个趋势：为什么这些原本叫做 Coding Agent 的工具，都在慢慢变成通用 Agent。

1.8 从 Coding Agent 到通用 Agent

市面上的 Agent 产品其实有很多种。有些是专门做某一件事的，比如专门帮你写邮件的、专门帮你做 PPT 的、专门帮你做数据分析的。这类 Agent 通常有一个固定的工作界面和预设的工作流，我们能做的事情被限定在它设计好的范围内。

而通用 Agent 指的是没有被限定在某个特定场景里的 Agent。它有文件系统的完整权限、能执行任意的终端命令、能安装和调用各种工具。我们给它什么任务它就做什么任务，不存在"这个功能我没有"的限制。它的能力边界取决于它能调用的工具有多少，而不是产品经理预设了哪些功能。

像 Codex、Claude Code、Cursor，它们最早都是给程序员写代码用的。但是大家慢慢发现，写代码无非就是在读文件、改文件、跑命令。那帮我整理文档不也是读文件改文件吗？帮我做调研不也是运行一些搜索命令吗？帮我批量处理图片不也是跑一些脚本吗？

这些 Coding Agent 本来就有文件系统的完整权限和命令执行的能力，它们天然就能做远超写代码以外的事情。只是最早的用户群体是工程师，所以大家以为它只能写代码。

OpenClaw 走的是另一条路。它从一开始就定位为通用 Agent，面向的不只是程序员。它可以接入微信、飞书这些即时通讯工具，在手机上就能控制电脑执行任务。它默认带有记忆和人设系统，交互方式更像一个私人助理。

但如果我们看底层能力，OpenClaw 和 Codex 其实是一样的东西：文件读写 + 命令执行 + 浏览器控制 + 自主循环。只不过 OpenClaw 是从"通用助理"这个角度切入的，而 Codex 是从"编程工具"这个角度切入的。它们都在向同一个方向演化——成为一个能做任何事情的通用操作系统级别的 Agent。

Codex 现在加了桌面端、加了浏览器控制、加了 Computer Use、加了图片生成、加了定时任务、加了手机端远程控制。它已经不再只是一个编程工具了。而 OpenClaw 因为从一开始就不是为写代码设计的，它本身不擅长处理复杂的编程任务。所以官方提供了一个叫 coding agent 的 Skill，它的作用就是当我们让 OpenClaw 去写代码的时候，它不会自己硬写，而是去找我们电脑上装的 Codex 或者 Claude Code，把编程任务委派给这些专业的编程 Agent 去执行。这本身就说明了不同 Agent 之间是可以协作分工的。

它们最终都会变成同一种东西：一个拥有完整系统权限的、能调用任意工具的、可以自主规划执行任务的通用 Agent。只是入口不同、交互风格不同、擅长的场景不同。

理解这一点之后，我们在后面使用 Codex 的时候，就不要把它局限在写代码这一件事上。任何我们在电脑上做的事情，只要能被拆解成文件操作和命令执行，都可以交给它。

---

第 2 章：常用模型选择

在上一章里，我们弄清楚了 Agent 产品和普通 AI 对话产品的本质区别。在这一章里，我们来聊聊模型选择。

2.1 搞清楚模型、Agent 与 AI 产品的差别

为什么我们要强调这个区别？因为我们在使用 Codex 或者 Cursor 这样的 Agent 产品时，我们是在使用一个 Agent 的外壳，去挑选一个大语言模型作为它的智力大脑。Agent 产品的运行上限，取决于你给它配置了什么模型。

2.2 谁是目前最强的首选

目前在海外，最强的三家大模型厂商就是 OpenAI、Anthropic 和谷歌。他们各自有自己最强的模型系列。在很长的一段时间内，这三家厂商的实力很接近，很难说谁比谁强。但是截止到 2026 年 5 月底，最强的模型已经非常明确了，那就是 OpenAI 的 GPT-5.5 和 Anthropic 的 Claude Opus 4.7。在 Agent 的运行场景下，它们两个是目前表现最好、最顶尖的模型。

我们来看看这三家模型各自的特点。它们都原生支持视觉识别。

Claude 系列

Claude 系列的优势是编程能力很强，需求理解能力也是三家里最好的。当你向它描述一个稍微有些抽象或者复杂的业务逻辑时，它能比较准确地抓住你的真实意图，写出的代码逻辑比较严密。但是，它的缺点就是价格昂贵。无论是调用 API 接口的按量计费，还是各种高级订阅套餐，它的使用成本都是三家里面最高的。

GPT 系列

GPT 系列的编程执行力也很强，但是在理解抽象需求的能力上，它会稍微逊色于 Claude。如果你给它的指令不够具体，它有时会产生一些理解偏差。不过，它的优势在于实际使用性价比很高。虽然从单次调用的模型单价来看它并不便宜，但是如果你订阅了 ChatGPT Pro 或 ChatGPT Ultra 这样的包月套餐，在重度开发和高频使用的场景下，折算下来的实际开销会比 Claude 便宜非常多，用量额度也更加慷慨。

Gemini 系列

Gemini 系列在 Agent 场景下表现一般。工具调用成功率不高，逻辑规划容易跑偏，不太适合当 Agent 的主力模型。最新的 Gemini 3.5 Flash 有一些改善，但跟前两家比还是有差距。不过 Gemini 的优点是审美好，写出来的文案和排版比较自然、有人味，而且价格便宜。我一般把它用来做设计相关的事情。

这里有一个很多人忽略的问题：如果你没有使用过最强的模型，你很可能会对 AI 的表现感到不乐观。很多人找我付费咨询时，会说他们之前使用的是某个普通产品去做某件事情，结果发现 AI 给出的回答非常糟糕，或者在任务进行到一定深度时，模型的幻觉就变得很严重。这其实是因为他们从来没有体验过真正强的模型。用弱模型去跑复杂的 Agent 任务，效果自然不好。但如果换成 GPT-5.5 或者 Claude Opus 4.7，之前很多搞不定的问题就通了。

当然，除了模型本身的智力之外，还有一个关键因素决定了任务的成败，那就是不同 Agent 产品的 harness 能力。Harness 翻译过来可以理解为马鞍或者鞍具，在 Agent 场景下就是指这个工具套件和底层框架的设计能力。哪怕调用完全相同的底层大语言模型，一个设计好的 Agent 框架，能通过更好的工具调度、上下文引导、以及运行时纠错机制，把模型的智力榨取到极限。而一个简陋的框架，则会让同一个模型高频出错。

2.3 什么是多模态以及它的实际场景

我们在看模型规格表时，经常会看到单模态和多模态这两个词。模态（Modality）其实就是大模型和外部世界交流的感官通道。传统的单模态模型只有纯文本这一条感官，而多模态模型则相当于给大模型增加了视觉、听觉和语音生成。

在网页端聊天时，多模态可能只是让你能发一张表情包。但在 Agent 产品的执行循环里，不同的模态结合具体的自动化工具，能够直接帮你解决很多繁琐的工作。

网页设计和网页还原的应用

在过去，我们如果想要 AI 帮我们编写一个网页，我们必须在对话框里使用几百个字，非常繁琐地向它描述：左上角放一个灰白色的输入框，右边放一个深蓝色的按钮，背景需要带有微弱的网格渐变。尽管费尽口舌，单模态模型写出来的界面往往很难看。

我们可以直接调用 GPT Image 2 等生图工具来做 UI 设计。在 Agent 里面，我们只要说一个大概的需求（比如"做一个简约风格的 Dashboard 页面"），AI 会自己写合适的生图提示词。另外生图的时候给一张参考图比纯文字描述效果好很多，AI 能从参考图里提取风格、配色、布局这些信息。

你可以将生成的这几张设计图，或者你在网上看到的任何优秀网站截图，直接发送给拥有视觉能力的顶级模型（如 GPT-5.5、Claude Opus 4.7 或者是原生支持视频和超长图像流识别的 Gemini 3.5 Flash）。它会扫描这张图片，提取出页面里的颜色 HEX 代码、容器圆角大小、文字行高和边距，然后直接写出还原度很高的 HTML 和 CSS 代码。

字幕校对时的实际效果

我们在做视频制作或者字幕转录时，经常会遇到同音字转译错误的情况。比如我们在视频里说的是编程工具 Claude Code，普通的语音识别引擎在转录时，由于它只有听觉这单一模态，往往会识别成 cloud call（云端通话）。

在 Agent 的自动剪辑工作流里，它会采取两个模态联合工作的校对方式：

第一步，通过音频转译生成初版字幕。

第二步，Agent 会在后台对你的视频画面进行关键帧抽帧 OCR 扫描。模型会核对视频画面里电脑屏幕上出现的代码、网站标志、或者是窗口标题。

第三步，模型会核对屏幕上显示的 Claude Code，去校对音频听到的同音字 cloud call。一旦发现两者不一致，它就会结合上下文，自动将错漏的字幕修正为准确的专有名词，并且自动处理首字母大写。

原生多模态和插件多模态的区别

很多国产模型和部分开源模型在调用 API 接口时，本身是不直接支持图像和音频数据输入的。它们想要处理图片，必须依赖 Agent 框架在本地配置临时的 ASR 或 OCR 插件进行中转。这种临时拼接的模态调用速度慢，而且经常因为图片背景复杂而发生报错。

而像 OpenAI 的 GPT-5.5、Anthropic 的 Claude Opus 4.7 或者是谷歌的 Gemini 3.5 Flash，都是在底层算法上直接支持多模态原生输入的。在执行高频、复杂的自动化浏览器控制任务时，原生多模态模型几乎是唯一的选择。

2.4 挑选 Agent 模型需要看重什么

我们在网页上跟 AI 聊天，通常只看它回答得聪不聪明。但如果放到 Agent 里去执行任务，评估标准就不一样了。适合 Agent 的模型要看这几个方面。

汇报时的交流感

在 Agent 运行中，模型需要频繁地向你汇报它准备运行什么指令，修改什么文件，并且向你申请执行权限。如果模型的回复非常生硬和晦涩，使用复杂的话去解释简单的问题，你就会很难看懂它的方案，从而无法建立信任感。

上下文被多次压缩后的听话程度

Agent 产品在连续执行长任务时，上下文会迅速增加。当上下文达到一定长度，Agent 产品会自动运行压缩机制，把之前的对话和工具执行记录进行精简。在上下文被多次压缩之后，很多普通的模型就会开始出现失忆或者偷懒的情况，容易乱改之前已经定好的代码方案。

修改大文件的稳定性

Agent 产品需要高频地对我们本地的文件进行修改。它通常会先读取一个文件，然后通过搜索 and 替换其中的一段代码来完成修改。如果模型在这方面不够稳定，它在编辑几十行的小文件时可能没有问题，但在编辑几百行的大文件时，就容易发生替换失败，甚至会自作主张地删掉不相关的代码。

2.5 实际开发中的开销决策

包月订阅往往比接口计费更划算

在 Agent 产品的 ReAct 运行循环里，模型每一次去运行工具或者查看文件，都需要把之前所有的会话历史、项目代码结构全部作为上下文重新读取一遍。这会导致每一次对话消耗的 Token 数量以指数级迅速飙升。

如果完全使用接口（API）按量计费，遇到复杂的开发任务，随便修改和调试几次功能，可能就会产生几美金甚至十几美金的开销。我的经验是，只要大家在日常重度开发，能够选择包月订阅就绝不要选择 API 计费。比如订阅了 200 美金的 ChatGPT Ultra 升级包月套餐，在 Cursor 或者 Windsurf 里使用 GPT-5.5 或者 Codex 运行高难度的编程，无论怎么高频提问和重写文件，每月的支出都是固定封顶的。

通过子 Agent 分发降低 API 成本

如果因为团队协作或者软件本身的限制，我们必须调用接口（API）计费，可以通过主辅模型组合的设计来大幅度降低费用：

顶级高智商模型只用来编写开发方案：我们在主窗口里让它设计修改方案。由于它不需要具体去运行文件改写，它在主会话里的轮次就会非常少，上下文很干净，所以整体费用非常低。

低开销的辅模型作为子 Agent 去具体修改文件：主 Agent 将写好的确定方案传递给子 Agent。子 Agent 在后台执行高频的文件读取、修改、重试、测试报错以及重新编译。虽然这个过程会产生大量的 Token 消耗，但由于辅助模型的单价很低，最终的总开支会低很多。

视具体场景挑选高性价比模型

不同模型的长处不同，大家需要根据具体的任务类型来进行精准调度。

写代码与设计还原：如果我们需要写一些好看的页面排版、设计 UI 布局、或者撰写大白话的运营文案，可以直接调用 Gemini 3.5 Flash。它生成 Token 的速度很快，价格很便宜，且天生具备非常好的审美和文案风格。

关于模型生成 Token 的速度，行业里一般会使用 TPS（Tokens Per Second）这个指标来衡量，也就是大模型每秒钟能够输出多少 Token。如果一个模型的 TPS 在 50 以下，你会觉得输出很慢，而 Gemini 3.5 Flash 或者是 GPT-5.4 mini 这种轻量模型的 TPS 通常可以达到 150 到 200 以上。

另外还有 TTFT（Time to First Token，首字响应时间），通常轻量模型反应很快，首字等待时间只有一两百毫秒；而开启深度思考的推理模型，首字等待时间可能需要十几秒。

运行单点修改和报错排查：优秀的国产模型（GLM-5.1、Qwen 3.7 Max、DeepSeek V4 Pro 等）在中英文多任务和常规代码执行中的表现都非常好。但当任务复杂度很高、或者上下文达到几十万 token 的时候，它们相较于 GPT-5.5 和 Claude Opus 4.7 依然更容易产生定位失效和规划跑偏。所以，更推荐让它们在子 Agent 机制下，去具体运行那些已经确定好的单点修改、脚本执行或者常规报错排查。

大项目重构与老旧系统维护：如果任务涉及复杂的代码依赖重构，或者排查非常隐蔽的内存泄露，千万不要为了省钱而使用低配模型。在这种高难度任务下，低配模型因为逻辑规划不完善，经常会陷入修改错误、报错、重新修改失败的死循环，最终反复累计消耗大量 token。

2.6 我的模型组合演变过程

我平时写代码基本全是 Vibe Coding，自己不动手改文件，全靠跟 Agent 说话让它去执行。用了一段时间之后，我的模型组合经历了一次比较大的变化。

在过去，我习惯使用多模型异构的组合：

• 产品经理：使用 Claude Opus 4.6。因为它的需求理解能力很强，交流感好，代码设计能力也出色。
• 日常执行者：使用 GPT-5.3 Codex。因为它的接口调用价格非常便宜。
• 设计师：使用 Gemini 3.1 Pro。因为 Claude 和 Codex 在视觉设计上的审美比较单一。

现在我已经不用这种多模型的搭配了，直接 All-in-One：现在我完全使用 Codex 加上 GPT-5.5 运行日常所有的开发任务。一方面是 GPT-5.5 修了之前说话晦涩的问题，交流感和编程能力都不错了。另一方面，我订阅了 200 美金的 ChatGPT Ultra 套餐，额度很够用，性价比比 Claude 高很多。

---

第 3 章：Codex 的介绍与定位

3.1 什么是 Codex

其实，Codex 就是一个运行在本地项目里的工具。它的作用就是用来帮我们执行一些具体的编码任务、运行本地编译或者进行自动测试。

在最底层的设计上，它使用 Rust 语言进行了重构和编写，所以它在终端里冷启动时非常快，扫描大项目目录、查找里面的代码方法和定义时，几乎感受不到任何延迟，本地内存的占用也特别微小。

3.2 Codex 与 Claude Code 的区别

作为目前市面上最强大的两个终端 AI Agent 产品，它们两个在日常开发的使用体感上，其实几乎没有任何区别。

首先，它们的核心交互流程和节奏是完全一致的。它们都是在本地命令行终端里运行。当你敲下启动命令后，都会进入一个流式的黑乎乎的终端交互面板。当你输入一个开发需求，它们都会自主去扫描项目目录、读取本地文件、在后台执行测试和编译。

其次，在核心功能上，它们也是完全相通的。它们都无缝支持 /goal 等异步长期执行任务的命令。它们在长对话下也都会自动触发上下文的压缩机制，都支持接入 MCP 协议来扩展工具，也都支持通过编写定制的 Skill 来固定日常的重复工作流。

它们唯一的微小差异，仅仅体现在背后的模型品牌、外壳的封装形式、以及国内用户的账号安全稳定性上：

• 模型生态：Claude Code 默认绑定 Anthropic 官方的 Claude 系列模型。而 Codex 则是 OpenAI 旗下的产品，默认使用 GPT 系列模型。
• 产品形态：Claude Code 目前依然是一个纯粹运行在终端命令行里的工具。而 Codex 除了命令行工具之外，OpenAI 官方还为它封装了更方便管理多个并行开发任务的桌面端应用，以及多端联动的手机端。
• 账号安全性：Anthropic 的风控机制很严，甚至可以说对国内 IP 存在明显的地域限制，大面积封禁国内关联的账户。相比之下，OpenAI 针对中国用户的常规网络访问和充值的风控逻辑要宽容、稳定得多。

3.3 跟 OpenClaw 的区别在哪

OpenClaw 和 Claude Code / Codex 能做到的事情其实是一样的。它们都有文件操作、执行脚本、浏览器控制、联网搜索这些核心能力。

但是它们在产品设计上的取向是不同的。OpenClaw 最方便的地方在于，它可以很轻松地配置到我们的飞书、微信、Telegram 上面。我们在手机上就能跟它对话，远程控制电脑去执行任务。它还默认带有 Memory 和 Soul 系统，会不断把我们对话中的信息记到它的记忆里去，还会完善自己的人设。

而 Claude Code 是一个专注于写代码的工具。大部分人使用 Claude Code 的时候，不会去开启什么复杂的记忆系统，因为代码仓库本身就是它的记忆。这里有一个我自己的观察：OpenClaw 带着记忆带着灵魂，有一定的情绪价值，但它在严肃处理工作任务的时候，效果是不如 Claude Code 这一类编程工具的。

不过它们之间并不是非此即彼的关系。我自己就是同时在用的。OpenClaw 官方甚至提供了一个叫做 coding agent 的 Skill，意思就是如果我们让 OpenClaw 去写代码，它会自己去找我们电脑里有没有装 Codex 或者 Claude Code，然后把编程任务委托过去。它们是有分工的：OpenClaw 像一个小爱同学，负责一些轻量的待办管理、文件整理、信息抓取、手机远程控制；而 Codex 或 Claude Code 负责复杂编程、架构设计、长流程的工程任务。

3.4 我为什么选择使用 Codex

我选 Codex 主要就是因为它搭配 GPT-5.5 的整体效果不错。一方面，在日常高强度的开发之下，我订阅了 ChatGPT Pro 包月套餐，额度高得根本用不完。另一方面，GPT-5.5 在图片生成模态上的表现很好，无缝支持官方最新的 GPT Image 2 图片生成工具。

3.5 Cursor 作为替代入口

Codex 要用的话，得订阅 ChatGPT Pro，这需要有美区的手机号或者信用卡才能完成付款。如果你暂时买不到 GPT 的直接订阅，可以去用 Cursor。

Cursor 的好处在于：它是一个桌面应用，下载安装的门槛很低。里面所有的配置（Plugin、Rules、Skill、MCP）都是可视化的。它聚合了当前最强的几个模型（GPT-5.4、Claude Sonnet、Opus、Gemini 3.1 Pro），你可以自己选择使用。它不跟单一的模型厂商绑定，既可以切换海外的顶尖模型，也可以切换国内的模型进行对比。

当然 Cursor 也需要翻墙和订阅（20 美金），但比起自己去搞美区账号、绑虚拟卡、配 API Key 那一套流程，简单很多。如果支付问题解决了，能直接订阅 ChatGPT Pro，那还是建议直接用 Codex，体验会更完整。

---

第 4 章：安装与基础配置

4.1 我们需要准备的运行环境

因为我们在让 Agent 编写代码或者运行日常任务时，往往需要使用到各种外部依赖，所以建议在电脑上先安装好以下两个最基础的环境工具。

一是 Node.js 环境。建议直接安装最新的 LTS 稳定版本。因为后续通过 MCP 协议去加载和管理各种外部工具、发布插件时，大部分底层脚本都需要依赖 Node.js 运行环境。

二是 Git 工具。因为 Agent 在自动进行代码修改和 /goal 长期任务时，需要自动在本地进行代码差异比对、新分支的切分和代码提交。

4.2 如何下载和安装桌面端

我们这套课程完全不需要、也完全不推荐大家直接去黑乎乎的终端命令行里敲命令。我们所有的任务和管理，全部直接在官方提供的、可视化的桌面端软件里完成：

• macOS 用户：直接访问 Codex 官方桌面端页面 进行下载安装。如果你的 Mac 是苹果 M 系列芯片，选择 Apple Silicon 硬件版本；如果还是早期的 Intel 芯片，选择 Intel 版本即可。
• Windows 用户：直接访问 Windows 微软商店 Codex 页面 进行一键下载安装。

打开之后左侧是导航栏：New chat（新对话）、Search（搜索历史）、Plugins（插件和 Skill）、Automations（自动化任务）。中间是对话区域。底部是输入框。

4.3 登录我们的账号

当你第一次打开 Codex 桌面端应用时，在界面上直接点击登录。系统会自动在你的默认网页浏览器里弹出一个登录页面，你只需要直接登录你已有的 ChatGPT Plus 或者是 ChatGPT Pro 订阅账号进行授权即可。

4.4 配置文件 config.toml 的修改入口

Codex 所有的参数，都是通过一个叫做 config.toml 的配置文件进行控制的。我们可以直接在可视化界面里找到这个文件的修改入口。在左侧导航栏里，点击 Configuration 面板，你就会在右侧看到一个 Open config.toml 的按钮。

如果你在 Cursor 或者 VS Code 编辑器里修改这个 .toml 文件，我建议你在配置文件的最顶上敲入下面这行代码：

#:schema https://developers.openai.com/config-schema.json

4.5 常用的核心参数配置

在这个打开的 config.toml 文件里，下面几个参数是我们在后面写代码、做自动化任务时最常用到的。

功能特性开关（[features]）：

• goals = true：开启后，支持强大的异步长期任务（/goal 命令）。
• hooks = true：开启后，支持通过编写自动化的 Hook 机制来监听和扩展 Agent 的运行事件。

常用的核心参数（根级别）：

• model = "gpt-5.5"：推荐的全局默认主力模型。
• model_reasoning_effort = "high"：思考深度。可选 low / medium / high。
• sandbox_mode = "workspace-write"：沙盒模式。这个设置决定了 Agent 能动哪些文件。

外部工具接口（[mcp_servers]）：

• [mcp_servers.filesystem]：控制加载的本地文件系统插件。

账号与账单权限（[billing]）：

• model_provider = "chatgpt"：绑定 ChatGPT 的高级订阅服务。

这里还有一个非常省事的小技巧：既然你已经用上了 Codex，其实大部分的 config.toml 配置参数，你根本不需要自己动手去打开文件逐行修改。我们只需要在会话框里直接给它发一句话，比如"帮我把配置文件的默认模型换成 gpt-5.5，并且把推理思考强度设置为 high"，它就会自己去寻找并修改好这些配置。

---

第 5 章：上下文工程

之前我和一个不怎么用 AI 的朋友聊天，他说他觉得 AI 是越用越聪明的，就像养一只宠物一样。但实际用下来，他发现 AI 聊着聊着会突然忘记之前说过什么。这种困惑很普遍，在我们正式开始使用 Codex 之前，有必要先把上下文这个概念说清楚。

5.1 AI 不会因为跟你聊天而变聪明

这个可能是很多人最大的误解。大语言模型在训练完成之后，它的能力就固定了。我们跟它聊天的过程中，它不会"学习"新的知识，也不会因为我们多聊几句就变得更聪明。它只是在阅读我们给它的信息，然后基于这些信息来回答。

5.2 每一次对话都是无状态的

我们觉得自己在跟 AI "对话"，感觉它"记住"了前面说的话。但实际上，模型本身是没有记忆的。它每一次生成回复，都是从零开始的一次全新推理。

那它怎么做到"记住"之前聊过的内容呢？答案是：每一次我们发消息的时候，产品在后台会把之前所有的对话记录全部打包，连同我们最新这条消息一起，整体丢给模型。模型从头到尾看一遍这些内容，然后生成回复。

我们发第十条消息的时候，模型实际上收到的是前面九轮完整的问答记录加上我们第十条消息。它每次都是在"读完整份聊天记录"之后才回答的，而不是真的"记住"了什么。

5.3 上下文的本质：一份有大小限制的完整档案

理解了上面这个点之后，上下文就好解释了。每次模型回答问题的时候，它面前有一份完整的档案。这份档案里写着：

• 系统给它的行为规则
• 我们之前发的所有消息
• 它之前回复的所有内容
• 中间调用工具的结果

它每次回答的时候，就是把这份档案从头到尾看一遍，然后基于里面的全部内容来生成下一句话。这份档案就是上下文。

问题在于，这份档案有大小限制。每个模型的档案容量不一样，我们通常用 Token 数量来衡量。一个 Token 大约等于一个中文字或者半个英文单词。

5.4 不同模型的上下文有多大

目前主流模型的上下文窗口大小差异很大：

模型	上下文窗口
GPT-5.5 / GPT-5.4	1,050,000 Token
Claude 4.7 Opus / 4.6 Sonnet	1,000,000 Token
Gemini 3.5 Flash / 3.1 Pro	1,000,000 Token
Qwen 3.7 Max	1,000,000 Token
DeepSeek V4 Pro	1,050,000 Token
豆包 Seed 2.0 Pro	256,000 Token
Kimi K2.6	262,000 Token
MiniMax M2.7	205,000 Token
DeepSeek R1	164,000 Token

目前顶尖模型基本都到了 100 万 Token 的级别，大概相当于能装下 2500 页纯文字。

5.5 Agent 的上下文里都装了什么

在 Codex 这样的 Agent 里面，上下文的组成比普通的 AI 对话产品要复杂得多：

• 系统指令：Agent 的行为规则、可用工具的 JSON Schema 描述、当前工作目录等基础信息
• Skill 描述：如果我们安装了 Skill，每个 Skill 的触发条件和说明都会写进去
• 我们发的消息
• 模型的回复
• 思维链：模型在回答之前的推理过程
• 工具调用与结果：它读了哪些文件、文件的完整内容是什么、运行了什么终端命令

我们可能只发了一句"帮我看看这个项目的结构"，但 Agent 在后台可能读了十几个文件，每个文件几百行代码，终端跑了几个命令，这些结果全部写进了上下文。一句话的任务，实际消耗的 Token 可能是几万甚至十几万。

5.6 上下文是一种注意力预算

Anthropic 在他们的官方文章里提了一个很好的说法：上下文是一种有限的注意力预算。我们往上下文里塞的每一条信息，都在消耗模型的注意力。

所以上下文工程的核心原则不是"往里面塞更多东西"，而是"只放最有用的东西"。信息的密度比信息的总量重要得多。

5.7 为什么越聊越笨

随着上下文里的 Token 数量增加，模型的准确率和回忆能力会下降。即使上下文还没写满，只要里面塞的东西太多了，模型找到关键信息的能力就会变差。

所以并不是 AI 越聊越聪明。大多数情况下，上下文越长，AI 的执行质量越低。有效信息的密度才是关键。

5.8 怎么让上下文保持高效

按需获取，不要预加载：不要一开始就把所有可能用到的信息都塞进去。让 Agent 在需要的时候自己去获取就行了。

用子 Agent 隔离上下文：如果一个任务需要读很多代码才能找到关键位置，可以让一个子 Agent 先去做探索，它在自己的上下文里读完几十个文件，最终只把关键的几个路径返回给主 Agent。

已经用过的工具结果可以清掉：好的 Agent 产品会自动清理这些过期的工具返回结果。

重要信息写到外面去：如果有些信息是后面可能还要用到的，与其让它一直留在上下文里占空间，不如让 Agent 把它写到一个本地文件里。

5.9 Codex 的压缩机制

Codex 对上下文过长的问题做了自动处理。当上下文的 Token 用量接近窗口大小的 90% 时，它会自动触发一次压缩。

压缩的过程大概是这样的：把前面的对话历史交给模型生成一段摘要，然后用这段摘要替换掉原始的所有内容，只保留最近的对话和摘要。压缩是有代价的。一旦触发了压缩，之前的原始信息就不可逆了，只剩下摘要。

---

第 6 章：如何与 AI 对话

6.1 不要过度设计提示词

很多人的习惯是，打开 Agent 之前先在脑子里构思半天，然后一次性写一大段话丢过去。他们觉得如果一开始没说清楚，AI 就一定会做错。

但现在不一样了。Agent 是一个可以持续交流的协作者。它能反问我们、能自己去读文件补充信息、能查代码看现有的规范。我们不需要在第一句话里把所有事情都交代完。

6.2 另一个极端：不敢开口

很多人还是把 AI 当成一个搜索引擎，觉得我得先把问题想得很清楚、措辞很精确了才能去提问。但实际上，现在的 Agent 不是一个需要精准输入才能运行的程序。它就是一个什么都可以聊的对话者。所以对新手的建议就是：别想太多，先发出去再说。

6.3 模型已经很强了

2026 年的顶尖模型，不管是 GPT-5.5 还是 Claude Opus 4.7，它们对于各种技术的最佳实践已经有了非常深的理解。比如你让它写一个用户注册功能，它自己就知道密码要加密、要做输入校验、API 状态码要规范。这些东西不需要我们在提示词里一条条列出来。

6.4 为什么一次性长提示词反而效果差

除了浪费时间之外，一次性塞太多信息进去还有几个实际的坏处：

第一，它在消耗上下文预算。上下文里塞的信息越多，模型的注意力越分散。

第二，如果我们预设了太详细的执行步骤，反而限制了 Agent 自己规划的能力。

第三，写太长的提示词花的时间，其实比分两三轮对话还慢。

6.5 Agent 能自己获取信息

Agent 有工具，很多信息不需要我们手动交代：

• 技术栈是什么：它自己读 package.json 或者 requirements.txt
• 代码规范：它自己看现有代码的风格
• 数据库结构：它自己去看 schema 文件
• 项目结构：它自己扫一遍目录

我们需要告诉它的只有两件事：我要什么，以及有什么特殊的限制。

6.6 什么时候该多说一点

不是说永远都一句话就够了。这些情况下确实需要多交代一些：

• 有明确的业务约束
• 有验收标准
• 有个人偏好
• 有特殊的上下文是 Agent 看不到的

但注意，这些都是"约束和目标"层面的信息，不是"执行步骤"层面的。

6.7 对话的节奏

我自己跟 Agent 对话的节奏大概是这样的：

先说目标。简短地描述我要做什么事，不急着给方案。

让它先看看再动手。如果是在一个已有项目里工作，我会让它先看看相关的代码再开始改。

不确定的时候让它出方案。如果一个问题有多种实现方式，我不会自己想好了告诉它用哪种。我会让它给我几个选项，我来选。

方向偏了就直接纠正。不需要重新开话题从头来过，直接在当前对话里纠正比较高效。

无关的问题用 /side。如果做到一半我想问一个跟当前任务无关的问题，用侧边栏功能去问，不要污染主线上下文。

6.8 用语音输入来加速对话

既然跟 Agent 对话是一个渐进式的过程，那输入速度就很重要了。我自己平时大量使用语音输入，比打字快很多，尤其是描述需求这种口语化的内容。

Codex 自带了一个语音输入功能。我自己用的是闪电说，按住右侧 Option 键就能触发，说完松手文字就出来了。如果愿意付费，Typeless 是一个跨平台的选择，按 Fn 键说话，它会用 AI 把口语润色成书面语再输出。

---

第 7 章：话题与项目管理

7.1 代码项目与日常杂事项目的划分逻辑

当你在桌面端左侧看到 Projects 列表时，你需要根据不同的任务类型，采用完全不同的目录挂载逻辑：

• 代码仓库项目：如果我有一个具体的代码目录，比如像 museon 或者是 wolfcha 这种实际的代码仓库，我会直接把它作为一个独立的项目在左侧的 Projects 里打开。
• 日常杂务项目：如果是一大堆日常的繁琐工作，比如给视频添加字幕、做一些特定领域的联网调研、或者帮我构思小红书的选题，我会直接把用户根目录在左侧作为一个项目打开。

为什么要直接把整个用户根目录挂载上去呢？因为很多日常杂事往往需要读取我们电脑里不同路径下的文件。

7.2 话题的独立上下文与文件持久化

我们在使用桌面端时，左侧的每一个独立对话被称为一个话题。Codex 官方叫做线程 thread。每一个话题都拥有自己完全独立的上下文。

如果遇到了非常长的连续任务，我们每开一个话题，都去把长篇的背景设定重新输入一遍，不仅繁琐，而且白白浪费了大量的 Token。

我们可以直接让 Agent 把之前讨论出来的核心人设、选题方向或者调研结论，以 .md 文本文件的形式，直接写入到当前挂载的项目目录里。下一次，当我们新开一个干净的话题、开始新一轮的对话时，我们只需要在输入框里简单地对它发一条指令去读取那个文件就行了。

7.3 话题的置顶功能与常用线程沉淀

Codex 提供了一个小钉子图标，也就是话题的置顶功能（Pin）。点击它，这个话题就会被固定并沉淀到列表最顶端的 Pinned 专属区域中。我平时会习惯把一些高频复用的、作为日常主干任务的对话长期钉在最上面。

7.4 对话框的常用核心设置

无脑选择 Full access 权限

在对话框左下角，你会看到一个权限控制按钮。在日常使用中，我非常推荐大家直接无脑切换为 Full access（完全访问）。如果选择其他受限权限，Agent 每读一个文件、每跑一个命令都要弹窗问你同不同意，用起来很烦。

模型、思考深度与速度配置

在会话框右侧，直接点击模型名字按钮，可以对当前话题的运行大脑进行微调。思考强度可以在 Low、Medium、High、Extra High 几个等级中进行切换。运行速度建议直接勾选 Fast 模式。

7.5 对话信息的排队与插队机制

当 Codex 正在为你读取文件、调试报错时，如果你突然有了新想法，你可以直接把新的对话内容发送到会话框里。Codex 会默认将新对话存放在一个排队队列中。

如果在它正在执行任务的中途，你突然发现它理解错了解法，你可以在新发送的消息旁边，点击 steer（插队）按钮，点击之后 Codex 就会直接插队介入，立刻开始读取你刚刚插队进来的最新指导消息。

---

第 8 章：内置工具功能

很多人在第一次使用 Agent 的时候，往往分不清模型和工具之间的界限。这里有一个基本的认知需要先建立：模型负责思考，工具负责执行。

大语言模型本身其实只是一个运行在云端服务器上的、只能进行文本预测和思考的计算文件。它没有眼睛，没有手脚。而 Agent 的产品机制，就是在这个大语言模型外侧，提供了一个工具箱。

8.1 外部联网与图片设计工具

这一组工具主要帮助 Agent 突破本地文件的限制，去获取外部世界的信息：

• 网页查询与实时信息：Codex 可以直接去搜索互联网，并且支持打开任意网页、读取里面的具体内容。当我们要求它去写一段我们不熟悉的代码时，我习惯在提问里明确要求它先去搜索特定网页。
• 图片搜索与图片生成：Codex 直接自带了图片生成能力。它使用的是目前能力最强的 GPT Image 2 图片生成模型。图片生成除了可以用来做日常的一些设计之外，在 Vibe Coding 时，用来生成我们需要的各种设计素材。

8.2 本地文件修改与终端控制工具

这一组工具是 Agent 帮我们进行日常开发和文件管理的核心能力：

• 文件修改与本地终端：Agent 可以直接读取、写入和精细化修改我们本地的文件。
• 本地图片查看：它原生支持多模态视觉识别，我们可以直接提供一个本地图片的路径，它就能分析图片内容。

8.3 浏览器自动化工具

Codex 内置了 headless 浏览器。同时，如果我们安装了它的 Chrome 浏览器拓展，它就可以直接接管我们的默认浏览器，自动去操作我们已经登录的各种网站。

8.4 任务计划、目标跟踪与执行工具

这组工具保证了 Agent 在执行复杂的长任务时，能够非常有逻辑地推进：

• 任务计划与目标跟踪：在面对复杂的任务时，Agent 会自己在后台维护一个进度清单。它支持 /goal 命令，比如对它说"把这个项目修改到能运行起来为止"，它就会自发地在后台进行循环调试。
• 工作区依赖定位：Codex 能够自动去检索和定位你电脑上预装的各种 Node、Python 依赖。
• 用户输入请求：在遇到关键分歧点时，它会在桌面客户端的界面上弹出一个结构化的多选题 UI 表单。
• 自动化任务：Codex 允许我们在桌面端界面中直接为它配置各种定时自动化任务。

8.5 常用名词解释

• JSON：一种用来表达数据信息的特定文本格式。
• Schema：一份规则定义，用来约束某样东西应该长什么样。
• Metadata：元数据，也就是用来描述别的数据的辅助数据。
• Headless 浏览器：指没有可见软件界面的、运行在系统后台的浏览器。
• MCP 资源：全称是 Model Context Protocol（模型上下文协议）里的连接数据。

---

第 9 章：自动化

9.1 Computer Use 是兜底方案

在 Codex 的设置里面，有一个叫做 Computer Use 的页面。Any App 装了之后，Codex 就能像一个人一样去操作我们的电脑桌面。但这里有一个很重要的认知：Computer Use 是所有自动化方式里优先级最低的。

因为它的工作方式是截屏然后用视觉去识别界面元素，再模拟鼠标和键盘去点击。这个过程的精度和速度都不如专用工具。我平时的做法是：能用专用工具搞定的，就不要用 Computer Use。

9.2 Chrome 插件才是日常自动化的核心

Codex 最近做了一个非常实用的功能：Chrome 插件。在讲 Chrome 插件之前，我先说一下以前我们做浏览器自动化有多麻烦。

以前如果想让 Agent 去操控浏览器，主流的方式有两种：一种是 Agent Browser，但它会开一个全新的浏览器实例，我们得在那个新浏览器里重新登录。另一种是 Browser MCP，配置比较麻烦。

Codex 自己的 Chrome 插件，通过浏览器拓展的方式去接管我们现有的默认浏览器。这样所有的登录状态都是现成的，不需要重复登录。

怎么安装

在 Codex 的 Plugins 里面搜索 chrome，安装这个 Chrome 插件。安装完成后，第一次打开的时候它会引导我们去 Chrome 浏览器里装一个对应的浏览器拓展。

它解决了什么问题

核心就一句话：直接控制我们现有的浏览器，复用我们已有的所有登录状态。

我平时怎么用

• 前端的自动化测试
• 帮我做调研
• 自媒体多平台发布
• 爬一些需要登录才能看到的数据

9.3 它们之间的优先级

如果任务跟浏览器有关（调研、发布、测试网页），优先用 Chrome 插件。如果任务涉及到本地桌面应用，没有其他专用工具能覆盖的，再用 Computer Use。

---

第 10 章：Plan 模式

前面讲自动化和 Goal 的时候，我们讲的都是让 Codex 直接去执行任务。但有些时候，我们不希望它一上来就动手，而是想让它先想清楚再做。Plan 模式就是干这个事的。

10.1 怎么开启

在桌面端输入框左下角的加号菜单里，有一个 Plan mode 的开关。打开之后，我们发送的下一条消息，Codex 不会直接开始写代码或者执行操作。它会先去收集上下文、分析情况，然后给我们出一个执行计划。

10.2 什么时候用 Plan 模式

• 任务比较复杂的时候
• 自己也没想清楚的时候
• 对现有代码不确定影响范围的时候

10.3 搭配 PLANS.md 做长时间任务

如果任务特别大，官方推荐的做法是在项目里放一个 PLANS.md 文件。这个文件的作用是把整个任务拆成多个里程碑，每个里程碑有明确的验收标准。

Codex 在执行的时候会按照这个文件一步步来，每完成一个里程碑就验证一下，验证通过了才进入下一个。

10.4 搭配 Goal 模式使用

Plan 模式和 Goal 模式可以搭配在一起用。我的做法是：先打开 Plan 模式，让 Codex 出一个完整的执行计划。确认方案没问题之后，再用 Goal 模式让它按照这个计划持续执行到完成。

10.5 Plan 模式的局限

方案修改是全量重写的。有时候它不够深入就出方案了。Plan 模式的约束是提示词层面的，不是物理隔离的。方案不会自动保存到本地文件。

我自己的解决办法是：Plan 模式出完方案之后，手动让 Codex 把方案写到一个本地文件里（比如 PLAN.md）。

---

第 11 章：目标设置（/goal 命令）

正常情况下，我们给 Codex 发一条消息，它执行完就停下来等我们说下一步。但如果我们有一个很大的任务，我们其实希望它自己一直干到做完为止，不需要我们一直盯着。/goal 命令就是干这个事的。

11.1 怎么开启

在桌面端里，我们点击输入框左下角的加号按钮，会弹出一个菜单，里面有一个 Pursue goal 的开关。打开之后，我们发送的下一条消息就会被当作一个 Goal 来执行。

11.2 跟普通对话的区别

普通对话的流程是这样的：我发一条消息 → Codex 去做 → 做完了给我结果 → 停下来等我下一条消息。

Goal 的流程是这样的：Codex 做完一步 → 自己检查有没有达到目标 → 没达到就继续做下一步 → 再检查 → 直到达成目标。

11.3 怎么写一个好的 Goal

弱 Goal：

/goal 优化性能

这个写了跟没写一样。

强 Goal：

/goal 把 checkout 接口的 p95 延迟降到 120ms 以下，用 checkout benchmark 来验证，同时保持所有正确性测试通过。只允许修改 checkout service 相关的代码和测试。每次尝试之后记录改了什么、基准测试结果是多少、下一步打算试什么。如果基准测试跑不起来或者找不到有效的优化路径了，停下来告诉我卡在哪。

11.4 适合用 Goal 的场景

• 代码迁移
• 从零建项目
• 性能调优
• 复杂 Bug 排查
• Prompt 优化
• 大型重构

11.5 什么时候不该用 Goal

不是所有任务都适合 Goal。改一行代码、问一个问题、小 Bug 修复、简单的 Code Review，这些直接普通对话就行。

---

第 12 章：侧边栏功能（/side 命令）

在上面讲上下文的时候我们提到过，上下文越长、无关信息越多，Agent 的执行质量就越差。在日常对话的过程中，经常会遇到一个场景：Codex 正在帮我做某个任务，做到一半我突然想问它一个跟当前任务不太相关的问题。/side 就是用来解决这个问题的。

12.1 怎么用

在输入框里打 /side，发送之后它会在右侧新开一个对话窗口。这个右侧的对话有两个特点：第一，它能看到左侧主对话之前的所有上下文信息；第二，我们在右侧说的话不会写进左侧的上下文。

12.2 什么时候用

• 临时问问题
• 对比方案
• 并行执行

12.3 右侧的模型是独立选的

右侧侧边栏的模型可以跟左侧不一样。比如左侧主任务我用 GPT-5.5 跑着，右侧问个小问题我可以切一个便宜点的模型。

---

第 13 章：Rewind 对话回溯

上一节讲 /side 的时候，我们解决的是临时问题不要污染主线。这一节讲的 rewind 解决的是另一个场景：主线已经被污染了，我们想退回到之前某个干净的节点。

13.1 怎么操作

在桌面端里，把鼠标移到历史里之前的某一条消息上，会出现一个回到这一步的入口。点了之后，这条消息之后的所有内容就被丢弃了，对话回到那个时间点的状态。

13.2 最重要的一点：它只退对话，不退代码

rewind 删掉的是上下文，不是文件改动。所以涉及代码改动的时候，我的习惯是 rewind 之前先 git commit 一次。

13.3 跟新开话题、/side、压缩的区别

• 新开话题：完全从零开始
• rewind：保留前面有用的部分，只砍掉后面跑偏的部分
• /side：不动主线，临时开个侧栏问完就回来
• 压缩：系统在上下文快满的时候自动把前面浓缩成摘要

---

第 14 章：记忆功能

前面讲上下文的时候我们提到过，话题和话题之间的上下文是独立的。Codex 的记忆功能就是为了让某些信息跨话题都能记住。

14.1 在哪里开启

在设置里的 Personalization 页面，下面有一块叫 Memory (experimental)。这里有几个开关：Enable memories、Chronicle research preview、Skip tool-assisted chats、Reset memories。

14.2 它是怎么工作的

当一个对话空闲足够长的时间之后（目前是 12 小时以上），Codex 会在后台异步地去分析这个对话的内容，提取出一些它认为有价值的信息，然后生成记忆文件存在我们本地的 ~/.codex/memories/ 目录下。

14.3 我为什么不太用这个功能

我自己是把记忆功能关掉的。目前任何 Agent 的自动记忆功能，写进去的东西大多数都是没用的。比起让 AI 自动去记，我觉得用文件的形式手动管理是更靠谱的。

---

第 15 章：图片生成与 UI 设计

15.1 Codex 自带的生图能力

Codex 内置了 GPT Image 2 的图片生成模型。只要我们订阅了 ChatGPT Pro，就可以直接在对话里让它生成图片，不需要额外配置。

15.2 用 AI 生图来做 UI 设计

我之前测试了一下 GPT Image 2 用来做 UI 设计的效果，结论是：它做出来的 UI 设计稿，可落地性很强，而且审美比我们直接让 AI 写 HTML 代码要好。

15.3 怎么保持设计一致性

我试了两种方式：用提示词约束效果不行；给参考图效果很好。截一张系统里已有页面的图片，作为参考图传给它，然后告诉它"保持侧边栏与参考图完全一致，帮我设计一个新的 XXX 页面"。

我后来的做法是：参考图里只保留需要固定的部分，把右侧内容区清空。

15.4 怎么写生图的提示词

五种不同角度的提示词写法效果差异很大：

• 叙事视角
• 信息清单
• 类比参考
• 用户目标
• 情绪描述（效果最差）

我把这几种策略包装成了一个叫 draw-ui 的 Skill。安装方式：

npx skills add oil-oil/draw-ui

15.5 整体工作流总结

现在我做一个新页面的完整流程：

1. 跟 Codex 说我要做什么页面，提供一张系统现有页面的截图作为参考
2. Codex 用 GPT Image 2 生成设计稿，可能会出几个方案让我选
3. 我选好一个之后，它开始还原成代码
4. 还原的过程中自动分离素材、搭骨架、嵌入图片
5. 在内置浏览器里预览效果

整个过程大概十几分钟到半小时。

---

第 16 章：实用配置

16.1 防止电脑休眠

在 Settings 的 General 里面，有一个 Prevent sleep while running 的开关。打开之后，只要 Codex 还有任务在跑，电脑就不会进入休眠。

16.2 详情展示级别

在 Settings > General 里有一个 Detail level 的选项。默认是 Coding 模式。对于非程序员，可以切到 Default 模式，界面会清爽很多。

16.3 个性化设置

在 Settings > Personalization 里面可以设置两个东西：

• 回复风格：Friendly（友好）和 Pragmatic（精简）两种
• 自定义指令：告诉 Codex 它回复你的时候应该遵循什么规则

16.4 MCP 服务配置

MCP 全称是 Model Context Protocol。在 Settings > MCP servers 里面可以配置，比如我自己配了 Supabase（数据库）、LangSmith（调试）、MongoDB 这些。

16.5 Hook 机制

Hook 是 Codex 的一个进阶功能，它允许我们在特定事件发生的时候自动执行一些脚本。

16.6 Automation（自动化任务）

在桌面端左侧的 Automations，我们可以在这里配置定时执行的任务。比如设置"每天早上 10 点去调研小红书上有什么热门话题"。

---

第 17 章：子 Agent 功能

17.1 什么是子 Agent

子 Agent 就是 Codex 在执行任务的过程中，可以分出去的一个独立的小 Agent。它有自己独立的上下文，做完事情之后把结果交回给主 Agent。

17.2 Codex 不会自动派发子 Agent

Codex 不会自己主动去派子 Agent。只有我们在对话里明确说了，它才会去做。

17.3 子 Agent 的开销

子 Agent 会消耗更多的 Token。因为每个子 Agent 都是一个独立的模型调用，有自己的系统指令、工具调用和上下文。

17.4 自定义子 Agent

Codex 支持我们预先定义好不同角色的子 Agent。定义方式是在项目目录或者用户目录下放一个 TOML 文件。一个 Review 用的子 Agent 可以这样定义：

name = "reviewer"
description = "PR reviewer focused on correctness, security, and missing tests."
model = "gpt-5.4-mini"
model_reasoning_effort = "medium"
sandbox_mode = "read-only"

developer_instructions = """
Review code like an owner.
Prioritize correctness, security, behavior regressions, and missing test coverage.
Lead with concrete findings and include file references.
"""

17.5 子 Agent 的模型选择

不是每个子 Agent 都需要用跟主 Agent 一样高的思考强度。我自己的做法是：子 Agent 也用 gpt-5.5，但把思考程度调低。

---

第 18 章：Skill 的由来与原理

18.1 Skill 到底是什么

很多人第一次听到 Skill 这个词，以为它是某种很高深的东西。其实它就是一份写给 AI 看的操作指南，用文件的方式保存在本地。更直白地说：Skill 就是一个文件夹，里面放了一个 Markdown 文件（SKILL.md），可能还有一些脚本和参考资料。

18.2 为什么需要 Skill

两个原因。第一，AI 本身不具备的知识。第二，重复性的工作流程。

Anthropic 在他们的官方文章里对 Skill 的定位是：把我们的专业经验打包成可复用的资源，让通用 Agent 变成某个领域的专家。

18.3 渐进式加载机制

如果我们装了 30 个 Skill，是不是每次对话这 30 个 Skill 的全部内容都会塞进上下文？不是的。Anthropic 设计了一个叫渐进式加载的机制：

• 第一层：名字和描述。所有 Skill 的 name 和 description 会在每次对话时发送给 AI。
• 第二层：正文内容。只有当 AI 根据 description 判定相关之后，它才会去读取 SKILL.md 的正文。
• 第三层：附属资源。正文里可能会写"如果你需要做 XXX，去读 references/xxx.md"。

18.4 Skill 的文件结构

my-skill/
├── SKILL.md  # 必须有，入口文件
├── references/  # 可选，参考资料
├── scripts/  # 可选，可执行脚本
└── agents/  # 可选，openai.yaml 配置

18.5 触发方式

Skill 有两种触发方式：主动触发（用 $skill-name）和自动触发（AI 根据 description 匹配）。

---

第 19 章：怎么找到和安装 Skill

19.1 去哪里找 Skill

找 Skill 的渠道主要有这几个：

• GitHub 搜索
• Skills Marketplace
• ClawHub
• Codex 桌面端的 Plugins 页面
• 直接让 Agent 帮你找

19.2 怎么安装

方式一：直接让 Agent 装

找到一个 Skill 的 GitHub 链接之后，直接丢给 Codex，跟它说"帮我安装这个 Skill"。

方式二：用命令行安装

npx skills add owner/repo-name

方式三：手动下载

从 GitHub 上把仓库下载下来，然后把文件夹放到对应的目录里。

---

第 20 章：怎么写一个好的 Skill

20.1 现在几乎都是让 AI 来写 Skill

写 Skill 的模型一定要足够强。用最强的模型来写 Skill，相当于把强模型的一部分知识蒸馏进了文件里。

20.2 什么时候值得写成 Skill

我的判断标准很简单：如果一个任务我每天都要做两次以上，或者每次做都要重复交代一遍背景信息，那就值得写成 Skill。

20.3 description 是最重要的部分

好的 description 应该包含三个信息：

1. 这个 Skill 做什么
2. 什么时候应该触发
3. 什么时候不应该触发

20.4 正文怎么写

几个原则：

• 控制在 500 行以内
• 写命令式的步骤
• 用简洁的示例代替冗长的解释
• 每一条信息都要自问：AI 真的需要这个吗？

20.5 用子 Agent 测试 Skill

写完 Skill 之后怎么验证它好不好用？我的做法是让 Agent 启动一个子 Agent，让子 Agent 在干净的上下文里去使用这个 Skill。

---

第 21 章：实用 Skill 场景

21.1 跨 Agent 协作

不同的 Agent 擅长不同的事情。我们可以写一个 Skill，让当前的 Agent 把某些任务委派给另一个 Agent 去做。比如我写了一个 Skill，Claude Code 只要把任务描述传过去，Codex 就会在后台启动执行。

21.2 日常工作流自动化

任何我们每天重复做两次以上的事情，都值得封装成 Skill。比如写日报、提交代码、多平台发布。

21.3 代码库信息提取

代码库里的信息比 PRD 全面，而且永远是最新的。我们可以用 Skill 来从代码里提取各种形式的输出。

21.4 Skill 性能优化：模板化思维

很多 Skill 在生成最终产物的时候，会让 AI 把整个文件从头到尾写一遍。一个优化思路是：把重复的部分做成预置的模板片段，AI 只负责生成内容数据，拼装由脚本来完成。

21.5 Skill 绝对不是越多越好

这个点太重要了。Skill 的元数据（name 和 description）都会在每次对话时写进上下文。Skill 越多，这部分占的空间越大，模型的注意力就越分散。

---

第 22 章：Harness 概念与设计

22.1 什么是 Harness

Harness 这个词直接翻译是"马具"或者"驾驭"的意思。在 Agent 的语境下，Harness Engineering 指的是：如何设计一个让 Agent 能够自主、可靠、持续工作的工程环境。

这三个阶段是递进的：

• 提示词工程：怎么写好一句话让 AI 给出好回答
• 上下文工程：怎么管理好 AI 能看到的所有信息
• 驾驭工程：怎么设计好整个环境，让 AI 能长时间自己干活不出错

22.2 为什么需要 Harness

这些问题的根本原因是：我们每次只是在单独给 AI 下指令，没有设计一套能让它持续稳定工作的规则体系。

22.3 Harness 的几个核心组成

项目规范文件

在项目根目录放一个规范文件（Codex 里叫 AGENTS.md，Claude Code 里叫 CLAUDE.md），告诉 Agent 项目的基本情况。

知识放进仓库

很多项目相关的知识散落在飞书文档、Notion、或者团队成员的脑子里。我自己的做法是在项目里建一个 docs/ 目录，把架构设计、产品需求、数据库结构这些都以文件的形式存进去。

用程序强制执行规则

通过 Hook 机制，在 Agent 每次修改代码之后，程序自动去跑类型检查和 Lint。

让 Agent 具备自我验证的能力

如果修一个 Bug 的流程是：Agent 改代码 → 我们手动去页面上测试 → 把结果告诉 Agent → Agent 再改 → 我们再测试……这个循环里人的参与太多了，Agent 根本没办法自己跑。要让 Agent 能自己跑这个循环，它需要：

• 自己能启动项目和测试环境
• 自己能在浏览器里去看页面效果
• 自己能读取控制台日志
• 自己能判断修复结果是否符合预期

22.4 对于普通用户来说怎么落地

最核心的几件事：

1. 写好项目规范文件（AGENTS.md）
2. 把重复犯的错写进规范
3. 给它接上验证工具
4. 设计好任务的退出条件

---

第 23 章：Vibe Coding 如何提升效率

23.1 多需求并行：用工作树隔离

如果我们手上同时有好几个需求要做，这时候最高效的做法是让它们并行跑，互不干扰。工作树（Worktree）就是干这个事的。它相当于把我们的代码仓库复制了一份出来，在复制出来的那份里面改代码，不会影响到主项目。

在 Codex 桌面端里，新建话题的时候底下可以选 Local（本地项目）或者 Worktree（新工作树）。

23.2 单个话题里的并行：子 Agent

Codex 和 Claude Code 本身就有子 Agent 的能力。关键是什么情况下用子 Agent 效果最好：

• 任务本身可以拆成几块独立的部分
• 每一块需要读取大量文件
• 最终只需要各自的结论汇总

23.3 让 Agent 自己提交代码

安装 GitHub 的命令行工具 gh 之后，Agent 可以直接在终端里操作 GitHub：创建分支、提交代码、推送到远程、创建 PR、查看 CI 状态、合并 PR。

23.4 用 /side 处理临时问题

开发过程中经常遇到这种情况：Agent 正在帮我做一个功能，做到一半我突然想确认一个 API 的用法。用 /side 就很方便：临时开一个侧边栏问完就回来。

23.5 需求描述的颗粒度

效率高不高，很大程度取决于我们给 Agent 描述需求的颗粒度。我的经验是，一个好的需求描述粒度大概是：一次能做完、做完之后能立刻验证对不对的。

23.6 描述行为而不是描述修改

描述你观察到的现象或者期望的行为，比描述你想让它怎么改代码效果好。

23.7 每次做完一步就验证

不要一口气让 Agent 做完整个功能再去看结果。做完一步就验证一下，确认没问题再让它做下一步。

23.8 频繁提交代码

AI 写代码的速度很快，但也意味着代码变化的速度很快。我的习惯是每做完一个小功能点就提交一次。

---

第 24 章：Vibe Coding 如何节省成本

24.1 包月套餐 vs API 按量计费

如果你每天重度开发，包月套餐比 API 按量计费划算太多了。API 计费下你每次让 Agent 读文件、跑命令都在花钱，几轮对话就是几美金。

24.2 不是所有任务都需要最强模型

这是节省成本最直接的方式。我以前的做法是分三层：主模型做需求拆解和决策，便宜模型做具体的代码执行，Gemini 做设计

原文媒体