今天发点适合写代码的东西。

写项目的时候，刚开始代码都很清爽：两个页面、三个接口、几段工具函数，目录一眼能看完。

功能多了之后，又是加 wrapper，又是塞 options，功能没涨多少，代码量翻了几倍。

不过只要你用了 GitHub 上的这个 Ponytail（马尾辫） 项目，AI 写代码会突然变得很精简。

01. 项目简介

Ponytail 是开源的 AI 编程代理规则集和插件系统。

项目地址：https://github.com/DietrichGebert/ponytail

项目能让 Claude Code、Codex 等 AI coding agent 写代码时优先选择最小、最直接、最不容易留下维护债的实现。

Ponytail 会让 AI agent 在写代码前走一遍固定判断链：

• 这个功能真的需要存在吗？不需要就跳过。
• 标准库已经有能力吗？有就用标准库。
• 浏览器、数据库、操作系统、框架原生能力能解决吗？有就用原生能力。
• 项目里已有依赖能解决吗？有就复用已有依赖。
• 一行代码能完成吗？能就写一行。
• 以上都不行，再写能工作的最小实现。

Ponytail 还提供了几个常用命令，专门处理代码复杂度问题。

/ponytail-review 负责审查过度设计。Ponytail 会指出哪些代码可以删除、内联，或者直接换成标准库和平台原生能力。

/ponytail-audit 负责扫描整个仓库。Ponytail 会找出抽象过头、依赖过重、配置过多、文件拆得太碎的地方。

/ponytail-debt 负责整理技术债。Ponytail 会收集代码里的 ponytail: 注释，把当时为什么选择简化、后面什么时候需要升级，整理成一份清单。

/ponytail-help 负责显示速查信息。Ponytail 会列出可用命令、模式切换方式和基本用法。

Ponytail 在保证代码简洁的同时，也有边界：不会为了少写代码删掉信任边界的输入校验、避免数据丢失的错误处理、安全措施、可访问性要求，以及用户明确要求的功能。

02. 项目实测

Ponytail 安装完会自动生效，Claude Code 和 Codex 会在每个新会话启动时，通过 lifecycle hook 把规则注入上下文。项目分为 4 种模式，通过 /ponytail 命令切换 lite、full、ultra、off，默认是 full。

case 1  代码减少测试

不用Ponytail：

提示词：

【测试组】Baseline

【运行环境】

只允许修改：

D:360MoveDataUserswinDesktop蒸馏full-stack-fastapi-template-baseline

目录不存在时，从 https://github.com/fastapi/full-stack-fastapi-template 克隆，并检出 cd83fc1。

开始前确认 HEAD 为 cd83fc1，git status –short 为空。

使用全新线程、独立 node_modules、独立 Python 虚拟环境和独立构建缓存。

确认 Ponytail 插件、hook、Skill 和 Ponytail 规则均未加载。不要用 @ponytail off 代替环境隔离。

不得读取或复制 full-stack-fastapi-template-ponytail 中的代码。

无法满足任一条件时停止执行，不要修改代码，并报告“Baseline 环境无效”。

【开发任务】

为 full-stack-fastapi-template 增加可选的 due_date 日期字段。

1. 在 frontend/src/components/Items/AddItem.tsx 的 Item 创建表单中加入 due_date 日期选择控件。
2. 在 frontend/src/components/Items/EditItem.tsx 的 Item 编辑表单中加入 due_date 日期选择控件。
3. 在 backend/app/models.py 中为 ItemBase、ItemCreate、ItemUpdate 和 ItemPublic 增加 due_date。
4. 在 backend/app/alembic/versions/ 中新增数据库迁移，为 item 表加入可空的 due_date 日期列。
5. 使用 full-stack-fastapi-template 现有生成流程更新 frontend/src/client/ 中的 Item 类型。
6. 在 frontend/tests/items.spec.ts 中测试日期选择、修改和清空。
7. 在 backend/tests/api/routes/test_items.py 中测试 due_date 的创建、读取、更新和清空。
8. due_date 使用 YYYY-MM-DD 格式，不包含时间和时区。
9. 遵循 full-stack-fastapi-template 现有代码风格并运行相关测试。

按 AI coding agent 的默认方式完成需求，不引用 Ponytail，不加入“少写代码”“优先一行实现”等额外要求。

【结果记录】

完成后运行 git diff –numstat、git diff –stat 和 git status –short。

统计新增行数、删除行数、修改文件数、新增依赖数、测试结果、耗时和 token 消耗。

无法获取耗时或 token 时填写 unavailable。

 

测试报告不得写入 full-stack-fastapi-template-baseline。

将测试报告保存到：

D:360MoveDataUserswinDesktop蒸馏ponytail-ab-resultsbaseline.md

不用Ponytail：

提示词：

@ponytail full

 

【测试组】Ponytail Full

 

【运行环境】

只允许修改：

D:360MoveDataUserswinDesktop蒸馏full-stack-fastapi-template-ponytail

 

目录不存在时，从 https://github.com/fastapi/full-stack-fastapi-template 克隆，并检出 cd83fc1。

开始前确认 HEAD 为 cd83fc1，git status –short 为空。

使用全新线程、独立 node_modules、独立 Python 虚拟环境和独立构建缓存。

确认 Ponytail 插件和 lifecycle hook 已启用，Ponytail 当前模式为 full。

Claude Code 使用 /ponytail full，Codex 使用 @ponytail full。

不得读取或复制 full-stack-fastapi-template-baseline 中的代码。

无法满足任一条件时停止执行，不要修改代码，并报告“Ponytail 环境无效”。

 

【开发任务】

为 full-stack-fastapi-template 增加可选的 due_date 日期字段。

