开发者实测 Ponytail 插件：让编码智能体少写一半代码

所有文章 2026年11月13日 · 7 分钟阅读 · Nathan Broadbent Ponytail 能让 coding agent 写的代码量减少大约一半。我让 Claude Code 在我们的 Rails monorepo 上对它做了基准测试，并拿它对照了我过去五个月的消息记录。下面是我们保留了什么、跳过了什么，以及我们现在已经开源的配置。 前几天有人跟我提到 Ponytail。它是 Claude Code、Codex 和其他 coding agent 的一个热门插件，作用是让它们少写代码：它扮演“懒惰的资深开发者”，在动手写最小可用版本之前，先问一句这个改动到底需不需要存在。它自己的基准测试显示，agent 写的代码行数大约减少一半，成本降低四分之一，在隐藏测试上的结果还略好一些。 我琢磨着自己是不是也该用上它，于是让 Claude Code 去查一查。 Claude 翻了我过去五个月在主仓库的 Claude Code 会话里输入的 10,939 条消息，把我提出的每一条抱怨归类为“做得太多”或“做得太少”。它读了我的 AGENTS.md 文件、skills 和评审记录，用 Ponytail 的检查清单重新评审了我们一些已发布的 commit，还跑了 16 次基准会话：从我们的历史记录里取四个真实任务，分别在启用和不启用 Ponytail 的情况下执行，然后由一个盲审来打分。最后它给我写了一份报告，给出了明确的建议。 我们是在 Rails 和 React 的 monorepo 上，用 Claude Code 2.1 和 Opus 5.5 评估的 Ponytail 5.3.3。这次基准测试规模很小（四个任务，每个跑两次），所以这些数字只能当作大致方向来看。我们采纳的规则从 11 月 13 日起已经写进了我们的 AGENTS.md。 Ponytail 由一组规则（大约 470 个词）、几个 skill（review、audit，以及一份有意为之的捷径清单）和若干 hook 组成，这些 hook 会在每个会话和每个 subagent 中把它启用。规则归结起来就是一个阶梯：这东西需要存在吗？现有代码能做吗？标准库能做吗？然后就写能用的最少代码，并留下一条捷径注释，写明你接受了哪些限制、什么时候需要重新审视。 它的基准测试跑了 39 个任务，每个任务执行五次，分别启用和不启用 Ponytail。启用 Ponytail 的运行写出的代码行数少了 53%，成本低了 26%，完成速度快了 41%，隐藏检查的通过率为 96.7%，对照组为 95.6%。收益最大的是前端任务和小型应用任务。 那个基准测试关闭了 CLAUDE.md 文件和自动记忆。单独衡量这个插件时这样做是合理的，但我的 agent 从来不是这样运行的。它们每个会话开始时都会加载根目录的 AGENTS.md、代码库各个部分的嵌套 AGENTS.md、记忆，以及一整套工作流 skill。所以对我们来说，问题在于 Ponytail 在这一切之上还能不能带来额外价值。 DocSpring 负责填充 PDF、生成文档和收集电子签名。已签署合同里的一个错误值，比一条报错信息糟糕得多，所以我们的 agent 配置倾向于极度谨慎。我们有 42 个 AGENTS.md 文件，总共大约 65,000 词：一个根文件写每次改动都要遵守的规则，代码中每个有自己坑的部分（迁移、后台任务、公开 API、CI）旁边各有一个嵌套文件。除此之外，我们还有围绕代码的工作流 skill：在写任何东西之前调查工单、协作式 PR 评审、由另一个模型给出第二意见的评审、修复 CI、浏览器 QA 检查，以及会话结束前的收尾排查。 Claude Code 发现的“agent 做得太多”的抱怨，大约是“做得太少”的两倍。大多数“做得太多”的抱怨都和代码有关：没人要求的选项、兼容层、回填任务、和我们已有辅助函数重复的辅助函数。Ponytail 针对的正是这一类问题。 “做得太少”的抱怨更少，但几乎都有同样的形态：agent 提议为某件事开一个后续工单，而它本该在同一个分支里修好。如果进一步施压让它少做，这类问题只会更糟。 评审循环是多余代码的另一个主要来源。前一天我们审计一个批量分支时，大约三分之一的代码来自评审循环：AI 评审发现一个边缘情况，修复引入了新代码，下一次评审又在修复里发现一个边缘情况，如此往复。其中很多情况是真实客户或 PDF 永远不会产生的输入。 我们的 PR 评审记录从另一面讲了类似的故事。人工决定处理的评审发现中，大约十分之九被接受并修复。只有不到百分之一的发现是关于本不该存在的代码。我们的评审很擅长找出缺失的东西，却几乎从不问某个东西到底该不该存在。 当 Claude Code 用 Ponytail 的检查清单重新评审我们最近发布的四个 commit 时，其中三个本来就很精简。第四个手写了一套“在事务提交后执行这个”的机制，而 Active Record 已经以 ActiveRecord.after_all_transactions_commit 提供了这个能力，我们的计费代码用了它大约十次。 Claude Code 从我们的 git 历史里取了四个任务（一个仪表盘汇总、一个注册流程改动、一个头像修复和一个欢迎弹窗），检出每个任务之前的那次 commit，把原始任务交给加载了我们 AGENTS.md 的全新 Claude Code 会话。一半会话还额外加载了 Ponytail 的规则。每种组合各跑两次。 然后由一个单独的会话在不知道哪份是哪份的情况下评判这些 diff。它更青睐只有我们自己配置的那一组：总体 6.8 分对 5.9 分（满分 10 分），完整性 2.4 分对 2.1 分（满分 3 分）。它也在我们那一组的 diff 里找出了更多可以删掉的代码（253 行对 94 行），所以 Ponytail 的 diff 确实更精简。 完整性上的差距来自真实的遗漏。在注册任务中，两个启用 Ponytail 的会话都改动了使用 Google 和 GitHub 的注册路径，却漏掉了用户手动输入姓名的那条。在头像任务中，两个启用 Ponytail 的会话都留下了一个会失败的测试，而且它们的最终回复对代码做出了不实的说法。在汇总任务中，每个会话，无论是否启用 Ponytail，都构建了一个没人要求的、用于修复现有数据的任务。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）