夜雨聆风你只是想让 Claude Code 或 Cursor 修一个小 bug。
它读了半个代码库，扫了一堆无关文件，跑了一堆命令，输出一大段解释。最后真正改的，只有三行代码。
功能是修好了。
但你心里隐隐觉得哪里不对。
因为你不是在花钱买那三行代码。
你是在花钱让 AI 把一堆它根本用不上的上下文，认真地、逐字逐句地读了一遍。
这不是错觉。
AI 写代码正在进入一个新阶段：以前大家关心的是“AI 会不会写代码”，现在大家开始关心的是——
它到底烧了多少 token 才写出这几行代码？
有人做过一个对照：同一个 Express.js 重构任务，OpenAI Codex 大约消耗 150 万 token；Claude Code 完成同样任务用了约 620 万 token。
Claude 更快，也抓到了 Codex 漏掉的问题，但 token 消耗是 4 倍多。这个案例很好地说明了现在 AI coding 的真实矛盾：更彻底、更主动的 agent，往往也更贵、更重、更容易把上下文塞爆。
你打开 Claude Code 或 Cursor 的时候，表面上是在写代码。
但很多时候，你更像是在一台老虎机前投币。
这次请求会烧几百 token，还是几万 token？
它会精准改一个函数，还是绕着代码库旅游一圈？
它是真的理解了问题，还是只是把一堆上下文吞进去，然后一本正经地猜？
你不知道。
这才是最可怕的地方。
你花的不只是 token，是判断力
token 浪费不是单纯的账单问题。
它还会影响代码质量。
上下文窗口越长，里面混进的旧日志、失败尝试、无关文件、历史讨论越多，模型越容易分心。Anthropic 自己在 Claude Code 质量复盘里也承认过，他们曾把 Claude Code 的默认 reasoning effort 从 high 降到 medium，后来发现这是错误取舍，又把它改了回来。
这件事说明一个很现实的问题：
AI coding 不是上下文越多越好，而是上下文越干净越好。
你每多塞一段没用的日志，AI 就多一个跑偏的机会。
你每多贴一个无关文件，AI 就多一层噪音。
你每让它在一个已经污染的对话里继续修，后面所有判断都可能被前面的失败尝试拖偏。
然后你再花更多 token 让它纠正。
这就是死亡循环。
它不是一次性多花点钱。
而是越用越乱，越乱越贵，越贵越不准。
最贵的不是模型，是垃圾上下文
很多人以为 AI coding 贵，是因为模型贵。
其实更常见的问题是：你喂进去的东西太脏。
最典型的三种浪费：
第一，重复上下文。 项目架构、技术栈、代码规范、数据库结构、构建命令，每次新会话你都重新解释一遍。AI 每次都重新读一遍。token 像水龙头一样往外流。
第二，无关文件。 你要修一个登录表单，结果把整个 app/、components/、lib/ 都丢进去。AI 当然可以看，但它不一定需要看。
第三，冗长输出。 你只想要一个 diff，它给你写了 800 字教程。你只想知道为什么报错，它顺便教你一遍 React 生命周期。
这些都不是“AI 很努力”。
这是你在为噪音付费。
CLAUDE.md 不是百科全书，是索引
现在很多人知道要写 CLAUDE.md、AGENTS.md、项目规则文件。
但新的问题来了：
有人把这些文件写成了产品白皮书。
几千字，什么都往里塞：项目愿景、技术栈、目录结构、历史决策、未来规划、代码风格、部署流程、业务背景。
结果每次对话都带着一大坨不一定有用的上下文。
这不是缓存。
这是负重。
Claude Code 官方文档里确实把 CLAUDE.md 作为 memory 和项目上下文的一部分，让 Claude 在会话中自动获得项目规则和指令。但这不代表你应该把所有东西都塞进去。
好的上下文缓存，应该像索引，不像百科全书。
它只放稳定、高频、能减少误解的信息。
比如：
```md
Project Context
• Stack: Next.js 15, App Router, TypeScript strict mode.
• Database: PostgreSQL via Prisma.
• Auth: NextAuth, session stored in HTTP-only cookie.
• Style: Tailwind, no default exports.
• Error handling: use Result type instead of throwing in service layer.
• Important: payments table is large; avoid full table scans.
```
这类内容不长，但很有用。
它告诉 AI 基本边界，让它少问你、少误解、少重复探索。
真正该避免的是：
把所有历史信息都写进去。
把还没稳定下来的需求写进去。
把一次性任务细节写进去。
把 AI 上次犯的所有错都写进去。
上下文缓存的目标不是“让 AI 知道一切”。
而是让 AI 在最小必要信息下，做出稳定判断。
别把 AI 当实习生，先把它当查询引擎
很多人对 AI 太客气，也太模糊。
“你能帮我看看这段代码有没有问题吗？”
“这个实现有没有更好的方式？”
“帮我优化一下。”
这类 prompt 很容易得到又长又泛的回答。
AI 会解释背景、列出选项、补充注意事项、顺便重构一堆你没让它动的东西。
你觉得它很聪明。
账单觉得它很贵。
更好的方式，是像写 SQL 一样写 prompt。
你不会在生产数据库里随便写：
``sql SELECT * FROM users; ``
你会选字段，加条件，限制返回行数。
跟 AI 也一样。
不要说：
帮我看看登录哪里坏了。
要说：
auth/LoginForm.tsx 能正常提交，但 POST 到 /api/auth/login 返回 401。数据库凭证确认正确。只分析下面这两个文件。不要重写架构。只返回导致 401 的可能原因和需要修改的 diff。
你要告诉它：
看哪里。
忽略哪里。
输出什么格式。
不要输出什么。
回复多长。
能不能改代码。
如果信息不够，先问你，不要猜。
这不是抠门。
这是专业。
AI 默认很愿意多说。你不限制它，它就会用最贵的方式向你证明它很努力。
让每次回复都短一点、准一点
token 浪费不只发生在输入端，也发生在输出端。
你只想要代码，AI 给你解释一堆原则。
你只想知道错误原因，它给你写了完整教程。
你只想改一个函数，它把整个模块重写了。
所以你的 prompt 里，要经常加几句“限流词”：
```txt 只返回 diff，不要解释。
如果需要解释，每条不超过 50 字。
不要重写无关部分。
不要输出完整文件，只输出修改片段。
如果信息不够，先问我，不要猜。 ```
这不是为了省几分钱。
它会直接提高你的工作流质量。
因为 AI 回复越短、越准，你越容易判断，越容易应用，越容易继续迭代。
很多时候，让 AI 少说点，不是降低智能。
是降低噪音。
你的工作流，需要降噪
现在已经有不少工具开始专门解决 AI coding 的上下文浪费问题。
比如 SigMap 这类工具，方向是让 AI 不再盲目读完整代码库，而是提取更小、更相关的上下文。作者声称它能把常见 AI coding session 从约 80k tokens 压到约 2k tokens，达到接近 97% 的 token reduction。
这个数字未必适用于所有项目，但它代表了一个很重要的趋势：
代码库上下文正在被重新组织，而不是一股脑丢给模型。
还有很多类似方向：
有的工具压缩 CLI 输出，避免你在 Claude Code 里跑个测试，结果把几千行日志全塞进上下文。
有的工具用调用图、依赖图、文件索引，让 agent 顺着相关路径读代码，而不是到处乱搜。
有的工具做跨会话 memory，避免你每次新开会话都重新解释项目结构。
这些工具解决的是同一个问题：
AI 不缺能力。
它缺干净的输入。
你真正要做的，不是搭一个越来越复杂的 AI 帝国。
而是先把噪声源关掉。
不是什么任务都该用最强模型
还有一种浪费，是所有任务都用最强模型。
写架构方案，用强模型，合理。
排查复杂 bug，用强模型，也合理。
但生成测试数据、格式化 JSON、写几个样板函数、改一个普通 CRUD，也用最贵模型，就像开法拉利送外卖。
你可以简单分层：
小模型 / 快模型： 样板代码、格式转换、简单重构、测试数据、正则、脚本小修。
中等模型： 写测试、code review、改组件、解释局部逻辑。
强模型： 复杂 bug、架构设计、跨文件重构、安全风险、性能瓶颈、关键决策。
这不是降低质量。
这是合理配置质量。
每次开强模型之前，先问一句：
这件事真的需要顶级推理吗？
还是我懒得切模型？
先统计，再砍，别靠感觉优化
如果你真的在意 AI coding 成本，不要靠感觉。
花一周时间，简单记录三件事：
• 大概用了多少 token / 花了多少钱
• 任务类型是什么：修 bug、写功能、重构、解释代码、写测试
• 第一次回复有没有用
一周后你会看到规律。
也许你会发现，“解释代码”最贵，但真正有用率不高。
也许你会发现，每次新 session 的第一个 prompt 最贵，因为你都在重建上下文。
也许你会发现，大部分 token 都烧在日志、终端输出、无关文件、重复解释上。
有了数据，才知道从哪里砍。
不要一上来优化所有地方。
先砍最贵的三类场景。
这和做增长一样。
先找最大漏斗，不要先优化按钮颜色。
最后
这套打法的核心，真的不是省钱。
如果你每个月只花 20 美元订阅 AI 工具，token 成本可能不是最大问题。
但上下文效率依然是大问题。
因为它影响的不只是账单。
它影响 AI 是否准确，回复是否稳定，任务是否可控，你是否需要花很多时间擦屁股。
AI coding 的早期阶段，大家比的是谁敢用、谁用得多。
现在进入第二阶段，比的是谁用得更干净、更便宜、更可控。
给 AI 更少但更准确的上下文。
让 AI 输出更短但更可执行的结果。
把稳定信息缓存起来，把临时信息按需提供。
把简单任务交给便宜模型，把关键任务留给强模型。
这套能力会越来越重要。
因为未来大家用的模型可能差不多，工具也会越来越相似。
真正拉开差距的，不是你有没有 AI。
而是你能不能把 AI 放进一个低噪音、高效率、可持续的工作流里。
这周你可以只做一个小动作：
下一次让 AI 改代码前，别急着把整个文件丢进去。
先花三分钟，把问题收窄到一个函数、一个报错、一个明确目标。
你会发现，省下来的不只是 token。
还有时间、注意力，和很多不该发生的返工。
· · ·
关于 OPC Community（OPC同行社）
OPC Community（OPC同行社）是一个面向全球 AI 时代一人公司与超级个体的支持型社区，关注独立创业者在成长中的真实需求，提供支持、连接与共同成长。
如果你也在做自己的产品、项目或一人公司，欢迎加入我们，一起在 AI 时代找到同行者。
访问官网：opc.community
