Ponytail Skill for Claude Code: Does It Really Cut Agent Code by 54%?

Ponytail 技能对 Claude 代码：真的能减少令牌吗

JetBrains AI

通过 JetBrains 产品中的 AI 功能增强您的工具

关注

• 关注：

• RSS RSS

查看更多

智能体 AI

AI

AI 助手

Ponytail 技能对 Claude 代码：真的能减少智能体代码 54% 吗？

Denis Shiryaev

系列文章的第三部分，我们测试了公开的"令牌节省"插件对编码智能体的效果，并对每个插件运行相同的 A/B 对比基准测试。第一部分是原始人技能（宣传减少 65%，实际减少 8.5%）。第二部分是 rtk（宣传减少 60-90%，实际增加 7.6%）。

我们运行了 80 个配对任务来测试 Ponytail 技能对 Claude 代码的效果。宣传效果：减少 54% 代码，减少 22% 令牌，减少 20% 成本，减少 27% 时间。实际效果：减少 15% 代码，减少 10.3% 成本，减少 11% 时间。以下是实际发生的情况。

实际节省效果虽然只有宣传效果的四分之一到一半，但这是该系列中第一个具有统计显著性成本节省信号的工具。我们没有发现质量差异，但约 80 对样本只能排除较大的差异。关键点在于：代码缩减效果只出现在存在过度构建空间的场景中。

WIDGET:tiles START（将此代码块复制到 WP 自定义 HTML 块中）

WIDGET:tiles END

为什么进行这次测试

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%的token使用量、20%的成本和27%的时间消耗。此次测试特别具有价值的原因在于，该主张的文档记录异常详尽。作者在收到针对原始基准的批评（问题#126）后，重新构建了其基准测试，他们公开了诚实版本：真实无头模式的Claude Code会话正在编辑真实的FastAPI + React仓库，其评分基于其留下的git diff。他们甚至记录了在自身测试框架中发现的污染漏洞，其中SessionStart钩子在每个臂上都会触发并秘密运行ponytail基线。

这种方法论上的坦诚程度在该领域内并不多见。因此，此处的问题是：该效果是否能在作者未选择的基准测试中、在更强的模型上、通过验证器评分的质量评估中得以延续。

设置

工具链

Harbor 0.18 — Docker沙箱、任务验证器、配对运行

代理

Claude Code 2.1.201，无头模式运行

bypassPermissions

在两个臂中均固定启用

模型

claude-sonnet-5

以中等推理努力程度运行

基准测试

SkillsBench，80个配对任务，自动评分0-1（含部分得分）

臂A

标准Claude Code

臂B

ponytail v4.8.4：技能已安装

并注入其规则集，字节级与规则集文本完全一致。其

SessionStart

钩子生成的文本（钩子的其他首次运行输出未被复现）。这是对已发布插件完整模式的紧密模拟，仅存在三个已记录差异（无首次运行状态栏提示、无子代理重新注入、规则集在任务之后而非之前追加）

规模

3个配对阶段（10任务烟雾测试、k=3时相同10任务、完整80任务），加上自激活和连接检查——完整评估程序中共计251次计费代理试验，费用246.09美元。部分SkillsBench任务被排除：一个无法在本地沙箱中运行的任务，以及在我们的硬件上两个臂均以相同方式失败的若干任务。

有一个细节的重要性超出其表面表现。我们通过调用ponytail自身的hooks/ponytail-instructions.js生成臂B注入的文本，而非编写其摘要，因此模型看到的规则集是技能自身的文本而非我们的转述。这覆盖了钩子生成的规则集，而非钩子在真实首次运行时可能产生的所有副作用。每个带有ponytail的试验在之后都会被审计以确认规则集确实到达了模型；每个基线试验也会被审计以确认规则集未到达模型。该检查直接源自ponytail在其自身基准测试中发现的污染漏洞，结果干净无误：100%的处理试验确认规则集到达模型，0%的基线试验确认规则集未到达模型。

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

在付费运行之前，我们测试了显而易见的安装路径：将技能部署后让Claude Code自行决定何时使用。Ponytail的描述明确鼓励这种用法，指示模型在“任何编码任务：编写、添加、重构、修复、审查或设计代码”时使用该技能。

