小问题，大阵仗

给AI编程助手一个小任务，偶尔你会得到软件工程意义上的“雇一支施工队来挂一幅画”。比如，你只需要一个日期输入框，这个助手绝对能给你造出来。一个组件、状态管理、校验、样式、一个日期选择器依赖，说不定还要给这个依赖再包一层，因为看起来我们突然有了架构上的雄心。

打开网易新闻 查看精彩图片

与此同时，浏览器一直安静地待在角落里，它本来就有。这是AI辅助开发中一个比较有意思的失败模式：模型写代码的能力已经变得相当强，但它们并不总是同样擅长判断这段代码到底该不该存在。

“懒惰资深工程师”规则集

这个区别，正是Ponytail引起我注意的原因。Ponytail是Dietrich Gebert开发的一个开源规则集/插件，它自称要在你的AI编程助手里放进一个“懒惰的资深开发者”。它能在相当广泛的一组编程助手环境中工作，包括Claude Code、Codex、GitHub Copilot CLI、Gemini CLI、OpenCode，以及若干基于指令文件集成的环境。

这个玩笑开得不错，底下的工程思路更好。Ponytail本质上是在尝试教AI助手一件事，而这件事是资深工程师往往要付出昂贵代价才能学会的：每一行你没写的代码，都是你三年后不必调试、不必加固、不必测试、不必审查、不必升级、也不必向别人解释的一行代码。

AI助手的过度工程问题

问题不在于AI生成的代码总是很糟，如果真是那样，反而简单。让人不舒服的问题在于：代码本身可能完全合理，但创造它的决定从一开始就没有必要。要一个小功能，助手面前展开的是一个巨大的解决方案空间：创建抽象、添加依赖、创建辅助函数、创建组件、添加配置、引入接口、编写自定义解决方案。

这些选项里的大多数都能产出有效的软件，而这恰恰就是问题所在。编译器能告诉你TypeScript是否合法，测试能告诉你calculatePrice()是否返回了预期值，但两者都不会告诉你：我们当初为什么要创建AbstractPriceCalculationStrategyFactory？

资深工程的核心是“不做”

资深工程里充满了这类否定式决策。不要创建那个服务，现在还不要引入Kafka，不要因为一条查询慢就加Redis，客户端已经支持重试就不要自己写一套重试框架，两个函数恰好有四行相似代码也不要因此再引入一个抽象。还有，HTML早就解决了的问题，请不要再装38KB的JavaScript。

Ponytail试图把这个决策提前到代码生成之前，这个顺序很重要。剥掉品牌包装，Ponytail的核心机制其实非常小：在生成解决方案之前，助手会先走一遍一个层级结构，而真正的规则还加入了一个重要的限定条件。