我第一次看到 ponytail 的介绍时，脑子里冒出的不是“又一个 AI 编程插件”，而是一个很熟悉的画面：

你让 AI 帮你加一个日期选择器。它沉思三秒，然后开始安装依赖、封装组件、写样式、处理时区、加类型、补测试，最后给你一个看起来很专业的方案。

但你真正需要的，可能只是这一行：

<input type="date">

这就是 AI 编程时代最荒诞的日常：我们终于有了一个不知疲倦的初级工程师，但它太勤快了。

勤快到一个 5 行需求能变成 200 行代码。勤快到它会主动替你设计“未来可能用到”的扩展点。勤快到你看 diff 时突然怀疑：到底是它在帮我省时间，还是我在帮它做 code review？

ponytail 有意思的地方就在这里。它不是教 AI 写更多代码，不是让 Agent 更强、更复杂、更自动化，而是反过来给 AI 套上一条“工程克制”的缰绳：

别急着写。先问：这东西真的需要存在吗？

AI 编程助手最大的问题，不是不会写，而是太会写

过去我们担心 AI 写不出代码。现在问题反过来了：它写得太多。

尤其是 Claude Code、Cursor、Codex 这类 Agent 工具进入日常开发后，一个典型流程变成了这样：你输入需求，它读文件、搜上下文、推理方案、改代码、跑命令、再修补。表面上看，这是自动化的天堂；可落到工程里，经常会出现一种“代码通胀”。

一个按钮状态，本来改一行判断就够；AI 新建了一个 hook。

一个格式化逻辑，本来标准库能处理；AI 手写了一个 parser。

一个简单表单，本来浏览器原生控件能解决；AI 引入组件库，再封装一层设计系统适配。

它这么做不是因为坏，而是因为大模型的默认倾向就是“补全一个看起来完整的答案”。它学过太多教程、模板、最佳实践、框架样板。对它来说，“专业”常常等于“结构完整”；“结构完整”又常常变成“抽象过度”。

这在人类程序员身上也常见，只是 AI 把速度拉满了。

人类过度工程，可能半天写 300 行。AI 过度工程，可能 30 秒写 300 行。痛苦没有消失，只是变成了 diff。

ponytail 是什么：把“懒得多写一行代码”的老程序员塞进 Agent

ponytail 的 GitHub 项目描述很直白：

Makes your AI agent think like the laziest senior dev in the room. The best code is the code you never wrote.

翻成中文大概是：让你的 AI Agent 像房间里最懒的资深程序员一样思考。最好的代码，是你从没写过的代码。

这里的“懒”不是敷衍，也不是摆烂，而是一种老工程师才有的肌肉记忆：

• 能不做，就不做；
• 能复用，就不重写；
• 标准库能解决，就别造轮子；
• 平台原生能力能覆盖，就别引依赖；
• 一行能表达，就别铺十行；
• 真要写，也只写刚好够用的那部分。

ponytail 把这套判断做成了一个 AI 编程技能包。它可以用于 Claude Code、Codex、Cursor、Copilot 等多个 Agent 环境。项目本身并不庞大：核心是规则、提示和生命周期 hook。真正重要的不是代码量，而是它植入 Agent 脑子里的那条“最小可行阶梯”。

它的规则阶梯大概是这样：

1. 这个东西真的需要存在吗？不需要就跳过。
2. 代码库里已经有了吗？有就复用。
3. 标准库能做吗？能就用标准库。
4. 原生平台能力能覆盖吗？能就用原生能力。
5. 已安装依赖能解决吗？能就复用现有依赖。
6. 一行能写完吗？能就一行。
7. 到这里才写最少的新代码。

这套顺序很关键。

很多人理解“少写代码”，会直接跳到“一行流”或者“代码高尔夫”。ponytail 不是这个意思。它强调的是：先理解问题，再选择最少的实现路径。

懒，不等于不读代码；懒，是读完以后不乱写代码。

这也是它和普通 “YAGNI + one-liner” 提示词最大的区别。单纯告诉模型“尽量一行写完”，很容易把安全校验、错误处理、边界判断一起砍掉。ponytail 明确说，不能砍掉信任边界的输入校验、避免数据丢失的错误处理、安全措施、可访问性基础，以及用户明确要求的东西。

