DietrichGebert/ponytail

解决什么问题

编程 Agent 的典型毛病是过度生产：要个日期选择器，它手写一套日历组件再装个依赖；要个小修复，它顺手重构半个文件。代码能跑，但维护和 review 的成本远超预期。Ponytail 用一组写给 Agent 的指令（一个 skill，加上 /ponytail-review、/ponytail-audit 等命令）来纠正这个倾向：先看仓库里已经有什么，再决定写多少。

有什么不同

面向编程 Agent 的 prompt 合集大多是一堆泛泛规则——简洁、小函数——模型执行时很随意。Ponytail 更窄也更硬：优先复用、只写任务需要的，同时明确规定不能砍掉校验、错误处理、安全和无障碍。README 把它包装成一种 review 姿态（"会被叫起来救火的资深工程师"），audit 命令按"先修哪个"排序而不是罗列全部问题。真正卖的是这个视角，指令本身只是不长的文本。

适合谁

在真实的老仓库里用 Claude Code 或类似 Agent 的开发者：diff 臃肿是真的 review 负担，仓库里也确实有可复用的组件和工具函数。不适合从零起步、无物可复用的新项目，也不适合 Agent 被严格脚手架或生成器锁死的团队，更不适合追求确定性的人——它毕竟是提示词，效果随模型和会话波动。

上手成本

npm 包，MIT 协议，README 称支持约 20 种 Agent，安装方式见 README。没有需要部署的运行时。真正的成本在行为层面：你改变的是 Agent 对任务范围的判断，diff 可能更小，但在确实需要多写代码的任务上也可能交出半成品。README 里的基准数字（约一半代码量、高风险逻辑带测试比例更高）来自项目自建 harness、Claude Code 上 39 个任务，只能当方向性参考，没有独立验证。

点评

这个仓库只有约 4 个月，却已有 175k star，单月新增 30,888，但只上过 1 天日榜。这种年龄与关注度的比例更像围绕一个巧妙概念爆发出的传播，而不是久经沉淀的工具。点子便宜、试错成本低、卸载也容易，"先复用"的倾向也确实对应了 Agent 输出的真实痛点。但价值完全取决于模型是否听话，招牌数字也是自报的。建议先在一个仓库上试一周，再考虑推到整个团队。