Ponytail 深度剖析 —— 让 AI 像懒惰的高级开发一样写代码

发表于 分类于 ， Changyan： 本文字数： 16k 阅读时长 ≈ 15 分钟

你有没有遇到过这种情况：AI 帮你写了个功能，结果出来一大堆代码，看着挺”专业”，但总觉得哪里不对劲？明明一个函数能搞定的事，它给你整了三个文件、五个类、两个设计模式？

Ponytail 就是来解决这个问题的。它是一套让 AI 像”懒惰的高级开发”一样写代码的行为规则集——不是真的懒，而是聪明地偷懒。

一、Ponytail 是什么？

先打个比方：

Ponytail = 给 AI 配了一个”老油条”开发的脑子

你团队里一定有这么一个人：代码写了十几年，什么花里胡哨的都见过，最讨厌过度设计。你跟他说”帮我加个缓存”，他会先问你”真的需要吗？”，然后可能用一行代码搞定，而不是给你搞个完整的缓存框架。

Ponytail 就是把这个”老油条”的思维方式，变成了 AI 的行为规则。

核心理念：最懒的解决方案就是最好的

Ponytail 的名字来源于”马尾辫”——简单、利落、不拖泥带水。它的核心思想可以用一句话概括：

能不写的代码就不写，能少写的就少写，能用现成的就用现成的。

这不是偷工减料，而是一种高级的工程判断力。知道什么不该做，往往比知道什么该做更重要。

它不是一个工具，是一个”行为约束层”

很多人以为 Ponytail 是个代码生成器或者优化工具，其实不是。它本质上是一个行为约束层——它不生成代码，它只是改变 AI 生成代码的方式。

打个比方：如果 AI 是一个水龙头，Ponytail 就是水龙头上的阀门。它不产生水，但它控制水流的大小和方向。

二、7 阶梯子：Ponytail 的核心决策引擎

Ponytail 的灵魂是这个7 阶梯子——写代码之前，先从梯子底部往上爬，能停在哪一阶就停在哪一阶。

graph TB
    L1["1️⃣ 这事真的需要做吗？<br/>YAGNI — 猜测性需求 = 跳过"]
    L2["2️⃣ 代码库里已经有了吗？<br/>复用现有的 helper/util/模式"]
    L3["3️⃣ 标准库能搞定吗？<br/>用它"]
    L4["4️⃣ 平台原生支持吗？<br/>input[type=date] > 日期选择器库"]
    L5["5️⃣ 已装的依赖能用吗？<br/>用它，别为几行代码加新依赖"]
    L6["6️⃣ 能一行搞定吗？<br/>一行"]
    L7["7️⃣ 写最小可用代码<br/>但也要够用"]

    L1 -->|"需要做"| L2
    L2 -->|"没有现成的"| L3
    L3 -->|"标准库没有"| L4
    L4 -->|"平台不支持"| L5
    L5 -->|"依赖不满足"| L6
    L6 -->|"不能一行"| L7

    style L1 fill:#ff6b6b,stroke:#d63031,color:#fff
    style L2 fill:#fdcb6e,stroke:#f39c12
    style L3 fill:#55efc4,stroke:#00b894
    style L4 fill:#74b9ff,stroke:#0984e3
    style L5 fill:#a29bfe,stroke:#6c5ce7
    style L6 fill:#fd79a8,stroke:#e84393
    style L7 fill:#636e72,stroke:#2d3436,color:#fff

关键点：梯子是个反射动作，不是研究项目。AI 不需要花时间思考”我该用哪个方案”，而是按照固定顺序自动检查，第一个满足条件的方案就是最终方案。

用一个真实例子走一遍梯子

假设你说：”帮我写个函数，判断邮箱格式是否正确。”

阶梯 AI 的思考 结果
1 “这事需要做吗？” → 需要，邮箱验证是真实需求 继续
2 “代码库里有现成的吗？” → 搜了一下，没有 继续
3 “标准库能搞定吗？” → re.match(r'@', email) 一行就行 停在这里

最终产出：

1
2
def is_valid_email(email):
    return '@' in email

而不是：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
import re
from typing import Optional

