不少人订了 Codex 之后遇到同一个困惑：明明没写多少代码，周额度却掉得飞快，回头也说不清钱花哪了。这篇不背数字，只给判断标准和可执行动作——哪些用法在放大消耗、哪些步骤能省、什么时候省额度反而不划算。照着文末清单过一遍就能动手改。
订了 Codex 之后，很多人都会碰到同一个困惑：感觉自己没写多少代码，额度却掉得飞快，回头想不起到底花在了哪里。这篇不背具体数字，只讲判断标准和能直接上手的动作——哪些用法其实在放大消耗、哪些步骤可以省、什么时候省额度反而不划算。照着文末的清单过一遍，就能马上动手改。
先说明一点：省额度不等于把每次对话都压到最短。真正的目标是让每一次调用都产生可验收的产出，返工越少，额度花得越值。下面按任务的整个流程来讲，从看清楚花费在哪，到拆任务、管上下文、处理失败，最后落到一份自查清单。
先搞清楚额度浪费在哪，别急着找技巧
把一次任务的花费拆成三段看：读进来的上下文、模型的输出、失败之后的重试。多数人的浪费集中在第一段和第三段——上下文越贴越多，失败之后反复重发，这两头都在悄悄烧额度。输出往往只占一小部分，不用在这上面抠太细。
- 大段贴日志、把整个文件贴进对话，等于每轮都重新付一次输入的钱，长任务会一轮轮放大
- 报错后原样再发一遍，是最典型的浪费：同样的输入，换来同样的结果
- 判断标准：如果你说不清上一个小时干了什么、大概花了多少，先记账一周再谈省，站内 /usage 和 /resets 可以对照着看
- 可以在每天开工和收工时各看一眼消耗，找到消耗突然变快的时间点，回忆当时在做什么
什么叫合理的消耗，没有统一标准，得看你自己的任务结构。到 /coding-plans 看你所在档位的额度口径，再到 /usage 对照实际消耗，两边的出入就是你要查的地方。具体数字以站内页面当时显示的为准。
任务拆小、指令写死：最省额度的一步
一次任务能不能少花额度，很大程度上在开工那一刻就决定了。把一个大需求拆成几个能一次通过的小任务，每次只给必要文件和明确目标，产出可验收了再进下一个。这样每一轮都是有效消耗，不会做了一半发现方向错了再推翻。
- 写清目标和范围开工前把验收标准、改动范围、不许动哪些文件写进提示，减少来回澄清的轮次。验证方式：第一轮产出就能直接验收，不用反复补问。
- 一次只做一类事改代码、写测试、解释报错别混在同一次对话里，混着做容易产出不合格再返工。验证方式：每一轮产出的东西能独立验收。
- 拆成小步，逐步确认每步做完看一眼结果，确认没问题再进下一步。验证方式：出现偏差时只损失一步，不用回滚一大段。
不适用的场景也要说清楚：探索性调研类任务本来就是摸索着走，硬拆反而增加轮次、拉长周期，这类任务可以放在额度相对充裕的时间段集中做，别为了省而拆。
| 做法 | 常见表现 | 会不会多花额度 |
|---|---|---|
| 一次给全量上下文 | 每轮都重贴整文件 | 会，输入反复计费 |
| 拆成小任务逐步验收 | 每步产出可检查 | 通常更省，返工少 |
| 混着做多类事 | 改完代码又写测试又查报错 | 容易，产出不合格要返工 |
| 探索性任务硬拆 | 来回补信息 | 可能更贵，轮次变多 |
上下文卫生：老对话该收就收
换任务就开新会话，旧对话里的历史都在按输入计费，越攒越贵。需要复用之前的结论时，把结论压缩成几行摘要带过去，比把整段对话搬过去划算得多。这是最容易改、见效也最快的一个习惯。
- 同一仓库反复改时，先分清哪些是稳定背景、哪些是本次的变量，稳定部分能少贴就少贴
- 开会话前想清楚这次要解决什么，会话里只留和这件事相关的内容
- 做完的任务把结论记成简短摘要，下次开新会话直接引用摘要
- 关掉不再需要的上下文，比在旧会话里硬往下接着聊更划算
失败、重试与选型：容易被忽略的隐性消耗
报错之后不要原样重发，先改提示或者补信息再试。盲目重试等于用同样的价钱换同一个错误。简单任务也别一律上最重的方式，重复性改动、格式化、小补丁这类活换个更轻的处理路径，能省下不少。
- 逻辑错误
- 原样重试没用，必须改提示或补信息，否则就是双倍付费
- 超时或限流
- 重试合理，别和逻辑错误混为一谈
- 连续多次不通过
- 停下来人工拆解，比继续试更省钱
- 重复性小改动
- 换更轻的处理路径，不必动用重的方式
判断标准很简单：同一个任务连着两三次不通过，就该停手，人工拆解问题出在提示、任务粒度还是需求本身。继续试只会让消耗成倍往上走。这里说的重和轻，具体哪种方式对应什么消耗，到 /tools/speed-test 和站内相关说明页核对当时的数字，别凭印象选。
一份可以照着过的自查清单
上面的判断标准落到日常，就是一张固定的清单。每周花几分钟过一遍，比等到额度见底再找原因有用得多。
- 每周固定一次：翻 /coding-plans 里你所在档位的额度口径，再对一遍 /usage 的实际消耗
- 每次开工前问三句：目标写清了吗、范围限定了吗、验收标准定了吗
- 把反复失败的任务记下来，周末复盘是提示问题还是任务粒度问题
- 算一下省下来的时间值不值：额度省了但工期拖了，这个账要一起算
常见问题
把任务拆小就一定更省额度吗？
不一定。拆得太碎会让每轮都重复带一遍背景说明，输入成本反而涨。判断标准是拆完之后每个子任务能不能一次通过、背景能不能大幅精简；如果拆完还要反复补上下文，就不如合并成一个中等任务。
开新会话省额度，会不会丢之前的上下文导致返工？
会，所以要分情况。换任务、话题不相关时开新会话，能立刻止住历史累积的输入消耗；同一条设计思路的多轮推演则留在原会话里更合适，中途清空往往要重新解释一遍，花的钱不比省下来的少。
额度掉得快是不是账号有问题？
先别怀疑账号。按本文顺序自查：任务是否贴了过量上下文、有没有反复失败重试、有没有把重活放在最贵的方式上。三项都排除后，再去 /resets 看重置节奏、去站内对应套餐页核对当期额度口径，最后才考虑联系渠道确认。
