Ponytail 技巧真能减少 54% 代理代码？实测揭底

在许多 JetBrains 产品中，借助 AI 驱动的功能增强你的工具

这是本系列的第 3 部分。我们会选取面向编程智能体、公开发布的“Token 节省”扩展，并对每款扩展进行相同的配对 A/B 基准测试。第 1 部分测试的是 caveman skill（宣称减少 65%，实测减少 8.5%）。第 2 部分测试的是 rtk（宣称减少 60%–90%，实测增加 7.6%）。

我们运行了 80 组配对任务，以测试 Claude Code 的 ponytail skill。宣称效果：代码减少 54%、Token 减少 22%、成本降低 20%、耗时缩短 27%。实测效果：代码减少 15%、成本降低 10.3%、耗时缩短 11%。以下是实际发生的情况。

它确实带来了节省，尽管实际幅度大约只有宣传值的四分之一到一半，但这是本系列中第一个呈现出统计上可靠的成本节省信号的工具。我们没有发现质量差异，不过约 80 组配对数据只能排除较大的差异。需要注意的是：只有在原本存在过度构建空间的情况下，代码量才会减少。

Ponytail skill 旨在让 AI 智能体编写更少的代码。它的核心理念是：一位见多识广的高级开发者，能用一行代码替代你的五十行代码。如果你要求实现一个日期选择器，它不会安装 flatpickr 再编写一个包装组件，而是直接写下 <input type="date">，然后继续处理其他事情。

从机制上讲，它是一架模型在编写任何内容之前必须逐级攀爬的梯子：这个东西真的需要存在吗？代码库中是否已经有了？标准库能否实现？平台是否提供原生功能？已安装的依赖能否完成？能不能只用一行？只有完成这些检查后，它才会编写能够工作的最少代码。这套检查是在理解问题之后执行的，并非用于取代问题理解；验证、错误处理、安全性和无障碍性也被明确排除在精简范围之外。

下面是我们自己的测试中，它在实际场景里的表现。两个智能体都被要求将一个 three.js 场景导出为可供 Blender 使用的 OBJ 文件；两者都生成了通过验证器检查的文件。由于 three.js 的 OBJExporter 无法处理实例化网格，两者都编写了同样繁琐的循环来展开这些网格。区别在于这段循环周围的一切。为了将场景旋转到 Blender 使用的方向并写入文件，普通智能体创建了一个包装对象来承载旋转操作，并为每个中间步骤命名：

// no skill — 10 statements to rotate the scene and write the file
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 — the same job, 5 statements
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 直接旋转已有对象，而不是创建一个父对象来代替它执行旋转，同时还少使用了一个 import。十条语句变成了五条，两个文件导出的几何体完全相同，并且都获得了 1.0 分。这正是宣传中的效果——只不过它发生在一个任务中的一个文件上。

其核心宣传主张是代码减少 54%，此外 Token 减少 22%、成本降低 20%、耗时缩短 27%。这项测试之所以值得进行，是因为这些主张有着异常详尽的记录。针对一项批评——issue #126 指出原始数据来自一个过于啰嗦的基线——作者重新构建了基准测试，并公开了更诚实的版本：一个真实的无头 Claude Code 会话编辑真实的 FastAPI + React 仓库，并根据会话最终留下的 git diff 评分。他们甚至记录了在自家测试工具中发现的污染缺陷：SessionStart hook 在每个实验分支中都会触发，导致基线组也在暗中运行 ponytail。

与这一领域的大多数工具相比，这体现了更坦诚的方法论态度。因此，这里的问题是：在作者没有亲自选择的基准测试中，面对更强的模型，并使用验证器评估质量时，这种效果能否依然成立。

有一个细节比表面上更重要。我们通过调用 ponytail 自己的 hooks/ponytail-instructions.js 来生成 B 组注入的文本，而不是自行编写摘要，因此模型看到的是该 skill 自己的规则文本，而非我们的转述。这覆盖了 hook 生成的规则集，但不包括它在真实首次运行时产生的所有副作用。之后，我们会审计每一次启用 ponytail 的试验，确认规则集确实传达给了模型；同时审计每一次基线试验，确认其中没有该规则集。这项检查直接源于 ponytail 在自家基准测试中发现的污染缺陷，而检查结果完全干净：100% 的实验组试验包含规则集，0% 的基线组包含规则集。

发现 1——ponytail skill 会在 Claude Code 中自行激活吗？

在开始付费测试之前，我们先测试了最直观的安装方式：放入该 skill，然后让 Claude Code 自行决定何时使用它。Ponytail 的描述正是这样引导模型的，它要求模型在“任何编程任务：编写、添加、重构、修复、审查或设计代码”中使用它。

