Ponytail：让 AI 写出资深工程师的代码
Ponytail: Lazy Senior Engineer Skill
Ponytail 是一个专为 AI 编程助手设计的规则集，旨在模拟资深工程师的极简编码风格。它强制 AI 遵循 YAGNI 原则，优先使用标准库和现有依赖，拒绝过度设计。测试数据显示，Ponytail 能减少 54% 的代码量，降低 20% 的成本，同时保持 100% 的安全性。该插件支持 Claude Code、Copilot CLI、Gemini CLI 等 14 种主流 AI 代理，通过 `/ponytail` 命令即可一键开启从 lite 到 ultra 的不同精简模式，帮助开发者在生成代码时自动过滤冗余，只保留最核心的逻辑。
他一言不发，只写一行代码，然后它就运行了。
HN 评论区
20- oefrha
我喜欢这个仓库有 159 个文件、11635 行代码，而其中承重（!!!）的部分仅仅是几行自然语言指令：
1. *这东西真的需要存在吗？* 如果是推测性的需求就跳过，用一句话说明。 (YAGNI)
2. *代码库里已经有了吗？* 如果这里已经有一个 helper、util、type 或 pattern → 直接复用。写之前先看看；重新实现隔壁几个文件里已有的东西是最常见的垃圾代码。
3. *标准库能搞定吗？* 那就用它。
4. *原生平台特性能覆盖吗？* 用 `<input type="date">` 而不是 picker 库，用 CSS 而不是 JS，用数据库约束而不是应用层代码。
5. *已安装的依赖能解决吗？* 那就用它。绝不要为了几行代码能做的事去添加新依赖。
6. *能写成一行吗？* 那就一行。
7. *只有到了这一步：* 写出能工作的最小代码。
- 不要任何未请求的抽象：不要只有一个实现的接口，不要只生产一个产品的工厂，不要为永远不会变化的值配置配置项。
- 不要样板代码，不要“为将来”搭建脚手架，将来可以自己搭。
- 删除优于添加。无聊优于 clever，clever 是那种让人在凌晨 3 点还要去解码的东西。
- 文件越少越好。最短的有效 diff 获胜——但前提是你已经理解了问题。在错误地方做最小改动不是懒，而是第二个 bug。
- 需求复杂？先交付懒版本，并在同一回复中质疑它，“做了 X；Y 能覆盖。需要完整的 X？请说明。”绝不要在你本可以给出默认答案的事情上卡壳。
- 两个标准库选项，大小一样？选那个在边界情况下正确的。懒意味着 […]
- varun_ch
我知道智能体（agents）已经把建网站的成本降到了几分钱的 token 和几美元的域名，但这对于一个只有几行的 markdown 文件来说是不是有点太过了？为什么不直接展示这个‘技能’本身，再配几行注释说明它是做什么的、怎么帮忙？
- taurath
我忍不住觉得，使用这个工具的实际结果将会是一堆语言怪癖的滥用、大规模的功能链式调用，以及单字母变量。
为了最少的代码行数（LOC）而优化，可能比代码行数多更糟糕，而两者糟糕的原因是一样的——这让人类更难去解读和理解 LLM 到底做出了什么糟糕的决定和权衡。