AI编程助手的最大问题在于生成多余代码而非错误代码

给AI编程助手一个简单的任务，你可能会发现它的反应过于夸张，就像“请一支建筑队来挂一幅画”。假设你只需要一个简单的日期输入框，它可能会为你设计出一个复杂的解决方案，包括组件、状态管理、验证、样式，甚至引入一个日期选择器依赖，并且可能还会在这基础上加上一层封装，让这个需求变得过于复杂。而实际上，这个日期输入框在浏览器中本身就已经有了，直接可以使用。这是AI编程助手在开发过程中暴露出的一个有趣的失败模式：尽管模型生成代码的能力增强了，但它不一定能够判断所生成的代码是否真的有必要。

引起我关注的是Ponytail，这是一套由Dietrich Gebert开发的开源规则集，它试图在你的AI编程助手中引入一种“懒惰的资深工程师”的思维方式。Ponytail能够在多种编程助手环境中运行，包括Claude Code、Codex、GitHub Copilot CLI、Gemini CLI和OpenCode等。这背后的理念非常有趣，Ponytail的目标是教AI助手一个重要的概念：每一行没有写的代码，都意味着将来不需要调试、不需要加固、不必测试、不必审查、不必升级，也不必向他人解释的那一行代码。

AI助手的过度工程现象并不在于生成的代码总是糟糕，其实真实的问题在于，虽然代码本身可能是合理的，但从一开始生成这些代码的决策就是不必要的。当你请求一个简单的功能时，助手呈现的往往是一个复杂的解决方案空间：创建抽象、添加依赖、编写辅助函数、生成组件、进行配置、引入接口、编写自定义解决方案等。这些选择几乎都可以生成有效的软件，这正是问题所在。尽管编译器能够判断TypeScript语法是否正确，测试也能确认calculatePrice()是否返回期望值，但它们无法回答一个更基础的问题：当初为什么要创建AbstractPriceCalculationStrategyFactory这个抽象类？

资深工程师的工作常常涉及这类否定性的决策。他们会选择不建立某些服务，避免引入Kafka，不因查询慢而栽引Redis，知道客户端支持重试时就不再开发重试框架，甚至对于两个函数之间相似四行代码，也不轻易创建额外的抽象。更不用提HTML已经能够解决的问题，绝对不应该再引入一个38KB的JavaScript库。Ponytail的目标在于将这种决策过程提前到代码生成之前，这一顺序是关键。简化来看，Ponytail的核心机制非常简单：在生成解决方案之前，它会先检查一个层级结构，并添加重要的限制条件。