Ponytail

AI 写代码，越写越多才是真问题

上周我用 Claude Code 给一个 FastAPI 项目加日期选择器，它给我装了 flatpickr，写了个 400 行的封装组件，还加了一套 CSS 主题系统。功能是有了，但我盯着那 404 行 git diff 想了半天——一个日期选择器，400 行？

这不是个别现象。AI 编码助手的核心倾向不是"写不好"，而是写太多。你让它加个搜索框，它给你写整套搜索组件库。你让它做个导出 CSV，它顺便帮你把 Excel、PDF、邮件通知都实现了。模型遵循"覆盖所有可能的需求"，但你的工单只需要一行功能。

我自己用 AI 写代码做了两个月的小云雀项目，维护到第三周就发现：不是 AI 写的代码跑不起来，是两个月后自己都看不懂。过度工程化才是真正吃掉团队时间的黑洞。

为什么这个问题值得讲

AI Coding 领域现在竞争的方向是"谁更聪明"——更长的上下文窗口、更复杂的推理链、更精准的代码生成。但很少有人讨论另一个方向：谁更克制。

一个能精准判断"这行代码根本不需要存在"的 AI，比一个能写 1000 行完美代码的 AI 更有用。因为代码的维护成本跟行数成正比，而写出来的代码里大概 30-50% 是过度工程化——该用原生能力的用了自定义实现，该用标准库的写了轮子，该跳过的功能写了"以防万一"。

这不是"AI 不够好"的问题，是 AI 的默认行为模式就有过度构建倾向。Ponytail 正是盯上了这个盲区。

我的判断

AI 编码的下一个战场不是"谁写的代码更漂亮"，而是"谁能让 AI 只写必须写的代码"。YAGNI 从来不是新概念，但把它变成 AI Agent 的强制决策链——代码生成前必须逐级判断"这个功能要不要存在"——这是第一次有人把工程纪律做成可量化、可复现的行为约束。

Ponytail 不是又一个 SKILL.md 文件合集。它是一个行为修饰器——不改 AI 的能力上限，改它的行为下限。效果不是让 AI 更聪明，是让 AI 更克制。

决策阶梯：六步判别，逐步瘦身

Ponytail 的核心是一套决策优先级链，AI 在写代码前必须逐级检查：

这个阶梯的逻辑非常干净：符合上一层就直接用，不用往下走。日期选择器这个经典案例——基线 Agent 写了 404 行自定义组件，Ponytail 在第三级"原生能力"就拦住了，直接输出 <input type="date">，23 行完事。

但关键不是"写短了"，是安全不能丢。YAGNI + 偏好单行的朴素提示词也能写短代码，但 4 次运行里有 1 次漏掉了路径遍历校验——../../ 可以跳出目录。Ponytail 的安全底线规则把这种校验锁死在决策阶梯之外，4 次运行全部安全。

实测数据：不是为了好看，是为了证伪

这份基准测试的设计目的不是"证明 Ponytail 很好"，而是证伪——有人质疑（Issue #126，Colin Eberhardt），作者就按质疑者的要求搭了测试框架。

测试环境：真实 Claude Code 无头会话编辑 FastAPI 全栈模板（tiangolo/full-stack-fastapi-template），不是裸 API 单次输出，是完整 Agent 工作流。四个对照组：基线（无技能）、Ponytail、Caveman（简洁表述对照）、YAGNI 单行提示（质疑者提出的替代方案）。每个任务 n=4，独立隔离。

这些项目不是互相替代的关系，而是互补：karpathy-skills 管"不该做什么"的底层校准，mattpocock/skills 管工程流程，addyosmani/agent-skills 管大厂规范，taste-skill 管 UI 品味。Ponytail 管的是代码体积——写出来的代码行数能不能从 400 压到 23。

但你可能会问：mattpocock/skills 也有 /caveman（省 75% token），addyosmani 也有反过度工程，karpathy 也有 Simplicity First——这不重叠吗？

不完全重叠。这些项目的"克制"是偏好级——AI 倾向于简洁，但没强制判断链。Ponytail 的"克制"是流程级——AI 在写代码前必须逐级回答六个问题，符合上层规则就不再往下走。朴素 YAGNI 提示词就是反例：效果不稳定，安全有漏洞。

怎么装、怎么跑

