别再让AI写那么多代码了

别再让 AI 写那么多代码了

哈喽，大家好，我是阿亮。

这篇聊一个把 Coding Agent 从“勤快写代码”拉回“少写正确代码”的 GitHub 项目，叫 Ponytail。

它解决的不是模型智商问题，而是一个更日常的工程问题：AI 太容易把一个简单需求写成一坨实现。

你让它做日期选择器，它会倾向于拉组件库、写 wrapper、补样式、再顺手讨论时区。Ponytail 的第一反应很朴素：浏览器不是已经有 <input type="date"> 了吗？

项目地址：https://github.com/DietrichGebert/ponytail

截至 2026-06-22，这个仓库已经有 48.3K Star、2.4K Fork，最新 release 是 2026-06-16 的 v4.7.0，MIT License。这个热度说明一件事：大家确实开始被 AI 写出来的“过度工程”折磨了。

先说结论：Ponytail 不是代码生成器，也不是新的聊天框。

它更像给 Claude Code、Codex、Cursor、Windsurf、Gemini CLI、OpenCode、GitHub Copilot 等 coding agent 加了一层工程习惯：写代码前先过一把“资深工程师的懒人梯子”。

这把梯子大概是这样：

这件事真的需要做吗？
标准库已经有了吗？
平台原生能力能解决吗？
现有依赖已经覆盖了吗？
能不能一行解决？
最后，才写最小可用实现。

注意，它强调的是 lazy，不是 careless。

输入校验、数据丢失保护、安全边界、无障碍这些不能省。真正该省的是没人要求的抽象、只服务一个实现的接口、为了“以后可能会用”提前搭的架子、为了小需求安装的大依赖。

想来想去，Ponytail 最值得看的就是一句话：

很多时候，AI 写代码真正贵的不是 token，而是它把不该存在的复杂度带进了你的项目。

好，那它到底能带来什么？

项目自己给了一组比较硬的 benchmark：让同一个 Claude Code agent 在真实 FastAPI + React 项目里做 12 个 feature ticket，对比无 skill、Ponytail、短话风格控制组，以及一句简单的 YAGNI one-liner prompt。

结果很有意思。

在有明显过度构建空间的任务里，Ponytail 压得非常狠。日期选择器从 404 行压到 23 行，颜色选择器从 287 行压到 23 行，文件上传 dropzone 从 251 行压到 95 行。整体 feature 任务里，Ponytail 的新增 LOC 少了 54%，token 少了 22%，成本少了 20%，时间少了 27%。

这里最关键的不是“少了多少行”，而是它为什么少。

日期选择器和颜色选择器这类任务，平台已经有答案了。AI 如果没有约束，很容易从“做一个日期选择”理解成“实现一个日期选择组件”。Ponytail 把问题重新拉回去：用户要的是能力，不是组件。

这就是它对产品、运营、创作者也有价值的地方。

你不是每天都要写系统架构，但你每天都在让 AI 改页面、写脚本、整理数据、补后台小功能。普通人用 AI 编程最容易踩的坑，不是 AI 不会写，而是 AI 太会写。它会把你临时想验证的小需求，写成一个你以后要维护的小系统。

比如一个活动页只需要收集日期，原生日期输入够用。

比如一个内部脚本只要把 CSV 加总，三行就够，不需要造一套文件处理框架。

比如你只是想在后台加一个搜索标题的入口，直接查字段就能交付，不需要提前铺一个“可扩展搜索服务”。

Ponytail 的价值，不是替你写得更炫，而是提醒 Agent：先别炫。

这件事放到 AI 时代尤其重要。

过去一个初级开发者过度设计，还会被代码量、时间、review 卡住。现在有了 coding agent，复杂度生成的成本突然变低了。一个人一天可以制造过去一周的代码量，坏消息是，其中很多代码本来就不该存在。

所以我倾向于把 Ponytail 看成一个 AI 工作流里的刹车片。

它不负责让模型更聪明，它负责让模型更少把聪明用错地方。

从使用方式看，它做得也很像一个“跨 Agent 分发包”，而不是单个平台插件。

在 Claude Code 里可以走 plugin marketplace：

/plugin marketplace add DietrichGebert/ponytail/plugin install ponytail@ponytail

在 Codex 里是：

codex plugin marketplace add DietrichGebert/ponytailcodex

然后进入 /plugins 安装 Ponytail，再到 /hooks 里审查并信任它的生命周期 hooks。

它还提供了多种轻重模式：lite、full、ultra、off。默认是 full，也就是认真执行那套“先不做、先用已有能力、最后才写代码”的梯子。

更实用的是几个命令：

/ponytail-review 看当前 diff 里哪些地方过度工程。

/ponytail-audit 扫整个代码库，找可以删除、缩短、替换成标准库或原生能力的地方。

/ponytail-debt 把那些带 ponytail: 标记的临时简化点收成一张账，防止“以后再说”真的变成永远不管。

/ponytail-gain 展示 benchmark 里的收益，不把当前项目的收益乱算成一个不存在的数字。

这几个命令说明它不是单纯的 prompt 包。它在试着把“别过度设计”变成可执行的工程流程。

真正适合怎么用？

第一种场景，是你让 Agent 做小功能。

你可以先让 Ponytail 模式开着，只让它交付最小正确版本。等功能跑通，再决定要不要补更多交互、配置、抽象和兼容。这个顺序很重要：先证明需求存在，再让复杂度进场。

第二种场景，是你做代码 review。

很多 AI 生成代码看起来“完成度很高”，其实里面塞了很多没人会用的扩展点。Ponytail-review 这种删除导向的 review，能把问题问得更尖：这个类有没有第二个实现？这个配置有没有第二个值？这个依赖是不是标准库已经能做？

第三种场景，是你在做 AI 编程学习。

新手最容易被 AI 的长答案带偏，以为“写得多”就是“考虑周全”。Ponytail 提供的反向训练很有价值：先学会识别哪些代码不用写，再学怎么写。

但别把它神化。

Ponytail 最适合的是那些容易过度构建的任务：表单控件、小工具函数、后台 CRUD、脚本、轻量交互、已有平台能力能覆盖的问题。

如果你的需求本身就复杂，比如权限系统、支付、审计、数据迁移、多人协作状态、强安全边界，它不会把复杂问题变简单。它只能提醒 Agent 不要额外加戏。该做的校验、错误处理和测试，仍然要做。

还有一个现实限制：不同 Agent 对 plugin、skill、hooks 的支持程度不一样。Claude Code、Codex 这类入口可以获得更完整的模式切换和生命周期 hooks；Cursor、Windsurf、Cline、Kiro 这类更多是加载规则文件。体验会跟宿主平台有关。

它也非常新，安装适配还在快速变动。真要装进日常工作流，优先按最新仓库说明来，不要照搬旧教程。

再就是团队使用时要先小流量试。

“少写代码”听起来永远正确，但你的团队可能已经有组件规范、浏览器兼容要求、设计系统约束、审计要求。Ponytail 可以帮你挡住无意义复杂度，不能替你判断所有业务边界。

我的建议很简单：

如果你经常用 coding agent 写前端小组件、后台小功能、数据脚本，Ponytail 值得装。

如果你正在带新人用 AI 写代码，更值得装。它会持续灌输一个比“多问 AI”更重要的习惯：先问这段代码有没有必要存在。

最后留一句话：

AI 时代，真正稀缺的不是生成能力，而是克制生成的能力。