这句话是灵魂：Lazy, not negligent. 懒，但不粗心。

那些数字要怎么看：54% 少代码，不是魔法，是少造轮子

ponytail 官方给了一组很醒目的数字：在真实 Claude Code session 中，处理一个真实开源项目 tiangolo/full-stack-fastapi-template 的 12 个 feature ticket，对比没有技能的 baseline，结果是：

这组数据很诱人，但要读得诚实一点。

它不是说任何任务都能神奇减少 54% 代码。官方自己也承认：收益主要发生在“有过度构建陷阱”的任务上。

比如日期选择器，baseline 可能写出 404 行，ponytail 最后只留下 23 行，因为它选择了浏览器原生的 <input type="date">。颜色选择器也是类似，baseline 287 行，ponytail 23 行，因为浏览器本来就有 <input type="color">。

这不是模型突然变聪明了，而是它终于想起来：平台已经替你做了很多事。

更有意思的是，在那些本来就没有多少压缩空间的后端 CRUD 任务里，差距会迅速缩小。比如“按 title 搜索 item”这类任务，各组结果几乎差不多。因为该写的查询就是得写，业务逻辑没有凭空消失。

所以 ponytail 的价值，不在“所有代码都减半”，而在“识别哪些代码本来就不该被写出来”。

这和真实工程经验非常一致。一个好 senior engineer 的价值，并不是每次都能把 100 行压成 10 行，而是能在开工前看出：这 100 行根本不该存在。

为什么普通提示词不够：少写代码和少做工程是两回事

有人可能会问：这不就是在 system prompt 里写一句 “Follow YAGNI principles, and prefer one-liner solutions” 吗？

ponytail 的基准测试刚好做了这个对照。

结果很有意思：这个简单提示词确实能少写不少代码，甚至在某些任务上很快。但它有一个问题：不稳定，而且容易把不该省的东西也省掉。

官方安全测试里，有一类任务是处理不可信文件路径。最短写法当然可以很短，但如果你漏掉 ../../ 这种路径穿越检查，代码就从“简洁”变成“漏洞”。

在这组测试里，YAGNI + one-liners 有一次把路径安全 guard 砍掉了，安全率是 95%；ponytail 保留了大约 3 行额外检查，安全率 100%。

这就是“偷懒”和“乱省”的分界线。

真正成熟的工程克制，不是看到代码就删，而是知道哪些东西不能删：

• 用户输入校验不能删；
• 权限检查不能删；
• 数据丢失保护不能删；
• 可访问性基础不能删；
• 明确业务规则不能删；
• 能让未来排查问题的最小日志不能删。

能删的是另一类东西：

• 为一个实现写接口；
• 为一个常量写配置系统；
• 为一个页面状态写全局 store；
• 为一个原生控件引组件库；
• 为一个临时需求搭“未来架构”；
• 为了显得专业而存在的样板代码。

这两类东西，在代码行数上看都叫“多写了”；但在工程价值上完全不同。

ponytail 想训练 AI 分清它们。

我为什么觉得这个方向值得写：AI 时代的稀缺品变成了克制

这几年 AI 编程工具的发展路线，大多是在追求“更能干”：更长上下文、更强 agent、更自动化的工具调用、更复杂的多 Agent 协作。

但用久了你会发现，很多场景的瓶颈不是 AI 不够强，而是它太愿意行动。

它会在没有问清楚之前改文件；会在一个局部 bug 上做全局重构；会为了一个错误提示顺手升级依赖；会把“修这个问题”理解成“顺便整理这个模块”。

这时候你需要的不是更强的 AI，而是一个会说“不值得”的 AI。

ponytail 最打动我的地方，不是 54% 这个数字，而是它把一个传统工程文化重新塞回了 AI 工作流：

写代码是成本，不写代码也是能力。

过去这句话主要用来说服年轻程序员。现在它开始用来说服模型。

而且 AI 比人类更需要这条规则。人类写多了会累，AI 不会。人类过度设计时还有同事拦一下，AI 在工具链里经常是一路绿灯。你让它跑，它就跑；你让它改，它就改；你不限制，它就把“完整方案”铺满屏幕。