在全部十次会话中，它自行激活的次数为零。不是很少，而是一次都没有。该 skill 已安装且可见，但模型从未主动调用它。

这并不是 ponytail 的缺陷，也正因如此，该工具才以插件的形式发布，并通过 SessionStart hook 注入规则集，无论你是否要求使用它。但这也意味着，安装方式决定了你能否获得任何效果。如果只是将 SKILL.md 复制到 skills 文件夹中，那么你很可能什么也测不到。下文的所有数据均来自规则集实际得到注入的实验组。

发现 2——实测代码缩减幅度只有宣传值的三分之一

在 80 组配对任务中，一个典型任务里智能体编写的代码减少了 15.4%；从总量来看，10,205 行变成了 8,756 行。这是相当可观的实测降幅。不过，其 p 值为 0.088，是我们几项核心数据中统计信号最弱的一项，而且与 54% 相去甚远。

关于这一差距，有两点需要说明，而且这两点对该工具而言都是公平的。第一，他们宣称的 54% 是基于 12 个精心挑选的功能工单计算出的均值；我们的 15.4% 则是基于 80 个并非为此目的挑选的任务计算出的中位数。在偏斜数据中，均值和中位数完全是两码事，而且他们自己的文章也明确指出，该数字“在智能体过度构建时最高可达 94%，而在代码已经足够精简时则接近于零”。

第二点也更有意思：我们自己的数据呈现出了相同趋势。

发现 3——节省效果集中出现在存在过度构建空间的任务中

我们按照基线组编写的代码量对任务进行了划分。由于分组由普通智能体决定，Ponytail 无法通过这种方式自行选择所属区间。不过需要明确说明的是：这些阈值是我们在看到数据之后才选定的，而且依据基线组自身的输出进行分组，本身就可能放大这样的梯度。因此，应将图表理解为对效果集中区域的强烈提示，而不是一条经过测量得出的定律。

在大型构建任务中，代码降幅达到 31%。对于普通智能体原本就几乎没有编写任何代码的任务，典型任务的变化为零——不过，该组的代码总量实际上从 104 行上升到了 910 行，而这处差异揭示了本轮测试中唯一真正令人意外的现象。

在七个任务中，我们的计数器记录到普通智能体编写了零行代码，而 ponytail 编写了 51 到 230 行。阅读会话记录后可以发现，这种差距主要取决于代码存放在哪里，而不是实际有多少代码。普通智能体通过 heredoc 将解决方案直接传入 Python 解释器，既生成了交付成果，也没有留下脚本。Ponytail 则将同类逻辑写入了文件。我们的计数器将保存的文件视为代码，而将内联 heredoc 视为临时内容，因此一组被计入了代码量，另一组则没有。

需要明确这些文件的性质：全部七个文件都是普通的工作脚本——edit.py、diff.py、build_model.py——而不是测试。因此，这并不是 ponytail 的“留下一个可运行检查”规则产生的结果；它只是将解决方案保存到了磁盘，而普通智能体则通过解释器运行了等价内容。我们不能据此断言 ponytail 在这些任务中编写了更多代码，只能说它有更多代码被持久化保存。

这会使核心结果产生偏差吗？会有轻微影响，而且两个方向都有。只有 Ponytail 持久化代码的任务有 7 个，共 761 行；只有普通智能体持久化代码的任务有 4 个，共 567 行。净差约为 190 行，相对于 10,205 行不到 2%，幅度太小，无法为任何一方提供有力依据。我们并不会因此声称 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）。在第 2 部分中我们发现，AI 智能体的账单主要由那部分重读操作主导，这就是为什么压缩命令输出的工具几乎没有影响。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%，在已经精简的任务中几乎没有变化。你的 AI 智能体进行的过度构建越多，ponytail 能减少的就越多。

有一个声称能节省令牌的工具？告诉我们是哪个，我们将通过相同的基准测试来运行它。

方法学注记

永远不要相信 k=1。升级梯系：一次免费的记录审计，然后是 10 任务烟雾测试，然后在 k=3 时运行相同的 10 个，然后是完整的 80 个。发现 6 展示了烟雾测试会告诉我们什么。

仅进行配对分析。两个版本之间的逐任务比较；任何在任一版本中出错的任务都会从两个版本中删除。质量采用符号检验，逐任务中位数加上 Wilcoxon 检验用于其他所有指标，因为一次长上下文会话可能账单是正常的 25 倍，会破坏平均值。

在付费运行之前确定的端点：奖励、编写的代码、输出令牌、新增输入令牌、成本、轮数、实际耗时。总令牌是之后添加的，一旦我们检查了 ponytail 自己的 benchmarks/agentic/run.py 实际宣传的是哪个指标。它对输入、缓存和输出求和，所以将我们的仅输出数据与其 −22% 进行比较，会让我们看起来好三倍。

