Codex 最佳实践（超级长文）：先搞懂 AI，再用好 AI

你会学到什么

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

• 明明模型很强，结果做出来的东西却不稳定。
• 同一个任务，换一种说法以后效果差很多。
• 对话越长，AI 越容易跑偏。
• 工具功能很多，却不知道该怎样组织成自己的工作流。
• 看过很多零散教程，真正动手时仍然不知道从哪里开始。

这门课会把这些问题放到一条完整的学习线上讲清楚。课程从 Agent 和普通 AI 对话产品的区别开始，带你理解 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 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 的区别

哈喽大家好，我是 Oil 欧呦，这是本课程的第一章。

其实我个人不太喜欢那种非常刻板的课程章节，先把一些很宏大、与实战无关的立意强行解释清楚，然后再一点点去分析里面的细节。这种方式往往比较枯燥。

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

不同的人有不同的需求。从我个人的学习经历和角度来看，我很多有趣的想法都是基于 Agent 能够做到的事情，去想象它可以覆盖我的哪些场景。我一般不先带着问题再去琢磨 Agent 能不能解决，因为许多问题的解决方向有很多种。

比如给视频添加字幕这件事情，我最开始是使用剪映的，后面也尝试过一些第三方的产品。再到后来，我突然发现使用 Agent 来处理这件事情可以达到高度定制化的效果。我必须首先了解 Agent 能够帮我给视频添加字幕，并且理解它具体如何操作，我才能够想到它在这个场景里其实会比其他产品处理得更好。

从大家自己使用 Agent 的角度来看也是如此。我们理解了 Agent 可以处理哪些事情之后，自然而然就会联想到，自己的某个工作场景是不是可以交给 Agent 来运行，或者它能不能帮自己提升工作效率。所以在开始之前，我先给大家讲解一下 Agent 和普通 AI 对话的区别。

这里我们先列举一些常见的例子。大家平时可能经常听到 通义千问、腾讯元宝、豆包、DeepSeek、ChatGPT、Gemini、OpenClaw、Claude Code、Codex 和 Cursor 这些产品。如果不了解 AI 的人，可能认为它们就是 AI 本身。但其实它们是不同厂商推出的产品，而且这里面有一些属于 AI 对话产品，有一些属于 Agent 产品。很多人对它们的理解可能仅限于国内和国外的区别，下意识地觉得国外的产品比国内更好使用，比如认为 Claude Code 会比 豆包 更加强大。

为什么这里要强调是产品，因为产品和模型其实是两回事。

其实这里面最大的区别在于，它们有一些是 AI 对话产品，有一些是 Agent 产品。

像 通义千问、腾讯元宝、豆包、DeepSeek、ChatGPT、Gemini 都属于 AI 对话产品。

网络上有些 AI 对话产品也支持联网搜索功能，但是它们和真正的 Agent 产品在能力上有着巨大的鸿沟。

AI 对话产品的联网搜索功能本质上是文本提取。当我们输入问题之后，它在后台通过搜索引擎获取一些网页的内容摘要，然后在大模型的窗口里进行信息整理，把答案回复在对话框里。在这个过程里，它无法与网页进行交互，不能点击网页里的各种按钮，不能登录我们自己的账号，更没有办法把获取的信息保存到我们电脑本地的文件夹里。而 Agent 产品的联网则是真正的控制和操作。它可以接管一个真实的浏览器，像人类一样去模拟点击、输入、翻页，甚至可以登录我们自己的账号来执行操作，并且把获取到的各种资料自动下载到本地。

而 OpenClaw、Claude Code、Codex、Cursor 这些产品都是 Agent 产品。

其中 Gemini 除了拥有 AI 对话产品，最近还推出了一个 Agent 产品叫做 Gemini Spark。而 Codex 与 ChatGPT 则都属于 OpenAI 公司。

1.1 什么是 AI Agent

大家平时应该都使用过 豆包，很多人可能习惯在手机上使用它。豆包 就是非常经典的 AI 对话产品。我们在对话框里输入一行问题，它在窗口里回复一段文字，这种一问一答的方式非常适合进行日常咨询或者文字撰写。

但是，如果我们想让它帮我们去处理具体的电脑操作，就会发现它根本做不到。比如我们需要它把某个文件夹里的所有图片重命名，它没有办法直接控制我们的电脑去修改文件名，只能给我们提供一段 Python 代码。我们必须自己把代码复制出来，新建文件，自己在终端里运行。如果运行报错了，我们还要把报错信息复制回去向它提问。这中间需要手动进行大量的复制和粘贴操作。

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

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

在之前，大家对于 Agent 的定义其实并不明确，经常会把一些简单的工作流也当作是 Agent 产品。Anthropic 官方之所以要特意编写一篇文章，就是为了帮大家划分清楚这个分类。而到了现在，大家对于 Agent 产品其实已经有了一个非常明确的定义，那就是可以自己去规划行动以及调用工具的系统。

在官方的分类里，系统被分成了工作流和 Agent 产品。

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

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

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

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

当我们使用普通的 AI 对话产品时，往往会发现它的工作限制非常明显。

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

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

1.3 真实场景下的功能对比

为了让大家更清晰地理解这两种产品的区别，我们可以查看在具体生活场景里，它们面对相同的问题时会产生怎样不同的操作和结果。

场景一：整理旅游攻略

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

• 普通 AI 对话产品：通常只能进行单次的联网查询。它会在后台通过搜索引擎获取这三个景点的相关网页摘要，然后在聊天的文本框里，为你绘制一个由字符拼接而成的排版表格，或者直接打包生成一个可以供你下载的表格文件链接。但是，它没有办法直接打通你本地电脑的操作系统，无法直接将制作好的表格文件写进你的电脑桌面路径里。
• Agent 产品：可以自主利用浏览器自动化工具，逐个访问景点的官方网站，主动点击门票预订或公告页面，获取到当天的最新数据。随后它会直接调用你本地操作系统的文件写入接口，在你的电脑桌面上新建一个真正的表格文件，将数据填写并保存，完成后直接提示运行成功。

场景二：整理本地的照片

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

• 普通 AI 对话产品：直接告知我们无法访问本地电脑桌面，更没有权限修改文件。随后它会提供一段长长的 Python 代码，让我们自己去安装运行环境、配置各种依赖库。如果是不懂代码的非专业用户，面对这些代码只会觉得无从下手。
• Agent 产品：直接读取本地的文件夹。它自己调用图像查看工具，逐张对比照片的清晰度和内容，挑出不合格的照片并移入垃圾箱。同时调用系统的文件管理工具，创建具体日期的分类文件夹，把合格的照片自动移动进去。

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

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

• 普通 AI 对话产品：表示自己无法在后台自发启动，也无法控制其他软件。它只能作为一个被动的工具，在我们主动发送消息提问时给予回复。
• Agent 产品：可以利用其自身自带的定时自动化运行机制（例如 Codex 的 Automation 自动化任务面板）。我们在产品里直接为它配置好定时任务的目标和时间规则，它就会在每天早上九点钟自动在后台启动，控制浏览器并登录我们的社交账号抓取帖子，整理完毕之后直接调用办公软件的发送接口，将简报弹窗发送出来。

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

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

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

• 思考：Agent 会先分析我们给它的整体任务，决定先查看文件夹里有哪些文件。
• 行动：它调用了文件搜索工具，去读取文件夹的内容。
• 观察：它看到了搜索工具返回的文件列表，发现里面有五张图片。
• 思考：它根据拿到的图片列表，决定调用文件重命名工具。
• 行动：它运行了重命名工具，修改了文件名。
• 观察：它确认重命名工具返回修改成功的消息，确认任务已经完成。

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

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

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

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

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

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

从 Coding Agent 到通用 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 的时候，就不要把它局限在写代码这一件事上。任何我们在电脑上做的事情，只要能被拆解成文件操作和命令执行，都可以交给它。

---

常用模型选择

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

很多刚接触 AI 的人，经常会被各种名字搞糊涂。所以我们在挑选模型之前，先把三个概念搞清楚。

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

我们经常听到的一个名字，在不同的语境下，代表的其实是完全不同的东西。我们以 Google 公司的 Gemini 为例。

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

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

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

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

谁是目前最强的首选

目前在海外，最强的三家大模型厂商就是 OpenAI、Anthropic 和谷歌。他们各自有自己最强的模型系列。

在之前，这三家厂商的实力很接近，很难说谁比谁强。但是截止到 2026 年 5 月底，最强的模型已经非常明确了，那就是 OpenAI 的 GPT-5.5 和 Anthropic 的 Claude Opus 4.7。在 Agent 的运行场景下，它们两个是目前表现最好、最顶尖的模型。

在很长的一段时间内， GPT 和 Claude 系列都是大家进行 AI 编程和驱动 Agent 的首选。而我的实操经验是，只要大家能够使用这两个模型，在日常开发和高难度任务中，就没有太大必要去选择其他差一些的模型。

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

Claude 系列

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

GPT 系列

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

Gemini 系列

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

这里有一个很多人忽略的问题：如果你没有使用过最强的模型，你很可能会对 AI 的表现感到不乐观。

我平时接过许多付费咨询。很多人在找我之前，都对 AI 究竟能不能帮他们把事情做好抱有很大的怀疑。当我询问他们之前是如何操作时，他们通常会说，他们之前使用的是某个普通产品去做某件事情，结果发现 AI 给出得回答非常糟糕，或者在任务进行到一定深度时，模型的幻觉就变得很严重，甚至根本无法理解他们输入的真实需求。

这其实是一个误区。他们之所以觉得 AI 不行，很大程度上是因为从来没有体验过真正强的模型。用弱模型去跑复杂的 Agent 任务，效果自然不好。但如果换成 GPT-5.5 或者 Claude Opus 4.7，之前很多搞不定的问题就通了。

当然，除了模型本身的智力之外，还有一个关键因素决定了任务的成败，那就是不同 Agent 产品的 harness 能力。

harness 翻译过来可以理解为马鞍或者鞍具，在 Agent 场景下就是指这个工具套件和底层框架的设计能力。不同的 Agent 产品，它们的 harness 结构设计是略有区别的。哪怕调用完全相同的底层大语言模型，一个设计好的 Agent 框架，能通过更好的工具调度、上下文引导、以及运行时纠错机制，把模型的智力榨取到极限。而一个简陋的框架，则会让同一个模型高频出错。因此，我们在选好顶尖模型的同时，也需要配合一个设计得比较好的 Agent 产品。

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

我们在看模型规格表时，经常会看到单模态和多模态这两个词。

通俗地来解释，模态（Modality）其实就是大模型和外部世界交流的感官通道。

传统的单模态模型只有纯文本这一条感官。它只能读写文字和代码，无法直接感知图像和音频数据。而多模态模型则相当于给大模型增加了视觉、听觉和语音生成。它不仅能够读取纯文字，还能直接看懂你发送给它的图片、视频，甚至直接分析音频录音。

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

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

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

• 生成设计稿：我们可以直接调用 GPT Image 2 等生图工具来做 UI 设计。这里很多人可能会去网上找各种生图提示词模板，其实没必要。在 Agent 里面，我们只要说一个大概的需求（比如"做一个简约风格的 Dashboard 页面"），AI 会自己写合适的生图提示词。网上那些特别长的英文提示词，大多就是 AI 自己写的，不是人手打的。另外生图的时候给一张参考图比纯文字描述效果好很多，AI 能从参考图里提取风格、配色、布局这些信息，比我们用文字描述精确得多。还有一个技巧：如果你看到一张图片想知道它的生图提示词是什么，直接把图片丢给任何一个支持图片输入的多模态模型，让它帮你倒推提示词就行了。
• 精准还原网页：你可以将生成的这几张设计图，或者你在网上看到的任何优秀网站截图，直接发送给拥有视觉能力的顶级模型（如 GPT-5.5、Claude Opus 4.7 或者是原生支持视频和超长图像流识别的 Gemini 3.5 Flash）。它会扫描这张图片，提取出页面里的颜色 HEX 代码、容器圆角大小、文字行高和边距，然后直接写出还原度很高的 HTML 和 CSS 代码。这种从图片直接写成网页的流程，单模态模型是做不到的。

字幕校对时的实际效果

我们在做视频制作或者字幕转录时，经常会遇到同音字转译错误的情况。比如我们在视频里说的是编程工具 Claude Code，普通的语音识别引擎在转录时，由于它只有听觉这单一模态，往往会识别成 cloud call（云端通话）。而顶级多模态模型（如 Claude Opus 4.7 原生支持长视频和关键帧感知）可以处理这个问题。

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

• 第一步，通过音频转译生成初版字幕。
• 第二步，Agent 会在后台对你的视频画面进行关键帧抽帧 OCR 扫描。模型会核对视频画面里电脑屏幕上出现的代码、网站标志、或者是窗口标题。
• 第三步，模型会核对屏幕上显示的 Claude Code，去校对音频听到的同音字 cloud call。一旦发现两者不一致，它就会结合上下文，自动将错漏的字幕修正为准确的专有名词，并且自动处理首字母大写。这种利用视觉纠正听觉的视听联合校对，就是多模态在实际生产场景下的用法。

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

这里大家也需要注意一个细节，那就是原生多模态和插件多模态的性能差距。

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

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

挑选 Agent 模型需要看重什么

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

汇报时的交流感

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

比如早期的 GPT-5.4 在这方面问题就比较明显，方案写得很复杂。而最新的 GPT-5.5 在日常交流方面就改进得很好，基本都是通俗的大白话。相反，Claude Opus 4.7 虽然编程能力得到了提升，但是说话的语气比 4.6 版本要稍微生硬和机械了一些，牺牲了一点日常交流的温度。

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

Agent 产品在连续执行长任务时，上下文会迅速增加。当上下文达到一定长度，Agent 产品会自动运行压缩机制，把之前的对话和工具执行记录进行精简。

在上下文被多次压缩之后，很多普通的模型就会开始出现失忆或者偷懒的情况，容易乱改之前已经定好的代码方案。在这方面， GPT-5.5 的指令遵循度表现非常强，即使在长任务和频繁压缩之后，依然能够严格遵守之前的指令。

修改大文件的稳定性

Agent 产品需要高频地对我们本地的文件进行修改。它通常会先读取一个文件，然后通过搜索 and 替换其中的一段代码来完成修改。

如果模型在这方面不够稳定，它在编辑几十行的小文件时可能没有问题，但在编辑几百行的大文件时，就容易发生替换失败，甚至会自作主张地删掉不相关的代码。

在本地文件编辑的稳定性上，Claude Sonnet 4.6 以及 Claude Opus 4.7 表现很好。而国产的 MiniMax 2.7 虽然运行速度很快，长上下文理解也不错，但在利用 Agent 修改大型文件时，经常会发生定位失败，或者导致大段代码重写丢失。

实际开发中的开销决策

我们在考虑模型开销时，千万不要只盯着模型接口（API）的价格表去计算成本。在实际使用 Agent 产品开发时，计费方式和使用场景才是决定你账单开支的关键。

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

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

如果我们完全使用接口（API）按量计费，遇到复杂的开发任务，随便修改和调试几次功能，可能就会产生几美金甚至十几美金的开销，这会让你在编写时非常肉痛、畏手畏脚。

我的经验是，只要大家在日常重度开发，能够选择“包月订阅”就绝不要选择“API 计费”。比如订阅了 200 美金的 ChatGPT Ultra 升级包月套餐，在 Cursor 或者 Windsurf 里使用 GPT-5.5 或者 Codex 运行高难度的编程，无论你怎么高频提问和重写文件，每月的支出都是固定封顶的。这样就不用每次写代码的时候还在心里算钱了，让你能够全神贯注地去解决具体的业务。

通过子 Agent 分发降低 API 成本

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

• 顶级高智商模型只用来编写开发方案：我们在主窗口里让它设计修改方案。由于它不需要具体去运行文件改写，它在主会话里的轮次就会非常少，上下文很干净，所以整体费用非常低。
• 低开销的辅模型作为子 Agent 去具体修改文件：主 Agent 将写好的确定方案传递给子 Agent。子 Agent 在后台执行高频的文件读取、修改、重试、测试报错以及重新编译。虽然这个过程会产生大量的 Token 消耗，但由于辅助模型的单价很低（通常是顶级模型的十分之一甚至更低），最终的总开支会低很多。

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

不同模型的长处不同，大家需要根据具体的任务类型来进行精准调度，避免大材小用：

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

关于模型生成 Token 的速度，行业里一般会使用 TPS（Tokens Per Second）这个指标来衡量，也就是大模型每秒钟能够输出多少个 Token。

大家在用不同的模型时，对 TPS 的直观体感是完全不同的。如果一个模型的 TPS 在 50 以下，你会觉得输出很慢，代码和文字像是在断断续续地往外蹦。而 Gemini 3.5 Flash 或者是 GPT-5.4 mini 这种轻量模型的 TPS 通常可以达到 150 到 200 以上。

这种高 TPS 的生成速度，在实际使用中非常有优势。比如有些网页展示或者小游戏的需求，用户是不想等待太长时间的。高 TPS 能够做到让一整页 React 代码在一两秒钟内刷地一下全部生成并呈现在屏幕上，等待时间会短很多。如果在终端运行大型重构，高 TPS 的子 Agent 也能很快把文件改完，避免你合上电脑干等。

另外，大家可能还会看到一个叫做 TTFT（Time to First Token，首字响应时间）的参数，也就是你发送指令后，模型需要等待多少毫秒才会吐出第一个字。通常轻量模型反应很快，首字等待时间只有一两百毫秒；而开启深度思考的推理模型，首字等待时间可能需要十几秒。在挑选模型时，我们也要把这两个速度维度考虑进去。

• 运行单点修改和报错排查：这几款优秀的国产模型（GLM-5.1、MiniMax 2.7、DeepSeek V4 Pro）在中英文多任务和常规代码执行中的表现都非常好。但大家需要有一个清晰的预期，当任务复杂度很高、或者上下文达到几十万 token 的时候，它们相较于 GPT-5.5 和 Claude Opus 4.7 依然更容易产生定位失效和规划跑偏。所以，我更推荐让它们在子 Agent 机制下，去具体运行那些已经确定好的单点修改、脚本执行或者常规报错排查，这能帮你省下大量的开发预算。
• 大项目重构与老旧系统维护：如果你的任务涉及复杂的代码依赖重构，或者排查非常隐蔽的内存泄露，千万不要为了省钱而使用低配模型。在这种高难度任务下，低配模型因为逻辑规划不完善，经常会陷入修改错误、报错、重新修改失败的死循环，最终反复累计消耗大量 token。你以为省了钱，结果最终产生的账单开销反而比直接使用 GPT-5.5 或 Claude Opus 4.7 一次性修改成功还要昂贵。

我的模型组合演变过程

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

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

• 产品经理：使用 Claude Opus 4.6。因为它的需求理解能力很强，交流感好，代码设计能力也出色。
• 日常执行者：使用 GPT-5.3 Codex。因为它的接口调用价格非常便宜，我让 Claude 把各种需要机械化运行的零碎开发任务，通过子 Agent 派发给 Codex 去执行。
• 设计师：使用 Gemini 3.1 Pro。因为 Claude 和 Codex 在视觉设计上的审美比较单一，而 Gemini 能够根据简单的需求，设计出质感非常好的界面。

