Ponytail 这个 AI 编码技能这两个月在 JetBrains 用户圈子里讨论度一直没降下来。官方演示视频里它对一个老 Java 类做重构代码行数净减少 54%JetBrains 官方实测之后给的结果是 15%我又陆续收集了 480 次社区里公开的独立复现数据算下来中位数是 23%但分布极其离散——有人拿到 61%也有人不仅没减少反而多写了 8% 的代码。三个数字放在一起大部分人的第一反应都是官方又在吹牛。我一开始也这么想可等我把每一轮测评的统计口径、任务类型和基座模型逐个拆开之后发现真正有意思的不是谁对谁错而是代码量减少这个指标在不同条件下本来就会剧烈波动。这篇文章不想证明哪个数字更真而是想把这几轮测评的底裤翻出来给你看包括我自己复现时踩过的坑以及一套可以拿去直接用的公平测评模板。1. Ponytail 到底是什么一套加载进编码代理的少写代码行为约束1.1 安装命令与工作机制Ponytail 是开发者 Dietrich Gebert 发布的一个 Claude Code Skill安装命令是npx skill add dietrichgebert/ponytail。这里得先解释一下Skill是什么因为它和传统意义上的 IDE 插件完全不同。Skill 的本质是一组 Markdown 指令里面不包含可执行代码也没有编译产物。它做的事情是给 AI 编码代理coding agent定义一套行为规范。你可以把它理解成给刚入职的程序员发的一份《团队编码守则》守则本身不能帮你写代码但它规定了你在动手之前必须看哪些资料、在什么情况下不许 new 一个方法、提交前要检查什么。Ponytail 就是这样一份给 AI 用的守则。它的触发流程我拆开看其实很朴素当 AI 被要求修改或新增代码时Ponytail 会强制它先执行三个动作。第一查看目标文件的尾部理解这个文件最近在写什么、代码风格是什么样。很多模型习惯从头读文件读到一半就开始生成根本不知道文件后面已经写了什么逻辑。第二在项目里搜索相同或相似的逻辑看是否已有现成的工具方法、公共函数可以直接调。第三结合git diff确认当前改动的影响边界避免改一个地方连带重写半个模块。完成这三步之后AI 才被允许生成代码而且在生成前必须回答一个问题这段逻辑项目里是否已经存在如果存在能不能直接复用如果不存在新增的最小 diff 应该是什么这一套流程下来AI 重复造轮子的概率确实会低很多。从尾巴读文件这个设计本质上是治一个特别常见的病AI 在超大文件或大型项目里上下文窗口有限往往只读了个开头就开始发挥结果文件后面早就写好的逻辑它没看见于是又生成了一份功能重叠的代码。Ponytail 逼着模型把视线挪到文件末尾和全局符号上才避免了这种睁眼瞎式的重复劳动。1.2 官方 54% 这个数字测量口径其实很窄作者在仓库 README 和演示视频里展示了一个案例对一个大约 3000 行的老 Java 类做重构把这个类里大量重复的空值判断、日志调用、错误处理样板代码抽成公共方法然后让原位置替换成一行方法调用。用 diff 工具统计重构前后的净行数变化结果是净减少约 54%。这个 54% 我没有质疑过它有水分但它的测量范围非常窄它统计的是一个单文件、单次重构任务的 diff 行数变化不包含新增功能不包含测试代码也没有统计整个代码库的规模变化。换句话说这是个单个重构任务里新旧代码行数的比率不是整个项目代码量减少 54%。理解了这个口径再回头看社区里的争论你就会发现很多吵架都没吵到点子上。有人说我用了根本没减少 54%有人反驳你不会用。其实两边可能都对因为大家手里的任务、统计方式、基座模型都不一样。官方那个 54% 是一个极端优秀的样本而不是一个平均值。2. 官方54%和JetBrains 15%的差距任务画像、统计口径、模型遵循度三处不同2.1 JetBrains 内部验证的场景与口径JetBrains 为什么会测这个东西原因很实际Ponytail 在他们用户社区里的讨论量实在太高加上 opencode 的 JetBrains IDEA 插件开始支持这类技能文件官方 AI Assistant 团队就想做个内部验证看看这玩意儿在真实项目里到底有没有用。我当时通过公开渠道看到的信息是他们选取的是 JetBrains 内部项目里一些非常常见的开发任务包括新接口实现、DTO 转换类编写、Spring Data Repository 创建、Service 层逻辑补充、单元测试补齐等。对照组不加载任何 Skill实验组加载 Ponytail每个任务跑多次取平均。统计口径是看整个项目的净变化行数而不是只看目标文件并且会把新增测试代码和配置文件的改动也计入。结果就是大家知道的那个数字平均大约 15%。但如果把任务拆开看差异其实比平均值大得多。我根据公开信息整理了一下任务类型对照组平均新增行Ponytail 组平均新增行净减少新写 Repository Entity约 320 行约 250 行22%新写 Service 方法约 180 行约 165 行8%补全单元测试 setup/teardown约 140 行约 105 行25%修改既有缓存逻辑约 95 行约 97 行-2%注意表格里的数字是多个任务的平均值不是某一个任务的精确结果。但趋势很明显在样板代码多的任务里Ponytail 的减少效果确实存在且有价值到了业务逻辑复杂、需要人来判断的算法类修改上它几乎没有任何增益甚至因为多了一步检查上下文而显得更慢。2.2 15% 不是缩水而是官方演示之外的常态JetBrains 这个 15% 被很多人解读成官方数据打三折但我更愿意把它理解为官方演示之外的真实常态。原因有三点。任务画像变了。官方演示做的是旧代码重构旧代码里到处都是重复样板Ponytail 的先读上下文、再检查复用正好打在痛点上。而 JetBrains 测的主要是新增功能新功能没有太多旧代码尾部可以读它的找重复逻辑能力几乎没有用武之地。统计范围变了。官方只统计单个文件的净行数变化JetBrains 看的是全项目变化新增的测试代码、配置文件改动都算进去。这两者天然有差距。模型遵循度不同。Ponytail 是给 Claude Code 量身定做的指令官方演示用的也是 Claude 系列模型指令遵循度很高。而 JetBrains AI Assistant 底层的模型对 Skill 格式的遵循度可能没那么高很多时候模型并没有真的去读文件尾巴只是走了个过场就开始写代码。这三个变量叠加下来54% 变成 15% 一点都不奇怪。真正让我觉得有意思的是如果把条件换成高质量旧代码 Claude 单文件统计社区里其实很多人也能复现出 40% 以上的减少。所以问题从来不是哪个数字是假的而是你在什么条件下测的。3. 480次独立复现翻出的底牌中位数23%重构类任务能到31%3.1 480 个样本怎么筛选出来的光看两家官方数据还是不够我在过去两个多月里做了一件比较笨的事把 GitHub issue、Reddit 的 r/ClaudeAI 和 r/JetBrains、V2EX、一些个人技术博客里的公开复现帖尽量收集起来筛掉那些我试了一下感觉不错或者完全没用但没有任何 diff 数据支撑的帖子最后留下有效样本 480 个。我要求每个样本必须包含任务类型、编程语言、使用的基座模型、以及可核对的行数变化统计否则不纳入。必须说明这不是严格意义上的随机抽样它存在两个天然偏差第一愿意发帖的人往往是效果特别好或者特别差的两端中间状态的人很少出来说话第二不同人统计行数变化的方式不完全一致。所以我把这 480 个样本当成了一个社区真实体验分布来看而不是精确的科学实验数据。即便如此这个样本量比大多数单个测评要可靠得多。3.2 按任务类型、语言、模型拆开后的真实分布整体数据是这样的480 个样本的中位数净减少是 23%平均值大约 22.8%但标准差非常大最小是 -8%最大是 61%。如果只看平均值你会得到一个还算不错的结论但一旦拆开看会发现这个 23% 其实是很多完全不同的体验拼出来的。按任务类型分差别非常明显任务类型样本量中位数净减少平均值最小值最大值旧代码重构19731%29.4%-3%61%新功能开发1689%10.7%-8%28%测试/样板代码生成11528%27.1%5%54%按语言分也有明显梯度。Java/Kotlin 项目的复现中位数大约是 26%因为这些项目里样板代码多压缩空间大TypeScript 项目大约 21%Python 项目大约 18%动态语言本身简洁能挤的水分本来就少Go 项目大约 16%Go 的强约定和 gomft 把很多代码风格问题已经在编译期解决了。按基座模型分趋势一样清晰Claude 3.5/3.7 Sonnet 及更新系列的中位数约 27%GPT-4o / 4.1 系列约 17%其他一些小众模型或本地模型约 12%部分样本直接是负收益。3.3 那 26 个负收益样本问题出在哪480 个样本里有 26 个净变化是负数也就是代码量不降反增。我逐个看过这些样本的场景描述之后发现它们高度集中在同一个组合上新功能开发 Python/TypeScript 已有代码质量比较差。这个结果很反直觉。按理说已有代码质量差不是正好应该用 Ponytail 来纠偏吗实际恰恰相反。Ponytail 的工作机制是让 AI 先去读现有代码、理解现有风格然后再动手。但如果现有代码本身就是一堆长函数和重复逻辑AI 读完之后不仅不会变简洁反而会被这种坏味道带偏生成的新代码延续同样的臃肿风格。还有一个高频现象模型为了复用而强行复用。有些发帖者贴出来的 diff 里模型把一个只有两行的简单逻辑硬是抽成一个带 6 个参数的工具方法然后调用方变得更难读。这种为了抽象而抽象的行为在 Ponytail 的优先复用指令下很容易出现尤其是在需求边界模糊、模型理解不到位的时候。这也解释了为什么负收益样本在动态语言里更多——动态语言里没有编译器的强约束模型自由度更高发挥空间和跑偏空间都更大。4. 决定你用Ponytail是54%、15%还是负数的三个关键变量4.1 基线代码质量Ponytail 不是清理器而是放大器我在整理那 480 个样本的时候发现一个规律所有效果好到 40% 以上的案例对应的项目基础都不算差至少是有命名规范、有工具类目录、有清晰分层的老项目。Ponytail 教会 AI 去找已有的东西复用前提是项目里真的存在值得复用的好东西。如果项目本身是一团缠绕的线球AI 按 Ponytail 的方法找到的现有逻辑往往本身就该被重写复用它只是把坏代码复制了一份。所以我会把 Ponytail 定义成放大器而不是清理器它能把好代码库里的重复删掉也能把坏代码库里的混乱风格放大。如果你的项目连基础的格式化都没统一我建议先做一次基础整理再上这类 Skill否则很容易得出这工具没用的结论。4.2 基座模型对 Skill 指令的遵循度Skill 本质上是一段提示词不是一段程序模型完全可以不按它执行。官方演示用的是 Claude CodePonytail 本身就是为 Claude 定制的指令遵循度自然最高。而其他基座模型对 Skill 指令的遵循程度差异巨大有些模型只是象征性地执行了读取文件的步骤实际生成的代码和没加载 Skill 时一模一样。怎么判断模型有没有真读而不是假读有个很简单的检验方法看生成的代码里是否出现了项目里已有某个方法、所以我复用了它这类表述。如果代码里通篇都是自己从零写的新逻辑大概率是模型没有认真执行前两个步骤。我自己的经验是在 JetBrains 环境里如果用的是第三方模型最好把 Ponytail 的指令直接贴进 system prompt 里并且明确要求模型在回答开头先列出已存在的相关代码这一步能显著提高遵循度。4.3 任务边界只有有旧代码可读的场景才占便宜Ponytail 的核心优势来自先读旧代码再动手这也就意味着它只在已经存在一堆相关旧代码的场景里才有溢价空间。反过来如果是全新项目从零搭架构项目里根本没有已有逻辑可复用Ponytail 给出的约束就变成了纯消耗——它让模型多读了很多文件但读完之后能复用的东西非常有限token 花了不少代码量也没减多少。同样的道理也适用于一次性脚本和算法题。脚本本身就是临时的追求的是快速产出不需要长期维护的复用体系算法题的性能敏感代码更是如此强行套用最小 diff有时候反而让解法变复杂。所以我自己现在用 Ponytail 有一个非常明确的边界重构旧代码、补样板代码、为已有类扩展方法这些场景主动加载绿场项目和一次性脚本直接不加载。这里还牵扯到一个延展问题有人担心加载 Skill 会增加 token 成本。这是真实存在的Ponytail 的先读文件、再搜索、再写 diff流程比无脑生成要多花不少输入 token。在代码量减少和token 支出增加同时发生的时候到底值不值取决于你的项目体量和重构频次。我见过一个样本代码减少了 30%但 token 消耗翻了快一倍算下来如果只是为了一次性任务确实不划算。5. 我自己的接入配置和一套公平可比的对测方法5.1 在 JetBrains 环境中启用 Skill 的操作记录我在自己的 IntelliJ IDEA 里跑通了完整流程这里记录一下实际操作尽量去掉环境差异给后面折腾的人一个参考。第一步确认机器上有 Node.jsnpx 命令可用。Ponytail 的安装命令是npx skill add dietrichgebert/ponytail它会自动把技能文件下载到本机的 skill 目录里。注意这个命令非常适合在终端里跑用 IDE 自带的终端或系统终端都行。装完可以看到目录下多出一份 Markdown 格式的技能定义文件。第二步看你的编码代理接的是哪种后端。如果直接用 Claude Code那么装完之后在对话里触发相关任务Ponytail 会自动生效。如果要在 JetBrains AI Assistant 或 opencode 插件的环境里用情况会不同。我在 opencode JetBrains IDEA 插件里转了一圈它支持读取 skill 目录但不同版本的插件对 skill 的加载方式略有差异稳妥的做法是让对话以使用 Ponytail 方法处理开头或者手动把技能文件里的指令复制到当前对话的上下文中。第三步我强烈建议配一个自定义 prompt 模板不要只依赖 Skill 自动加载。我的模板是每次修改代码之前先回答三个问题——项目里是否已存在实现相同功能的代码如果存在为什么不能复用如果不存在这次改动的最小 diff 是什么我在实测中发现这个模板对模型行为的约束力有时候比 Skill 本身还大。还有个容易被忽略的细节如果你用的是 IDE 自带的 AI Assistant记得把它和你日常编码的 JDK 版本、项目 SDK 配好。我一开始没注意模型生成的代码在编译时才报错白白浪费了好几轮对话。关于 JetBrains 授权我还是要多提一嘴用正版或者走 JetBrains 官方的学生认证就行学生认证之后专业版功能都能正常用千万别去碰网上那些乱七八糟的激活工具安全和合规上的问题远比省那点钱严重。5.2 一套不会打口水仗的对测统计方法整理 480 个样本的时候最让我头疼的问题就是每个人统计代码量减少的方式都不一样。有的人只看新增行有的人看净变化有的人把空行和注释全算进去最后得出来的数字完全不可比。这里分享一套我做对测时用的统计规则尽量保证公平。统计净变化行数 新增行数 - 删除行数而不是只看新增。不计入空行、纯注释、import 调整、格式化改动。每个任务至少跑 3 次取中间值因为 LLM 生成有随机性。对照组和实验组必须在同一模型、同一温度、同一上下文长度的条件下运行。必须把任务类型和统计范围写进记录。比如对 UserController 这个文件做重构统计该文件净变化和完成一个新登录功能统计整个项目净变化这是两个完全不同的测评。我用这套规则复现了一次社区里很热门的案例在一个约 5000 行的 Spring Boot 老项目里做重复代码清理目标是消除 Service 层里反复出现的空值判断和参数校验。实验组加载 Ponytail对照组不加载各跑 5 次取中位数。最终结果实验组净减少约 33%对照组约 12%。官方 54% 我始终没跑出来但 33% 这个数已经足够说明在老项目重构这个标准场景下Ponytail 的效果是实打实的。5.3 我的使用清单与预期管理把自己当成一个普通使用者而不是测评博主我现在对 Ponytail 的预期管理是这样的适合用的场景大概三类。一是老项目重构和重复代码清理这是它的主场中位数能到三成以上二是为已有类补方法、补逻辑新代码天然可以复用周边的工具方法三是样板代码比较多的模块像 Repository、DTO、单元测试的 setup/teardown这些场景减少效果稳定在 25% 上下。不适合的场景也明确全新项目从零搭建没有可复用的旧代码效果基本可以忽略性能敏感的算法模块强行压缩代码量可能演变成一行超长表达式的可读性灾难一次性脚本更别用它需要的是速度不是长期可维护的抽象。几点个人经验第一不要对任何单一数字抱有执念官方 54% 是极端样本JetBrains 的 15% 是全项目常态你的实际体验大概率落在 9% 到 31% 之间具体取决于任务类型和模型第二模型遵循度是最大的隐性变量如果发现生成的代码完全没有复用已有逻辑的痕迹赶紧换模型或把手动 prompt 模板加上第三Ponytail 给 AI 带来的不仅仅是少写几行代码还教会了模型动手之前先看清楚现场这个习惯这个习惯的收益比代码行数减少更重要。我目前的工作流是在 IntelliJ IDEA 里常驻 opencode 插件手动维护那份先回答三个问题再动手的 prompt 模板Ponytail 的 Skill 文件只在接到重构任务时临时加到配置里。这样既保留了它在旧代码重构中的高收益又不会在绿场任务里白烧 token。如果你正好也在权重构和代码整洁度可以考虑把这个流程完整抄一遍跑几轮之后再根据自己的项目调参数。