如何把Claude Code费用降低3倍 Karpathy上下文工程的实战应用

Q: Q: 我不是用 Supabase 或 InsForge 的用户，这些技巧对我有什么用？

A: 核心原理适用于 所有 AI 编码场景： 1. 减少 MCP 调用 — 倾向于用 Skill/CLI 文档代替实时的 API 说明书查询 2. 给 Agent 足够的结构化上下文 — 用一个初始的 /init 或文件读取，让 Agent 在写代码前就了解项目 3. 用 /compact 压缩长对话 — 防止上下文膨胀加剧消耗 4. 一个对话只做一件事 — 防止历史上下文按数量级增加 Token 成本 这些原则适用于任何 AI 编码工具，不限于某个特定后端。

Q: Q: 如何监控自己的 Claude Code Token 消耗？

A: 1. 命令行检查 ：在会话中使用 /cost 命令查看当前会话的成本 2. CLAUDE.md 设置预算提醒 ：在 CLAUDE.md 中加入成本控制规则 3. 建立检查习惯 ：每 30 45 分钟运行一次 /cost ，或每次 /compact 时顺便检查 4. 分阶段使用不同模型 ：规划/架构阶段用 Opus（深度思考），编码实现用 Sonnet（高效省成本） 参考 CLAUDE.md 配置优化指南 了解更多成本控制的配置方法。

Q: Q: 如果我在开发个人项目，每月 Claude Code 费用控制在多少比较合理？

A: 根据使用强度不同： 轻度使用 （每天 30 60 分钟）：建议每月预算 $15 30 中度使用 （每天 2 3 小时）：建议每月预算 $50 100 重度使用 （全职开发者）：建议每月预算 $100 300 关键省钱策略： 1. 规划用 Opus，实现用 Sonnet（可省 50%+） 2. 每个对话只做一件事，频繁 /clear （可省 30%） 3. 善用 /compact 压缩长对话（可省 20%） 参考 AI Agent 团队协作指南 了解更多高效 AI 使用的策略。

基于Karpathy的上下文工程理念，将Claude Code对话成本从$9.21降至$2.81。实战对比Supabase与优化方案，涵盖MCP优化、Skills替代、结构化上下文等技巧。

适合人群

本文适合以下读者：

重度使用 Claude Code 的开发者，希望控制 AI 开发成本
正在搭建全栈 AI Agent 应用的工程师
对 Supabase、MCP 等后端服务的 Token 消耗优化感兴趣的技术爱好者
想了解 Andrej Karpathy「上下文工程」理念实战应用的用户

前置要求：了解 Claude Code、MCP 协议、REST API 等基本概念。

准备清单

✅ Claude Code 已安装（参考 Claude Code 完整配置教程）
✅ 已有全栈开发项目经验
✅ 了解基本的 Token 计费概念
✅ 一个 Supabase 或类似 BaaS 项目（可选，用于对照实验）

操作步骤

背景：一个反直觉的现象

MCPMark V2 基准测试揭示了一个反直觉的现象：模型越聪明，后台 Token 消耗反而越大。

当 Claude 从 Sonnet 4.5 升级到 4.6 后，通过 Supabase MCP 服务器的后台 Token 用量从 1160 万增加到了 1790 万——在 21 个数据库任务中增加了 54%。

原因很微妙，而且和模型本身无关。

当上下文不完整时，更强的模型不会跳过缺口——它会花更多的 Token 来推理缺口、运行更多发现查询、更频繁地重试。所以缺失的上下文不会因为模型更好而消失——只会变得更贵。

为什么 Supabase 的 MCP 服务器浪费 Token

问题 1：文档检索一次性返回全部内容

当 Claude Code 需要设置 Google OAuth 时，它会调用 search_docs MCP 工具。

Supabase 的实现每次调用都返回完整 GraphQL schema 元数据，实际上是 Claude Code 需求量的 5-10 倍。

如果 Agent 只想要 OAuth 设置说明，它却拿到了整个认证文档，包括邮箱密码、Magic Links、手机认证、SAML 和 SSO 等所有章节。

