Ponytail 技术解读：七级决策梯如何让 AI 编码代理少写 54% 的代码

AI 编程工具的功能列表越拉越长，代理写出来的代码却常常比需要的多得多：要一个日期输入框，它会安装第三方库、封装组件、再补一堆样式和配置。GitHub 上的开源项目 DietrichGebert/ponytail 把这个问题当成唯一目标来处理。它的自我介绍只有一句：让你的 AI 代理像屋里最懒的高级工程师一样思考，最好的代码是你永远不用写的那部分。

这个项目目前拥有超过 11 万 star，日增 star 数长期保持在四位数，npm 包名为 @dietrichgebert/ponytail（当前版本 4.9.0），MIT 协议，运行时零依赖。它在 2026 年 6 月发布了一份针对批评者意见重建的 agentic benchmark，方法论和数据都在仓库内公开，可以直接复现。

七级决策梯：懒在方案，不在阅读

ponytail 的本体是一份规则集，不是框架。代理在动手写代码之前，按顺序停在第一个成立的梯级上：

1. 这段代码需要存在吗？     不需要就不写（YAGNI）
2. 代码库里已经有了吗？     有就复用，别重写
3. 标准库能做到吗？         用标准库
4. 平台原生特性能做到吗？   用原生特性
5. 已安装的依赖能做到吗？   用现有依赖
6. 一行能解决吗？           就写一行
7. 以上都不行               写能工作的最小实现

两个细节决定了这份规则和普通 prompt 的差别。其一，决策梯在代理理解问题之后才运行：它先读取这次改动涉及的代码、追踪真实的数据流，然后再选梯级，规则约束的是产出方式，替换不了前置的理解过程。其二，有些东西永远不进砍削范围：信任边界上的输入校验、数据丢失处理、安全性、无障碍访问。项目的原话是"懒于解决方案，绝不懒于阅读"。它追求的目标同样经过了校准：代码量小是因为必要，不是刻意的 code golf，更低的成本和延迟只是副产品；对一个会在思考阶段反复权衡梯级的 terse 推理模型，这套规则可能适得其反（作者确认在 GPT-5.5 上就出现了反向变化）。

被批评打出来的 benchmark

ponytail 最初的测试是单轮生成式：一条 prompt、一次回答、数回答里的行数，结果显示代码量减少 80% 到 94%。Colin Eberhardt 在 issue #126 里指出这个对比站不住脚：裸模型的基线会用大量散文、注意事项和多个备选方案填满回答，行数统计把评论也算成了代码；而且真实的编码工作是多轮代理编辑真实代码库，一次补全说明不了问题。

作者的回应是把整个 benchmark 推倒重建。新版直接把这些批评写进了实验设计：

实验设置：Claude Code 2.1.177 无头模式，模型 Haiku 4.5，仓库选定 tiangolo/full-stack-fastapi-template（固定的 commit cd83fc1，FastAPI 加 React 的真实项目），12 个功能工单，每组配置跑 4 次，四个对照组分别是无技能基线、ponytail、caveman（只在语气上简短的对照技能，用来分离"说话简短"和"写码克制"两种效应）、以及 Colin 本人的七个词的 prompt（"Follow YAGNI principles, and prefer one-liner solutions"，加进系统提示）。

结果里 ponytail 是唯一在所有指标上同时下降、且保持满分的组：

以基线均值为参照（每任务 191 行新增代码、349k tokens、约 0.10 美元、69 秒），ponytail 平均写下 46% 的行数、消耗 78% 的 tokens、花费 80% 的成本、用时 73%。最大的削减发生在基线过度建设的场景：日期选择器从 404 行降到 23 行，因为 ponytail 直接取用 <input type="date"> 这个浏览器原生控件；颜色选择器 287 行对 23 行，用的同样是 <input type="color">；文件拖放区 251 行对 95 行。而在没有压缩空间的代码上，各组迅速收敛：标题搜索接口四个组的行数都是 44 行上下，命令面板 233 到 285 行之间，后端 CRUD 任务几乎没有差异。ponytail 没有在没有油水的地方发明节省。

