Ponytail技能实测：代码量减少15%而非54%，成本降低10%

为什么我们做这个测试

ponytail 技能的设计目标是让 AI 智能体写更少的代码。它的核心理念：一个见过各种情况的高级开发者会用一行代码替换你的五十行。如果需要实现一个日期选择器，它不会安装 flatpickr 并编写一个包装组件，而是直接写 <input type="date"> 并继续。

从机制上讲，这是一个模型在编写任何代码之前必须爬升的阶梯：这个功能真的需要存在吗？代码库里是否已经有了？标准库是否提供？原生平台是否有？已安装的依赖中是否包含？能否只用一行完成？只有这些问题都得到否定回答后，才编写最小可行的代码。这个阶梯是在理解问题之后运行的，而不是代替理解；同时，验证、错误处理、安全性和可访问性被明确排除在削减范围之外。

以下是实际运行中的例子，来自我们自己的测试。两个智能体都被要求将一个 three.js 场景导出为 Blender 兼容的 OBJ 文件；两者都生成了验证器接受的文件。它们都编写了相同的复杂循环来展开实例化网格，因为 three.js 的 OBJExporter 无法处理这些网格。区别在于围绕这个循环的所有代码。为了将场景旋转到 Blender 的坐标系并写出文件，普通智能体构建了一个包装对象来持有旋转，并命名了每个中间步骤：

// 无技能 — 10 行语句用于旋转场景并写入文件
const exportRoot = new THREE.Group();
exportRoot.name = 'blender_export_root';
exportRoot.rotation.x = -Math.PI / 2;
exportRoot.add(root);
exportRoot.updateMatrixWorld(true);

const exporter = new OBJExporter();
const objString = exporter.parse(exportRoot);

const outputPath = '/root/output/object.obj';
fs.mkdirSync(path.dirname(outputPath), { recursive: true });
fs.writeFileSync(outputPath, objString);

// ponytail — 同样的工作，5 行语句
root.rotation.x = -Math.PI / 2;
root.updateMatrixWorld(true);

const obj = new OBJExporter().parse(root);
fs.mkdirSync('/root/output', { recursive: true });
fs.writeFileSync('/root/output/object.obj', obj);

这里没有牺牲任何东西。Ponytail 旋转了它已经拥有的对象，而不是构建一个父对象来替它旋转，并且同时跳过了导入。十行变成了五行，两个文件导出了相同的几何体，且都得了 1.0 分。这正是效果如广告所说——在单个文件、单个任务上。

最核心的宣称是 −54% 代码，加上 −22% 令牌、−20% 成本以及 −27% 时间。这个测试之所以值得做，是因为该宣称的文档化异常充分。作者们根据批评（issue #126）重建了基准，他们最初的数字来源于一个话很多的基线，之后他们发布了诚实的版本：一个真正的无头 Claude Code 会话编辑真正的 FastAPI + React 仓库，并用它留下的 git diff 评分。甚至，他们还记录了自己测试框架中发现的一个污染漏洞——SessionStart 钩子会在每一次试验中触发，从而在基线中秘密运行 ponytail。

这种方法上的坦诚程度超过这个领域的大多数工具。所以问题在于：这个效果能否在一个非作者选择的基准、更强的模型以及验证器评分的质量检验下存活。

设置

有一个细节看似不起眼但至关重要：我们生成 Arm B 的注入文本时，调用了 ponytail 自身的 hooks/ponytail-instructions.js，而不是编写一个总结，因此模型看到的规则集是技能自己的原文，而不是我们的转述。这覆盖了钩子生成的规则集，但并未覆盖真实首次运行时钩子的所有副作用。每个带有 ponytail 的试验之后都会被审计，以确认规则集确实到达了模型；每个基线试验也被审计，以确认规则集没有到达。这个检查直接继承自 ponytail 在其自身基准中发现的那个污染漏洞，结果干净利落：100% 的处理组试验，0% 的基线试验。

发现 1——ponytail 技能在 Claude Code 中会自动激活吗？