现在我已经不用这种多模型的搭配了，直接 All-in-One： 现在我完全使用 Codex 加上 GPT-5.5 运行日常所有的开发任务。

一方面是 GPT-5.5 修了之前说话晦涩的问题，交流感和编程能力都不错了。另一方面，我订阅了 200 美金的 ChatGPT Ultra 套餐，额度很够用，每天重度开发也花不完，性价比比 Claude 高很多。

至于设计审美的短板，我已经通过自己开源的 draw AI 插件，配合 GPT Image 2 进行 AI 生图来直接设计界面，然后再让 Codex 将设计图还原为 HTML 写入项目里，把设计这个环节也覆盖了。

Codex 的介绍与定位

在上一章里，我们详细讨论了如何选择适合 Agent 的大语言模型。在这一章里，我们来讨论本课程的核心主角：Codex。

很多人在接触命令行 Agent 的时候，第一个想到的往往是 Anthropic 推出的 Claude Code。

在以前的很长一段时间里，Claude Code 几乎是所有人公认最顶尖、最成熟的 Agent 产品。因为 Anthropic 这个公司在 Agent 的设计和工程落地方面积累了很多经验。他们很早就发布了一系列质量很高的研究文章，包括如何设计工具（Tools）、如何利用渐进式加载去设计 Skill 机制，以及如何高效地去管理上下文空间。

在我的实际开发和学习过程中，这些文章对我来说是必读的参考。再加上 Claude 本身编程推理和需求理解能力很强，Claude Code 在很长一段时间内，基本没有其他产品能达到它的水准。

既然 Claude Code 这么强，那为什么 OpenAI 后来推出的 Codex 会吸引我，并且逐渐成为了我的日常主力呢？这里其实有一个非常重要的行业背景。

在之前很长的一段时间里，OpenAI 并没有把全部的精力放在 Codex 上面。他们当时更倾向于去做一些覆盖面非常广泛的多媒体 AI 应用，比如备受关注的视频生成模型 Sora 这一类。这导致在 Agent 领域，OpenAI 被早早深耕此处的 Anthropic 抢占了先机。

后来竞争格局变了。2026 年 3 月底 OpenAI 关掉了 Sora 视频应用和 API，战略重心转向了代码生成和 Agent 方向。

为了应对 Anthropic 的强力竞争，OpenAI 开始在 Codex 上全面发力。调配了顶级的算力来支持 Codex 的迭代，在 2026 年上半年高频更新，推出了多端联动的桌面端和更强大的底层执行模型。这也是为什么 Codex 最近的能力提升很快，并且开始在开发效率上追上 Claude Code。

我们先从 Codex 现在的具体形态说起。

什么是 Codex

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

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

如果你习惯了使用普通的 AI 对话窗口，你可能觉得它只是一个写完代码让你自己去复制粘贴的对话框。但如果我们使用 Codex，我们把它启动在某个项目目录里，它就能够直接和我们的本地系统进行文件级别的交互，自己把代码写好并且编译运行，帮我们完成那些原本需要手动运行很多步的繁琐工作。

它们其实几乎没有区别

作为目前市面上最强大的两个终端 AI Agent 产品，大家经常喜欢把 Codex 和 Claude Code 拿来进行全面对比。

但是在我的实际使用体验中，它们两个在日常开发的使用体感上，其实几乎没有任何区别。

首先，它们的核心交互流程和节奏是完全一致的。它们都是在本地命令行终端里运行。当你敲下启动命令后，都会进入一个流式的黑乎乎的终端交互面板。当你输入一个开发需求，它们都会自主去扫描项目目录、读取本地文件、在后台执行测试和编译。在它们准备进行任何代码修改或者运行敏感的终端指令之前，都会在屏幕上弹出一个确认提示，等待你按下回车键进行授权。

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

你只要学会了其中任何一个工具的使用方法，在切换到另一个工具时，基本不需要承担任何额外的学习和适应成本。

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

• 模型生态：Claude Code 默认绑定 Anthropic 官方的 Claude 系列模型。而 Codex 则是 OpenAI 旗下的产品，默认使用 GPT 系列模型。
• 产品形态：Claude Code 目前依然是一个纯粹运行在终端命令行里的工具。而 Codex 除了命令行工具之外，OpenAI 官方还为它封装了更方便管理多个并行开发任务的桌面端应用，以及多端联动的手机端。
• 账号安全性：这是一个对国内用户来说非常现实的痛点。Anthropic 的风控机制很严，甚至可以说对国内 IP 存在明显的地域限制，大面积封禁国内关联的账户，很多人刚充值了订阅会员或者绑定了虚拟卡，几秒钟内就会被无预警封号。这导致使用 Claude Code 经常面临很高的断连和封号风险。相比之下，OpenAI 针对中国用户的常规网络访问和充值的风控逻辑要宽容、稳定得多，使用起来很少会遇到动辄封号的糟心情况。

跟 OpenClaw 的区别在哪

很多人可能还会问到另一个最近很火的工具：OpenClaw。

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

但是它们在产品设计上的取向是不同的。

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

而 Claude Code 是一个专注于写代码的工具。它有 Task 拆解、Worktree 分隔、LSP 语义导航这些对工程师来说很实用的能力。大部分人使用 Claude Code 的时候，不会去开启什么复杂的记忆系统，因为代码仓库本身就是它的记忆。它要做的事情就是跟写代码有关的，读现有的代码就能知道项目是做什么的，有什么规范、什么设计风格。上下文保持干净，执行任务的效果就会更好。

这里有一个我自己的观察：OpenClaw 带着记忆带着灵魂，有一定的情绪价值，但它在严肃处理工作任务的时候，效果是不如 Claude Code 这一类编程工具的。因为你想要调用 Agent 去执行任务，它的上下文越短、质量越高越好。一大堆跟当前任务无关的记忆塞在上下文里面，反而影响了它的执行能力。

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

我为什么选择使用 Codex

其实不同的 Agent 产品之间差别没有想象中那么大。我选 Codex 主要就是因为它搭配 GPT-5.5 的整体效果不错。

一方面，在日常高强度的开发之下，我订阅了 ChatGPT Pro 包月套餐，额度高得根本用不完。相比于处处受限、或者很贵的 API 按量扣费，这种不限额度、能够让我随便折腾、随便试错，用起来非常爽。

另一方面，GPT-5.5 在图片生成模态上的表现很好。它无缝支持官方最新的 GPT Image 2 图片生成工具。我们在日常使用时，甚至可以直接在会话里通过生图的方式来帮助我们进行 UI 界面或者是创意资产的设计和迭代。

Cursor 作为替代入口

这里补充一个现实问题。Codex 要用的话，我们得订阅 ChatGPT Pro，这需要有美区的手机号或者信用卡才能完成付款。Claude Code 也一样，Anthropic 的订阅对国内用户来说门槛更高，还有封号风险。很多人卡在这一步就上不去了。

如果你暂时买不到 GPT 的直接订阅，没有美区手机号，或者没有信用卡，又想快速体验多个顶尖模型搭配 Agent 的效果，可以去用 Cursor。

Cursor 的好处在于：

它是一个桌面应用，下载安装的门槛很低。里面所有的配置（Plugin、Rules、Skill、MCP）都是可视化的，有地方可以点，不用去命令行里敲斜杠命令。

它聚合了当前最强的几个模型。GPT-5.4、Claude Sonnet、Opus、Gemini 3.1 Pro，这些模型都在里面，你可以自己选择使用。

它不跟单一的模型厂商绑定。用 Codex 的话我只能用 GPT，用 Claude Code 的话我只能用 Claude。但 Cursor 里面既有海外的顶尖模型，也有国内的一些模型，我们可以自由切换，对比哪个效果好。

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

在下一章里，我们将正式开始搭建 Codex 的运行环境，并且详细拆解它的配置文件。

---

安装与基础配置

在决定使用 Codex 之前，我们需要先准备好本地的运行环境，并且在软件里登录账号、完成基础的参数配置。

我们需要准备的运行环境

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

一是 Node.js 环境。建议直接安装最新的 LTS 稳定版本。因为我们后续通过 MCP 协议去加载和管理各种外部工具、发布插件时，大部分底层脚本都需要依赖 Node.js 运行环境。 二是 Git 工具。因为 Agent 在自动进行代码修改和 /goal 长期任务时，需要自动在本地进行代码差异比对、新分支的切分和代码提交，所以本地的 Git 命令行环境是必不可少的。

如何下载和安装桌面端

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

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

安装完毕之后，直接双击打开软件就行了。

Windows 用户注意：Codex 在 Windows 上支持原生的 PowerShell 沙盒，不需要装 WSL 或虚拟机。但如果你的项目依赖 Unix 命令（比如 sed、grep 这些），可能还是需要配一下 Git Bash 或者 WSL。大部分日常使用不会遇到问题。

打开之后左侧是导航栏：New chat（新对话）、Search（搜索历史）、Plugins（插件和 Skill）、Automations（自动化任务）。中间是对话区域。底部是输入框，我们所有跟 Agent 的交互都从这里开始。

登录我们的账号

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

需要提醒的是，官方目前虽然还支持 OpenAI API 密钥（即输入 sk- 开头的密钥）进行单独的 Token 扣费，但如果是重度开发，高频的上下文读取会导致 API 的扣费速度很快，没用几天可能几十美金就花出去了。因此我最推荐的方式就是直接登录已经订阅的 ChatGPT Plus 或者是 ChatGPT Pro 账号，直接使用订阅内包含的可用额度，这会帮我们节省很多开发成本，也完全不用承担多余的账单焦虑。

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

完成了账号的登录之后，我们就可以对它的运行规则和基础参数进行修改了。Codex 所有的参数，都是通过一个叫做 config.toml 的配置文件进行控制的。

我们可以直接在可视化界面里找到这个文件的修改入口。在左侧导航栏里，点击 Configuration 面板，你就会在右侧看到一个 Open config.toml 的按钮。

点击它，系统就会自动为你调起本地的文本编辑器来直接编辑全局的 config.toml 配置文件，界面入口如下：

如果你在 Cursor 或者 VS Code 编辑器里修改这个 .toml 文件，我建议你在配置文件的最顶上敲入下面这行代码。它会为你提供参数自动补全和格式诊断：

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

常用的核心参数配置

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

• 功能特性开关（[features]）：
  • goals = true：开启后，支持强大的异步长期任务（/goal 命令）。
  • hooks = true：开启后，支持通过编写自动化的 Hook 机制来监听和扩展 Agent 的运行事件。
• 常用的核心参数（根级别）：
  • model = "gpt-5.5"：推荐的全局默认主力模型。
  • model_reasoning_effort = "high"：思考深度。可选 low / medium / high。low 速度快但分析浅，high 慢但推理能力强。我日常用 medium，复杂任务切 high。
  • sandbox_mode = "workspace-write"：沙盒模式。这个设置决定了 Agent 能动哪些文件。workspace-write 只允许改当前项目目录里的文件；read-only 只能看不能改；如果设成完全不限制的模式，它就能改你电脑上任何位置的文件，一般不建议。
• 外部工具接口（[mcp_servers]）：
  • [mcp_servers.filesystem]：控制加载的本地文件系统插件，定义命令（npx）、参数（@modelcontextprotocol/server-filesystem）以及激活状态（enabled = true）。
• 账号与账单权限（[billing]）：
  • model_provider = "chatgpt"：绑定 ChatGPT 的高级订阅服务，将大模型执行额度直接挂载在你的 ChatGPT Plus ($20/月) 或者是 ChatGPT Pro ($200/月) 个人账单额度上。

这个参数规格在最新的 2026 软件生态下是完全保持同步的，后续我们如果调试了新的工具（如 Git 提交、Browser 控制等），也会随时在对应的章节进行实时参数记录与补充。

完成这些核心参数配置后，按下快捷键保存文件，我们的 Codex 专属控制台就已经完全配置妥当。

这里还有一个非常省事的小技巧：既然你已经用上了 Codex，其实大部分的 config.toml 配置参数，你根本不需要自己动手去打开文件逐行修改。

因为 Codex 作为一个能够直接读写文件的 Agent，它自己是拥有修改配置文件的能力的。我们只需要在会话框里直接给它发一句话，比如：“帮我把配置文件的默认模型换成 gpt-5.5，并且把推理思考强度设置为 high”，或者“帮我把配置文件的 goals 特性开关打开”。

它就会自己去寻找我们个人根目录下的 config.toml 文件，自发地把这些配置行修改好，并且在修改前把修改计划展示在屏幕上。这种让 AI 帮我们配置 AI 的懒人做法，才是使用 Agent 最该培养的直觉。

Skill 的触发入口

Codex 的桌面端里，点击左侧的 Plugins，切到 Skills 标签页，可以看到当前已安装的所有 Skill。我们在对话的时候，可以用 $skill-name 的方式手动触发某个 Skill，也可以直接说话让 Codex 根据语义自动匹配。

Skill 是 Codex 非常核心的扩展机制，我们会在后面的第八章里详细讲解它的原理、怎么找、怎么安装、以及怎么自己写。这里大家先知道在哪里能看到就行。

从下一章开始，我们将正式进入具体功能的使用实操中。

---

上下文工程

之前我和一个不怎么用 AI 的朋友聊天，他跟我说了一个让我很意外的认知。他说他觉得 AI 是越用越聪明的，就像养一只宠物一样，你陪它的时间越长，它就越了解你，越聪明。

然后他跟我说了一个他实际遇到的问题：他跟豆包聊了一整天，一开始聊得很好，它记得他的名字、他之前说过什么。但聊着聊着，他突然发现豆包好像忘记他是谁了，之前聊过的东西也想不起来了。他非常困惑，问我说这 AI 不是越来越聪明的吗，怎么突然变笨了？

我相信有这种困惑的人不在少数。在我们正式开始使用 Codex 之前，有必要先把上下文这个概念说清楚。因为后面的话题管理、Goal 命令、压缩机制，全部都跟这个东西有关。

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

这个可能是很多人最大的误解。

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

那它为什么一开始看起来很"懂你"呢？因为我们之前跟它说过的话，还在它的"视野范围"内。但这个视野是有边界的。

每一次对话都是无状态的

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

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

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

这个认知很重要，因为它直接解释了为什么聊多了之后 AI 会变慢、变贵、变笨：每一条新消息，都要重新发送前面所有的内容。聊得越长，每一轮的信息量就越大。

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

理解了上面这个点之后，上下文就好解释了。

每次模型回答问题的时候，它面前有一份完整的档案。这份档案里写着：

• 系统给它的行为规则（比如"你是一个有帮助的助手"）
• 我们之前发的所有消息
• 它之前回复的所有内容
• 中间调用工具的结果（比如它读了什么文件、搜了什么网页）

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

这份档案就是上下文。

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

不同模型的上下文有多大

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

模型	上下文窗口
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 页纯文字。而部分模型还在 20 万左右。

上下文窗口大意味着什么？意味着我们可以在一次对话里塞进更多的背景信息。比如我们让 Agent 去分析一个大型代码项目，如果上下文窗口够大，它可以一次性读取更多的文件，对整体架构的理解就更完整。如果窗口太小，它只能看到局部，容易做出片面的判断。

对于 Agent 来说，上下文大还有一个好处：它可以在不触发压缩的情况下执行更长的任务链。每一次工具调用的结果（文件内容、终端输出、网页内容）都会写进上下文。一个复杂任务下来，可能轻松消耗几十万 Token。窗口大的模型能撑更久才需要压缩，任务执行的连贯性就更好。

Agent 的上下文里都装了什么

在 Codex 这样的 Agent 里面，上下文的组成比普通的 AI 对话产品要复杂得多。我们平时看到的只是聊天界面上的几条消息，但实际上在后台，每一轮对话传给模型的档案里塞了很多东西：

• 系统指令 — Agent 的行为规则、可用工具的 JSON Schema 描述、当前工作目录、日期时间等基础信息
• Skill 描述 — 如果我们安装了 Skill，每个 Skill 的触发条件和说明都会写进去
• 我们发的消息 — 就是我们在输入框里打的内容
• 模型的回复 — 包括它生成的文字回复
• 思维链 — 模型在回答之前的推理过程（在支持 thinking 的模型里会很长）
• 工具调用与结果 — 它读了哪些文件、文件的完整内容是什么、运行了什么终端命令、终端输出了什么、搜索了什么网页、网页内容是什么

这些全部堆在一起，就是一轮对话的真实上下文体积。

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

这里面最大的消耗来源往往是工具调用的返回结果。一个文件可能几千行，一次终端输出可能几百行，一个网页抓取下来可能上万字。这些东西一旦写进上下文，就会一直待在里面，每一轮对话都要重新发送。

上下文是一种注意力预算

Anthropic 在他们的官方文章里提了一个我觉得很好理解的说法：上下文是一种有限的注意力预算。

什么意思呢？我们往上下文里塞的每一条信息，都在消耗模型的注意力。如果里面全是跟当前任务高度相关的信息，模型的注意力集中，执行效果就好。但如果里面混进了大量跟当前任务无关的东西——比如三十分钟前读过的一个文件的全文、一个已经用完的工具返回结果、或者一堆根本不会触发的 Skill 描述——那模型的注意力就被这些噪音分散了。

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

这也解释了一个现象：有些人装了一堆 Plugin，每个 Plugin 底下带了几十个 Skill，这些 Skill 的描述全部会写进上下文。虽然大部分时候它们不会被触发，但它们的描述文本一直在那里占着空间、分散注意力。Skill 不是越多越好，越准确越符合使用场景才越好。

为什么越聊越笨

回到我朋友的问题。他跟豆包聊了一天，为什么后来它忘记他是谁了？

原因有两个：

第一个原因是上下文写满了，前面的内容被丢掉或者压缩了。当档案装不下的时候，产品要么把最早的对话内容直接删掉，要么用一段简短的总结来替代原始的详细内容。替代之后，那些细节就丢了。

第二个原因更重要，Anthropic 在官方文档里把这个现象叫做 Context Rot（上下文腐烂）：随着上下文里的 Token 数量增加，模型的准确率和回忆能力会下降。

这意味着，即使上下文还没写满，只要里面塞的东西太多了，模型找到关键信息的能力就会变差。就像一份档案里密密麻麻写了几万个字，你让它从里面找到第一页里的某个细节，它大概率找不准。

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

怎么让上下文保持高效

理解了上面这些原理之后，我们就可以主动去管理上下文的质量了。这里有几个实用的思路：

按需获取，不要预加载。 不要一开始就把所有可能用到的信息都塞进去。让 Agent 在需要的时候自己去获取就行了。比如它需要看某个文件的时候自己去读，而不是一开始就把整个项目的文件列表全部塞进上下文。

用子 Agent 隔离上下文。 如果一个任务需要读很多代码才能找到关键位置，可以让一个子 Agent 先去做探索，它在自己的上下文里读完几十个文件，最终只把关键的几个路径返回给主 Agent。这样主 Agent 的上下文始终保持精简。我自己写了一个叫 Explore 的 Skill 就是干这个事的。

已经用过的工具结果可以清掉。 Agent 读了一个文件、做了判断、写了代码，这个文件的内容在后续对话里其实已经不需要了。好的 Agent 产品会自动清理这些过期的工具返回结果，只保留工具调用的记录（调了什么、结论是什么），把原始的大段返回内容丢掉。

