跳到主要内容
中文
English en 中文 zh-CN
GitHub
给正在用 AI agent 写代码的人

别让 AI agent
 把小需求写成一套小框架

Ponytail Skill 会在 agent 动手前先拦一下：标准库能不能做？浏览器原生有没有？项目里是不是已经有依赖？都不行，再写最小的安全实现。

复制安装命令 看前后对比
-54% benchmark 新增行
-22% token 使用
100% 安全评分
1
规则：先检查再动手
4
AI 最爱多写的地方
30s
选工具复制命令
0
不用发明新流程

把它放到你已经在用的 agent 工作流里。

Claude Code
Codex
OpenCode
Gemini CLI
Copilot
Cline
问题

AI 写多了，通常不是因为笨，而是太积极

它很容易把一个小需求，顺手扩成组件、依赖、配置和一堆没人愿意 review 的文件。

浏览器明明有，它还要封一层

日期、开关、选择框、弹窗：平台已经给了，就先别急着造组件。

一行代码的事，它想先装个包

先看标准库、运行时 API 和项目里已有依赖，再决定要不要加新东西。

只有一个调用方，也要先抽象

接口、适配器、工厂、配置层都不是不能写，但得证明现在就需要。

diff 大到 reviewer 只想关掉

目标不是代码越短越好，而是改动小到别人愿意认真看。

安装命令

选你的工具，复制命令

下面不是编出来的一键安装脚本，都是 Ponytail 仓库里真实支持的安装方式。

text 
/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytail

在 Claude Code 里直接运行。桌面 App 没有 /plugin 命令，要走插件 UI。

打开 README
bash 
codex plugin marketplace add DietrichGebert/ponytail
codex

运行后打开 /plugins 安装 Ponytail，再到 /hooks 看一眼并信任 hooks。

打开 README
bash 
copilot plugin marketplace add DietrichGebert/ponytail
copilot plugin install ponytail@ponytail

Copilot CLI 会按 plugin 名称给命令加 namespace，例如 /ponytail:ponytail-review。

打开 README
markdown 
把 Ponytail 作为项目级常驻规则：

- 写代码前先检查：标准库、原生平台能力、已安装依赖、一行方案。
- 只有这些都不适合时，才写最小但安全的实现。
- 绝不删掉验证、错误处理、安全、可访问性和必要的冒烟测试。

适合还不支持 Ponytail plugin、但会读项目指令文件的 agent。

查看适配文档
安装

先看它支不支持你的工具

不要为一个 skill 发明新流程。把它放进你的 coding assistant 已经会读的地方。

Claude Code

安装 skill 和 hooks，让 Claude Code 每次开工前都能看到这条决策梯子。

Agent

Codex CLI

把规则放进 agent 指令，贴合终端里的编程流程。

Agent

OpenCode

走已有适配路径，而不是手写一份 prompt。

Agent

Gemini CLI

在 Gemini 编程流程里复用同一套 Ponytail 规则。

Agent

GitHub Copilot

放进编辑器会读取的指令文件，尽量沿用原生 assistant 工作流。

编辑器

Cline

加入代码助手能读取的项目级规则。

编辑器

Benchmarks

先看方法，再相信标题数字。

证据

Git diff

用它留下的代码判断效果，而不是用自信的解释判断。

证据

找一个 agent 平时容易写多的任务，装上后直接对比 diff。

打开安装说明
前后对比

它到底会少写什么？

不是让 agent 少解释几句，而是让它在动手前先问：这东西真的需要存在吗？

没有 Ponytail Skill

  • 先写一个 DatePicker 组件
  • 再补状态 helper、解析工具和 wrapper 样式
  • 顺手引一个 UI 依赖
  • 最后为了一个表单字段留下多文件 diff

使用 Ponytail Skill

  • 先试 <input type="date">
  • 保留验证和可访问性标签
  • 复用已有表单样式和浏览器行为
  • 只留下一个小 diff，再写清什么时候该升级
工作方式

它怎么管住 agent？先过三道坎

每次 agent 想造东西时，Ponytail Skill 都让它先走一遍很无聊、但很管用的检查。

1

这东西要不要存在？

当前任务不需要的选项、wrapper 或子系统，就先别建。

2

平台是不是已经给了？

标准库、浏览器原生能力、项目已有依赖，都排在新代码前面。

3

最后才写最小安全实现

验证、错误处理、可访问性、安全和必要的冒烟测试，仍然要保留。

工作流

不只是写代码时有用，review 时也能用

Ponytail Skill 最有价值的地方，是把这套判断变成 agent 的固定习惯，而不是临时喊一句“少写点”。

拒绝脑补需求

当前任务不需要的东西，agent 就不应该先搭起来。

优先无聊原语

已有平台能力，通常比聪明的小框架更可靠。

保留护栏

小实现不等于可以不安全、不可访问、没测试。

够清楚就停

如果 diff 已经容易 review，就别继续表演。

写代码

实现模式会在 agent 创建文件、安装依赖之前，先套一遍决策梯子。

安装 skill
Benchmark

看它留下的 diff，不看它说得多自信

benchmark 跑的是隔离的 Claude Code 会话，目标仓库固定，最后统计真正落到仓库里的 git diff。

指标
无 skill 基线
Caveman 短文风
推荐 Ponytail 决策梯子
新增 LOC 100% -20% -54%
token 使用 100% +7% -22%
运行成本 100% +3% -20%
耗时 100% +2% -27%
安全评分 100% 100% 100%
阅读方法 查看对照 安装
证据文章

先看方法，再看数字

数字不难写，难的是说明它到底测了什么、没测什么。

打开基准测试目录
FAQ

几个容易被误解的点

Ponytail Skill 很小，所以话不能说满。

这只是“少写点代码”的 prompt 吗？

不是。benchmark 里专门放了短文风对照组，结果不一样。Ponytail Skill 管的是决策顺序，不是说话风格。

会不会让 agent 把安全代码也删了？

不会。它明确保护验证、错误处理、可访问性、安全和必要的冒烟测试。安全 benchmark 仍然是 100%。

每个项目都能少写 54% 吗？

不能。这是 benchmark 均值，不是通用承诺。收益最大的时候，是 agent 原本会过度设计的时候。

它怎么和 AGENTS.md 共存？

把 Ponytail Skill 当成现有 agent 指令里的一条聚焦规则。项目自己的规则仍然优先。