Ponytail Review skill : 精简冗余代码

AI coding 已经渐渐成为几乎所有开发者的默认选项，当代码的产量成倍增长📈之后，code review 就成为了新的瓶颈。除了正确性，代码是否冗余也成为了 code review 的重点。比如一个日期输入框带进来一个组件库，一个只有一个实现的接口配了工厂，测试全过，常规 /review 命令也挑不出毛病。

DietrichGebert/ponytail 库中的 Agent Skill ponytail-review 为此而生，专门处理这一类问题：

这个 Diff 里，有什么东西根本不需要存在？

它不检查正确性、安全性或性能，也不自动修改代码，只列出可以删除、内联或换成现成能力的代码，并且每条建议都要写出替代方案。Ponytail 下的六个 Skills之中，我觉得 ponytail-review 是开发过程中最实用的一个，后面会解释原因。

正确但多余的代码，常规 Review 看不出来

假设需求只是给表单加一个日期字段，Agent 可能会交出这样的实现：

• 新增第三方日期组件依赖。
• 包装一层项目组件。
• 新建样式文件。
• 提前加入时区配置。
• 为一个调用方抽象出通用接口。

这些代码能编译，测试也可能通过。常规 Review 关注功能和风险，很可能不会把它们标成问题。

但仓库从此多了依赖升级、样式兼容和理解抽象的成本，而且每次维护都要付。

ponytail-review 把“过度设计”单独拿出来审查。它不问代码能不能工作，而是追问：

• 需求真的要求这项能力吗？
• 仓库里已经有实现了吗？
• 标准库是否已经提供？
• 浏览器、数据库或操作系统是否原生支持？
• 这个抽象是否真的有第二个实现？
• 同样的逻辑能否更直接地表达？

这类审查特别适合 Agent 生成的 Diff。人写冗余代码，多半是赶时间复制粘贴；Agent 则常常为了显得周全，主动补上脚手架、扩展点和解释性封装。原因不同，最后都由维护者买单。

五个标签：delete、stdlib、native、yagni、shrink

ponytail-review 的每条发现都必须带一个标签。标签的作用是逼审查者讲清楚这段复杂度属于哪一类，删掉以后由什么替代。

下面的示例改写自 SKILL.md 里的例子。

delete：删掉没有现实需求的代码

L52-71: delete: 为幂等的本地调用增加重试包装。无需替代。

这一类不是要把所有保护代码都删掉。它找的是没有故障模型支撑的机制、永远走不到的分支，以及“以后也许有用”的功能。本地调用本身幂等又不会因网络抖动失败，重试包装就没有要防的故障。

stdlib：不要重新实现标准库

L12-38: stdlib: 27 行的邮箱校验类。用 "@" in email 一行判断，真正的校验交给确认邮件。

标准库实现通常更短，也经过更广泛的测试。重点不在于追求一行代码，而是让团队不必长期维护一份本不需要自研的实现。

native：先用平台已经提供的能力

date-picker.tsx:L4: native: 为一个日期输入引入组件库。使用 <input type="date">，减少一个依赖。

native 是 Ponytail 最有辨识度的一类建议。浏览器控件、CSS、数据库约束和操作系统能力，往往比在应用层重新实现更便宜。

前提是原生能力真的满足产品要求。如果日期选择器需要浏览器不支持的交互、格式或无障碍行为，就不该为了少几行代码硬换。

yagni：第二个需求出现前，不为它设计

repo.py:L88: yagni: AbstractRepository 只有一个实现。在出现第二个实现前直接内联。

接口和工厂本身没错，问题在于它们是否在应对已经存在的变化。只有一个实现、一个调用方、一个从不变化的参数时，抽象层只会把阅读路径拉长。

shrink：逻辑不变，写法更短

L30-44: shrink: 手写循环组装字典。改用 dict(zip(keys, values))。

这一类最容易被误用成代码高尔夫。好的 shrink 应该同时减少行数和理解成本。如果更短的写法需要读者停下来猜，它就算不上简化。

一条发现只占一行，这个限制很关键

ponytail-review 要求每条发现使用固定格式：

<file>:L<line>: <tag> <删什么>。<用什么替代>。

多文件 Diff 标出文件名，单文件 Diff 可以只给行号。最后用一行汇总理论上能减少的代码：

net: -42 lines possible.

这个数字只是参考，改不改还要看具体代码。我也不建议把它当成团队指标：为了让负数更大而牺牲可读性或必要的保护，正好违背了这个 Skill 的本意。

如果没有可删的内容，它不需要为了证明自己干过活而硬找问题，只输出：

Lean already. Ship.

这个格式规避了 AI Review 的几个老毛病。它必须定位到具体行，不能泛泛地说“结构似乎有些复杂”；它必须给出替代方案，不能只表达个人口味；一行的长度限制压掉了大量客套和铺垫，作者扫一眼就能判断建议成不成立。

它不检查什么：Lean already 不等于可以发布

一个窄 Skill 好不好用，很大程度上看它清不清楚自己的边界。ponytail-review 明确排除了：

• 正确性 Bug。
• 安全漏洞。
• 性能问题。
• 自动应用修改。

