10万星标 Skill「马尾」：95 行代码，逼 AI 学会偷懒写代码

把踩过的坑，焊成删不掉的规则：一个 95 行 Skill 的活法

胖猫小栈 · 开源工具拆解 · 2026.08

最近 GitHub 上有个仓库挺火，叫 ponytail（DietrichGebert/ponytail），10 万 + 星标，MIT 协议，最新 v4.9.0，自称能让 AI 像「最懒的资深开发」那样写代码。名字来自那种扎马尾、戴椭圆眼镜、进公司比版本库还早的老工程师——你把五十行代码递给他，他一声不响换成一行。

它的 README 例子是真实的：你让 AI 加个日期选择器，普通 agent 会装 flatpickr、写 wrapper、加样式表，然后跟你聊时区；ponytail 直接给你一个更短的答案。仓库地址在这里：
https://github.com/DietrichGebert/ponytail

它到底是什么

skills/ 目录下只有 6 个 SKILL.md，最大的才 6.6KB，最小的 1.6KB。但 tests/ 里有 15 个测试文件，benchmarks/ 里 10 份带日期的实验报告，整个仓库 212 个文件。换句话说，围绕这个 skill 的「工程量」，是它本身的好十几倍。

我自己的看法：这个比例，基本就是「会写 skill」和「写得住 skill」的分水岭。大部分人卡在前半段，以为写 skill 就是写一篇好文档。

核心是一把「梯子」

ponytail 的核心机制叫 the ladder（梯子），一共 7 级，每一级都是一个可判定的「是/否」：

• 这东西真的需要存在吗？不需要就跳过（YAGNI）
• 代码库里已经有了吗？有就复用
• 标准库能搞定吗？用标准库
• 平台原生能力覆盖了吗？用原生
• 已装的依赖里有吗？用依赖
• 一行能写完吗？
• 只有到了这里，才写能跑的最少代码

关键一句在梯子上方：停在第一个成立的那一级。这不是文风，是工程约束——它给了 agent 一个明确的停止条件，不然它会在「权衡」里越陷越深，反而写更多代码来证明自己权衡过了。

真实翻车：v1 让 agent 在「要不要建」上纠结太久，5 个任务总耗时 228 秒，对照组才 136 秒。v2 加了「梯子是反射，不是研究项目」的补丁后，时间降了 31%。还有一句我最喜欢：真实时钟会漂移，真实传感器会读偏，PCA9685 会跑快几个百分点——所以留有校准旋钮，别把配置当「多余的东西」删掉。这是作者踩过舵机全歪之后补的。

几条值得偷师的硬规则

• description 是你唯一的触发器。Skill 的 name + description 是 agent 决定要不要调用它的唯一依据，所以「绝不做什么」也得写进 description，而不是正文——因为正文在触发那一刻还没被加载。
• 每条硬规则都配一条反向补丁。写完「要懒」，就明确禁止「在理解问题上偷懒」。
• 固定动作脚本化。规则一致性校验、债务收割、benchmark 复现，全用脚本跑，不让 agent 手翻。
• 先立正确性闸门，再追效率指标。行数只记录不裁判，能不能跑才是裁判。否则你会拿到「指标满分但跑不起来」的玩意。
• 测行为，不测文本。双臂对照：有 skill vs 无 skill，差值才是 skill 的全部价值。

好 skill 是测出来的，不是想出来的

大多数人写 skill：想一想、写下来、感觉不错、发布。ponytail 是：写下来、和「没有它」对打、量出来、改、再打。

• v1：代码最少（比无 skill 少 5.5 倍），但总 token 反而输 4%，耗时 228s vs 136s。原因：代码极简，却写了长篇「我为什么故意没建」的小作文，散文把省下的都吃回去了。
• v2：加输出上限 + 梯子是反射，token −4.8%，时间 −31%（70 秒）。
• v3：只做一件事——把 SKILL.md 从 115 行压到 95 行，再降 915 token、31 秒。

最精彩的一段：issue #65 有人报告 ponytail 让 gpt-4.1-mini 正确率从 15/15 掉到 10/15。作者一查，74 次失败里 72 次是测试自己的 bug——评分器把「裸代码」判成了零分。修好之后两臂都是 100/100。作者还照实写下：2/20 次模型抓了 lib 方案却漏了邮箱本地校验，说「这是走向一行式的真实代价」。

还有件少见的事：issue #126 指出对照组的「少写 80-94%」被高估了，作者二话不说，把头条数字改成「约 54% 更少代码（最高 94%）」，并明写「#126 说得对」。一个愿意下调自己数字的仓库，比数字漂亮的可信得多。

写在最后

开头那个比例我一直记着：6 个 skill 文件，15 个测试文件，10 份实验报告。很多人以为写 skill 的门槛在「把提示词写得更聪明」。但看完 ponytail，我觉得正好相反——写出一个像样的 skill 一个下午就够；让它三个月后还不变形、换 5 个平台还一致、被人质疑时还能拿出数字，靠的不是灵感，是工程。

最打动我的，是 AGENTS.md 最后一行：这套规则也适用于在 ponytail 仓库上干活的 agent，尤其适用于它们。最好的 skill，是三个月后没人需要去修的那一个。

我自己折腾 agent 也有段时间了，最大的体会是：真正省时间的不是「让 AI 少写」，而是「不让 AI 在该停的地方硬写」。ponytail 把这件事钉成了规则，挺值得抄。

开源协议：MIT。使用前请确认你的 Agent 宿主支持 Skill 机制；文中数据来自仓库官方 benchmark，未实测的部分以官方文档为准。