1. 在 frontend/src/components/Items/AddItem.tsx 的 Item 创建表单中加入 due_date 日期选择控件。
2. 在 frontend/src/components/Items/EditItem.tsx 的 Item 编辑表单中加入 due_date 日期选择控件。
3. 在 backend/app/models.py 中为 ItemBase、ItemCreate、ItemUpdate 和 ItemPublic 增加 due_date。
4. 在 backend/app/alembic/versions/ 中新增数据库迁移，为 item 表加入可空的 due_date 日期列。
5. 使用 full-stack-fastapi-template 现有生成流程更新 frontend/src/client/ 中的 Item 类型。
6. 在 frontend/tests/items.spec.ts 中测试日期选择、修改和清空。
7. 在 backend/tests/api/routes/test_items.py 中测试 due_date 的创建、读取、更新和清空。
8. due_date 使用 YYYY-MM-DD 格式，不包含时间和时区。
9. 遵循 full-stack-fastapi-template 现有代码风格并运行相关测试。

只应用 Ponytail Full 已加载的规则，不追加其他 YAGNI、一行实现或精简提示。

 

【结果记录】

完成后运行 git diff –numstat、git diff –stat 和 git status –short。

统计新增行数、删除行数、修改文件数、新增依赖数、测试结果、耗时和 token 消耗。

无法获取耗时或 token 时填写 unavailable。

 

测试报告不得写入 full-stack-fastapi-template-ponytail。

将测试报告保存到：

D:360MoveDataUserswinDesktop蒸馏ponytail-ab-resultsponytail.md

在本轮对比中，Baseline 组新增 225 行代码，Ponytail Full 组新增 149 行，Ponytail 让总新增代码减少约 34%，修改文件从 10 个降到 8 个，已经能说明 Ponytail 可以减少需求外功能、重复校验和不必要改动。

case 2 项目审查

提示词：

/ponytail-review

请只审查过度设计，不要重写代码。重点找出可以删除、内联、替换成标准库或浏览器原生能力的地方。

审查这段 React 代码：

import { useState } from “react”;

import dayjs from “dayjs”;

 

class DateInputAdapter {

constructor(formatter) {

this.formatter = formatter;

}

 

normalize(value) {

return this.formatter(value);

}

}

 

const createDateFormatter = () => {

return (value) => dayjs(value).format(“YYYY-MM-DD”);

};

 

export function BirthdayPicker() {

const [date, setDate] = useState(“”);

const adapter = new DateInputAdapter(createDateFormatter());

 

function handleChange(event) {

const normalized = adapter.normalize(event.target.value);

setDate(normalized);

}

 

return (

type=”text”

placeholder=”YYYY-MM-DD”

value={date}

onChange={handleChange}

/>

);

}

Ponytail 准确找出了预埋的四处过度设计，标出了行号、问题类型和修改方向，没有跑去讨论命名、代码风格或异常处理，符合 /ponytail-review 只审查过度设计的定位。

case 3 仓库检查

这个 case 中，仓库故意加入了单实现接口、工厂、适配器、管理器、Facade、多余配置和可替换依赖，看看能不能检查出来。

提示词：

/ponytail-audit

请扫描/D:/360MoveData/Users/win/Desktop/蒸馏/ponytail-case2-audit仓库，只找复杂度浪费。输出时按文件列出问题，并说明每处复杂度可以怎样减少。

重点检查这些问题：

1. 为单一实现创建 interface、factory、manager、adapter。
2. 为简单数据转换引入第三方依赖。
3. 为未来可能出现的需求预留配置。
4. 多个文件之间只有一层转发，没有真实逻辑。
5. 能用标准库、框架能力、数据库能力完成，却手写了一套逻辑。

 

不要做业务功能审查，不要检查代码风格，只关注 Ponytail 关心的过度设计。

Ponytail 的 13 条发现基本覆盖了 Case 3 预埋的度问题，而且没有误删 CSV 转义、JSON 读取和自动测试。找得全，建议也够具体。

case 4 收集技术债

提示词：

/ponytail-debt

请收集/D:/360MoveData/Users/win/Desktop/蒸馏/ponytail-case3-debt仓库里的 ponytail: 注释，整理成技术债清单。

请按下面格式输出：

– 文件路径

– 注释原文

– 当时选择简化的原因

– 未来需要升级的触发条件

– 当前是否需要处理

 

请特别关注下面几类注释：

 

// ponytail: keep native date input until timezone support is required

// ponytail: inline this mapper until a second provider appears

// ponytail: use in-memory cache until requests exceed 1000/min

// ponytail: avoid queue dependency until retry semantics are needed

 

不要添加代码里没有的技术债。

Ponytail 把 5 条 ponytail 注释全部找到，文件和行号准确。每条记录都拆出了简化原因、升级条件和当前状态。

03. 挖一挖

Claude Code、Codex 正在接管越来越完整的开发任务。

代码生成速度提高后，改动带来的审查、验证和维护成本也会提高。DORA 2025 调查显示，90% 的受访者已在工作中使用 AI，比 2024 年增加 14.1%，但AI 使用程度提高与软件交付不稳定性上升相关。

Ponytail 可以缩短 MVP 的开发和返工时间，减少代码审查压力，还可以作为一套固定的 AI 编码规则，限制无意义的依赖、抽象和文件增长。

34% 只是一次本地测试结果，不能直接套到所有代码库。原有实现已经足够精简时，Ponytail 很难继续减少代码；需求存在原生能力、重复封装或过度设计时，Ponytail 才会拉开明显差距。

Ponytail 的价值还是落在减少后续维护、审查和返工成本上。

原文链接：GitHub 狂揽 47K Stars，代码写出来再也不臃肿