class EmailValidator:
    """
    邮箱格式验证器
    支持多种邮箱格式，包括：
    - 普通邮箱：user@example.com
    - 带点号：user.name@example.com
    - 带加号：user+tag@example.com
    """
    
    def __init__(self, allow_unicode: bool = False, check_mx: bool = False):
        self.allow_unicode = allow_unicode
        self.check_mx = check_mx
        self._pattern = self._build_pattern()
    
    def _build_pattern(self) -> str:
        # ... 50 行正则表达式
    
    def validate(self, email: str) -> bool:
        # ... 20 行验证逻辑
    
    def validate_with_reason(self, email: str) -> tuple[bool, Optional[str]]:
        # ... 30 行带原因的验证
    
    def __repr__(self) -> str:
        return f"EmailValidator(allow_unicode={self.allow_unicode})"

Ponytail 的态度是：真正的邮箱验证是发确认邮件，不是写 27 行的正则。

三、12 条规则：AI 的行为红线

梯子是决策流程，规则是行为约束。Ponytail 有 12 条明确的规则，每一条都是针对 AI 常见问题的”解药”。

规则分类

graph LR
    subgraph "反过度设计"
        R1["禁止未要求的抽象"]
        R2["禁止样板代码"]
        R3["禁止预留设计"]
    end
    
    subgraph "最简优先"
        R4["删除优于添加"]
        R5["最少文件"]
        R6["最短 diff"]
    end
    
    subgraph "诚实标记"
        R7["已知上限要标记"]
        R8["复杂需求先出简版"]
        R9["标准库选稳健的"]
    end
    
    subgraph "安全边界"
        R10["输入验证不能省"]
        R11["错误处理不能省"]
        R12["安全措施不能省"]
    end
    
    style R1 fill:#ff6b6b,stroke:#d63031,color:#fff
    style R2 fill:#ff6b6b,stroke:#d63031,color:#fff
    style R3 fill:#ff6b6b,stroke:#d63031,color:#fff
    style R10 fill:#00b894,stroke:#00cec9
    style R11 fill:#00b894,stroke:#00cec9
    style R12 fill:#00b894,stroke:#00cec9

逐条拆解：每条规则如何改变 AI 的行为

规则 1：禁止未要求的抽象

原文：No unrequested abstractions: no interface with one implementation, no factory for one product, no config for a value that never changes.

通俗解释：你没说要工厂模式，AI 就不会给你搞个工厂。

AI 常见问题：一上来就定义 IRepository 接口、搞 ServiceFactory、写配置类——其实只有一个实现，一个产品，一个配置值。

Ponytail 如何纠正：强制 AI 问自己”这个抽象有第二个实现吗？”如果没有，就内联。

1
2
3
4
5
6
7
8
9
10
11
# ❌ AI 默认行为：一个接口 + 一个实现
class IRepository:
    def get(self, id): pass

class UserRepository(IRepository):
    def get(self, id):
        return db.query(id)

# ✅ Ponytail 模式：直接写
def get_user(id):
    return db.query(id)

规则 2：禁止样板代码

原文：No boilerplate, no scaffolding “for later”, later can scaffold for itself.

通俗解释：别为了”以后可能用到”而写一堆脚手架代码。

Ponytail 如何纠正：永远不做”为了以后”的事情。以后需要的时候，再加也不迟。

规则 3：删除优于添加

原文：Deletion over addition. Boring over clever, clever is what someone decodes at 3am.

通俗解释：能删代码就别加代码。朴素比花哨好，花哨的东西凌晨三点没人能看懂。

这条规则的深层含义：每行代码都是维护成本。删一行代码，你省的不只是那行本身，还包括它带来的理解成本、测试成本、bug 风险。

规则 4：最少文件 + 最短 diff

原文：Fewest files possible. Shortest working diff wins — but only once you understand the problem.

通俗解释：改动越少越好。但前提是先理解问题——在错误的地方做最小改动，不是懒，是第二个 bug。

规则 5：已知上限要标记

原文：Mark deliberate simplifications that cut a real corner with a known ceiling with a ponytail: comment naming the ceiling and upgrade path.

通俗解释：当简化有已知代价时（比如全局锁、O(n²) 复杂度），用注释标记出来，说明什么时候该升级。