在付费运行之前，我们测试了简单的安装路径：放下技能，让 Claude Code 自行决定何时使用它。Ponytail 的描述正是这样引导的，告诉模型在*“任何编码任务：编写、添加、重构、修复、审查或设计代码”*中使用它。

在所有十个会话中，它自激活了零次。不是稀少，是从来没有。技能已经安装并可见，但模型一次也没有调用它。

这不是 ponytail 的 bug，正因如此，该工具作为一个带有 SessionStart 钩子的插件发布，无论你是否要求，它都会注入规则集。但这意味着安装方式决定了你是否能得到任何结果。将 SKILL.md 复制到技能文件夹中，你很可能会测不出任何效果。下面所有数字都来自规则集确实被注入的那个 arm。

发现 2——观察到的代码削减量仅为广告规模的约三分之一

在 80 个配对任务中，一个典型任务减少了智能体编写代码的 15.4%；总计从 10,205 行降至 8,756 行。这是一个显著的观察到的缩减。然而，p=0.088 使得它成为我们核心指标中最不显著的一个。它也远未达到 54%。

关于这个差距，有两点需要说明，这两点对工具都是公平的。首先，他们的 −54% 是十二个精心挑选的功能工单的平均值；而我们的 −15.4% 是 80 个无人专为此目的选择的任务的中位数。在偏态分布中，平均值和中位数是不同的概念，而且他们自己的文章明确指出该数字“在智能体过度构建时达到 94%，在代码已经是最小化时接近零”。

其次，也是更有趣的一半：我们的数据也指向了相同的方向。

发现 3——节省主要集中在有过度构建空间的领域

根据基线编写的代码量来划分任务。Ponytail 不能自己选择进入哪个桶，因为代码量由普通智能体决定。不过必须坦率地说：这些阈值是我们在看到数据后选择的，并且按照基线自身的输出进行分组本身就可能放大这种梯度。请将图表视为关于效果所在位置的强烈提示，而非一条测定定律。

在大构建任务上，削减达到 −31% 。在普通智能体已经几乎不写什么的任务上，典型任务的变动为零——尽管该组的总行数实际上从 104 行上升到 910 行，而这个缺口正是本次运行中一个真正的意外出现的地方。

在七个任务中，我们的计数器记录到普通智能体编写了零行代码，而 ponytail 编写了 51 到 230 行。阅读记录，这个差距主要源于代码存在的位置而非代码的多少。普通智能体将其解决方案直接通过管道输入 Python 解释器（作为一个 heredoc），这产生了交付物但未留下脚本。Ponytail 则将同类逻辑写入了一个文件。我们的计数器将保存的文件视为代码，将内联 heredoc 视为临时数据，因此一个 arm 被计入成本而另一个没有。

需要明确这些文件是什么：全部七个都是普通的工作脚本——edit.py、diff.py、build_model.py——不是测试。因此这不是 ponytail 的“留下一个可运行的检查”规则在起作用；它只是将解决方案保存到了磁盘上，而普通智能体则通过解释器管道传递了等效内容。我们不能说 ponytail 在这些任务上写了更多代码，只能说它的更多代码被持久化了。

这对核心数字有偏倚吗？略有，且双向都有。Ponytail 独自在 7 个任务上持久化了代码（761 行）；普通智能体独自在 4 个任务上持久化了代码（567 行）。净影响，约 190 行（占 10,205 行的不到 2%）对 ponytail 不利，这个数量很小，不足以支持任何一种结论。我们不会声称 −15.4% 是保守估计。

发现 4——账单下降了，这次信号可靠

使用 ponytail 后，典型任务成本降低了 10.3%：在 80 对中 p=0.004，46 个任务更便宜，34 个更贵。这是本系列到目前为止最强的正向成本结果，也是第一个可靠的节省而不是可靠的惩罚——rtk 的 +7.6% 同样显著，但方向相反。Caveman 在去除一个定价等级异常值后也节约了约 10%，但那是一个脆弱的数字，依赖于一次排除；这是成本差异首次在完整运行的配对测试中存活。

