Ponytail：让 AI 写最少代码的 YAGNI 决策框架

把'最懒资深程序员'的思维植入 AI agent——写代码前先问 7 个问题，-54% 代码量、-20% 成本、100% 安全性，支持 16 个 AI 编程平台。

项目地址：https://github.com/DietrichGebert/ponytail ｜ MIT 开源协议 ｜ ⭐ 63K+ Stars

这是什么

Ponytail 是一个给 AI 编程 Agent 用的 YAGNI 决策框架。它把"最懒的资深程序员"的思考方式做成一个可执行的决策阶梯，让 AI agent 在每次写代码前先问自己七个问题——结果是用更少的代码完成同样的事。

形象设定是一个扎着长马尾、戴椭圆眼镜的老程序员：在公司待得比版本控制系统还久，你看他、他面无表情，把你五十行代码重写成一行，然后一言不发继续干活。

核心数据：真实 Claude Code 会话中，对比无 skill 的同一 agent，代码量 -54%（极端案例 -94%）、token -22%、成本 -20%、耗时 -27%、安全性 100%。测量方式不是单一 prompt 输出，而是让 agent 在真实 FastAPI + React 仓库里完成 12 个 feature 任务后的 git diff 统计。

插件还是技能？

Ponytail 同时是插件和技能，两者职责不同：

一句话：规则部分是自动的（像空气一样一直在），命令部分是手动的（需要时才调）。

/plugin install ponytail@ponytail 一步把插件和技能都部署到位，不需要额外安装。

纯指令适配器（Cursor、Windsurf、Cline 等）只能用到指令部分——把规则文件 copy 到项目里，agent 读到后生效，但没有 hook 层和 /ponytail 命令。

核心原理：7 级决策阶梯

AI agent 在动笔写代码之前，从低到高依次检查，停在第一个能站稳的阶梯：

1. 这东西需要存在吗？        → 不需要就跳过（YAGNI）
2. 代码库里已经有了？        → 复用，别重写
3. 标准库能做？              → 用标准库
4. 浏览器 / 平台原生能力？   → 用原生 API
5. 已安装的依赖能做？        → 用已装依赖
6. 一行能搞定？              → 就写一行
7. 实在不行：写最少必要的代码

两个关键设计：

• 先理解再偷懒：阶梯在 agent 读完相关代码、追踪了真实执行流之后才运行，不是盲猜。对解题懒，不对阅读懒。
• 安全护栏不可逾越：信任边界校验、数据丢失处理、安全、无障碍——这四条永远不在裁剪名单上。这也是 benchmark 里 Ponytail 安全性 100% 而裸 "YAGNI + one-liner" prompt 只有 95% 的原因。

这个阶梯不是"用最少 token"的规则，而是"只写任务真正需要的代码"的规则。代码少是因为必要，不是因为压缩。

安装

Claude Code

两条命令，分开发送：

/plugin marketplace add DietrichGebert/ponytail

/plugin install ponytail@ponytail

桌面版没有 /plugin 命令，从 UI 安装：Customize → 个人插件旁的 + → 创建插件并添加市场 → 从仓库添加，输入仓库 URL。

Codex

codex plugin marketplace add DietrichGebert/ponytail
codex

打开 /plugins，选择 Ponytail 市场，安装 Ponytail。然后打开 /hooks，审查并信任两个 lifecycle hook，开新线程即可。

其他平台

纯指令平台（Cursor、Windsurf、Cline、Kiro、Zed、CodeWhale）：复制对应规则文件到项目目录即可。详见仓库的 Agent portability。

设置默认强度

安装后默认为 full。可通过以下方式修改：

• 环境变量：PONYTAIL_DEFAULT_MODE=lite（可选值：lite/full/ultra/off）
• 配置文件：~/.config/ponytail/config.json（Windows 上为 %APPDATA%\ponytail\config.json），写入 { "defaultMode": "lite" }

命令速查

启动和切换强度时 agent 会显示当前模式。以下命令需要 skill 支持（Claude Code、Codex、OpenCode 等平台可用）：

使用示例

场景一：让 AI 加个颜色选择器

不用 Ponytail 时，AI agent 可能会：

1. npm install react-colorful
2. 写 ColorPicker.tsx 封装组件（~50 行）
3. 写 ColorPicker.module.css（~30 行）
4. 在父组件引入、传 props、加 onChange
5. 加上 "支持 HEX/RGB/HSL 格式切换" 的扩展点
6. 顺手加 focus trap 和键盘导航

总共 150-300 行 diff。

用 Ponytail 后：

<!-- ponytail: browser has one -->
<input type="color">

就一行。决策阶梯的判断过程：

• Step 1：需要存在吗？✅ 需要（需求明确）
• Step 2：代码库已有？❌ 没有
• Step 3：标准库？❌ 没有
• Step 4：浏览器原生？✅ <input type="color"> 所有现代浏览器支持，原生 color picker，零 JS，零 CSS，自带无障碍。
• 停在第 4 级，后面都不需要了。

场景二：让 AI 加个日期选择器

不用 Ponytail：装 flatpickr，写封装组件，加样式表，开始讨论时区。最后 400+ 行 diff。

用 Ponytail：

<input type="date">

真实 benchmark 中这个任务从 404 行降到了 23 行。

场景三：调整强度

觉得 Ponytail 太激进（某个场景确实需要一个组件库），降到 lite：

/ponytail lite

反之，看到烂代码一肚子火：

/ponytail ultra

Ultra 模式下 AI 会像那个在公司待了 20 年的老程序一样，面无表情地把你的 200 行重构为 12 行，然后一言不发地继续写。

与其他工具的关系

vs mattpocock/skills 的 /caveman

两者不在一个维度上，可以叠加。/caveman 让 AI 说人话，Ponytail 让 AI 写少代码。

vs Superpowers

两个方法论层的极端，方向互补：

两者可叠加：Superpowers 管"该做的都做到位"，Ponytail 管"不该做的别多做"。

vs rtk

降 token 的链路不同，完全互补：

rtk：      命令输出 → [压缩] → 给 LLM          （外部工具输出）
Ponytail： LLM 思考 → [阶梯过滤] → 写代码       （LLM 生成内容）

rtk 压 git diff、npm test 的输出，Ponytail 让 agent 少生成代码，两条链路不重叠。

vs taste-skill

taste-skill 让 AI 写更好看的前端，Ponytail 让 AI 写更少的前端。叠加时 Ponytail 的阶梯优先执行（先问"需要存在吗"），可能把 taste-skill 加的 DESIGN_VARIANCE / MOTION_INTENSITY 判定为 YAGNI——需要人工判断边界。

适用场景

适合：

• AI agent 经常过度工程——装 flatpickr 就为了选个日期、写 300 行 wrapper 就为了调个 API
• 前端/全栈/CRUD 开发——这些领域平台原生能力和已有依赖覆盖了大量需求
• 想降低 AI 编程的 token 成本和延迟
• 快速迭代——代码越少，改动越快，review 越轻松

不太需要：

• 业务逻辑密集、跨系统集成的场景——阶梯效果有限，因为真正的复杂度在业务里
• 已经对代码量有严格控制的项目——节省空间不大
• 深度底层开发——原生能力和标准库覆盖少，阶梯能跳过的层级有限

一句话建议：如果你经常觉得"AI 写的代码太多了"，装 Ponytail。两行命令，零学习成本，装完就生效。