1
2
3
4
5
6
# ponytail: global lock, per-account locks if throughput matters
lock = threading.Lock()

def process(data):
    with lock:
        # ... 处理逻辑

这条规则体现了 Ponytail 的诚实——它承认”这是偷懒，但我知道边界在哪”。

四、三档强度：按需调节”懒惰程度”

Ponytail 不是一刀切，它支持三档强度，让你根据场景选择：

graph LR
    subgraph "三档强度"
        L["Lite<br/>提案级<br/>━━━━━━━<br/>照做但告诉你<br/>其实有更懒的方案"]
        F["Full<br/>默认强制<br/>━━━━━━━<br/>强制执行梯子逻辑<br/>标准库→原生→一行"]
        U["Ultra<br/>极端YAGNI<br/>━━━━━━━<br/>先质疑需求<br/>再决定做不做"]
    end
    
    L -->|"升级"| F
    F -->|"升级"| U
    
    style L fill:#74b9ff,stroke:#0984e3
    style F fill:#fdcb6e,stroke:#f39c12
    style U fill:#ff6b6b,stroke:#d63031,color:#fff

同一需求，三档对比

你说：”加个 API 缓存。”

档位 AI 的反应 产出
lite 给你写个缓存类，但顺便说一句”其实 functools.lru_cache 一行就能搞定” 自定义缓存类 + 一行提示
full 直接用 @lru_cache(maxsize=1000) 一行装饰器
ultra “真的需要缓存吗？先 profiler 看看再说。如果确实需要：@lru_cache。手写 TTL 缓存类是个 bug 工厂。” 质疑需求 + 一行方案

什么时候用哪个档位？

档位 适用场景 不适用场景
lite 探索性开发、快速原型 生产代码
full 日常编码、代码审查、重构 无
ultra 代码审计、清理臃肿项目 需求明确的功能开发

五、6 个 Skill：Ponytail 的完整工具箱

Ponytail 不是一个单一工具，而是一个技能家族，6 个 Skill 各司其职：

graph TB
    subgraph "Ponytail 技能家族"
        P["ponytail<br/>核心懒惰模式<br/>━━━━━━<br/>永久生效<br/>每次响应都激活"]
        
        PR["ponytail-review<br/>代码审查<br/>━━━━━━<br/>只关注一件事<br/>哪里可以删？"]
        
        PA["ponytail-audit<br/>全仓库审计<br/>━━━━━━<br/>扫描整个代码库<br/>按可砍量排序"]
        
        PD["ponytail-debt<br/>技术债清单<br/>━━━━━━<br/>收集 ponytail: 注释<br/>防止延期变成永久"]
        
        PG["ponytail-gain<br/>效果看板<br/>━━━━━━<br/>基准测试中位数<br/>展示实际收益"]
        
        PH["ponytail-help<br/>命令手册<br/>━━━━━━<br/>速查卡片<br/>所有模式和命令"]
    end
    
    P -->|"核心引擎"| PR
    P -->|"核心引擎"| PA
    P -->|"产出标记"| PD
    P -->|"量化效果"| PG
    
    style P fill:#ff6b6b,stroke:#d63031,color:#fff
    style PR fill:#fdcb6e,stroke:#f39c12
    style PA fill:#55efc4,stroke:#00b894
    style PD fill:#74b9ff,stroke:#0984e3
    style PG fill:#a29bfe,stroke:#6c5ce7
    style PH fill:#636e72,stroke:#2d3436,color:#fff

5.1 ponytail（核心引擎）

这是主力技能，默认激活。它会强制 AI 按照梯子逻辑来写代码，贯穿每一次代码生成。

触发方式：自动激活，或者输入 /ponytail

行为改变：AI 从”我能做什么”转向”我应该做什么”

5.2 ponytail-review（代码审查）

专门审查代码过度工程化的问题。它只关注一件事：哪里可以删？

触发方式：/ponytail-review

输出格式：每个发现一行，标签化

