夜雨聆风 
说明：这是一篇来自 X 用户 @DeRonin_ 的长文翻译。原文讲的是如何通过模型路由、prompt caching 和上下文纪律，把 AI 编程账单从每月 4200 美元降到 312 美元。本文保留原文结构和主要数字，只做中文化整理，原文链接：https://x.com/DeRonin_/status/2054235707791778034。
我把自己的 AI 编程账单从每月 4200 美元，降到了每月 312 美元。
没有换新工具。
没有减少交付。
也不是那种“那就用更便宜的替代品吧”的自我安慰。
我只是做了更聪明的模型路由，开启了 prompt caching，并修掉了工作流里 5 个固定的漏洞。
在我意识到之前，这些漏洞一直悄悄烧掉我大约 50%-70% 的 token。
这篇文章，就是我之前承诺的完整拆解。
每一个修复点。
每一份配置。
每一美元是怎么省下来的。
读完之后，你会得到一套这个周末就能真正落地的系统。
读完并执行之后，你会拥有：
1. 在不牺牲交付速度和质量的情况下，把每月 AI 编程账单降低 50%-70%。 2. 一个可以根据任务自动选择正确模型的多模型路由器。 3. 一套关于 token 经济学的工作理解，而 95% 的 vibe coder 从来没有认真学过这件事。 4. 一个 30 天落地计划，每周都有明确动作。 5. 一份可以复制粘贴到 Cursor / Claude Code 的路由配置。
下面开始拆。
1. 为什么你的 AI 编程账单正在爆炸
2026 年，vibe coder 的成本曲线看起来像一根冰球杆。
Claude Code、Cursor、Aider、Windsurf，每个工具背后都跑在同一套经济模型上：
tokens in，tokens out。
输入和输出方向都按每百万 token 多少钱来计费。
你用这些工具交付得越多，烧掉的 token 越多，账单也就跟着涨。
陷阱在于，大多数 vibe coder 学 AI 编程的时候，GPT-3.5 还是免费的，Claude 还是每月 20 美元的固定订阅。
没有人训练你，去应对这样一个时刻：
周二早上你还在泡咖啡，工具已经开始自动跑一个 50000 token 的 agentic loop。
三件事同时发生了：
• 模型变得更聪明，也更贵了。Opus 4.6 的输入成本大约是两年前 GPT-3.5 的 10 倍。 • 工具开始自动包含更多上下文。Cursor 的 auto-context、Claude Code 的 repo awareness，以及每个 IDE 都在提供各种 @-everything。• Agentic workflow 成为默认方式。现在每个工具都会跑多步循环，而每一步都要支付完整 token 成本。
结果是：
一个每天都在交付的普通 vibe coder，每月可能烧掉 2000-5000 美元。
而且大多数人并不知道其中有多少是浪费，直到他们真正看到账单明细。
诊断结果不是：
“模型太贵了。”
真正的诊断是：
“你在为懒惰付费。”
你的大部分 token 账单是可修复的行为问题，而不是价格问题。
这是好消息。
也是这篇指南为什么真的有效。
核心洞察：你付费的不是 token，而是上下文
网上每一篇“降低 AI 账单”的文章，都会告诉你换模型。
这是错误的修法。
真正的修法在更上游：
停止发送那些你本来不需要发送的 token。
一个典型的 vibe coder 会话是这样的：
1. 打开 Cursor。 2. Auto-context 加载 47000 token 的 repo 文件。 3. 让 Claude “修复这个函数里的 bug”。 4. Claude 在 47000 token 上推理，只为了找到真正重要的 30 行代码。 5. Claude 返回一个 200 token 的修复。 6. 这个循环一天重复 50 次。
成本：
约 0.70 美元 / 轮 × 50 轮 = 35 美元 / 天。
这还只是一个“小工作日”。
真正的有效信号是什么？
30 行真正重要的代码。
你不是付钱让 Claude 修 bug。
你是付钱让 Claude 把整个 repo 读 50 遍，然后从里面找出 30 行。
上下文纪律才是杠杆。模型选择是后面的事。
一旦你真正理解了这一点，后面的每一节都会变得合理。
Token 经济学 101：大多数 vibe coder 根本不了解的单位经济学
在我们开始把账单省下 80% 之前，你必须先理解自己到底在为什么付费。
每一张现代 AI 账单上，都有 4 类 token：
Input tokens
你发送给模型的一切：
prompt、system message、文件内容、对话历史。
它们按每百万输入 token 计价。
Output tokens
模型返回给你的一切：
代码、解释、推理结果。
通常每个 token 比输入 token 贵 3-5 倍。
Cached tokens
最近请求里已经发送过、并被标记为可缓存的输入 token。
价格大约是普通输入成本的 10%。
这是一个被严重低估的 90% 降本空间，大多数人根本没有用起来。
Reasoning tokens
模型在生成输出之前内部使用的“思考”token。
Claude Opus 会消耗这些 token。
你看不到它们，但你仍然会为它们付费。
截至 2026 年中左右的近似价格如下。
发布前请去各厂商页面核对，因为这些价格会变：
• Claude Opus 4.6：约 15 / 75 美元每百万 token，分别对应输入 / 输出。 • GPT-5：约 10 / 40 美元。 • Claude Sonnet 4.6：约 3 / 15 美元。 • Claude Haiku 4.5：约 1 / 5 美元。 • Kimi 2.6（Moonshot）：约 0.50 / 2 美元。
最贵选项和最便宜付费选项之间，输入价格大约差 30 倍，输出价格大约差 35 倍。
特别注意 Sonnet 4.6 和 Kimi 2.6 之间的差距：
输入便宜 6 倍。
输出便宜 7.5 倍。
对 95% 的严肃编码工作来说，最终交付质量的差距几乎看不出来。
很多 vibe coder 正在用 Sonnet 的价格，支付 6 倍成本，买一个 Kimi 也能以同等质量交付的结果。
后面我们会用真实数字说明，哪些任务应该发给哪个模型。
现在先诊断你的浪费。
2. 每个 vibe coder 都会踩的 5 个 token 陷阱
下面这 5 件事，把我的账单推到了每月 4200 美元。
把它们逐个修掉，你就能拿回大部分浪费。
陷阱 1：每一轮都重新发送整个 repo
发生了什么：
Cursor 或 Claude Code 的 auto-context 功能，会在每次 prompt 里包含同样的 30-50 个文件。
这些文件没有变化。
但你每一轮都在为它们付费。
一个 50 文件上下文，大约是 80000 input token。
按 Opus 价格算，每轮大约 1.20 美元。
每天 50 轮，就是 60 美元一天，也就是每月 1800 美元。
而这只是重复发送未变化上下文的成本。
解决办法：
• 关闭稳定文件的 auto-context。通过 prompt caching 只包含一次。 • 在问模型之前先用 grep / ripgrep。只发送相关函数或代码块。 • 在 Cursor 里，日常工作不要默认使用 @codebase，改用具体的@file引用。• 在 Claude Code 里，依赖 agent 自己的 grep 工具，而不是提前把文件全塞进去。
这一项单独就能在稳定会话里节省 60%-80% 的输入 token。
陷阱 2：工具调用循环失控
发生了什么：
Agent 调用一个工具。
拿到数据。
重新发送完整上下文。
再调用另一个工具。
再重新发送。
再调用第三个工具。
再重新发送。
Agent 每说一次“让我检查一下”，你都可能在重新支付完整输入成本。
等 agent 真正找到答案时，你已经为同一个 50000 token 上下文付了 5 次钱。
解决办法：
• 批量处理相关工具调用。让 agent 在执行前先规划工具调用。 • 强力摘要工具输出。不要把原始输出直接塞回上下文。 • 对已知工作流，用确定性的 Python helper 替代 agentic tool loop。 • 对工具调用做 profiling。连续一周记录每次调用的输入 / 输出 token，找出失控循环。
节省效果：
agentic flow 成本降低 3-5 倍。
陷阱 3：把高级模型用在便宜模型就能处理的任务上
发生了什么：
你让 Opus 去“修一个错别字”“格式化 JSON”“全局重命名变量”。
模型思考 12 秒，烧掉 8000 个 reasoning token，然后返回答案。
成本是 0.60 美元。
而 Haiku 本来 0.02 美元就能搞定。
更糟的是：
你让 Sonnet 重构一个 500 行文件。
输出成本 0.12 美元，14 秒交付。
同样的重构，用 Kimi 2.6 成本 0.04 美元，16 秒交付，而且生产里看不出差异。
解决办法：
• 设置路由器。琐碎任务默认走 Haiku 或本地模型。 • 真正的实现工作，默认用 Kimi 2.6，而不是 Sonnet。编码任务上的交付质量相同，成本只是零头。 • 把 Opus / GPT-5 留给那 10% 会产生复利影响的决策，比如架构和复杂重构。
我自己的一个真实例子，让我彻底看清了这件事：
我的 agentic refactor loop 以前全程跑在 Opus 上。
平均每次成本是 18-24 美元。
后来我只保留规划步骤用 Opus，一次调用。
后面 25-30 个迭代步骤全部路由到 Kimi 2.6。
同一个 workflow。
同样交付代码。
同样测试通过。
新成本是每次 1.40 美元。
高级模型并没有在迭代步骤里做出高级质量的工作。
Kimi 2.6 一行一行都能匹配。
我之前只是为这个循环根本不需要的能力付费。
节省效果：
• cleanup / format / lint 层可以节省 95%。 • 对每一步都是中等难度的长 agentic loop，可以节省 10-15 倍。
陷阱 4：该批处理时用了流式，或者反过来
发生了什么：
在某些工作流里，流式响应可能会破坏 prompt caching。
而本该流式交互时使用批处理，又会浪费用户时间。
解决办法：
• 对 stable-prefix workflow，使用批处理响应。cached prompt 配合批处理效果更好。 • 对交互式编码，使用流式响应，让体验更顺。 • 对不需要用户反馈的后台 agent，始终使用批处理。
节省效果：
当缓存前缀和批处理配合正确时，可以节省 30%-50%。
陷阱 5：“以防万一”导致上下文膨胀
发生了什么：
你不确定 Claude 是否需要 utils.ts，所以把它加进去。
你不确定它是否需要测试文件，所以也加进去。
你不确定它是否需要 schema，所以也加进去。
于是一个“修这个 bug”的 prompt，变成了 80000 token。
解决办法：
• 先 grep / ripgrep。如果 grep 找不到引用，模型通常不需要这个文件。 • 让 agent 主动请求它需要的文件，不要提前自愿塞进去。 • 在长会话里，定期摘要旧上下文，然后丢掉原文。 • 用 CLAUDE.md/ system prompt 把静态上下文编码一次，然后缓存它。
节省效果：
输入 token 可节省 70% 以上。
现在开始构建修复方案。
3. 路由架构：停止用一个模型处理所有事情
这是你能做的最大改变。
根据任务类型，把工作拆给多个模型。
大多数 vibe coder 用一个模型处理所有事情。
要么他们全程用 premium 模型，比如每个任务都用 Opus，成本很高。
要么他们全程用 budget 模型，比如每个任务都用 Haiku，真正重要的任务质量下降。
大多数人默认的中间路线，是所有事情都用 Sonnet。
这是两头都不占优：
你支付了不必要的 6 倍成本，而且高强度工作日还会撞 rate limit。
聪明的做法是：
用一个路由器，根据任务选择正确模型，并让 Kimi 2.6 承担大部分真实编码工作。
路由决策树：
1. 这是规划 / 架构任务吗？ 使用 Premium tier，比如 Opus 4.6 或 GPT-5。那 10% 会产生复利影响的决策，值得花钱。
2. 这是实现、代码审查、重构、调试，或者任何严肃编码工作吗？ 使用 Kimi 2.6。它是你的日常主力。它在交付质量上匹配 Sonnet，成本低 6 倍，而且没有那么多 rate limit 麻烦。
3. 这是一个有很多轮迭代的长 agentic loop 吗？ 还是 Kimi 2.6。成本优势会在每一次迭代里继续放大。
4. 这是 lint、format、单行修改或琐碎修复吗？ 使用 Utility tier，比如 Haiku 4.5，或者直接用 IDE 的 autocomplete。
5. 这是 boilerplate、autocomplete 或 stub generation 吗？ 使用 Local tier，比如通过 Ollama 跑 Qwen 3。免费。
大多数 vibe coder 从来没有搭过这套东西，因为工具默认只给你一个模型。
但现在每个现代 AI 编程工具都支持自定义模型：
Cursor、Aider、Claude Code、Windsurf，全都可以。
搭一个路由器需要 30 分钟。
在你做任何其他事情之前，它就能把账单砍掉 50%-70%。
4. 模型分层：为每个任务选对模型
知道该把任务发给哪个模型，已经赢了一半。
下面是不带营销话术的真实定位。
Premium Tier：用于会产生复利影响的决策
Claude Opus 4.6
高级架构师。
这一组里判断力最好，成本最高，约 15 / 75 美元每百万 token。
用于系统设计、安全关键审查、复杂多文件重构、并发调试。
大约只有 10% 的工作真正属于这里。
GPT-5.5
推理能力接近 Opus，价格层级相近，约 10 / 40 美元。
在数学任务和形式化证明上经常领先。
在长上下文连贯性和代码判断上略弱一点。
Workhorse Tier：你的日常主力
Kimi 2.6（Moonshot）
现代 AI 编码栈里真正的主力，约 0.50 / 2 美元。
这里是大多数人最容易判断错的地方，所以我直接说：
Kimi 2.6 在大多数编码任务上匹配或超过 Sonnet 4.6，同时成本低 6 倍。
我跑过的 benchmark 显示，Kimi 2.6 在重构、调试、代码生成上达到了 Sonnet 的质量，有时还略微领先。
“Kimi 是便宜选项”这种 2025 年的说法已经过时。
到了 2026 年，Kimi 2.6 是你应该默认使用的选项。
Sonnet 只应该保留给少数它确实有特定优势的任务。
Kimi 2.6 明显胜出的地方：
• 长 agentic loop，10 次以上迭代。 每次迭代都是一个小而明确的步骤。跑一个 30 步重构 agent：Opus 约 25 美元，Sonnet 约 5 美元，Kimi 约 1 美元。同样的交付代码。Kimi 在迭代间保持状态的能力和 Sonnet 一样好。 • 中高复杂度代码生成。 CRUD endpoint、脚手架、多文件功能实现。Kimi 的代码质量持续处在 Sonnet 同一档，价格是 1/6。 • 大规模重构。 当你重写 500 行文件时，Sonnet 的边际质量差异并不会体现在最终 diff 里。Kimi 的输出同样能通过测试。 • 后台持续运行的 agent。 一个 24/7 monitoring agent 用 Sonnet 跑，每月 200-400 美元。用 Kimi 跑，同样的 agent 每月 15-30 美元。Sonnet 版本算不过账，Kimi 版本算得过。 • 高吞吐批处理任务。 如果你的工作流被 Sonnet rate limit 卡 30 分钟，那么更便宜的模型在实践里反而也是更快的模型。Moonshot 的 rate limit 宽松得多。 • 长上下文工作。 Kimi 2.6 的 256k context window 在高区间可以匹配或超过 Sonnet 的连贯性。“大上下文就用 Sonnet”这条一年前的规则已经不成立了。
我仍然会用其他模型的少数场景：
• 架构和系统设计决策：Opus 或 GPT-5，premium tier，约 10% 的工作。 • 生产 PR 的安全关键代码审查：Opus。 • 高度专业化领域，比如形式化验证、小众编译器：premium tier。
注意，不在这个列表里的是什么：
严肃实现、调试、代码审查、重构、agentic flow。
这些现在都属于 Kimi 2.6。
有效的框架是：
premium 模型处理 10% 会产生复利的决策。
Kimi 2.6 处理 90% 的严肃交付工作。
Haiku / local 处理那 10% 纯 cleanup。
Sonnet 最后只剩下一小部分“我确实想用 Claude 某个特定习惯”的场景。
这没问题。
但它不应该是默认值。
Utility Tier：清理和执行
Claude Haiku 4.5
初级工程师。
快，便宜，约 1 / 5 美元。
用于 lint、format、单行修改、变量重命名、简单 stub 生成。
多步任务质量会下降，但它非常适合那些不需要思考的任务。
GPT-5 mini / o4-mini
OpenAI 生态里的 Haiku 等价物。
价格层级和使用场景类似。
选哪个，取决于你的工具已经更好集成了哪个。
Local Tier：零成本
Qwen 3 / Llama 3（via Ollama）
跑在你的笔记本上。
每个 token 成本为 0。
最适合 autocomplete、typing、boilerplate、语法修复。
不适合多步推理，也不适合任何需要微妙判断的任务。
诚实结论
• 如果你只能有一个模型：Kimi 2.6 是 2026 年的正确选择。它以高质量覆盖 90% 的场景，成本低于一个 Sonnet 订阅。 • 如果你想要双模型栈：Kimi 2.6 + Opus。Kimi 负责日常，Opus 负责 premium 决策。这是轻量但专业的配置。相比全 Sonnet 基线，大约能省 70%。 • 如果你在规模化交付：完整路由，也就是 Opus / Kimi / Haiku / Local，是唯一能在保持关键任务质量的同时让账单保持理性的方式。
大多数 vibe coder 的错误，是因为 2024-2025 年的营销惯性而默认使用 Sonnet。
2026 年的成本 - 质量关系已经不同。
Kimi 2.6 缩小了质量差距，但价格差距仍然很大。
继续把 Sonnet 当作 2026 年默认模型，等于把 60%-70% 的账单白白留在桌上。
下面进入实用技巧。
5. 不降低质量砍成本的 7 个实用技巧
把下面所有技巧都落地，你就可能达到我的效果，把 AI 编程账单砍掉 80%。
如果你不知道怎么应用到自己的 workspace，可以在评论区或私信问。
技巧 1：在所有可用地方开启 prompt caching
Anthropic、OpenAI、Moonshot，现在都支持 prompt caching。
Cached token 的成本大约是普通输入的 10%。
把稳定上下文放进 cached prefix：
CLAUDE.md、system instructions、codebase summary。
把工作组织成 5 分钟左右的片段，因为 cache 有 TTL。
• Claude Code：system prompt 和 CLAUDE.md的 caching 通常是自动的。• Cursor：在 settings → models 里开启 “use prompt caching”。 • Aider：传入 --cache-prompts。
节省效果：
稳定输入 token 可节省 60%-90%。
技巧 2：先 grep，再取文件
不要“以防万一”就包含某个文件。
先 grep 符号或模式。
只包含真正重要的东西。
rg "useUserAuth" --type ts -l # find filesrg "useUserAuth" --type ts -B 5 -A 20 # find usage with context大多数“我需要整个文件”的直觉都是错的。
90% 的时候，30 行就够了。
技巧 3：Profile 你的工具调用
连续一周记录每次工具调用的输入 / 输出 token。
你会发现哪些 loop 会失控，哪些工具会重复获取同一份数据 10 次。
Claude Code 的快速记录方式：
开启 --verbose-tools，并把输出 pipe 到文件里。
然后用 grep 分析，找到最大的 token sink。
大多数 vibe coder 只要修掉最糟糕的 3 个工具循环，就能节省 30%-50%。
技巧 4：使用 Graduated Skill Pattern
一旦某个 workflow 跑通，就把它保存成 SKILL.md 文件。
下一次 agent 加载这个 skill，就可以完全跳过发现阶段。
例子：
我的“部署到 staging”工作流，过去每次用 Opus 跑要 4 美元，因为 agent 每次都要重新理解环境。
后来我把它写成一个 SKILL.md，并把 runner 切到 Kimi 2.6。
现在每次成本是 0.18 美元，交付结果一样。
这也是 Browserbase 的 Autobrowse 用在浏览器 agent 上的模式。
一旦一个 workflow 被捕获成 skill，后续运行成本会低一个数量级。
这个原则同样适用于编码。
技巧 5：用本地模型处理 boilerplate 和 autocomplete
Qwen 3 / Llama 3 通过 Ollama 跑在你的笔记本上。
每个 token 成本为 0。
适合：
• autocomplete • typing • simple completions • syntax fixes • stub generation
不要用于：
• complex reasoning • anything multi-step • anything where quality matters
安装需要 5 分钟：
brew install ollamaollama pull qwen3:7bollama serve然后把你的 IDE autocomplete 指向 localhost:11434。
节省效果：
boilerplate 层节省 100%。
技巧 6：在长会话中激进摘要
每 10-15 轮，让 agent 总结已经完成了什么、下一步是什么。
丢掉原始对话上下文。
从摘要开始下一批工作。
一个 200k token 的会话，可以压缩成 5k token 的摘要。
下一批从摘要开始，成本只有继续原会话的 5%。
大多数 vibe coder 从不这么做，因为工具不会主动提醒他们。
设置一个 30 分钟计时器。
技巧 7：批量处理你的“小请求”
不要把 10 个小问题拆成 10 次问模型。
10 次独立 API call，就意味着 10 次独立的输入前缀计费。
把它们合并成一个 prompt：
“请按 1-10 编号回答下面 10 个问题……”
节省效果：
对批处理工作流，输入 token 可节省 70%-90%。
配合 prompt caching 时尤其强。
下面看证明它有效的数字。
6. 真实任务成本 benchmark
我用主流模型跑了同样 4 个任务。
这些数字是说明性的。
你自己的 benchmark 会随任务类型和代码库变化。
但真正重要的是形状。
任务：重构 500 行文件
Opus 4.6：0.42 美元 / 18s / 9.5
GPT-5：0.32 美元 / 16s / 9.4
Sonnet 4.6：0.12 美元 / 14s / 9.0
Kimi 2.6：0.04 美元 / 16s / 9.2
任务：构建 CRUD endpoint
Opus 4.6：0.18 美元 / 22s / 9.0
GPT-5：0.14 美元 / 20s / 9.0
Sonnet 4.6：0.06 美元 / 18s / 9.0
Kimi 2.6：0.02 美元 / 17s / 9.0
任务：调试 stack trace
Opus 4.6：0.08 美元 / 11s / 9.5
GPT-5：0.07 美元 / 10s / 9.4
Sonnet 4.6：0.03 美元 / 9s / 9.0
Kimi 2.6：0.01 美元 / 10s / 9.1
任务：架构方案
Opus 4.6：0.65 美元 / 28s / 9.8
GPT-5：0.50 美元 / 26s / 9.7
Sonnet 4.6：0.22 美元 / 24s / 8.5
Kimi 2.6：0.08 美元 / 25s / 9.2
几个值得注意的点：
• Kimi 2.6 在 4 个任务上都匹配或超过 Sonnet 4.6 的质量，同时成本低 3-4 倍。 • Kimi 2.6 距离 Opus / GPT-5 只差 0.3-0.6 个质量分，但成本只有大约 1/10。 • Haiku 很快，但在大多数任务上质量低于 7.0，只适合琐碎工作。 • Opus / GPT-5 只有在架构决策上明显领先，而那里边际质量真的重要。
合理解读是：
把 10% 的架构工作路由到 premium 模型。
把 90% 的常规严肃工作路由到 Kimi 2.6。
把 cleanup 层交给 Haiku / 本地模型。
Sonnet 最后只剩下一小部分边缘场景，比如长文生成、某些 Claude 特定模式。
这没问题。
但它不是默认值。
你这一周交付的质量是相近的。
月底账单不是。
7. 我的精确路由配置
这是我正在运行的实际配置。
你自己的配置需要调优，但这是一个起点。
# ~/.config/claude-router/config.yaml# Kimi 2.6 is the default for nearly all serious workdefault: kimi-2.6-instructroutes: # planning / architecture / complex decisions planning: model: claude-opus-4-6 fallback: gpt-5 triggers: - "plan" - "architect" - "design system" - "refactor architecture" - "security review" # serious implementation, code review, debugging, refactoring (the bulk of real work) implementation: model: kimi-2.6-instruct triggers: - "review" - "debug" - "cross-file refactor" - "implement" - "build feature" # most coding tasks (default workhorse, same as implementation, Kimi 2.6) default_implementation: model: kimi-2.6-instruct # cleanup, lint, format, single-line edits cleanup: model: claude-haiku-4-5 triggers: - "lint" - "format" - "fix typo" - "rename variable" # boilerplate, autocomplete (local, free) boilerplate: model: ollama:qwen3:7b triggers: - "autocomplete" - "stub" - "generate boilerplate"caching: enabled: true prefix_cache: truecontext: max_tokens: 50000 auto_summarize_after: 15 # turns use_grep_first: true把它粘到你的 Claude Code 或 Cursor 配置里。
路径因工具而异，请查看对应工具文档里的 “custom routing” 或 “model selection”。
配置前：
4200 美元 / 月。
配置后：
312 美元 / 月。
比例：
只剩原来的 7.5%。
关键任务质量：
不变。
8. 30 天把账单砍掉 80% 的计划
如果你想结构化推进，而不是一次性全改，可以按下面这样做。
第 1 周：止血
• 在你使用的任何工具里开启 prompt caching。 • 关闭稳定文件的 auto-context。 • 安装 ripgrep，开始先 grep 再问模型。 • 预期节省：30%-40%。
第 2 周：把默认模型切到 Kimi 2.6
这是结构性的一周。
前面的技巧是在削掉浪费。
切换默认模型，才是真正改变单位经济模型。
• 设置工具的 custom model config。 • 把默认 workhorse 路由到 Kimi 2.6。这是整个 30 天里最大的动作。大多数 vibe coder 还在因为习惯默认使用 Sonnet 4.6，为质量等价的交付代码支付 6 倍价格。 • 把 lint / format 路由到 Haiku。 • Opus / GPT-5 只保留给 planning tier。 • 预期额外节省：40%-55%。大部分降本都来自这一次切换。
第 3 周：Profile 并修复工具循环
• 开启一周 verbose tool logging。 • 找出最贵的 3 个 tool loop。 • 用批量调用或 deterministic helper 替代。 • 预期额外节省：10%-20%。
第 4 周：Graduated Skills + 本地模型
• 找出 3 个你反复执行的 workflow，把每个都写成 SKILL.md。• 设置 Ollama + Qwen 3，用于 autocomplete 和 boilerplate。 • 把琐碎任务路由到本地模型。 • 预期额外节省：5%-10%。
累计效果：
30 天内账单降低 70%-85%。
而且不损失交付速度。
9. 什么时候应该多花钱：Premium 仍然赢的 10%
降本是有边界的。
有些任务确实需要 premium 模型。
强行让便宜模型做这些任务，重试和修 bug 的成本可能比节省下来的钱更高。
以下任务始终使用 Opus / GPT-5：
• 系统架构决策。 • 安全关键代码审查。 • 带有横切关注点的复杂多文件重构。 • 并发 / race condition 调试。 • 编译器 / 形式化验证工作。
规则是：
如果一个错误答案的成本超过模型差价的 100 倍，就用 premium 模型。
一个 0.50 美元的规划错误，可能让你浪费一周。
一个 0.05 美元的小修复出错，30 秒就能恢复。
根据失败成本给模型定价，而不是根据单次调用成本定价。
中间的大多数任务，比如严肃实现、重构、代码审查、非并发级调试，Kimi 2.6 是正确选择。
“为了保险就用 premium 模型”的本能，正是你之前烧钱的原因。
更大的图景
你在 token 上省下的每一美元，都可以用来交付更多东西。
2027 年赢下来的开发者，不会是拥有最好模型的人。
他们会是拥有最好上下文纪律和最聪明路由的人。
未来 12 个月里，每月 200 美元预算也能交付的人，和每月 4000 美元预算还在烧钱的人，差距不会是技能。
差距会是路由能力。
希望你选择正确的路，也不要懒到不去实现这篇文章里的所有技巧。
觉得有收获？请 点赞、转发 和 关注 ，让更多工程师看到这篇文章~
