ponytail

「什么都不做」的 AI 程序员，怎么就拿了 4 万星？

凌晨三点，一个 AI 程序员接到了任务：给网页加一个日期选择器。

它装上了 flatpickr，写了一个 React wrapper 组件，引用了样式文件，然后开始讨论时区问题——最后留下了 404 行代码。

另一个 AI 程序员接到了同样的任务。它看了两秒，说了一句：「浏览器已经有了。」然后写了 <input type="date">。

23 行。

后面这位的"思维方式"，来自一个叫 Ponytail 的开源项目——一个让 AI 程序员像「公司里那个留马尾辫的老开发」一样思考的工具：什么都不写，除非非写不可。

图1：Ponytail 项目 Logo

这个想法怎么来的？

很多开发者发现，AI 编程工具写代码的能力很强，但有一个奇怪的毛病：过度服务。你让它写一个功能，它像是在完成 KPI——能想到的依赖全加上，能预见的扩展全埋好，能抽象的逻辑全抽象。

Dietrich Gebert（项目作者）把这个叫"过度建设陷阱"（over-engineering trap）：一个简单的日期选择器，最终变成了一整套 npm 包 + React 组件 + CSS 变量 + 时区处理逻辑。

这种行为的后果很现实：更多代码 = 更多 bug 入口 = 更难维护 = 月底账单更贵。

Ponytail 的思路很简单：在 AI 真正动手之前，先问它六个问题——

1. 这东西真的需要存在吗？（YAGNI）
2. 标准库已经搞定了？
3. 平台原生 API 覆盖了？
4. 已装的依赖已经能解决？
5. 一行代码能搞定？
6. 只有以上都不行，才写最少的代码。

这六个问题形成了一个「懒惰阶梯」（Lazy Ladder），每层都比下层更懒。AI 必须在当前层级无法解决时，才允许自己爬到下一层。

图2：Agentic 基准测试（vs 无技能 baseline，Haiku 4.5）

核心能力：不是一条提示词，是一个系统

Ponytail 不仅仅是一条系统提示词。它实际上是一套多层级、自适应、可审计的 AI 编程行为框架。

三种强度模式

模式	触发命令	适用场景
Lite	/ponytail lite	适度简化，保留必要抽象
Full（默认）	/ponytail	完整阶梯：YAGNI → stdlib → 原生 → 一行
Ultra	/ponytail ultra	极限精简，删除优于添加，质疑需求本身

四大专项技能

技能	命令	功能
ponytail	/ponytail	激活懒惰模式
ponytail-review	/ponytail-review	代码审查：找出可以删除的代码
ponytail-gain	/ponytail-gain	量化收益看板：代码量↓、成本↓、速度↑
ponytail-help	/ponytail-help	速查参考卡片

基准测试数据

在真实 Claude Code 会话中，用真实开源仓库（FastAPI + React）测试了 12 个功能任务，结果：

• 代码量减少 54%（最高 94%，日期选择器从 404 行→23 行）
• Token 消耗减少 22%
• 成本降低 20%
• 执行时间减少 27%
• 安全性保持 100%（不过度简化导致安全漏洞）

对照组「YAGNI + 一行代码提示词」安全分只有 95%，ponytail 是唯一在所有指标均优化且安全满分的方案。

平台原生知识库

项目内置了一个巨大的「平台原生方案」文档，记录了大量不需要 npm 包的原生解决方案：

• CSS 的 <details> 做手风琴组件，不需要 JS 库
• Object.groupBy() 替代 lodash.groupby
• structuredClone() 替代 lodash.clonedeep
• new URLSearchParams() 替代 qs/query-string
• HTML <dialog> + showModal() 做模态框，不需要 component 库

这些知识让 AI 在「什么都不装」这个选项上更有底气。

架构设计：适配器模式驱动的 Agent 技能包

Ponytail 的架构非常清晰：核心技能 + 平台适配器。

目录结构

skills/ponytail/          # 核心技能 SKILL.md
skills/ponytail-review/   # 代码审查技能
skills/ponytail-gain/    # 收益量化技能
hooks/                    # 生命周期钩子（Node.js）
  ponytail-activate.js    # SessionStart 时激活技能
  ponytail-mode-tracker.js  # 跟踪用户命令切换模式
.claude-plugin/           # Claude Code 插件定义
.codex-plugin/            # Codex 插件定义
.opencode/                # OpenCode 插件
pi-extension/            # Pi Agent Harness 扩展
ponytail-mcp/             # MCP Server 实现

技术栈

• 核心语言：纯文本规则文件（Markdown/YAML/TOML）+ JavaScript 钩子
• 插件宿主：Node.js（v16+，用于生命周期钩子）
• 支持环境：Claude Code、Codex、OpenCode、Pi Agent、 Gemini CLI、Cursor、Windsurf、Cline、GitHub Copilot CLI、Antigravity、CodeWhale、Kiro
• 无 Python 依赖、无运行时开销——所有计算都是提示词注入

MCP Server 实现

ponytail-mcp/ 是一个 Model Context Protocol 服务器，通过 stdio 与 MCP 兼容宿主通信。它暴露两个端点：

• ponytail prompt：返回完整技能规则集
• ponytail_instructions tool：返回结构化内容 {mode, instructions}

这个 MCP server 让 Ponytail 可以接入任何 MCP 兼容的 AI 工具。

争议与局限

1. 「什么都不做」的边界在哪里？

ponytail 自己也承认：对于已经是最优解的代码，增量为零。如果 AI 已经写得很简洁了，ponytail 不会让代码变得更少——这是好事。

2. Ultra 模式的适用性

Ultra 模式甚至会质疑用户的需求本身（「这个功能真的需要吗？」）。这在生产代码中可能会引发团队摩擦——产品经理不会喜欢 AI 在代码评审时质疑需求文档。

3. 安全 vs 简洁的平衡

基准测试中，「YAGNI + one-liner」提示词组的安全分是 95%（AI 在追求简洁时跳过了输入验证）。ponytail 明确把安全、错误处理、Accessibility 放在「绝不妥协」列表里，所以这不构成实际问题，但这个列表是硬编码的，对于特定行业（医疗、金融）可能不够。

4. 对 AI 模型的要求

效果最好的模型（Haiku 4.5、Claude Sonnet 4、Opus 4）在遵循多层级指令上更可靠。低端模型可能会「跳过层级」或「在不该偷懒时偷懒」，效果打折。

5. 极度工程化的代码库

对于已经是高度抽象、分层清晰的复杂系统，ponytail 可能会给出「不要抽象」的建议，这与系统设计原则冲突。适用场景是新功能开发和代码评审，而不是重构一个已经成型的架构。

行业意义：从「AI 能写代码」到「AI 会思考代码」

Ponytail 的出现标志着 AI 编程工具的一个转折点：从「能写多少」到「该写多少」的思维升级。

这个项目提出的核心命题是：AI 编程工具最稀缺的品质不是能力，而是克制。当你给 AI 装上一个「懒惰 senior dev」思维模式，它会自动绕过 54% 的不必要代码——这不只是省 token，是省掉了未来所有维护这堆代码的人力。

从数据来看：

• 2026 年 6 月创建，两周内 4 万星
• 支持 14 种主流 AI Agent 平台
• GitHub Copilot CLI、Claude Code、Codex 三大平台官方插件市场均有收录
• 已经有公司开始在内部 AI 编程规范中引用它

一个没有一行实际代码（全是提示词文件）的项目，能在两周内拿到 4 万星，说明整个行业已经到了一个共识点：我们需要教会 AI「少写代码」。