在所有十次会话中，该技能从未自动激活过。不是偶尔，而是完全从未。技能已安装且可见，但模型一次也没有调用它。

这并不是 ponytail 的缺陷，因此该工具以插件形式提供，并带有 SessionStart 钩子，无论用户是否主动请求，都会注入规则集。但这意味着安装方式决定了你是否能获得任何内容。将 SKILL.md 复制到 skills 文件夹中时，你很可能完全无法测量到任何数据。以下所有数据均来自实际注入规则集的执行环境。

发现 2 — 实际削减的代码量仅为宣传规模的三分之一

在 80 个配对任务中，每个任务平均削减了代理编写代码的 15.4%，总计 10,205 行代码减少到 8,756 行。这是一个显著的观察到的减少量。然而在 p=0.088 的统计显著性下，这却是我们所有主要数据中最为微弱的。这一数值也远未达到 54% 的宣传水平。

WIDGET:promise START

WIDGET:promise END

WIDGET:accumulate START

WIDGET:accumulate END

关于这一差距，有两点需要说明，这两点都对工具是公平的。首先，他们提到的 -54% 是基于 12 个精心挑选的功能工单的平均值；而我们的数据是基于 80 个任务的中位数，这些任务并未特意为此次研究选择。在偏态分布数据中，平均值和中位数代表的是完全不同的概念，他们自己的报告也明确指出该数值"在代理过度构建时可达 94%，而在代码已接近最小化时则接近零"。

其次，这更值得关注：我们的数据也指向了相同的方向。

发现 3 — 代码削减集中在存在过度构建空间的区域

根据基线编写代码量对任务进行分类。Ponytail 无法自主选择分类方式，因为这是普通代理决定的。需要明确指出的是：我们在看到数据后才选择这些阈值，而按基线输出进行分组本身就能拉伸这种梯度。请将图表解读为关于效果分布的强烈暗示，而非精确的测量定律。

WIDGET:doseresponse START

WIDGET:doseresponse END

在大型构建任务中，削减幅度达到 -31%。在那些普通代理几乎未编写任何代码的任务中，典型任务的代码量基本保持不变——但该组任务的总代码量实际上有所增加（从 104 行增加到 910 行），而这一差距正是本次运行中唯一真正的意外发现。

在七个任务中，我们的计数器记录到普通代理的代码量为零，而 ponytail 的代码量在 51 到 230 行之间。阅读对话记录后发现，这种差距主要体现在代码存储位置而非代码量本身。普通代理直接通过 heredoc 将解决方案输入 Python 解释器，生成交付物后未留下任何脚本。而 ponytail 则将相同逻辑写入文件。我们的计数器将保存的文件视为代码，而内联 heredoc 视为草稿，因此一个分支被计费而另一个未被计费。

明确说明这些文件的性质：所有七个文件都是普通的工作脚本——edit.py、diff.py、build_model.py——而非测试脚本。因此这并非 ponytail 的"留下一个可运行检查"规则在起作用，它只是将解决方案保存到磁盘，而普通代理则通过解释器直接处理了等效内容。我们无法断言 ponytail 在这些任务中编写了更多代码，只能确认其更多代码被持久化保存。

这是否会影响主要结论？略有影响，但方向双向都有。Ponytail 独立持久化保存代码的有 7 个任务（761 行）；普通代理独立持久化保存的有 4 个任务（567 行）。总体而言，10,205 行代码中约 190 行与 ponytail 相关——不足 2%，且规模过小不足以对结论产生实质性影响。我们并未声称 -15.4% 的数据是由于这个原因而显得保守。

发现 4 — 费用下降，且这一次信号非常明确

安装ponytail后，典型任务成本降低了10.3%：在80对任务中p=0.004，46个任务成本降低而34个任务成本增加。这是本系列迄今为止最强的正向成本结果，也是首个实现实质性节省而非实质性增加的结果——rtk的+7.6%同样显著，只是方向相反。移除单个定价层级异常值后，caveman也降低了约10%的成本，但这个结果依赖于单一排除项，存在脆弱性；这是首次在完整运行的配对测试中成本差异得以保持。