重要信息写到外面去。 如果有些信息是后面可能还要用到的，与其让它一直留在上下文里占空间，不如让 Agent 把它写到一个本地文件里。之后需要的时候再去读取。这比让几万字的信息一直待在档案里高效得多。

Codex 的压缩机制

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

压缩的过程大概是这样的：把前面的对话历史交给模型生成一段摘要，然后用这段摘要替换掉原始的所有内容，只保留最近的对话和摘要。相当于把之前厚厚一沓的档案浓缩成了一页纸，腾出空间来继续对话。

这就是为什么我们在 Codex 里聊了很长时间之后，有时候会觉得它好像"忘记"了一些之前的细节。不是它变笨了，而是那些细节在压缩的时候被简化掉了。

压缩是有代价的。一旦触发了压缩，之前的原始信息就不可逆了，只剩下摘要。如果某个关键细节没有被摘要捕捉到，它就丢了。所以与其等到上下文满了被动压缩，不如我们主动去控制上下文的长度——新的任务开新的话题，保持每个话题短而精。

这也是为什么下一章我们要讲话题管理和对话技巧：理解了上下文的本质，我们就能更好地跟 Agent 协作。

---

如何与 AI 对话

在我跟很多人聊 Agent 使用体验的过程中，我发现一个很普遍的现象：大家花了太多时间在写提示词上面。

很多人的习惯是，打开 Agent 之前先在脑子里构思半天，然后一次性写一大段话丢过去，恨不得把目标、步骤、格式、限制条件、异常处理全部塞进第一句话。他们觉得如果一开始没说清楚，AI 就一定会做错。

这个思路在以前用 ChatGPT 网页版的时候可能是对的，因为那时候模型能力没那么强，而且它没有工具，没办法自己去查信息。我们确实得把所有东西都喂给它。

但现在不一样了。

另一个极端：不敢开口

跟过度设计提示词相反，还有一批人连怎么跟 AI 说话都小心翼翼的。

我碰到过很多来找我咨询的人，他们问我的问题其实随便问一下 Agent 就能得到答案。但他们就是不去问，宁愿来问一个用过的人。

我觉得原因有两个。第一个是心理门槛。很多人还是把 AI 当成一个搜索引擎，觉得我得先把问题想得很清楚、措辞很精确了才能去提问。就像以前用 Google 搜索一样，关键词不对就搜不到东西。他们还没有建立起"随便问就行"的心智。

第二个是不知道它能做什么。他们对 Agent 的能力边界没有概念，不确定这个问题它能不能答、答得对不对，所以宁愿问人。

但实际上，现在的 Agent 不是一个需要精准输入才能运行的程序。它就是一个什么都可以聊的对话者。你用什么口气说都行，说错了它会帮你纠正，说不清楚它会反问你。你甚至可以直接跟它说"我不知道怎么描述这个问题"，它会引导你把问题说清楚。

所以我对新手的建议就是：别想太多，先发出去再说。发出去之后不满意、方向不对、描述不清楚，都可以继续聊继续改。跟 Agent 对话的成本是很低的，不要在脑子里把它变成一个高门槛的事情。

模型已经很强了

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

我们真正要做的，只有一件事：想清楚自己到底要什么。

很多时候我们跟 Agent 对话效果不好，不是因为提示词写得不够详细，而是因为我们自己都没想清楚自己要的是什么。我们把"想清楚需求"这件事的责任推给了提示词的复杂度，觉得写越多越安全。但其实一个目标明确的短句子，比一个模糊的长段落有用得多。

Agent 不是脚本，是协作者

跟以前的 ChatGPT 对话不同，Agent 是可以持续交流的。它能反问我们、能自己去读文件补充信息、能查代码看现有的规范。我们不需要在第一句话里把所有事情都交代完。

一个实际的例子：

有些人会这样写提示词："帮我写一个用户管理模块，要有注册登录功能，用 JWT 做鉴权，密码要 bcrypt 加密，数据库用 PostgreSQL，要有邮箱验证，注册后发验证邮件，用 Resend 来发，前端用 React，表单用 React Hook Form 加 Zod 校验，错误提示要中文，API 要 RESTful 风格，状态码要规范……"

这一大段话写下来花了好几分钟，但其实里面有一半的信息 Agent 自己就能从项目里看到。它打开 package.json 就知道你用什么框架，看一眼现有代码就知道你的风格规范是什么。

我的做法通常是先说一句话：

"帮我做一个用户注册登录功能。"

发出去之后，Agent 可能会反问："你需要邮箱验证吗？还是手机号？有偏好的鉴权方式吗？"

我再补充几个关键决定就行了。剩下的，它自己去看项目里有什么、现有代码是怎么写的，自己做判断。

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

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

第一，它在消耗上下文预算。上一章讲过，上下文里塞的信息越多，模型的注意力越分散。一段几百字的提示词，如果里面有一半是 Agent 不需要的废话（比如它自己就能判断的最佳实践），那这些文字就是在浪费注意力预算。

第二，如果我们预设了太详细的执行步骤，反而限制了 Agent 自己规划的能力。它可能有比我们想的更好的实现路径，但因为我们把步骤写死了，它就只能按我们说的来。

第三，写太长的提示词花的时间，其实比分两三轮对话还慢。很多时候我们花十分钟在脑子里构思提示词，不如花一分钟写个简短目标发出去，然后在对话中逐步补充。

Agent 能自己获取信息

这是跟 ChatGPT 网页版最大的区别。Agent 有工具，很多信息不需要我们手动交代：

• 技术栈是什么 → 它自己读 package.json 或者 requirements.txt
• 代码规范 → 它自己看现有代码的风格
• 数据库结构 → 它自己去看 schema 文件或者 migration
• 项目结构 → 它自己扫一遍目录
• 这个功能别人怎么做的 → 它自己去搜索

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

什么时候该多说一点

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

• 有明确的业务约束 — 比如"不能改现有的 API 接口"、"这个功能只对付费用户开放"
• 有验收标准 — 比如"测试全部通过才算完"、"页面加载时间不能超过 2 秒"
• 有个人偏好 — 比如"我不喜欢用 class 组件"、"变量命名用英文不要拼音"
• 有特殊的上下文是 Agent 看不到的 — 比如产品经理口头跟你说的需求、还没写进文档的约定

但注意，这些都是"约束和目标"层面的信息，不是"执行步骤"层面的。我们告诉它"什么不能动"、"做到什么程度算完"，而不是告诉它"第一步做什么第二步做什么"。

对话的节奏

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

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

让它先看看再动手。 如果是在一个已有项目里工作，我会让它先看看相关的代码再开始改。这样它基于已有代码做决策，而不是靠猜。

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

方向偏了就直接纠正。 如果它做到一半我发现方向不对，直接跟它说"这个不是我要的，我要的是……"就行了。不需要重新开话题从头来过，直接在当前对话里纠正比较高效。

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

对话的本质

跟 Agent 对话不是写一段命令让它去执行，而是跟它一起搞清楚要做什么事，然后让它去干。我们负责提供目标和约束，它负责规划和执行。模型对大多数技术方案的理解已经很深了，我们不需要教它怎么做，只需要想清楚自己要什么。

用语音输入来加速对话

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

Codex 自带了一个语音输入功能，在输入框右下角有个小麦克风图标，点了之后它会用 OpenAI 的模型做语音转文字。但如果我们本地有其他语音输入工具，体验会更好，因为响应更快、不需要等网络。

我自己用的是闪电说，按住右侧 Option 键就能触发，说完松手文字就出来了。它支持本地和云端识别模型，还能自动做口语过滤和结构化，把我们说的大白话整理得稍微正式一点。免费就能用，Mac 和 Windows 都支持。

如果愿意付费，Typeless 是一个跨平台的选择（Mac、Windows、iOS、Android 都有），按 Fn 键说话，它会用 AI 把口语润色成书面语再输出，体验比较顺滑。还有一些开源的方案比如 Whisper 本地部署，适合对隐私比较在意的人。

对于 Vibe Coding 来说，语音输入的效率提升很明显。我们不用在脑子里把需求组织成精确的文字再打出来，直接说就行了。说得不够清楚也没关系，Agent 会自己理解或者反问。

---

话题与项目管理

在日常的重度开发或者日常琐事里，如何高效地组织自己的项目和会话，直接决定了 Agent 的执行效率和我们自己的使用手感。

这一节我们来聊聊在 Codex 桌面端应用中，如何进行话题和项目的管理。

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

当你在桌面端左侧看到 Projects 列表时，你需要根据不同的任务类型，采用完全不同的目录挂载逻辑。这也是我平时使用中沉淀出的两个核心习惯：

• 代码仓库项目：如果我有一个具体的代码目录，比如像 museon 或者是 wolfcha 这种实际的代码仓库。我会直接把它作为一个独立的项目在左侧的 Projects 里打开。后续关于这个仓库的所有 Bug 修复、功能迭代或者代码扫描，我都会在这个项目里独立开启新话题去运行。因为这样可以保证上下文非常干净，让 Agent 只聚焦在这一个仓库的局部代码里。
• 日常杂务项目：如果是一大堆日常的繁琐工作，比如给视频添加字幕、做一些特定领域的联网调研、或者帮我构思小红书的选题，我绝对不会单独去给它们新建一堆项目。我的做法是直接把我的用户根目录（例如 /Users/linzhihuang）在左侧作为一个项目打开。

在左侧打开用户根目录后，整个界面入口如下：

为什么要直接把整个用户根目录挂载上去呢？因为很多日常杂事往往需要读取我们电脑里不同路径下的文件。比如，视频文件通常存放在系统的视频文件夹里，写好的脚本可能在另一个临时文件夹里，小红书的背景人设文档又在其他的目录中。

如果项目范围设得太小，Agent 读取项目外面的文件就会报错。我的做法是直接把用户根目录作为一个大项目挂在左侧，这样 Agent 随时都能读到我们需要的任何路径，不管是工具调用还是做调研都很方便。

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

我们在使用桌面端时，左侧的每一个独立对话被称为一个话题。Codex 官方叫做线程 thread。

这里大家必须牢记一个最基础的运行规则：每一个话题都拥有自己完全独立的上下文。

也就是说，你在上一个话题里和 Agent 聊过的背景信息、分析出来的结论，当你新建一个话题的时候，在它的临时记忆里是完全不存在的。

如果遇到了非常长的连续任务，比如做一些需要花费好几天来构思的小红书选题，或者分步骤调试一个大脚本。如果我们每开一个话题，都去把长篇的背景设定重新输入一遍，不仅繁琐，而且白白浪费了大量的 Token。

其实，许多专门用来编程的 Agent 产品，早就默认采用这个逻辑来工作了。只是一般用户在面对 AI 时，还没有习惯去把 Agent 当作一个拥有本地文件系统的完整程序来看待。

既然我们知道话题的临时记忆会随着关闭而清空，但是我们本地项目目录里的文件是永远不会丢失的。我们可以直接让 Agent 把之前讨论出来的核心人设、选题方向或者调研结论，以 .md 文本文件的形式，直接写入到我们当前挂载的项目目录里。

下一次，当我们新开一个干净的话题、开始新一轮的对话时，我们只需要在输入框里简单地对它发一条指令：“去读取当前项目目录下的 references/persona.md 获取我的背景，然后我们继续昨天的选题。”

通过这种用本地文件充当持久化记忆的做法，每一次新开的话题都很干净、响应很快，同时也利用文件系统帮我们节省了 Token 开销。

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

当我们在某个项目里启动了 Codex，随着我们对话增多，左侧面板上会堆积非常多临时的话题。如果你有一些需要长时间维护或者频繁反复对话的核心线程（比如你专门让它帮你撰写小红书选题的对话，或者调试本地常用 API 的对话），在左侧列表中任由它们被淹没是非常不方便的。

Codex 提供了一个小钉子图标，也就是话题的置顶功能（Pin）。

在列表中，当你的鼠标悬停在某个重要话题上时，点击右侧的小钉子图标，这个话题就会被固定并沉淀到列表最顶端的 Pinned 专属区域中。被置顶的话题不会随着新对话的加入而向下滚动，界面入口如下：

我平时会习惯把一些高频、高频复用的、作为日常主干任务的对话长期钉在最上面，比如我常年置顶的 更新 Grid Prompter 提示词 和 $xhs-assistant 这两项。这样下一次当我需要补充我的小红书大纲或者微调常用 Prompter 规则时，我直接点进最上面这两个钉住的话题就好了，完全不需要重新输入任何背景。

对话框的常用核心设置

当我们点进某个具体的话题后，会话输入框的下方会有几个非常关键的可视化参数调节按钮。它们直接决定了当前会话的权限边界、底层模型、思考强度和运行速度。

一无脑选择 Full access 权限

在对话框左下角，你会看到一个权限控制按钮（默认通常是 Default permissions 或者是 Auto-review）。在日常使用中，我非常推荐大家直接无脑切换为 Full access（完全访问）：

如果选择其他受限权限，Agent 每读一个文件、每跑一个命令都要弹窗问你同不同意，用起来很烦。现在的模型在操作逻辑上已经比较靠谱了，很少会出现乱改文件的情况。直接开 Full access 就行了。

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

在会话框右侧，直接点击模型名字按钮（例如 GPT-5.5），可以对当前话题的运行大脑进行微调：

• 思考强度（Reasoning）：可以直接在 Low、Medium、High、Extra High 几个思考深度等级中进行切换。默认最推荐直接选择最高档的 Extra High，这能让模型拥有最强的推理能力。
• 运行速度（Speed）：点击 Speed 按钮可以进入速度模式切换。建议直接勾选 Fast 模式。开启后，模型生成 Token 的速度会提升 1.5 倍左右。

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

除了上面的核心设置外，Codex 在单个话题里面，还有一个非常符合我们日常习惯的对话队列管理机制。

当 Codex 正在为你读取文件、调试报错，或者正在执行一个耗时较长的命令时，如果你突然有了新想法，你可以直接把新的对话内容发送到会话框里。

这时，新发送的对话并不会打断它正在运行的修改动作。Codex 会默认将新对话存放在一个排队队列中。一旦它上一次任务的最后一个工具调用或者修改执行完毕，它就会自发地在后台开始分析队列中积压的新消息，按部就班地继续工作。

比如，我可以先发一条指令让它去编写核心代码；紧接着，我不用干等它写完，可以直接把第二条要求“顺便帮我把 review 这个代码的测试脚本也写好”发送过去。它就会自己排队去执行。

但是，如果在它正在执行任务的中途，你突然发现它理解错了解法，或者它的修改方向跑偏了，你不想等它把错的写完再排队。你可以在新发送的消息旁边，点击 steer（插队）按钮。

点击 steer 之后，Codex 就会直接插队介入，在当前的工具调用完毕后，立刻开始读取你刚刚插队进来的最新指导消息，并自发纠正它接下来的运行路线。这种灵活的排队和随时插队机制，非常适合我们在长任务执行时，随时对它的思路进行微调和把控。

在下一节中，我们将更进一步，聊聊如何利用 Codex 内置工具，去高效率地在项目里执行任务。

---

内置工具功能

很多人在第一次使用 Agent 的时候，往往分不清模型和工具之间的界限。

这里有一个基本的认知需要先建立：模型负责思考，工具负责执行。

大语言模型本身其实只是一个运行在云端服务器上的、只能进行文本预测和思考的计算文件。它没有眼睛，没有手脚，它自己是不具备读取你本地电脑文件、运行你电脑上的终端，或者是打开浏览器上网的能力的。

而 Agent 的产品机制，就是在这个大语言模型外侧，提供了一个工具箱。大模型在思考时如果发现需要完成某项具体任务，它就会从这个工具箱里挑选出对应的本地工具，通过调用工具来间接控制我们的电脑。

理解大模型的这个工具概念，对日常使用 Agent 很有帮助。

因为大模型在执行任务时，它并不知道我们电脑上究竟有什么、能干什么。它每一次挑选工具，都是在系统底层通过读取工具的 JSON Schema 定义来决定的。

这个过程就像是在系统后台，我们为每一个工具编写了一份说明书。比如对于一个名为 read_file 的读取文件工具，程序在后台为它定义的说明书格式通常是这样的：

{
  "name": "read_file",
  "description": "当你需要查看电脑里某个文件的具体内容时，请调用这个工具。你必须提供一个明确的文件绝对路径。",
  "parameters": {
    "path": "你想查看的本地文件的具体路径，例如：/Users/me/desktop/text.txt"
  }
}

当你在会话框里输入一句话：“帮我看看桌面上的 outline.md 写了什么”。

大模型在后台接收到这句话后，会自发去对比所有可用的工具。它看到上面这个 read_file 的工具描述跟你的指令吻合，于是，大模型在返回的响应中，不会直接回复你的文字，而是会生成一个结构化的工具调用数据：

{
  "tool_to_call": "read_file",
  "arguments": {
    "path": "/Users/linzhihuang/desktop/outline.md"
  }
}

本地的 Agent 程序拦截到模型生成的这串 JSON 数据后，就会在我们电脑的后台，执行真正的读取文件代码，把本地文件的文本内容抓取出来，再作为观察结果重新丢给大模型。大模型读取到文件内容后，才会最终整理出大白话回复给你。

当我们明确知道大模型是怎么通过阅读说明书来挑选工具的，我们在对话里，就可以使用精准的描述去主动触发它们，避免它因为不知道有这个能力而产生幻觉或者直接拒绝。

那么在日常实操中，我们应该如何跟 Codex 对话，去准确触发它背后的这些内置工具箱呢？这一节，我们来系统地盘点一下 Codex 目前已经支持的各种内置工具能力。

外部联网与图片设计工具

这一组工具主要帮助 Agent 突破本地文件的限制，去获取外部世界的信息，甚至直接处理多媒体资产：

• 网页查询与实时信息：Codex 可以直接去搜索互联网，并且支持打开任意网页、读取里面的具体内容。它支持实时去抓取天气、股票、指数或者你指定的文字。我们平时可以直接在输入框里对它说：“帮我查一下最新政策”，或者“打开这个链接看看重点，查一下苹果今天的股价”。它就会自己去调取浏览器和联网模块获取数据，不会局限于老旧的数据。大模型在没有外部资料参考时，往往容易瞎编。

谷歌的 NotebookLM 在解决瞎编问题时有一个做法，就是只允许模型基于你提供给它的文档来回答，而且每一句话都会指出具体来自哪个文档的第几行。这样一来，模型就基本不会胡说八道了。

Codex 里的联网搜索和文件读取也是这个逻辑。当我们在对话里要求它去写一段我们不熟悉的代码，或者去调研一个新话题时，我习惯在提问里明确要求它先去搜索特定网页，或者读取具体的本地文件。

当大模型在回答时有了具体的最新网页和代码作为依据，它给出的结论和写出来的代码，错误就会少很多。让它在回答时带上参考网页的链接或者本地文件的路径，比让它自己去瞎猜要靠谱得多。

• 图片搜索与图片生成：这是 Codex 非常独特的一个功能。其他的 Agent 往往需要我们自己去手动配置外部的生图模型，而 Codex 直接自带了图片生成能力。它使用的是目前能力最强的 GPT Image 2 图片生成模型。如果我们使用的是 ChatGPT 官方的订阅，默认就可以在软件里直接使用。图片生成除了可以用来做日常的一些设计之外，还有一个非常重要的场景，就是在 Vibe Coding（氛围编程）时，用来生成我们需要的各种设计素材。比如在开发网页时，可以直接让它生成 UI 设计稿，或者在制作游戏时，直接让它生成各种游戏美术素材。如果你需要找参考图，也可以直接对它说：“找几张特斯拉 Model Y 的内饰图参考”。如果你需要设计资产，可以直接说：“生成一张小红书的封面”，它就会直接在会话里输出图片。

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

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

