返回博客首页
小需求被 AI 写成大工程，并不一定因为模型不会写代码，往往是它没先确认范围与现有实现。Ponytail 5 想给编程助手加上“先读、先复用、再写”的顺序。这篇把当前安装方式、review 新能力和维护者基准拆开核对，并给出一套团队可试运行的方法。
一个小需求，为什么被 AI 写成了大工程
让编程助手给表单补一个日期输入框，结果它引入日历组件库、新建状态管理文件，还写了整套样式和测试夹具。代码并非不能运行，但团队以后要维护的东西变多了。Ponytail 想干预的正是这个决策点：动手前先确认范围，再找现成实现，最后才考虑新代码。
图中的夸张场景很常见：问题不在于代码写得快，而在于需求边界没先说清。
10 月 3 日的原文把 Ponytail 介绍为一个已有 152K Star 的工具。但截至本文整理时，GitHub 仓库已显示约 158K Star，而且项目当前已进入 Ponytail 5，公开了日期为 10 月 7 日的新版基准。Star 是动态数字，不宜继续写成固定标题；更关键的是，新版的 review 和 audit 已经扩大检查范围。本文以当前仓库说明和新版基准记录为准，旧截图只当操作画面。
这是 10 月 3 日附近的仓库截图；版本和 Star 数请以打开仓库时的页面为准。
Ponytail 5 做的不是“把代码压到最短”
项目的规则文件列了一条具体的选择顺序：先判断功能是否真的需要，再看代码库里有没有现成的组件或约定；其次考虑标准库、平台原生能力和已安装依赖；都不合适时，才写完成任务所需的最小代码。一个不好读的“一行流”并不自动优于清晰的十行实现。需要改到的调用方、配置、测试与 fixture，也不能为了缩短 diff 留下不一致。
这张旧版流程图展示了“先复用、后新建”的思路；Ponytail 5 的完整规则仍应查最新规则文件。
项目特别写明不应删掉信任边界校验、防止数据丢失的错误处理、安全措施和无障碍支持。新版还要求：分支、循环、解析器、涉及金钱或安全的非平凡逻辑，至少留下一个小测试或断言。换句话说，少写的是多余结构，不是必要保障。
一个可讨论的例子来自维护者的基准记录：日期选择器任务里，无插件的代理写了 335 行，Ponytail 5 用仓库已有的 Input 组件和浏览器原生日期输入，交付了 10 行。但这只证明该测试任务有更小的可行实现；如果你的产品有跨时区规则、特定无障碍要求或复杂日历交互，仍要按需求验证原生控件是否足够。
项目首页截图保留了当时的展示口径；下文数字采用 Ponytail 5 的新基准。
在 Codex 和 Claude Code 中怎么装
先从官方仓库确认项目地址。维护者提醒只从 DietrichGebert/ponytail 或其 npm 包安装，避免同名第三方包。当前安装说明给出的 Codex 命令是：
codex plugin marketplace add DietrichGebert/ponytail
codex plugin add ponytail@ponytail
安装后在 Codex 打开 /hooks，检查并信任该插件的两个生命周期 hook，再开启新会话；桌面端安装后需重启应用。插件使用 Node.js hook，Node 不在非交互式 PATH 时，规则仍可能载入，但 hook 会报 node: command not found。团队环境最好先阅读插件目录、hook 脚本和权限范围，再决定是否启用。
原文 GIF 的第一帧展示在插件市场找到 Ponytail；界面位置可能随客户端版本变化。
第二帧展示安装动作；安装后仍应按当前说明检查 hook 和重启要求。
如果团队使用 Claude Code，官方提供两条分开发送的命令：
/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytail
单纯复制项目的 AGENTS.md 到代码库，是另一种只注入规则的接入方式；它不等于安装了完整插件与生命周期 hook。如果仓库已有 AGENTS.md，应审阅并合并规则，不要直接覆盖原有项目约束。也不要把原文中的 Codex 图形界面流程直接当成所有版本的唯一安装方法。
三档模式、Review 与 Audit 怎么用
lite 先完成请求，顺带指出更小的做法；full 是默认完整规则；ultra 会更主动质疑没有必要的需求。首次使用建议在一个非关键的小任务上开 full，要求它给出范围、可复用位置、最小改动和验收方式，再决定是否提高强度。off 可关闭；stop ponytail 或 normal mode 也用于退出持续模式，具体入口以宿主工具为准。
最能减少误删的起步方式是让它先审查。Ponytail 5 的 /ponytail-review 已不再只找“能砍掉的代码”：它会阅读改动触及的上下文，检查 bug、安全、负载、缺失测试、慢路径和不必要实现。/ponytail-audit 把同样的思路扩展到整个仓库。项目还提供 /ponytail-debt、/ponytail-gain 和 /ponytail-help，分别用于收集延期事项、查看基准收益与查帮助。在 Codex CLI/IDE 中，命令可能以 $ponytail:ponytail-review 这样的命名空间 skill 形式出现，不能假定所有宿主都能直接输入同一条斜杠命令。当前 README列出了宿主差异。
原文展示的是旧版审查画面；Ponytail 5 的审查范围已有变化。
这张表是旧版快照，可帮助认识命令名称；实际能力与调用方式以新版 README 为准。
你可以把首次试用请求写得具体一些：
请先 review 当前分支相对目标分支的改动，重点找重复实现和未复用的现有组件。
不要直接改代码。对每条建议列出涉及的文件、现有可复用实现、可能破坏的行为，
并标明哪些校验、错误处理、测试和无障碍要求必须保留。
审查完只采纳能在仓库里核实的建议；旧项目里看似冗余的分支，可能承载历史数据兼容。若要它直接修改，给出具体文件和任务范围，比一句“把这个项目简化一下”更安全。
用一个真实项目问题检验它的判断
假设任务是“在用户资料页增加地区选择”。仓库已有一个带键盘操作和错误提示的 Select 组件，也有读取地区列表的接口。没有看代码的 Agent 可能新造 RegionPicker、复制一份选项数据，还为了缓存建立新服务。合适的最小改动应先复用组件与接口，再补一条提交时的校验。如果需要搜索、离线缓存或多级行政区联动，那是额外需求，应先确认，而不是自作主张一并实现。
让 Ponytail 处理时，可以要求它先回答四个问题：现有 Select 的入口在哪里？地区数据由谁维护？新增字段会经过哪些表单校验和 API 调用？怎样证明旧用户资料没有被破坏？如果答案找不到，就让它先查仓库，别让“最短实现”变成猜测。完成后人工看一次 diff：有没有改到所有调用方，有没有留下必须的校验和测试，是否因复用而引入新的耦合。只有这些都过关，少写的代码才是真正节省。
“少 53% 代码”该怎样读
维护者 10 月 7 日的完整基准在 Claude Code CLI + Opus 5.5 上，用 39 个任务、每任务每组 5 次，共 585 次会话，对比无插件、Ponytail 旧版和 Ponytail 5。相对无插件，新版报告如下：
| 指标 | Ponytail 5 相对无插件 | 这个数字能说明什么 |
|---|---|---|
| 交付代码行数 | -53% | 该测试集上的实现更短，不等于功能自动更全 |
| 输出 token | -45% | 该测试环境下回复更省 |
| 按标价估算成本 | -26% | 对应实验模型与任务，不是通用账单折扣 |
| 会话耗时 | -41% | 是实验会话时间，不等于线上交付周期 |
| 需要测试的逻辑留下测试 | 98%（无插件 68%） | 覆盖率更高，测试本身仍要看质量 |
这里最需要读的是限制：只测了一个模型和一个宿主；代理不能执行 Bash，写出的代码没有经过它自己跑测试；39 个任务中只有 18 个有真正运行的隐藏正确性检查。那 18 个任务里，Ponytail 5 通过 87/90 次，无插件通过 86/90 次，差距不足以证明普遍提高正确性。基准由项目维护者发布，并非你团队的独立复测。原文中的“54%—94% 少写代码、快 27%、省 20%”属于更早的展示口径，不能直接当成 Ponytail 5 的普遍效果。
还有一层不能忽略：基准里“需要测试时留下测试”从无插件的 68% 升到 98%，但在已经有测试的样本中，这些测试抓住注入小错误的比例是 69%，无插件组为 77%。更常留下测试，不等于每一条测试都更敏感。团队验收时要给关键分支补反例：空值、越权、旧数据、失败重试各选至少一个，确认测试会在错误实现上失败，而不是只看测试文件是否存在。
给自己的仓库做一次可回退的小试运行
先用 6—10 个已完成工单做对照：覆盖容易过度设计的 UI 任务、需要兼容旧数据的后端任务与真实 bug 修复。固定起点、模型、工具权限和验收规则，再比较无插件与 Ponytail full；别只比最终 diff 的行数。
一次可照着执行的仓库试验
从已完成需求中挑一张工单，例如“资料页增加地区选择”。先记录起始 commit、目标分支、原始需求、已有 Select 组件位置、地区 API、现行测试命令。复制出两个相互隔离的工作目录或分支：A 保持原代理配置，B 只加 Ponytail full；模型、工具权限、输入提示和时间预算一致。让两边先说明计划再动手，完成后在同一环境运行测试，由不知道哪边启用了插件的评审者检查结果。不要在同一工作目录先后运行，否则第二次会看到第一次的改动。
可以直接给两边同一段任务说明：
任务：给用户资料页增加地区选择，保存后刷新仍能显示；沿用现有地区 API。
动手前：指出已有 Select、数据来源、受影响的调用方和必要测试。
限制：不新增依赖；除非说明现有方案不满足需求，不新建组件或缓存层。
验收：空值与无效地区有明确错误；旧资料可正常加载；相关测试通过。
交付：列出改动文件、运行的检查、未解决风险；不要只报告减少的代码行数。
记录表至少包含 task_id / 组别 / 是否验收通过 / 新增与删除行数 / 测试结果 / 人工评审分钟 / 返工分钟 / 实际费用。若 B 的代码更短但多漏一个权限检查，这项任务应记为失败，而不是“节省代码”。试验完成后只为优势稳定出现的任务类别启用规则，并保留 A 作为回退。
Code0 团队怎样建立“少写但完整”的规范
在 Code0 面向的多模型开发工作流里，不要把 Ponytail 当成某个模型自带能力。把它视为作用于代理的规则层：同一个历史任务固定模型和权限，只切换是否启用 Ponytail，才能看出规则带来的差别。将“复用现有组件、覆盖调用方、保留边界校验、跑完必要测试”写进团队验收单；未经过本地对照，不承诺节省特定比例的 token。
资料来源
- Ponytail 官方仓库、安装说明、规则文件：当前功能与命令。
- Ponytail 5 基准记录：实验设计、逐任务结果和局限。
- 原公众号文章：本文主题与原始配图来源；其旧版数据和截图已单独标注。
