这两天我注意到一个 Github刚看到的时候还是有点搞笑的。看到这个 readme 你第一反应是不是会想到又是哪个大聪明在恶搞。或者觉得这又是一个什么恶趣味的 Github 。其实不是这是一个正经的能帮助大家减少 Token 消耗的 Github。它的介绍是这么说的Makes your AI agent think like the laziest senior dev in the room. The best code is the code you never wrote.让你的 Agent 一样像个成熟的高级开发人员一样最好的代码就是你不写代码。你现在看到这个介绍会不会想起来你接触的高级开发他们发量有些不足有的甚至很极客带着眼镜不修边幅。他们在公司的时间比版本控制的历史还长。但是当他们坐在电脑前面的时候你用 50 行的代码被他用一行就搞定了。这个“马尾辫”老哥的形象在项目里也描述得活灵活现。Long ponytail. Oval glasses. Has been at the company longer than the version control. You show him fifty lines; he looks at them, says nothing, and replaces them with one.长马尾椭圆眼镜工龄比公司的版本控制系统还老。你给他看五十行代码他瞅一眼啥也不说反手给你换成一行。Ponytail 干的事就是把这位老哥的灵魂塞进你的 AI Agent 里。然后 Repo 给你展示了一个 benchmark 效果。我实际看了一下现在的 benchmark 测试比前两天的不一样了如果只看早期 benchmark最吸引人的数字是代码少 80%-94%成本低 42%-75%速度快 3-6 倍。现在它写的是平均少 54% 代码最高少 94%成本低 20%速度快 27%安全率 100%。很多开源项目如果拿到了一个好看的数字会恨不得把它钉死在 Readme 首页。但 Ponytail 的作者承认旧 benchmark 有问题然后重新做了一套更接近真实 Agent 使用场景的测试。这说明这个 Github 不像是一个专门用来刷数据、洗评分的 Github。不过重新做 benchmark 测试其实是有缘由的。Ponytail 一开始的 benchmark是单次生成。也就是给模型一个 prompt让它吐一段答案然后数代码行。这种 benchmark 的测试跟我们真实用 Coding Agent 的方式不太一样。真实情况里Agent 不是只在聊天框里回你一段代码。它会进项目目录看文件改代码留下一个 git diff。所以有人在 issue #126 里提出了一个质疑。单次生成里的基准线太容易“话多”模型会写解释、写注意事项、写多个方案于是最后统计“回答里的代码行数”很容易把基准线放大。还有一个更关键的问题如果只是让 Agent 少写会不会把安全校验也省掉比如路径拼接、SQL 参数、用户输入、token 校验这些东西不能因为 Ponytail 的懒得做而省略这些步骤。这个质疑确实也很合理。不过Ponytail 的作者没有忽略这个质疑他重新做了一个 agentic benchmark。这次不是单次补全这次是让真实 Claude Code session 去改一个真实开源仓库。仓库选的是tiangolo/full-stack-fastapi-template一个 FastAPI React 项目。模型是 Haiku 4.5任务是 12 个真实 feature ticket每组跑 4 次。最后统计的对象也换了直接看 Agent 留下来的git diff新增行数。而且它还加了安全任务。让生成出来的函数去跑路径穿越、SQL 注入、伪造 token、异常 CSV、配额耗尽这类对抗输入。这才像一个正常人类会关心的 benchmark。我把官方 benchmark 里的 setup 翻成中文大概是这样。整理依据Ponytail agentic benchmark。安全任务这块也可以翻成一张图。整理依据Ponytail agentic benchmark。我觉得新数据更可信了。12 个 feature task 平均下来方案代码行数tokens成本时间安全Ponytail-54%-22%-20%-27%100%caveman-20%7%3%2%100%YAGNI one-liner prompt-33%-14%-21%-30%95%这里有两个点很重要。第一个点Ponytail 不是在所有任务里都减少了 90%它在“Agent 容易过度设计”的地方容易努力过度比如日期选择器。原因很简单浏览器原生就有input typedate、input typecolor、input typefile。Agent 如果不被约束很容易自己写一套组件。Ponytail 会先问一句平台自己有没有有那就别写了。第二个点它在没什么可省的地方也不会硬省。现在它告诉你有些任务能省很多有些后端任务省不了。这就比较真实了。这个项目如何做的这个项目它不是个插件也不是个新工具它就是一套“决策规则集”。在 AI 动手写代码之前必须要先过一下他的六类核心判断这东西需要存在吗→ 不需要就直接跳过YAGNI 原则标准库能搞定吗→ 能用就用平台原生功能有吗→ 有就直接用已安装的依赖里有吗→ 有就别重复造轮子能一行搞定吗→ 就写一行以上都不行→ 才写最少量的必要代码进过这六步判断你的 Agent 根本水不了。然后这个判断下方还有一行小字这行小字容易注意到“懒惰并不是疏忽信任边界验证、数据丢失处理、安全性和可访问性永远不会被忽视”具体怎么用大家更关心的其实是它装完之后到底怎么用。我把它分成三种情况说。第一种你用 Codex 。官方 README 里把 Claude Code、Codex、GitHub Copilot CLI 的安装方式都列出来了。图源DietrichGebert/ponytail README。先在终端里加 Ponytail marketplacecodex plugin marketplaceaddDietrichGebert/ponytail codex然后进入 Codex 之后打开/plugins。选择 Ponytail marketplace安装 Ponytail。装完之后再打开/hooks。这里会看到它的两个 lifecycle hooks。不要直接闭眼信任先看一下它要做什么再点 trust。它的作用是让 Ponytail 在新 session 里自动注入规则并追踪当前模式。如果你用的是 Codex desktop app需要安装后重启一下 app。在 Codex 里一般可以这样用。普通小改动直接让它带 Ponytail 干活Use Ponytail mode for this task. 只改这个 bug优先用现有代码和标准库不要新增依赖。如果它已经给了一个很大的 diff不要着急让他继续改。可以先用ponytail-review这个命令看的不是 bug。它专门看“哪里写多了”。比如手写了标准库已有的东西、为了一个实现抽了 interface、为了一个调用者加了 factory、为了一个永远没人改的值加了 config。它最后会给你一个 delete-list。第二种你用 Claude Code。Claude Code 的安装方式/plugin marketplace add DietrichGebert/ponytail /plugin install ponytailponytail装完以后Ponytail 默认是 full 模式。你可以用/ponytail看当前状态也可以手动切图源DietrichGebert/ponytail README。一般来说 ponytail 分为下面几种模式/ponytail lite /ponytail full /ponytail ultra /ponytail offlite更像提醒。它会告诉你更懒惰一点的方案但不会强行替你决定。full是我觉得最适合日常使用的模式。它会按照上面提到的六步决策法。这是他的那条决策流程先标准库再平台原生再已有依赖最后才写代码。ultra就比较牛批了。这个模式适合那种你打开项目看到一堆 wrapper、factory、abstract class血压已经飙升的时候。但我不建议你把 ultra 当默认模式。它适合清理过度工程不适合所有开发场景。第三种你不想装插件。那就用 instruction 文件。Ponytail 的 agent portability 文档里把不同工具该放哪个文件也列出来了。图源Ponytail agent portability。比如在项目根目录放AGENTS.md。Ponytail 仓库本身就提供了一份AGENTS.md你可以复制到自己的项目里。Codex、VS Code Codex extension、CodeWhale 这类能读AGENTS.md的工具就适用于这条规则。Cursor 可以放到.cursor/rules/。Windsurf 可以放到.windsurf/rules/。Cline 可以放到.clinerules/。GitHub Copilot editor 可以放到.github/copilot-instructions.md。这种方式没有插件的模式切换和 hooks但最核心的规则能生效。对很多项目来说这已经够用了。