给AI编程助手一个看似简单的任务，它常常会给出一套过度庞大的解决方案。举个常见例子：只需要一个日期输入框，助手可能会生成一个完整的组件、状态管理、校验逻辑、样式、一个日期选择器依赖，甚至为这个依赖再包一层封装——好像突然需要一套架构体系。与此同时，浏览器自带的输入控件往往已经能满足需求，这种“为小事动用大工程”的倾向是AI辅助开发中的一种明显失误模式。

问题并非AI写不出正确代码，而是它们不总能判断出某段代码是否本就应存在。模型能生成语法正确、能通过测试的实现，但很难辨别：我们真的需要为这件事创建新的抽象、引入第三方依赖或搭建额外的服务吗？编译器会告诉你类型正确，测试会验证功能，但没人会告诉你当初为什么要多出那个 AbstractPriceCalculationStrategyFactory。

Ponytail 是由 Dietrich Gebert 开发的一个开源规则集/插件，目标就是把“懒惰又有经验的工程师”的思路塞进你的AI助手里。它可在多种AI代码环境中工作（如一些主流的代码模型和CLI集成环境），本质上是把资深工程师那种“多写一行代码，就多了一行未来要维护的负担”的直觉提前到代码生成之前。

资深工程师常做的不是创造复杂方案，而是谨慎选择不做：不要在早期就引入新的服务或消息队列，不要因为一条慢查询就马上加缓存，不要为两处短小重复代码马上抽象出一套框架，不要重复实现浏览器已经解决的功能。每一行不必要的代码都会带来未来的调试、测试、审查、升级与解释成本。

Ponytail 的关键思想很精简：在实际生成代码前，先让助手沿着一个决策层级检查可能的操作，并在此基础上施加约束。规则倾向于优先选择更简单、直接、基于现有平台能力的方案，只有在确有必要并能说明理由时才允许引入新依赖、新抽象或额外文件。换言之，它把“能不做就不做”的判断当作第一步，而不是事后补救的想法。

把“不做”作为默认决策会显著减少未来维护负担，也更符合成熟工程实践。让AI学会在生成代码前先问一句“这段代码真的必要吗？”比修复一堆冗余实现要划算得多。像 Ponytail 这样的规则集，虽小却切中要害：把经验丰富工程师的否定式决策形式化，帮助手续性地避免那些本不该存在的代码。