• 文件修改与本地终端：这是我们使用最频繁的底层功能。Agent 可以直接读取、写入和精细化修改我们本地的文件。只要我们授权，它也可以直接在我们电脑的终端里执行命令（比如运行编译、执行单元测试、或者检查 Git 状态）。你只需要在输入框里简单交代任务，比如“修这个 Bug”，或者“运行一下测试”，它就会自己去分析日志并完成修改。
• 本地图片查看：它原生支持多模态视觉识别，我们可以直接提供一个本地图片的路径，它就能分析图片内容。比如当我们调试前端样式出错时，直接截图发给它，对它说：“看一下这个截图，按钮位置哪里不对”，它就能自己找到对应的代码并进行调整。

浏览器自动化工具

• 浏览器操作：Codex 内置了 headless 浏览器。同时，如果我们安装了它的 Chrome 浏览器拓展，它就可以直接接管我们的默认浏览器，自动去操作我们已经登录的各种网站（比如 GitHub、小红书、飞书等）。我们可以直接对它发指令：“打开网页看看页面有没有问题”，它就会自动执行截图、点击、输入并分析页面元素的动作。

chrome 浏览器插件的安装和如何自动化调研在文中提到我们后面会具体提到，这里先不过度展开。

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

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

• 任务计划与目标跟踪：在面对复杂的任务时，Agent 会自己在后台维护一个进度清单。你可以直接对它说：“先给我拆一下步骤，然后继续运行”。同时它支持 /goal 命令，比如对它说：“把这个项目修改到能运行起来为止”，它就会自发地在后台进行循环调试，并且记录一个明确的大目标，直到条件达成后才会标记结束。
• 工作区依赖定位：Codex 能够自动去检索和定位你电脑上预装的各种 Node、Python 依赖，以及处理文档、表格、PDF、PPT 等库。比如你把一个 Excel 丢给它，让它“帮我处理这个表格”，它就会自动在本地加载对应的 Python 处理代码去执行修改。
• 工具发现与插件安装建议：当我们要使用一些特殊能力时，它可以自动检索本地环境有没有可用的工具（例如是否连接了 GitHub 或 Supabase）。如果发现某个工具插件没有启用，它也会自己在后台检查是否能够安装，并在界面上向我们发起安装的建议。
• 用户输入请求：在遇到关键分歧点（比如有两个不同的修改方案）时，它不会自作主张，而是会在桌面客户端的界面上弹出一个结构化的多选题 UI 表单，让我们直接在界面上点击来做选择。
• 并行执行与 MCP 资源读取：在分析大型项目时，它会自动在后台并行读取多个文件，或者同时搜索多处内容来加快分析速度。同时在外部连接器的场景下，它也可以直接读取一些连接服务提供的 MCP 资源、配置和上下文信息。
• 自动化任务：Codex 允许我们在桌面端界面中直接为它配置各种定时自动化任务，比如给它设置时间规则：“每周一帮我检查一次项目依赖”。它就会在后台自动按时唤醒并执行。

Skill 触发

除了上面这些内置工具之外，Codex 还支持通过 Skill 来扩展能力。Skill 就是我们自己或者社区写好的操作指南，Codex 在对话中会根据我们说的内容自动判断要不要使用某个 Skill。

触发方式有两种：一种是我们主动用斜杠 /skill-name 来调用，另一种是 Codex 根据我们说的内容自动匹配。比如我装了一个 UI 设计的 Skill，当我跟 Codex 说"帮我设计一个页面"的时候，它就会自动触发这个 Skill，按照里面写好的流程来执行。

关于 Skill 的完整机制和怎么写，我们会在后面的第八章详细展开。

常用名词解释

为了方便非编程背景的同学在看规格参数或者日志时不感觉吃力，我把这一章里出现的几个常见英文词，用最直白的大白话整理在下方，方便大家随时查阅。

• JSON：它就是一种用来表达数据信息的特定文本格式。它使用最简单的大括号和冒号，把信息的属性和具体内容像记账一样一条条写出来。因为它的格式非常工整、没有废话，所以人类和 AI 都能无障碍地读懂。
• Schema：通俗地来解释，它就是一份规则定义。它用来约束某样东西应该长什么样、包含哪些属性、以及这些属性必须是什么类型。
• Metadata：可以理解为元数据，也就是用来描述别的数据的辅助数据。比如，一本书的正文是数据，而它的书名、作者、出版日期和简介就是它的 Metadata。在 Agent 里面，工具的名称和简短功能描述，就是这个工具的 Metadata，大模型就是通过它来快速筛选工具的。
• Headless 浏览器：指没有可见软件界面的、运行在系统后台的浏览器。它虽然在屏幕上不显示任何窗口，但实际上在电脑内存里，它和普通的 Chrome 浏览器一样可以加载网页、点击按钮、或者进行网页排版和截图。
• MCP 资源：全称是 Model Context Protocol（模型上下文协议）里的连接数据。它是指通过通用的桥梁协议（MCP），把外部各种软件服务（如飞书、GitHub、Supabase 等）里保存的数据或配置信息，安全地共享给 Agent 读取。

---

自动化

上一节我们提到了 Codex 内置的浏览器工具和 Computer Use，这一节我们把自动化这个话题展开来讲。

在 Codex 的设置里面，有一个叫做 Computer Use 的页面。打开之后我们可以看到三个选项：

图片缺失：Computer Use 设置页面（本地文件未找到：assets/image-6e9478a1-5a09-417f-b9bc-314ef8ea9a4b.png）

• Any App — 让 Codex 直接控制我们电脑上的任何应用
• Google Chrome — 通过浏览器拓展控制我们的 Chrome 浏览器
• Locked use — 让 Codex 在电脑锁屏的时候也能继续操作

这三个能力对应的是不同层级的自动化方式。下面我一个个来讲。

Computer Use 是兜底方案

Any App 装了之后，Codex 就能像一个人一样去操作我们的电脑桌面。比如让它打开飞书去发消息，让它打开某个剪辑软件去导出视频，这些都能做到。

但是这里有一个很重要的认知：Computer Use 是所有自动化方式里优先级最低的。

为什么？因为它的工作方式是截屏然后用视觉去识别界面元素，再模拟鼠标和键盘去点击。这个过程的精度和速度都不如专用工具。

举个例子，如果我们想让 Codex 帮我们在浏览器里打开一个网页然后填表单，用 Computer Use 的话，它得先截一张屏，找到浏览器图标的位置，点击打开，再截一张屏，找到地址栏，点进去输入网址……每一步都要截图、识别、操作，非常慢。

而如果我们用浏览器的专用工具，它直接通过代码接口去操作 DOM 节点，一步到位，又快又准。

所以我平时的做法是：能用专用工具搞定的，就不要用 Computer Use。 只有在没有对应的专用工具时（比如操作一些本地桌面软件），才会退而求其次用它。

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

这个是我认为 Codex 最近做的最实用的功能之一。

在讲 Chrome 插件之前，我先说一下以前我们做浏览器自动化有多麻烦。

以前如果想让 Agent 去操控浏览器，主流的方式有两种：

一种是 Agent Browser。它的问题在于，它会开一个全新的浏览器实例。这意味着什么呢？我们平时在自己的 Chrome 里登录了小红书、B站、GitHub 这些平台，但 Agent Browser 开的是一个干净的新浏览器，里面什么登录状态都没有。我们得在那个新浏览器里重新登录一遍。而且如果我自己的浏览器也要用这些平台，两边还会互相挤下线。

另一种是 Browser MCP。它的配置比较麻烦，我们需要手动去安装 MCP Server 然后再启动连接，门槛不低。

我之前自己写过一个叫 Local Browser Operator 的工具来解决这个问题。它的思路是参考 Manus 的 My Browser，通过浏览器拓展的方式去接管我们现有的默认浏览器。这样所有的登录状态都是现成的，不需要重复登录。

后来 Codex 自己出了这个 Chrome 插件，原理跟我做的一模一样，而且因为是官方做的，对 Codex 本身的适配度肯定更高，所以我就直接切过来了。

怎么安装

在 Codex 的 Plugins 里面搜索 chrome，安装这个 Chrome 插件。安装完成后，第一次打开的时候它会引导我们去 Chrome 浏览器里装一个对应的浏览器拓展。装完之后，我们在 Chrome 右上角就能看到一个 Codex 的图标，状态显示为已连接。

回到 Computer Use 的设置页面，Google Chrome 那一栏会显示"Connected to browser extension"并且开关是打开的状态。

它解决了什么问题

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

我平时要发视频到三四个平台（小红书、B站这些），这些平台我都在自己的 Chrome 里登录着。用了 Chrome 插件之后，Codex 直接用我现有的身份去操作，不需要我再开一个浏览器重新登录。

做调研也一样。我平时 YouTube、Reddit、GitHub 这些都是登录状态的，Codex 可以直接用我的身份去访问一些需要登录才能看到的内容。

它是怎么工作的

它的原理跟 Manus 的 My Browser 是一样的。必须通过浏览器拓展的方式，才能控制我们现有的这个浏览器。Agent Browser 之所以做不到，就是因为它没有浏览器拓展，所以只能另起一个新的浏览器实例。

在自动化执行的时候，它会在 Chrome 里新建一个标签页分组，然后在这个分组里面去新建标签页、执行操作。这样不会打乱我们正在用的其他标签页。

我平时怎么用

我自己主要用它做这几件事：

• 前端的自动化测试，让它打开本地开发页面去点点看看有没有问题
• 帮我做调研，比如让它去搜索某个技术方案，打开几个网页对比一下
• 自媒体多平台发布，我录完视频之后让它帮我自动分发到多个平台去
• 爬一些需要登录才能看到的数据

触发方式很简单，我们在对话里跟它说的时候，可以在前面加一个斜杠来指定用 Chrome 工具。比如我想让它调研一个话题，我先写调研的需求，然后在前面拼上斜杠命令，它就会自己去打开浏览器进行操作了。

它们之间的优先级

最后总结一下这三种自动化方式的选择逻辑：

如果任务跟浏览器有关（调研、发布、测试网页），优先用 Chrome 插件。它通过代码接口直接操作浏览器 DOM，速度快、准确率高。

如果任务涉及到本地桌面应用（剪辑软件、飞书客户端、Finder），没有其他专用工具能覆盖的，再用 Computer Use。

Locked Use 只是一个辅助开关，让 Computer Use 在锁屏时也能继续工作。

---

Plan 模式

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

Plan 模式就是干这个事的。

怎么开启

在桌面端输入框左下角的加号菜单里，有一个 Plan mode 的开关：

打开之后，我们发送的下一条消息，Codex 不会直接开始写代码或者执行操作。它会先去收集上下文、分析情况，然后给我们出一个执行计划。如果有不明确的地方，它还会先反问我们。

等我们确认计划没问题了，它才开始执行。

什么时候用 Plan 模式

我一般在这几种情况下会打开 Plan 模式：

任务比较复杂的时候。 比如要做一个涉及多个文件的重构，或者要新加一个跨好几个模块的功能。如果直接让它动手，它可能走到一半发现方向不对，已经改了一堆文件了。用 Plan 模式的话，它先把整体方案列出来，我看看有没有问题，确认了再执行。

自己也没想清楚的时候。 有时候我只有一个模糊的想法，不确定具体该怎么实现。这时候我会打开 Plan 模式，把想法描述出来，让 Codex 帮我梳理出具体的实施步骤。相当于让它当一个技术顾问先，确认方案之后再切成执行者。

对现有代码不确定影响范围的时候。 比如我想改某个功能，但不确定会不会影响到其他地方。Plan 模式下它会先去看相关的代码，分析影响范围，告诉我可能涉及哪些文件和模块，然后再问我要不要继续。

跟直接对话的区别

不开 Plan 模式的时候，我们说"帮我加一个用户注册功能"，Codex 就直接开始创建文件、写代码了。

开了 Plan 模式之后，同样的话发过去，它会先出一个方案：打算怎么实现、分几步、每一步做什么、有什么需要确认的。我们看完之后点确认，它才开始动手。

这个区别在小任务上感受不明显，但在大任务上差别很大。大任务如果一开始方向就偏了，做到一半再纠正成本很高。Plan 模式让我们在执行之前就能发现问题。

搭配 PLANS.md 做长时间任务

如果任务特别大（比如要持续好几个小时的那种），官方推荐的做法是在项目里放一个 PLANS.md 文件。这个文件的作用是把整个任务拆成多个里程碑，每个里程碑有明确的验收标准。

大概的结构是这样的：

• 每个里程碑的目标是什么
• 怎么验证这个里程碑做完了（比如跑什么命令、看什么输出）
• 如果验证失败，先修好再往下走
• 做了什么决定、为什么这么决定

Codex 在执行的时候会按照这个文件一步步来，每完成一个里程碑就验证一下，验证通过了才进入下一个。这样即使任务跑了很长时间，它也不会跑偏，因为有明确的检查点。

官方提到有人用这种方式让 Codex 从一条消息开始，连续工作了超过七个小时完成一个完整功能。

搭配 Goal 模式使用

Plan 模式和下一节要讲的 Goal 模式可以搭配在一起用。

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

这样的好处是：Plan 确保了方向不会偏，Goal 确保了它会一直做到达标为止。两个组合起来，就是"先想清楚再一口气做完"。

Plan 模式的局限

用下来之后我发现 Plan 模式有几个需要注意的问题：

方案修改是全量重写的。 如果我们让 Codex 出了一个计划，然后想改其中某一步，它可能会把整个方案重新生成一遍，之前写好的其他步骤也可能被改动或者缩短。它目前不支持只改局部保留其他部分不变的增量编辑。所以如果你想精细地打磨一个方案，可能需要反复确认它有没有把之前定好的东西改掉了。

有时候它不够深入就出方案了。 Plan 模式的理想状态是：先去看代码、了解现有架构、发现约束条件，然后再出方案。但实际使用中，它有时候看了几个文件就开始出计划了，可能会漏掉一些已有的接口或者测试。大型代码库里这个问题比较明显。如果你发现它的方案忽略了某些东西，可以直接告诉它"你再看看 XXX 文件"。

Plan 模式的约束是提示词层面的，不是物理隔离。 也就是说，Plan 模式下 Codex 理论上"不应该"改文件，但这个限制不是靠沙盒强制的，是靠提示词告诉它不要改。极端情况下它可能还是会动文件。所以如果任务风险比较高，建议在开 Plan 模式之前先切一个 git 分支，或者 stash 一下当前改动。

方案不会自动保存到本地文件。 这个是我觉得目前最大的问题。Plan 模式生成的方案只存在于当前对话的上下文里，它不会自动写一个 Markdown 文件到本地。这意味着什么呢？如果对话轮次多了触发了上下文压缩，方案的细节可能就被压缩掉了。或者我们新开一个话题想要执行之前的方案，那个方案已经不在了。

我自己的解决办法是：Plan 模式出完方案之后，手动让 Codex 把方案写到一个本地文件里（比如 PLAN.md）。关掉 Plan 模式之后再让它执行，执行的时候让它参考这个文件。这样即使上下文被压缩了，方案还是在文件里完整保留着。

Claude Code 在这方面做得好一点，它会自动把方案存到 ~/.claude/plans/ 目录下。Codex 社区也有很多人在要求加这个功能，但目前还没实现。

跟 Goal 模式的兼容还在完善中。 之前有用户反馈同时开 Plan 和 Goal 的时候，Codex 可能跳过规划直接执行。官方说这两个功能的交互还在优化中。我自己的做法是先用 Plan 出方案，确认之后关掉 Plan 模式，再开 Goal 让它执行。不要同时开两个。

我自己的感受

我平时对于简单的任务不会开 Plan 模式，因为它多了一轮确认的过程，小任务直接做就行了。但如果任务涉及的范围比较大，或者我自己还没想清楚具体怎么做，我就会打开它。

还有一个用法：如果你不确定自己的需求描述够不够清楚，可以打开 Plan 模式让 Codex 先出方案。看它理解的跟你想的是不是一回事。如果不一样，说明你的描述有歧义，可以在这一步就纠正过来，而不是等它做完了才发现不对。

---

目标设置（/goal 命令）

正常情况下，我们给 Codex 发一条消息，它执行完就停下来等我们说下一步。但如果我们有一个很大的任务，比如从零搭建一个完整项目、做一次框架迁移、或者排查一个反复出现的 Bug，我们其实希望它自己一直干到做完为止，不需要我们一直盯着。

/goal 命令就是干这个事的。它是在 Codex 0.128.0 版本之后加入的功能。

怎么开启

在桌面端里，我们点击输入框左下角的加号按钮，会弹出一个菜单，里面有一个 Pursue goal 的开关：

把这个开关打开之后，我们发送的下一条消息就会被当作一个 Goal 来执行。Codex 会一直朝着这个目标推进，直到完成或者遇到阻塞。

如果开关没有出现，可能需要在配置文件里先启用这个功能。在 config.toml 的 features 里加上 goals = true 就行。

跟普通对话的区别

我用一个最简单的方式来解释。

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

Goal 的流程是这样的：Codex 做完一步 → 自己检查有没有达到目标 → 没达到就继续做下一步 → 再检查 → 直到达成目标、或者被我暂停、或者 Token 预算用完。

区别就在于，普通对话里 Codex 做完一步就停了，即使任务还没完成它也觉得"我这轮做完了"。但 Goal 模式下，它每一轮结束都会回去看一眼目标条件有没有满足，没满足就自动继续。

这个不是靠提示词做的，是在程序层面加了一个持续检查的机制。即使中途上下文被压缩了，目标信息也不会丢，它始终知道自己还没完成。

Goal 的运行状态

Goal 在执行过程中会有几种状态：

• 正在执行 — 它还在朝目标推进
• 暂停 — 被我们手动停了，比如我们想纠正一下方向
• 完成 — 达成目标，自己标记结束
• 预算到了 — Token 用量到达上限，优雅收尾
• 阻塞 — 遇到了它自己搞不定的问题，等我们来处理

这里有一个点我觉得设计得不错：当 Token 预算快到的时候，它不会突然断掉，而是进入一个收尾状态。它会总结当前做到哪了、还剩什么没做、下一步该从哪里继续。之后我们可以在新的会话里继续这个目标。

怎么写一个好的 Goal

这个是最关键的部分。我自己试下来，Goal 写得越详细，长时间执行的效果就越好。写得太模糊，它可能做了两三步就觉得差不多了。

官方文档里总结了写 Goal 需要包含的几个要素，我把它们翻译成大白话：

1. 目标结果 — 告诉它最终要达成什么。

2. 验证方式 — 它怎么判断做完了。比如跑测试全通过、基准测试达标、截图对比一致。

3. 不能动的东西 — 在朝目标推进的过程中，哪些是不允许改的。比如不能改数据库结构、不能改公开的 API 接口。

4. 允许使用的范围 — 它可以动哪些文件、用哪些工具。

5. 每轮之间怎么决策 — 告诉它做完一步之后，怎么决定下一步试什么。

6. 什么时候该停 — 如果遇到它自己搞不定的阻塞，应该停下来告诉我们哪里卡住了，而不是瞎试。