每个 search_docs 调用——包括数据库查询、存储配置、Edge Function 部署——都重复这个模式，返回整个领域的完整元数据。

问题 2：没有后端状态可见性

人类开发者使用时可以打开 Supabase 仪表板一目了然——当前的 Auth 提供商、表结构、RLS 策略、存储桶、部署的 Edge Function——都在一个页面上。

Agent 看不到仪表板。

Supabase 的 MCP 服务器虽然通过 list_tables 和 execute_sql 暴露了一些状态，但没有任何方法能问「我整个后端现在长什么样？」并得到一个结构化的回答。

Agent 只能零敲碎打地拼凑信息：多调用 = 多 Token。

问题 3：无结构化的错误上下文

出问题时（肯定会的，因为 Agent 在猜），Supabase 返回原始错误消息。

人类开发者会看下仪表板，对照日志，然后修正。

Agent 没有这个路径。它得到错误消息，推理可能的原因，尝试修复。修复错了就重试。每次重试重新发送整个对话历史——Token 成本呈复合增长。

这三个机制（文档开销、状态发现、错误重试循环）快速叠加。

Karpathy 的「上下文工程」解决方案

修复方案不是换模型，而是给 Agent 结构化的后台上下文，让它不需要探索和猜测。

Andrej Karpathy 定义「上下文工程」为：「用恰好的信息填充上下文窗口供下一步使用的精湛艺术与科学。」

大多数人把这个概念应用到提示词和 RAG 检索上。但后台也是上下文窗口的一部分——而目前几乎没人优化这一块。

"最重要的是写起游戏来很开心。我用 Claude Code 从零开始构建了整个游戏。你应该给我看看 Agent 的使用方法——我大概只用了 10% 的潜力。Agent 实在太强了。"

—— Andrej Karpathy 在构建游戏后的感慨

实战：3 种降低 Token 成本的核心方法

方法 1：用 Skill 替代 MCP 文档检索

MCP 的「一次性加载全部」模式是 Token 杀手。Skill 模式则不同：

Skill 使用渐进式加载：初始化时只加载元数据（名称、描述，约 70-150 Token/个）。只有在 Agent 判断该 Skill 匹配当前任务时，才加载完整内容。

这意味着即使安装了 100+ 个 Skill，也不会发生上下文膨胀——这是 MCP 的「全有或全无」模式做不到的。

# 正确做法：用 Skill 封装后端操作知识
# 每个 Skill 聚焦一个领域
insforge skill install insforge       # 前端 SDK 模式
insforge skill install insforge-cli   # 后端基础设施管理
insforge skill install insforge-debug # 错误诊断

方法 2：用 CLI 替代 MCP 工具调用

CLI 命令可以通过管道结合 jq、grep、awk 处理，一次调用完成 MCP 需要多次顺序调用才能完成的工作：

# MCP 需要：3 次调用 + 等待 + 解析
# CLI 只需要：1 条命令 + 管道
npx insforge metadata --json | jq '.tables, .auth, .functions'

基准测试显示，CLI + Skill 模式在单用户工作流中的 Token 效率比等价的 MCP 设置高 10-35 倍，成功率接近 100%。

方法 3：结构化 MCP 调用（只查状态，不查文档）

MCP 仍然是有效的——但用于一个更窄的范围：检查当前后端状态。

# 只查状态，不查文档
# 一个调用 + ~500 Token 获取完整的后端拓扑
# 不再需要 search_docs 海量加载

关键设计原则：MCP 用于检查「正在变化」的运行状态，Skill 用于提供「不变」的静态知识。

这与典型的 MCP 使用模式正好相反，也是为什么优化过的后端在等价任务上消耗远少于常规后端的原因。

真实数据对比：Supabase vs 优化方案

为了量化差异，有一项实验在两种后端上用 Claude Code 构建了同一个应用（DocuRAG：用户通过 Google OAuth 登录，上传 PDF，系统分块嵌入文本，存储向量，用户用自然语言提问）：

Supabase 方案：

