摘要：Codex用量消耗太快，未必只是模型选贵了。本文从模型分工、推理强度、上下文、重复读取和验证策略出发，整理7个能直接落地的优化方法。

刚开始用Codex时，很容易形成一种习惯：不管什么任务，都选能力最强的模型；觉得任务重要，再把推理强度调到最高。

这样做当然省心，但用一段时间后，另一个问题就出来了——用量掉得很快。

再翻任务记录，会发现消耗往往不只发生在“写代码”这一步：Codex读了一遍项目，过几轮又重新找入口；刚跑完全量测试，改了一个小地方，又从头跑一遍；任务方向已经变了，却还带着前面几十轮对话继续做。

于是网上开始流行一种省用量的方法：

先让最强模型分析和规划，再让便宜模型照着计划执行。

这个方法有用，但并不是所有任务都适合。计划交接得不好，后面的模型还是要重新理解项目；执行过程中一旦发现新问题，它还可能反复读取、尝试和返工，最后并没有省下多少。

这篇文章想解决的，就是这件更具体的事：怎样减少Codex没有产生成果的消耗，同时又不因为省模型而增加返工。

---

一、用量到底花在了哪里

先把一个误区拿掉：Codex的消耗并不等于“最终生成了多少行代码”。

在一次完整任务里，下面这些内容都会占用上下文或产生新的模型输出：

• 你的任务说明、项目规则和历史对话；
• Codex读取的代码、配置、日志和命令输出；
• 模型用于分析、规划和验证的内容；
• 修改失败后的重新定位和再次尝试；
• 测试、构建和检查产生的大段结果；
• 任务方向改变后仍然被带入的旧上下文。

所以有时候只改了三行代码，消耗却不小。真正占空间的，可能是前后几轮项目扫描、几百行报错信息和一次又一次的重新确认。

OpenAI当前把GPT-5.6系列分成三个主要档位：Sol面向复杂推理和编码，Terra强调能力与成本的平衡，Luna面向成本敏感、高频任务。OpenAI模型目录

在API计费口径下，三者目前的文本价格如下：

模型	适合的官方定位	输入价格/百万Token	缓存输入	输出价格/百万Token
GPT-5.6 Sol	复杂专业工作、复杂推理与编码	$4.00	$0.40	$20.00
GPT-5.6 Terra	能力与成本平衡	$2.00	$0.20	$12.00
GPT-5.6 Luna	成本敏感、高频任务	$0.20	$0.02	$1.20

价格来源：OpenAI模型对比。数据核对时间为2026年8月25日，后续可能调整。

这里要特别说明：**上表是API按Token计费的价格，不等同于ChatGPT或Codex订阅套餐中的额度扣除规则。**不同账号能选择哪些模型，也以你实际看到的界面和套餐为准。但无论按API费用还是套餐用量计算，减少无关上下文、重复输出和无效返工，方向都是一致的。

---

二、“强模型规划，便宜模型执行”什么时候才省

这个方法适合三类任务：

1. 目标已经明确；
2. 修改范围能够提前圈定；
3. 执行结果可以用测试、构建或明确清单验证。

例如：已经确定要把某个页面的请求层迁移到新接口，涉及哪些文件、字段怎么映射、验收命令是什么都很清楚。可以先让Sol或Terra识别依赖和风险，再把一份完整的执行说明交给成本更低的模型。

但如果任务是下面这些情况，机械分工往往不划算：

• 第一次接触一个陌生仓库，入口和架构都还没找到；
• Bug无法稳定复现，根因未知；
• 需求本身模糊，需要边做边确认；
• 跨多个模块重构，执行时大概率会发现新约束；
• 涉及权限、安全、数据迁移或发布风险。

这类任务里，“规划”和“执行”不是完全分开的。执行过程中发现的新证据会反过来改变计划。强行换模型，可能只是让后一个模型重新读一遍。

省用量的关键不是每一步都选最便宜的模型，而是选择能够较高概率一次完成当前任务的最低成本模型。

---

三、不同任务，模型应该怎么分工

下面这张表不是绝对规则，更适合作为起步配置。先按任务风险选择，再根据实际结果升级或降级。