需要明确说明的一点是：我们希望供应商能认识到，虽然中位数节省为-10.3%，但置信区间已触及零值。方向性有充分支持，单任务测试结果明确。"在此工作负载下大致便宜10%"是可辩护的表述，"ponytail节省了10%"则不成立。

WIDGET:spend START

WIDGET:spend END

需要特别指出未发生显著变化的部分：输入侧。重新读取历史记录下降8.4%，新生成token下降3.9%，均不显著（p=0.138和p=0.085）。在第二部分中我们发现代理账单主要由重新读取部分构成，这也是为什么压缩命令输出的工具对账单影响甚微。ponytail则针对模型输出侧进行优化，在本基准测试中正是成本发生转移的侧边。

发现5 —— 未检测到质量差异

对于一个"写得更少"的技能，显而易见的担忧是它可能通过删除重要内容来实现。ponytail声称其从不接触验证、错误处理、安全或可访问性，并在其基准测试的独立对抗性层级中报告了100%的安全性。

我们无法验证这一安全性声明，需要明确说明原因：SkillsBench验证器仅评估任务是否完成。它们不是安全、验证或可访问性测试套件。所有测试仅检查工作是否通过，不涉及ponytail是否保留了防护机制。

WIDGET:quality START

WIDGET:quality END

9个任务得分略有下降，6个任务略有提升，65个任务完全相同——统计上无法区分。这是一个零结果，而非明确的健康证明：本次运行并未设计用于证明等效性，数据同样兼容小幅退化或小幅改进。可以确定的是，这里没有任何迹象显示出现明显故障模式，即"写得更少"悄无声息地导致测试失败。

关于遵循规则的一点小说明：ponytail的规则集要求模型通过添加"ponytail"标记来标注有意的快捷方式，包括标注上限和升级路径。在80次明确包含规则集的测试中，这种情况仅发生过1次。规则被遵循了，但文件记录却没有。

发现6 —— 小样本在两个方向都误导了我们

值得展示，因为这正是本系列旨在避免的陷阱。我们最初的10任务烟雾测试显示ponytail使代码量减少3%但成本增加9.6%，平均任务得分从0.51骤降至0.31。如果当时发布这个结果，我们将写出完全错误的文章。

WIDGET:ladder START

WIDGET:ladder END

结论

ponytail有效。在80个配对任务中，它使典型账单减少10.3%，代码量减少15%，且未检测到质量差异。这是本系列首个明确节省成本的工具。如果您安装后不再关注，应该会获得适度的收益。

不要期望在所有情况下都能达到宣传的54%。Ponytail的基准测试使用了存在明显过度构建陷阱的任务，而我们的测试没有这种情况。在我们的测试中，代码在大型构建中减少了31%，而在原本已经精简的任务中几乎没有变化。你的代理执行的过度构建越多，Ponytail能削减的空间就越大。

如果你有声称能节省token的工具，请告诉我们是哪个，我们会用相同的基准测试来验证。

方法论说明

• 永远不要相信k=1的结果。验证阶梯：先进行免费的转录审计，然后是10个任务的烟雾测试，接着在k=3时重复相同的10个任务，最后进行完整的80个任务测试。第6个发现展示了烟雾测试本应揭示的内容。

• 仅进行配对分析。对每个任务的两个分支进行比较；任一分支出现错误的任务会被两个分支同时剔除。质量比较使用符号检验，每个任务的中位数加上Wilcoxon检验用于其他所有指标，因为一个长上下文会话可能产生正常情况25倍的费用，从而破坏平均值。

• 在付费测试前已固定端点：奖励、编写代码量、输出token数、新鲜输入token数、成本、轮次、墙钟时间。总token数是在后续添加的，当我们确认ponytail自己的基准测试/agentic/run.py实际宣传的指标后。它统计的是输入、缓存和输出的总和，因此将我们的纯输出数据与它的-22%进行比较，会使我们看起来优秀三倍。

• 这里空结果的含义与非含义。质量比较是显著性检验而非等效性检验。"未检测到差异"是诚实的结论；要证明质量确实没有变化，需要非劣效性设计并预先声明边界值——对于这个基准测试约40%的基线，在80%功效下5个百分点的通过率变化，需要每个分支数百个配对任务，而不是80个。