这些应该交给常规 Code Review。它还明确保留最小的 Smoke Test 和基于 assert 的自检，不会因为测试增加了行数就把它们当成膨胀。

所以 ponytail-review 不能单独作为合并门槛。一个 Diff 可能拿到 Lean already. Ship.，同时仍然有 SQL 注入、竞态条件，或者业务逻辑整个写错了。这句话只代表“没有明显的过度设计”。

和其他五个 Ponytail Skills 比，review 的接入成本最低

Ponytail 仓库目前提供六个 Skills。它们共享同一套理念，但用起来的成本差别很大。

ponytail：常驻约束整个编码过程

主 Skill 把 YAGNI、复用现有代码、标准库优先、平台原生能力优先组织成一架决策梯子，提供 lite、full、ultra 三档强度。插件还能通过生命周期 Hooks，在每轮对话和子 Agent 里持续注入规则。

想强制统一 Agent 编码风格的团队可能用得上，但这套机制不轻：模式有状态，涉及环境变量和配置文件，不同 Agent 的安装和注入方式也不一样。很多项目其实只需要把几条核心原则写进 AGENTS.md。

ponytail-review 没有这些负担。它是一次性的，需要时运行，读完 Diff 就结束，不会改变后续会话的模式。

ponytail-audit：把审查扩展到整个仓库

ponytail-audit 用同样的标签扫描全仓，按预计删除量排序。专门清理遗留代码时可以用，但不适合当日常默认动作。

全仓代码缺少当前 Diff 那样的需求边界。一个看起来只有单实现的接口，可能在服务外部插件；一个看起来没人改的配置，可能由部署系统覆盖。范围越大，Agent 越难拿到完整的历史，误报和人工核实的成本都会上升。

当前 Diff 通常有明确的需求、作者和测试，在这个范围里判断新抽象是否多余，要可靠得多。

ponytail-debt：为简化方案单独建台账

ponytail-debt 扫描代码里的 ponytail: 注释，把有意采用的简化、能力上限和升级条件整理成清单。如果项目已经在用 Issue、TODO 或技术债标签，再加一套 Ponytail 专用约定就重复了。

ponytail-review 不要求仓库采用任何新注释或治理流程，它只读已经存在的 Diff。

ponytail-gain 与 ponytail-help：不一定需要做成 Skill

ponytail-help 是命令速查表，README 就能承担同样的职责。ponytail-gain 是一张固定的 Benchmark 展示卡，不分析当前仓库。

而且，本文查看的 `ponytail-gain` 还在用早期单轮生成实验里“减少 80–94% 代码”的数字。项目当前的 README 已经承认，旧基线把模型的解释和备选方案也算了进去，夸大了收益。更新后的真实 Agent 实验，平均结果是代码行数减少约 54%，成本减少约 20%，耗时减少约 27%。

数据来源：Ponytail 固定版本实验汇总。

Benchmark 报告值得看，但把会更新的数据固化进 Skill，维护成本比它带来的能力还高。

这就是 ponytail-review 和其他几个文件的区别：它不是常驻方法论、仓库治理协议、全局扫描器或宣传页，只是一个边界清楚的审查工具。

推荐用法：放在常规 Review 之后跑第二遍

稳妥的用法是连续做两遍审查，而不是用它替代常规 Review：

功能实现完成
  ↓
常规 Review：需求、正确性、安全、错误处理、性能、测试
  ↓
ponytail-review：只寻找可以删除的复杂度
  ↓
人工确认建议并修改
  ↓
重新运行测试

以下几种情况最值得跑一遍：

• Agent 生成的 Diff 明显比需求预期的大。
• 新增了依赖、接口、工厂、Provider、Wrapper 或配置层。
• 本应用浏览器、数据库或标准库能力解决的需求，被实现成了一套自定义系统。
• PR 功能正确、测试通过，但维护者总觉得“这么小的需求不该有这么多代码”。

调用时可以写明审查范围，例如：

使用 ponytail-review 检查当前分支相对 main 的 Diff。
只报告过度设计，不检查正确性，也不要修改代码。

在 Codex 中安装完整插件后，可以用 @ponytail-review 调用；其他支持 Skill 的 Agent 一般用 /ponytail-review。如果只需要这一个能力，把对应的 SKILL.md 放进项目或用户的 Skills 目录就够了，不必同时启用 Ponytail 的常驻模式、Hooks 和其他辅助 Skills。

接受一条删除建议前，先问四个问题

拿到 ponytail-review 的输出后，如果觉得有问题，可以用四个问题快速复核：

1. 替代方案是否完整覆盖了当前明确的需求？
2. 被删除的代码是否在保护安全、数据或无障碍方面的边界？
3. 这个抽象是否真的只有一个实现、一个变化方向？
4. 改完以后，代码是否不仅更短，也更容易理解和测试？

四个答案都支持简化，再应用建议。只要有一项取决于 Agent 不知道的业务背景，就该由人拍板，而不是看到输出里写着 delete 就照删。

总而言之，当你懒得仔细 code review 时， 得到一句 Lean already. Ship. 总会多一分踏实。😇