Ponytail | 让 AI 编程代理先复用、再写最小实现

如果让 AI 编程代理实现一个日期选择器，它可能会先安装组件、写一层包装，再补一份样式。Ponytail 给代理加入一套相反的规则：先确认需求是否真的需要新代码，再依次检查现有代码、标准库、原生平台能力和已安装依赖，最后才写能够完成任务的最小实现。它不是新的模型，也不是代码生成框架，而是可安装到多种 Agent 宿主的开源规则集、技能与插件集合；项目采用 MIT 许可证。

截至 2026 年 9 月 2 日核对，DietrichGebert/ponytail 的默认分支是 main，最新 Release 为 v4.9.0（2026 年 8 月 7 日发布），package.json 版本为 4.9.0；GitHub 页面当时显示约 12.1 万 stars 和 6,541 个 forks。仓库统计、版本和适配器列表会继续变化，安装前应以官方仓库和 Release 页面为准。

Ponytail 把“少写代码”变成可执行的规则

Ponytail 的核心不是要求代理把每个回答都压缩成最少字符，而是在代理真正修改代码前，强制它先读懂相关代码和流程，然后从一条固定的决策阶梯中选择第一个成立的选项。README 用“浏览器已经有日期控件”为例：若需求只需要日期输入，原生 <input type="date"> 可能比引入第三方 date picker、包装组件和样式表更合适。

阶梯	问题	成立时的动作
1	这件事需要存在吗？	不需要就跳过，遵循 YAGNI
2	代码库里已经有吗？	复用现有实现，不重复重写
3	标准库能完成吗？	优先使用标准库
4	平台原生能力能完成吗？	使用浏览器、操作系统或运行时的原生能力
5	项目已经安装了依赖吗？	先使用现有依赖，不轻易增加新包
6	一行代码能完成吗？	保留一行解决方案
7	前面都不成立怎么办？	只实现能够工作的最小方案

这条阶梯的顺序很重要：它把“新增抽象”放到了最后，而不是把“少写几行”当成脱离上下文的目标。代理仍然需要先阅读变更所涉及的代码，理解真实数据流后再选择阶梯；Ponytail 只是把复用、原生能力和最小变更放到决策的前面。

Ponytail 最小实现阶梯与安全护栏概念示意 — Ponytail 的最小实现阶梯与安全护栏概念示意图，用于解释规则关系，并非某个 Agent 宿主的实际界面。

“懒”不等于跳过验证和安全

README 特别强调，Ponytail 的 lazy senior dev 不是代码高尔夫。信任边界上的输入校验、数据丢失处理、安全要求和无障碍能力都不在可删清单里；真正被压缩的是没有必要的包装、重复的抽象和未经证明的依赖。比如使用原生控件之前，仍要确认浏览器兼容性、键盘操作、错误提示和业务校验是否满足当前产品要求。

因此，Ponytail 更像一层决策约束，而不是“自动重构器”。它不会替团队定义安全策略，也不会替代测试、代码审查或威胁建模；如果需求确实需要缓存、权限隔离或复杂交互，代理仍应实现这些必要部分，只是避免先从过度工程化的方案开始。

官方 benchmark 应该怎样读

Ponytail README 的主要数据来自一次 agentic benchmark：让无头 Claude Code 会话修改 tiangolo/full-stack-fastapi-template 这一真实的 FastAPI + React 开源仓库，完成 12 个 feature ticket，再把同一个代理在有无技能时留下的 git diff 进行比较。模型是 Haiku 4.5，n=4。这比只比较单次回答的字符数更接近真实编码过程，但仍然是项目自己的测试，不是跨模型、跨代码库的普遍保证。

相对无技能基线	代码行数	tokens	成本	耗时	安全项
ponytail	-54%	-22%	-20%	-27%	100%
caveman（简短表达控制组）	-20%	+7%	+3%	+2%	100%
“YAGNI + one-liners”提示词	-33%	-14%	-21%	-30%	95%

上表中的百分比来自 README 的 12 项任务平均值；README 还指出，日期选择器等明显存在过度实现陷阱的任务，差距会更大，而原本已经很小的代码任务差距接近于零。仓库同时保留了早期 single-shot 测试，但作者明确说明其中 80%—94% 的差距受基线回答填充说明和备选方案影响，不能当作平均收益。README 还提醒，在 GPT-5.5 这类会花更多思考 tokens 斟酌阶梯的模型上，成本和耗时未必下降。

安装：把规则接入你的 Agent 宿主

Ponytail 同时提供插件、技能和 instruction-only 规则文件。不同宿主的权限模型并不相同，安装前要先确认你需要的是自动注入、命令面板，还是只读取 AGENTS.md。Claude Code 与 Codex 插件会运行两个很小的 Node.js 生命周期钩子，因此 Node 必须在非交互 shell 的 PATH 中；缺少 Node 时规则和技能仍可工作，但 always-on 激活会保持安静。