标签 含义 例子
delete: 死代码、用不上的灵活性 写了个配置类，但配置值从没变过
stdlib: 手写的轮子，标准库有现成的 自己写了个校验器，re.match 一行搞定
native: 依赖干的事，平台原生就能做 引入 moment.js 只为格式化一个日期
yagni: 过度抽象，只有一种实现的接口 定义了 IRepository 接口，但只有一个实现类
shrink: 同样逻辑，能写更短 手动循环拼字典，dict(zip(...)) 一行搞定

实际输出示例：

1
2
3
4
5
L12-38: stdlib: 27-line validator class. "@" in email, 1 line, real validation is the confirmation mail.
L4: native: moment.js imported for one format call. Intl.DateTimeFormat, 0 deps.
repo.py:L88: yagni: AbstractRepository with one implementation. Inline it until a second one exists.
L52-71: delete: retry wrapper around an idempotent local call. Nothing replaces it.
L30-44: shrink: manual loop builds dict. dict(zip(keys, values)), 1 line.

最后给一个总数：net: -156 lines possible.

5.3 ponytail-audit（全仓库审计）

ponytail-review 的全仓库版。不是看某个 diff，而是扫描整个代码库，给你一份”瘦身清单”。

触发方式：/ponytail-audit

和 review 的区别：

维度 ponytail-review ponytail-audit
范围 当前 diff 整个仓库
输出 按行号排序 按可砍代码量排序
用途 代码审查 代码审计、技术债清理

5.4 ponytail-debt（技术债清单）

Ponytail 懒归懒，但不是无脑砍。有些简化是有”已知上限”的，它会用 ponytail: 注释标记出来。

ponytail-debt 就是把这些标记收集起来，变成一份技术债清单。

触发方式：/ponytail-debt

输出格式：

1
2
server.py:42, global lock. ceiling: single-threaded bottleneck. upgrade: per-account locks if throughput matters.
cache.py:18, in-memory TTL dict. ceiling: single-process only. upgrade: Redis when you need multi-process.

最后统计：3 markers, 1 with no trigger.

5.5 ponytail-gain（效果看板）

一个成绩单，展示 ponytail 的实际效果。基于 5 个日常任务在 3 个模型上的基准测试中位数。

触发方式：/ponytail-gain

输出：

1
2
3
4
5
6
7
ponytail gain                     benchmark median · 5 tasks · 3 models

Lines of code   no-skill  ████████████████████  100%
                ponytail  ██▌·················    6–20%   ▼ 80–94%
Cost            no-skill  ████████████████████  100%
                ponytail  █████▌··············   23–53%  ▼ 47–77%
Speed           ponytail  ▸ 3–6× faster

5.6 ponytail-help（命令手册）

速查卡片，快速查看所有 ponytail 模式和命令。

六、Ponytail vs 其他 Skills：它在技能生态中的位置

要理解 Ponytail 的独特价值，需要把它放到整个 Skills 生态中来看。

技能分类

graph TB
    subgraph "过程类技能（怎么做事）"
        SP["using-superpowers<br/>技能调度器<br/>━━━━━━<br/>决定用哪个技能"]
        B["brainstorming<br/>头脑风暴<br/>━━━━━━<br/>需求探索→设计→评审"]
        WD["writing-plans<br/>写计划<br/>━━━━━━<br/>设计→实施计划"]
    end
    
    subgraph "领域类技能（做什么事）"
        FD["frontend-design<br/>前端设计<br/>━━━━━━<br/>UI/UX 专业指导"]
        SC["skill-creator<br/>技能创建<br/>━━━━━━<br/>创建/迭代技能包"]
        SD["systematic-debugging<br/>系统调试<br/>━━━━━━<br/>结构化排错"]
    end
    
    subgraph "行为约束类技能（怎么做人）"
        PT["ponytail<br/>懒惰模式<br/>━━━━━━<br/>最简方案优先"]
    end
    
    SP -->|"调度"| B
    SP -->|"调度"| FD
    SP -->|"调度"| PT
    
    style SP fill:#636e72,stroke:#2d3436,color:#fff
    style PT fill:#ff6b6b,stroke:#d63031,color:#fff
    style B fill:#74b9ff,stroke:#0984e3
    style WD fill:#74b9ff,stroke:#0984e3
    style FD fill:#55efc4,stroke:#00b894
    style SC fill:#55efc4,stroke:#00b894
    style SD fill:#55efc4,stroke:#00b894

