1. 半年迭代复盘：Codex 到底更新了哪些硬货
Codex 这半年的更新节奏，说实话比我预想的要猛。从最初那个只能补全代码的命令行工具，到现在能跑计划模式、能接第三方模型、能管理多轮会话的完整编码代理，中间隔了大概十几个版本。我几乎每个版本都跟了一遍，踩了不少坑，也攒了一些省 Token 的野路子。这篇文章就把我这半年的使用笔记整理出来，重点讲三件事：更新了什么、怎么省 Token、有哪些不太正经但确实好用的玩法。
如果你刚开始接触 Codex，或者用了一段时间但总觉得 Token 烧得太快、功能没吃透，那这篇应该能帮你省下不少试错时间。我会尽量把每个关键更新背后的逻辑讲清楚，不只是告诉你“有这个功能”，而是告诉你“为什么这么设计”以及“怎么用才不亏”。
1.1 从补全工具到编码代理的定位转变
早期 Codex 的定位很单纯，就是一个代码补全引擎。你在终端里敲个命令，它给你返回一段建议代码，完事。但大概从去年下半年开始，OpenAI 明显在把它往“编码代理”的方向推。什么叫编码代理？就是它不只是被动等你问，而是能主动读文件、跑命令、改代码、验证结果，形成一个闭环。
这个转变带来的最直接影响就是交互模式变了。以前你是一问一答，现在你可以给它一个任务描述，它自己拆步骤、自己执行、自己检查。计划模式就是在这个背景下出来的。你让它做一个功能，它会先列一个执行计划，你确认之后它再一步步做。这个模式的好处是你能提前看到它的思路，避免它跑偏了烧一堆 Token 才发现方向错了。
另一个明显的变化是模型支持的灵活性。以前 Codex 基本绑死在自家模型上，现在你可以通过配置接第三方模型，比如 DeepSeek 之类的。这个改动对国内用户来说意义很大，一方面是成本考虑，另一方面是某些场景下第三方模型的中文理解确实更顺。
1.2 计划模式与多轮会话管理的引入
计划模式刚出来的时候我其实没太在意，觉得多一步确认挺麻烦的。但后来有一次我让它重构一个模块，它没走计划模式直接开干，结果改了十几个文件，最后发现方向完全不对，Token 烧了一大截还得回滚。从那以后我就学乖了，稍微复杂一点的任务都先走计划模式。
计划模式的核心价值在于“把思考过程和执行过程分开”。它先输出一个步骤列表，你可以编辑这个列表，删掉不需要的步骤，或者调整顺序。确认之后它才真正开始执行。这个过程本身也消耗 Token，但相比它跑偏之后重新来的成本，这点消耗完全值得。
多轮会话管理是另一个实用更新。以前每次开新会话都是从头开始，上下文全丢。现在它可以保持会话状态，你可以在同一个会话里连续做多个相关任务，它记得之前改了什么、为什么这么改。这个对大型项目的连续性开发帮助很大，不用每次都重新交代背景。
1.3 第三方模型接入与配置体系的变化
配置体系的改动是我觉得这半年最值得关注的部分。早期 Codex 的配置很简单，基本就是 API Key 加几个开关。现在配置文件的结构复杂多了，支持模型切换、代理设置、Token 管理、会话持久化等等。
配置文件格式是 TOML，这个选择挺有意思的。TOML 比 JSON 更适合写配置，支持注释，结构也更清晰。但问题在于它的语法比较严格，一个引号或者括号写错了整个文件就加载不了。我遇到过好几次“无法加载 config.toml”的报错，排查半天发现就是一个字符串没加引号。
第三方模型接入这块，配置项里需要指定模型名称、API 端点、认证方式。有些第三方模型的接口格式和官方不完全一致，需要在配置里做适配。这个后面我会专门讲怎么配。
2. 省 Token 的核心逻辑：把钱花在刀刃上
Token 消耗是每个 Codex 用户都绕不开的问题。尤其是重度使用的时候，一天烧掉几十万 Token 很正常。但说实话，大部分 Token 其实是浪费掉的，要么是上下文带了一堆没用的信息，要么是让模型做了它不该做的事。我总结了几条省 Token 的原则，都是实打实能省下真金白银的。
2.1 上下文精简：别让模型读废话
Codex 每次执行任务的时候，会把当前项目的相关文件内容作为上下文发给模型。这个“相关”的范围如果控制不好，就会带进去大量无关代码。比如你改一个前端组件，它可能把整个项目的后端代码也读进去了，这些 Token 全是白花的。
我的做法是手动控制上下文范围。在配置文件里可以设置忽略规则，把不需要的目录排除掉，比如 node_modules、dist、.git 这些。另外，对于大文件，可以只把关键部分喂给它，而不是整个文件。具体操作是在任务描述里明确指定“只关注某某文件的某某函数”，这样它就不会去读其他部分。
还有一个技巧是定期清理会话历史。多轮会话虽然方便，但历史记录会一直累积，每轮都带着之前的所有对话，Token 消耗是线性增长的。如果当前任务和之前的对话无关，就开新会话，别舍不得。
2.2 模型选择策略：什么活用什么模型
不同模型的 Token 价格差异很大，能力也有区别。我的策略是分档使用：简单的代码补全、格式调整、注释生成，用便宜的小模型就够了；复杂的重构、架构设计、疑难排查，才上大模型。
在配置文件里可以设置默认模型，也可以在单次任务里临时切换。我一般把默认模型设成中等档位的，遇到搞不定的再手动切到高级模型。这样日常使用的成本能降下来不少。
另外要注意的是，有些模型对中文的支持更好，有些对特定编程语言更擅长。比如处理 Python 代码的时候，某些第三方模型的表现就不错，价格还便宜。这个需要根据自己的实际使用场景去试，没有统一答案。
2.3 提示词工程：把话说清楚就是省钱
提示词写得好不好，直接影响 Token 消耗。一个模糊的指令会让模型反复确认、多次尝试，每一次交互都是 Token。一个清晰的指令能让它一次做对，省下大量来回。
我写提示词的习惯是：先说背景，再说目标，最后说约束。背景交代清楚当前代码的状态和业务逻辑，目标说明要达成什么效果，约束列出不能改什么、必须用什么。这三段写清楚，模型基本不会跑偏。
还有一个细节是避免让模型“解释”。默认情况下它会在执行前输出一段分析，执行后再输出一段总结，这些文字也占 Token。如果不需要，可以在提示词里明确说“直接给结果，不要解释”。这个习惯能省下不少。
2.4 缓存与复用：同样的活别干两遍
Codex 有一些缓存机制，比如相同的文件内容不会重复读取，相同的查询会复用结果。但这个缓存不是万能的，需要你主动去配合。
我的做法是把常用的代码片段、配置模板、常用命令整理成文件放在项目里，需要的时候直接引用文件路径，而不是把内容粘贴到对话里。这样一方面减少 Token，另一方面也方便维护。
另外，对于重复性的任务，可以写成脚本让 Codex 调用，而不是每次都用自然语言描述一遍。比如批量重命名、批量格式化这种，写个脚本一次搞定，比反复对话高效得多。
3. 实操配置：从安装到跑通第一条任务
这部分我尽量写得细一点，因为配置环节是最容易卡住新手的。我自己第一次配的时候折腾了大半天，各种报错。下面按步骤来，每一步都说明为什么这么做。
3.1 安装与初始配置的完整流程
安装方式有几种，我推荐用包管理器装，省事。Windows 上可以用 winget 或者 scoop，macOS 上用 brew，Linux 上用对应的包管理器。装完之后第一件事是验证版本，确保装的是最新版。
初始配置需要设置 API Key 和默认模型。API Key 的获取方式这里不展开，按官方指引操作就行。配置文件默认在用户目录下的 .codex 文件夹里，文件名是 config.toml。如果这个文件不存在，需要手动创建。
配置文件的基本结构是这样的：
model = "默认模型名称" api_key = "你的密钥" [proxy] enabled = false [session] persist = true max_history = 50这里解释一下几个关键项。model 是默认使用的模型，可以填官方模型也可以填第三方模型名称。api_key 是认证凭证。proxy 部分如果不需要就关掉。session 部分控制会话持久化，persist 设为 true 表示会话历史会保存到本地，max_history 控制保留多少轮对话。
注意：config.toml 的语法比较严格，字符串必须用双引号，布尔值是小写的 true/false，不能写成 True/False。我见过好几次报错都是因为大小写问题。
3.2 接入第三方模型的配置方法
接入第三方模型需要改几个配置项。首先是模型名称，要填第三方平台提供的模型标识。然后是 API 端点，需要指向第三方的接口地址。最后是认证方式，有些平台用 Bearer Token，有些用其他方式，要看具体文档。
配置示例大概长这样：
model = "第三方模型名称" api_base = "https://第三方接口地址/v1" api_key = "第三方平台的密钥" [model_options] temperature = 0.7 max_tokens = 4096这里 api_base 是关键，填错了就连不上。temperature 控制输出的随机性，写代码建议设低一点，0.2 到 0.5 之间比较合适。max_tokens 控制单次输出的最大长度，设太大浪费，设太小不够用，一般 4096 够大多数场景了。
配置完之后要测试一下能不能通。最简单的测试方法是让它写一个 Hello World，如果能正常返回就说明配置没问题。如果报错，先检查 api_base 和 api_key 是否正确，再检查网络能不能访问那个地址。
3.3 计划模式的启用与使用技巧
计划模式在配置文件里有个开关，也可以在执行任务时临时指定。启用之后，Codex 接到任务会先输出一个执行计划，等你确认。
使用技巧方面，我建议在计划阶段仔细看它的步骤。如果发现它理解错了你的意图，这时候纠正成本最低。你可以直接编辑计划，删掉不需要的步骤，或者补充它遗漏的步骤。确认之后再让它执行。
还有一个技巧是给计划模式设置一个步骤上限。比如你估计这个任务最多五步能完成，就设个上限，防止它无限拆解下去。这个在配置里可以设，也可以在任务描述里说“最多五步”。
3.4 会话管理与历史清理的实操
会话管理这块，我建议养成定期清理的习惯。在配置文件里可以设置自动清理的策略，比如超过多少轮就自动截断，或者超过多少天就删除旧会话。
手动清理的话，会话文件存在 .codex/sessions 目录下，按时间排序，删掉不需要的就行。但注意别删正在用的，不然会报错。
另外，如果遇到“无法加载 config.toml”或者“对话串无法继续”这类报错，大概率是配置文件格式问题或者会话文件损坏。排查方法是先备份配置文件，然后逐段注释掉配置项，看是哪一段导致的。会话文件损坏的话，直接删掉对应的会话文件重新开始就行。
4. 新奇玩法：那些不太正经但好用的路子
除了正经的编码任务，Codex 还有一些偏门用法，是我在折腾过程中偶然发现的。这些玩法不一定适合所有人，但确实能解决一些特定场景的问题。
4.1 用 Codex 做代码审查与重构建议
Codex 做代码审查挺好用的，尤其是你写完一个模块之后，让它过一遍。它会指出潜在的问题，比如边界条件没处理、异常没捕获、命名不规范等等。这个比人工审查快，而且不会漏。
用法很简单，把要审查的文件路径给它，说“审查这个文件，指出问题并给出修改建议”。它会输出一份报告，你可以根据报告决定改不改。如果让它直接改，建议先走计划模式，确认它的修改思路没问题再执行。
重构建议也是类似。你可以说“这个函数太长了，帮我拆成几个小函数”，它会给出拆分方案。但要注意，重构之后一定要跑测试，Codex 有时候会改出一些隐蔽的 bug。
4.2 批量处理与自动化脚本生成
批量处理是 Codex 的强项。比如你有一堆文件需要重命名、格式化、提取特定内容，用自然语言描述规则，让它生成脚本，然后跑脚本就行。
我常用的一个场景是批量修改配置文件。比如把项目里所有配置文件中的某个参数从 A 改成 B，手动改容易漏，写脚本又嫌麻烦。直接跟 Codex 说“把 config 目录下所有 toml 文件里的 timeout 从 30 改成 60”，它会生成一个脚本，你确认没问题就跑。
生成脚本的时候建议让它加上 dry-run 模式，先看看会改哪些文件，确认无误再实际执行。这个习惯能避免很多误操作。
4.3 跨语言代码转换与学习辅助
跨语言转换也是我常用的功能。比如把一段 Python 代码转成 Go，或者把 JavaScript 转成 TypeScript。Codex 在这方面表现不错，基本能保持逻辑一致，语法也正确。
学习辅助方面，你可以让它解释一段复杂的代码，或者让它用更简单的方式重写。我有时候看开源项目的源码，遇到看不懂的地方就丢给 Codex，让它用大白话解释一遍。这个比查文档快多了。
还有一个玩法是让它出题。比如你正在学某个框架，让它根据你的水平出几道练习题，做完之后让它批改。这个用来巩固知识挺有效的。
4.4 配置文件调试与报错排查实战
配置文件出问题是最让人头疼的，因为报错信息往往很模糊。我总结了一套排查流程，基本能解决大部分问题。
第一步，检查语法。TOML 的语法错误会导致整个文件加载失败。可以用在线的 TOML 校验工具过一遍，或者用命令行工具校验。
第二步，检查必填项。model 和 api_key 是必填的，缺了会报错。api_base 如果用了第三方模型也是必填的。
第三步，检查网络。如果报“token exchange failed”或者“connection refused”，大概率是网络问题。检查 api_base 能不能访问，密钥有没有过期。
第四步，检查模型名称。如果报“model is not supported”，说明模型名称填错了，或者当前账号没有权限使用这个模型。
下面这个表格整理了我遇到过的典型报错和解决方法：
| 报错信息 | 可能原因 | 解决方法 |
|---|---|---|
| 无法加载 config.toml | 语法错误或文件编码问题 | 用 TOML 校验工具检查，确保 UTF-8 编码 |
| token exchange failed | 密钥无效或网络不通 | 检查密钥是否过期，测试网络连通性 |
| model is not supported | 模型名称错误或无权限 | 核对模型名称，确认账号权限 |
| 对话串无法继续 | 会话文件损坏 | 删除对应会话文件，重新开始 |
| 一直在重新连接 | 网络不稳定或端点错误 | 检查 api_base，切换网络环境 |
提示：修改配置文件之前一定要备份，改坏了还能回滚。我习惯在改之前先复制一份 config.toml.bak，出问题直接还原。
5. 常见问题与排查技巧实录
这一部分把我这半年遇到的高频问题整理一下，每个都附上排查思路和解决方法。有些问题是配置层面的，有些是使用习惯层面的，希望对你有帮助。
5.1 登录与认证类问题的排查
登录问题主要集中在 Token 失效和认证失败这两类。Token 失效的典型报错是“your access token could not be refreshed”，意思是刷新令牌失败了。这种情况一般是因为长时间没使用，或者在其他地方登录导致当前会话被踢下线。解决方法就是重新登录，获取新的 Token。
认证失败的另一类报错是“token endpoint returned status 403 forbidden”，这个通常是密钥权限不够或者账号状态异常。先检查密钥有没有过期，再确认账号有没有欠费或者被封禁。如果都没问题，可能是接口地址填错了，检查 api_base 是否指向了正确的端点。
还有一种情况是“sign-in could not be completed”，这个多半是网络问题。检查一下能不能正常访问认证服务器，如果网络不通，换个环境试试。
5.2 模型加载与配置错误的解决
模型加载错误最常见的就是“model is not supported”。这个报错的意思是当前使用的账号不支持这个模型。可能的原因有几个：模型名称拼错了、账号等级不够、或者这个模型已经下线了。
排查方法是先确认模型名称是否正确，注意大小写和连字符。然后确认账号有没有使用这个模型的权限，有些高级模型需要特定订阅才能用。如果都没问题，可能是模型已经更新了名称，去官方文档查一下最新的模型列表。
另一个常见问题是配置文件里的模型名称和实际调用的不一致。比如配置文件里写的是 A，但任务描述里指定了 B，这时候会以任务描述里的为准。如果 B 不存在就会报错。建议统一在配置文件里管理模型名称，不要在任务里临时指定。
5.3 网络连接与超时问题的处理
网络问题是最难排查的，因为报错信息往往很笼统。常见的报错有“connection timeout”、“error sending request”、“一直在重新连接”等等。
我的排查步骤是这样的：先确认基础网络是否正常，能不能访问其他网站。然后确认 api_base 地址是否正确，有没有多写或者少写路径。接着检查有没有代理设置干扰，如果不需要代理就把代理关掉。最后检查防火墙规则，有些企业网络会拦截特定端口的请求。
如果以上都没问题，可能是服务端的问题。这种情况只能等，或者换个时间段再试。我遇到过几次是服务端在维护，过几个小时就恢复了。
5.4 Token 用量异常增长的排查
Token 用量突然增长，一般有几个原因。一是上下文带太多了，检查一下忽略规则有没有生效，有没有把大文件带进去。二是会话历史太长了，检查一下 max_history 设置，该清理就清理。三是任务描述太模糊，导致模型反复尝试，这个需要优化提示词。
排查方法是先看用量统计，确认是哪个环节消耗最多。然后针对性地调整。如果是上下文问题，就收紧忽略规则；如果是会话问题，就清理历史；如果是提示词问题，就改提示词。
还有一个隐蔽的原因是模型切换。如果你从便宜模型切到了贵模型，用量不变但费用会涨。检查一下当前使用的模型是不是你预期的那个。
5.5 配置文件损坏的应急恢复
配置文件损坏是最紧急的情况，因为会导致整个工具无法使用。我的应急恢复流程是这样的：
首先，找到备份文件。如果你有定期备份的习惯，直接还原就行。如果没有备份，尝试从会话历史或者日志里找回之前的配置内容。
其次，如果找不到备份，就重建配置文件。从最小配置开始，只保留 model 和 api_key 两个必填项，确认能跑通之后再逐步加其他配置。每加一项就测试一次，这样能快速定位是哪一项导致的問題。
最后，把这次的配置存一份备份，并且养成每次修改前备份的习惯。我现在的做法是用 Git 管理配置文件，每次修改都提交一次，出问题直接回滚到上一个版本。
6. 半年使用下来的个人体会
这半年用 Codex 最大的感受是，它确实能提升效率，但前提是你得摸清它的脾气。它不是一个万能工具，有些任务它做得很好，有些任务它做得很糟。关键是知道什么时候用它，什么时候不用它。
省 Token 这件事，说到底就是减少无效交互。把话说清楚、把上下文控制好、把模型选对，这三件事做好了，Token 消耗自然就降下来了。我现在的用量大概是最开始的三分之一，但完成的工作量反而更多了。
新奇玩法这块，我建议抱着玩的心态去试。有些玩法可能不适合你的工作流，但试的过程中你会更了解这个工具的能力边界。知道它能做什么、不能做什么，比学会某个具体技巧更重要。
最后分享一个小习惯：我每周会花十分钟回顾一下这周的 Codex 使用记录，看看哪些任务做得好、哪些做得不好、Token 花在哪里了。这个复盘习惯帮我省了不少钱，也让我对这个工具的理解越来越深。
