上上周一个午后，我在重构一个文件搜索 MCP Server 的代码。这事本来不应该花太多时间——一个查文件列表的工具，核心逻辑不到 50 行。但当我打开那个文件的时候，发现它不知不觉长到了 480 行。接口文件、抽象基类、配置绑定、依赖注入、错误码枚举、日志级别常量、超时策略配置类、缓存策略接口、还有三个不同版本的文件搜索实现类——有的是我亲手让 Claude 写的，有的是我自己加的，有的是 Claude 看到我加了一个类后主动建议"要不要抽一个基类"然后我点了同意。每一个改动单独看都没问题。叠加在一起，一个 50 行的工具变成了一锅连自己都不想碰的意大利面。这种感受你有过吗？用 AI 编程工具写代码，一开始很爽。你提需求，模型生成代码，你测试通过就提交。几个轮次下来，功能确实实现了，但打开仓库一看，能读的代码越来越少。你不敢重构，因为代码不是你逐行写的，你不知道哪些抽象是真的为了扩展性，哪些只是一次生成时的顺带产物。然后你安慰自己：先跑起来再说。直到我发现了 Ponytail。说出来你可能不信，这个在 GitHub 上发布才 14 天、已经飙到 82K Stars 的开源项目，做了一件非常简单的事：盯着你的 AI 生成的代码，找出那些过度工程的部分，然后建议你删掉。没有花哨的架构，没有封装成 SaaS 平台，甚至没有独立的 GUI——就是一个 Claude Code 的插件，加上在其他编辑器里的适配器。但它在 GitHub 上一天涨五六千 Stars，因为每个被 AI 代码产出量吓到的开发者看到它，第一反应都是——终于有人干这事了。Ponytail 的核心逻辑用一句话就能说清楚：在 AI 生成的代码被合并之前，用一套预定义的规则审查它，标记出不必要的抽象、多余的配置、过早的优化、以及那些"以防万一"加上的代码。它不阻止你写代码，它只在你提交之前给你一份"你真的需要这 200 行吗"的报告。项目的创建者 Dietrich Gebert 是一个在德国做后端开发的工程师。他在 GitHub 上发布 Ponytail 时写的 Readme 只有两段话，其中一句是这么说的：「AI 模型正在以越来越快的速度生成代码，但它们不会帮你维护。生成时省下的时间，会在代码审