关键区别

技能 定位 解决的问题 激活时机
using-superpowers 技能调度器 “该用哪个技能？” 每次对话开始
brainstorming 过程技能 “需求不清，先探索” 创意工作之前
ponytail 行为约束 “AI 太勤快了” 每次代码生成

协同工作流

sequenceDiagram
    participant U as 用户
    participant SP as superpowers
    participant B as brainstorming
    participant P as ponytail
    participant AI as AI Agent

    U->>SP: "帮我加个用户系统"
    SP->>B: 先头脑风暴
    B->>U: 需求探索：需要哪些功能？
    U->>B: 注册、登录、个人资料
    B->>B: 设计方案：3 种实现路径
    B->>U: 方案评审：推荐方案 A
    U->>B: 批准方案 A
    B->>P: 进入实现，Ponytail 生效
    P->>AI: 强制执行梯子逻辑
    AI->>U: 产出：最简可用代码
    
    Note over P,AI: Ponytail 在整个实现阶段<br/>持续约束 AI 的行为

和 brainstorming 的对比

这两个技能经常被混淆，但它们解决的是不同阶段的问题：

维度 brainstorming ponytail
阶段 设计阶段 实现阶段
问题 “不知道做什么” “做得太多了”
方法 提问→探索→设计 梯子→规则→约束
产出 设计文档 代码
思维方式 发散（探索可能性） 收敛（砍掉不必要的）

一个有趣的互补：brainstorming 里的规则说”YAGNI ruthlessly”（无情地砍需求），ponytail 里的规则说”禁止未要求的抽象”。它们从两端夹击过度工程化——brainstorming 在设计阶段砍需求，ponytail 在实现阶段砍代码。

七、为什么 Ponytail 能做到这种效果？

这是最值得深挖的部分。Ponytail 的魔力不在于它用了什么黑科技，而在于它精准地解决了 AI 编程的一个根本问题。

问题根源：AI 太”勤快”了

大语言模型有一个特点：它倾向于生成更多内容。你让它写个函数，它会给你加上文档字符串、类型注解、错误处理、日志记录、单元测试……每一项单拿出来都”对”，但加在一起就是过度工程化。

这不是 AI 的 bug，而是它的训练方式决定的。AI 被训练成”尽量多做”，而不是”判断什么该做”。

用一个比喻：AI 就像一个刚入行的 Junior 开发，急于证明自己很能干。 你让他写个工具函数，他恨不得把设计模式全套上，生怕你觉得他”不够专业”。

Ponytail 的解决思路：规则约束 + 梯子逻辑

Ponytail 本质上是一个行为约束层，它通过明确的规则，强制 AI 从”我能做什么”转向”我应该做什么”。

graph TB
    subgraph "AI 默认行为"
        A1["用户需求"] --> A2["AI 思考"]
        A2 --> A3["我能做什么？"]
        A3 --> A4["生成尽可能完善的代码"]
        A4 --> A5["过度工程化"]
    end
    
    subgraph "Ponytail 约束后"
        B1["用户需求"] --> B2["AI 思考"]
        B2 --> B3["爬梯子：需要做吗？<br/>有现成的吗？<br/>标准库能搞定吗？"]
        B3 --> B4["生成最简可用代码"]
        B4 --> B5["最小可行方案"]
    end
    
    style A5 fill:#ff6b6b,stroke:#d63031,color:#fff
    style B5 fill:#55efc4,stroke:#00b894
    
    style A3 fill:#fdcb6e,stroke:#f39c12
    style B3 fill:#74b9ff,stroke:#0984e3

三个关键点：为什么规则约束有效

1. 明确的否定指令

Ponytail 不是模糊地说”写简洁点”，而是有明确的否定规则：

  • 禁止未要求的抽象
  • 禁止样板代码
  • 禁止”为了以后可能用到”的预留

这些规则就像给 AI 画了红线，它知道什么不能做。

为什么有效？ 因为 LLM 擅长的是”模式匹配”——你给它明确的否定示例，它就知道要避开。模糊的指令（”写简洁点”）对 LLM 来说效果很差，因为它不知道”简洁”的边界在哪。

