Ponytail 安装教程：Codex、Claude Code 和 Gemini CLI 怎么用

Wed, 24 Jun 2026 21:02:49 +0800

Ponytail 是一个很有意思的 AI 编码插件。

它不是让 AI 更会“炫技”，而是反过来提醒 AI：先别急着写代码，先看看这事能不能不写、能不能复用、能不能用标准库、能不能用浏览器或平台自带能力解决。

如果你经常遇到这种情况：

1
2
3

只是想要一个日期选择器，AI 却装了组件库、写了封装、加了样式，还开始讨论时区。
只是想改一个小逻辑，AI 却顺手抽象出三层 helper。
只是想修一个 bug，AI 却重构了半个文件。

那 Ponytail 的思路就很对味：让 AI 像一个懒但靠谱的资深开发一样，先找最小改动。

Ponytail 是什么

Ponytail 可以理解成一组给 AI 编码代理看的工作规则。

它会提醒代理在写代码前先按一条“阶梯”判断：

1. 这个东西真的需要存在吗？
2. 代码库里是不是已经有了？
3. 标准库能不能做？
4. 平台原生能力能不能做？
5. 已安装依赖能不能做？
6. 一行代码能不能解决？
7. 最后才写刚好够用的新代码。

这不是代码高尔夫，也不是盲目追求短。它强调的是少做无效工作：能删就删，能复用就复用，能用原生能力就别造轮子。

项目 README 里有一个很典型的例子：日期选择器。

普通 AI 可能会装 flatpickr，写 wrapper，补样式，再解释一堆边界情况。

Ponytail 风格会先想到：

`1`	`<input type="date">`

这就是它想训练 AI 做的判断。

它解决的不是“代码短”，而是“别过度设计”

Ponytail 最容易被误解成“让 AI 写一行代码”。

其实更准确的说法是：让 AI 少做没必要的设计。

它保留安全边界，不鼓励删掉必要的校验、错误处理、安全处理和可访问性。该做的仍然要做，只是不要为了一个很小的需求引入一堆额外复杂度。

适合它处理的场景包括：

前端小功能；
表单控件；
简单工具函数；
配置文件调整；
小型 bug 修复；
代码审查时发现过度实现；
AI 改代码前的约束提醒；
让代理优先查找现有实现。

不适合把它理解成：

永远只写一行；
永远不加依赖；
永远不重构；
为了少代码牺牲可维护性；
为了速度跳过阅读代码。

Ponytail 的重点是“懒于实现，不懒于阅读”。

支持哪些 AI 编码工具

从项目 README 看，Ponytail 覆盖的工具比较多，包括：

Claude Code；
Codex；
GitHub Copilot CLI；
Pi agent harness；
OpenCode；
Gemini CLI；
Antigravity CLI；
CodeWhale；
Swival；
OpenClaw；
Cursor、Windsurf、Cline、Aider、Kiro、Zed 等规则文件方式。

这类项目的好处是：你不一定非要换主力 AI 工具。

如果你现在用的是 Codex，就按 Codex 插件方式装；如果你用 Claude Code，就走 Claude Code 插件市场；如果只是想把规则放进编辑器，也可以复制对应的规则文件。

Codex 里怎么安装 Ponytail

如果你使用的是 Codex CLI，README 给出的入口是：

1
2

codex plugin marketplace add DietrichGebert/ponytail
codex

然后在 Codex 里：

打开 /plugins；
选择 Ponytail marketplace；
安装 Ponytail；
打开 /hooks；
检查并信任它的两个 lifecycle hooks；
开一个新对话开始使用。

如果你用的是 Codex 桌面版，README 里也提到：安装完成后重启应用，插件会被识别。

注意一点：Ponytail 的 Claude Code 和 Codex 插件会运行两个很小的 Node.js lifecycle hooks，所以 node 需要在 PATH 里。README 也说明，如果没有 node，skills 仍然可以工作，只是 always-on 激活不会自动生效。

可以先检查：

node -v

如果命令找不到，先安装 Node.js，或者确认当前非交互 shell 的 PATH 能找到 node。

Claude Code 怎么安装

Claude Code 的安装命令是：

`1`	`/plugin marketplace add DietrichGebert/ponytail`

然后再发一条：

`1`	`/plugin install ponytail@ponytail`

README 特别提醒，这两条需要分两次发送。

如果你用的是 Claude 桌面应用，没有 /plugin 命令，需要从 UI 里添加个人插件市场：

打开 Customize；
点击 personal plugins 旁边的加号；
创建插件并添加 marketplace；
选择 Add from repository；
输入 Ponytail 的 GitHub 仓库地址。

GitHub Copilot CLI 怎么安装

Copilot CLI 可以用：

1
2

copilot plugin marketplace add DietrichGebert/ponytail
copilot plugin install ponytail@ponytail

