本月我做了个决定：把 Claude Code 的套餐从 Max 降到 Pro。
原因有点反常识：不是因为 Claude 不好用，而是 Codex 移动端最近的体感实在太顺手，我一半的活儿挪过去了，Max 那一个月的钱花得肉疼。降到 Pro，省下大半。
然后我就尝到了苦头。
目前工作流是 Opus 4.8 用来生成 PLAN , Codex 用来写代码，Opus 用来做 Code Review。降到 Pro 之后，Claude Code 的额度，配上我这种高强度的用法，根本不够烧。
带着这个问题，我刷到了一个这两周在 GitHub 上炸开的仓库。11 天，5 万星。它的名字叫 Ponytail——马尾辫。说起来，这也是我装的插件里仅次于 Superpower 用得最多的一个——一个管把活儿拆成能执行的步骤，一个管每一步具体该写多少代码，两者搭配着用反而互补。
Ponytail 是什么，解决的是哪类问题
Ponytail 不是模型，也不是某种微调，本质上是一份会被整段塞进 Agent 上下文的 skill。项目作者给这套行为取了个形象的名字——对应那种资历最老、话最少、看一眼就把你五十行代码删成一行的老工程师形象，这是营销话术，但背后的机制是真的。装上之后，它要求 Agent 在动手写代码前，先过一遍六级判断：
1 | 1. 这东西真的需要存在吗？ → 不需要就跳过（YAGNI） |
规则只有一条：停在第一个能站稳的台阶上。绝大多数 Agent 的默认路径是直接跳到第六级，因为产出代码就是它被训练出来要做的事；Ponytail 强迫它从第一级开始往下挣，每一级证明走不通，才有资格继续往下走。
落到具体代码上，效果是这样的：
| 任务 | 放养的 Agent 通常会写 | Ponytail 给出的版本 |
|---|---|---|
| 日期选择器 | npm install flatpickr + 30 行 React 包装组件 + 一份 CSS |
<input type="date"> |
| 内存缓存 | 120 行 TTLCache 类，带线程安全、LRU 淘汰、命中率统计端点 |
@lru_cache(maxsize=1000)，两行 |
| 限流 | 35 行滑动窗口 RateLimiter，deque 配 threading.Lock |
threading.Semaphore(10)，一行 |
| 防抖 | npm install lodash.debounce，引入并包装调用 |
3 行 setTimeout 闭包 |
| 倒计时 UI | React 组件：useEffect、useState、useRef、清理逻辑、格式化函数 |
<input type="time"> |
右边这一列的共同点：浏览器团队、Python 标准库、操作系统内核早就把这件事做完了，比现写的版本更原生、更无障碍，也经过更长时间的验证。
效果到底有多大，作者拿 12 个真实的 Claude Code agentic 任务 对着一个公平的 agent 基线重新测了一遍。修正后的数字是：
| 指标 | 修正后的结果 |
|---|---|
| 少写代码 | 约 54%（过度工程严重的场景最高仍达 94%） |
| 更省钱 | 约 20% |
| 安全性 | 全程不打折，是唯一一个砍掉所有指标还能保持安全的方案 |
省得最狠的地方，永远是那些有「过度建造陷阱」的活儿——日期选择器从 404 行砍到 23 行，颜色选择器从 287 行砍到 23 行。对已经很精简的代码，它几乎一行不动。
还有一处反直觉的细节，作者写在了 README 里：这条规则从来不是「用最少的 token」。省钱省时间只是「老实爬梯子的模型」的副作用——换一个爱钻牛角尖的推理模型，比如 GPT-5.5，会在每一级台阶上反复思考该不该跳，token 反而更多。这点值得记住：它优化的目标是少写不必要的代码，不是省 token，两者经常一致，但不是一回事。
在 Claude Code 里怎么装
1 | /plugin marketplace add DietrichGebert/ponytail |
装完开一个新会话，前面说的两个 SessionStart / UserPromptSubmit hook 才会生效。如果你的环境里 node 不在 PATH 上，这两个 hook 会静默不工作，但 skill 本身还能用，只是要靠你手动提一句「ponytail」去触发。
强度随时可以切：
1 | /ponytail lite # 正常写，旁边提一句更懒的做法 |
也可以用环境变量 PONYTAIL_DEFAULT_MODE，或者 ~/.config/ponytail/config.json 里的 defaultMode 字段，把默认档位固定下来，不用每次开会话都手动切。
装好之后，别急着拿它跑新任务。最诚实的第一次测试，是拿一个你自己都觉得「写得太肿了」的旧 PR，对它跑一遍 /ponytail-review，看它让你删什么。
大概率你会同意它的判断。而那些你不同意的地方，才是最有意思的——它们会告诉你，这道梯子在你自己的代码库里，哪个台阶踩空了。比如「用已装的依赖」这一级，可能会把 Agent 推回一个你正打算迁移掉的老库。梯子优化的是「少写新代码」，这和「代码库该往哪个方向走」并不总是一回事。
所以那几条 review 建议，看看就好，别无脑全盘照收。
真正值得琢磨的那个问题
绕了一圈，回到最开始。我因为额度焦虑找到 Ponytail，最后发现它的解决的核心问题不是额度消耗。
它解决的是一个更底层的偏见：AI 编码 Agent 天生喜欢写，不喜欢删。 你让它加个功能，它的默认路径永远是装库、包组件、加 hook、加清理逻辑，因为产出代码才能给它「干完了」的满足感。它不会停下来问那句最该问的话——这东西，真的需要存在吗？