作者： Matt Connor
Ponytail：让 AI 编程代理少写代码的规则
Ponytail 通过决策阶梯让代理优先复用现有代码、标准库和平台功能。了解它的规则、基准测试结果，以及如何立即复制这套方法。
Ponytail 是什么
Ponytail 是一组规则，用于让 AI 编程代理少写代码。该项目用一句话介绍自己：“让你的 AI 代理像房间里最懒的资深开发者一样思考。最好的代码，就是你根本没有写过的代码。”它采用 MIT 许可证。它本身没有运行时，也不会执行任何内容。它只是代理指令中的文本：对于支持加载 skill 的宿主，打包为 skill；对于不支持加载 skill 的宿主，则作为普通规则文件提供。
该仓库位于 DietrichGebert/ponytail。它创建于 12 June 2026，并在 1 August 2026 前达到 90,000 stars。1 August 2026 时，最新的带标签版本是 v4.8.4，发布于 29 June 2026；仅 14 June 至 29 June 期间，releases 页面就列出了十个标签。它的更新速度并未放缓：17 October 2026 时，最新版本是 v5.3.2，于 16 October 深夜发布，是当天继 v5.3.0 和 v5.3.1 之后的第三个版本。此前，v5.2.0 于 13 October 发布；五天前的 8 October，v5.0.0 和 v5.1.0 同时发布。该仓库显示的 stars 已超过 165,000。按这样的速度推进，等你阅读本文时项目可能已经发生变化，因此在基于它构建任何内容前，应先固定一个标签。
工具之前的思路：在第一个成立的阶梯处停止
Ponytail 的核心是一个决策阶梯。代理在编写任何内容前先沿阶梯检查，并在第一个成立的阶梯处停止。
- 这项功能是否根本不需要存在？这就是 YAGNI（你不会需要它）。如果答案是否定的，就跳过它。
- 代码库中是否已经存在？复用已有的辅助函数或模式。
- 标准库是否能完成？使用标准库。
- 原生平台功能是否能覆盖？使用原生平台功能。
- 已安装的依赖项是否能解决？使用它。
- 能否写成一行？就写成一行。
- 只有在此之后，才编写能正常工作的最少代码。
这就是 v4.8.4 中写出的阶梯，本文其余部分的阶梯编号也遵循这一顺序。当前的 main 分支将第 3 和第 4 阶梯合并为一个：“标准库或平台功能？除非项目有自己的实现，否则使用它。”同时补充了“项目自有组件优于原生小部件”，因此现在共有六个阶梯。顺序不变。
真正发挥作用的是顺序，而不是某个单独的阶梯。代理收到“添加日期选择器”的要求后，就会编写日期选择器，因为这正是它被要求完成的任务。决策阶梯会要求它在构建任何内容前检查已有实现：第 2 阶梯询问代码仓库中是否已有对应组件，第 4 阶梯指出浏览器已经提供了 <input type="date">。项目当前的基准测试记录正好说明了这一点：不使用该规则时，日期选择器最终有 335 行；使用 Ponytail 5 后，只有 10 行，因为代理复用了代码仓库自己的 Input 组件和 type="date"，并让浏览器提供日历功能。颜色选择器的代码量减少得较少，从 135 行降至 26 行。第 2 阶梯最容易无声地失效，因为代理如果看不到已有的辅助函数，就会直接再写一个；可查询的代码库映射正是为了弥补这一缺口。
这里的“偷懒”并不意味着粗心，规则集对此有直接说明。“绝不在这些方面偷懒”列表包括：在做决定前理解问题、在信任边界验证输入、防止数据丢失的错误处理、安全性、可访问性，以及用户明确要求的任何内容。规则集还要求为每段非平凡逻辑添加一个小型可运行检查。该规则减少的是重复发明，而不是正确性。
该仓库实际提供的内容
AGENTS.md，始终启用的规则集。全部核心思想都集中在这个文件中，五分钟即可读完。skills/ponytail/SKILL.md，skill 定义，其中的参数提示为lite、full、ultra或off。- 编辑器专用目录下的规则文件，例如
.cursor/rules/和.windsurf/rules/，供能够读取规则但不会加载 skill 的宿主使用。 hooks/、benchmarks/、examples/和scripts/。
强度参数会改变规则施加约束的力度。lite 会构建你要求的内容，并在一行中指出一个更懒的选项。full 是默认设置，会强制执行该阶梯。ultra 是 YAGNI 极端设置：它倾向于删除而不是添加，并且会质疑需求本身。
支持 skill 的宿主还会获得 slash 命令。/ponytail 设置级别，/ponytail-review 检查 diff 是否存在过度设计，/ponytail-audit 检查整个仓库，/ponytail-debt 收集你推迟处理的快捷方式，/ponytail-gain 输出基准评分卡。只读取规则文件的宿主只能获得规则集，不提供命令。自 v5.3.0（发布于 16 October 2026）起，Claude Code 还会在提示词上方显示一个信息栏，展示任务成本、代码复用情况和测试状态。它要求 Claude Code 2.1.290 或更高版本，不会出现在 VS Code 聊天面板、云端会话或 claude -p 中；/ponytail band off 可以将其隐藏。自 v5.3.2 起，/ponytail band import 会读取你过去的 Claude Code 会话，并将其成本、代理运行时间和 tokens 添加到信息板中，这样你可以将这些会话与启用该规则运行的会话进行比较。
在信任源代码之前，应克隆标签而不是分支。上面的阶梯规则来自此标签；如果要阅读当前内容，可将其替换为 v5.3.2，这是 17 October 2026 的最新标签：
git clone --depth 1 --branch v4.8.4 https://github.com/DietrichGebert/ponytail.git对于 Claude Code，项目改为记录 plugin 安装方式。以下两行与 17 October 2026 的文档一致：
/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytailplugin 路径跟随默认分支，而不是固定标签。因此，在不同会话之间，控制代理行为的指令可能发生变化。使用更新命令更方便，但这就是你需要接受的代价。
为什么“懒惰”的 agent 在 VPS 上更省钱
agent 写入的 diff 不会离开当前对话。下一轮中，模型会再次读取它，同时还会读取它为生成该 diff 而打开的每个文件。因此，500 行的修改不仅会增加生成它的那一轮的成本，还会在会话后续每一轮中持续增加成本，直到压缩操作用摘要替换较早的对话内容。正因如此，失控的重构会让 agent 随着会话持续进行而变得越来越慢、越来越不可靠：上下文窗口被 agent 自己的输出填满，留给实际代码的空间就会缩小。如何控制这一点，正是管理编码 agent 的上下文窗口的全部内容。
Token 按输入和输出分别计费，因此一个大小减半的 diff 会节省两次成本：写入时节省一次，之后每一轮重新读取时再节省一次。节省是否会反映在账单上，取决于您的付费方式。Pro 或 Max 订阅只会在使用限额内吸收额外 token；超过限额后，选择启用的用量额度会单独计费。按 token 计费的 API 则会为每个 token 收费。如果您在自托管环境中关注账单，指令文件就是一个无需成本即可调整的控制点。控制 AI agent 的成本应从输出量开始，而编码 agent 如何消耗 token则解释了为什么重新读取的成本比很多人预期的更高。
diff 仍然需要人工审查。一个本应只有 20 行、却写成 400 行的修改会消耗审查者的注意力，而注意力是最先耗尽的资源。没有人能像认真审查当天第一个长 diff 那样，认真审查当天第四个长 diff。因此，过度实现不仅浪费时间，还会悄然降低本应发现错误的审查质量。
在服务器上，风险更高，因为 agent 通常会在无人监控的情况下运行。agent 在 tmux 会话中或按定时任务运行时，可能有数小时的时间在错误决策的基础上继续操作，直到您发现问题。这就是在 VPS 上运行编码 agent的实际风险，也是进行循环工程的人会把大量精力放在持久指令上，而不是单个提示上的原因。始终启用的文件中的规则可以应用于第 200 轮；您在聊天中输入的规则只能应用于第 3 轮。该文件中的规则还会应用于您在同一台服务器上启动的第二个会话。第二个会话可以读取已提交的文件，但不会继承您在第一个会话中输入的内容，即使两个会话可以相互发送消息。
新增依赖项是另一项隐性成本。第 5 条要求使用已安装的软件。agent 自行添加的每个软件包，之后都需要您负责打补丁，并且最终会进入您从该代码仓库构建的每个容器镜像。
Ponytail 自己的基准数据说明了什么
该项目发布了两类结果，两者相差很大。两者都是项目自行发布的数据，均不是独立测试结果。
此图表背后的数据
[
{
"label": "Lines of code",
"v4_13_pct": 48,
"v5_pct": 53
},
{
"label": "Cost per run",
"v4_13_pct": 16,
"v5_pct": 26
},
{
"label": "Wall clock time",
"v4_13_pct": 38,
"v5_pct": 41
}
]该图表是项目当前的代理基准测试，日期为 7 October 2026。测试使用默认工作强度的无头 Claude Code 2.1.288 会话，在 39 个任务上运行；每个任务和每个测试组运行五次，共 585 个会话，测试组包括不使用 skill、Ponytail v4.13.0 和 Ponytail 5。其中 12 个任务是 tiangolo 的 full-stack-fastapi-template 中的功能工单。这是一个真实的 FastAPI 和 React 仓库，评分依据是最终留下的 git diff。其余任务包括 18 个带隐藏检查的外科式任务、6 个小型应用请求，以及 3 个“给我看一个示例”的请求。所有测试组均禁用 Bash。使用 Ponytail 5 后，输出 token 减少了 45%。
将这一结果与项目在 June 2026 发布的单次运行数据对比。那些数据来自一个裸模型在有规则和无规则情况下回答 5 个日常提示，并以多次运行的中位数报告。结果显示，在 Haiku、Sonnet 和 Opus 上，代码量减少了 80% 至 94%；17 June 2026 的成本核验显示，Haiku 的成本降低了 63%。当前 Ponytail 5 的代理测试结果是代码行数减少 53%，成本降低 26%，实际耗时减少 41%。项目很快修正了单次运行数据。到 v4.8.4 时，即 29 June 2026，README 已将代理测试结果置于标题位置：“代码减少约 54%（最高 94%）”，并注明此前的 80% 至 94% 是“每个任务的上限，而不是平均值”；同时，它将单次运行数据移入名为“Older single-shot numbers”的折叠区域。该区域明确说明了差距产生的原因：单次运行基线是一个裸模型，它会“用说明文字和选项填充答案”，因此很容易被超越。与执行实际工作的真实代理进行比较，优势会缩小。但这一优势仍然存在，这才是更有用的事实。那次 June 的代理测试使用 Haiku 4.5，测试 12 个工单，每个运行 4 次，代码行数减少了 54%，接近当前数据；当前 README 已不再保留单次运行数据。
项目还提出了一个限制条件，这也是决定它是否对你有帮助的关键。真正存在过度构建风险的代码，节省量最大；原本已经足够精简的代码，节省量接近于零。October 的逐任务表也证明了这一点：多个外科式任务在三个测试组中的代码行数完全相同。仅使用一个模型和一个宿主完成的 39 个任务，且禁用了 Bash，无法预测你的仓库会得到什么结果。如果这个数字对你很重要，应在自己的工单上分别运行有规则和无规则的对比，并自行统计代码行数。
今天无需安装即可复制的模式
这个梯子本质上是文本，因此无需安装插件即可使用这一思路。将类似下面的代码块粘贴到 agent 已经读取的指令文件中，可以是 AGENTS.md、CLAUDE.md 或编辑器的规则文件。
## Before you write code
Climb this list in order. Stop at the first line that applies.
1. Does this need to exist? If not, say so and stop.
2. Does this repo already have it? Reuse the helper.
3. Does the standard library do it? Use it.
4. Does the platform do it natively? Use it.
5. Does an installed dependency do it? Use it.
6. Can it be one line? Write one line.
7. Otherwise write the minimum that works.
Never take the shortcut on: reading the code before changing it, validating
input that crosses a trust boundary, error handling that would otherwise lose
data, security, accessibility, or anything I asked for by name.
Do not add an abstraction I did not ask for. Do not add a dependency without
saying why in one line. Prefer deleting code to adding it.
Mark a deliberate simplification with a comment naming its ceiling and the
upgrade path.最后一条规则值得单独说明。Ponytail 当前版本的约定是使用带有 shortcut: 标签的注释，说明限制条件以及何时升级（6 月发布的版本，包括 v4.8.4，改用 ponytail: 标签）：
# shortcut: global lock, per-account locks if throughput matters这条注释只需两行，却能解决一个原本可能耗费一轮审查的问题。它告诉下一位读者，简单版本是经过决策的方案，并说明该方案何时不再适用。没有这条注释，审查者无法判断这是经过权衡的简化方案，还是 agent 遗漏了某项工作，因此只能提出疑问。
代码块的放置位置与内容同样重要。agent 每次运行都会加载的文件会影响每次运行，包括你没有监控的运行。编写 agent 实际遵循的 AGENTS.md 说明了这种差异，也正因如此，这种模式应放在已提交的文件中，而不是 shell 历史记录里。在 monorepo 中，它应放在多个已提交的文件中，因为为每个包设置一个 AGENTS.md可以让每个目录的规则保持简短，避免 agent 每次运行都读取整个目录树的约定。不过，文件位置并不能保证规则一定生效。在断定需要使用更强措辞之前，最好先了解agent 为什么会跳过已加载的规则。
规则不再适用的情况
这套阶梯针对的是已有代码库中的功能开发，此时通常可以复用现有代码，而且复用通常是正确的。它不太适合从零开始的项目，因为第 2 级没有可复用的内容，第 5 级也没有已安装的组件。代理仍可停在第 1 级，即使用标准库、平台功能或单行实现，但两个成本最低的选项已经不存在，因此更多任务会落到编写新代码上。如果你确实需要抽象，它也不适合此时使用。即将添加同一段复制代码的第 4 个调用方时，“最短差异”会让你再复制出第 5 份。
ultra 级别会质疑你的需求。这正是该级别的用途；但如果你已经做出决定，只希望完成工作，这也会带来实际成本。日常工作使用 full；怀疑功能请求本身有问题时，再使用 ultra。
没有任何指令块可以避免你误解问题。规则集的第一项本身就是在做决定前理解代码，而这一步最耗时，也是文本无法替你完成的部分。在错误的函数中使用最小差异，仍然是错误的修复；而且现在它是一个容易获批的小型错误修复。
坦率地说，Ponytail 是一份编写严谨、分发得当并附有数字的提示词。它不要求使用该插件。这个项目提供的价值在于：有人正确编写了这份列表，在真实代码库上进行了测试，并将方法与结果一同发布。
FAQ
Ponytail 是否支持 Claude Code 以外的代理？
支持。它以 skill 的形式提供给能够加载 skill 的宿主，README 中列出的宿主包括 Claude Code、Codex、OpenCode、Gemini 以及其他几个工具。Cursor、Windsurf、Cline 和 Copilot 等只能读取规则文件、但不会加载 skill 的编辑器，会从匹配的规则目录读取始终启用的规则集，但不会获得斜杠命令。两种方式使用的是相同文本，真正的区别在于宿主是每轮都将这些文本保留在上下文中，还是仅在触发 skill 时加载。
惰性代理会跳过测试、验证或安全检查吗？
不会，规则集对此有明确要求。“绝不偷懒”的列表包括信任边界上的输入验证、防止数据丢失的错误处理、安全性和无障碍性，并要求为每段非平凡逻辑提供一个可运行的小型检查。该规则移除的是臆造的结构：没人要求的抽象，以及没人需要的依赖。如果安装后代理开始删除测试，原因是你自己的配置中存在优先级更高的其他指令。请读取代理最后加载的文件。
已发布的速度和成本数据可靠吗？
这些数据是项目自行测量并发布的，附带测量方法，因此应按这一范围理解。2026年6月的单次运行数据与一个基础模型进行了比较；该模型用额外说明和选项扩充答案，README 当时也指出这是一个较弱的基线。当前的代理运行数据来自无头 Claude Code 的 Opus 5.5 会话，共39个任务，每个任务运行5次，其中12个是同一个 FastAPI 和 React 仓库中的功能工单。对于该配置，这些数据是真实的。但它们不能预测你的代码库，因为项目按任务发布的结果显示，对于原本已经精简的代码，节省量会降至接近零。
是否必须安装某些内容才能获得收益？
不需要。这个阶梯本质上是文本。将等效内容块粘贴到代理已经读取的指令文件中，就能获得大部分效果。插件提供维护后的措辞、强度级别、审查命令和更新路径。先尝试复制内容，是回答“是否必须安装才能使用”的第1级方案。
如何阻止无人值守的代理在夜间过度构建？
将规则放入始终启用的指令文件，而不是聊天消息中。这样规则会在长时间运行的第200轮继续生效，而不只是在第3轮生效。然后单独限制潜在损失：为代理提供一个允许其破坏的 checkout，不要使用唯一副本，并要求人工审查 diff 后才能合并。最小 diff 规则可以减少需要阅读的内容。但它不会决定哪些更改最终落地，也不应由它决定。