一个诚实的限制条件（因为我们希望它被用在供应商身上）：中位数节省是 −10.3%，但中位数周围的散布足够宽，以至于自举区间刚好触及零。方向得到良好支持，每任务测试也很清晰。“在这个工作负载上大约便宜 10%”是站得住脚的；“ponytail 能节省 10%”则不是。

值得一提的是，输入侧的变动并不干净。重新读取自身历史下降了 8.4%，新令牌下降了 3.9%，两者都不显著（p=0.138 和 p=0.085）。在第二部分中，我们发现智能体的账单主要由重新读取主导，这就是为什么一个压缩命令输出的工具几乎没能影响它。Ponytail 攻击账目的另一侧——模型编写的内容——在这个基准上，这正是金钱移动的一侧。

发现 5——没有可检测到的质量差异

一个以“写更少”为全部个性的技能，明显的担忧是它通过删除重要的东西来达到目的。Ponytail 声称它从不碰验证、错误处理、安全性和可访问性，并在其自身基准的另一个对抗性层级中报告了 100% 的安全。

我们无法评价这个安全声明，并想明确说明原因：SkillsBench 验证器评分的是任务是否完成。它们不是安全性、验证或可访问性套件。以下内容并不测试 ponytail 是否保留了防护，只测试工作是否仍然通过。

九个任务得分略低，六个略高，65 个相同——统计上不可区分。这是一个零结果，而非健康证明：这次运行设计的统计功效从未足以证明等价，数据既与小幅退化兼容，也与小幅改进兼容。我们能说的是，这里没有任何东西看起来像明显的失败模式——即写更少悄悄导致测试不通过。

一个关于遵从性的小注记。Ponytail 的规则集要求模型用 ponytail: 注释标记故意的捷径，并说明天花板和升级路径。在规则集显然在上下文中的 80 次试验中，这种情况只发生了一次。阶梯被遵循了，但文书工作没有。

发现 6——小样本两次误导了我们

值得展示，因为这是整个系列试图避免的陷阱。我们的十任务烟雾测试显示 ponytail 削减了 3% 的代码，却让事情贵了 9.6%，平均任务得分从 0.51 骤降至 0.31。如果我们当时发表了，我们会写出一篇完全不同的、错误百出的文章。

结论

Ponytail 有效。在 80 个配对任务中，它将典型账单降低了 10.3%，减少了 15% 的代码编写量，且我们没有检测到质量差异。这是本系列中第一个明确节省金钱的工具。如果你安装它然后不再管它，你应该会略有改善。

不要指望广告中 54% 处处可见。Ponytail 的基准使用了带有明显过度构建陷阱的任务。我们的则没有。在我们的运行中，代码在较大的构建任务上下降了 31%，在已经精简的任务上几乎没有变动。你的智能体过度构建得越多，ponytail 能削减的就越多。

有声称节省令牌的工具吗？告诉我们哪个，我们会用相同的基准运行它。

方法论注释

