Ponytail 5：让 AI agent 先读代码再写代码，代码砍 53% 测试全过

研究对象：DietrichGebert/ponytail
抓取日期：2026-10-20 ｜ 当日 stars：1396
许可证：MIT ｜ 语言：JavaScript

一个你一定认识的人

每个公司都有这么一个人。长马尾，椭圆眼镜，在公司待得比版本控制还久。你给他看五十行代码，他什么都不说，直接替换成一行。

Ponytail 把这个人装进了 AI agent。

但这次重写后的 Ponytail 5 和之前版本有一个根本区别：它不再只是"砍代码"，而是先读代码再决定砍什么。

数字会说话

先看基准测试（2026-10-07，agentic 模式，多轮运行）：

更关键的两个数字：

• 98% 的有风险逻辑带了测试（无 skill 只有 68%）
• agent 自己的测试抓住了 66% 的注入 bug（无 skill 只有 46%）

代码砍了一半，测试覆盖率反而上升了。这不是"少写代码"，是"只写必要的代码"。

还有一组数字：在六个安全任务（SQL 注入、路径遍历、伪造 token、速率限制、畸形 CSV 行、缓存）上，Ponytail 5 跑了 30 次全过。更少的代码，不更不安全。

七级阶梯：懒惰的优先级

Ponytail 的核心机制是一个七级阶梯（ladder）。在写代码之前，agent 从第一级开始，停在第一个能 hold 住的级别：

1. 这东西需要存在吗？——也许根本不需要写。
2. 仓库里已经有了吗？——先搜一下。
3. 标准库能做吗？——Python/JS 自带的。
4. 原生平台功能？——浏览器自带的 <input type="date">。
5. 已安装的依赖能做吗？——package.json 里已有的。
6. 能不能一行搞定？——真的一行。
7. 以上都不行，才写最少能工作的代码——加一个小测试（如果有逻辑）。

这个阶梯的关键不是"写更少"，而是**"先确认必要性，再写"**。大多数 AI agent 的问题不是写得不好，而是不问"这东西需不需要存在"就直接开写。

README 里有一个 before/after 例子：你让 agent 加一个日期选择器。无 skill 的 agent 安装了一个日期选择器库，或者手写了一个完整的日历——335 行。Ponytail 5 先看仓库里有什么：有一个 Input 组件，浏览器原生支持日期选择。把两个放一起——10 行。

381 行的差距，不是"优化"出来的，是"问对了问题"消失的。

"懒惰，但不疏忽"

README 里有一句精确的表述：

Lazy about the solution, never about reading.

对解决方案懒惰，对阅读代码从不懒惰。阶梯是在 agent 读完代码、理解了问题之后才运行的，不是替代理解。

还有一条铁律：

Trust-boundary validation, data-loss handling, security, and accessibility are never on the chopping block.

信任边界验证、数据丢失处理、安全性、无障碍——这四样永远不在砍的范围内。Ponytail 砍的是"不必要的代码"，不是"重要的代码"。这就是为什么代码砍了 53% 但安全测试全过。

有分支、循环、解析器、涉及钱或安全的逻辑，会留一个小测试。每次回复都以"跳过了什么、没检查什么、有什么风险"结尾。懒惰不等于不负责。

新功能：band 和 board

Ponytail 5.3 新增了"band"——在 Claude Code 的 prompt 上方显示一条状态栏：

• 当前任务花了多少钱
• 用了多少 token、多少 agent 时间
• reuse 率：多少代码是复用已有的，多少是新写的
• 最后一轮改动后测试是否通过

这个 reuse 率是 Ponytail 最独特的指标。大多数 agent 的 dashboard 显示"写了多少代码"，Ponytail 显示"复用了多少代码"。71% reuse 意味着 71% 的代码是从仓库里已有的部分拿来的，只有 29% 是新写的。

"board" 是一个本地页面，跨项目展示所有任务的成本、时间、token、测试状态。默认所有数据留在本地（~/.config/ponytail/band/），不上传任何地方。

/ponytail-review：从"砍什么"到"修什么"

旧版的 /ponytail-review 只找可以砍的代码。5.0 重写后，它变成了"那个半夜被叫起来修 bug 的资深开发者"的视角：

• 读你的改动触及的代码，不只是 diff
• 检查 bug、安全、真实负载、缺失的测试、慢路径、可以砍的部分
• 每个 finding 说四件事：代码做了什么、出了什么问题、怎么修、不修会怎样

基准测试：100% 的植入问题被发现（无 skill 87%），100% 的 diff 外问题被发现（无 skill 78%）。

"读 diff 外的代码"是关键。大多数 code review 工具只看 diff，但很多 bug 是改动引发的连锁反应——你改了一个字段名，另一个没碰过的文件就崩了。Ponytail review 会读那个文件。

/ponytail-audit：整个仓库，按优先级排

/ponytail-audit 对整个仓库做同样的检查。它先画地图：入口点、数据流向、预期负载。然后按优先级排列发现：

1 must fix: office batches with 1,200 fail completely
2 must fix: the import silently skips bad rows
3 must fix: a mistyped SKU in an office batch is silently ignored
4 should fix: the risky code paths have no tests
5 nice to have: the API crashes on a body that isn't an object

"先修哪个"比"有多少问题"更有用。大多数审计报告列出 50 个问题但不排优先级，开发者看了就关了。Ponytail audit 直接说"先修 1，因为 1200 条批次完全失败"。

/ponytail-debt：把"以后再说"变成账本

开发者经常在代码里写 // TODO: refactor later 或者 // shortcut: 用了硬编码，以后改。这些 shortcut 会累积成技术债，但很少有团队追踪它们。

/ponytail-debt 扫描代码里的 shortcut: 注释，把它们收进一个 ledger。每个 shortcut 记录位置、原因、影响范围。"以后再说"不再变成"永远不说"。

这是一个很 Ponytail 的功能：承认你会走捷径，但让捷径可见。

一个 prompt，不是一个框架

Ponytail 的核心是一个 prompt：skills/ponytail/SKILL.md。没有 RAG、没有微调、没有向量数据库、没有 agent 框架。它只是一个精心写的 prompt，被加载到不同的 agent 里。

这说明了一件事：很多 agent 行为问题不需要基础设施解决，需要的是更好的指令。你不需要给 agent 装一个"代码审查微服务"，你需要的是告诉它"在写代码之前，先问自己这七个问题"。

Ponytail 的成功证明了一个不太流行的观点：prompt engineering 还没到天花板。在所有人都在谈 RAG、微调、agent 框架的时候，一个写得好的 prompt 能砍 53% 的代码、提升测试覆盖率、降低 26% 的成本。

"少"是目标，"必要"是清单

README 里有一句总结：

The rule was never "fewest tokens." It is: write only what the task needs, and never cut validation, error handling, security, or accessibility. The code ends up small because it is necessary, not golfed. Lower cost and latency are a side effect.

目标不是"最少的 token"，是"只写必要的"。代码最终变小是因为它必要，不是因为被压缩。更低的成本和延迟是副作用。

这个区分很重要："少"是目标，"必要"是清单。目标不告诉 agent 什么不能砍，它会把验证和错误处理一起砍了；清单明确写着验证、安全、无障碍不在刀下。98% 的有风险逻辑带了测试，就是因为清单上有这一条。

GitHub: https://github.com/DietrichGebert/ponytail
许可证: MIT
基准测试: benchmarks/results/2026-10-07-agentic.md