任务类型	建议起步	推理强度	典型任务
边界非常清楚、低风险、重复性高	Luna	low / medium	格式整理、固定字段替换、局部文案、明确的小改动
常规开发和大部分日常工作	Terra	medium	功能开发、普通Bug、跨文件修改、测试和文档
未知较多、判断成本高	Sol	medium / high	陌生项目、架构设计、疑难故障、复杂重构
高风险、质量优先	Sol	high / xhigh，必要时再提高	安全审查、数据迁移、发布前关键检查

OpenAI当前的建议也是把medium作为均衡起点，延迟敏感任务可以从low开始；只有实际结果证明更高推理强度有明显收益时，再使用high或xhigh，max留给最困难、质量优先的工作。OpenAI GPT-5.6使用指南

同样，Pro模式会让模型在一次请求里投入更多工作，同时增加延迟和Token消耗。它适合高价值的困难任务，不适合被当成所有日常任务的默认开关。

如果你的入口没有Sol、Terra、Luna，也不用卡在名字上。把现有模型按“高能力”“平衡”“低成本”分成三档，再套用同样的判断就可以。

---

四、真正能减少无效消耗的7个使用习惯

习惯1：按任务难度选模型，不要按工作阶段机械切换

“规划用最强、执行用最便宜”听起来清楚，但工作阶段并不能代表难度。

有些计划很简单，执行反而困难；有些任务根本不需要单独规划。更实用的判断是先问四个问题：

• 目标是否明确？
• 文件范围是否清楚？
• 出错后是否容易恢复？
• 有没有客观的验收方法？

四项都明确，才适合交给低成本模型。只要其中两三项还不确定，就先用Terra或Sol把未知信息查清楚。

如果确实需要换模型，交接内容至少包含：

任务目标：最终要完成什么
已确认范围：允许修改哪些目录和文件
当前结论：已经定位到什么，证据是什么
执行步骤：按什么顺序修改
硬性边界：哪些内容不能动
验收方法：运行哪些命令，预期看到什么
未决问题：遇到什么情况必须停止并汇报

没有这份交接，便宜模型接到的不是“执行任务”，而是“重新理解任务”。

习惯2：推理强度从够用开始，不默认拉到最高

不少人选对了模型，却又把所有任务都调成最高推理强度。改一个标题、整理一个JSON、补一条测试，也让模型做长时间探索。

可以先用一个简单规则：

• low：范围明确、结果容易检查；
• medium：大部分日常任务；
• high / xhigh：根因未知、跨模块、错误代价较高；
• max / Pro：确实复杂，而且质量提升值得额外消耗。

不要凭感觉比较。找三到五个自己经常做的任务，分别跑一次当前配置和低一级配置，记录是否一次完成、用了多久、有没有返工。能稳定通过验收，就没必要继续往上加。

习惯3：第一句话就给范围，别让它先扫完整个仓库

下面两种任务写法，消耗可能差很多。

比较模糊：

帮我看看登录页为什么有问题，修一下。

范围更清楚：

问题只出现在Web端登录页：点击“发送验证码”后按钮一直处于加载状态。

请先检查：
- apps/web/src/pages/login
- packages/api/src/auth
- 最近一次相关Git Diff

先复现并定位根因，只修改与验证码请求状态有关的文件。
不要调整页面样式、路由和其他登录方式。
验收：运行auth相关测试，并手动验证请求失败后按钮可以恢复。

第二种写法不一定更长很多，但它告诉Codex从哪里开始、哪里结束、怎样算完成。模型不需要先在整个项目里猜“问题”指什么。

OpenAI官方模型指南也建议精简重复指令和无关工具说明。在一组内部编码Agent评测中，精简系统提示后，总Token下降约41%—66%，成本下降约33%—67%；官方同时强调，这些数字只能作为方向参考，具体效果仍要用自己的任务验证。OpenAI GPT-5.6使用指南

注意，“精简”不是把任务缩成一句话。应该删的是重复背景、无关规则和无用示例，不是目标、边界和验收条件。

习惯4：目标明显变化时，及时开新任务

一个常见场景是：开始让Codex修登录Bug，修完以后顺便改页面，再顺便补文档，最后又让它检查整个项目。

任务看起来一直在继续，实际上目标已经换了三次。前面的报错、尝试、文件内容和讨论仍然留在上下文里，后面的每一轮都可能继续携带这些历史。

以下情况适合新开任务：