• 永远不要相信 k=1。 升级阶梯：免费记录审计，然后是 10 任务烟雾测试，然后是相同 10 任务在 k=3 下重复，然后是完整 80 任务。发现 6 展示了烟雾测试会告诉我们什么。
• 仅配对分析。 在双臂之间进行每任务比较；任何在一臂中出现错误的任务都会从双臂中剔除。质量使用符号检验，其余使用每任务中位数加 Wilcoxon 检验，因为一个长上下文会话的账单可能达到正常的 25 倍并破坏平均值。
• 付费运行前固定终点： 奖励、编写的代码、输出令牌、新输入令牌、成本、回合数、挂钟时间。总令牌数是之后添加的，一旦我们检查了 ponytail 自己的 benchmarks/agentic/run.py 实际广告的是哪个指标。它汇总了输入、缓存和输出，所以只对比我们的输出指标与它的 −22% 会使我们看起来好三倍。
• 零结果在这里的含义与不含义。 质量比较是显著性检验，而不是等价检验。“未检测到差异”是诚实的解读；证明质量真正不变需要非劣效性设计，并预先声明界值，而且——在这个基准约 40% 的基线通过率下，检测 5 个百分点的通过率变化需要 80% 的统计功效——每个 arm 需要几百个配对任务，而不是 80 个。
• 采用情况有仪器记录。 每次试验都审计规则集是否到达模型——处理组 100%，基线组 0%——这样“ponytail 什么也没节省”永远不会与“ponytail 从未运行”混淆。
• 没有工作区差异时的代码测量。 Ponytail 自己的基准统计 git diff 新增行。Harbor 不保留智能体运行后的工作区，因此我们从智能体的工具调用中重建等价物：Write、Edit 以及重定向到文件的 shell heredoc，按非空、非注释行计数，与 ponytail 的 benchmarks/loc.js 完全一致。这是累计发出的行数，不是最终实现的大小：一行被编写后又重写，每次都会被计数。通过管道输入解释器的 heredoc 被视为临时分析并被排除。我们在这些数字来源的运行上审计了提取器的覆盖率：Write 和 Edit 占计数的 95.6%（18,961 行中的 15,632 行和 2,496 行），因此该指标不是由于遗漏代码去向而产生的人为结果。两个无法看到的东西，在双臂中对称：运行时脚本写入的文件，以及在子智能体内编写的代码。
• 来源。 ponytail 锁定在提交 16f2980（v4.8.4，MIT）；智能体版本在双臂中锁定；注入的规则集由 ponytail 自己的钩子代码生成，sha256 已记录。SkillsBench 的 87 个任务中有 7 个被排除：一个完全无法在本地沙箱中运行的任务，以及六个在我们的硬件上在两臂中都同样失败的任务。排除是对称的——任务要么从双臂中剔除，要么都不剔除——完整列表随评估构件一起保留。
• 这不能告诉你的。 SkillsBench 是数据、分析和修复工作；它很少包含导致 ponytail 最大胜利的前端过度构建陷阱。这是对成本、速度和质量声明的公正测试，也是对代码声明的保守测试。它并不反驳他们自己任务集上的 −54%。

图表风格借用于 dither-kit，此处作为无依赖的内联组件实现。## 常见问题解答

ponytail skill 能与 Claude Code 一起使用吗？

可以，但安装方式很重要。如果你把 SKILL.md 复制到 skills 文件夹中，让模型自行决定何时使用，那么它实际激活的次数为零——我们在十次会话中确认了这一点。Ponytail 被设计为通过 SessionStart 钩子自动注入规则集的插件来运行。只有这种配置才能产生可衡量的效果。

ponytail skill 实际能减少多少代码和 token 用量？

在 80 个配对任务中，我们测得的代码编写量中位数减少 −15%，成本降低 −10.3%。宣称的 −54% 代码缩减在存在明显过度构建陷阱的任务中是真实的；我们的基准测试偏向于数据和分析类工作，属于更保守的测试。在我们运行的大型构建中，代码量下降了 31%。

ponytail skill 会降低代码质量吗？

在 80 个任务中，我们没有发现统计学上显著的质量差异——65 个任务评分完全相同，9 个稍差，6 个稍好。这是一个零结果，而非完全健康的证明：本次测试的统计效力不足以证明等价性。它能排除的是一种明显的故障模式：即少写代码在不知不觉中破坏功能。

什么是用于 Claude Code 的 ponytail skill？

Ponytail 是一个开源 AI Agent 技能，它约束模型编写最简代码。在生成任何内容之前，它会先通过一系列问题检验：这个东西是否需要存在？代码库中是否已有？标准库能否处理？能否用一行代码搞定？验证、错误处理、安全性和可访问性被明确排除在其极简规则之外。

ponytail skill 与其他节省 token 的技能相比如何？

在本系列测试中，ponytail 是唯一一个产生了统计学显著成本节约的工具。caveman skill 实现了 −8.5% 的代码缩减（宣称 −65%）。RTK 导致了 +7.6% 的成本增加。Ponytail 实现了 −10.3% 的成本降低，p 值 = 0.004——这是本系列中第一个可靠的正面结果。