• 采用情况已记录。每个试验都审计了规则集是否到达模型——处理组100%，对照组0%——因此"ponytail没有节省任何东西"永远不会与"ponytail从未运行"混淆。

• 在没有工作区差异的情况下测量代码。ponytail自己的基准测试统计的是git diff新增的行数。Harbor不保留代理运行后的工作区，因此我们通过代理的工具调用重建等效数据：Write、Edit和shell heredocs重定向到文件，按ponytail的benchmarks/loc.js方式精确统计非空非注释行。这是累计输出行数而非最终实现规模：一行代码被多次重写时会重复计数。管道到解释器的heredocs属于临时分析，已排除。我们审计了这些数据来源的提取器覆盖率：Write和Edit占统计行数的95.6%（15,632和2,496行，共18,961行），因此该指标不会因代码去向的缺失而产生偏差。两个分支都无法看到的两样东西：运行时脚本生成的文件和子代理内部编写的代码。

• 来源信息。ponytail固定在提交16f2980（v4.8.4，MIT）；两个分支都固定了代理版本；注入的规则集由ponytail自己的钩子代码生成，已记录sha256哈希值。SkillsBench的87个任务中排除了7个：一个完全无法在本地沙箱运行的任务，以及在我们硬件上两个分支都以相同方式失败的6个任务。排除是对称的——任务要么同时从两个分支剔除，要么都不剔除——完整列表已与评估工件一起保留。

• 本研究无法说明的问题。SkillsBench 是数据、分析和修复工作；它包含的前端过度构建陷阱远少于产生 ponytail 最大收益的那些场景。这是一项对成本、速度和质量主张的公正测试，也是对代码主张的保守测试。它不会反驳他们在自有任务集上实现的 −54% 改进。

图表风格借鉴自 dither-kit，在此处重新实现为无依赖的内联组件。

WIDGET:ENGINE START — 作用域限定的 WordPress 安全型 ES5 图表引擎

WIDGET:ENGINE END

WIDGET:AUTHOR-PONYTAIL START

WIDGET:AUTHOR-PONYTAIL END

常见问题

ponytail 技能是否支持 Claude Code？可以支持，但安装方式影响效果。如果将 SKILL.md 复制到技能文件夹并让模型自行决定使用时机，技能将完全不会激活——我们在十次会话中验证了这一现象。ponytail 设计为通过 SessionStart 钩子自动注入规则集的插件模式运行，这种配置是唯一能产生可测量效果的方式。

ponytail 技能实际能减少多少代码和 token 消耗？在 80 个配对任务中，我们测得代码量中位数减少 15%，成本降低 10.3%。宣传的 −54% 代码缩减效果在存在明显过度构建陷阱的任务中确实成立；我们的基准测试偏向数据和分析工作，这属于更保守的测试场景。在我们测试的大型项目中，代码量减少了 31%。

ponytail 技能会降低代码质量吗？在 80 个任务中，我们未发现具有统计显著性的质量差异——65 个任务得分完全相同，9 个任务略差，6 个任务略优。这是一个零结果而非完美结论：测试未达到证明等效性的统计效力。它排除的是那种"少写代码却静默导致故障"的明显失效模式。

Claude Code 的 ponytail 技能是什么？ponytail 是一个开源 AI Agent 技能，它约束模型编写最简代码。在生成任何内容前，它会依次判断：是否需要存在、是否已存在于代码库、标准库是否能处理、能否用一行代码实现？验证、错误处理、安全性和可访问性被明确排除在极简规则之外。

ponytail 技能与其他节流技能的对比如何？在我们的测试中，ponytail 是唯一产生统计显著成本节约的工具。caveman 技能实现的 −8.5% 代码缩减远低于宣传的 −65%。RTK 反而导致 7.6% 的成本增加。ponytail 实现了 −10.3% 的成本降低（p=0.004）——这是该系列首个明确的正向结果。

• 分享

• Facebook

• Twitter

• Linkedin

上一篇

介绍 JetBrains Context：为代码代理提供仓库智能