• 从排查问题转成开发新功能；
• 从后端修改转成无关的页面设计；
• 当前目标已经验收完成；
• 前面讨论了多个方案，最终只采用其中一个；
• 对话中已经出现大量失效日志和旧文件内容。

新任务不等于从零开始。结束旧任务前，让Codex生成一段交接摘要即可：

请生成一份用于新任务的交接摘要，只保留：
1. 当前目标与已经完成的结果；
2. 实际修改过的文件；
3. 仍然有效的约束和技术决定；
4. 已通过的验证；
5. 尚未解决的问题。

不要复制完整聊天记录、长日志和已经否定的方案。

习惯5：第一次读取后留下“状态快照”，减少反复找入口

Codex重复读取不一定是它在做无用功。有些时候文件刚被修改，重新读取是必要的；有些时候它需要核对引用位置，不能只凭记忆修改。

真正应该减少的是：项目状态没有被整理，导致每次继续工作都重新搜索同一批入口。

第一次完成项目探索后，可以要求它写一份简短状态快照：

请把本轮调查结果整理成“任务状态快照”，控制在800字以内：
- 入口文件和调用链；
- 已确认的根因与证据；
- 本次允许修改的文件；
- 已排除的方向；
- 下一步动作；
- 需要重新读取文件的触发条件。

后续优先根据快照继续；只有文件已变化、证据冲突或即将修改具体代码时，才重新读取对应文件。不要再次扫描无关目录。

这里不能写成“禁止重新读取”。修改代码前确认最新内容、生成补丁后核对结果，都是合理操作。目标是限制无范围的重复扫描，不是让模型闭着眼睛改。

习惯6：验证要分层，不要每改一点就跑全量检查

完全不跑测试看起来最省，返工时通常最贵；每次改一行都跑全量测试，也没有必要。

更合理的是三层验证：

1. 修改过程中：只跑目标模块的测试、类型检查或最小复现；
2. 功能完成后：跑受影响范围的测试和构建；
3. 准备提交或发布前：再执行项目要求的完整验收。

例如修改一个格式化工具，不必每保存一次就构建整个前后端；但在最终提交前，仍要检查它有没有影响调用方。

可以直接把验证层级写进任务：

修改过程中只运行与auth模块直接相关的测试。
确认修复后，再运行Web端类型检查和构建。
除非局部验证失败且根因指向其他模块，不要提前运行全仓库测试。
每条命令只保留失败摘要和关键证据，不要在回复中重复粘贴完整成功日志。

习惯7：给失败循环设置停止条件

最浪费的一类消耗，不是一次复杂分析，而是Codex在同一个错误上循环：执行命令、读取报错、改一点、再次执行，又回到原来的报错。

任务开始时可以明确停止条件：

如果同一验证连续失败两次，不要继续试探性修改。
请暂停并汇报：
1. 两次失败分别做了什么；
2. 不变的错误证据；
3. 当前最可能的根因；
4. 缺少的权限、依赖、信息或外部条件；
5. 建议我确认的下一步。

未经确认，不扩大修改范围，不安装新依赖，不降低测试标准。

这个约束并不会削弱Codex的自主性。它只是把“持续推进”和“无证据地反复尝试”分开。

---

五、一段可以直接复制的“低消耗执行约定”

如果不想每次把七条重新写一遍，可以把下面这段放进项目的AGENTS.md，或者按任务临时粘贴。

请按低消耗、可验证的方式完成本任务：

1. 先确认目标、允许修改的范围和验收方式；信息足够时不要重复追问。
2. 优先读取与任务直接相关的文件，不扫描无关目录。
3. 第一次调查后保留简短状态摘要，记录入口、证据、边界和下一步。
4. 文件未变化、证据未冲突时，不要无理由重复读取同一批内容。
5. 不重复输出长日志；只保留失败摘要、关键行和结论依据。
6. 修改过程中运行最小相关验证，完成后再扩大到受影响范围。
7. 不为了“顺手优化”扩大任务范围。
8. 同一失败连续出现两次时暂停，汇报证据和阻塞原因，不继续试探性修改。
9. 如果任务目标发生明显变化，先生成交接摘要，再建议开启新任务。
10. 最终只汇报实际改动、验证结果、残余风险和需要人工决定的事项。

