Ponytail — 让 AI Agent 像慵懒资深工程师一样写极简代码¶

AI 编程的最大陷阱不是"写不出代码"，而是"写得太多"。Ponytail 用一个核心理念对抗这种倾向：代码不是资产，代码是负债。（Code is liability, not asset）

AI 编程的"代码腐化"问题¶

当前 AI 编程 Agent 的核心痛点：过度工程（Over-engineering）。

一个 5 行代码能解决的问题，AI Agent 动辄生成 500 行"屎山代码"——多余依赖、过度封装、不必要的抽象层、冗长注释。表现欲爆棚的新手和 AI Agent 的行为惊人相似。

用户需求：日期选择器
─────────────────────────────────
❌ 无约束 AI 行为：
   安装 flatpickr → 写 wrapper 组件 → 加样式表 → 讨论 timezone
   产出：~200 行代码 + 1 个新依赖

✅ Ponytail 约束后：
   <input type="date">
   产出：1 行代码，零依赖

这种"代码腐化"在 Code Review 中造成巨大负担，尤其在企业级工程中。

Ponytail 核心架构：六步阶梯法则¶

Ponytail 的本质是一套决策阶梯（Decision Ladder）——在写任何代码之前，强制 Agent 逐级向上攀登：

┌─────────────────────────────────────────┐
│     写代码前的六步决策阶梯               │
├─────────────────────────────────────────┤
│                                         │
│  Step 1: 这东西需要存在吗？              │
│     └─ NO → YAGNI，跳过（不写）         │
│         └─ YES ↓                        │
│                                         │
│  Step 2: 标准库能做吗？                  │
│     └─ YES → 用标准库                   │
│         └─ NO ↓                        │
│                                         │
│  Step 3: 平台原生特性能做吗？             │
│     └─ YES → 用原生 API                 │
│         └─ NO ↓                        │
│                                         │
│  Step 4: 已安装的依赖能做吗？             │
│     └─ YES → 复用现有依赖               │
│         └─ NO ↓                        │
│                                         │
│  Step 5: 一行代码能解决吗？             │
│     └─ YES → 写一行                     │
│         └─ NO ↓                        │
│                                         │
│  Step 6: 才写"能工作的最小实现"          │
│                                         │
└─────────────────────────────────────────┘

关键原则：慵懒，但不失职（Lazy, not negligent）

每条"偷懒"路径用 ponytail: 注释标记升级路径：

# ponytail:upgrade — add timezone support when i18n needed
import datetime
now = datetime.datetime.now().isoformat()

性能数据与 Benchmark 分析¶

官方声称（5 个日常任务 × 3 个模型 × 10 次运行）¶

Benchmark 批判（Scott Logic 分析）¶

Scott Logic CTO Colin Eberhardt 的深度分析揭示了 Benchmark 设计的重大缺陷：

1. 测试任务过于简单

"tasks": [
  { "id": "email", "prompt": "写一个 Python 邮箱验证函数" },
  { "id": "debounce", "prompt": "给搜索框加防抖" },
  { "id": "csv-sum", "prompt": "读取 CSV 并求和" },
  { "id": "react-countdown", "prompt": "React 倒计时组件" },
  { "id": "rate-limit", "prompt": "给 FastAPI 加限流" }
]

每个任务约 10 行代码——无法反映真实 Claude Code 使用场景。

2. 基准线不公平

基线对比把 Agent 的所有对话输出（多方案讨论、注释、使用示例）都算入 LOC，人为膨胀了基线数字。

3. 7 个字打败 Ponytail

"Follow YAGNI principles, and one-liner solutions." — 7 个英文单词，LOC 更低，且正确率 100%。

4. 有测试用例本身就是坏的

"debounce" 任务反复失败——它假设 document 对象存在（Node.js 测试环境无 DOM）。

本质是什么¶

Ponytail 的实际"逻辑"是约 100 行 Markdown，核心就是 1990 年代的 YAGNI 原则。整个仓库 90 个文件、6232 行代码，但有效内容就是那个规则文件。

"Is this the new leftpad?" — Hacker News 评论

安装与使用¶

支持的 Agent 平台¶

三种强度模式¶

关键命令¶

判断决策树：什么时候该用这类约束？¶

AI 写代码过于臃肿？
│
├─ 简单任务（<50 行）
│   └─ 直接在 prompt 中加 "Follow YAGNI, prefer one-liner solutions"
│       → 7 个字就够，不需要装插件
│
├─ 日常开发（中等复杂度）
│   └─ Ponytail full 模式有参考价值
│       → 但关键是 prompt 工程素养，不是依赖插件
│
├─ 企业级 / 生产环境
│   └─ ultra 模式 + ponytail-review 命令
│       → 结合团队 Code Review 规范使用
│
└─ 复杂架构设计（>1000 行）
    └─ Ponytail 类工具帮助有限
        → 需要 AI Agent 有足够的架构理解能力
        → 过度简化可能导致欠工程（Under-engineering）

最佳实践清单¶

• ✅ 在 prompt 中明确要求 YAGNI 原则
• ✅ 要求 AI 先输出方案对比再写代码（思考优先）
• ✅ Code Review 时检查不必要的依赖引入
• ❌ 不要盲目信任 Skill 的 Benchmark 数据
• ❌ 不要在复杂架构场景中过度简化

相关项目¶

Scott Logic 指出两个仓库结构高度相似，怀疑 Ponytail 是用 Claude Code 指向 Caveman 仓库生成的。

参考资料¶

• Ponytail GitHub 仓库 — 项目主页
• Ponytail, YAGNI, and the Problem with Prompt Benchmarks — Scott Logic 深度批判分析
• Reddit: I gave Claude Code a "lazy senior dev" mode — 作者原始讨论帖
• Hacker News 讨论 — 技术社区讨论

相关笔记¶