我花了 $200/月买 Claude Max,然后发现 Skill 系统在悄悄吃掉我的额度

我花了 0/月买 Claude Max,然后发现 Skill 系统在悄悄吃掉我的额度作者:一个被”网络错误”骗了很久的 Max 用户
我第一次注意到这个问题,是在一个普通的下午。
我打开 Claude Code,放了几个自定义 skill,然后发了一句再普通不过的话:”你好。”
系统告诉我:上下文已使用 3%。
我愣了一下。我什么都没做。我只是打了个招呼。
那一刻我开始意识到,这个我每个月花 \$200 订阅的工具,正在以一种我完全看不见的方式消耗着它的”燃料”。而我,对此一无所知。
“省 Token”的 Skill,其实是 Token 黑洞
Skill 系统的官方叙事是这样的:它通过懒加载机制,只在需要时才把完整的 skill 内容注入上下文,平时只保留简短的描述摘要。言下之意——它是帮你 token 的。
这个说法在技术上没有撒谎,但它遮住了更重要的事实。
当你真正触发一个 skill 的那一刻,系统并不是只加载那一个 skill 的内容。它需要先把所有可用 skill 的描述目录打包发给模型,让模型自己判断该调用哪个、以什么方式调用。这个”目录”包括你自己写的 skill,也包括 Claude Code 内置的 bundled skill——/loop/batch/debug/simplify/claude-api……不管你用不用它们,它们的元数据都在那次请求里。
这是一个”调用 skill 的 skill”——一个元调度层。它的存在让 Claude 具备了自主决策能力,但代价是:每次触发,你都要先交一笔”入场费”。
更讽刺的是,这笔入场费的大小,官方从未明确告诉你。
每次发消息,你在为什么付费?
在 Claude Code 里,你发出的每一条消息,实际上是一个打包好的请求,里面塞满了你可能从未意识到的内容。我们可以把它想象成一个洋葱,你的真实问题只是最中间那一层,外面包裹着一层又一层的系统开销。
暂时无法在飞书文档外展示此内容我花了 0/月买 Claude Max,然后发现 Skill 系统在悄悄吃掉我的额度
System Prompt 是基础开销,固定存在,约 5,000 到 15,000 个 token。这是 Claude 理解自己是谁、能做什么的”操作手册”,每次对话都要重新发送,无法关闭,无法压缩。
工具定义是第二层。Bash、文件读写、搜索……每一个内置工具都有一份 JSON schema 定义,告诉模型这个工具接受什么参数、返回什么格式。这些定义加起来又是几千 token,同样每轮必须携带。
Skill 描述列表是第三层,也是本文的主角。只要你的环境里存在 skill,它们的描述就会常驻在上下文里。你没有调用它们,但它们就在那里,每一轮对话都被重新发送一遍。内置的 bundled skill 你无法移除,自定义 skill 越多,这一层越厚。
对话历史是第四层,随着会话推进线性增长。你和 Claude 聊了十轮,第十一轮发送的请求里,前十轮的完整内容都在里面。
你真正想说的那句话,在整个请求里占多少比例?根据实测数据,通常不超过 4%
剩下 96%,是系统在替你”准备”。
Skill 触发的真实链路
很多用户以为调用一个 skill 的过程很简单:我说一句话,Claude 执行对应的 skill,完事。但实际的链路要复杂得多。
我花了 0/月买 Claude Max,然后发现 Skill 系统在悄悄吃掉我的额度
注意这里有一个关键细节:触发 skill 往往需要两次 API 请求。第一次是让模型决定用哪个 skill,第二次才是真正执行。每一次请求都携带了完整的上下文包。也就是说,你触发一次 skill,实际上产生的 token 消耗是你看到的数字的两倍左右。
这不是 bug,这是设计。但没有人在文档的显眼位置告诉你这件事。
Max 订阅制,是保护你的盾,还是模糊视线的幕布?
\$200/月的 Max 计划,最大的心理安慰是”不按 token 计费”。你不会收到一张写着”本月消耗 XX 元”的账单,所以你很难直观感受到浪费的存在。用量焦虑被订阅制的外壳包裹起来,变得不那么刺眼。
但这不代表 token 消耗不重要。
Anthropic 后端对每个用户的 token 消耗有实时追踪和速率限制。当你在短时间内触发了过高的 token 消耗——比如连续调用几次 skill,每次都触发那个元调度层的完整加载——系统会开始节流。请求变慢,响应延迟,然后报错。
前端显示的是什么?“网络错误。”
这三个字,把一个平台侧的速率限制决策,变成了一个你自己的网络问题。你开始检查 Wi-Fi,重启路由器,怀疑是运营商的问题,甚至开始考虑要不要换一个梯子。你不会去想:也许是系统在悄悄告诉你,你用得太多了,先等一等。
我把这种现象叫做”错误归因设计”——不一定是刻意为之,但客观上把平台的限制转化成了用户的自我怀疑。它的效果非常好:用户不会投诉速率限制,因为他们以为是自己的网络问题。
我花了 0/月买 Claude Max,然后发现 Skill 系统在悄悄吃掉我的额度
Skill 系统的真正受益者是谁?
我不是要否定 skill 系统的价值。对于重度 agent 工作流用户——那些让 Claude Code 自主运行数小时、跨文件、跨工具完成复杂任务的人——skill 系统是强大的。元调度层的存在,让 Claude 能在几十个工具里自主选择,而不需要用户手动指定每一步。这是真正的 agent 能力,不是噱头。
但这个系统是为重度用户设计的,却被默认安装给了所有用户
如果你只是偶尔用一个 skill 来做代码审查,或者生成一份提交信息,你并不需要那个元调度层,也不需要 /loop 和 /batch 的描述常驻在你的上下文里。但你没有选择。这些内置 skill 是硬编码的,用户无法完全关闭它们对 token 的占用。
我们可以用一个简单的矩阵来看清楚,skill 系统对不同用户的实际价值:
左下角的轻度日常用户,承担了和右上角重度用户几乎相同的基线 token 开销,却只获得了极少的收益。这是一个典型的一刀切设计税——平台为了服务最复杂的用例,让所有人都付出了代价。
这是一个优先级判断:平台的能力完整性,优先于单次会话的 token 效率。
对 Anthropic 来说,这个判断有其合理性——他们在构建一个生态,而不是一个工具。但对于付了 \$200/月、只想安静写代码的用户来说,这个判断的代价,是他们在不知情的情况下默默承担的。
我学到了什么:一份真实的避坑指南
用了一段时间之后,我调整了自己的使用方式。这些不是从官方文档里学来的,是我在反复碰壁、反复观察 token 消耗之后,自己摸索出来的。
第一,区分场景,不要把 Claude Code 当聊天工具用。 不需要 skill、不需要操作文件的对话,直接去 claude.ai。Claude Code 的基线开销是为 agent 任务设计的,用它聊天是在浪费入场费。
第二,任务之间用 /clear 重置上下文。 对话历史会线性累积,不同任务之间如果不清空,你会把上一个任务的所有上下文带入下一个任务,白白消耗 token。
第三,把不常用的 skill 设置 disable-model-invocation: true 这样它们不会出现在常驻描述列表里,只有你手动调用时才会被加载。这是目前用户能做的最有效的 skill 瘦身操作。
第四,用skilloverrides把内置bundle skilll设置为“off“。在.claude/settings.json里配置,可以把你完全不需要的内置skill从描述列表里移除,减少每次请求的基线开销。
第五,把 CLAUDE.md 精简到 300 行以内。 很多人把所有”以防万一”的说明都堆进去,结果 CLAUDE.md 本身就占了几千 token。把它当成索引,而不是百科全书。
第六,用 /cost 和 /context 命令监控实际消耗。 在不知道钱花在哪里之前,先搞清楚钱花在哪里。这两个命令是你的财务报表,应该定期查看。
这些操作,没有一个是产品引导我去做的。一个好的产品,不应该让用户靠自己摸索来避免浪费。
写在最后:信息不对称是 AI 时代的新型成本
我依然在用 Claude Code。它在真正复杂的工程任务上,仍然是目前最好的工具之一。当我需要让它自主重构一个模块、跨文件追踪 bug、或者执行一个多步骤的部署流程时,skill 系统的价值是真实的,那些 token 开销是值得的。
但我希望有更多用户知道这些事:
“订阅制”不等于”随便用”——速率限制真实存在,只是被包装成了网络错误。
“省 token 的 skill”在某些场景下恰恰是最大的 token 消耗源——懒加载是真的,但元调度层的开销也是真的。
“网络错误”不一定是你的网络问题——在排查路由器之前,先想想你刚才是不是连续触发了几次 skill。
信息不对称,是 AI 产品时代用户面临的新型成本。 平台知道你在消耗什么,但没有义务主动告诉你。看穿这一层,是我们作为用户能做的第一件事,也是最重要的一件事。
如果你也有类似的体验,欢迎留言讨论。这篇文章的所有观察,都来自真实的使用过程,没有任何夸大。

本文来自转载悠酱AI ,不代表发现AI立场,如若转载,请联系原作者;如有侵权,请联系编辑删除。

(0)
评测组小编的头像评测组小编
ChatGPT 能替你管钱了,你敢把银行账户交给它吗?
上一篇 20小时前
马耳他:向全民发放免费 ChatGPT 会员
下一篇 16小时前



扫码关注我们,了解最新AI资讯~

相关推荐

发表回复

登录后才能评论