如何将 AI 编码账单削减 80%：方法论整理版

摘录2026年5月14日7 次阅读约 19 分钟

来源：https://x.com/DeRonin_/status/2054255152555545079
主题：通过上下文控制、模型路由、Prompt 缓存和工作流治理，降低 AI 编码成本。
适用对象：高频使用 Cursor、Claude Code、Aider、Windsurf 等 AI 编码工具的开发者。

1. 核心结论

这篇文章的核心观点不是“换一个更便宜的模型”，而是：

AI 编码账单高，主要不是因为模型贵，而是因为上下文发送方式和工作流设计太浪费。

作者将自己的 AI 编码账单从：

$4,200 / 月
降到 $312 / 月

主要依靠三类动作：

更聪明的模型路由
Prompt Caching
修复工作流中 5 类 token 泄漏点

最终目标是：

不降低交付速度
不降低关键任务质量
将月度 AI 编码成本降低 50%–80%

2. 最重要的认知：你付费的不是 token，而是上下文

很多人以为 AI 编码成本高，是因为模型本身贵。

但作者认为真正的问题是：

你每一轮都在把大量无关上下文发给模型。

典型场景：

打开 Cursor / Claude Code
工具自动加载大量代码仓库上下文
用户只想修一个小 bug
模型却要阅读几十万字符的上下文
最后只改了 20–30 行代码

问题不在输出，而在输入。

关键判断

错误做法	正确做法
把整个仓库或大量文件直接丢给模型	先搜索，再只提供相关代码块
默认使用 `@codebase`	使用具体文件、函数、调用链
每轮重复发送稳定上下文	使用 Prompt Caching
一个模型处理所有任务	根据任务类型路由到不同模型

3. Token 成本结构

现代 AI 编码账单通常由 4 类 token 构成。

类型	含义	成本特征
Input Tokens	发送给模型的内容，包括 prompt、文件、历史对话、系统提示	通常按百万 token 计费
Output Tokens	模型返回的内容，包括代码、解释、推理结果	通常比输入 token 贵 3–5 倍
Cached Tokens	被缓存的重复输入上下文	价格通常只有普通输入 token 的约 10%
Reasoning Tokens	模型内部推理消耗的 token	用户不可见，但仍会计费

重要结论

输出贵，但输入浪费更常见。
Prompt Caching 是很多人忽略的降本点。
高级模型的 reasoning tokens 可能在简单任务中造成隐性浪费。

4. 五个常见 token 陷阱

陷阱 1：每一轮都重新发送整个代码仓库

问题

AI 编码工具可能会在每次请求中自动包含大量文件。

这些文件多数没有变化，但每次调用都会重新计费。

典型浪费

50 个文件
约 80,000 input tokens
每天几十轮调用
每月可能浪费上千美元

修复方式

关闭不必要的自动上下文
日常任务避免默认使用 @codebase
使用明确的 @file
先用 grep / ripgrep 搜索相关代码
只发送函数、类、调用链、错误堆栈相关内容
稳定上下文放入可缓存区域

预期效果

输入 token 可减少 60%–80%。

陷阱 2：Agent 工具调用循环失控

问题

Agent 每调用一个工具，可能都会重新携带完整上下文。

例如：

查文件
查引用
查日志
查测试
再查配置

如果每一步都重复传入完整上下文，成本会快速放大。

修复方式

让 Agent 先规划工具调用，再执行
将相关工具调用批量化
对工具输出做摘要，不要把完整原始结果回填上下文
对固定流程使用脚本替代 Agent 循环
记录工具调用 token 消耗，持续观察一周

预期效果

Agent 工作流成本可降低 3–5 倍。

陷阱 3：用高级模型处理简单任务

问题

很多人会让 Opus、GPT-5、Sonnet 处理所有任务，包括：

修 typo
格式化 JSON
重命名变量
生成简单样板代码
修复 lint

这些任务不需要高级推理。

修复方式

根据任务复杂度选择模型：

任务类型	推荐模型层级
架构设计、安全审查、复杂决策	Opus / GPT-5
真实编码、调试、重构、代码审查	Kimi 2.6
lint、format、单行修改	Haiku / mini 模型
自动补全、样板代码	本地模型

预期效果

简单任务成本可下降 90%+
长 Agent 循环成本可下降 10–15 倍

陷阱 4：流式与批量模式使用不当

问题

有些工作流中，流式响应会影响 Prompt Caching 的效果。

反过来，如果交互式编码场景完全使用批量响应，也会降低体验。

修复方式

场景	推荐方式
用户正在交互式编码	Streaming
后台 Agent 执行任务	Batch
稳定上下文 + 可缓存前缀	Batch
需要快速看到中间结果	Streaming

预期效果

缓存前缀调用可节省 30%–50%。

陷阱 5：“以防万一”的上下文膨胀

问题

开发者经常因为不确定模型是否需要某个文件，就把它也加入上下文。

结果是：