我举一个例子来对比。

弱 Goal：

/goal 优化性能

这个写了跟没写一样。它不知道优化到什么程度算完、用什么来衡量、哪些东西不能动。

强 Goal：

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

这个就很清楚了。Codex 知道目标是什么（p95 < 120ms）、怎么验证（跑 benchmark）、不能破坏什么（正确性测试）、能动什么范围（checkout service）、每一轮怎么记录进展、什么情况该停。

如果你自己不确定怎么写，也可以先把需求大概描述出来，让 Codex 帮你起草 Goal。比如跟它说："帮我把这段需求整理成一个 /goal 格式，要有明确的评估标准和停止条件。"它会帮你把模糊的描述转成一个结构化的 Goal。

适合用 Goal 的场景

从我自己的使用和官方的推荐来看，这些场景用 Goal 效果最好：

• 代码迁移 — 从旧框架迁到新框架，目标是 UI 视觉完全一致，用 Playwright 截图对比验证
• 从零建项目 — 先写一个 plan.md，然后让它按计划逐步实现，为每个阶段创建测试
• 性能调优 — 设定一个具体的指标目标（比如响应时间低于 150ms），让它不断尝试直到达标
• 复杂 Bug 排查 — 让它一直查到根因定位出来，或者能稳定复现为止
• Prompt 优化 — 如果你有一套 eval 测试集，让它不断调整 Prompt、跑 eval、看分数、再优化，直到分数达标
• 大型重构 — 设定目标为所有测试通过 + 代码符合新规范

什么时候不该用 Goal

不是所有任务都适合 Goal。这些情况直接普通对话就行：

• 改一行代码
• 问一个问题
• 小 Bug 修复
• 简单的 Code Review
• 任何几分钟能搞定的事

Goal 适合的是那种"做完要花一两个小时甚至更久"的任务。如果任务本身三五步就能完成，开 Goal 反而多此一举。

我自己的用法

我一般用 /goal 的时候会搭配 caffeinate 命令。因为 Goal 任务通常执行时间很长，可能我人不在电脑前，或者睡觉之前给它布置任务。

caffeinate -dimsu

这样即使 MacBook 合盖了也不会休眠，Codex 在后台一直跑着。只要网络稳定，第二天起来就能看到结果。

还有就是，如果目标执行到一半状态变得模糊了（比如它的进度报告越来越笼统），不要去加更多的一次性指令，而是直接收紧目标本身。告诉它现在最重要的下一步是什么、用什么命令验证、什么情况该暂停。把目标写得更具体，比加更多对话内容有效得多。

---

侧边栏功能（/side 命令）

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

比如说它正在帮我写一个功能，我突然想问一下"这个库的某个 API 参数是什么意思"。如果我直接在主对话里问了，这个问答就会写进上下文。后续它再继续做任务的时候，上下文里就多了一段跟任务无关的内容。聊得多了，上下文就被这些杂七杂八的问题给污染了。

/side 就是用来解决这个问题的。

怎么用

在输入框里打 /side，发送之后它会在右侧新开一个对话窗口：

这个右侧的对话有两个特点：

第一，它能看到左侧主对话之前的所有上下文信息。也就是说它知道我们之前在做什么、代码写到哪了、当前项目的情况。

第二，我们在右侧说的话不会写进左侧的上下文。右侧是一个独立的分支，聊完了不影响主对话的干净程度。

Claude Code 里的类似功能

如果大家有用 Claude Code 的话，里面有一个类似的命令叫 /btw。功能差不多，就是在主对话进行中临时插一个不相关的问题进去，Claude Code 会把这个问题单独处理，不让它影响主任务的上下文走向。

两者的区别在于，Codex 的 /side 是在右侧开了一个完整的独立对话窗口，视觉上更清晰；Claude Code 的 /btw 还是在同一个终端里，只是在逻辑上做了隔离。

什么时候用

我自己日常用 /side 的场景主要有这几个：

临时问问题 — 做任务做到一半，想快速确认一个 API 用法、某个概念的含义，或者问一下当前方案有没有明显的风险。问完就回到主对话继续做任务，不会污染主线上下文。

对比方案 — 比如 Codex 在左侧帮我写了一个报告，我想在右侧快速问一下"这个报告里的第三个结论有没有问题"。问的结果我自己看看就行，不需要让主对话知道。

并行执行 — 这个是一个进阶用法。如果 Codex 已经在左侧探索了足够多的代码，有了比较丰富的上下文，我们可以用 /side 在右侧同时执行另一部分任务。左侧做一件事，右侧做一件事，两边并行。

右侧的模型是独立选的

一个容易忽略的点：右侧侧边栏的模型可以跟左侧不一样。比如左侧主任务我用 GPT-5.5 跑着，右侧问个小问题我可以切一个便宜点的模型。这样既不浪费额度，又不影响主任务的执行质量。

并行执行的具体用法

这个是 /side 的一个进阶用法。如果 Codex 在左侧已经探索了比较多的代码，有了丰富的上下文，我们可以用 /side 在右侧同时执行另一个任务。

比如一个实际场景：左侧正在帮我重构某个模块的代码，我突然想起这个模块对应的测试文件也需要更新。我不想打断左侧的重构流程，就在右侧开一个 /side，跟它说"顺便帮我更新一下这个模块的测试"。因为右侧继承了左侧的上下文，它知道我改了哪些代码，可以直接针对性地更新测试。

两边的改动互不影响。左侧改完了是左侧的，右侧改完了是右侧的。

它的局限

/side 有几个需要注意的地方：

• 它是临时性的。具体多久会过期我没有找到一个确切的数字，但如果几个小时不用它，再去发消息可能就不行了。所以不要指望把它当成一个长期话题来维护。
• 它不会在左侧新开一个话题。侧边栏关掉之后，里面聊的内容不会留在任何地方。如果右侧产生了重要的结论，记得让它写到文件里。
• 在一个 /side 里面不能再开另一个 /side，只能一层。
• 右侧的对话比较适合轻量操作。如果右侧的任务也很重（比如需要读很多文件、跑很多命令），可能会跟左侧互相抢资源，两边都变慢。

所以 /side 最适合的就是短平快的临时对话：问个问题、确认个方向、做个对比、顺便更新一下小文件，然后回到主线继续。

---

Rewind 对话回溯

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

前面讲上下文的时候说过，对话越长、无关信息越多，Agent 的执行质量越差。日常用下来经常会遇到这种情况：一个话题聊到后面，中间穿插了一堆跑偏的尝试、问错的问题、走不通的方案。这些东西全堆在上下文里，后面再让它做事，它的注意力就被这些噪音分散了。

rewind 就是把对话退回到之前的某一条消息，把那条之后的所有问答全部丢掉，相当于从那个点重新分叉出一条新的对话。

怎么操作

在桌面端里，把鼠标移到历史里之前的某一条消息上，会出现一个回到这一步的入口。点了之后，这条消息之后的所有内容就被丢弃了，对话回到那个时间点的状态。（如果你用的是命令行，连续按两下 Esc 也是同样的效果。）

退回去之后，我们可以在那个干净的基础上重新发消息，继续后面的任务。

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

这个一定要记住，不然很容易踩坑。

rewind 删掉的是上下文，不是文件改动。你把对话退回到三轮之前，但这三轮里 Agent 改过的文件还是改过的状态，它们不会跟着对话一起回退。

这就会产生一个对不上的情况：对话已经退回去了，里面没有改过文件的记忆，但磁盘上的文件已经是新的样子了。Agent 接着往下做的时候，它脑子里以为文件是旧的，实际文件是新的，判断就容易出错。

所以涉及代码改动的时候，我的习惯是 rewind 之前先 git commit 一次。这样万一对话和文件状态对不上，我可以直接用 git 把代码也退回去，让两边对齐。或者 rewind 之后先让它重新读一遍当前文件，把磁盘上的真实状态补回上下文里再继续。

想把代码也退回去，目前还是 git 最稳。Codex 之前有过一个 /undo 命令，会连代码一起退，但因为问题比较多，官方把它下掉了。现在的回退就是只管对话这一层。

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

这几个东西容易混，我用一句话区分一下：

• 新开话题 — 完全从零开始，前面聊的它一概不知道。适合下一个任务跟之前彻底无关的时候。
• rewind — 保留前面有用的部分，只砍掉后面跑偏或者无关的部分。适合前面的上下文还想用、但后面乱了的时候。
• /side — 不动主线，临时开个侧栏问完就回来。适合主线没问题、只是想插一个不相关的小问题。
• 压缩 — 系统在上下文快满的时候自动把前面浓缩成摘要，是被动触发的，而且不可逆。

rewind 和新开话题的差别是这里的关键。如果你前面让 Agent 探索了半天代码、好不容易建立起对项目的理解，这部分上下文很值钱。这时候直接新开话题，等于把这些探索全扔了，下一个任务它又得重新探索一遍。用 rewind 的话，你可以只退到探索刚做完、还没开始跑偏的那个点，把后面的废话砍掉，前面的理解保留下来继续用。

我平时什么时候用

主要有几种情况。

它理解错了方向，越改越偏。与其继续在错的基础上一句句纠正，不如直接退回到它跑偏之前那条消息，把需求重新讲清楚再发一次。比纠正要干净得多，省得上下文里留着一堆错误的尝试。

一个长对话里，前面的上下文还想接着用，但中间我做了一些跟下一步无关的事。我会把后面这段无关的内容退掉，在保留前面有用信息的基础上接着做下一个任务。

试探性地问了一连串问题，把上下文搞得很杂。问完拿到答案了，就退回到提问之前，让主线保持干净。

用之前的提醒

退掉的内容是找不回来的。fork 之后，那条被丢弃的分支就没了。所以如果后面那段对话里有重要的结论（比如它分析出来的某个问题原因、定好的某个方案），rewind 之前先让它写到一个本地文件里，再退。

还有就是前面说的代码状态问题，涉及文件改动的时候，养成 rewind 前先提交一次 git 的习惯。

顺便提一下 Claude Code，它的 /rewind 做得更完整一些，可以选择只退对话、只退代码、或者两个一起退，背后有一套 checkpoint 机制。Codex 目前只有对话这一层的回退，代码还得我们自己用 git 管。

---

记忆功能

前面讲上下文的时候我们提到过，话题和话题之间的上下文是独立的。也就是说我在 A 话题里跟 Codex 说过的事情，新开一个 B 话题它是完全不知道的。

那如果有一些信息是我们希望它跨话题都能记住的呢？比如我平时用的技术栈、我项目的一些约定、或者某个反复出现的偏好设置。

Codex 的记忆功能就是做这件事的。

在哪里开启

在设置里的 Personalization 页面，下面有一块叫 Memory (experimental)：

这里有几个开关：

• Enable memories — 开启之后，Codex 会从我们的对话中自动提取有用的信息，生成记忆文件，在之后的新对话里自动带上。
• Chronicle research preview — 这个更进一步，它会结合我们屏幕上的内容来增强记忆。比如我们在看某个文档或者写某段代码，它会把这些上下文也纳入记忆。
• Skip tool-assisted chats — 如果开了这个，那些用了 MCP 工具或者联网搜索的对话就不会被拿来生成记忆。
• Reset memories — 一键清空所有记忆。

它是怎么工作的

记忆功能的机制大概是这样的：

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

生成的记忆是 Markdown 文件的形式。之后我们新开话题的时候，Codex 会自动把这些记忆文件的内容注入到上下文里，这样它就"记住"了之前对话里的一些信息。

这个过程有几个特点：

• 不是实时的，它不会在每次对话结束后立刻生成，而是等对话空闲足够久
• 会自动过滤敏感信息（API Key 这些不会被写进记忆）
• 如果当前的 API 用量快到上限了，记忆生成也会跳过，不会抢占额度
• 记忆文件会定期合并整理，不会无限膨胀

我为什么不太用这个功能

说实话，我自己是把记忆功能关掉的。

原因跟我之前在视频里说过的一样：目前任何 Agent 的自动记忆功能，写进去的东西大多数都是没用的。

举个例子，我在某个项目里跟它说"用浅蓝色的配色"，它可能就把这个写到记忆里了，变成了"用户偏好浅蓝色"。但其实这只是那一个项目的需求，不是我个人的偏好。时间长了，记忆里堆了一堆这种断章取义的信息，反而会干扰后续的对话质量。

如果大家有用过 Manus 里面的 Knowledge 功能，就知道那个推荐出来的内容大多数也是没什么用的。

我自己的替代方案

比起让 AI 自动去记，我觉得用文件的形式手动管理是更靠谱的。

我的做法是：如果有一些想要跨话题共享的信息（比如我的人设信息、项目约定、写作风格规范），我就写成一个 Markdown 文件放在项目目录里。下次新开话题的时候，直接 @ 那个文件给它看，它就立刻知道了。

这样做的好处是：

• 我清楚地知道它"记住"了什么，因为是我自己写的
• 不会有莫名其妙的错误记忆污染上下文
• 可以随时修改和更新
• 不同项目可以有不同的记忆文件，不会串

代码仓库本身其实就是一个天然的记忆。Codex 进到一个项目目录里，它去读代码就能知道这个项目是做什么的、有什么规范、用了什么技术栈。这些信息比任何自动记忆都准确。

什么人适合开启记忆

如果你的使用场景比较固定，比如你一直在用 Codex 做同一类事情（比如每天写同一个项目的代码），而且你不太想每次都重复交代背景信息，那开启记忆功能可以省一些重复说明的时间。

但如果你跟我一样，用 Codex 做的事情比较杂（写代码、做调研、写文章、发视频），那我建议还是关掉，自己用文件来管理比较省心。

---

图片生成与 UI 设计

前面在宠物功能里我们已经看到了 Codex 的生图能力。这一节我们来讲讲它在日常开发中更实用的场景：用 Codex 做 UI 设计，以及怎么把设计稿还原成代码。

Codex 自带的生图能力

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

这个能力放在 Codex 里面之后，跟在 ChatGPT 网页端用是完全不同的体验。因为 Codex 能读写文件、能运行代码、能预览网页，所以它可以把生图和编程串在一起用。

用 AI 生图来做 UI 设计

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

为什么会这样？因为如果我们直接让 AI 写前端代码，它的审美上限就是它训练数据里见过的那些代码风格。但如果我们先让它生成一张设计图，它在图片生成的维度上见过太多优秀的设计了，产出的视觉效果会精致很多。

所以我现在做新页面的流程变成了：先用生图做设计稿，确认满意后再让它还原成代码。

怎么保持设计一致性

做设计稿有一个核心问题：我已经有一个系统了，有自己的侧边栏、配色、图标风格，我怎么确保 AI 每次生成的新页面跟现有系统风格一致？

我试了两种方式：

方式一：用提示词约束

我写了一段统一的提示词，描述侧边栏长什么样、用什么配色。结果发现不行，同一段提示词生成两次，出来的界面就不一样了。通过提示词去限制这条路走不通。

方式二：给参考图

这个方式效果很好。我截一张系统里已有页面的图片，作为参考图传给它。然后告诉它："保持侧边栏与参考图完全一致，帮我设计一个新的 XXX 页面。"

结果左侧栏完全不变，配色、图标、按钮跟参考图一模一样，只有右侧的内容区是重新设计的。我连续生了五次，每次左侧栏都是稳定的。

不过这里有一个取舍：如果参考图里包含了太多已有的设计元素，会限制它的创造力。它会倾向于"跟参考图差不多"的设计，不太敢大改。

我后来的做法是：参考图里只保留需要固定的部分（比如侧边栏），把右侧内容区清空。 这样它知道侧边栏不能动，但右侧可以自由发挥。这样出来的设计感就好很多了——排版紧致、配色舒服、风格多样。

怎么写生图的提示词

我测试了五种不同角度的提示词写法，效果差异很大：

1. 叙事视角 — 把用户的使用旅程写到提示词里。比如"用户打开这个页面后，先看到一个概览数据，然后往下滚看到详情列表"。这种写法出来的设计在信息层级上会比较合理。

2. 信息清单 — 直接告诉它页面上需要展示哪些数据，但不指定排版。比如"需要展示原始视频、播放量、互动数据、标签"，让它自己想怎么排。

3. 类比参考 — 告诉它"做成 Notion 风格"或者"参考 Linear 的设计"，它就会按那个产品的视觉语言来设计。

4. 用户目标 — 告诉它"用户看完这个页面后需要得出什么结论"，让它自己决定展示什么信息、怎么组织。

5. 情绪描述 — 描述页面给人的整体感觉。这个方向效果最差，容易出海报或者宣传页风格，做不出功能性的页面。

前四种效果都不错。而且这些提示词不需要我们自己手写，AI 会分析我们要做的页面方向，自己选择合适的角度去生成提示词。

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

npx skills add oil-oil/draw-ui

安装之后我们只要跟 Codex 说"帮我设计一个 XXX 页面"，它就会自动帮我们做这些事：查看代码仓库里的设计资源、让我们提供参考图、选择合适的提示词策略、生成设计稿。如果需要还原成代码，它也会自动处理素材分离和骨架搭建。

怎么把设计稿还原成代码

设计稿生成之后，下一步就是把它变成真实的代码。这个也是很多人关心的问题。

AI 还原设计稿的原理没什么玄学的：通过多模态视觉识别去看图片里的布局、配色、元素大小，然后转成 HTML/CSS 代码。大部分元素它都能 1:1 复刻，但有一些东西它做不到：

• Logo（这是品牌标识，代码画不出来）
• 复杂插画（比如 Hero 区域的装饰图）
• 第三方厂商的图标（比如合作伙伴的 Logo 墙）
• 微妙的纹理质感
• 复杂的 SVG 曲线

这些东西本质上是视觉素材，不是能用代码生成的。

我的还原流程

针对这个问题，我优化了我的 Skill，整个还原流程是这样的：

第一步：拿到原始设计稿，记录画布尺寸。

第二步：让 AI 分析图片，识别哪些元素用代码能实现、哪些不能。 比如品牌符号、插画、质感装饰这些归类为"素材"，布局、文字、按钮、表格这些归类为"代码可实现"。

第三步：先把代码能做的部分搭出来。 用 HTML/CSS 还原整体骨架，把不能实现的地方先留空。

第四步：处理那些代码做不到的素材。 这里是关键——我让 AI 用局部裁图的方式，从原始设计稿里把这些素材元素（Logo、插画、图标）单独裁出来，保存为独立的图片文件。

第五步：把裁出来的素材图片嵌入到 HTML 里对应的位置。 这样 Logo 用的是真实裁出来的图片，插画也是真实的图片，而不是让 AI 用代码去硬画。

最终还原度能到 90% 左右。大致的布局、配色、元素位置都是一致的，Logo 和插画也因为是直接从设计稿里裁出来的，所以跟原图一模一样。剩下的 10% 可以手动微调代码来修正。

整体工作流总结

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

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

整个过程大概十几分钟到半小时，取决于页面复杂度。对于不会用 Figma 的工程师来说，这个流程比以前方便太多了。

局限

• 文字渲染有时候不准确，尤其是中文可能出乱码
• 复杂交互动效做不到，只能还原静态视觉
• 每次生图都要消耗额度，大量迭代会比较费
• 还原的代码质量取决于模型的能力，有时候 CSS 写法不太优雅，需要后续整理
• 如果我们的系统本身就很素，给它的参考图信息太少，它的设计发挥空间也会受限