12 条用户消息（其中 10 条是错误报告）
135 次工具调用
30+ 次 MCP 工具调用
1040 万 Token
成本：$9.21

优化方案（Skill + CLI + 结构化 MCP）：

1 条用户消息
77 次工具调用
0 次 MCP 工具调用
370 万 Token
成本：$2.81

成本差距的 70% 以上来自错误重试循环。Supabase 方案中，Agent 遇到了 Google OAuth 认证问题，花了 8 轮修复代码级问题——而根因在平台层的 verify_jwt 安全网关上，是代码上游的问题。

Claude Code 日常使用中的快速省钱技巧

在等待完整的 Skill + CLI 生态成熟前，以下方法可以立即降低成本：

1. 每个对话只做一件事

# ❌ 不要在同一个对话中混合任务
# ✅ 每类任务新建对话
/clear

2. 用紧凑模式压缩长对话

# 长对话 30 分钟后执行
/compact

3. 先用 /init 建立上下文基线

# 让 Claude Code 理解项目结构，减少初始化查询
/init

更多日常技巧见 Claude Code 35 个进阶技巧。

核心结论

如果 Agent 把 Token 花在发现后端如何工作、猜测配置、因错误消息没有说明问题所在而反复重试——你在为缺失的上下文付费。

修复方案不是更好的模型或更长的上下文窗口。是在 Agent 开始写代码之前给予结构化的后端信息。

这就是应用于后端的上下文工程。

"精心填充上下文窗口——包含正确的信息——是核心技能。"

—— Andrej Karpathy

常见问题

Q: 我不是用 Supabase 或 InsForge 的用户，这些技巧对我有什么用？

A: 核心原理适用于所有 AI 编码场景：

减少 MCP 调用 — 倾向于用 Skill/CLI 文档代替实时的 API 说明书查询
给 Agent 足够的结构化上下文 — 用一个初始的 /init 或文件读取，让 Agent 在写代码前就了解项目
用 /compact 压缩长对话 — 防止上下文膨胀加剧消耗
一个对话只做一件事 — 防止历史上下文按数量级增加 Token 成本

这些原则适用于任何 AI 编码工具，不限于某个特定后端。

Q: 如何监控自己的 Claude Code Token 消耗？

命令行检查：在会话中使用 /cost 命令查看当前会话的成本
CLAUDE.md 设置预算提醒：在 CLAUDE.md 中加入成本控制规则
建立检查习惯：每 30-45 分钟运行一次 /cost，或每次 /compact 时顺便检查
分阶段使用不同模型：规划/架构阶段用 Opus（深度思考），编码实现用 Sonnet（高效省成本）

参考 CLAUDE.md 配置优化指南了解更多成本控制的配置方法。

Q: 如果我在开发个人项目，每月 Claude Code 费用控制在多少比较合理？

A: 根据使用强度不同：

轻度使用（每天 30-60 分钟）：建议每月预算 $15-30
中度使用（每天 2-3 小时）：建议每月预算 $50-100
重度使用（全职开发者）：建议每月预算 $100-300

关键省钱策略：

规划用 Opus，实现用 Sonnet（可省 50%+）
每个对话只做一件事，频繁 /clear（可省 30%）
善用 /compact 压缩长对话（可省 20%）

参考 AI Agent 团队协作指南了解更多高效 AI 使用的策略。

Q: MCP V2 发布后，文中的 MCP 问题是否得到了解决？

A: MCP V2 确实引入了改进的 schema 描述机制和更好的工具发现功能，但仍然没有完全解决「全有或全无」的文档加载问题。理想的做法仍然是：MCP 只查状态，Skill 提供知识。两者分工协作效果最佳。

参考来源

下一步建议

CLAUDE.md 配置优化指南 — 用四原则优化 Claude Code 行为，减少无效成本
Claude Code 35 个进阶技巧 — 掌握高效使用 Claude Code 的核心技能
Claude Code MCP 配置教程 — 正确配置 MCP 以优化 Token 消耗
今天就开始：运行 /cost 检查你的最近会话成本，设定每月预算目标