一个小 bug 请求
变成了几十个文件
prompt 达到数万甚至十几万 token

修复方式

先搜索引用，再决定是否提供文件
让 Agent 自己请求需要的文件
长会话中定期总结旧上下文
总结后丢弃原始对话
使用 CLAUDE.md 或系统提示保存稳定背景信息

预期效果

输入 token 可减少 70%+。

5. 推荐的模型路由架构

文章建议停止“一个模型打天下”，改成模型分层。

路由决策树

任务是架构 / 规划 / 安全关键决策？
    -> 使用 Premium Tier：Opus / GPT-5

任务是实现 / 调试 / 重构 / 代码审查？ -> 使用 Workhorse Tier：Kimi 2.6

任务是多轮 Agent 循环？ -> 使用 Kimi 2.6

任务是 lint / format / typo / 单行修改？ -> 使用 Utility Tier：Haiku / mini 模型

任务是样板代码 / 自动补全？ -> 使用 Local Tier：Qwen / Llama via Ollama

6. 模型分层建议

层级	推荐模型	适合任务	不适合任务
Premium Tier	Claude Opus / GPT-5	架构设计、安全关键审查、复杂多文件重构、并发问题	日常简单编码
Workhorse Tier	Kimi 2.6	日常实现、重构、调试、代码审查、Agent 循环	极高风险架构决策
Utility Tier	Haiku / GPT mini	lint、format、变量重命名、简单修复	多步骤复杂任务
Local Tier	Qwen / Llama via Ollama	自动补全、样板代码、stub、语法修复	复杂推理和高质量判断

7. 七个实用降本技巧

技巧 1：启用 Prompt Caching

适用工具：

Claude Code
Cursor
Aider
支持缓存的 API 工具链

建议缓存内容：

系统提示
项目约定
CLAUDE.md
代码库摘要
开发规范
稳定工具说明

预期节省：

稳定输入 token 降低 60%–90%

技巧 2：先 grep，再提问

不要直接把文件丢给模型。

先搜索：

rg "useUserAuth" --type ts -l
rg "useUserAuth" --type ts -B 5 -A 20

推荐流程：

搜索符号
找到调用链
截取相关函数
附上错误日志
再让模型分析

技巧 3：分析工具调用

建议记录：

每次工具调用名称
输入 token
输出 token
是否重复查询
是否可以批量化
是否可以脚本化

目标是找到最贵的 3 个循环。

技巧 4：把稳定流程写成 `SKILL.md`

重复性工作不要每次都让 Agent 重新摸索。

适合固化为 Skill 的流程：

发布到测试环境
生成接口文档
跑测试并修复
检查日志
数据库迁移
前端构建发布
代码审查规范

示例结构：

# Deploy to Staging Skill

`Goal`

Deploy the current branch to staging safely.

`Steps`

Check current branch
Run tests
Build project
Package artifact
Deploy to staging
Verify health check

`Common Errors`

Port occupied
Missing environment variable
Failed migration

`Verification`

Health check returns 200
Logs contain no startup errors

技巧 5：本地模型处理样板代码

使用 Ollama：

brew install ollama
ollama pull qwen3:7b
ollama serve

本地模型适合：

自动补全
生成 DTO / VO / Entity
简单模板代码
基础注释
单文件小改动

不适合：

架构判断
跨模块重构
并发 bug
安全审查

技巧 6：长会话定期总结

每 10–15 轮对话后，让模型输出：

## 已完成

...

`当前结论`

...

`关键文件`

...

`未解决问题`

...

`下一步`

...

然后开启新会话，把总结作为新上下文。

目标：

用 5k token 的总结替代 200k token 的历史对话。

技巧 7：批量处理小请求

错误方式：

问 10 次，每次一个小问题。

正确方式：

请一次性回答下面 10 个问题，按编号输出：

...
...
...

适合批量处理的内容：

代码解释
命名建议
小 bug 分析
SQL 优化点
文档润色
测试用例生成

8. 示例路由配置

# ~/.config/claude-router/config.yaml

default: kimi-2.6-instruct

routes: planning: model: claude-opus-4-6 fallback: gpt-5 triggers: - "plan" - "architect" - "design system" - "refactor architecture" - "security review"

implementation: model: kimi-2.6-instruct triggers: - "review" - "debug" - "cross-file refactor" - "implement" - "build feature"

default_implementation: model: kimi-2.6-instruct

cleanup: model: claude-haiku-4-5 triggers: - "lint" - "format" - "fix typo" - "rename variable"

boilerplate: model: ollama:qwen3:7b triggers: - "autocomplete" - "stub" - "generate boilerplate"

caching: enabled: true prefix_cache: true

context: max_tokens: 50000 auto_summarize_after: 15 use_grep_first: true

9. 30 天落地计划

第 1 周：先止血

目标：减少明显浪费。

行动：

启用 Prompt Caching
关闭不必要的自动上下文
安装并使用 ripgrep
不再默认使用 @codebase
只发送相关代码片段

