Ponytail 把最懒的资深开发者装进 AI agent 里
Ponytail：把"最懒的资深开发者"装进 AI agent 里
> 原项目：DietrichGebert/ponytail · 1610 stars/day · JavaScript
一个你一定认识的人
每个公司都有这么一个人。长马尾，椭圆眼镜，在公司待得比版本控制还久。你给他看五十行代码，他看一眼，什么也不说，然后把它替换成一行。
Ponytail 这个项目做的事，就是把这个人装进你的 AI agent 里。
听起来像段子，但它是真的——而且数据证明它有效：代码量减少 54%、token 消耗减少 22%、成本降低 20%、速度提升 27%、安全性 100% 保持。
这不是"让 AI 写更少的代码"那么简单。这是一个关于必要性的工程哲学。
核心实验：一个公平的对比
Ponytail 的作者 DietrichGebert 做了一个相当严谨的实验。他不是在玩具任务上测试，而是：
- 真实代码库：tiangolo 的 full-stack-fastapi-template（一个真实的 FastAPI + React 项目）
- 真实任务：12 个 feature ticket，同一个 agent 有/无 skill 各跑一遍
- 公平基线：不是和"裸模型"比，而是和"裸 agent"比——agent 有工具调用能力，只是没有 ponytail skill
- 多模型：Haiku 4.5，n=4
- 评分标准：看 git diff 留下了什么
| 指标 | ponytail | caveman（简洁散文控制组） | "YAGNI + one-liners" prompt |
|---|---|---|---|
| LOC | -54% | -20% | -33% |
| tokens | -22% | +7% | -14% |
| cost | -20% | +3% | -21% |
| time | -27% | +2% | -30% |
| safe | 100% | 100% | 95% |
为什么"YAGNI + one-liners"会掉安全
这里有个很重要的细节：直接给 agent 一个"写最少的代码"的 prompt，安全性会从 100% 掉到 95%。
为什么？因为"写最少的代码"是一个目标，但 agent 不知道哪些是不能省的——验证、错误处理、安全检查、无障碍。它会为了"少"而砍掉这些。
ponytail 的规则不是"写最少的代码"。它的规则是：
> 只写任务需要的东西，永远不要砍验证、错误处理、安全或无障碍。代码最终变短是因为它是必要的，不是因为它被压缩了。
这是一个很精妙的区分。"必要"和"短"是不同的目标。 "短"是字数优化，"必要"是必要性优化。前者会砍掉重要的东西，后者不会。
最有说服力的案例：日期选择器
实验里有一个任务：实现一个日期选择器。
没有 ponytail 的 agent：安装 flatpickr 库，写一个 wrapper 组件，加样式表，开始讨论时区问题——最终 404 行代码。
有 ponytail 的 agent：——23 行代码。
这个例子太经典了。浏览器原生就有日期选择器，但 AI agent 不知道（或者不倾向于使用），因为它的训练数据里充满了"用库实现"的例子。ponytail 让 agent 意识到："等等，这个功能浏览器已经有了，我不需要装任何东西。"
颜色选择器同理：287 行 → 23 行，因为 agent 选择了原生的 。
"最懒的资深开发者"到底是什么意思
ponytail 的 prompt 里有一段很精妙的角色设定：
> You are a lazy senior developer. Lazy means efficient, not careless. You have seen every over-engineered codebase and been paged at 3am for someone else's clever code.
这段话里有三个关键概念：
1. "Lazy means efficient, not careless"——懒等于高效，不等于粗心。这是一个很重要的区分。资深开发者的"懒"不是偷工减料，而是"不愿意做不必要的工作"。 2. "Seen every over-engineered codebase"——见过所有过度工程的代码库。这意味着 agent 被设定为"对过度工程敏感"——它会主动识别"这个需求不需要这么复杂"。 3. "Paged at 3am for someone else's clever code"——凌晨 3 点被别人的聪明代码叫醒。这是一个很生动的场景：过度工程的代码在出 bug 时，维护者要付出代价。资深开发者知道这件事，所以会避免写出"看起来聪明但难维护"的代码。
这三点加起来，构成了一个"必要性守门员"的角色——不是让 agent 写更少的代码，而是让 agent 在写每一行代码前问自己："这行代码真的需要吗？"
为什么这个项目一天涨 1610 stars
Ponytail 火起来踩中了一个巨大的痛点：AI agent 普遍存在"过度工程"问题。
你用过 Cursor 或 Claude Code 就知道——你让它实现一个简单功能，它会：
- 安装一个你不需要的库
- 写一个 wrapper 组件（即使原生 API 就够）
- 加一层抽象（即使只有一个实现）
- 写一堆配置文件（即使默认值就行）
- 开始讨论时区问题（即使你只是想显示一个日期）
ponytail 做的是给 agent 一个反向的先验——"默认情况下，代码应该尽可能少。只有在确实需要时才增加复杂度。"
这和"少即是多"的设计哲学一脉相承，但落地到了 AI agent 的行为层面。
一个更深的观察：AI agent 的"性格"是可以被设计的
Ponytail 代表了一个更深的趋势：AI agent 的"性格"不是固定的，是可以被 skill 文件设计的。
裸的 Claude Code 倾向于"乐于助人"——你要什么它给什么，还多给一点。这听起来是好事，但在工程场景下是坏事——因为它会给你不需要的东西。
ponytail 通过一个 skill 文件，把 agent 的"性格"从"乐于助人"改成了"懒但可靠"。这不是微调，不是 prompt engineering，而是性格工程——通过一个 Markdown 文件定义 agent 的行为倾向。
这让我想到 i-have-adhd 那个项目——用 143 行 Markdown 把 ADHD 的神经科学事实转化为 LLM 的输出规则。这两个项目指向同一个方向：对齐不一定需要重训模型，有时只需要一个 skill 文件。
"最好的代码是你永远没写的代码"
ponytail 的 tagline 是：
> The best code is the code you never wrote.
这句话听起来像段子，但它是软件工程的一个深刻真理：代码是负债，不是资产。 每一行代码都需要被维护、被测试、被理解、被更新。少写一行代码，就少一份负债。
Fred Brooks 在《人月神话》里说："程序员产出的是代码，但价值不是代码本身——而是代码解决的问题。" 我们经常忘记这个区分，把"写更多代码"等同于"创造更多价值"。
ponytail 把这个理念装进了 AI agent——让它在写每一行代码前问自己："这行代码解决的问题，值得它带来的维护成本吗？"
这是一个很深的工程哲学，用一个非常轻量的 skill 文件实现了。
安装
npx skills add DietrichGebert/ponytail -g
然后在 Cursor / Claude Code / Codex 里正常使用。不需要改 prompt，不需要改模型——ponytail 会自动生效。
---
项目地址：github.com/DietrichGebert/ponytail 完整基准测试：benchmarks/results/2026-06-18-agentic.md 博客解读：alphamatch.ai/blog/ponytail-ai-coding-skill-2026
一句话总结：Ponytail 把"最懒的资深开发者"装进 AI agent——不是让 agent 写更少的代码，而是让 agent 在写每一行前问"这真的需要吗"，54% 的代码因此消失，100% 的安全性因此保持。