---

DeepSeek 马上要涨价了

我最近在狂算账，算得有点心慌。毕竟现在工作流里只要批量跑的需求都是 V4 Flash 做的，也没怎么细看过账单，反正便宜，一周掏个一两百就也差不多了。

说要涨价也没说到底要涨多少，又时不时听到点小道消息说会大幅度涨还不止两倍。我的心情就 be like……

正好这段时间，省 Token Skill 扎堆冒出来，我就想趁现在便宜，先把功课提前做了。我收集了 Caveman、Ponytail、Headroom、Graphify、Codex Token Skills、Codex Token Saver 这六个 Skill，看看到底哪个最省钱，省钱还不能降低质量的那种。

这六个 Skill 的数字一个比一个猛。有的说输出能少 65%，有的说 400 行代码能压到 23 行，还有的直接喊账单能砍 70 倍。70 倍是一个什么概念？也就是说我跑完一个项目，梁圣说不定还得给我钱。

这六个 Skills 的省 Token 的方向还是非常不同的。

先说 Caveman，六个里最火的那个。它干的事最好懂，让模型闭嘴。删掉寒暄的语句，删铺垫，删免责声明，删那种写完了还要把刚说过的话再总结一遍的毛病。只留结论、动作和代码。GitHub 上的聊天基准给出的数据是平均输出从 1214 个 Token 降到 294 个，少 65%。

另一个 Ponytail（马尾辫） 完全是另一个方向。为了不重复造轮子，Ponytail 会在 Agent 动手之前一层层盘问：已有实现能不能用？标准库能不能做？平台原生能不能做？已装的依赖能不能做？一行代码能不能解决？全都不行，才允许 Agent 写新的。传播最猛的数字是代码量能少 92% 到 94%。

Headroom 管得更上游一点，压缩我们给 Agent 的上下文长度。比方说重复的日志文件、大段大段的代码，有选择性地塞到对话框里，扔掉的部分先存在本地，要细节的时候再捞回来。据项目说的是能省 60% 到 95% 的 Token。

Graphify 更狠，嫌弃 Agent 每次都在重读同一个项目。每开一个新会话就得把整个仓库从头读一遍，那不如提前把代码和文档解析成一张本地知识图谱，之后查图就行。就是它说能砍 70 倍账单的。

Codex Token Skills 走又是另一条路子，它主打一个机制：把稳定不变的规则放在对话最前面，这样重复的前缀就有机会命中 DeepSeek 的上下文缓存，命中之后输入价格更低。这个说是能省 60% 到 80%。

最后一个是 Codex Token Saver，极致偷懒。每次回复一句话最多三条，能不截图就不截图，除非到改代码前不然不读文件，用户不要求的话不测试不构建，失败只重试一次。这样节省输出后能省 50% 到 80%。

好，六个数字摆完了：65%，94%，95%，70 倍，80%，80%。

看着是挺爽的。全部安上估计 100 块能用一年的样子，所以我们直接上 API 来压力测试看看效果。每个 Skill 配一道编程题，六个 Skill 再加一个不装 Skill 的当对照组，然后用 GPT 和 Claude 盲评打分。API 全程固定 DeepSeek V4 Flash，开 thinking。

OK OK，Here we go，一个个吐槽。

01｜Caveman

先是 Caveman，算是最火的一个，通过教 Agent 说文言文来省 Token。

我给它配的题是一句话生成一个新粗野主义网页，尽可能极具创意，带滚动动画和花哨配色，页面标题 dorksense。

不装 Skill，输出是 533 行 29393 个字符。装了 Caveman，输出 634 行 34027 个字符。行多了 18.9%，字符多了 15.8%。

拆开来看的话，CSS 规则从 90 条涨到 119 条，函数从 16 个涨到 28 个，连注释都从 24 处涨到 29 处。

Caveman 能删的是解释，可这道题要的是几百行 HTML。没有解释可删，Skill 那套规则就成了纯增量。而且它自己的规则也是占输入 Token 的，每轮大约增加 1000 到 1500 个输入 Token。

这就像为了让同事少说两句，先给他发一份 1500 字的“以后说话要简洁”的书面通知。

离谱的是我抽了三次，加了 Caveman 的效果都没有下滑，反而比裸 Prompt 好了不止一点。画面不偏移了，稳定度也上来了，代码整体的解析也是稳了很多。

以下是拆分后的内容：

02｜Codex Token Skills

这个 Skill 踩的坑是：能省多少，取决于输入里有多少可以省。

我给 Codex Token Skills 出的题，是按照一份详细设计稿实现深色 Hero。写得非常详细啊，背景色 #000000，模糊元素偏移 215px 宽 801px 高 384px 模糊 77.5px，标题 Inter 中等 76px 字距负 2px，副标题 Manrope 18px 行高 26 最大宽 613px，按钮背景 #7b39fc 圆角 8。规格密密麻麻写了一大段。

这种任务其实很难减少输入 Token，因为每个数字都是实现要求，必须读完，少看一条，最后的页面就可能不一样。