Claude Code 用户最简单——两行命令：

装完之后，AI 会自动在每轮会话注入决策阶梯规则。你可以手动切换强度：

/ponytail-review 和 /ponytail-audit 是我最有感的两个命令——不光管生成侧，还管存量侧。你扔给 AI 一个老仓库，它会告诉你哪些代码是过度工程化的遗物，哪些可以删掉。

不支持命令的平台（Cursor、Windsurf、Cline、Aider、Kiro、Zed）只需要复制对应的规则文件到项目目录，常驻规则自动生效，无命令功能但核心决策阶梯仍然工作。

我发现了什么

真正厉害的不是 54% 这个数字，是它怎么做到的。Ponytail 的减码不是"把 50 行压缩成 10 行"，而是"判断这 50 行里 47 行根本不该存在"。

日期选择器那个案例：基线 Agent 安装了 flatpickr 包、写封装组件、加样式表、讨论时区处理——404 行。Ponytail 的判断链走到第三级"原生能力"，发现浏览器自带 <input type="date">，直接跳到输出，23 行完事。这不是代码压缩，是决策前置。

不可简化的代码（后端 CRUD、搜索接口）减码接近 0%，说明没有夸大。能砍的砍，不能砍的不碰。

安全是真正分出胜负的地方。YAGNI 单行提示减码 33%，看起来还行，但 4 次运行里有 1 次漏掉了路径遍历校验。Ponytail 减码 54%，4 次运行全部安全。3 行路径校验逻辑就是"安全底线锁死"的具象化。

Caveman 对照组最有说服力。"请输出简洁"这个指令，代码减 20%，token 反增 7%，成本反增 3%。说明仅改输出风格不改决策逻辑，AI 会在"简洁表述"里花更多推理 token——没省到真地方。

局限也得说清楚：

减码效果高度依赖场景——前端组件开发、API 手架、数据处理 pipeline 是甜区（过度构建空间大），后端核心逻辑、已有简洁代码的仓库收益趋近 0。如果你的 Agent 本身就不太知道标准库有什么能力，决策链的上层判断就失效了——它不知道浏览器有 <input type="date">，自然不会走第三级。这个项目在 Claude 系列模型上效果最好，其他模型表现可能波动。

跟我在做的事有什么关系

我每天都在用 AI Agent 跑 GitHub AI 日报自动化——从搜索、调研、写文章、去 AI 味、保存、同步到 Obsidian，整条链都是 Agentic 工作负载。这些自动化脚本和 HTML 模板的维护成本，直接跟代码行数成正比。

前几天翻自己两个月前写的日报生成脚本，光一个"搜索 GitHub trending + 筛选 AI 项目 + 排除已评测"的函数就写了 200 行。现在用 Ponytail 的视角重新看——其实核心逻辑就 30 行，剩下 170 行全是过度工程化：冗余的 fallback、不必要的日志格式化、"以防万一"的多种排序策略。

Ponytail 给我的启发不是"装了这个技能代码就少了"，而是一种审视存量代码的新视角——/ponytail-audit 那个命令，本质上是在回答"你仓库里有多少代码是不该存在的"。这个视角我之前没有。

更远一点：AI Coding Agent 的未来不只是"谁更强"，还有"谁更克制"。我们做了三个月的日报评测，看过几十个 Agent Skills 项目——大多数都在教 AI 做更多事。Ponytail 是第一个系统地教 AI不做多余事的。这个方向会持续出现变体，因为过度工程化是 AI Agent 的默认行为模式，必须有人持续做行为修正。

我现在还没有在日报自动化脚本上装 Ponytail，原因有两个：一是脚本已经稳定运行三个月不想动，二是我的 Agent 是自己配置的工作流不是 Claude Code 直接编码。但下一个项目迭代，我会先跑 /ponytail-audit 看看存量代码有多少冗余。

GitHub: DietrichGebert/ponytail — 项目仓库

Agentic 基准测试完整报告 — 可复现的量化数据

Issue #126: Colin Eberhardt 的质疑 — 催生了这份基准测试

Agent Portability 文档 — 14 平台规则文件映射

Decision Crafters 评测 — 外部技术分析

竞品参考：andrej-karpathy-skills · mattpocock/skills · addyosmani/agent-skills · taste-skill