夜雨聆风很多人第一次认真看 AI 编程账单，都会有一种很微妙的感觉。
明明只是让它改一个按钮文案，或者修一个不太复杂的小 bug，怎么消耗看起来像跑了一轮大工程？
更扎心的是，你回头看整个过程，好像也没问多少问题。不是一天到晚让 AI 写系统，也不是让它重构公司祖传代码。就是很日常地用 Cursor、Claude Code、Codex、Windsurf 这类工具写写改改。
但账单就是上去了。
这两天看到 Berry Xia 在 X 上转述 Andrej Karpathy 的一个判断，大意是，AI 编程账单里有很大一部分浪费，并不是浪费在真正的思考上，而是浪费在发送不必要的上下文上。
我更愿意把这个“90%”理解成一个提醒，而不是精确统计。
它真正刺中的不是数字，而是一个很多人没意识到的问题：
你以为自己是在请 AI 改一行代码。
实际上，它可能每次都背着一整个项目文件夹去问模型。
这件事特别像我们刚开始用搜索引擎的时候，不知道关键词该怎么写，于是把一整段心情、一整段背景、一整段解释全塞进去。搜索引擎不会因为你写得长就更懂你，AI 也一样。
尤其是 AI 编程。
Token 不是一个抽象的技术词。它就是模型每次阅读、理解、推理时要付出的成本。你发过去的文件越多，历史对话越长，规则说明越重复，它就要读越多。读得越多，花得越多，慢得也越明显。
问题在于，很多时候它读的并不是“必要内容”。
最常见的一种浪费，是小问题读大范围文件。
比如你只是想改一个登录页按钮文案，理想状态应该是先定位到对应组件，再让模型处理那几行相关代码。结果有些 Agent 会先扫一遍目录，再看一堆相邻文件，再把历史上下文也带上。
像一个刚入职的同事，为了改一句话，先把公司组织架构看完。
这当然不是说 Agent 不该探索代码。
复杂问题需要探索。跨模块 bug 需要探索。架构判断更需要探索。
但如果每一个小改动都默认大范围探索，那就很像你去便利店买瓶水，司机先带你绕城一圈熟悉路况。不是不能走，只是没必要。
还有一种浪费，是简单事情也默认上最贵模型。
我见过不少人用 AI 编程工具，模型选择基本只有一个原则：选最强的。因为心里会觉得，反正我都付费了，当然要用最好的。
这个想法很自然，我也干过。
但后来会发现，很多活儿其实不配动用最贵的模型。
重命名变量、格式整理、查找替换、补一个很标准的单元测试、把错误信息翻译成人话，这些事情未必需要顶级推理模型。
强模型应该留给更难的地方，比如排查复杂链路、判断架构取舍、理解一段非常绕的旧代码，或者在关键上线前帮你做风险检查。
真正会用 AI 编程的人，不是永远用最强模型。
而是知道什么时候不用它。
一种更现实的做法，是把模型分层。便宜、快的模型处理常规动作，中等模型处理大多数编码和解释，强模型只处理关键判断。
具体用哪一个模型，不需要写成固定答案。重点是你心里要有这层分工。
不分工，账单就会替你分工。
第三种浪费，是每次都让 AI 重新学习同一件事。
项目规范是什么，接口怎么命名，哪些目录不能动，测试命令怎么跑，团队喜欢什么风格，哪些历史坑不要再踩。
这些知识明明很稳定，但很多人每次开新对话都重新解释一遍。
这就有点荒唐了。
你不会每天早上重新给同事介绍一次公司业务，但很多人每天都在重新给 AI 介绍项目。
所以我觉得，AI 编程里特别值得做的一件小事，是把稳定知识沉淀下来。
可以是项目里的规则文件，可以是工具自带的项目说明，也可以是团队共享的一份简短约定。名字不重要，重要的是它要让 AI 少一点重复学习，多一点直接进入状态。
有些工具和模型也支持把稳定背景缓存起来，下一次复用时成本会更低。普通用户不用急着研究所有细节，但至少要形成一个意识：
重复发送同一段长背景，是很贵的。
这不是抠门。
这是尊重系统的计费方式。
说到这里，我觉得有一个误区要拆掉。省 Token 不是让你少用 AI，也不是让你每次都把问题写得像电报一样短。
很多人一听“省 Token”，就会想到克制、压缩、别问太多。
但真正重要的不是少问，而是少带无关东西。
你可以问得很清楚，很完整，很有上下文。但这个上下文应该是被筛过的。该给的给，不该给的别让模型读。
比如改一个前端交互，你给相关组件、状态逻辑、报错信息就够了。没必要把整个后端接口目录也带进去。
比如修一个测试失败，你先把失败日志、对应测试文件、被测函数拿出来。没必要一上来让 Agent 自由巡游全项目。
比如做一次架构讨论，你当然可以给更多背景。但这时候给的是有意选择过的背景，而不是把仓库丢过去说，你自己看吧。
这就是差别。
我现在更倾向于把 AI 编程分成两个动作。
一个动作是让 AI 干活。
另一个动作是管理 AI 干活时能看到什么。
以前我们总觉得，会写指令的人更强。这个判断没有错，但已经不够了。接下来真正拉开差距的，可能是会不会管理上下文、会不会看工具调用、会不会把模型用在合适的位置。
一个很简单的自查方法：下次你用 AI 写代码时，别急着盯它最后改了什么。
先看它中间做了什么。
它读了哪些文件？
有没有反复读同一批文件？
有没有把明显无关的目录也塞进来？
这个问题真的需要强模型吗？
那些项目背景，是不是你昨天、前天、上周已经讲过很多遍？
你只要认真看一次，大概率就会发现一些很浪费的地方。
有时候优化不需要很复杂。先缩小上下文，再选择合适模型，再把稳定知识沉淀下来，再观察账单和速度有没有变化。就这么朴素。
如果你是团队负责人，这件事更值得早点做。
因为个人浪费一点 Token，可能只是一个月多花几十、几百块。团队里每个人都让 Agent 带着整个代码库乱跑，那就不是个人习惯问题了，而是研发成本会被悄悄放大。
更麻烦的是，大家还会误以为这是 AI 本身太贵。
但很多时候，不是 AI 太贵。
是我们使用它的方式太粗。
我挺喜欢 Karpathy 这个提醒的原因也在这里。它没有让我们回到“AI 到底有没有用”这种老问题，而是把问题往前推了一步。
AI 已经进入日常工作了。
现在该问的是，我们能不能像管理数据库查询、管理云资源、管理代码依赖一样，开始管理 AI 的上下文和模型选择。
这听起来有点工程化，但其实很日常。
别让小问题带上大包袱。
别让简单动作消耗强模型。
别让稳定知识每天重新付费。
别让 Agent 在你看不见的地方反复绕路。
所谓很多人在浪费 Token，未必是因为他们不懂 AI。
更可能是因为他们还在用“人类聊天”的方式，使用一个按上下文计费的系统。
下一次你让 AI 改代码时，可以先慢半拍。
别急着问它怎么改。
先看它准备带着多少东西去思考。
管理上下文，其实就是管理 AI 成本。
你最近用 AI 编程时，有没有遇到过“明明小问题，却跑得很重”的情况？可以顺手翻一次工具调用记录，很多答案都藏在那里。