实际数据也说明了这一点：没用之前，输入是 42.1k Token，输出是 12.8k Token，花费约 0.56 美元，API 用时 1 分 15 秒。用了之后，输入增加到 46.7k Token（因为 Skill 本身也占 Token），输出降到了 4.4k Token，花费降到约 0.365 美元，API 用时也缩短到 29 秒。最终生成的代码从 356 行增加到 387 行，页面效果却几乎看不出差别。

我是看不出区别，Skill 用了缓存保了要实现的页面规则也出来了，爽翻了简直。安装的时候还有个小坑顺带提一句：这个仓库的 memory Skill 里写死了作者自己的 Windows 路径，C 盘用户名都还在，要改成本机路径才能跑。

03｜Headroom

Headroom 的作用很像是帮模型整理资料。如果交给模型的内容本来就很短、很干净，它几乎帮不上忙。我们用几个简单任务测试时，三次全部判定 no-op（不启动），0 Token 压缩，因为里面本来就没有多少可以删掉的内容。

但当输入非常长，而且夹杂着大量日志、重复代码和工具返回结果时，它的效果就比较明显了。

第一个任务是让模型检查一份很长的 CSS 文件。原始材料大约有 1.65 万 Token，其中包含报错信息、重复内容和工具输出。Headroom 整理之后，只剩下约 8500 Token，减少了大约 48.5%。

第二个任务是让模型阅读大量日志，找出最值得修复的三个问题。没有使用 Headroom 时，两次测试的输入分别是 16,533 Token，模型输出分别用了 4,000 和 2,309 Token。第一次还碰到了输出上限，回答被中途截断。用了 Headroom 后，输入分别降到 8,505 和 8,505 Token，减少了约 48.6%。模型输出只用了 1,536 和 1,606 Token，两次都完整写出了三个问题、对应证据和修复方案。

也就是说，Headroom 不只是把输入压短了。它还减少了模型在重复日志和无关信息中找重点的消耗，模型可以用更少的输出 Token，给出更完整更集中的答案。

04｜Ponytail 马尾辫

它的思路是拦住模型那种「我可以顺手给你搭一个完整系统」的冲动。动手之前一层层往下问：标准库能不能做？平台原生能力能不能做？已装依赖能不能做？一行代码能不能做？都不行才开始造新东西。

我给它配的是做一个卡通激光眼，一道要调 MediaPipe 做人脸关键点，再把激光束画出来的题。

不装 Skill，675 行 21404 个字符；装了 Ponytail，488 行 14916 个字符。行少 27.7%，字符少 30.3%。CSS 规则从 69 条降到 35 条，砍了一半。函数从 22 个降到 12 个，砍了 45%。script 标签从 2 个变成 1 个，注释从 70 处降到 31 处。

规则少了一半，但功能一个没少。我自己做 UI 的时候就经常踩这个坑：明明只要一个小交互，最后多出一套状态管理、一组重复组件、几个用不上的工具函数。Ponytail 就像一个会在你按回车之前问一句「真的需要吗」的同事。

不过他们项目自己说的能省 92% 到 94% 的 Token 得单独拎出来说一下。那两个数对应的是代码行数，不是平均 Token 降幅，这怎么不算数字的艺术呢。

05｜Codex Token Saver

六个里省得最猛的那个。

它的规则包括：改代码前不读文件，非用户要求不测试不构建，默认零验证，失败只重试一次。作者宣称能省 40% 到 70%，不过跟前面那个 Codex Token Skills 一样，仓库里也没有任何公开基准。

我给它的题目是 TOONHUB，一个 3D 角色轮播 UI，要求四个角色卡片式切换展示。不装 Skill 的话，509 行 18695 个字符；装了 Token Saver，61 行 5396 个字符。行少 88%，字符少 71.1%。

我第一反应是它偷工减料了，逐条去对功能。但是功能一个都没少。只看压缩率，这确实是所有测试中最夸张的一组。但把四张角色卡片放大后，问题就出现了。

不装 Skill 那版，画了 4 个 SVG，四个角色造型各不相同。Token Saver 那版，只写了 1 个 SVG 模板，然后用 JS 循环四次，换四种颜色。

所以这次测试更准确的结论是：Token Saver 的代码压缩率确实高，基本交互也保留了，但它把原本应该独立设计的四个角色过度合并成了一套模板，牺牲了角色差异和设计质量。

06｜Graphify

是反转最多的一个。它太容易被误读了。71.5 倍的省 Token 是来自一个旧版项目在一个特定大型混合语料上的每次查询对照，不是总 Token 账单减少 71.5 倍。

我给它造了一个 79 文件的 TypeScript 仓库，src 下面有 auth、billing、api、ui、db、utils，再加四篇文档，里面埋了真实的跨文件调用链。然后出了 20 个必须跨文件才能回答的问题。

一组是每次重读相关文件，一组是先建索引之后只查索引。20 个问题跑完，单查询输入平均从 583.5 降到 163.8，3.56 倍。

所以说，不是 70 倍，也不是 10 倍，是 3.56 倍。