2. 梯子是条件反射，不是研究

Ponytail 强调：”梯子是反射动作，不是研究项目”。这意味着 AI 不需要花时间思考”我该用哪个方案”，而是按照固定顺序自动检查，第一个满足条件的方案就是最终方案。

这大大减少了决策成本。

用一个类比：你去超市买东西，如果每次都要比较 10 个品牌、看成分表、查评价，你会很累。但如果你有个固定规则——“只买最便宜的，除非最便宜的那个品牌我信不过”——购物就变成了一件轻松的事。Ponytail 就是给 AI 这样的”购物规则”。

3. “已知上限”的诚实标记

Ponytail 不是盲目追求最简。当简化有已知代价时（比如全局锁、O(n²) 复杂度），它会用 ponytail: 注释标记出来。

这种诚实很重要——它承认”这是偷懒，但我知道边界在哪，知道什么时候该升级”。这比”假装完美”要靠谱得多。

类比：外科医生的”不伤害”原则

医学上有个古老的原则：”Primum non nocere”——首先，不伤害。

Ponytail 就是编程版的”不伤害”原则：在你能确认需要之前，不要添加代码。 每一行代码都是潜在的维护成本、潜在的 bug 来源。能不写就不写，这不是懒，是负责任。

八、Ponytail 的适用边界

Ponytail 不是万能的，它有明确的适用范围：

适合的场景

graph LR
    subgraph "Ponytail 大显身手"
        S1["日常编码<br/>写函数、加功能、修 bug"]
        S2["重构<br/>简化现有代码"]
        S3["代码审查<br/>找出过度工程化"]
        S4["新项目启动<br/>避免一开始就过度设计"]
    end
    
    style S1 fill:#55efc4,stroke:#00b894
    style S2 fill:#55efc4,stroke:#00b894
    style S3 fill:#55efc4,stroke:#00b894
    style S4 fill:#55efc4,stroke:#00b894

不适合的场景

graph LR
    subgraph "Ponytail 不该插手"
        N1["非编码任务<br/>翻译、写散文、总结文章"]
        N2["安全关键代码<br/>输入验证、错误处理、安全措施"]
        N3["用户明确要求完整实现<br/>如果用户说'我就是要完整版'<br/>那就做完整版，不争论"]
    end
    
    style N1 fill:#ff6b6b,stroke:#d63031,color:#fff
    style N2 fill:#ff6b6b,stroke:#d63031,color:#fff
    style N3 fill:#ff6b6b,stroke:#d63031,color:#fff

Ponytail 自己也说了：”不要用于非编码请求（general knowledge, prose, translation, summaries, recipes）。”

九、实战：一个完整的对比案例

让我们用一个真实场景来对比有无 Ponytail 的区别。

需求：”写一个限流器”

没有 Ponytail 的 AI 会怎么做

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
from typing import Callable, Any, Optional
from functools import wraps
import time
import threading
from collections import defaultdict
from dataclasses import dataclass, field
import logging

logger = logging.getLogger(__name__)


@dataclass
class RateLimitConfig:
    """限流器配置"""
    max_requests: int = 100
    window_seconds: int = 60
    strategy: str = "sliding_window"  # fixed_window, sliding_window, token_bucket
    burst_size: Optional[int] = None
    retry_after: bool = True
    custom_key_func: Optional[Callable] = None


class RateLimitExceeded(Exception):
    """限流异常"""
    def __init__(self, message: str, retry_after: Optional[float] = None):
        super().__init__(message)
        self.retry_after = retry_after