这段约定不要与项目里已有的规则重复堆叠。同一件事写三遍，不但没有更安全，反而会继续占用上下文。

---

六、三个例子：到底应该怎么选

场景1：修改20个配置文件里的同一字段

范围明确、规则固定、可以通过搜索和Diff验证。适合成本较低的模型，配合low或medium推理强度。先备份或只生成Diff，再批量执行。

没有必要先单独调用最强模型写一份长规划。

场景2：给已有页面增加一个常规筛选功能

需要理解组件、状态和接口，但风险可控。可以直接从Terra和medium开始，让它完成分析、修改和局部验证。

如果中途发现筛选逻辑分散在多个服务、涉及缓存一致性，再升级模型或推理强度。

场景3：线上偶发数据错乱，无法稳定复现

这类任务的主要成本在判断，不在敲代码。适合让Sol先建立证据链、梳理并发和数据流，再决定是否修改。

如果已经得到明确根因和可执行方案，可以把边界清楚的实现部分交给Terra；如果执行仍会改变判断，就不要为了换模型强行切断上下文。

---

七、几种看起来省、实际可能更贵的做法

全程使用最便宜模型

简单任务确实合适；复杂任务如果要多轮返工，节省的单次成本很容易被重复读取和修复抵消。

把提示词压缩到一句话

短不等于省。缺少范围和验收标准，Codex可能花更多轮去猜。

禁止重新读取文件

这会让模型基于旧内容修改。应该限制无关扫描，而不是禁止必要核对。

为了省用量不运行测试

它只是把验证成本推到了更晚。改动越接近发布，发现问题后的返工越贵。

一个任务一直聊到底

连续上下文确实方便，但目标改变后，旧信息会逐渐变成负担。完成一个独立目标后及时收口，通常更清楚。

---

八、人离开电脑后，别让任务因为一次确认被迫重来

还有一种浪费不完全来自模型选择：Codex已经读完项目、跑到关键步骤，却在等待一个权限确认、范围选择或测试结果。人正好离开电脑，任务就停在那里。

如果回来后直接重新开一轮，很可能又要解释背景、重新读取文件和恢复状态。

这也是我们开发 Linco Bridge 的原因之一。它可以把电脑上运行的Codex、Claude Code、Hermes等本地Agent会话延伸到手机端，让你查看进度、回复问题或继续会话。

需要说清楚：**Linco Bridge本身不会神奇地降低Token价格。**它解决的是跨端跟进和人工确认，减少因为人暂时离开电脑而产生的中断、重启和重复解释。

• GitHub：lincotalk/linco-bridge
• 在线体验：bridge-demo.lincotalk.com
• 微信小程序：搜索 Agent桥接器

如果它刚好解决了你的使用场景，欢迎在GitHub点一个Star。连接过程中遇到问题，也可以提交Issue或在评论区交流。

---

九、Codex 实战系列

如果你正在重新整理自己的Codex工作流，可以继续看这些内容：

• 第一次让 Codex 接手陌生项目，我不会先让它写代码：7 步完成项目接管
• AGENTS.md 到底怎么写？给 Codex 一份真正有用的项目说明书
• Codex 改完代码，怎么判断能不能提交？一套可直接复制的验收流程
• Codex 改完代码，文档还要自己补？从 Git Diff 生成 CHANGELOG 和发布说明
• Codex 每次都要重新教？Prompt、AGENTS.md、Skills、MCP 到底怎么选
• Codex 修 Bug 总是越改越多？把复现、定位、修复、回归测试做成一个 Skill

Linco Bridge 开源系列

• Linco Bridge 开源：在手机端续接 Codex、Claude Code、Hermes 等本地 AI Agent
• 手机端续接 Codex 实战：从安装 linco-connect 到跑通第一个跨端会话
• cc-connect 已经很强了，我们为什么还要做 Linco Bridge？
• 离开电脑后，怎么继续跟进 Codex 任务？国内用户的 5 种远程方案

---

回头看，真正昂贵的通常不是“用了强模型”这件事，而是强模型被用来反复读取无关内容，便宜模型又因为能力或上下文不足不断返工。

如果你也遇到过Codex重复读取、反复测试或者在同一个报错上循环，可以把具体场景留在评论区。比起只讨论哪个模型最省，看看任务为什么会重复，往往更有用。