caveman 的位置说明了简短语气解释不了结果：它能省一些代码（80%），但 tokens 和成本反而高于基线（107%、102%）。真正起作用的是克制的代码决策，简洁的表达风格贡献不了多少。那句七个词的 prompt 则表现不稳定，在颜色选择器上拿到了全场最低的 25 行，在向导组件上写了 406 行，命令面板 285 行还超过了基线的 268 行；同样的 prompt 时灵时不灵，插件每次都落在同一侧。

成本差异在小任务上就能拉开：同样是实现日期选择器，基线组平均花费约 0.15 美元、耗时 88 秒，ponytail 组约 0.06 美元、49 秒。

安全维度单独设了一层：6 个对抗性任务（路径穿越、SQL 注入、令牌伪造、畸形输入、限流绕过），直接执行生成的函数来评分。基线、caveman、ponytail 全部满分，唯一的失分来自"YAGNI + one-liners"prompt 组（95%，有一次丢掉了输入防护）。这组数据回答了 #126 里最尖锐的问题：追求代码最小化是否会牺牲防御。这份结果给出的答案是，完整的规则集守住了防线，粗糙的极简口号没守住。

一次自曝家丑的测量

重建过程中还有一段值得记录的经历。早先一版 agentic 测试只显示出约 4% 的差距，团队差点照此发布，随后发现了实验污染：ponytail 和 caveman 作为 Claude Code 插件都会触发 SessionStart 钩子，而这个钩子在所有对照组上都生效了，等于基线也被偷偷装上了 ponytail。修复方式是给每个单元格隔离设置源（--setting-sources project,local），并用 --plugin-dir 保证每个组恰好加载一个插件。这个 bug 的排查过程连同原始数据一起留在了公开的方法论文档里，附带的说明是，这种错误正是让 benchmark 说谎的那类错误。

装进你的编码代理

ponytail 支持 20 多个编码代理客户端，常见的几种接入方式：

# Claude Code（两条命令分两次发送）
/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytail

# Codex
codex plugin marketplace add DietrichGebert/ponytail
codex plugin add ponytail@ponytail

# OpenCode：opencode.json 里加一行
{ "plugin": ["@dietrichgebert/ponytail"] }

# Gemini CLI
gemini extensions install https://github.com/DietrichGebert/ponytail

# Hermes Agent
hermes plugins install DietrichGebert/ponytail --enable

不依赖插件的客户端走 AGENTS.md 约定：把仓库根目录的 AGENTS.md 复制进项目即可，CodeWhale、Qoder 这类自动加载该文件的工具就是零配置接入。装好后规则集默认常驻，另有 6 条命令管理粒度：/ponytail lite|full|ultra|off 切换强度，/ponytail-review 做评审，/ponytail-audit 审计冗余代码，/ponytail-debt 登记技术债，/ponytail-gain 统计节省量。Claude Code 与 Codex 的插件层会运行两个 Node.js 生命周期钩子负责自动激活，机器上需要有 node 在 PATH 里。

用之前要知道的事

这份 benchmark 的所有结论建立在一个模型上：Haiku 4.5。作者明说一个模型足以证明论点，但也明说换个模型结果可能移动，terse 推理模型上有实测的反向案例。54% 是 12 个任务的均值，上限是日期选择器那种 94% 的平台特性替换场景，下限是零节省的收敛区，具体到某个团队的代码库，数字取决于那里有多少"本该是原生控件的手搓组件"。这份测试也没有执行 Web 服务或浏览器端到端流程，度量止于代理留下的代码本身。

至于一个 prompt 规则集为什么能在趋势榜上压过大量重型框架，上面这些章节本身就是回答的一部分：一份知道自己在测什么、并且愿意公开自己错过的测量，加上一条能把 404 行的需求压回 23 行的规则。

来源：DietrichGebert/ponytail（MIT License）、agentic benchmark 方法论、npm @dietrichgebert/ponytail