Ponytail 真实测评整理：官方称代码减少 54%，JetBrains 实测 15%，480 次独立复现给出另一组结果
Ponytail 是一个用于 AI 编程代理的开源插件。它不直接压缩命令输出，而是在模型写代码前加入一套约束：先判断功能是否需要实现、项目中是否已有实现、标准库或平台原生能力是否可以完成，再决定是否新增代码。
项目目前公开宣传的数据是：代码量减少约 54%、Token减少约 22%、成本降低约 20%、耗时减少约 27%。这些数字来自 Ponytail 自己修正后的 Claude Code 基准测试。
围绕这些数字，目前已经出现 JetBrains 独立测试、GitHub 用户复核、480 次独立构建测试、Cursor SDK 测试和社区实际使用反馈。
下面只整理这些公开数据。
JetBrains：80 对真实任务独立 A/B 测试
网页地址：blog.jetbrains.com/ai/2026/07/…
JetBrains 在 2026 年 7 月对 Ponytail 做了独立 A/B 测试。
测试使用 Claude Code 2.1.201 和 Claude Sonnet 5，在 SkillsBench 上运行 80 对任务。任务通过自动验证器评分，完整测试计划共执行 251 次付费代理任务，总支出 246.09 美元。Ponytail 组和普通 Claude Code 组使用相同任务。
JetBrains 在文章开头直接对比了宣传数据和实测数据：
| 指标 | Ponytail 宣传 | JetBrains 实测 |
|---|---|---|
| 代码量 | -54% | 约 -15% |
| 成本 | -20% | -10.3% |
| 耗时 | -27% | 约 -11% |
80 对任务中，典型任务的代码量减少 15.4% 。统计到的代码总量从基准组的 10,205 行下降到 8,756 行。
代码量差异的统计显著性为 p=0.088，没有达到常见的 0.05 显著性标准。
成本方面，典型任务下降 10.3% ，80 个任务中有：
- 46 个任务成本下降
- 34 个任务成本上升
- 统计显著性 p=0.004
JetBrains 将它称为这个系列测试中首次得到明确统计信号的成本下降结果。文章同时强调，更准确的表述是“在这组工作负载上成本降低约 10%”，而不是认为所有任务都会固定节省 10%。
Token方面需要单独区分。
| 指标 | 变化 | 显著性 |
|---|---|---|
| 重新读取历史内容 | -8.4% | p=0.138 |
| 新输入Token | -3.9% | p=0.085 |
这两项都没有达到统计显著。
JetBrains 特别说明，Ponytail 官方的“-22% Token”与这里的部分Token指标不能直接横向比较，因为双方统计口径不同。
代码质量方面，80 个成对任务中：
| 结果 | 任务数 |
|---|---|
| 两组得分相同 | 65 |
| Ponytail 较差 | 9 |
| Ponytail 较好 | 6 |
整体没有检测到统计显著的质量差异。
JetBrains 同时说明，这并不能证明两种方案质量完全等价。SkillsBench 主要验证任务是否完成，并不是专门的安全、输入验证或可访问性测试。
Ponytail 的效果还与任务规模有关。在基准组本来会生成较多代码的任务中，代码减少幅度最高达到约 31% ；如果基准组原本就已经写得很少，典型任务的代码减少接近 0% 。
JetBrains 还测试了安装方式。
如果只是把 Ponytail 的 SKILL.md 放进 Claude Code 的技能目录，由 Claude 自己判断什么时候调用，那么 10 次测试中自激活次数为 0。
JetBrains 后面的正式测试因此使用了 Ponytail 插件自动注入规则的方式，并验证所有 Ponytail 测试任务都实际收到了规则，而基准组没有收到。
JetBrains 最终给出的结论是：在这 80 对任务中，Ponytail 将典型任务成本降低约 10.3%，代码量降低约 15%，没有检测到质量差异；但官方宣传的 54% 代码减少不能视为所有任务的普遍结果。
独立开发者 v3：480 次构建测试
独立开发者 Deepusleepy 后来重新构建了一套 Ponytail 测试。
这套测试使用 Claude Opus 4.8，共有 24 个编程任务，分别测试：
- 不安装 Ponytail
- Lite
- Full
- Ultra
每种配置执行 5 次，总计：
24 × 4 × 5 = 480 次构建。
与早期版本不同，v3 使用真实安装的 Ponytail 插件，通过实际运行代码检查正确性，通过真实攻击检查安全性，并使用解析器统计代码结构。
代码量结果如下：
| 配置 | 相比不安装 Ponytail |
|---|---|
| Lite | 约 -40% |
| Full | 约 -44% |
| Ultra | 约 -46% |
默认的 Full 模式代码量减少约 44% ，逻辑语句数量减少约 53% 。
正确性方面，Ponytail 与不安装插件的对照组通过率都约为：
99%
测试作者没有测到总体正确性下降。
安全测试会实际执行目录穿越、SQL 注入、伪造签名Token等攻击。
测试报告称，能够正常工作的构建都阻止了相同的攻击，没有发现 Ponytail 导致攻击成功的情况。
但测试发现了另一项差异：鲁棒性。
24 个任务中，有 5 个任务包含提示词没有明确写出的边界情况。
在这些任务上，Ponytail 更容易删除防御性处理。测试作者称，一些任务针对错误输入的处理能力会从接近完整下降到接近零，而且 Ponytail 设置从 Lite 提升到 Full、Ultra 后，这种情况会加重。
其余 19 个任务没有观察到这种损失。
该测试作者最后给出的结论是：Ponytail 可以减少大量代码，在这套测试中没有测到正确性和安全性整体下降，但对于需求中没有明确写出的边界情况，更精简的实现可能变得更脆弱，而且强度越高，这个问题越突出。
Cursor SDK 独立测试：代码更短，但部分模型成本增加
GitHub 用户 RicardoCostaGit 使用 Cursor SDK 做了另一组 A/B 测试。
测试覆盖 Composer 2.5 Fast、Gemini 3.5 Flash、Claude Opus 4.8、Claude Sonnet 4.6 和 GPT-5.5 High，共完成 10 次运行。
成本根据 Cursor SDK 返回的Token使用量和公开价格估算，不是后台实际账单。
代表性结果如下：
| 模型 | Ponytail 开启 | Ponytail 关闭 | 成本变化 |
|---|---|---|---|
| Composer 2.5 Fast | 约 $1.07 | 约 $0.69 | +55% |
| Gemini 3.5 Flash | 约 $1.32 | 约 $1.25 | +6% |
| Claude Sonnet 4.6 | 约 $1.55 | 约 $1.48 | +5% |
| Claude Opus 4.8 | 约 $2.35 | 约 $2.39 | -2% |
| GPT-5.5 High | 约 $1.80 | 约 $2.06 | -13% |
其中 Composer 2.5 Fast 的总Token量大约从 18.7 万增加到 30.8 万，估算成本从约 0.69 美元增加到 1.07 美元。
测试作者观察到，多个模型开启 Ponytail 后会执行更多代码读取、技能读取和上下文探索，因此工具调用和Token消耗增加；与此同时，最终写出的内容通常更短。
Claude Opus 4.8 和 GPT-5.5 High 在这组测试中是例外，没有出现相同的成本增长模式。
测试作者将结果限定在“大型、必须完成的任务”上。他指出，在这类任务中，Ponytail 可能增加前期探索成本；对于本来会因为阻塞、反复尝试而不断扩张的任务，它仍可能减少总成本。
GitHub Issue #126：开发者复核早期官方基准
Ponytail 最早的基准测试曾报告代码量减少 80%～94% 。
2026 年 6 月，Colin Eberhardt 在 GitHub Issue #126 中复核了这套测试，指出基准组没有类似真实编程代理的系统提示，因此模型经常同时输出解释、多个方案和使用示例。
这些内容也被计入代码行统计，导致基准组体积变大。
他给基准组增加了一条简单约束，只要求返回一个实现、不提供解释和使用示例，然后重新测试 Haiku，并排除存在歧义的 debounce 任务。
平均代码行数变为：
| 测试组 | 平均代码行数 |
|---|---|
| 原始基准组 | 108 |
| 限制只输出一个方案的基准组 | 16 |
| Ponytail | 8.25 |
原始基准组从 108 行下降到 16 行。
Ponytail 仍然更短，为 8.25 行，但与对照组之间的差距已经远低于最初使用 108 行基准时得到的结果。
Colin Eberhardt 因此建议项目降低核心宣传数字。
Ponytail 作者随后接受了这项批评，并重新制作了后面的真实代理基准。
Ponytail 早期官方单轮基准测试
Ponytail 最初使用 5 个日常编程任务测试 Haiku、Sonnet 和 Opus。
每个测试单元运行 10 次，报告中位数。代码行数从回答中的代码块统计，成本和延迟直接来自 API。
代码行数如下：
| 模型 | 无技能 | Caveman | Ponytail |
|---|---|---|---|
| Haiku | 518 | 116 | 39 |
| Sonnet | 693 | 120 | 44 |
| Opus | 256 | 67 | 51 |
对应的 Ponytail 结果被概括为：
代码量减少 80%～94%。
5 个任务的成本数据为：
| 模型 | 无技能 | Ponytail |
|---|---|---|
| Haiku | $0.030 | $0.011 |
| Sonnet | $0.137 | $0.035 |
| Opus | $0.137 | $0.079 |
官方当时报告成本降低 42%～75% 。
耗时数据为：
| 模型 | 无技能 | Ponytail |
|---|---|---|
| Haiku | 37.7 秒 | 9.9 秒 |
| Sonnet | 124.1 秒 | 20.1 秒 |
| Opus | 58.7 秒 | 18.0 秒 |
官方将结果概括为快约 3～6 倍。
不过这份基准后来被项目自己降级为“早期单轮数据”。
官方现在明确注明：无技能基准模型会返回多个方案和大量解释，而这些文字也进入了统计，所以 80%～94% 会高估实际代码减少幅度。
官方后续修正：真实 Claude Code 会话基准
收到 Issue #126 的质疑后，Ponytail 作者重新制作了基准。
官方文档直接承认，原来的单轮测试存在两个主要问题：真实开发不是“一条提示词对应一次回答”，同时原始基准模型会输出解释和多个方案，使此前的 80%～94% 降幅被放大。
新测试改用真实 Claude Code 2.1.177，模型为 Haiku 4.5，在真实的 FastAPI + React 开源项目上修改代码。
功能测试包含 12 个任务，每个任务、每种配置运行 4 次。
代码量按照最终 git diff 中增加的代码统计。
12 个功能任务的平均结果为：
| 方案 | 代码量 | Token | 成本 | 时间 |
|---|---|---|---|---|
| Caveman | -20% | +7% | +3% | +2% |
| Ponytail | -54% | -22% | -20% | -27% |
| 简单 YAGNI + 单行提示词 | -33% | -14% | -21% | -30% |
这组数据成为 Ponytail 后续 README 中“代码减少约 54%、Token减少约 22%、成本降低约 20%、速度提高约 27%”的主要来源。
不同任务之间的差距很大。
| 任务 | 无 Ponytail | Ponytail |
|---|---|---|
| 日期选择器 | 404 行 | 23 行 |
| 颜色选择器 | 287 行 | 23 行 |
| 文件拖放 | 251 行 | 95 行 |
| 多步骤向导 | 571 行 | 312 行 |
| 搜索项目标题 | 44 行 | 44 行 |
| 导出 CSV | 36 行 | 33 行 |
日期选择器减少约 94% ，颜色选择器减少约 92% ，文件拖放减少约 62% 。
已经较难进一步压缩的后端任务，两组结果则接近。
官方还增加了 6 个安全任务，其中 5 项会针对生成代码运行攻击测试，总计每组 20 次安全测试。
| 方案 | 安全通过率 |
|---|---|
| 无技能 | 100%，20/20 |
| Caveman | 100%，20/20 |
| Ponytail | 100%，20/20 |
| YAGNI + 单行提示词 | 95%，19/20 |
官方因此将 Ponytail 在这套测试中的安全率报告为 100%。文档同时注明，这是有限任务上的确定性检查，并不能构成完整的安全证明。
官方还披露了一次测试污染问题。早期真实代理测试一度只得到约 4% 的差异，后来发现 Ponytail 的 SessionStart 钩子同时进入了对照组，导致基准组实际上也运行了 Ponytail。修复隔离方式后才重新生成数据。
官方跨模型成本验证：Claude 省钱，部分 OpenAI 模型反而更贵
Ponytail 还专门对早期“成本降低 47%～77%”的宣传进行了重新验证。
Claude 每个测试单元合并 30 次运行。
结果为：
| Claude 模型 | 无技能 | Ponytail | 成本变化 |
|---|---|---|---|
| Haiku | $0.0299 | $0.0110 | -63.1% |
| Sonnet | $0.1367 | $0.0348 | -74.5% |
| Opus | $0.1368 | $0.0789 | -42.3% |
官方重新得到的范围是：
成本降低 42%～75%
而不是此前宣传的 47%～77%。官方称原宣传数字在上下限上都偏乐观几个百分点。
同一套测试换到 OpenAI 模型后，结果发生变化：
| 模型 | 无技能 | Ponytail | 成本变化 | 延迟 |
|---|---|---|---|---|
| GPT-4.1 mini | $0.0026 | $0.0015 | -39.6% | 快 2.5 倍 |
| GPT-5.4 mini | $0.0060 | $0.0075 | +26.2% | 快 1.5 倍 |
| GPT-5.5 | $0.0714 | $0.0990 | +38.7% | 约慢 10% |
这些模型上的 Ponytail 正确率均为 100%。
官方给出的解释是，GPT-5.4 mini 和 GPT-5.5 等推理模型本身输出已经较精简，而 Ponytail 的规则需要作为额外输入发送，还可能产生更多推理Token。额外输入和推理成本超过了减少代码带来的收益。
这份官方文档最终把结论限定为：成本下降数字主要适用于 Claude 的代码生成测试，不能作为跨模型、跨供应商的统一承诺。
Reddit 用户实际使用反馈
网页地址：www.reddit.com/r/ClaudeCod…
2026 年 6 月的一条 ClaudeCode 社区讨论中，用户反馈并不一致。
发帖用户表示自己使用 Ponytail 后没有发现较大的改善。
一名用户直接回答“作用不大”；另一名用户则表示 Ponytail 帮助自己减少了过量代码和违反 YAGNI 原则的实现。
还有用户在一个小型、完全由 AI 生成的 Python 项目中使用 Ponytail，称它发现了大约十多个可以简化的问题，并认为它在避免重复代码和不必要依赖方面有帮助。
另一名用户的反馈是，Ponytail 在一次性能优化重构中很有用，但在其他工作中效果不大。
这组讨论没有提供统一的Token、成本或代码行统计，因此只能作为实际使用反馈，不能与前面的定量基准直接比较。
总结
目前的公开数据支持 Ponytail 能减少 AI 编程代理的过度实现，但“代码减少 54%”不是所有开发任务都能得到的固定结果。
官方修正后的 12 个功能任务得到 代码 -54%、Token -22%、成本 -20%、耗时 -27% 。这些任务中包含日期选择器、颜色选择器等容易让代理过度实现的功能，其中单个任务的代码量可以减少 90% 以上；已经足够精简的后端任务，收益接近零。
JetBrains 换成 80 对并非专门为 Ponytail 选择的 SkillsBench 任务后，代码减少幅度降到 15.4% ，成本下降 10.3% ，耗时下降约 11% 。成本差异达到统计显著，代码量差异没有达到常见的统计显著标准。80 个任务中也没有检测到整体质量差异。
另一套 480 次独立构建测试得到更高的代码减少幅度：默认 Full 模式约 44% ，逻辑语句减少约 53% ，正确率维持约 99% 。但它同时发现 24 个任务中有 5 个在没有明确写出边界条件时出现鲁棒性下降。
成本也不是固定下降。Cursor SDK 的独立测试中，部分大型任务开启 Ponytail 后工具调用和Token增加；Ponytail 官方自己的跨模型测试也发现 GPT-5.4 mini 成本增加 26.2% ，GPT-5.5 增加 38.7% 。
因此，现有公开数据更适合把 Ponytail 看成一种限制 AI 过度实现的编程约束，而不是一个稳定比例的Token压缩工具。任务越容易产生额外组件、封装、依赖和重复实现，公开测试中的收益越大；任务本身已经精简时，收益可能接近零。在推理成本较高的模型和需要大量上下文探索的任务中，额外规则还可能增加成本。
同时，独立测试已经给出一个需要关注的代价：如果边界条件没有写进需求，减少“模型自行补充的实现”也可能同时减少模型自行加入的防御性处理。Ponytail 对明确需求下的代码精简已有多组公开数据支持，但它并不能替代对错误处理、安全性和边界条件的明确约束。