在交互式 Copilot CLI 会话里，也可以用 slash 命令：

1
2

/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytail

安装后，Copilot CLI 里可以通过 Ponytail 命令使用不同能力，例如 README 中提到的：

1
2

/ponytail:ponytail ultra
/ponytail:ponytail-review

Gemini CLI 和 Antigravity CLI

Gemini CLI 的安装方式是：

`1`	`gemini extensions install https://github.com/DietrichGebert/ponytail`

它会把规则集作为每次会话的上下文加载，并注册 /ponytail 相关命令。

Antigravity CLI 可以用：

`1`	`agy plugin install https://github.com/DietrichGebert/ponytail`

README 里还提到，Google 正在把 Gemini CLI 改名为 Antigravity CLI，所以一段时间内两种路径可能会并存。实际使用时，按你当前安装的 CLI 名称来。

OpenCode 怎么用

OpenCode 可以在 opencode.json 中加入：

`1`	`{ "plugin": ["@dietrichgebert/ponytail"] }`

如果你从本地 checkout 运行，也可以指向本地插件文件：

`1`	`{ "plugin": ["./.opencode/plugins/ponytail.mjs"] }`

这种方式适合已经在 OpenCode 里管理项目配置的人。

只想用规则，不想装插件怎么办

Ponytail 仓库里还放了很多不同工具的规则文件。

例如：

AGENTS.md；
.cursor/rules/；
.windsurf/rules/；
.clinerules；
.github/copilot-instructions.md；
.kiro/steering/。

如果你的工具支持读取项目级规则，可以直接复制对应文件。

比如 VS Code 的 Codex 扩展会读取 AGENTS.md。如果你把 Ponytail 的 AGENTS.md 放到项目根目录，或者放到全局 Codex 配置位置，就可以用规则方式让 Codex 遵循这套思路。

插件方式更完整，规则文件方式更轻。

Ponytail 适合怎么提示

装完以后，不要只期待它“自动变聪明”。你也可以在任务里主动配合它。

比如：

`1`	`请先检查现有代码里是否已经有类似实现，优先复用；只有确实没有时再新增最小实现。`

或者：

`1`	`这个需求不要过度设计。先判断是否可以用标准库、原生 HTML 控件或已有依赖解决。`

再比如做 code review：

`1`	`请按 Ponytail 思路审查这次改动，重点找过度抽象、重复实现、不必要依赖和可以用原生能力替代的地方。`

这类提示和 Ponytail 的规则方向一致，效果会更稳定。

适合用 Ponytail 的典型任务

1. 前端控件

比如日期、颜色、文件上传、数字输入、开关、下拉选择。

AI 很容易一上来装组件库，但很多场景原生 HTML 控件已经够用。

2. 工具函数

比如去重、排序、格式化、路径处理、日期处理。

先看语言标准库和项目已有 helper，再决定要不要写新函数。

3. 配置改动

比如 ESLint、TypeScript、Hugo、Vite、Docker、CI 配置。

很多配置问题只需要改一行，不需要写脚本或新增工具链。

4. 小 bug 修复

Ponytail 思路适合先找最小修复点，避免 AI 为了修一个 bug 引出大重构。

5. 代码审查

它很适合当作“过度设计检查器”。

你可以让 AI 看 diff，专门回答：

有没有重复造轮子；
有没有没必要的新依赖；
有没有可以直接删除的代码；
有没有复杂度超过需求的实现；
有没有可以复用现有模块的地方。

使用时要注意什么

Ponytail 的方向很好，但不要把它变成新的教条。

下面这些场景不能为了少代码而硬省：

输入校验；
权限检查；
数据丢失保护；
并发和事务安全；
用户隐私；
可访问性；
错误处理；
关键日志；
测试覆盖。

简单不是粗糙。

如果一个功能涉及安全边界、资金、用户数据、生产环境操作，最小实现也必须把边界处理清楚。

我的建议用法

如果你第一次用 Ponytail，可以按这个顺序试：

先在一个小项目里安装；
用一个很容易过度实现的需求测试，比如日期选择器或颜色选择器；
对比没有 Ponytail 时 AI 会写什么；
再让它审查一次已有 diff；
最后再放到日常项目里。

不要一上来就拿大重构测试。

Ponytail 最能体现价值的场景，是那些“本来很小，但 AI 特别容易写大”的任务。

一句话总结

Ponytail 不是让 AI 变成只会写短代码的工具，而是让 AI 在动手前多问一句：

`1`	`这段代码真的需要写吗？`

如果你用 Codex、Claude Code、Copilot CLI、Gemini CLI 这类 AI 编码代理，经常被它们的过度实现烦到，可以试试 Ponytail。它不能替你判断所有架构问题，但很适合给 AI 加上一层“少造轮子、少绕路、先复用”的约束。

Ponytail on KnightLi的博客