前阵子用 Claude Code 写博客项目，发现一个让我挺头疼的问题——AI 太"勤快"了。
让它"帮我加个缓存"，它给我写了个完整的 Cache 类，带 LRU 淘汰策略、过期时间、命中率统计。我就想给一个查询接口加个 @Cacheable 而已。
让它"加个日期选择"，它引了三个库，写了个 200 行的组件，支持农历、时区、拖拽排序。
每次都得多说一句"别搞那么复杂"，它才收敛点。但下次又忘了。
后来在 Claude Code 的社区里看到了 Ponytail 这个插件，描述就一句话："让 AI 变成懒程序员"。装上一试，体验确实不一样。
它干了什么
Ponytail 给 AI 注入了一套行为约束——写代码前先过一遍"效率阶梯"：
- 这真的需要存在吗？ —— 猜你可能需要的功能？跳过。
- 标准库能干吗？ ——
functools.lru_cache就一行，别写 Cache 类。 - 平台原生能力覆盖吗？ ——
<input type="date">能用，别引日期选择库。 - 已安装的依赖里有吗？ —— Spring Data JPA 已经给了 CRUD，别再加 Repository 实现类。
- 能一行搞定吗？ —— 一行的就别写三行。
- 实在不行 —— 写最少必要的代码。
两级能满足就取更高那级，不是让你研究，是条件反射。
说实话，大部分时候 AI 写的代码在第一级就被毙掉了——"你不需要这个"。
装之前 vs 装之后
装之前让它写个 Repository：
public interface UserRepository {
Optional<User> findById(Long id);
User save(User user);
void deleteById(Long id);
}
@Repository
public class UserRepositoryImpl implements UserRepository {
@Autowired
private JdbcTemplate jdbc;
// 30 行模板代码...
}
装之后：
@Repository
public interface UserRepository extends JpaRepository<User, Long> {
}
Spring Data JPA 已经把活干完了，接口 + 实现类全是多余的。
三条硬规则
除了阶梯，Ponytail 还定了三条规矩：
不主动抽象。 一个接口只有一个实现 → 删接口。一个工厂只生产一种产品 → 删工厂。一个值从来不改变 → 别写成配置项。
删除优于添加。 能删代码解决的问题，别加代码解决。删掉的代码不会出 bug。
无聊优于聪明。 凌晨三点被报警叫起来的时候，你不会想看到一段"精妙"的代码。
三个级别
| 级别 | 效果 |
|---|---|
full |
阶梯全开，标准库优先。默认就是这个。 |
lite |
轻量约束，建议但不强制。 |
ultra |
极致懒惰，解释都懒得给，只出代码。 |
日常开发 full 就够。写一次性脚本或者快速试东西的时候切 ultra，很爽。
实际效果：用了一个月的真实数据
上面写的都是理念，说说在这个博客项目里的实际效果。最近 Ponytail 做了一次"大扫除"，一次提交清了 628 行代码。
确实干掉了的无用代码
- 5 个完全未被引用的依赖：
pinyin-pro、jsdom、playwright、flexmark、aliyun-sdk-oss，代码里根本没有 import，不知道什么时候装上去的 - 1 个冗余依赖：
@vueuse/core，项目用的是@vueuse/nuxt，它已经把 core 都 re-export 了，单独再装是多余的 - 8 个 Service 接口：每个都只有一个 Impl 实现，Controller 直接注入 Impl 就够了，接口纯属多了一层跳转
- 350 行 mock 数据：项目早期用来写 demo 的假数据，早就没用了
- 一个 API 路径常量类：全局没一个地方引用
这些真的是 Ponytail "这个真的需要存在吗"那一问筛出来的，清得很干净。
踩的坑
但 Ponytail 太激进了，也出了两次问题：
1. 把热重载依赖删了
spring-boot-devtools 被 Ponytail 判定为"无用依赖"删掉了。这个依赖的 scope 是 runtime，打包时不参与，代码里也没有 import——但它靠 Spring Boot 的自动装配机制生效，放那儿就能用。删了之后后端改了代码不自动重启，每次都要手动停掉再跑。
事后在 pom.xml 里加了个 ⚠️ 禁止删除 注释，提醒自己和 AI 这个依赖虽然看起来"没用"，实际靠 classpath 自动激活。
2. 浏览器 API 在服务端炸了
Ponytail 在清理代码时，把一段服务端也会跑的 HTML 处理逻辑用浏览器原生 API 重写了。Node.js 里没有这些 API，文章页面直接 500。
根源是这段代码本身就绕了弯路——为了提取文章目录标题，先把 markdown 转成 HTML，再解析 HTML，最后解码实体字符。Ponytail 删了中间依赖没问题，但它选择在最后一步用浏览器 API 替代，而不是换一条不用浏览器的路。正确的修法其实是绕开 HTML 这层中间转换，直接从 markdown 原文解析标题，后面两步都不需要了。
教训
Ponytail 的方向没问题——少写代码、少依赖、少抽象——但目前的版本对两类"间接生效"的东西判断不准：
- 通过 classpath / SPI / 自动装配激活的依赖——没有 import 不等于没用
- SSR 环境差异——Node.js 和浏览器不是同一个运行时，浏览器 API 在服务端用不了
所以我现在 full 模式照开不误，但它要删依赖的时候会多看两眼——特别是 scope 是 runtime、provided 的东西，以及跟 devtools、SSR 沾边的工具库。
总体来说是利大于弊的。清掉的 600+ 行无用代码是真的不用维护了，踩的两个坑修起来也不费事，学到了就该写进 CLAUDE.md 里。