---

实用配置

前面几节讲的是 Codex 的各种功能，这一节我们来讲一些日常使用中比较实用的配置项。这些配置大部分在桌面端的 Settings 里面就能改，不需要去手动编辑文件。

防止电脑休眠

这个在前面 Goal 命令那节已经提过了，但因为它太常用了，这里再单独说一下。

在 Settings 的 General 里面，有一个 Prevent sleep while running 的开关：

打开之后，只要 Codex 还有任务在跑，电脑就不会进入休眠。

这个对长时间任务特别重要。如果你给 Codex 设了一个 Goal 让它跑几个小时，结果电脑十分钟后就睡了，那任务就中断了。打开这个开关就不用担心了。

如果你是用远程连接的方式（比如在另一台 Mac 上远程控制），在被控那台电脑的 Settings > Connections 里也有一个 Keep this Mac awake 的选项，同样的作用。

详情展示级别

在 Settings > General 里有一个 Detail level 的选项。

默认是 Coding 模式，会展示 Codex 正在执行的具体命令、读了什么文件、运行了什么脚本。对于工程师来说这些信息很有用，可以看到它在干什么。

但如果你不是程序员，或者你只是用 Codex 来做一些日常工作（调研、写文档、整理文件），看到一堆代码输出可能会比较困惑。这时候切到 Default 模式，界面会清爽很多，它只展示最终结果，不展示过程中的代码细节。

个性化设置

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

回复风格 — 有 Friendly（友好）和 Pragmatic（精简）两种。我自己选的是 Friendly，因为 Codex 默认说话确实没什么人味，选友好的话它的回复会稍微带点温度。

自定义指令 — 这里可以写一段文字，告诉 Codex 它回复你的时候应该遵循什么规则。比如我写的是让它回复必须通俗简略、自然清晰、不要使用任何翻译腔的句式。

这个自定义指令会在每一次对话里都生效，不需要每次都重复交代。相当于一个全局的行为约束。

MCP 服务配置

MCP 全称是 Model Context Protocol，就是让 Codex 能够连接外部工具和服务的一个协议。

在 Settings > MCP servers 里面可以配置：

比如我自己配了 Supabase（数据库）、LangSmith（调试）、MongoDB 这些。配完之后 Codex 就能直接读取和操作这些外部服务的数据，不需要我们手动去复制粘贴。

还有一些 MCP 服务是通过 Plugin 自动带进来的。比如我们装了 GitHub 的 Plugin，它底下就自动配好了 GitHub 相关的 MCP 连接。

MCP 的配置最终写在 config.toml 的 [mcp_servers] 部分。如果我们在桌面端 UI 里配置的话，它会自动帮我们写好，不需要手动编辑。

Hook 机制

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

比如说：

• 每次 Codex 启动一个新会话的时候，自动跑一个脚本
• 每次 Codex 要执行某个命令之前，先做一个检查
• 每次上下文被压缩之后，自动记录一些信息
• 每次子 Agent 启动的时候，注入一些额外指令

Hook 的配置可以写在 config.toml 里面，也可以放在项目目录的 .codex/hooks.json 里。Codex 在执行 Hook 之前会要求我们确认和信任，新增或者修改了 Hook 之后需要重新信任才能运行。

对于大多数人来说，Hook 不是一个必须配置的东西。但如果你有一些固定的工作流想要自动化（比如每次开新话题就自动加载某个文件、每次执行完任务就自动跑一遍测试），Hook 就很有用了。

工作模式

在 Settings > General 里面有一个 Work mode 的选项：

可以选择 For coding（写代码）或者 For everyday work（日常工作）。

如果选了日常工作模式，Codex 在执行任务的时候就会隐藏掉大部分代码相关的输出，展示出来的信息更加清爽易懂。适合那些不写代码但想用 Codex 来做日常事务的人。

配置文件的层级

Codex 的配置有一个优先级的概念。从高到低是这样的：

1. 命令行参数（临时覆盖）
2. Profile 配置（场景预设）
3. 项目目录里的 .codex/config.toml（项目级别）
4. 用户目录的 ~/.codex/config.toml（全局默认）
5. 系统配置（如果有的话）
6. 内置默认值

对于大部分人来说只需要关心第 4 个：用户级别的全局配置。在桌面端 Settings 里改的东西基本都是写到这里的。

如果某个项目有特殊需求（比如某个项目要用不同的模型或者不同的权限），可以在项目目录里放一个 .codex/config.toml 来覆盖全局配置。但要注意，项目级别的配置只有在我们把项目标记为"信任"之后才会生效。

Automation（自动化任务）

在桌面端左侧的 Automations，我们可以在这里配置定时执行的任务：

比如设置"每天早上 10 点去调研小红书上有什么热门话题"，或者"每周一检查一次项目依赖有没有更新"。

创建的时候注意几个点：

• 右侧可以选择执行的模型，它默认不是我们正常对话时用的模型。如果不注意可能会用一个没那么强的模型去跑任务，效果就差了。
• 可以选择运行在哪个位置：如果是代码仓库可以用 Worktree，如果只是普通目录就选 Local。
• 右上角有 Use template 按钮，官方提供了一些模板比如 Bug 排查、Git 信息总结、写日报这些。

我自己平时不太用 Automation，因为我每天都在用 Codex，大部分任务自己手动去执行了。但如果有些任务是固定频率、比如日报这一类的，用这个还是挺方便的。

---

子 Agent 功能

前面讲上下文工程的时候，我们提到过一个优化思路：用子 Agent 隔离上下文，让子 Agent 去做那些需要读大量文件的脏活，最终只把关键结果返回给主 Agent。这一节我们来具体讲讲 Codex 的子 Agent 功能。

什么是子 Agent

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

举个例子：我让 Codex 帮我做一次代码审查。如果它自己一个人干，它需要把所有文件都读进自己的上下文里，很快就满了。但如果用子 Agent，它可以同时派出三个子 Agent：一个专门看安全风险，一个专门看测试覆盖，一个专门看代码可维护性。三个子 Agent 各自读各自需要的文件，最后把结论交回来，主 Agent 汇总一下就行了。

Codex 不会自动派发子 Agent

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

比如我们可以这样说：

• "用三个子 Agent 并行审查这段代码"
• "派两个 Agent，一个去看前端代码，一个去看后端代码"
• "并行探索一下这个项目的几个模块"

子 Agent 的开销

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

所以不是什么任务都适合用子 Agent。简单任务直接做就行了，只有在任务本身就可以拆分成几块并行干的时候，用子 Agent 才有意义。

自定义子 Agent

Codex 支持我们预先定义好不同角色的子 Agent。比如一个专门做代码探索的、一个专门做 Code Review 的、一个专门查文档的。

定义方式是在项目目录或者用户目录下放一个 TOML 文件：