class RateLimiter:
    """
    通用限流器
    
    支持多种限流策略：
    - 固定窗口
    - 滑动窗口
    - 令牌桶
    
    线程安全，支持分布式部署（通过 Redis 后端）。
    """
    
    def __init__(self, config: Optional[RateLimitConfig] = None):
        self.config = config or RateLimitConfig()
        self._store = defaultdict(list)
        self._lock = threading.RLock()
        self._tokens = {}
        self._last_refill = {}
        
    def _get_key(self, identifier: str, func_name: str) -> str:
        if self.config.custom_key_func:
            return self.config.custom_key_func(identifier, func_name)
        return f"{func_name}:{identifier}"
    
    def _fixed_window(self, key: str) -> bool:
        # ... 30 行实现
        pass
    
    def _sliding_window(self, key: str) -> bool:
        # ... 40 行实现
        pass
    
    def _token_bucket(self, key: str) -> bool:
        # ... 50 行实现
        pass
    
    def check(self, identifier: str, func_name: str = "default") -> bool:
        with self._lock:
            key = self._get_key(identifier, func_name)
            
            if self.config.strategy == "fixed_window":
                allowed = self._fixed_window(key)
            elif self.config.strategy == "sliding_window":
                allowed = self._sliding_window(key)
            elif self.config.strategy == "token_bucket":
                allowed = self._token_bucket(key)
            else:
                raise ValueError(f"Unknown strategy: {self.config.strategy}")
            
            if not allowed and self.config.retry_after:
                retry_after = self._calculate_retry_after(key)
                raise RateLimitExceeded(
                    f"Rate limit exceeded for {key}",
                    retry_after=retry_after
                )
            
            return allowed
    
    def _calculate_retry_after(self, key: str) -> float:
        # ... 15 行实现
        pass
    
    def reset(self, identifier: str, func_name: str = "default"):
        with self._lock:
            key = self._get_key(identifier, func_name)
            self._store[key] = []
            self._tokens.pop(key, None)
            self._last_refill.pop(key, None)
    
    def decorator(self, func: Callable) -> Callable:
        @wraps(func)
        def wrapper(*args, **kwargs):
            identifier = self._extract_identifier(args, kwargs)
            self.check(identifier, func.__name__)
            return func(*args, **kwargs)
        return wrapper
    
    def _extract_identifier(self, args: tuple, kwargs: dict) -> str:
        # ... 20 行提取逻辑
        pass

产出：约 150 行代码，3 种策略，完整异常处理，装饰器支持。

有 Ponytail 的 AI 会怎么做

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
import time
from functools import wraps
from collections import defaultdict

def rate_limit(max_calls, period):
    """Simple sliding window rate limiter."""
    calls = defaultdict(list)
    
    @wraps(max_calls)  # Note: max_calls is the decorator arg
    def decorator(func):
        @wraps(func)
        def wrapper(*args, **kwargs):
            now = time.time()
            key = func.__name__
            calls[key] = [t for t in calls[key] if now - t < period]
            if len(calls[key]) >= max_calls:
                raise RuntimeError(f"Rate limit: {max_calls}/{period}s")
            calls[key].append(now)
            return func(*args, **kwargs)
        return wrapper
    return decorator

# Usage:
# @rate_limit(10, 60)  # 10 calls per minute
# def my_api(): ...

产出：约 15 行代码，一种策略，够用。

Ponytail 的注释：skipped: 3-strategy config, custom key func, distributed backend. add when single-process sliding_window isn't enough.

对比总结

维度 无 Ponytail 有 Ponytail
代码量 ~150 行 ~15 行
功能 3 种策略 + 配置 + 装饰器 1 种策略 + 装饰器
可用性 完整 够用
维护成本 高 低
文件大小 8KB+ 1KB

十、总结

Ponytail 的核心价值可以用三句话概括：

  1. 它是一个行为约束层，让 AI 从”我能做什么”转向”我应该做什么”
  2. 它是一个优先级排序，先问”要不要做”，再问”怎么做最简”
  3. 它是一个诚实的简化者，知道什么该偷懒，什么不该

使用 Ponytail 之后，你会发现 AI 生成的代码少了，但更好了。因为少掉的那些，本来就不该存在。

最好的代码，是没写出来的代码。

快速参考

命令 作用
/ponytail 激活核心懒惰模式（默认 full）
/ponytail lite 切到提案级
/ponytail ultra 切到极端 YAGNI
/ponytail-review 审查当前 diff 的过度工程化
/ponytail-audit 全仓库审计
/ponytail-debt 收集 ponytail: 技术债
/ponytail-gain 查看效果看板
/ponytail-help 速查卡片
stop ponytail 关闭 ponytail

本文基于 Ponytail v1.0 的 SKILL.md 文档和实际使用经验整理。