北京
一个叫 Ponytail 的项目，想让你的 AI 智能体像房间里最懒的资深开发那样干活。它的核心主张只有一句：最好的代码，是你从没写过的代码。
这个说法本身带着反差。通常人们期待 AI 编程助手多产出、快产出，而 Ponytail 反过来要求它少写、能不写就不写。作者在 Ponytail 的 readme 里看到一份基准测试结果，随即产生疑问：它是靠什么框架或库做到的？翻遍官网的“工作原理”部分，并没有透露多少内部细节。
答案藏在 GitHub 的 readme 里。Ponytail 本质上就是一个提示词：skills/ponytail/SKILL.md。面向那些会读取规则文件的智能体，还有一个精简版本 AGENTS.md。仓库里其余的东西，都是把这个提示词加载进不同的智能体。
这份 SKILL.md 给智能体设定的角色是“懒散的资深开发者”：用最少的新代码解决整个问题，并给出一段忙碌的人读一遍就能懂的回复。它适用于任何编码任务——写代码、修 bug、重构、审查、选依赖；当用户说出“ponytail”“be lazy”“最简单的方案”“yagni”，或者抱怨过度工程和臃肿时，也会触发。它分三档：lite、full（默认）、ultra。
提示词要求智能体在动笔前先读任务和它涉及的代码，列出这次改动必须触达的每一处：调用方、测试、fixture、配置、导出。还要检查改动可能给用户带来的破坏，比如会毁掉或暴露的数据、会失效的调用方。这被定义为“范围”，额外功能不算。
具体做法是一串优先级，取第一个完全可行的选项：
- 这东西需要存在吗？没人要的功能、选项和灵活性直接跳过，并用一行说明。
- 代码库里已经有了？按周围代码的用法复用。
- 标准库或平台特性？直接用，除非项目有自己的实现。
- 已安装的依赖？直接用，绝不为几行代码新增依赖。
- 能写成读者一眼看懂的一行？就写一行。
- 否则，写能跑通的最少代码。
它对“懒”划了边界：对方案可以懒，对改动本身不能懒。任务需要的每一部分都要完成，包括因改动而受影响的调用方、测试和 fixture。不写没人要求的抽象、包装、类型转换、选项、配置、样板代码或“以后再用”的代码。删除优于新增，保持代码库原有的分层、接口和约定。
提示词还规定了几条细则：最短的可运行 diff 才算赢，但一行需要解码的代码不算短；注释只写代码本身表达不了的“为什么”，且只写一行；修 bug 前先 grep 被改函数的每个调用方，然后在共享代码里一次性修掉根因；搬移或合并的代码保留原有的错误处理和校验；同等体量的选项之间，选边界情况正确的那个。
“懒代码”必须带上检查才算完成：新的非平凡逻辑——一个分支、一个循环、一个解析器、涉及金钱或安全，或者一整个新脚本、新应用——要留一个小测试或基于 assert 的自检。琐碎改动不需要。带已知限制的捷径要留一行注释，格式为 shortcut: <限制>, <原因>。
有几样东西永远不能砍：信任边界上的校验、防止数据丢失的错误处理、安全、可访问性、真实硬件所需的校准，以及用户明确要求的东西。
三档行为的差别也很清楚：lite 档只做被要求的事，用一行点出更小的选项让用户自己选；full 档执行上述全部规则，是默认档；ultra 档还会质疑需求本身，动手前先反驳需求中站不住脚的部分。
仓库里还附了示例，说明 Ponytail 如何帮助减少代码行数。作者 Ramu Narasinga 自述花了 3 年多研究开源代码库，写了 400 多篇文章探讨什么构成生产级代码，如今换了一种实践方式：不再亲手写每一个修复，而是运行编码智能体来完成——把机器注册为 Runtime，指向仓库，智能体接手 issue、写修复、开 PR，人只负责审查。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