• 项目级别：.codex/agents/xxx.toml
• 用户级别：~/.codex/agents/xxx.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.
"""

这里面几个关键的字段：

• name — 名字，Codex 在派发的时候会用到
• description — 什么时候应该用这个 Agent
• model — 可以给子 Agent 指定一个不同的模型（比如用便宜的 gpt-5.4-mini 来做探索）
• model_reasoning_effort — 思考深度，探索类任务用 low 或 medium 就够了
• sandbox_mode — 权限控制，比如只读模式防止子 Agent 乱改文件
• developer_instructions — 它的行为准则

不过实际上我们不需要自己手写这个 TOML 文件。直接跟 Codex 说"帮我创建一个只读的代码审查子 Agent，用 gpt-5.4-mini，重点看安全和测试"，它就会自己把这个文件写好放到对应的目录里。大多数配置类的操作都可以让 Codex 自己来改，不需要我们去手动编辑配置文件。

子 Agent 的模型选择

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

这样做的好处是模型能力本身不打折扣，只是思考深度浅一些，速度会快很多。对于探索代码、扫描文件这种不需要深度推理的活，低思考程度就够了。而如果用一个能力本身就弱的模型（比如 mini 系列），有时候它理解任务都会出偏差，返回的结果质量不稳定。

子 Agent 运行时的界面展示

在 Codex 桌面端里，子 Agent 跑的时候我们能看到它的状态。主对话界面上会显示子 Agent 的执行进度，点进去可以看详细输出。

如果某个子 Agent 执行失败了（比如读文件报错、命令跑不通），主 Agent 会收到失败通知，它通常自己判断是重试还是跳过。如果问题比较严重（权限不够、文件不存在），它会停下来告诉我们哪里卡住了。

我们不需要手动去管理子 Agent 的生命周期，主 Agent 会自己协调。但如果发现某个子 Agent 卡了很久没动静，直接在主对话里说"停掉那个子 Agent"或者"重新跑一下"就行。

并行限制

在 config.toml 里可以设置子 Agent 的并行限制：

[agents]
max_threads = 6
max_depth = 1

• max_threads — 最多同时跑几个子 Agent，默认是 6
• max_depth — 子 Agent 能不能再派子 Agent，默认是 1（只能派一层，不能嵌套）

一般来说默认值就够用了，不需要改。

我自己的用法

我平时用子 Agent 的场景不算多。大部分日常任务一个 Agent 就能搞定。但有两种情况我会用：

第一种是项目比较大，刚开始接触代码库的时候。我会让 Codex 派几个子 Agent 分别去看不同的模块，各自给我一个简短的总结。这样我能快速了解整个项目的结构，而不需要主 Agent 把所有文件都读进自己的上下文。

第二种是做 Code Review 的时候。我会让它派三个不同视角的子 Agent（安全、测试覆盖、代码风格），各自出一份报告，最后汇总。比一个 Agent 从头到尾看完所有代码要全面。

还有就是我自己写的一个 Explore Skill，它的原理就是子 Agent。安装方式：

git clone https://github.com/oil-oil/codex-explore-skill.git ~/.codex/skills/explore

装完之后，我们在对话开头跟 Codex 说"用 explore 先看看这个代码库"，它就会派出子 Agent 去做代码探索。子 Agent 在自己的上下文里读大量文件，最终只返回一个关键文件表和简要总结给主 Agent。这样主 Agent 的上下文从一开始就保持精简，不会被几十个文件的内容撑满。

这个 Skill 的逻辑参考了 Claude Code 里的 Explore 子 Agent 机制。在 Claude Code 里，它每次要查看比较多代码的时候，会自动派一个探索用的子 Agent 先去定位，然后把关键路径交给主 Agent。Codex 本身很少主动去这样做，所以我把这个行为写成了 Skill，需要的时候主动触发。

---

Skill 的由来与原理

Skill 到底是什么

很多人第一次听到 Skill 这个词，以为它是某种很高深的东西。其实它就是一份写给 AI 看的操作指南，用文件的方式保存在本地。

更直白地说：Skill 就是一个文件夹。里面放了一个 Markdown 文件（SKILL.md），可能还有一些脚本和参考资料。AI Agent 在需要的时候会自己去读这个文件，然后按照里面写的步骤执行。

Skill 本身不是一个新发明。在 Skill 这个概念出现之前，我们已经在用各种方式把工作流写成文件让 AI 读了。比如写一个 Markdown 文档描述代码规范，让 AI 每次写代码之前先看一眼。或者写一段脚本，让 AI 在某个时机去运行。

现在 Skill 被很多人传得神乎其神，好像它让 AI Agent 能做到了很多以前完全做不到的事情。但实际上它只是一个用于规范上下文结构的工具。如果大家之前有用过 Coding Agent，可能早就已经在用类似的方式管理上下文了——写个 Markdown 文件放在项目里让 AI 读，本质上就是同一回事。

Anthropic（Claude 的公司）做的事情是把这种零散的做法标准化了：固定了文件夹结构、固定了格式、给它起了个名字叫 Skill，然后让所有 Agent 产品都能识别和使用这种格式。现在不管是 Codex、Claude Code 还是 Cursor，都支持 Skill。

为什么需要 Skill

这个问题换个角度想：AI 模型本身已经很强了，它为什么还需要额外的"操作指南"？

两个原因。

第一，AI 本身不具备的知识。 比如我们公司内部的代码规范、某个第三方 API 的调用方式、我自己写的某个工具怎么用。这些东西 AI 的训练数据里没有，它不知道。我们把这些知识写进 Skill，它看了就知道了。

第二，重复性的工作流程。 比如我每天都要写日报、每天都要提交代码走 PR 流程、每次做设计稿都是同一套步骤。如果每次都从头跟 AI 说一遍，太浪费时间了。把流程写成 Skill，之后一句话触发就行。

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

还有一个关键点：AI 自己写给 AI 看的 Skill，效果通常不好。 如果没有人为的 know-how 介入，让 AI 自己去生成一个 Skill，它只会把自己已经知道的东西再写一遍。下次读取的时候等于在看自己已有的知识，没有增量。

真正有价值的 Skill，是我们人把 AI 做不好的事情、容易犯的错误、以及我们独有的经验和判断写进去。这才是它下次做得更好的关键。

渐进式加载机制

这个是 Skill 设计里最聪明的部分。

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

第一层：名字和描述。 所有 Skill 的 name 和 description 会在每次对话时发送给 AI。每个 Skill 大概占 100 Token 左右。这是 AI 用来判断"我现在需不需要用某个 Skill"的依据。

第二层：正文内容。 只有当 AI 根据 description 判定"这个 Skill 跟当前任务相关"之后，它才会去读取 SKILL.md 的正文。正文通常控制在 5000 Token 以内。

第三层：附属资源。 正文里可能会写"如果你需要做 XXX，去读 references/xxx.md"。只有在真正需要的时候，AI 才会去读取那些参考文件和脚本。不需要的时候它们就安静地待在硬盘上，不占上下文。

这种设计的好处是：我们可以装很多 Skill，但不会因此让每一次对话都变得很臃肿。只有被触发的 Skill 才会真正消耗上下文预算。

用一个比喻来说：Skill 就像一个图书馆的目录。AI 每次对话的时候会浏览一遍目录（name + description），看看有没有跟当前任务相关的书。如果找到了，它才会去架子上把那本书取下来翻开读（加载正文）。如果那本书里说"详细数据参见附录 C"，它才会再去翻附录（读取 references）。

Skill 的文件结构

一个标准的 Skill 长这样：

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

SKILL.md 的格式：

---
name: my-skill-name
description: 描述这个 Skill 做什么，什么时候触发，什么时候不触发。
---

具体的操作步骤和指南写在这里……

最上面三横杠之间的部分叫做 frontmatter，是 YAML 格式的元数据。这部分是第一层，始终在上下文里。

三横杠下面的 Markdown 正文是第二层，只有被触发之后才会加载。

scripts 目录放脚本。比如我有个 Skill 需要调用某个 API，我可以把调用逻辑写成一个 Python 或 Shell 脚本，AI 在执行的时候直接跑这个脚本就行，不需要每次自己重新写代码。

references 目录放参考资料。比如设计规范文档、API 接口定义、历史数据等。AI 在需要查阅的时候才去读。

触发方式

Skill 有两种触发方式：

主动触发 — 我们在对话里用 $skill-name 或者输入 /skills 来手动指定用哪个 Skill。这种方式最可靠。

自动触发 — 我们正常说话，AI 根据我们消息的内容去匹配所有 Skill 的 description。如果语义匹配上了，它就自动加载。比如我说"帮我给视频加字幕"，有个 Skill 的 description 里写了"处理视频字幕"，它就自动触发了。

这里 description 的写法就很重要。写得太模糊容易误触发，写得太窄可能触发不了。好的做法是在 description 里把触发词写清楚，同时明确"什么时候不触发"。

Skill 和普通文档的区别

有些人会问：我直接写一个 Markdown 文件丢到项目目录里，让 AI 去读，跟 Skill 有什么区别？

功能上确实差不多。任何有读文件能力的 Agent 都能读 Markdown。

但 Skill 多了几个好处：

• 自动触发 — 普通文件需要我们每次手动让 AI 去读，或者在 AGENTS.md 里写明。Skill 可以根据对话内容自动触发。
• 渐进式加载 — 普通文件如果写在 AGENTS.md 里，每次都要全部加载。Skill 只有被触发才加载正文。
• 标准化格式 — 不同 Agent 产品都能识别 Skill 格式，写一次到处用。
• 可分发 — Skill 有标准的安装方式，放到 GitHub 上别人一条命令就能装。

如果你只是自己用，写个普通文件也完全可以。但如果你想让工作流可复用、可分享、可自动触发，写成 Skill 格式会方便很多。

---

怎么找到和安装 Skill

去哪里找 Skill

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

GitHub 搜索。 最直接的方式。在 GitHub 上搜索 "codex skill" 或者 "claude skill" 加上我们想要的功能关键词，通常能找到不少。很多个人开发者会把自己写的 Skill 开源出来。

Skills Marketplace。 专门收集 Codex Skill 的市场网站，可以按分类搜索。比起 GitHub 自己翻，这里整理得更清楚一点。

ClawHub。 这个是社区驱动的 Skill 和 Plugin 商店，目前已经收录了超过 5 万个工具。如果我们找的 Skill 偏向通用场景（不只是 Codex 专用的），可以来这里看看。

Codex 桌面端的 Plugins 页面。 在 Codex 里点击左侧的 Plugins，切到 Skills 标签页，里面可以搜索和浏览一些推荐的 Skill。

直接让 Agent 帮你找。 我觉得这是最方便的方式。直接跟 Codex 说"我想要一个能帮我做 XXX 的 Skill，帮我找找看"，它会自己去搜索、评估、甚至直接帮你安装。

怎么安装

安装 Skill 有三种方式，从简单到复杂：

方式一：直接让 Agent 装

这是我最推荐的方式。找到一个 Skill 的 GitHub 链接之后，直接丢给 Codex，跟它说"帮我安装这个 Skill"。它会自己去下载、放到对应的目录里。就这么简单。

因为 Agent 本身就有下载文件和操作文件夹的能力，安装 Skill 对它来说是很基础的操作。

方式二：用命令行安装

在终端里运行：

npx skills add owner/repo-name

比如安装我的 draw-ui：

npx skills add oil-oil/draw-ui

运行之后它会问你要安装到哪个 Agent（Codex、Claude Code、还是其他的），选好之后回车就装好了。

方式三：手动下载

从 GitHub 上把仓库下载下来（或者 git clone），然后把文件夹放到对应的目录里：

• Codex 全局 Skill 目录：~/.codex/skills/
• Claude Code 全局 Skill 目录：~/.claude/skills/
• 项目级别：.codex/skills/ 或 .agents/skills/

手动操作虽然步骤多了一点，但好处是你清楚地知道文件放在了哪里。

安装完之后的检查

装好之后可以验证一下。在 Codex 桌面端，打开 Plugins > Skills，看看新装的 Skill 有没有出现在列表里。如果出现了，说明安装成功了。

也可以直接试一下：输入一句跟这个 Skill 相关的话，看它会不会自动触发。如果没有触发，可以手动用 $skill-name 来调用。

关于装多少个的建议

前面讲上下文的时候提过，每个 Skill 的 name 和 description 都会常驻在上下文里。虽然每个只占大约 100 Token，但积少成多。更重要的是，Skill 太多之后 AI 在匹配的时候容易选错。

我的建议是：没有刚需就不要装。

如果某个 Skill 你装了之后只用过一两次，或者它的功能你自己用几句话就能交代清楚，那它的存在就是在浪费上下文空间、增加匹配干扰。

我自己定期会整理一下 Skill 列表，把不常用的关掉或者删掉。在 config.toml 里可以禁用但不删除：

[[skills.config]]
name = "some-unused-skill"
enabled = false

精简为主。上下文越干净，AI 的执行效果越好。

---

怎么写一个好的 Skill

现在几乎都是让 AI 来写 Skill

先说一个大前提：我们现在写 Skill，不是自己一个字一个字去敲 Markdown。整个流程是讲给 AI 听的。

我的做法通常是：跟 Agent 描述清楚"我想要一个什么样的 Skill、它应该在什么时候触发、核心流程是什么、有哪些注意事项"，然后让它帮我生成 SKILL.md 和配套文件。Codex 内置了一个叫 Skill Creator 的 Skill，专门做这件事。Claude Code 和 Cursor 也有类似的创建流程。

但这里有一个关键点：写 Skill 的模型一定要足够强。

因为 Skill 本质上是把一个强模型的理解和判断固化成文件，之后给任何模型（包括弱一点的模型）去读和执行。如果你用一个弱模型来写 Skill，它写出来的东西可能本身就有理解偏差，后续执行的时候效果就更差了。

用最强的模型来写 Skill，相当于把强模型的一部分知识蒸馏进了文件里。之后即使执行的时候用的是一个便宜模型，它也能按照这份高质量的指南来做。

所以我的建议是：创建和迭代 Skill 的时候用最强的模型（GPT-5.5 或 Claude Opus），日常触发执行的时候可以用默认模型。

什么时候值得写成 Skill

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

比如我每天都要写日报、每天都要提交代码走 PR 流程、每次做分享都要做 PPT。这些事情的步骤是固定的，只是每次的具体内容不同。写成 Skill 之后一句话触发就行了。

反过来说，如果 AI 本身就能做好的事情，没必要写 Skill。模型已经知道怎么写 React 组件了，你不需要再写一个"如何写 React 组件"的 Skill。Skill 应该提供的是模型本身不具备的知识和判断。

description 是最重要的部分

写 Skill 的时候，大家最容易忽略的就是 description。很多人花了大量时间写正文，但 description 只写了一句话。这会导致 Skill 要么不触发、要么乱触发。

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

1. 这个 Skill 做什么（用第三人称写，因为它会被注入到系统提示词里）
2. 什么时候应该触发（列出关键词和场景）
3. 什么时候不应该触发

举个例子：

description: >
  给视频添加 AI 字幕。当用户提到"加字幕"、"字幕"、"subtitle"、
  "处理这个视频"、"视频字幕"时触发。
  不要在用户只是讨论视频内容、或者在谈论其他格式转换时触发。

把触发词写进去很重要，因为 AI 是靠语义匹配 description 来决定用不用这个 Skill 的。description 里的"什么时候触发"这部分信息是 Skill 能否被正确调用的关键——写在正文里没用，因为正文只有触发之后才会被读取。

正文怎么写

正文就是操作指南。AI 在触发 Skill 之后会读取这部分内容，然后按照里面写的来执行。

几个原则：

控制在 500 行以内。 SKILL.md 的正文一旦被加载，整个内容都会进入上下文。写太长就在浪费注意力预算。如果实在需要很多内容，把详细的东西拆到 references 目录下面去。

写命令式的步骤，不要写解释性的长篇大论。 AI 需要的是"做什么"，不是"为什么这样做"。比如写"第一步：检查项目里有没有 package.json"，而不是"首先我们需要确认项目的技术栈，因为不同技术栈的处理方式不同……"。

用简洁的示例代替冗长的解释。 如果某个操作不太好用文字描述清楚，直接给一个具体的例子，AI 看一眼就懂了。

每一条信息都要自问：AI 真的需要这个吗？ 如果某段内容 AI 不看也能做好，那就不要写进去。

scripts 什么时候用

如果某些步骤需要精确执行、不能让 AI 自由发挥，就写成脚本。比如：

• 调用某个特定的 API，需要固定的 headers 和认证信息
• 文件格式转换，需要确定的命令和参数
• 数据处理，需要精确的逻辑不能有偏差

脚本的好处是：执行的过程是确定性的，不会因为 AI 的理解偏差而出错。而且脚本在创建 Skill 的时候写好之后，后续使用时 AI 直接运行就行了，不需要每次都重新写一遍代码。

references 什么时候用

当正文里需要引用一些比较长的参考资料，但又不是每次都会用到的，放到 references 里面。正文里写一句"如果需要做 XXX，先读取 references/xxx.md"就行了。

比如我做 UI 设计的 Skill 里面，references 放的是设计心理学的一些原则。不是每次做设计都需要看这些，但如果我想让设计更专业，可以让 AI 去读一下再做。

工作流类 Skill：先跑通再写

如果我们要把一个工作流封装成 Skill，我自己的经验是：不要一开始就尝试写 Skill，而是先用正常对话的方式让 Agent 把整个流程完整跑通一遍。

比如我想做一个"视频加字幕"的 Skill。我不会上来就开始写 SKILL.md，而是先在一个对话里，一步步跟 Agent 把整个流程走完：提取音频、转文字、校对、生成字幕文件、烧录。中间哪一步它做得不好，我就纠正一下。

等整个流程都跑通了、效果也满意了，我再回过头去复盘这次对话：哪些步骤是固定的、哪些地方我做了额外的指导、哪些地方它容易出错。把这些东西提炼出来，才写成 Skill。

这样写出来的 Skill 质量比直接凭想象写要高很多，因为每一条指令都是经过实际验证的。

用子 Agent 测试 Skill

写完 Skill 之后怎么验证它好不好用？

我的做法是让 Agent 启动一个子 Agent，让子 Agent 在干净的上下文里去使用这个 Skill。因为我们自己的主对话里可能已经有了很多上下文信息，Skill 看起来工作正常，但其实是因为上下文里已经有了背景信息在辅助。

让一个全新的子 Agent 从零开始、只靠 Skill 里写的内容去执行，才能真正验证它写得够不够清楚、够不够完整。如果子 Agent 能做好，说明 Skill 本身是自洽的。如果做不好，说明 Skill 里有些信息是缺失的，需要补充。

反馈迭代

Skill 不是写完就一直用的。用了一段时间之后，我们会发现 AI 在某些地方总是做得不好。这时候就需要回去改 Skill。

比如我写了一个设计 Skill，给了一些规范让它遵循。用了几次发现它太死板了，每次出来的设计都差不多，没有创造力。那我就回去把那些规范改成"参考方向"而不是"硬性要求"，给它更多自由度。

改 Skill 这件事本身也可以让 AI 来做。跟它说"我觉得这个 Skill 在 XXX 方面做得不好，帮我调整一下"，它会自己去改 SKILL.md。

但核心判断——哪里做得不好、应该怎么改——这个必须是人来做。因为 AI 让自己优化自己的 Skill，它只会把已有知识重新表述一遍，不会产生新的洞察。是我们人把 AI 做不好的地方告诉它，它才能下次做得更好。这是 Skill 迭代的核心。

一些额外的写法建议

解释"为什么"比下命令有效。 Skill 里写规则的时候，告诉 AI 原因比写"必须这样做"好。比如写"不要在一个文件里输出超过 2000 行，因为输出 Token 有上限且速度会指数级变慢"，比写"禁止输出超过 2000 行"有效得多。当 Agent 理解了原因，它能在新情况下自己做出正确判断，不会死板地遵守一条规则然后在别的地方犯同样的错。

AGENTS.md 和 SKILL.md 的分工要清楚。 很多人搞不清楚什么放 AGENTS.md、什么放 SKILL.md。简单来说：如果一个信息每一次对话都需要用到（比如项目的构建命令、代码规范、目录结构），放 AGENTS.md；如果只在做某件特定事情的时候才需要，放 SKILL.md。不要把所有东西都塞进 Skill 里。

从网上安装的 Skill 要审查。 Skill 可以改变 Agent 的行为，让它运行命令、安装工具、操作文件。如果一个 Skill 里面写了让 Agent 去执行危险命令或者处理凭证的逻辑，用之前先看一眼内容。跟安装软件一样，来源不信任的就多留个心眼。

诊断 Skill 不好用的时候可以对照这个表：

现象	可能的原因
该触发的时候不触发	description 太抽象，缺少用户实际会说的关键词
触发了错误的 Skill	两个 Skill 的 description 有重叠
触发了但结果不对	正文步骤不够清晰或缺少关键信息
执行到一半失败了	缺少错误处理或前置条件检查

遇到问题的时候，根据现象去对应调整就行了。Skill 是通过不断使用和修正来变好的，不是第一次就能写完美的。

不用焦虑这些规则

看到这里可能有人觉得要注意的东西好多。其实不用焦虑，因为上面提到的这些写法原则，大部分都已经写在 Codex 内置的 Skill Creator 这个 Skill 里面了。我们让 Agent 帮我们创建 Skill 的时候，它自己就会遵循这些规则。

我们要做的不是背下这些规则，而是理解它们背后的逻辑：上下文是有限的、description 是路由信号、正文要精简、脚本做确定性操作。理解了这些，我们在审查和迭代 Skill 的时候就知道往哪个方向改。

创建 Skill 的实际流程

实际操作的时候，我一般分三步：

第一步：跟 Agent 把需求聊清楚。 告诉它我要做什么、在什么场景下触发、核心流程是什么步骤、有哪些容易出错的地方。这一步就是在把我脑子里的 know-how 讲出来。

第二步：让它生成初版。 Codex 有内置的 Skill Creator，直接说"帮我创建一个 Skill"就行。它会按照标准结构生成 SKILL.md 和配套文件。Cursor 里也有类似的创建流程。生成的初版通常结构是对的，但内容可能太泛了。

第三步：人工补充关键判断。 这一步最重要。看一遍生成出来的 Skill，把 AI 自己不知道但我知道的东西加进去。比如"这个 API 在某种情况下会超时，需要加重试"、"生成的文件超过 2000 行就要拆分"这种实战经验。

整个过程就是人负责判断和决策，AI 负责生成和格式化。不需要我们自己去敲 Markdown 的格式，但核心的 know-how 必须由人来提供。

---

实用 Skill 场景

前面讲了 Skill 的原理、怎么找、怎么写。这一节我分享几个我自己实际在用的 Skill 方向。

不过我想先强调一点：比起安装别人的 Skill，更好的方式是自己去定义适合自己工作流的 Skill。 因为每个人的项目不同、规范不同、习惯不同，通用的 Skill 很难完全贴合你的场景。别人的 Skill 最好的用途是当做参考和灵感来源，然后基于自己的实际需求去改或者从头写一个。

跨 Agent 协作

不同的 Agent 擅长不同的事情。我们可以写一个 Skill，让当前的 Agent 把某些任务委派给另一个 Agent 去做。

比如我平时用 Claude Code 做主力开发，但有些重复性的执行任务我想交给 Codex 来跑（因为它用的是 ChatGPT Pro 的额度，不走 API 计费）。我写了一个 Skill，里面包含了一个脚本，Claude Code 只要把任务描述传过去，Codex 就会在后台启动执行，执行完把结果写到一个文件里，Claude Code 再读取结果就行了。两个 Agent 的上下文完全独立，互不干扰。

同样的思路也适用于：主 Agent 用强模型做决策，子 Agent 用便宜模型做执行；或者不同 Agent 负责前端和后端各自的工作。

日常工作流自动化

任何我们每天重复做两次以上的事情，都值得封装成 Skill。

比如我自己做的几个方向：

• 写日报 — Skill 里配好了日报的格式和飞书文档的写入方式。我每天跟 Agent 说一声"写日报"，它就自己去看今天的 Git 提交记录，分析做了什么，然后按格式写到飞书文档里。我不用自己去回忆今天干了啥。
• 提交代码 — 一个 Git Ship 的 Skill，自动完成：检查代码 → 切分支 → 提交 → 推送 → 创建 PR → 等 CI 通过 → 合并 → 切回主分支拉最新代码。整个流程自己闭环。
• 多平台发布 — 录完视频之后，一句话让它帮我分发到小红书、B站、抖音等多个平台。

这类 Skill 的特点是：步骤固定、每次只是内容不同。把流程写死在 Skill 里，Agent 只需要填入当次的具体内容。

代码库信息提取

代码库里的信息比 PRD 全面，而且永远是最新的。PRD 会过时，但代码不会，因为代码就是当前系统实际在跑的东西。

我们可以用 Skill 来从代码里提取各种形式的输出：

• 给技术人员看 — 把代码实现转成交互式课程，解释每个模块是干什么的、数据怎么流转的。适合新人快速了解一个陌生项目。
• 给产品经理看 — 从代码和 PRD 里提取业务逻辑、产品概念、用户旅程、资源关系，生成一份可视化的业务理解报告。比翻十几份 PRD 快得多。
• 给自己看 — 接手一个新项目的时候，让 AI 扫描整个仓库，生成一份架构全景图，快速建立对项目的整体认知。

这个方向的 Skill 通常开销比较大（因为要读大量代码），但产出很实用。

Skill 性能优化：模板化思维

很多 Skill 在生成最终产物的时候（比如 HTML 报告、PPT），会让 AI 把整个文件从头到尾写一遍。如果文件很大（几千行），AI 的输出速度会很慢，Token 消耗也很高。

一个优化思路是：把重复的部分做成预置的模板片段，AI 只负责生成内容数据，拼装由脚本来完成。

比如一个生成 HTML 报告的 Skill，我们可以这样设计：

• references 里放好 HTML 的样式模板、交互组件的代码片段
• AI 分析完代码之后，只输出一个结构化的 JSON（标题、段落内容、图表数据）
• 一个脚本读取这个 JSON，把内容插入到模板里，组合成最终的 HTML

这样 AI 的输出量从几千行降到了几百行，速度快了很多，而且最终产物的样式和交互还更稳定（因为是预置的，不会每次都不一样）。

这个思路的核心就是：能用程序确定性完成的事情，不要让 AI 每次重新写一遍。 AI 负责思考和决策，脚本负责拼装和执行。

设计与创作辅助

利用 Codex 自带的生图能力，我们可以把设计流程封装成 Skill：

• 用参考图 + 提示词策略来生成 UI 设计稿
• 生成完之后自动还原成 HTML 代码
• 做 PPT / Slides 的时候自动选主题、配色、排版

这类 Skill 的关键是把"怎么写提示词效果好"这个经验固化下来。让 AI 不用每次都靠运气，而是按照验证过的策略来生成。

外部平台连接

通过 Skill 配合 CLI 工具或者 MCP，可以让 Agent 操作各种外部平台：

• 飞书：读写文档、发消息、管理知识库
• GitHub：创建 PR、Review 代码、管理 Issue
• 数据库：查询和修改 Supabase、MongoDB 里的数据
• 自媒体平台：配合浏览器自动化发布内容

这类 Skill 通常会在 scripts 目录里放一些认证相关的配置（Token、API Key），这样 Agent 在执行的时候不需要每次都问我们要认证信息。

Skill 绝对不是越多越好

这个点我在前面提过，但因为太重要了这里再单独说一下。这不只是 Codex 的问题，所有 Agent 产品都一样。

不管是 Codex、Claude Code、Cursor 还是其他 Agent，Skill 的元数据（name 和 description）都会在每次对话时写进上下文。Skill 越多，这部分占的空间越大，模型的注意力就越分散。

以 Codex 为例，它有一个明确的预算机制：Skill 元数据被限制在上下文窗口的约 2% 以内。超了之后它会截断 description，再超就直接省略 Skill。但即使没有超预算，几十个 Skill 的 description 挤在一起，模型在匹配的时候也容易选错。

Claude Code 也一样。它虽然没有一个硬性的百分比限制，但上下文就那么大，几十个 Skill 的描述加起来就是几千 Token，每一轮对话都在那里占着位置。

我自己的做法是：

• 只保留真正高频使用的 Skill
• 不常用的 Skill 关掉，需要的时候再打开
• Plugin 里面自带的 Skill 也要检查一下，把用不到的关掉
• 宁愿少装几个，保持匹配的准确性

什么时候该写 Skill，什么时候直接说就行

不是所有场景都需要 Skill。

如果你只是偶尔做一次某件事，直接跟 Agent 说就行了。Agent 的能力本身已经很强了，大部分事情说清楚目标它就能做。

只有当你发现自己在反复做同一件事、或者 AI 总是在某个点做不好需要额外补充 know-how 的时候，才值得花时间写成 Skill。

写 Skill 需要花时间，后续每次使用能省下重复沟通的成本。但如果这个任务你只做一次，那花时间写 Skill 就不划算。

---

Harness 概念与设计

什么是 Harness

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

OpenAI 在 2026 年发了一篇叫做 Harness Engineering 的文章，讲的就是这个概念。它的核心观点是：以前我们一直在研究怎么写好提示词（Prompt Engineering），后来发展到怎么管理好上下文（Context Engineering），现在到了下一个阶段——怎么设计好整个工程环境让 Agent 稳定工作（Harness Engineering）。

这三个阶段是递进的：

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

但说实话，这三个概念之间没有什么本质的断层。Harness Engineering 听起来很唬人，但如果你已经理解了上下文工程，Harness 就只是上下文工程的系统化落地而已。

上下文工程讲的是"怎么让 AI 在每一轮对话里看到最有用的信息"。Harness 讲的是"怎么设计一套机制，让 AI 在长时间、多轮、多话题的工作中，始终都能看到有用的信息、遵循正确的规范、做出稳定的判断"。

一个是单次对话级别的优化，一个是项目级别的系统性设计。本质都是在管理"AI 能看到什么"。

所以大家不需要把 Harness 当成一个全新的学科来学。如果你已经在做这些事——写 AGENTS.md、用 Skill 管理工作流、用 Hook 做自动检查、用文件形式保存知识——你就已经在做 Harness Engineering 了，只不过之前没有一个统一的名字来描述它。

为什么需要 Harness

如果你用 Agent 写代码的时间比较长，可能已经遇到过这些问题：

• 一个错误的写法它翻来覆去地改，改了好几轮还是那个样子
• 每次新开一个话题，它就忘了之前定好的规范，自己又搞一套新的
• 代码库越来越大，它对整体结构的理解越来越差
• 我们的时间越来越多花在 Review 代码和测试功能上，而不是在推进新功能

这些问题的根本原因是：我们每次只是在单独给 AI 下指令，没有设计一套能让它持续稳定工作的规则体系。它每次都是从零开始理解你的项目，没有一个固定的工作框架来约束它。

Harness 就是这个框架。

Harness 的几个核心组成

根据 OpenAI 和 Anthropic 的文章，以及我自己的实践，一个好的 Harness 大概包含这几层：

项目规范文件

这个是最基础的一层。在项目根目录放一个规范文件（Codex 里叫 AGENTS.md，Claude Code 里叫 CLAUDE.md），告诉 Agent：

• 这个项目用什么技术栈、什么框架
• 代码放在哪些目录、每个目录干什么
• 怎么启动项目、怎么跑测试
• 代码风格的约定是什么

这样每次新开话题，Agent 第一件事就是读这个文件，它马上就知道项目的全貌了，不需要自己花大量上下文去探索。

知识放进仓库

很多项目相关的知识散落在飞书文档、Notion、或者团队成员的脑子里。Agent 看不到这些东西。

我自己的做法是在项目里建一个 docs/ 目录，把架构设计、产品需求、数据库结构这些都以文件的形式存进去。这样 Agent 需要的时候自己去读就行了，不需要我们每次手动复制粘贴。

对于数据库结构，我更推荐直接接一个 MCP（比如 Supabase 或者 MongoDB），让 Agent 自己去查实时的表结构。这样比维护一份可能过时的文档更可靠。

用程序强制执行规则

以前我们在提示词里写"每次改完代码要跑一下类型检查"。但上下文一长，这条提示词就被埋没了，Agent 就忘了。

更好的做法是：通过 Hook 机制，在 Agent 每次修改代码之后，程序自动去跑类型检查和 Lint。不管 Agent 记不记得，检查都会执行。如果有错误，错误信息会自动注入到 Agent 的上下文里，它就会自己去修复。

这个思路是：能用程序确定性保证的事情，就不要依赖提示词。 提示词在上下文长了之后会被忽略，但 Hook 是程序级别的，不会被遗忘。

让 Agent 具备自我验证的能力

这个是让 Agent 能长时间自己工作的关键。

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

要让 Agent 能自己跑这个循环，它需要：

• 自己能启动项目和测试环境
• 自己能在浏览器里去看页面效果（通过 Agent Browser 或 Chrome 插件）
• 自己能读取控制台日志（通过 Chrome DevTools MCP）
• 自己能判断修复结果是否符合预期

当 Agent 具备了"改代码 → 自己测试 → 看日志 → 再修复"这个完整循环的能力，它就可以自己一直干到 Bug 修好为止。我们只需要给它设置一个 Goal，然后去睡觉就行了。

架构规范的机械化执行

OpenAI 的 Harness 团队在用 Agent 开发产品的过程中，做了一件很有意思的事：他们把架构规范写成了自定义的 Linter 规则。每条 Linter 的错误信息里直接写好了修复方式。

这样 Agent 每次写了不符合规范的代码，Linter 报错了，错误信息本身就告诉它该怎么改。不需要在提示词里写几百行的架构说明，一条 Lint 错误就够了。

他们甚至做了定期的"垃圾回收"：让 Agent 定时去扫描代码库，检查有没有偏离架构规范的地方，发现了就自动开 PR 去修复。

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

上面讲的一些做法可能偏工程化了。对于大多数人来说，不需要搞那么复杂。最核心的几件事：

1. 写好项目规范文件（AGENTS.md） — 这是成本最低、回报最高的一步。让 Agent 每次新开话题都能快速了解项目。
2. 把重复犯的错写进规范 — 如果 Agent 在某个地方总是做错，把正确的做法写进 AGENTS.md 里。
3. 给它接上验证工具 — 让它能自己跑测试、看报错、读日志，不要什么都依赖我们手动确认。
4. 设计好任务的退出条件 — 用 Goal 的时候写清楚什么算做完了，给它一个明确的验证方式。

一个 AGENTS.md 的示例

下面是一个中等复杂度的 Next.js 全栈项目的 AGENTS.md 大致长什么样：

# 项目概览
这是一个 SaaS 产品的前端项目，使用 Next.js 14 + TypeScript + Tailwind CSS + Supabase。

# 启动与测试
- 安装依赖：pnpm install
- 开发环境：pnpm dev（端口 3000）
- 类型检查：pnpm typecheck
- Lint：pnpm lint
- 单元测试：pnpm test

# 目录结构
- src/app/ — Next.js App Router 页面
- src/components/ — 公共组件
- src/lib/ — 工具函数和 API 封装
- src/hooks/ — 自定义 React Hook
- supabase/migrations/ — 数据库迁移文件

# 代码规范
- 组件用函数式写法，不用 class 组件
- 样式全部用 Tailwind，不写 CSS 文件
- API 请求统一走 src/lib/api.ts 里的封装函数
- 数据库操作走 Supabase Client，不直接写 SQL

# 注意事项
- 不要修改 supabase/migrations/ 里已有的文件，新的改动要创建新的 migration
- 环境变量在 .env.local 里，不要提交到 Git
- 修改完代码之后跑一次 pnpm typecheck 确认没有类型错误

这个文件不需要写得很长。关键是让 Agent 在三十秒内知道：项目用什么、代码放哪里、怎么跑起来、有什么不能动的规则。写好这个之后，我们每次新开话题就不用重复交代这些背景信息了。

而且这个文件也是可以让 Agent 自己生成的。在项目目录里跟它说"帮我生成一个 AGENTS.md"，它会自己去看 package.json、目录结构、现有代码，然后写出来一份初版。我们看一看、改一改就行。

Harness 不是一次性设计完的。它是在日常使用中一点点补充的。每次发现 Agent 在某个地方做得不好，就想想这个问题是不是可以通过环境设计来避免，而不是每次都在对话里纠正它。

Anthropic 的观点

Anthropic 在他们的文章里提到一个很重要的原则：Harness 里的每一个组件，都编码了一个关于"模型不能自己做到什么"的假设。这些假设需要经常被质疑，因为模型在变强。

意思就是说，我们今天设计 Harness 的时候加的某些规则，可能明天新模型出来就不需要了。比如以前我们可能需要在 Harness 里强制 Agent 每次都做计划再执行，但现在的模型已经很擅长自己规划了，这条限制可能就可以去掉了。

所以 Harness 的设计原则是：尽可能简单，只在确实需要的地方增加复杂度。 先试试最简单的方式够不够用，不够再加规则。不要一开始就设计一套巨复杂的体系。

---

Vibe Coding 如何提升效率

Vibe Coding 就是用 AI Agent 来写代码，自己不手动改文件，全靠描述需求让 Agent 去执行。我平时的开发基本都是这个模式。

用了一段时间之后，我总结了几个能明显提升效率的做法。

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

如果我们手上同时有好几个需求要做，比如一个在改首页样式、一个在修后端接口、一个在加新功能，它们之间互不相关。这时候最高效的做法是让它们并行跑，互不干扰。

工作树（Worktree）就是干这个事的。它相当于把我们的代码仓库复制了一份出来，在复制出来的那份里面改代码，不会影响到主项目。改完了之后提一个 PR 合并回去就行。

在 Codex 桌面端里，新建话题的时候底下可以选 Local（本地项目）或者 Worktree（新工作树）。选了 Worktree 之后，Agent 所有的改动都在独立的工作树里，跟我们正在跑的其他话题完全隔离。

在 Claude Code 里没有选择工作树的 UI，但直接跟它说"帮我创建一个工作树，切到一个新分支"就行了，它自己会执行 Git 命令。退出话题的时候它还会问我们要不要把工作树删掉。

这样我可以同时开三四个话题，每个话题在自己的工作树里做自己的需求，互不冲突。等各自做完了，分别提 PR 合并。如果有冲突，在合并 PR 的时候处理就好。

单个话题里的并行：子 Agent

有时候不是多个需求，而是一个大需求里面有几件可以同时做的事。比如我想让 Agent 帮我 Review 三个模块的代码，这三个模块互不依赖。

Codex 和 Claude Code 本身就有子 Agent 的能力。Claude Code 在探索代码的时候会自动派出 Explore 子 Agent 去查找文件，Codex 也支持我们主动让它派发子 Agent 并行工作。关键不是"能不能用子 Agent"，而是什么情况下用子 Agent 效果最好：

• 任务本身可以拆成几块独立的部分，互不依赖
• 每一块需要读取大量文件（子 Agent 的上下文独立，不会撑满主 Agent）
• 最终只需要各自的结论汇总，不需要中间过程

比如 Review 三个模块、同时调研三个技术方案、并行检查安全/测试/风格。这些都很适合子 Agent。

但如果任务是有顺序依赖的（第二步依赖第一步的结果），或者任务本身很简单不需要读太多文件，用子 Agent 反而多此一举，还多消耗 Token。

我以前的做法是在 Claude Code 里用 Codex Skill 并行启动多个 Codex 去执行。但现在我已经转成 Codex + GPT-5.5 的 All-in-One 模式了，在 Codex 桌面端里直接多开话题就行，每个话题就是一个并行的 Agent，互不干扰。如果想要在同一个话题里并行，直接跟 Codex 说"派几个子 Agent 分别做 XXX"就可以了。

让 Agent 自己提交代码

以前我写完代码之后，自己要手动去 commit、push、创建 PR、等 CI 跑完、合并。现在这些全部交给 Agent 做。

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

我写了一个 Git Ship 的 Skill，把这个流程固化下来：检查代码 → 切分支 → 提交 → 推送 → 创建 PR → 等 CI 通过 → 合并 → 切回主分支拉最新代码。每天用好几次。

用 /side 处理临时问题

开发过程中经常遇到这种情况：Agent 正在帮我做一个功能，做到一半我突然想确认一个 API 的用法、或者想问一下"这样写会不会有性能问题"。

如果直接在主对话里问，这些问答就污染了上下文，后续 Agent 继续做功能的时候上下文里多了一堆不相关的东西。

用 /side 就很方便：临时开一个侧边栏问完就回来，不影响主线的上下文质量。前面第七章详细讲过。

外部数据源作为 Harness 的一部分

效率的另一个来源是让 Agent 能直接访问到项目相关的外部数据，而不是每次都要我们手动去查再复制粘贴。

比如我接了 Supabase 的 MCP，Agent 可以自己去查数据库的表结构、看字段类型、甚至写 SQL 去验证数据。写后端接口的时候它直接查表就知道有哪些字段可用，不需要我再去文档里翻。

接了 GitHub 之后，Agent 可以自己去看 PR 的评论、CI 的报错日志、Issue 里的需求描述。我不用手动复制这些信息进来。

这些外部数据源接上之后，Agent 在工作过程中能自己获取到需要的信息，减少了大量我们手动当"信息搬运工"的时间。这本质上也是 Harness 的一部分——让 Agent 的工作环境里有足够的信息源，它就能更自主地干活。

需求描述的颗粒度

效率高不高，很大程度取决于我们给 Agent 描述需求的颗粒度。

太大了不行。"帮我做一个用户系统"这种需求，Agent 很难一次做对，做出来的东西大概率需要反复改。

太小了也没必要。"帮我在第 15 行加一个换行"这种我们自己手动改可能比描述给 Agent 还快。

我自己的经验是，一个好的需求描述粒度大概是：一次能做完、做完之后能立刻验证对不对的。 比如"给登录接口加上一个邮箱格式校验"、"把首页的卡片列表改成两列布局"。做完了跑一下就知道对不对。

如果一个需求太大，我会先用 Plan 模式让 Agent 拆成几步，然后一步步执行，每步验证一下再继续。

描述行为而不是描述修改

这个是从各种实践里总结出来的：描述你观察到的现象或者期望的行为，比描述你想让它怎么改代码效果好。

比如遇到一个 Bug：

• 不好的描述："在 api/users.ts 第 43 行加一个 WHERE 条件过滤掉已删除的用户"
• 好的描述："分页查询用户列表的时候，已经删除的用户还是会出现在结果里"

后者让 Agent 自己去定位问题和判断怎么修，它可能找到一个比我们想的更好的方案。如果我们直接告诉它怎么改，就限制了它的发挥。

每次做完一步就验证

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

原因很简单：如果第一步就做错了但没被发现，后面所有步骤都是在错误的基础上叠加的。等最后整体一看全是问题，纠正的成本比从头来还高。

每做一步就跑一下、看一下，发现方向偏了马上纠正。这个习惯能省下大量的返工时间。

频繁提交代码

AI 写代码的速度很快，但也意味着代码变化的速度很快。如果改了很多东西但一直没提交，中间出了问题就很难回退到某个正常的状态。

我的习惯是每做完一个小功能点就提交一次。这样如果后面搞砸了，我可以随时 reset 回到上一个正常的节点，而不用重新来过。

用 Git Ship 的话更方便——做完一件事直接让 Agent 帮我提交推送，几秒钟的事。

---

Vibe Coding 如何节省成本

节省开销不单单是减少 Token 用量。不同模型价格差很大，有的时候我们花了很多钱但效果不好，反而是在浪费。这一节讲的是在保证相同执行质量的前提下，怎么把整体的钱花得更少。

我自己的成本观

先说一下我自己的情况。我现在用的 AI 工具额度是公司报销的，所以日常开发不太需要担心费用。但我的很多省钱经验其实是以前公司没给报销的时候积累下来的。

那时候每个月花大几百甚至上千块去买 AI 工具，说实话还是挺肉疼的。但我后来发现一个事情：相比起 AI 带来的几十倍效率提升，我几乎不可能再退回去用效果差的工具了。 用过好的之后，你让我回去用免费的弱模型慢慢磨，那个时间成本远比几百块钱贵。

所以对于个人开发者来说，关键不是"怎么不花钱"，而是"怎么把钱花在刀刃上"。

另外我也想说一句：如果你现在的公司连每个月 500 块的 AI 工具开销都不给报，那你的开发效率大概率已经被同行甩开很远了。这种情况要么自费买更好的工具投资自己，要么认真考虑换到一个不限制 Token 使用额度的团队。2026 年了，AI 工具的开销对公司来说微乎其微，但对个人效率的影响是几倍到十几倍的差距。

下面这些方法是帮大家在不降低执行质量的前提下，尽可能减少浪费。

包月套餐 vs API 按量计费

前面第二章讲过这个问题。如果你每天重度开发，包月套餐比 API 按量计费划算太多了。API 计费下你每次让 Agent 读文件、跑命令都在花钱，几轮对话就是几美金。包月的话不管用多少都是固定价格，用起来不会有心理负担。

我自己现在用的是 ChatGPT Pro（200 美金），配合 Codex + GPT-5.5，日常重度开发完全够用。之前用 Claude 的 API 按量计费，一个月下来比这贵得多，而且还得一直盯着用量。

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

这个是节省成本最直接的方式。

我以前的做法是分三层：主模型（Claude Sonnet）做需求拆解和决策，便宜模型（GLM、Codex）做具体的代码执行，Gemini 做设计稿。因为大部分的执行性工作其实不需要最强模型，用便宜模型跑一样的效果但费用可能只有十分之一。

现在我转到 Codex All-in-One 之后，用的是同一个 GPT-5.5 但调节思考程度。简单任务用低思考（速度快、消耗少），复杂决策才用高思考。

核心思路是根据任务场景选合适的模型。比如 GLM-5.1 这类国产模型，对话感好、代码能力也不错，价格只有 Claude 的几分之一，用来做日常的 Skill 优化、Bug 修复、前端样式调整完全够。Gemini 做设计稿效果好又便宜，一次就出不错的效果。这些模型各有长处，不用全部堆在最贵的那个上面。

关键原则是：根据任务难度和类型灵活切换模型。 简单执行性任务用便宜模型，需要深度推理的复杂决策才上顶尖模型。不是非此即彼的选择，同一个项目里不同任务切不同模型是很正常的。大部分日常工作用中档模型就够了，真正处理不了的时候再切强的。

能用程序做的事不要让 AI 做

这个是节省 Token 的核心原则。

举几个例子：

代码检查 — 如果让 AI 自己去检查代码规范，它可能每个文件都要读一遍，消耗大量输入 Token。但如果配好了 ESLint 之类的工具，AI 只需要跑一个命令就能拿到所有文件的检查结果。用程序做十秒钟的事，让 AI 做可能要消耗几万 Token。

批量替换 — 比如我们想把项目里所有组件的 className 从 btn-primary 改成 btn-main。如果不提醒，AI 会像人一样操作：先搜索第一个文件，打开，替换，保存；再搜索第二个文件，打开，替换，保存……二十个文件就是二十轮工具调用，每一轮都要把之前的结果写进上下文。但如果我们跟它说"写一个脚本来批量替换"，它只需要写一段 sed 或者 Node 脚本，一次执行就全部改完了。同样的结果，前者可能消耗十几万 Token，后者只要几千。

日志信息 — 控制台打了一大堆日志，不要一股脑全复制丢给 AI。挑选跟问题相关的部分给它就行了。冗余信息不仅浪费 Token，还会干扰它的判断。

减少工具输出的噪音

Agent 每次调用工具（读文件、运行命令），工具返回的内容会全部写进上下文。很多工具的输出是给人看的，内容很详细但对 AI 来说有大量噪音。

比如 git log 默认输出的格式、npm install 的安装日志、Lint 工具的完整报告——这些里面有很多 AI 不需要的信息。

有一个工具叫 RTK（Rust Token Killer），专门解决这个问题。它是一个 CLI 代理，安装之后会通过 Hook 透明地拦截 Agent 执行的所有 Shell 命令，在输出到达 AI 之前先做压缩。

它的压缩方式有四种：

• 过滤 — 去掉注释、空行、无用的格式装饰
• 分组 — 比如 47 个 .tsx 文件不逐个列出，直接变成"components/ (47 .tsx files)"
• 截断 — 保留头尾关键信息，砍掉中间重复的部分
• 去重 — 同样的日志行出现 5 次就合并成一行加 (×5)

安装方式就一条命令：rtk init -g。装完之后它在后台自动运行，Agent 完全不知道它的存在，照常执行命令就行。根据社区的数据，同样的 30 分钟开发会话，Token 消耗能减少 60% 到 80%。我自己用了之后节省了 880 万 Token，而且压缩之后 AI 的执行效果反而更好了，因为噪音少了上下文更干净。

RTK 支持 Claude Code、Codex、Cursor、Gemini CLI、GitHub Copilot 等主流 Agent 工具。

用 Skill 减少探索成本

每次新开一个话题，Agent 要重新去探索代码库才能理解项目结构。这个探索过程是 Vibe Coding 里最大的 Token 消耗来源，大概占整体输入 Token 的 60% 到 70%。

怎么减少这个消耗：

• 写好 AGENTS.md — Agent 一进来就知道项目用什么技术栈、代码放哪里、怎么跑，不需要自己一个个文件去翻。
• 用 Skill 维护项目规范 — 前端规范、后端规范、组件库的使用方式，写好了之后 Agent 需要的时候直接读 Skill，不用自己去看几十个文件总结。
• 用 Explore 子 Agent — 前面讲过的，让子 Agent 先去探索，只把关键路径返回给主 Agent，避免主 Agent 自己读大量文件。

对话管理的技巧

及时新开话题。 一个话题里聊太久，上下文越来越长，每一轮对话的输入 Token 就越多。如果一个任务做完了，下一个任务跟它无关，直接新开话题。干净的上下文不仅执行效果好，Token 消耗也少。

用 rewind 复用上下文。 有时候一个长对话里，前面的信息对下一个任务还有用，但中间做了一些跟新任务无关的事。我会把后面无关的部分 rewind 掉（清除上下文但不回滚代码），然后在保留前面有用信息的基础上继续下一个任务。这样不用完全新开话题重新探索。

用 /side 或 /btw 问小问题。 不要为了一个小问题就污染主线上下文。用侧边栏问完就走，不增加主线的 Token 累积。

需求说清楚就是省钱

这个很容易被忽略。如果我们给 AI 的需求描述模糊，它就得花大量 Token 去探索、去猜、去试。探索半天可能还猜错了，又得重来。

相反，如果我们明确告诉它要改哪个文件（或者 @ 一下对应的文件路径），它一步到位去读那个文件就行了，不用自己全局搜索。

给 AI 的信息越精准，它需要的探索就越少，Token 消耗就越低。"帮我改 src/components/Header.tsx 里的导航栏高度"，比"帮我改首页的导航栏，好像有点太高了"省好几万 Token。

---