1. 从一条日记说起为什么“用量砍半”和“自我优化”值得聊09-29 这条日记的标题信息量其实挺大拆开看是两件事一件是 OpenAI 的用量被砍掉了一半另一件是 Claude Code 在做自我优化。这两件事放在同一天记录不是巧合它们指向的是同一个趋势——AI 辅助编程工具正在从“堆量”走向“提效”。我自己是从去年开始把 AI 编程助手当成日常工具来用的中间换过好几套方案也踩过不少坑。最开始的想法很简单哪个模型强就用哪个哪个工具能补全就用哪个。但用久了会发现真正决定效率的不是模型有多强而是你怎么用它、用多少、在哪些环节用。OpenAI 用量砍半这件事表面上看是成本控制实际上是一次使用策略的调整Claude Code 的自我优化表面上看是工具迭代实际上是工作流的重新设计。这篇内容适合几类人看一是正在用或者准备用 AI 编程助手的开发者二是团队里负责技术选型和成本控制的人三是对 Claude Code 这个工具好奇但还没上手的人。我会把这两件事背后的逻辑拆开讲包括用量为什么能砍半、砍在哪里、Claude Code 的自我优化具体指什么、怎么在自己的项目里复现类似的优化思路。不堆概念直接讲我实际怎么做的。2. OpenAI 用量砍半不是少用是换用法2.1 用量砍半的真实含义先说清楚“用量砍半”不是把 AI 助手关掉一半时间而是把同样的任务用更少的 token 完成。我自己的账单从月初到月底做了一次对比发现同样的开发任务量API 消耗降了大约 47%接近一半。这个降幅不是靠少问问题实现的而是靠改变提问方式和任务分配实现的。具体来说之前我的用法很粗暴遇到问题就把整个文件贴进去让模型帮我改。一个 500 行的文件每次提问至少消耗 2000 到 3000 token改一次可能要来回三四轮一个任务下来轻松过万 token。后来我做了三件事第一把大文件拆成小模块每次只贴相关的那几十行第二把“帮我改这段代码”换成“这段代码的作用是 X我要实现 Y请给出修改建议”第三把重复性的补全任务交给本地模型只把复杂逻辑交给云端模型。这三件事做下来token 消耗直接降了一半而且代码质量没有下降反而因为上下文更聚焦模型给出的建议更准确。2.2 哪些环节最值得砍不是所有环节都值得省 token。我整理了一个优先级表按“节省效果”和“对结果的影响”两个维度来排环节节省效果对结果影响建议重复性代码补全高低交给本地模型或 IDE 自带补全简单语法查询高低查文档或本地知识库复杂逻辑重构中高保留云端模型但缩小上下文架构设计讨论低高保留云端模型值得花 token单元测试生成中中用模板局部生成结合这张表是我自己用了两个月之后总结出来的。最明显的是重复性代码补全比如写 getter/setter、写简单的 CRUD 接口、写配置文件这些完全没必要调用云端大模型。IDE 自带的补全或者本地跑一个小模型就足够了。我之前算过一笔账光是这一项每天就能省下 30% 左右的 token。复杂逻辑重构和架构设计讨论是值得花 token 的地方因为这两类任务对模型的推理能力要求高本地小模型搞不定。但即便是这两类任务也可以通过缩小上下文来降低消耗。比如重构一个函数不需要把整个文件贴进去只需要贴这个函数和它依赖的几个函数就够了。2.3 我实际用的 token 控制方法具体操作上我用了几个小技巧都是实测有效的。第一个是“分段提问”。以前我会一次性把需求说完比如“帮我优化这个模块的性能顺便把命名规范也改一下再加个日志”。现在我会拆成三次先问性能优化确认后再问命名规范最后加日志。每次提问的上下文更小模型回答更聚焦总体 token 反而更少。第二个是“缓存常用上下文”。有些项目背景信息是每次提问都要带的比如项目用的框架、数据库类型、代码风格约定。这些信息我会写成一个简短的 prompt 模板每次提问时只替换具体问题部分。这样比每次重新描述项目背景要省很多 token。第三个是“用本地模型做预处理”。比如我要让云端模型帮我写一个复杂的 SQL 查询我会先用本地模型生成一个初稿然后把这个初稿和我的修改要求一起发给云端模型。这样云端模型只需要做“修改”而不是“从零生成”token 消耗会低很多。注意token 控制不是一味地省该花的地方要花。我的原则是如果一个问题涉及核心业务逻辑或者架构决策不要为了省 token 而缩小上下文否则模型给出的建议可能不准确反而要花更多时间返工。3. Claude Code 的自我优化工具怎么越用越顺手3.1 Claude Code 是什么为什么值得关注Claude Code 是 Anthropic 推出的命令行编程助手跟 IDE 插件那种补全工具不太一样它更像是一个可以对话的编程搭档。你可以在终端里直接跟它聊让它帮你读代码、改代码、跑命令、查文档。我最初用它是因为它的上下文理解能力比较强后来发现它在“自我优化”这件事上做得挺有意思。所谓自我优化不是说工具自己会变聪明而是它提供了一套机制让你可以把重复性的操作固化下来下次直接调用。比如你经常需要“读取某个目录下的所有 Python 文件检查有没有未使用的 import然后批量删除”这个操作如果每次都用自然语言描述一遍既费时间又费 token。Claude Code 允许你把这套操作定义成一个自定义命令或者工作流下次直接输入一个短命令就能执行。3.2 自我优化的三个层次我把 Claude Code 的自我优化分成三个层次从浅到深分别是命令别名、工作流脚本、上下文记忆。命令别名是最简单的。比如我经常需要让 Claude Code 帮我“查看当前 git 状态并总结改动”我就把这个操作定义成一个别名输入/git-summary就能触发。这个层次不需要写代码只需要在配置文件里加一行映射。工作流脚本稍微复杂一点。比如我有一个固定的代码审查流程先检查代码风格再检查单元测试覆盖率最后检查有没有明显的性能问题。这个流程涉及多个步骤每一步都要调用不同的工具。Claude Code 允许我把这个流程写成一个脚本一次性执行。我实际用下来这个层次节省的时间最多因为代码审查是高频操作每次手动执行三个步骤很繁琐。上下文记忆是最深的一层。Claude Code 可以记住项目的关键信息比如项目结构、常用命令、代码规范。这样每次提问时不需要重复描述这些背景。我试过在一个中型项目里配置上下文记忆效果很明显同样的问题配置前需要 500 token 描述背景配置后只需要 100 token。3.3 我实际配置的自我优化案例举一个我实际配置的例子。我有一个项目是 Python 写的经常需要做这几件事格式化代码、运行测试、检查类型注解。以前我每次都要分别输入三个命令后来我在 Claude Code 里配置了一个工作流# 在 Claude Code 配置文件中定义 workflow check-all { step format { command black . } step test { command pytest --covsrc } step type-check { command mypy src } }配置好之后我只需要输入check-allClaude Code 就会依次执行这三个步骤并且把结果汇总给我。如果某一步失败了它会停下来告诉我哪里出了问题。这个工作流我每天至少用五次每次节省大概两分钟一天就是十分钟一个月就是五个小时。还有一个案例是代码审查。我配置了一个审查工作流它会自动读取当前分支的 diff然后按几个维度给出建议命名规范、潜在 bug、性能问题、测试覆盖。这个工作流我用了大概三周发现它确实能抓到一些我手动审查时容易忽略的问题比如边界条件处理、异常捕获不完整。提示配置工作流时建议把每个步骤的命令写成幂等的也就是重复执行不会产生副作用。这样即使工作流中断了重新执行也不会出问题。4. 把两个思路合起来我的日常 AI 编程工作流4.1 整体流程设计把 OpenAI 用量砍半和 Claude Code 自我优化这两个思路合起来我现在的日常 AI 编程工作流是这样的第一步用本地模型或者 IDE 自带补全处理简单的代码补全和语法查询。这一步不消耗云端 token。第二步用 Claude Code 的工作流处理重复性的任务比如代码格式化、测试运行、类型检查。这一步消耗少量 token但节省大量时间。第三步用云端模型处理复杂逻辑和架构问题。这一步消耗较多 token但值得花。第四步定期回顾 token 消耗看看哪些环节还可以优化。这个流程我用了大概两个月整体效率比之前提升了大概 40%token 消耗降了接近一半。最关键的是代码质量没有下降反而因为流程更规范bug 率还降低了一些。4.2 工具选型的考量工具选型上我没有追求“一个工具解决所有问题”而是按场景分工。本地补全用 IDE 自带的够用就行重复性任务用 Claude Code 的工作流复杂问题用云端模型。这样分工的好处是每个工具都在自己擅长的场景里工作不会出现“用大炮打蚊子”的情况。具体到 Claude Code 的安装和配置我是在 Ubuntu 上用的安装过程比较简单官方文档里有详细的步骤。配置上主要注意两点一是 API key 的管理建议用环境变量而不是硬编码二是工作流的配置文件建议纳入版本控制这样换机器或者团队协作时可以直接复用。4.3 成本与效率的平衡成本和效率的平衡是一个动态过程。我的做法是每个月做一次回顾看看上个月的 token 消耗分布哪些环节消耗最多哪些环节可以优化。比如上个月我发现单元测试生成的 token 消耗比较高这个月我就调整了策略改用模板加局部生成的方式消耗降了大概 30%。还有一个经验是不要为了省 token 而牺牲代码质量。我见过有人为了省 token把复杂的重构任务拆成很多小步骤结果因为上下文丢失模型给出的建议前后矛盾反而要花更多时间修正。我的原则是如果一个任务需要完整的上下文才能做好那就不要拆该花的 token 要花。5. 常见问题与排查技巧实录5.1 配置类问题问题一Claude Code 安装后无法执行命令。这个我遇到过通常是因为环境变量没有配置好。检查一下 PATH 里有没有 Claude Code 的安装路径以及 API key 是否设置正确。如果是 Ubuntu 系统建议把配置写到.bashrc或者.zshrc里然后重新加载。问题二工作流执行到一半卡住。这种情况多半是某个步骤的命令需要交互式输入比如确认删除文件。解决办法是在命令里加上非交互式参数比如-y或者--yes。如果命令本身不支持非交互式可以考虑用expect脚本包装一下。问题三token 消耗比预期高。先检查是不是上下文带太多了。我建议每次提问前看一眼当前上下文的大小如果超过 2000 token考虑是不是可以缩小。另外检查一下有没有重复提问有时候同一个问题问了两遍token 就翻倍了。5.2 使用类问题问题四模型给出的建议不准确。先检查上下文是否完整。如果只贴了一个函数但问题涉及整个模块的交互模型很难给出准确建议。这时候需要补充相关代码或者描述。另外提问方式也很重要尽量把“帮我改这段代码”换成“这段代码要实现 X目前的问题是 Y请给出修改建议”。问题五工作流配置后不生效。检查配置文件的路径和格式。Claude Code 的配置文件通常放在用户目录下的隐藏文件夹里具体路径可以查官方文档。格式上注意缩进和引号YAML 格式对缩进很敏感。问题六本地模型和云端模型怎么分工。我的经验是涉及业务逻辑、架构设计、复杂算法的任务交给云端模型涉及代码补全、格式化、简单查询的任务交给本地模型。中间地带的比如单元测试生成可以先用本地模型生成初稿再用云端模型润色。5.3 成本控制类问题问题七怎么知道哪些环节消耗最多。大部分 API 提供商都有用量统计面板可以按天、按模型、按项目查看。我建议每周看一次找出消耗最高的三个环节然后针对性地优化。问题八团队协作时怎么控制总成本。建议统一配置工作流和 prompt 模板避免每个人重复描述背景。另外可以设置用量上限超过阈值时提醒。我们团队的做法是每周同步一次用量情况大家互相看看有没有可以复用的工作流。注意成本控制不是一个人的事团队协作时更需要统一规范。我见过一个团队因为每个人用法不同同样的任务 token 消耗差了三四倍。6. 我踩过的坑和最后分享的几个小技巧踩过的坑不少挑几个有代表性的说。第一个坑是过度依赖云端模型。刚开始用 AI 编程助手时我什么任务都往云端扔结果 token 消耗飞快月底一看账单吓了一跳。后来才慢慢学会分工把简单任务交给本地模型。第二个坑是工作流配置得太复杂。我一开始想把所有操作都塞进一个工作流结果配置文件写了三百多行维护起来很麻烦而且经常因为某个步骤失败导致整个工作流中断。后来我拆成了几个小工作流每个只做一件事反而更稳定。第三个坑是忽略上下文管理。有一次我让模型帮我重构一个模块贴了大概两千行代码进去结果模型给出的建议质量很差因为它被太多无关信息干扰了。后来我学会了只贴相关部分效果明显好很多。最后分享几个小技巧。一是把常用的 prompt 模板存成文件用的时候直接复制省得每次重新写。二是定期清理不用的工作流和配置保持配置文件简洁。三是多看看官方文档的更新日志Claude Code 和 OpenAI 的 API 都在持续迭代新功能可能正好解决你之前遇到的问题。还有一个技巧是把 AI 编程助手当成一个“需要磨合的搭档”而不是一个“即插即用的工具”。刚开始用的时候效率可能不如手动写但用久了、配置好了效率提升会非常明显。我自己的体会是前两周是投入期第三周开始回本一个月后效率提升就很可观了。