Claude Code

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

README 要求把两条命令作为两个独立提示发送。Claude Code Desktop 的 Code 标签页也可以输入同样的命令，或从 Plugins 菜单添加已配置的 marketplace。

Codex

codex plugin marketplace add DietrichGebert/ponytail
codex plugin add ponytail@ponytail

安装后运行 codex，打开 /hooks 检查并信任两个生命周期钩子，再新建会话；Codex Desktop 安装插件后需要重启应用。钩子属于外部执行入口，团队应按自己的安全流程审阅其来源和权限。

其他宿主和无插件回退

GitHub Copilot CLI 可使用 copilot plugin marketplace add DietrichGebert/ponytail 与 copilot plugin install ponytail@ponytail；Pi 支持 pi install git:github.com/DietrichGebert/ponytail；OpenCode 可在 opencode.json 中配置 @dietrichgebert/ponytail；Gemini CLI 可运行 gemini extensions install https://github.com/DietrichGebert/ponytail。Cursor、Windsurf、Cline、Kiro、Zed 等宿主可以复制仓库提供的规则文件；直接使用 AGENTS.md 是 instruction-only 路径，不会自动获得插件钩子和模式命令。

模式与命令：从轻量提醒到完整规则

默认模式是 full，可以使用 PONYTAIL_DEFAULT_MODE 环境变量设置为 lite、full、ultra 或 off，也可以在 Linux/macOS 的 ~/.config/ponytail/config.json（Windows 为 %APPDATA%\ponytail\config.json）中设置 defaultMode。模式不是质量等级承诺，而是控制规则注入强度和提示范围；新项目可以先用 full 观察 diff，再按团队流程调整。

命令	用途
`/ponytail lite\|full\|ultra\|off`	切换强度；不带参数时报告当前模式
`/ponytail-review`	检查当前 diff，返回过度工程化的删除清单
`/ponytail-audit`	审查整个仓库，而不只是当前 diff
`/ponytail-debt`	收集以 `ponytail:` 标记暂缓的快捷方案，形成待办账本
`/ponytail-gain`	查看 benchmark 影响面板
`/ponytail-help`	查看快速参考

在 Codex 中，这些命令以技能形式调用，例如 @ponytail-review。规则默认也会注入通过 Agent 工具启动的子代理；如果只希望匹配某些子代理类型，可以用 PONYTAIL_SUBAGENT_MATCHER 环境变量设置不区分大小写的正则表达式。OpenCode、Gemini、Pi 等宿主的命令入口和钩子能力各有差异，不能把一个宿主的行为直接推断到另一个宿主。

仓库结构与维护方式

Ponytail 不是只有一份提示词。仓库根目录同时维护 skills/、hooks/、.codex-plugin/、.claude-plugin/、.opencode/、.qoder/、pi-extension/ 等宿主适配目录，并在 package.json 中声明 npm 包 @dietrichgebert/ponytail 的版本和 MIT 许可证。开发者修改紧凑规则文本后，可以运行 node scripts/check-rule-copies.js 检查各适配器副本，运行 npm test 执行测试；OpenClaw 技能包则由 node scripts/build-openclaw-skills.js 从 skills/ 生成。

这种结构的优点是同一套原则可以被不同 Agent 读取，代价是适配器同步和宿主行为差异需要持续维护。使用者如果只复制了某一份规则文件，应在项目升级时重新对照官方仓库，避免规则文本和命令列表长期落后。

MIT 许可与使用边界

仓库根目录和 npm 包都标记为 MIT。通常可以使用、修改和再分发 Ponytail，但应保留版权与许可证声明，并自行核对仓库内第三方文件或宿主平台的额外条款。MIT 许可证不等于代码审查、安全合规或模型输出质量保证；插件钩子的执行权限、Agent 平台的账号权限和项目自身的安全政策仍由使用者负责。

适合谁用，不适合什么场景

如果团队经常遇到“为了一个小需求引入新依赖、重复造已有组件、把原生能力再包装一层”的 AI 产出，Ponytail 可以作为提交前的规则约束和 diff 审查入口。它尤其适合已经采用 Claude Code、Codex、Copilot CLI、OpenCode 或其他支持规则文件的 Agent 工作流，并希望把 YAGNI、复用和安全护栏写成共享约定的团队。

它不适合被当成自动性能优化器、漏洞扫描器或测试替代品；官方 benchmark 的样本、模型和代码库都有限，不能承诺你的项目一定减少同样比例的代码、tokens、成本或耗时。对于强制使用特定组件、复杂跨浏览器交互、严格合规审计或高风险数据处理的项目，仍应以项目规范、测试和人工审查为先。