Ponytail——让 AI 少写点屎山代码

现在的 AI 编程工具已经很强了，但也有一个很真实的问题，相信尝试过 VibeCoding 的人都深有体会，它们有时候太爱写代码了。

你只是想修一个小 bug，它顺手重构三个文件；

你只是想要一个日期选择器，它安装依赖、封装组件、写样式，还开始讨论时区；

你只是想补个判空，它给你设计了一套“可扩展异常处理架构”。

这时候，Ponytail 就派上用场了。

Ponytail 是什么？

开源地址：https://github.com/DietrichGebert/ponytail

Ponytail 是 GitHub 上的一个开源项目，目前已经有超过 50K 的 star，就算有水分，也可以说非常有含金量了。它是一个给 AI 编程 Agent 使用的规则集 / 插件 / Skill 集合。它可以接入 Claude Code、Codex、OpenCode、Gemini CLI、GitHub Copilot CLI 等工具。

它的目标很简单：让 AI 在写代码前先冷静一下，尽量少写不必要的代码。

它的核心思路

Ponytail 的核心原则可以概括成一套决策顺序：

1. 这个功能真的需要写吗？

2. 项目里是不是已经有类似代码？

3. 标准库能不能解决？

4. 平台原生能力能不能解决？

5. 已安装依赖能不能解决？

6. 能不能用一行代码解决？

7. 最后才写最小可用实现。

这套规则看起来朴素，但很有效。因为很多 AI Agent 的问题不是“不会写”，而是“太愿意写”。

真正成熟的工程思维不是“我能不能实现”，而是“我能不能不新增复杂度”。

一个典型例子

来自项目的 README.md

你让 Agent 做一个日期选择器。普通 Agent 可能会安装 flatpickr，写 wrapper 组件，补 CSS，再顺手处理各种 props。

而 Ponytail 的思路是：

<input type="date">

浏览器原生就支持，没必要造一套新的。

这个例子非常能说明它的气质：不是不会写复杂方案，而是先看简单方案够不够用。

它解决哪些问题？

Ponytail 主要针对 AI 常见的几类毛病：

• 过度工程：小需求写成大架构。

• 乱加依赖：标准库能做的事也要装包。

• 重复造轮子：项目里已有工具函数，却重新写一套。

• 改动范围太大：本来能改一处，结果动一片。

• 只修表象：没有找 bug 的根因，只在局部打补丁。

它鼓励 AI 先读代码、理解流程、找到最小正确修改点，而不是一上来就生成一堆“看起来很专业”的代码。

Ponytail 的“懒”不是随便糊弄。

它明确强调：安全、输入校验、错误处理、数据保护、可访问性这些东西不能省。也就是说，它追求的是减少无用代码，不是砍掉必要工程。

好的极简不是：

return user.name.toUpperCase()

而是在理解边界条件后，写出更稳、更短、更合适的实现：

return user?.name?.toUpperCase() ?? ''

所以 Ponytail 不是代码高尔夫，不是为了短而短。它追求的是：在正确位置做最小但完整的修改。

它怎么工作？

从项目结构看，Ponytail 主要由几部分组成：

• AGENTS.md：核心规则说明；

• skills/：不同场景下的 Agent 技能；

• hooks/：用于注入规则；

• 各平台插件适配：比如 OpenCode、Codex、Claude Code 等。

以 OpenCode 为例，它会在每次聊天时把 Ponytail 的规则注入到 system prompt 中，并提供 /ponytail 命令切换模式。

常见模式包括：

• lite：轻度约束；

• full：默认强度；

• ultra：更强的极简倾向；

• off：关闭。

也就是说，它不是一次性提示词，而是一种可以长期生效的 Agent 行为约束。

适合谁用？

Ponytail 特别适合这些人：

• 经常用 Claude Code、Codex、OpenCode 写项目；

• 觉得 AI Agent 经常写太多；

• 希望减少不必要的依赖和封装；

• 主要在维护已有项目，而不是从零设计大架构；

• 喜欢小步修改、最小 diff、复用现有代码风格。

如果你正在做复杂架构设计、教学演示，或者希望 AI 多给方案、多解释，那可以临时关掉它。Ponytail 更适合“落地干活”，不太适合“展开讲课”。

安装方式

我选择直接把开源地址发给 Agent，让他自己装

总结

Ponytail 的价值，不在于让 AI 变得更会写代码，而在于让它更知道什么时候不该写代码。

它把一种成熟工程师的克制感写进规则里：

能不写就不写，能复用就复用，能用标准库就别造轮子。 真要写，也只写刚好够用的那一点。

在 AI 编程越来越强的今天，这种思路反而更重要。因为很多时候，我们缺的不是更多代码，而是一个能及时踩刹车的人。