这里的零结果意味着什么和不意味着什么。质量比较是显著性检验，而不是等价性检验。"未检测到差异"是诚实的解读；证明质量确实未改变需要进行非劣性设计，带有预先声明的边界，以及——在 80% 功效下 5 个百分点的通过率转变，围绕该基准测试的约 40% 基线——每个版本需要数百个配对任务，而不是 80 个。

采用情况有仪器化监测。每次试验都被审计以检查规则集是否到达了模型——治疗组 100%，对照组 0%——所以"ponytail 没有节省任何东西"永远不会与"ponytail 从未运行"混淆。

不通过工作区差异来测量代码。Ponytail 自己的基准测试计算 git diff 添加的行数。Harbor 没有保留代理后的工作区，所以我们从代理的工具调用重建等效的：Write、Edit 和重定向到文件的 shell heredoc，计算为非空非注释行，完全如同 ponytail 的 benchmarks/loc.js 所做的那样。这是发出的累积行数，而不是最终的实现大小：一行写入然后后来重写的行每次都计算。重定向到解释器的 heredoc 是一次性分析，被排除在外。我们审计了这些数据来源运行中提取器的覆盖范围：Write 和 Edit 占计数行的 95.6%（15,632 和 2,496，共 18,961），所以该指标不是缺少代码去向的工件。在两个版本中都有两件事它无法看到：脚本在运行时写入的文件，以及在子代理中写入的代码。

来源。ponytail 固定在提交 16f2980（v4.8.4，MIT）；代理版本在两个版本中都被固定；注入的规则集由 ponytail 自己的钩子代码生成，记录了 sha256。SkillsBench 的 87 个任务中有 7 个被排除：一个根本无法在本地沙箱中运行，六个在我们的硬件上在两个版本中都同样失败。排除是对称的——一个任务从两个版本中都被删除或都被保留——完整列表与评估工件一起保留。

这无法告诉你什么。SkillsBench 是数据、分析和修复工作；它包含的前端过度构建陷阱很少，而这正是产生 ponytail 最大胜利的地方。这是对成本、速度和质量声称的公平测试，也是对代码声称的保守测试。它并不否认他们在自己的任务集上的 −54%。

图表风格借用自 dither-kit，在这里重新实现为无依赖的内联小部件。

常见问题

Ponytail 技能是否适用于 Claude Code？ 是的，但安装方法很重要。如果你将 SKILL.md 复制到技能文件夹并让模型决定何时使用它，它将零次自动激活——我们在十次会话中都证实了这一点。Ponytail 被设计为作为带有 SessionStart 钩子的插件运行，自动注入其规则集。这是唯一产生可衡量结果的配置。

Ponytail 技能实际上减少了多少代码和令牌使用？ 在 80 个配对任务中，我们测量了 −15% 中位数代码减少和 −10.3% 成本减少。广告宣传的 −54% 代码减少在具有明显过度构建陷阱的任务上是真实的；我们的基准测试倾向于数据和分析工作，这是更保守的测试。在我们运行的较大构建中，代码下降了 31%。

Ponytail 技能是否降低代码质量？ 我们在 80 个任务中发现了没有统计上显著的质量差异——65 个得分相同，9 个略差，6 个略好。这是一个零结果，而不是一份良好的健康证明：该运行没有能力证明等价性。它排除的是明显的故障模式，即写得少会悄然破坏事物。

Claude Code 的 ponytail 技能是什么？ Ponytail 是一个开源 AI 智能体技能，它限制模型编写最少的代码。在生成任何东西之前，它会经过一系列问题的升级梯系：这需要存在吗，它已经在代码库中吗，标准库能处理它吗，它能是一行吗？验证、错误处理、安全性和无障碍性明确被排除在其最小化规则之外。

Ponytail 技能与其他令牌节省技能相比如何？ 在我们的系列中，ponytail 是唯一产生统计上显著成本节省的工具。caveman 技能测量了 −8.5% 的代码，而广告宣传的是 −65%。RTK 产生了 +7.6% 的成本增加。Ponytail 提供了 −10.3% 的成本削减，p=0.004——系列中第一个稳固的正结果。

关于在Claude Code上针对token压缩技能Caveman进行的配对A/B基准测试，在SkillsBench上运行的研究：它是否真的能节省token，以及是否会降低AI智能体输出的质量？宣传的节省率：65%。实际测量的节省率：8.5%。在真实智能体任务上的输出token节省，该技能被强制激活…

这个整合源自JetBrains与GitHub的深度合作，它让Copilot在agent选择器中成为原生集成，在你每天使用的IDE中直接提供更稳定的agent体验。从ACP Registry到原生体验 Copilot之前可以通过…