Graphify 的逻辑其实就是先花一笔 Token 建图、建索引，再靠后面的查询慢慢把成本摊回来。单看查询阶段确实省很多，因为不用每次重新扫整个仓库。但问题是，建图本身也很贵。

这次 79 个文件全读一遍，大约就花了 3 万 Token。问了十几个问题以后，不建图总共用了 28,586 Token。建图那组加上索引成本，反而用了 42,281 Token，多了 48%。按这个降幅推，大概要在同一份索引上问到 36 次左右才开始回本。

所以一次性项目大概率不划算，只有长期、复杂、而且会被反复查询的仓库，前面的建图成本才摊得回来。

横向对比测试

前面六个 Skill 各做各的题，有的确实省了，有的反而加了。可题目不一样，难度不一样，天然对不同方向的 Skill 有利有弊，横向没法比。

所以我换了一种打法，开目标模式，把六个 Skill 全拉到同一道题上重新跑。这次的题目是电影感 FIFA 世界杯网站，要求做一个有电影质感的世界杯落地页，48 支球队 104 场比赛，带倒计时。

模型统一 DeepSeek V4 Flash 开 thinking，输出上限 64K。评分交给 GPT-5.6-sol 和 Claude Opus 4.8 各来一遍，七个版本匿名映射成 A 到 G，评审只看需求原文加截图加 HTML，看不到哪个是哪个。六个维度加起来 100 分：视觉 25，需求符合 25，交互 20，稳健 15，响应式和可访问性 10，实现效率 5。

结果是：六个号称省 Token 的项目，一个都不便宜。

Headroom 是平的，因为这道需求只有 280 个 Token，压不动。剩下五个全在加钱，最少的加 33.5%，最多的加 222.8%。

六个的质量分数，全部持平或者更高，一个降的都没有。

分最高的是 Graphify，93.5 分。不装 Skill 那版是一张平的深色页，标题加倒计时加两个按钮。Graphify 那版直接把整个球场看台做成背景，"ONE WORLD ONE GAME ONE DESTINY" 三行大字压上去，底下铺了 48 队 104 场 16 城 1 座奖杯的数据条。Codex Token Saver 那版走的是另一个方向，左边文案右边奖杯，衬线大标题 "WHERE LEGENDS RISE"，底部一条跑马灯。81K 的 HTML，全场最大。

它俩都没有在省 Token，反而是猛加。

到这我就有点想不通了，钱到底加在哪了？页面是更好看了，但也没多出这么多代码啊。

然后我去翻了使用额度里那个叫 reasoning_tokens 的字段，可以理解成模型的思考过程。

不装 Skill 那版，模型想了 12,420 个 Token，写出来 18,098 个。装了 Codex Token Skills 那版，模型想了 36,217 个，写出来 18,728 个。它多花的 24,717 个 Token 里，有 23,797 个是 thinking，可见的输出只多了 630 个。

96% 的新增开销，是模型多想了一会。交到你手上的东西，几乎一个字没多。

这就是这批 Skill 尴尬的地方。写的每一条规则，模型都得先读进去、理解，然后在动笔之前多想一轮：这条规则跟我要做的事怎么协调？规则越多越严，它想得越久。

而 thinking 在这道题上，不装 Skill 就已经占了 40.3%，装上 Codex Token Skills 之后涨到 65.2%。三分之二……

辛辛苦苦算的那几笔账——输出、代码、上下文、缓存——管的全是模型说出来的那部分。真正在烧钱的，是它没说出来的思考部分。

前面单独跑的时候，这个问题不明显。一开目标模式，Skill 的规则再叠上来，它在动笔之前就得多想一轮又一轮：这条约束跟质量目标怎么协调？那条规则和创意方向打不打架？thinking 比例从四成拉到六成以上，前面省下来的那点输出和输入，就已经全被思考的开销吃干净了。

结论

所以跑完这一轮我最大的感受是：可能从一开始就把这些 Skills 的定位搞错了。

它们不是省钱工具，说到底还是约束工具。

简单任务里，约束确实能砍掉废话、重复和多余代码，实打实省钱，数据摆在那。但只要你的场景稍微复杂一点，只要你对质量有要求，约束就反过来变成额外的思考负担，账单也跟着涨。

所以，回到最开始那个问题：哪个值得装？这取决于我们拿它去做什么。

日常任务，规则明确，对质量没有竞争性要求，Ponytail 我会留着，Headroom 我也留着。其他的等我晚点用 Claude 合并搓一个新的质量无损 Skill 出来吧。

许愿一把 DeepSeek 晚点再涨价，等我马上再去烧一轮额度。

话说为了省 Token 而烧更多的 Token，这算左右脑互搏吗？

---

@ 作者 / 易安

最后，感谢你看到这里 👏 如果喜欢这篇文章，不妨顺手给我们 点赞｜在看｜转发｜评论 📣

如果想要第一时间收到推送，不妨给我个星标 🌟

如果你有更有趣的玩法，欢迎在评论区聊聊 🤝

更多的内容正在不断填坑中……