所以在 Agent 工程里，类似 ponytail 的技能会越来越重要。它们不是增强模型能力，而是修正模型的默认冲动。

适合谁用：不是所有团队都该立刻装，但所有人都该学这套判断

我不会把 ponytail 说成“必装神器”。原因很简单：任何规则一旦进入 Agent 的系统层，都会改变它的行为偏好。你得知道自己要什么。

如果你现在处在探索原型阶段，需要 AI 大胆展开、给多个方案、快速铺工程骨架，ponytail 可能会显得太克制。你让它搭房子，它可能先问：真的需要二楼吗？

但如果你已经进入维护期，代码库越来越大，AI 每次改动都容易牵出一串文件，那 ponytail 很适合。

尤其适合这些场景：

• 老项目小修小补，不希望 AI 顺手重构；
• 后台管理系统，很多需求其实 CRUD 就够；
• 前端页面，原生控件和 CSS 能解决大部分问题；
• 脚本工具，标准库比新依赖更可靠；
• 成本敏感的 Agent 流程，希望减少 token、diff 和 review 压力；
• 团队已经被 AI 生成的大量样板代码折磨过。

不太适合这些场景：

• 你明确要完整框架设计；
• 你正在做长期可扩展平台；
• 需求本身就是复杂系统建模；
• 安全、合规、审计需要更完整的显式流程；
• 团队还没建立代码审查和测试底线。

一句话：ponytail 适合给已经会跑的 Agent 装刹车，不适合拿来代替方向盘。

我会怎么把它放进自己的工作流

如果让我现在把 ponytail 放进日常 AI 编程流程，我不会全局无脑开启 ultra 模式，而会分层使用。

对小修复、脚本、样式、表单、工具函数，我会默认启用 full：让它优先找现有代码、标准库、原生能力，尽量给最小 diff。

对架构设计、系统重构、跨模块改造，我会先不用 ponytail，让 AI 展开思路；等方案确定后，再让它用 ponytail 视角做一次“删减审查”：哪些抽象能砍，哪些文件能不动，哪些依赖能不加。

对安全边界、数据迁移、权限控制，我会特别强调：少写可以，但不能少校验、少日志、少回滚路径。

比较理想的工作流可能是这样：

# 第一步：正常分析
让 Agent 读代码、理解需求、列出影响面。

# 第二步：ponytail 审查
要求它按 YAGNI / stdlib / native / existing dependency 顺序压缩方案。

# 第三步：最小实现
只允许改必要文件，禁止新增未请求抽象。

# 第四步：保留最小验证
非平凡逻辑必须有一个能跑的检查，安全边界必须保留 guard。

这套流程听起来比“让 AI 直接写”麻烦一点，但实际会省掉后面大量 review 时间。

因为 AI 生成代码最贵的部分，从来不是生成，而是你要读它、理解它、判断它有没有偷偷多做事。

少 50 行代码，省下的不是模型 token，而是人的注意力。

最后的判断：ponytail 真正卖的不是插件，而是一种反潮流的工程姿态

AI 编程工具现在整体都在往“更多”走：更多上下文、更多工具、更多自动化、更多 Agent、更多代码。

ponytail 反着来：少一点。

少一点抽象。少一点依赖。少一点未来感。少一点“看起来很完整”的幻觉。

这很不性感，但很工程。

因为代码库不是演示视频。演示视频里，AI 一口气生成几百行很震撼；真实项目里，几百行 diff 意味着 review、测试、维护、回滚、迁移和未来某个凌晨三点的排障。

我喜欢 ponytail，不是因为它能让所有 AI 输出都减少 54%。这个数字要看任务、看模型、看代码库，不该当成万能承诺。

我喜欢它，是因为它提醒了一个被 AI 热潮冲淡的老道理：

工程能力不只体现在“能造什么”，也体现在“忍住不造什么”。

AI 让写代码变得便宜，但没有让维护代码变得免费。

所以，一个会少写代码的 AI 编程助手，可能比一个更会写代码的 AI 编程助手，更接近真正的生产力。

项目地址：https://github.com/DietrichGebert/ponytail