这个插件,让 AI 少写 54% 代码:Ponytail 把“偷懒”变成工程能力

AI 编程越来越快，但很多开发者正在遇到一个反直觉的问题：代码生成得越容易，项目反而越容易变复杂。

你只想加一个日期选择器，Agent 却可能安装第三方组件、封装 React 控件、补一份样式文件，最后再和你讨论时区兼容。功能当然能跑，只是仓库里平白多出几百行需要长期维护的代码。

开源项目 Ponytail 想解决的，正是这种“AI 过度建设”。它把一位惜字如金、厌恶重复劳动的资深开发者塞进 AI Agent：不急着写代码，而是先问一句——这段代码真的有存在的必要吗？

项目作者用一句话概括它：最好的代码，是从未写下的代码。

它不是让 AI 玩“代码高尔夫”

Ponytail 的核心不是把十行挤成一行，更不是为了少写而删掉异常处理。它提供的是一套写代码之前的决策顺序：

1.这个功能真的需要做吗？不需要就跳过。

2.代码库里已经有了吗？优先复用现有工具和模式。

3.标准库能解决吗？能就别重复实现。

4.操作系统、浏览器或语言原生能力能解决吗？直接使用。

5.已安装的依赖能解决吗？避免再引入新包。

6.一行代码足够吗？那就只写一行。

7.以上都不行，才编写能工作的最小实现。

这套顺序看起来朴素，实际非常针对 AI Agent 的行为偏好。模型善于“生产”，也容易把专业感误解成更多分层、更多抽象、更多配置。Ponytail 则在生成前增加一道克制机制，让 Agent 先寻找仓库、标准库和平台已经给出的答案。

README 里的日期选择器案例很有代表性。普通 Agent 可能引入 flatpickr，再写包装组件和样式；Ponytail 首先想到的是浏览器本来就支持：

这不是炫技，而是把维护成本交还给成熟的平台能力。

“懒惰”必须建立在理解之上

Ponytail 特别强调：对解决方案偷懒，不等于对问题偷懒。

Agent 仍然需要阅读相关代码、追踪真实调用链，并找到根因。修 Bug 时，它要求搜索所有调用方，尽量在共享函数中修一次，而不是只在报错路径上贴补丁。

它还划出了一条清晰红线：输入信任边界的校验、防止数据丢失的错误处理、安全性、可访问性，以及用户明确要求的内容，都不能为了减少代码而牺牲。非平凡逻辑也要留下一项最小可运行检查。

所以，Ponytail 所说的“懒惰”，更接近成熟工程师的判断力：

●不创建没人要求的抽象；

●能不增加依赖，就不增加；

●优先删除，而不是继续堆叠；

●选择无聊但可靠的方案；

●用尽可能少的文件完成正确改动。

少写 54%，这个数字怎么来的？

项目给出了一组 Agent 实测：使用 Haiku 4.5，在真实的 FastAPI + React 开源仓库中完成 12 项功能任务；同一任务分别运行无技能基线、Ponytail、简短表达对照组，以及“遵循 YAGNI、偏好一行代码”的短提示词，每组每项运行 4 次，最后按 git diff 的新增行数统计。

项目报告显示，相对无技能基线，Ponytail 平均减少约 54% 代码量、22% Token、20% 成本和 27% 耗时。

差距最大的地方，恰好是最容易过度建设的功能：日期选择器从平均 404 行降到 23 行，颜色选择器从 287 行降到 23 行；但在本来已经很精简的后端 CRUD 任务中，各组结果接近。

这点很重要：Ponytail 并不能凭空压缩所有代码，它主要消除的是原本没有必要出现的复杂度。

安全测试中，Ponytail 在 20 次对抗性检查里全部通过；那条只有“YAGNI + one-liner”的短提示词通过率为 95%，曾有一次为了更短而漏掉路径穿越防护。项目借此说明：稳定的工程约束，比一句“少写点”更可靠。

当然，这些仍是项目方自测，不应被理解为适用于所有模型和仓库的普遍结论。测试只使用了一个模型、每项 4 次运行，安全题目数量也有限。更大的模型、不同语言和不同代码库，都可能得到不同结果。值得关注的不是一个绝对百分比，而是它证明了一种可复现的方向：先减少不必要的建设，再谈生成速度。

它适合谁？

如果你经常使用 Codex、Claude Code、OpenCode、Gemini CLI 或其他编程 Agent，且遇到下面这些情况，Ponytail 值得一试：

●小需求经常变成大改动；

●Agent 动不动就安装新依赖；

●仓库里重复工具函数越来越多；

●简单页面被拆出过多组件和配置；

●Code Review 的大量时间花在删掉“自作主张”的代码上。

它也不是所有场景的万能答案。需要明确扩展点的公共 SDK、严格分层的大型系统，以及团队已经统一规定架构模式的项目，不能只以代码行数衡量质量。Ponytail 的价值是提供默认刹车，而最终边界仍要由项目规范决定。

Codex 两行即可安装

Ponytail 已提供 Codex 插件形式。按照项目 README，可以依次执行：

随后启动 Codex，打开 /hooks，检查并信任它的两个生命周期钩子，再新建一个会话。默认模式为 full，也可以切换为 lite、ultra 或 off。

常用能力还包括：审查当前差异中过度设计的 /ponytail-review、扫描整个仓库的 /ponytail-audit，以及查看效果数据的 /ponytail-gain。在 Codex 中，这些能力以技能形式通过 @ 调用，例如 @ponytail-review。

写在最后

过去，我们担心 AI 不会写代码；现在，更现实的问题可能是：AI 太愿意写代码了。

Ponytail 提供的不是一种更聪明的语法，而是一种更稀缺的克制。真正资深的工程判断，往往不是能写出多复杂的系统，而是知道什么时候应该复用、什么时候应该删除，以及什么时候一行原生能力就已经足够。

如果 AI 编程的上半场比拼的是“能不能做出来”，下半场比拼的或许是：能不能只做必要的部分。

项目地址：

https://github.com/DietrichGebert/ponytail