HeyBinyang

最好的代码是没写的那行:聊聊开源插件 ponytail

·技术·visibility4 阅读 ·AI·开发

现在大家都在用 AI 写代码,但一个很现实的问题是:AI 写得太多了

同样一个小需求,一不小心就变成几十上百行,各种抽象、各种封装,评审和维护成本反而被抬高了。

有没有可能,让 AI 像那个“公司里最懒但最稳的老前辈”一样,只写刚刚够用的最小实现?

ponytail 就是为此而生的一个开源规则集(skill/plugin)。它的 Slogan 非常简单粗暴:

He says nothing. He writes one line. It works.

你给 50 行,它看一眼,默默删到 1 行,还能跑通。

ponytail 是什么?

用一句话总结:ponytail 把一个“极度懒惰的资深工程师”塞进了你的 AI 代码助手里。

它不是一个新的大模型,也不是一套框架,而是一组可以装进各类 AI coding agent 的「规则 + 技能」:

  • 以最小实现为目标,强制 AI 优先考虑标准库、语言内建、已有依赖。

  • 把“能不写就不写,能一行就不两行”写成明确的决策阶梯。

  • 提供一套命令(/ponytail、/ponytail-review、/ponytail-audit 等),帮你找出项目里可以删、可以简化的部分。

在官方基准测试里,开启 ponytail 后,AI 在常见任务上的表现大概是这样:

  • 代码量减少 80–94%

  • 生成速度提升 3–6 倍

  • Token 成本降低 47–77%

而安全、边界检查、可访问性这些东西,是明确禁止“抠门”的,不会为了偷懒牺牲关键防线。

一个经典例子:日期选择器

ponytail README 里举了一个非常典型的例子——“我要一个日期选择器”。

默认情况下,很多 AI 的做法是:

  • 安装第三方日期库(比如 flatpickr)

  • 写一个 React 包装组件

  • 引入一堆样式和配置

  • 顺便开始讨论时区、国际化……

而有了 ponytail 之后,它会先走一遍“懒惰阶梯”(下面一节会讲),然后得出一个极简解法:

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

就这一行。

  • 浏览器原生支持日期输入

  • 不需要多余依赖

  • 对大部分业务场景已经足够好用

如果你未来真的需要换成自定义组件,这个 ponytail: 注释也帮你标好了升级路径。

它是怎么让 AI 变“懒”的?

ponytail 的核心是一座 6 级“决策阶梯”,在 AI 写下任何一行代码之前,都必须按顺序自问自答:

1. 这东西真的需要存在吗?→ 不需要:直接跳过(YAGNI)
2. 标准库已经提供了吗?→ 有:用它
3. 语言 / 平台有原生特性吗?→ 有:用它
4. 项目里已经安装的依赖能解决吗?→ 能:用它
5. 能用一行解决吗?→ 能:写一行
6. 以上都不行 → 写一份“刚好能用”的最小实现

只要在某一层找到了够用的方案,就停止往下走,不再继续造轮子

这背后其实是把我们平时嘴上经常说的几条工程原则(YAGNI、KISS、优先用标准库)写成了硬规则,并且“注入”到 AI 的系统提示和插件逻辑里。

值得注意的是: 像信任边界校验、数据丢失风险、安全性、可访问性这些事项,pony tail 明确标记为永远不能偷懒的区域,不会为了少几行代码把它们砍掉。

实际效果:更少的代码,更快的反馈

在作者给出的基准实验里,他们用三个不同模型(Haiku、Sonnet、Opus),做了五类日常任务(邮箱校验、防抖、CSV 求和、倒计时计时器、限流器),对比了三种模式:

  • 无技能(普通 AI agent)

  • caveman 技能(另一套收敛规则)

  • ponytail 规则集

结论是:ponytail 在所有模型上都稳定实现了 80–94% 的代码行数削减,同时加快生成速度并降低成本,而且任务依然通过相同的安全与并发测试。

更重要的是,它不是简单“少写点”,而是尽可能保留:

  • 可读性:避免过度压缩到难以维护

  • 可演进性:每一处偷懒都会用 ponytail: 注释写明“以后要认真做的时候怎么升级”

对有代码洁癖的开发者来说,这更像是一个“自动帮你删冗余”的搭档,而不是一个只会胡乱删代码的 minifier。

支持哪些 AI 工具?怎么用?

目前 ponytail 已经适配了不少主流 AI coding agent 和工具链,你大概率在用的几个都能直接装:

  • Claude Code(官方插件)

  • Codex

  • GitHub Copilot CLI

  • Gemini / Antigravity CLI

  • OpenCode

  • Pi agent harness

  • 以及通过规则文件方式接入的:Cursor、Windsurf、Cline、GitHub Copilot(编辑器)、Kiro 等等

典型的安装方式非常“懒”,比如在 Claude Code 里只需要两步(在命令输入框里执行):

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

Copilot CLI 里也有类似的 marketplace 命令;而像 Cursor / Windsurf 这类,则是把仓库里的规则文件拷贝到对应位置即可。

安装完成后,你可以通过命令调整“懒惰等级”:

  • /ponytail lite

  • /ponytail full(默认)

  • /ponytail ultra(对过度设计深恶痛绝时使用)

  • /ponytail off(临时关闭)

另外还有几个很实用的命令:

  • /ponytail-review:只审查当前 diff,给出可以删 / 简化的清单

  • /ponytail-audit:对整个仓库做一次“过度工程”体检

  • /ponytail-debt:把代码里的 ponytail: 注释汇总成一份“技术债清单”,避免“以后重构”永远变成口头禅

如果你想全局打开某个默认模式,也可以通过环境变量或配置文件设置 PONYTAIL_DEFAULT_MODE,例如设为 fullultra

适合谁?一些实践建议

从 ponytail 的设计来看,它特别适合下面几类场景:

  • 你大量依赖 AI 写样板代码,但又不想让项目变成“AI 产出的代码垃圾场”

  • 你在维护一个中大型前后端项目,想通过 /ponytail-review/ponytail-audit 找出可以删减的冗余实现

  • 你在做教学 / Demo / 文章配套代码,希望示例尽可能短小、聚焦核心逻辑

结合我自己的经验,比较推荐的使用方式是:

  • 把 ponytail 作为 默认开启 的规则集,让 AI 从一开始就少写点

  • 对已有项目,用 /ponytail-review 先从新增 PR 开刀,再视情况对整个仓库做 /ponytail-audit

  • 在评审时把 ponytail: 注释当成一个“可升级锚点”,需要做更严谨实现时从这里切入

如果你也在用 Claude Code、Cursor 之类的 AI IDE,不妨装上 ponytail 在一个真实项目里跑一周,你会非常直观地感受到:AI 不啰嗦了,代码也瘦身了。

分享