预期节省：

30%–40%

第 2 周：切换默认模型

目标：改变单位经济模型。

行动：

配置自定义模型
将日常实现任务默认路由到 Kimi 2.6
将 lint / format 路由到 Haiku
将 Opus / GPT-5 保留给架构和安全任务

预期额外节省：

40%–55%

第 3 周：治理 Agent 工具循环

目标：减少重复调用和失控循环。

行动：

开启工具调用日志
统计每类工具调用 token 消耗
找出最贵的 3 个循环
改成批量调用或脚本化流程

预期额外节省：

10%–20%

第 4 周：沉淀 Skill + 本地模型

目标：减少重复探索和低价值 token 消耗。

行动：

找出 3 个高频工作流
每个写成 SKILL.md
配置 Ollama + Qwen
将样板代码和自动补全交给本地模型

预期额外节省：

5%–10%

10. 什么时候应该使用高级模型

降本不能无脑降。

以下任务应该使用 Opus / GPT-5：

系统架构设计
安全关键代码审查
涉及多个模块的复杂重构
并发问题 / 竞态条件排查
编译器 / 形式化验证
高风险生产问题

判断规则

如果一个错误答案的代价超过模型成本差异的 100 倍，就使用高级模型。

示例：

任务	推荐模型
改一个变量名	Haiku / 本地
生成 DTO	本地 / Haiku
实现普通 CRUD	Kimi 2.6
重构 500 行业务代码	Kimi 2.6
设计权限系统架构	Opus / GPT-5
审查支付链路安全问题	Opus / GPT-5
排查高并发数据一致性问题	Opus / GPT-5

11. 可执行检查清单

上下文控制

[ ] 是否默认关闭了不必要的自动上下文？
[ ] 是否避免无脑使用 @codebase？
[ ] 是否先 grep 再提问？
[ ] 是否只发送必要函数 / 类 / 日志？
[ ] 是否定期总结长会话？

模型路由

[ ] 是否区分架构、实现、清理、样板代码？
[ ] 是否避免高级模型处理简单任务？
[ ] 是否设置默认工作模型？
[ ] 是否为高风险任务保留高级模型？

Prompt Caching

[ ] 是否启用 Prompt Caching？
[ ] 是否将稳定上下文放入缓存前缀？
[ ] 是否复用项目规范和系统提示？

Agent 工作流

[ ] 是否记录工具调用？
[ ] 是否找出重复工具循环？
[ ] 是否将稳定流程写成 Skill？
[ ] 是否将固定流程脚本化？

本地模型

[ ] 是否安装 Ollama？
[ ] 是否配置 Qwen / Llama？
[ ] 是否将自动补全和样板代码交给本地模型？

12. 对开发者的实际启发

这篇文章真正值得借鉴的不是具体某个模型，而是它的工作方式：

不要把 AI 当聊天窗口，而要当可治理的工程系统。
不要只优化 prompt，要优化上下文、路由和流程。
不要把所有任务都交给最贵模型。
不要重复让 Agent 探索同一个流程。
不要忽略输入 token 的浪费。

最终目标不是少用 AI，而是：

用更低成本，获得相同甚至更稳定的交付能力。

13. 一句话总结

AI 编码降本的核心不是“少用模型”，而是“少传废上下文、按任务选模型、把重复流程沉淀成规则”。

1. 核心结论

2. 最重要的认知：你付费的不是 token，而是上下文

关键判断

3. Token 成本结构

重要结论

4. 五个常见 token 陷阱

陷阱 1：每一轮都重新发送整个代码仓库

陷阱 2：Agent 工具调用循环失控

陷阱 3：用高级模型处理简单任务

陷阱 4：流式与批量模式使用不当

陷阱 5：“以防万一”的上下文膨胀

5. 推荐的模型路由架构

路由决策树

6. 模型分层建议

7. 七个实用降本技巧

技巧 1：启用 Prompt Caching

技巧 2：先 grep，再提问

技巧 3：分析工具调用

技巧 4：把稳定流程写成 SKILL.md

Goal

Steps

Common Errors

Verification

技巧 5：本地模型处理样板代码

技巧 6：长会话定期总结

当前结论

关键文件

未解决问题

下一步

技巧 7：批量处理小请求

8. 示例路由配置

9. 30 天落地计划

第 1 周：先止血

第 2 周：切换默认模型

第 3 周：治理 Agent 工具循环

第 4 周：沉淀 Skill + 本地模型

10. 什么时候应该使用高级模型

判断规则

11. 可执行检查清单

上下文控制

模型路由

Prompt Caching

Agent 工作流

本地模型

12. 对开发者的实际启发

13. 一句话总结

技巧 4：把稳定流程写成 `SKILL.md`

`Goal`

`Steps`

`Common Errors`

`Verification`

`当前结论`

`关键文件`

`未解决问题`

`下一步`