1. 半年迭代后Codex 到底变成了什么样用了大半年 Codex从最初把它当成一个“能补全代码的编辑器插件”到后来把它塞进日常开发流里当半个结对搭档中间踩过的坑、省下的时间、浪费掉的 Token加起来能写一本小册子。这次想聊的不是官方文档里那些“支持多语言、智能补全”的场面话而是这半年里我自己反复验证过的、真正能落地的省 Token 技巧以及几个大多数人没注意到的玩法。如果你正在用 Codex或者刚装好还在摸索阶段又或者被 Token 消耗速度吓到过那这篇内容应该能帮你少走一些弯路。先说清楚一件事Codex 这类工具的核心成本不在订阅费而在Token 消耗。很多人用着用着发现额度不够第一反应是“是不是我代码写太多了”其实大部分浪费都来自交互方式本身。同样一个需求不同的提问结构、不同的上下文管理方式Token 消耗能差出三到五倍。这不是玄学是实打实的工程问题。下面我会把省 Token 的四个核心技巧拆开讲每个都附带我自己的实测数据和操作细节然后再说五个我觉得挺有意思、但讨论度不高的玩法。2. 省 Token 的四个核心技巧2.1 技巧一用“锚点式提问”替代“上下文倾倒”很多人用 Codex 的习惯是打开一个文件选中一大段代码然后问“这段代码有什么问题”。这种做法在 Token 消耗上非常奢侈因为 Codex 需要把你选中的全部内容作为输入 Token 处理哪怕其中百分之八十的代码跟你的问题无关。我自己的做法是锚点式提问只给关键行号、函数名和报错信息让 Codex 自己去定位。比如不说“帮我看看这个文件哪里有问题”而是说“processOrder函数在第 47 行返回了 undefined调用方在第 112 行期望一个对象帮我分析可能的原因”。这样输入 Token 可能只有原来的五分之一但输出质量反而更高因为模型不需要在一堆无关代码里“找重点”。实测下来一个 300 行的文件全选提问平均消耗 4200 个输入 Token锚点式提问平均消耗 780 个。按每天 50 次交互算一天就能省下十几万 Token。这个差距在月度账单上非常明显。注意锚点式提问的前提是你自己对代码结构有基本了解。如果完全不知道问题出在哪可以先让 Codex 做一次“全局扫描”但扫描完要立刻把上下文清掉不要让它一直挂着。2.2 技巧二会话隔离别让一个对话跑一整天Codex 的会话机制有个特点同一个对话里的历史消息会持续累积每次新提问都会把之前的全部内容作为上下文重新处理。这意味着你聊得越久单次提问的 Token 成本越高。我见过有人一个对话从早开到晚到后面每问一句话都要消耗上万 Token就是因为历史包袱太重。我的做法是按任务隔离会话。修 bug 开一个会话写新功能开另一个代码审查再开一个。每个会话完成后直接关闭不留恋。这样每次新会话的初始上下文都是干净的单次 Token 消耗稳定在低位。具体操作上我会在会话开头用一句话设定角色和范围比如“你现在是一个 Python 后端审查助手只关注这个文件里的异步逻辑”。这句话本身消耗很少但能让后续所有回答都聚焦在范围内避免模型发散导致的多轮追问。有个细节值得注意关闭会话不等于删除历史。我习惯把重要的会话导出成 Markdown 存到本地按项目分类。这样既保留了可追溯性又不会让活跃会话变得臃肿。导出这个动作本身不消耗 Token但能帮你建立自己的知识库。2.3 技巧三输出格式约束减少“废话 Token”Codex 默认的输出风格偏解释型喜欢先复述问题、再分析原因、最后给方案。这种风格对人友好但对 Token 不友好。如果你只是想要一个结果那些复述和分析全是浪费。我通常会在提问末尾加一句格式约束比如“直接给代码不要解释”或者“用表格列出三个方案每行不超过 20 字”。这样输出 Token 能压缩到原来的三分之一左右。别小看这个比例输出 Token 的单价通常比输入 Token 更高省下来的都是真金白银。更进一步的技巧是用结构化模板约束输出。比如我会预先定义一个简单的 JSON 结构让 Codex 按这个结构填充{ issue: 问题描述, cause: 根本原因, fix: 修复代码, risk: 潜在风险 }这样不仅 Token 少而且输出可以直接被脚本解析省去了人工提取信息的时间。对于需要批量处理的任务这个技巧的收益非常明显。2.4 技巧四缓存常用上下文避免重复输入有些上下文你会反复用到比如项目的目录结构、核心数据模型的字段定义、常用的工具函数签名。每次新会话都重新输入一遍累积起来是很大的浪费。我的做法是建一个上下文缓存文件把这些高频信息整理成精简的 Markdown需要的时候直接粘贴。注意是精简版不是把整个文件贴进去。比如数据模型只保留字段名和类型去掉注释和空行目录结构只保留三层深层目录用省略号代替。这个缓存文件我维护了大概两个月现在覆盖了日常开发中百分之七十的重复上下文需求。每次新会话只需要粘贴对应的片段几秒钟的事但省下的 Token 相当可观。提示缓存文件要定期更新尤其是项目结构发生变化时。过期的上下文比没有上下文更糟糕会导致 Codex 给出基于错误前提的建议。3. 五个新奇玩法大多数人没试过3.1 玩法一把 Codex 当“代码考古工具”用接手老项目时最头疼的不是写新代码而是理解前人留下的逻辑。注释缺失、命名混乱、层层嵌套读起来像考古。我试过用 Codex 做代码考古效果出乎意料地好。具体做法是选中一个复杂的函数然后问“这个函数在业务上解决了什么问题用一句话概括然后列出它依赖的外部状态”。Codex 会帮你把散落在各处的逻辑串起来给出一个人类可读的摘要。这个摘要不一定百分百准确但能帮你快速建立心智模型比逐行读快得多。我最近用这个方法梳理了一个五年前的老模块原本预计要花两天实际半天就摸清了主要逻辑。当然关键路径还是要自己验证但至少知道该往哪个方向验证了。3.2 玩法二用 Codex 生成测试用例的“边界清单”写单元测试时最怕漏掉边界情况。我习惯让 Codex 先列边界清单再写测试代码。提问方式是“这个函数接收三个参数分别是用户 ID、订单金额、优惠券码列出所有可能的边界情况和异常输入用列表形式。”Codex 给出的清单通常比我自己的更全面尤其是那些“看起来不可能但理论上会发生”的情况。比如金额为负数、优惠券码为空字符串、用户 ID 是特殊字符等。拿到清单后我再筛选出真正需要覆盖的然后让 Codex 按清单生成测试代码。这个玩法的价值在于把思考过程和实现过程分开。清单阶段只关注“有哪些情况”代码阶段只关注“怎么测”两个阶段分开后Token 消耗更低质量反而更高。3.3 玩法三跨语言翻译时的“语义对齐”检查Codex 在跨语言翻译上表现不错但直接翻译容易丢失语义细节。我的做法是分两步先让 Codex 用目标语言重写逻辑再让它对比原语言和目标语言的实现列出“行为差异清单”。比如把一段 Python 翻译成 Go第一步得到 Go 代码第二步问“这段 Go 代码和原 Python 代码在异常处理、并发行为、类型转换上有什么差异”。Codex 会指出比如 Python 的异常捕获范围更宽、Go 的 goroutine 调度时机不同等细节。这个检查步骤消耗的 Token 不多但能避免很多“翻译正确但行为不对”的坑。尤其是涉及并发和错误处理时跨语言的语义差异非常微妙人工检查容易漏。3.4 玩法四用 Codex 做“命名一致性审计”项目大了之后命名不一致是个隐形杀手。同一个概念在不同模块叫不同名字读代码时要在脑子里做映射非常消耗精力。我试过让 Codex 做命名审计把几个相关文件的函数签名和变量名贴进去问“这些命名中哪些指的是同一个概念但用了不同词汇”。Codex 会给出一个映射表比如“fetchData、loadData、getData在这三个文件里都指从远端拉取数据”。拿到映射表后你可以决定是否统一命名。即使不统一至少心里有数了。这个玩法适合在重构前做一次能帮你发现很多“以为已经统一了其实没有”的地方。3.5 玩法五把 Codex 当“技术方案对比助手”做技术选型时我习惯让 Codex 列对比表。但直接问“A 和 B 哪个好”得到的答案往往很泛。我的做法是限定维度先自己列出三个最关心的维度比如“学习成本、社区活跃度、与现有技术栈的兼容性”然后让 Codex 按这三个维度对比。更进一步我会让 Codex 给出“在什么场景下选 A、在什么场景下选 B”的判断规则。这个规则不一定完全准确但能帮你理清决策逻辑。我最近在选消息队列时用了这个方法Codex 给出的判断规则是“如果团队已经有 Kafka 运维经验选 Kafka如果追求轻量且能接受功能裁剪选 NATS”这个规则后来被证明很有参考价值。4. 实操中的常见问题与排查4.1 Token 消耗异常增长的排查思路如果你发现 Token 消耗突然变快按以下顺序排查排查项可能原因解决方法会话历史单个会话持续太久历史累积关闭旧会话按任务开新会话上下文范围选中了过多无关代码改用锚点式提问只给关键信息输出格式未约束输出模型自由发挥添加格式约束要求精简输出重复输入每次新会话都粘贴相同上下文建立缓存文件按需粘贴模型选择用了高消耗模型处理简单任务简单任务切换轻量模型这个表我贴在显示器旁边每次觉得消耗快了就对照检查一遍基本能定位到原因。4.2 会话隔离的实操细节会话隔离说起来简单做起来有几个细节要注意。第一关闭会话前把关键结论复制出来不要依赖历史记录。第二新会话开头用一句话设定范围但不要写太长否则又变成上下文倾倒。第三如果任务确实需要跨会话用缓存文件传递关键信息而不是让两个会话互相引用。我自己的习惯是每个会话结束后花十秒钟写一句“本次结论”存到本地笔记里。这个动作看起来多余但一周后回头看能帮你快速回忆起当时的决策逻辑。4.3 输出格式约束的边界格式约束不是越严格越好。如果约束太死Codex 可能为了满足格式而牺牲内容质量。我的经验是约束“结构”而不是“字数”。比如要求“用三个要点回答”比要求“回答不超过 50 字”更好因为前者保留了信息完整性后者可能导致关键信息被截断。另外格式约束要放在提问的末尾不要放在开头。放在末尾时模型已经理解了问题格式约束只是对输出的最后一道加工。放在开头则可能干扰模型对问题本身的理解。5. 一些个人体会用了大半年 Codex最大的感受是工具的效率上限取决于使用者的提问质量。同样的功能有人用起来觉得鸡肋有人用起来觉得离不开差别就在提问方式上。省 Token 的技巧本质上不是“抠门”而是逼自己把问题想清楚。当你能够用一句话说清楚要什么的时候Token 消耗自然就降下来了。另外新奇玩法的价值不在于“炫技”而在于帮你打开思路。Codex 不只是一个补全工具它可以做代码考古、命名审计、方案对比这些用法在官方文档里不会写但实际工作中非常实用。我建议你先从省 Token 的技巧开始练等交互方式稳定了再尝试这些玩法效果会更好。最后分享一个小习惯我每周会花十分钟回顾一下这周的 Codex 会话记录看看哪些提问方式效果好、哪些浪费了 Token。这个复盘习惯坚持了两个月后我的 Token 消耗下降了大概百分之四十而输出质量反而提升了。工具是死的用法是活的多琢磨总会有收获。