我给 AI 装了“偷懒插件”：代码少一半，安全和测试反而更好
先说一个很常见的翻车现场。
你让 AI 加一个日期选择器。它噼里啪啦写了一个自定义组件：日历、动画、主题切换、国际化，一个都不少。
而你真正需要的，可能只是浏览器原生支持的那一个：
1 | <input type="date"> |
这不是 AI 不会写，而是它默认把“能写”当成了“应该写”。
Ponytail 要解决的，就是这个问题。它不是新模型，也不是代码生成器，而是一套给 AI 编程助手用的行为规则：动手之前，先沿着“最小可行方案”往下走。
同一个日期选择器：普通 Agent 写了 335 行，Ponytail 复用项目已有组件和浏览器原生能力，只写 10 行。
项目地址：https://github.com/DietrichGebert/ponytail
本文数据核对于 2026-11-08，采用项目 README 的 v5 基准测试。实际效果会随项目、任务和模型变化。
先看结论：少写，不等于少做
作者在同一批任务上对比了“开 Ponytail”和“不开 Ponytail”的结果。测试包含 39 个任务，其中有真实的 FastAPI + React 仓库，每个任务跑 5 次。
最新 v5 基准的结果是：
- 代码量减少 53%
- 交付时间减少 41%
- 成本降低 26%
- 输出 Token 减少 45%
如果只看这些数字，很容易把它理解成“让 AI 少写点”。但真正有价值的是另一组数据：
- 高风险逻辑带测试的比例：98%，不开 Ponytail 时是 68%
- Agent 自己写的测试能抓到 66% 的注入 Bug，不开时是 46%
- 6 类安全任务、共 30 次运行全部通过
也就是说，代码确实少了一半，但验证、安全和测试没有被一起砍掉。
它到底改了什么：写代码前的 7 级梯子
Ponytail 的核心不是一句“给我写简洁点”，而是一套明确的决策顺序。
AI 在理解问题、读完相关代码之后，才允许开始选方案。它会依次问自己：
- 这东西真的需要存在吗？不需要就停。
- 代码库里已经有类似的吗？有就复用。
- 标准库能做吗？能就直接用。
- 平台原生能力能做吗？能就别重造。
- 已安装的依赖里已经有吗？有就不要再装一个。
- 能一行解决吗？能就写一行。
- 以上都不行，才允许写最小实现；如果包含分支、循环、解析、金钱或安全逻辑，还要留一个小测试。
先理解问题，再走梯子。懒的是方案，不是阅读和验证。
这套顺序看起来朴素，但它刚好补上了 AI 编程里最常见的漏洞：默认从“新增代码”开始，而不是从“现有能力”开始。
为什么不是一句“写简洁点”？
因为“简洁”这个词没有底线。
你在提示词里塞一句“少写点、简单点”，AI 确实可能少写几行。但它也可能顺手删掉路径遍历校验、输入边界检查、错误处理和可访问性支持。
Ponytail 明确划了四条红线，任何时候都不允许省：
- 信任边界上的输入校验
- 防止数据丢失的错误处理
- 安全
- 可访问性
它还把“给逻辑留测试”写进了规则里。不是所有代码都要配一套庞大测试，但分支、循环、解析器、金钱和安全逻辑，至少应该有一个小而有效的检查。
更少代码是结果，不是目标。目标是只写任务真正需要的那部分。
这也是它和“极简代码挑战”最大的区别：Ponytail 懒的是方案，不是责任。
怎么装：Claude Code 和 Codex 都能用
Ponytail 支持 Claude Code、Codex、Copilot、Cursor、Gemini CLI 等二十多个宿主。安装方式以官方 README 为准，下面是两个最常见的入口。
Claude Code
分别执行：
1 | /plugin marketplace add DietrichGebert/ponytail |
安装后默认是 full 档，开始新会话即可生效。
Codex
在终端执行：
1 | codex plugin marketplace add DietrichGebert/ponytail |
然后在 Codex 中打开 /hooks，信任它的两个生命周期 Hook，再新开一个线程。
其他 AI 编程工具
把项目里的 AGENTS.md 复制到你的项目，或者让 Agent 把 skills/ponytail/SKILL.md 安装成技能即可。Copilot、Cursor、OpenCode、Gemini 等宿主的具体步骤，官方 INSTALL.md 里都有。
只从
DietrichGebert/ponytail或 npm 的@dietrichgebert/ponytail安装。Ponytail 不会附带.exe或.dll文件。
三个最值得用的命令
装好之后，除了默认规则，我更推荐把这三个命令用起来。
/ponytail-review
不只检查“哪里能删”，还会读改动涉及的代码，检查 Bug、安全问题、真实负载下的风险、缺失测试和慢路径。
每条问题都应该说清楚：这段代码做什么、哪里会坏、怎么修、不修会怎样。
/ponytail-audit
把同一套检查扩大到整个仓库，按严重程度排序，告诉你先修什么。
它适合接手陌生项目，或者定期给老项目做一次体检。
/ponytail-debt
收集代码里刻意留下的简化点，生成一份技术债账本。
现在推荐的标记格式是：
1 | // shortcut: 只支持单文件，需要批量导入时升级 |
偷懒不可怕，可怕的是忘了自己偷过懒。把限制和升级条件写下来，之后才能用一条命令把账翻出来。
Codex CLI 里的命令会带命名空间，例如：
1 | $ponytail:ponytail-review |
怎么用才不容易翻车
Ponytail 不是“无脑砍代码”按钮。想让它发挥得好，任务描述里至少要给它三样东西：
- 目标：要解决什么问题，不是“给我写一个组件”。
- 边界：必须保留哪些行为、兼容性和安全要求。
- 验证方式：哪些测试必须跑，哪些场景不能退化。
如果你确实在做探索性原型，需要先比较几种方案，也可以明确告诉 AI：“先发散，最后再用 Ponytail 收敛到最小实现。”
它最适合已有代码库、维护型项目和 AI 生成代码越来越多的团队。因为这些场景里，真正的成本通常不是“写出第一版”，而是之后几年里持续阅读、修改和修 Bug。
最后说两句
这几年我们教 AI 的事，很多都是“写更多”：更多功能、更多抽象、更多看起来很专业的代码。
Ponytail 反着来，教它先停下来问一句：
这东西真的需要存在吗？
维护比生成贵。每多一行没人读过的代码，都是将来某个凌晨三点的 Bug 候选人。
最好的代码，是你从未写过的代码。
