1. 从一条日记说起为什么“用量砍半”和“自我优化”值得单独聊09-29 这条记录其实就两件事一是把 OpenAI 的调用量压下来一半二是让 Claude Code 进入一个能自己打磨自己的循环。听起来像两条不相干的线但做过 AI 工程的人一眼就能看出来这俩是同一件事的两面——成本控制和能力迭代。前者决定你能不能长期跑下去后者决定你跑得够不够快。我自己是从去年开始把日常开发流程往命令行 AI 助手上迁的中间踩过的坑基本覆盖了热词里那一长串从 API Key 怎么拿、环境怎么配到模型怎么切、终端命令怎么让它直接执行。所以这篇不打算写成教程目录而是把 09-29 这一天的两个动作拆开讲清楚每一步背后的判断逻辑以及哪些地方是真正会卡住人的。先给个定位这篇适合已经在用或者准备用命令行 AI 编程助手的人尤其是那些既想控制 token 开销、又想让工具越用越顺手的开发者。如果你只是好奇 Claude Code 是什么、怎么装前半部分够用如果你想搞明白“自我优化”到底怎么落地后半部分才是重点。全文的核心关键词就两个OpenAI 用量和Claude Code其余都是围绕它们展开的实操细节。我先把结论摆前面省得你看到一半才发现方向不对用量砍半靠的不是换更便宜的模型那么简单而是分层路由 缓存复用 提示词瘦身三件事一起做自我优化靠的也不是什么玄学而是把每次调用的输入输出沉淀成可检索的经验库再让助手在下次任务开始前先读自己的历史。这两件事都能落地但都有各自的坑。2. OpenAI 用量砍半不是省钱是让调用结构变健康2.1 先搞清楚“用量”到底花在哪很多人一说砍用量第一反应是换个便宜模型。我试过效果有限因为大头往往不在单价上而在无效调用上。你得先知道钱花哪了。我的做法是给每次调用打三个标签任务类型、输入长度、是否命中缓存。跑一周之后拉个表问题一目了然。调用类型占比平均输入 token平均输出 token是否可缓存代码补全42%800120部分可报错解释23%1500300可文档摘要18%4000500可自由问答12%600400不可其他5%300200不可这张表是我自己跑出来的不一定适用于你但结构大概率相似输入 token 远大于输出 token而且大部分输入是重复的上下文。也就是说砍用量的主战场在输入端不在输出端。你换个输出更便宜的模型省下来的可能还不到 10%。提示别急着上监控平台先用最土的办法——在调用封装层加一行日志把每次请求的 prompt 长度和响应长度写进本地文件。跑三天就够你看出规律了。2.2 分层路由把任务分给“够用就行”的模型砍半的第一个动作是分层。我的分法是三层轻量层、标准层、重载层。轻量层处理格式转换、简单补全、字段提取这类任务标准层处理报错解释、代码改写重载层才处理复杂推理和长文档分析。这么分的好处是轻量层可以用小模型甚至本地模型顶掉标准层用中等模型只有重载层才动用最贵的那档。我实测下来原来 100% 走重载层的调用分层之后只有 20% 左右还需要重载层其余都下沉了。单这一项用量就掉了四成左右。具体怎么判断一个任务该走哪层我用的是一套很朴素的规则输入长度 任务关键词 是否需要多步推理。比如输入超过 3000 token 且带“分析”“对比”“设计”这类词走重载层输入短、带“格式化”“提取”“转换”这类词走轻量层其余走标准层。规则不优雅但够用而且可解释出问题好排查。2.3 缓存复用把重复的上下文存下来第二个动作是缓存。前面那张表里报错解释和文档摘要这两类输入重复率极高。同一个项目的报错今天问一遍明天换个说法又问一遍。我的做法是给每个项目建一个本地缓存目录把“输入指纹 响应”存成键值对下次调用前先查缓存。这里有个细节要注意缓存键不能直接用原始 prompt因为稍微改一个字就命不中了。我用的是“任务类型 关键实体 输入长度区间”的组合键。比如“报错解释 模块名 长度 1000-2000”这样命中率高很多。实测缓存命中率能到 35% 左右等于这部分调用直接归零。注意缓存要设过期时间我一般设 7 天。代码库在变太老的缓存会给出过时答案反而添乱。2.4 提示词瘦身把废话从上下文里删掉第三个动作最容易被忽略但效果最直接删提示词里的废话。我见过太多人把整个文件、整个报错栈、整个需求文档一股脑塞进去觉得“给的信息越多越好”。实际上模型对上下文的利用是有衰减的塞太多反而稀释了关键信息。我的做法是三步先删掉与当前任务无关的文件内容再删掉重复的报错行最后把长文档压成摘要再喂进去。一个典型的报错解释任务原来输入 1500 token瘦身之后能压到 600 左右。三个动作叠加用量砍半不是目标是自然结果。3. Claude Code 上手从安装到让它直接执行终端命令3.1 安装这件事卡住的人比想象中多热词里“claude code 安装”“ubuntu 安装 claude code”“mac 安装 claude code”出现频率很高说明安装本身就是一道坎。我自己的经验是安装本身不难难的是环境依赖和权限。命令行工具大多依赖 Node 环境版本不对就会报各种奇怪的错。我的建议是先把 Node 版本对齐到工具要求的区间再装。装完之后别急着跑先执行一次版本检查命令确认能正常输出。如果报“与 64 位版本不兼容”这类错八成是 Node 架构和系统架构对不上重装对应架构的 Node 即可。提示如果你在 Windows 上遇到兼容性提示优先检查是不是装了 32 位的 Node。这个坑我踩过排查了半小时才发现是架构问题。3.2 登录与账号注册和不注册的区别热词里有一条“claude code 注册账号和不注册有啥不同”这个问题问得很实在。简单说注册账号能拿到更完整的模型能力和更高的调用额度不注册通常只能用受限的本地能力或者第三方接入。如果你只是偶尔用用不注册也能跑但如果你要把它当日常开发工具注册是值得的。登录方式上我倾向于用官方支持的登录流程别去折腾来路不明的 Key。热词里那些“api key 分享”之类的东西我建议直接跳过——用别人的 Key 等于把命脉交到别人手里额度、稳定性、安全性都不可控。自己注册、自己拿 Key麻烦一点但踏实。3.3 接入第三方模型本地模型和国产模型怎么选热词里“claude code 调用 lmstudio 的本地模型”“使用 cc switch 接入 deepseek、qwen、glm 等模型”这两条说明很多人想让 Claude Code 不只用官方模型。这个思路是对的因为不同任务用不同模型成本和效果都能优化。我的做法是日常补全和格式转换走本地模型复杂推理走官方模型。本地模型用 LM Studio 起一个服务Claude Code 通过配置指向本地端口即可。国产模型那边通过切换工具把请求路由过去适合处理中文语境强的任务。这里的关键是配置要能一键切换不然每次改配置文件太累。模型来源适用任务成本响应速度本地模型补全、格式化、简单问答几乎为零快国产模型中文文档、摘要、改写低中官方模型复杂推理、架构设计高中3.4 让它直接执行终端命令效率翻倍也风险翻倍“claude code 如何直接执行终端命令”是热词里最实用的一条。这个能力一旦打开效率提升非常明显——你不用再复制粘贴命令直接让它跑就行。但风险也同步放大因为它能改文件、能删东西。我的做法是分级授权只读命令如查看文件、列目录直接放行写操作如改文件、装依赖需要我确认危险操作如删除、覆盖一律禁止自动执行。这个分级不是工具自带的是我自己在使用习惯上定的规矩。你可以理解为给助手划一条红线红线内随便跑红线外必须喊人。注意千万别在没备份的目录里让它自动执行写操作。我有个朋友就是这么把一整个项目的配置文件覆盖掉的恢复花了半天。4. 自我优化让 Claude Code 越用越懂你的项目4.1 什么叫“自我优化”别被这个词吓到“Claude Code 打磨自我优化”听起来很玄其实拆开很朴素把每次任务的输入、输出、结果反馈沉淀下来形成一份可检索的经验记录下次遇到类似任务时先读这份记录再动手。它不是模型自己改自己而是你给它搭一个记忆层。我搭这个记忆层用的是最笨的办法每次任务结束后把“任务描述 关键决策 最终结果 是否满意”写进一个本地 Markdown 文件按项目分目录。下次开新任务前先让它读一遍相关目录下的历史记录。就这么一个动作重复问题的处理速度能快一倍以上。4.2 经验库怎么建才不变成垃圾堆建经验库最大的风险是变成垃圾堆——什么都往里塞最后检索不出来。我的原则是只记三类东西一是踩过的坑和解决方案二是项目特有的约定和规范三是被验证有效的提示词模板。其余的日常对话、临时问答一律不记。格式上我用的是固定结构问题描述、原因分析、解决方案、验证结果。四段式每段不超过三行。这样检索的时候一眼就能定位。文件名用“日期 模块 关键词”方便按时间和模块两个维度找。提示经验库别用数据库就用纯文本文件。好处是可读、可 diff、可版本控制出问题直接看文件不用查库。4.3 把经验库接进工作流三个具体动作光建库没用得接进工作流。我做了三个动作。第一个是任务前置检索每次开新任务先让它读相关经验记录再开始干活。第二个是任务后置沉淀任务结束让它自己总结一条记录写进库。第三个是定期回顾每周花十分钟翻一遍本周新增的记录把重复的合并、过时的删掉。这三个动作里第二个最容易偷懒。我的办法是把它做成一个固定命令任务结束顺手敲一下不给自己犹豫的机会。坚持两周之后你会发现它给出的方案越来越贴合你的项目习惯这就是“自我优化”的真实体感。4.4 一个真实的优化案例举个我自己的例子。项目里有个模块的构建总是失败报错信息很长。第一次处理花了四十分钟最后发现是某个依赖版本冲突。我把这条记录写进了经验库。两周后同样的报错又出现这次它先读了经验库直接定位到依赖版本问题五分钟解决。这个案例说明一件事自我优化的价值不在第一次在第二次、第三次。第一次你还是要花时间但只要你把过程沉淀下来后面每一次都在吃前面的红利。这也是我为什么坚持建经验库的原因——它不解决今天的问题它解决明天的问题。5. 常见问题与排查技巧实录5.1 安装与配置类问题速查现象可能原因排查动作安装后命令找不到环境变量未生效重开终端或手动 source 配置提示与系统不兼容Node 架构不匹配检查并重装对应架构 Node登录失败网络或账号状态异常检查网络确认账号可用模型切换不生效配置文件未重载重启工具或重新加载配置本地模型连不上端口或服务未启动确认本地服务已起、端口正确这张表是我自己踩坑之后整理的覆盖了八成以上的常见问题。遇到问题先查表查不到再深挖能省不少时间。5.2 用量控制类问题用量控制最常见的误区是只看单价不看结构。我见过有人为了省钱把模型换成最便宜的结果因为效果差反复重试总用量反而涨了。正确的顺序是先看结构、再做分层、最后才考虑换模型。另一个误区是缓存不设过期。缓存太老会给出过时答案导致你基于错误信息做决策返工成本远大于省下的那点调用费。我的经验是缓存过期时间设 7 天代码库变动频繁的项目设 3 天。5.3 自我优化类问题自我优化最容易失败的地方是记录太随意。随手记的笔记过两天自己都看不懂更别说让工具检索了。所以格式一定要固定字段一定要齐全。我用的四段式结构问题、原因、方案、验证是试了好几版之后定下来的够用且不啰嗦。还有一个坑是只记成功不记失败。失败的尝试同样有价值它能告诉你哪条路走不通。我现在连“试了 A 方案不行原因是 X”这种记录也会写进去避免下次重复踩坑。6. 我个人的几条实操心得第一条别追求一步到位。用量砍半不是一天做到的自我优化也不是一周建成的。我的做法是每周只改一个点改完观察一周有效再固化。这样虽然慢但每一步都稳不会因为一次大改把整个流程搞崩。第二条工具是工具判断是你的。Claude Code 能帮你跑命令、能帮你查经验库但最终拍板的还是你。尤其是涉及写操作和删除操作的时候多确认一次不丢人出事了才丢人。第三条经验库要定期清理。我每个月会花半小时翻一遍把过时的、重复的删掉。库不在大在精。一个塞满垃圾的库检索效率还不如没有。最后分享一个小技巧如果你同时用多个模型给每个模型建一个独立的经验子目录。因为不同模型的行为差异挺大混在一起会互相干扰。分开之后每个模型都能在自己的经验里越用越顺。这个内容后续还可以往“多模型协同”的方向扩展比如让一个模型负责检索、一个负责推理、一个负责验证但那又是另一个话题了。