夜雨聆风Ponytail
GitHub: DietrichGebert/ponytail | Stars: 3,881
它是什么
Ponytail 是一个面向 AI 编程 Agent 的规则/插件项目，官方描述是：Lazy senior dev mode for AI agents. The best code is the code you never wrote.
翻译成人话就是：让 Claude Code、Codex、OpenCode、Cursor、Windsurf、Cline、Copilot 等编程助手，在动手写代码之前，先像一个经验丰富但“不爱造轮子”的老工程师一样想一遍：
这个需求真的需要做吗？
标准库是不是已经有了？
浏览器、操作系统、框架原生能力是不是已经覆盖了？
现有依赖能不能直接用？
能不能一行解决？
只有这些都不行，才写“能工作的最小代码”。
这听起来像一句工程管理口号，但放到 AI 编程场景里很实用。因为很多 Agent 默认倾向于“把事情做完整”：一个日期选择器，它可能先装 flatpickr，再封装 React 组件，再加样式，再写生命周期清理；但很多时候，一个浏览器原生的 <input type="date"> 就够了。
为什么值得关注
过去一年，大家对 AI 编程工具的关注点主要是“能不能写更复杂的代码”。但 Ponytail 切的是另一个方向：能不能少写没必要的代码。
这正好戳中了 AI Coding 的一个真实痛点：
文件越改越多，Review 成本变高；
依赖越加越多，维护面变大；
抽象越堆越厚，后续需求反而更难改；
Agent 生成的“看起来很专业”的代码，里面可能有大量 YAGNI。
Ponytail 的思路不是让模型变聪明，而是给模型一个更强的工程约束：先删，后写；先用现成能力，后造轮子。
核心亮点
把“少写代码”变成 Agent 的默认工作流
Ponytail 的核心规则很简单：
1. Does this need to exist? → no: skip it (YAGNI)2. Stdlib does it? → use it3. Native platform feature? → use it4. Installed dependency? → use it5. One line? → one line6. Only then: the minimum that works
也就是说，它不是一个新的代码生成模型，而是一套可以注入 Agent 上下文的行为规则。对开发者来说，这类工具的价值在于：不用每次都手动提醒 AI “别过度设计”“别加依赖”“别抽象太早”。
支持多个主流编程 Agent
Ponytail 不是只服务某一个工具。它目前提供了多种适配方式：
Claude Code：插件安装，支持 session 激活、模式切换、命令和状态栏；
Codex：插件安装和生命周期 hooks；
OpenCode：通过插件每轮注入规则；
Cursor / Windsurf / Cline / Copilot / Kiro：通过规则文件或 instructions 文件接入；
通用 Agent：可以直接复用
AGENTS.md或 skill 文件。
这说明它更像是一个“AI 编程行为规范包”，而不是单纯的 Claude Code 小插件。
带有可复现 Benchmark
项目作者做了一组对比测试：5 个日常任务、3 个模型、3 组模式，每组 10 次运行取中位数。
任务包括：邮箱校验、JS debounce、CSV 求和、React 倒计时、FastAPI rate-limit。对比对象包括：
baseline：不加任何 skill；
caveman：另一个压缩表达风格的 skill；
ponytail：启用 Ponytail。
项目 README 给出的结果是：相比不加 skill 的 baseline，Ponytail 在所有模型上实现了：
少写 80%-94% 代码；
成本降低 47%-77%；
速度提升 3-6 倍。
从 benchmark 明细看，以代码行数为例：
| 模式 | Haiku | Sonnet | Opus |
|---|---|---|---|
| baseline | 518 | 693 | 256 |
| caveman | 116 | 120 | 67 |
| Ponytail | 39 | 44 | 51 |
当然，这类 benchmark 不能简单等同于真实项目里的长期收益，但它至少说明了一件事：提示词/规则层面的工程约束，对 Agent 输出风格影响非常明显。
不是无脑省代码，保留安全边界
Ponytail 的 README 和规则文件里也明确写了：lazy 不是 careless。它不会为了少写代码牺牲这些东西：
信任边界处的输入验证；
防止数据丢失的错误处理；
安全性；
可访问性；
用户明确要求的能力。
它还要求对有意简化的地方加 ponytail: 注释，说明这个 shortcut 的边界和未来升级路径。这个点很关键，否则“少写代码”很容易滑向“不负责任地省略代码”。
一个直观例子
比如你让 Agent “给表单加一个日期选择器”。
普通 Agent 可能会这么做：
npm install flatpickr
然后写一个 React wrapper，引入 CSS，处理初始化、销毁、value 同步等逻辑。
Ponytail 的回答可能是：
<!-- ponytail: browser has one --><inputtype="date">
这就是它的核心审美：能用浏览器原生能力，就不要急着装依赖。
再比如 Python 邮箱校验。很多 Agent 会写一个正则、一个 EmailValidator 类、一个 wrapper 函数，看起来很完整，但邮箱地址本身很难靠正则彻底验证。Ponytail 会倾向于给出更诚实的方案：简单场景做基本检查，真正验证交给确认邮件。
快速上手
如果你使用 Claude Code，可以通过插件市场安装：
/plugin marketplace add DietrichGebert/ponytail/plugin install ponytail@ponytail
安装后，它会在会话里启用 Ponytail 的规则，并提供几个命令：
/ponytail/ponytail-review/ponytail-help
其中 /ponytail 可以切换强度：lite、full、ultra、off。
/ponytail-review 则专门用来检查当前 diff 里有没有过度工程化的地方，例如：
可以删除的 speculative feature；
重复造标准库轮子；
用依赖实现平台原生能力；
只有一个实现却抽象出接口；
同样逻辑能不能更短。
如果你不用 Claude Code，也可以参考仓库里的适配文件，把对应规则复制到 Cursor、Windsurf、Cline 或 Copilot 的 instructions 里。
我怎么看
Ponytail 这个项目有意思的地方，不在于它技术上多复杂，而在于它抓住了 AI 编程工具的一个反直觉问题：模型越强，越需要工程约束。
以前我们担心 AI 不会写，现在很多时候要担心它太会写：把一个简单需求扩展成一堆文件、封装、依赖和“未来可扩展架构”。短期看像是高质量交付，长期看可能是维护负担。
所以 Ponytail 更适合作为团队里的 AI Coding 默认规范之一：
新需求先问有没有必要；
能用标准库就不用第三方库；
能用平台能力就不自己封装；
能少改文件就少改文件；
复杂抽象等第二个真实用例出现再说。
这套规则尤其适合小团队、个人项目、原型开发，以及任何被 AI 生成代码“膨胀”困扰过的项目。
总结
Ponytail 是一个很轻量但很有启发性的 AI 编程插件：它不追求让 Agent 写出更多代码，而是让 Agent 在写代码前先想清楚哪些代码根本不该出现。
如果你已经在用 Claude Code、Cursor、Codex 或 Copilot，不妨试试把这套规则加进去。很多时候，最好的代码确实是那段没有被写出来的代码。
