Ponytail skills 深度解析：省 token 且不掉质量的机制
解析对象： D:\code\store\ponytail__DietrichGebert\skills 目录下全部 6 个技能，解析日期 2026-08-31。
一句话结论： ponytail 省 token 的方式不是"少说话"，而是"少建造"——用七级阶梯在动手前砍掉不该写的代码；不掉质量的底气则来自一套"负空间规则 + 阅读豁免 + 最小验证 + 债务显性化"的四重护栏，全部写死在 skill 文本里，并有对抗性基准测试背书（安全项 20/20 全过，对照组裸 one-liner 提示词掉了 1 个）。
先纠正一个最容易误解的点：ponytail 明确声明 "Ponytail governs what you build, not how you talk"（管你建什么，不管你怎么说）——压缩输出措辞是另一个技能 caveman 的职责，ponytail 刻意不碰。所以它的 token 节省发生在生成的代码量上，不是措辞上。
1. 六个技能全景
| 技能 | 行数 | 类型 | 职责 | 触发方式 |
|---|---|---|---|---|
ponytail | 120 | 常驻模式 | 核心"懒资深工程师"规则集（人格 + 阶梯 + 规则 + 护栏） | hooks 每回合注入；/ponytail [lite|full|ultra] |
ponytail-review | 57 | 一次性 | 审查当前 diff 的过度工程，产出删除清单 | /ponytail-review |
ponytail-audit | 41 | 一次性 | 全仓库过度工程审计，按可删行数排序 | /ponytail-audit |
ponytail-debt | 44 | 一次性 | 收割代码里所有 ponytail: 注释成债务台账 | /ponytail-debt |
ponytail-gain | 50 | 一次性 | 展示实测收益记分板（只读展示） | /ponytail-gain |
ponytail-help | 71 | 一次性 | 全命令速查卡 | /ponytail-help |
整个 skills 目录只有 383 行——它自己的技能文本就践行了极简主张。只有 ponytail 是常驻模式，其余五个都是一次性（one-shot）、只读、不改任何文件的操作型技能。这个"1 个核心 + 5 个卫星"的分工结构本身就是一个值得抄的设计。
2. 核心技能 ponytail 的解剖
ponytail/SKILL.md 是全家的心脏，hook 注入的就是它（按强度过滤后的正文）。120 行分成 8 个段落，每段各司其职：
2.1. 人格设定（Persona）
You are a lazy senior developer. Lazy means efficient, not careless. You have
seen every over-engineered codebase and been paged at 3am for one. The best
code is the code never written.不用抽象规则开头，而用一个可代入的人格原型开头。"懒 = 高效 ≠ 粗心"这个定义在第一句就立住了，把"懒"的贬义歧义提前拆掉。"凌晨 3 点被过度工程化的代码库页过"给了模型一个具体的记忆锚点——这类具象人格比抽象指令的遵循率高得多。
2.2. 持久性（Persistence）
"ACTIVE EVERY RESPONSE. No drift back to over-building. Still active if unsure."——直接对抗 LLM 的指令漂移（instruction drift）：长会话里 agent 会逐渐"忘记"早期指令、漂回过度建造的默认倾向。这句话把"不确定时仍然生效"写死，配合 hook 每回合重新注入，双保险。
2.3. 七级阶梯（The ladder）——token 节省的真正发动机
写任何代码前，从上往下找到第一个成立的台阶就停：
- 这东西需要存在吗？（YAGNI，投机性需求直接跳过）
- 代码库里已经有了吗？（先看再写，重写几步之外就有的东西是"最常见的 slop"）
- 标准库能做吗？
- 平台原生特性能覆盖吗？（
<input type="date">而非日期库、CSS 而非 JS、数据库约束而非应用代码） - 已安装的依赖能解决吗？（永远不为几行事新增依赖）
- 能一行写完吗？
- 以上都不行：写能工作的最小实现。
关键约束在阶梯后面："阶梯是条件反射，不是研究项目——但它在你理解问题之后运行，而不是替代理解。先读任务和它触碰的代码、端到端追踪真实流程，然后再爬阶梯。" 这句话是质量护栏的第一根柱子。
另有一条独立的质量对齐规则：bug 修复 = 修根因不修症状——动手前 grep 目标函数的所有调用方，在共享函数里修一处，比每个调用方各加一个 guard 的 diff 更小。"懒"和"对"在这里方向一致，这是整个设计最聪明的地方：它不靠牺牲质量换省，而是重构了"省"的定义。
2.4. 规则（Rules）——全部写成可模式匹配的反模式
- 没有只有一个实现的接口、只造一个产品的工厂、永远不变的值的配置。
- 没有"为以后"的脚手架，以后会自己搭。
- 删除优先于新增。无聊优先于聪明——聪明是别人凌晨 3 点要解码的东西。
- 最少文件数。最短工作 diff 获胜——但必须先理解问题，在错误位置的最小改动不叫懒，叫第二个 bug。
- 复杂请求？交付懒版本并在同一条回复里质疑它，"做了 X；Y 已覆盖。需要完整版 X？说一声。"绝不停在可以默认的答案上。
- 两个同样短的 stdlib 方案，选边界情况正确的那个。懒是少写代码，不是挑更脆的算法。
2.5. 输出格式（Output）——压缩的是"解释"而非"代码"
Pattern: [code] → skipped: [X], add when [Y].代码优先，之后最多三行：跳过了什么、什么时候加回来。不写散文、不写功能巡礼、不写设计说明。"如果解释比代码还长，删掉解释——每一段为简化辩护的段落都是以散文形式走私回来的复杂度。"同时豁免：用户明确要求的解释（报告、走查、分阶段说明）不算债务，要给全——规则只针对未被请求的散文。
这个格式让"砍功能"变成透明决策：agent 不再默默砍（用户事后惊讶），而是显式声明"跳过了 X，触发条件 Y 时再加"。
2.6. 强度分级（Intensity）——三级递进 + 同一示例对照
| 级别 | 行为 |
|---|---|
| lite | 照要求建造，但用一行指出更懒的替代方案，让用户选 |
| full | 阶梯强制执行。stdlib 和原生优先。最短 diff、最短解释（默认） |
| ultra | YAGNI 极端主义。删除优先于新增。交付一行方案的同时质疑需求的其余部分 |
三个级别用同一个示例（"给这些 API 响应加个缓存"）对照展示：lite 交付缓存类但提示 lru_cache 一行替代；full 直接 @lru_cache(maxsize=1000) 并声明跳过了自建缓存类；ultra 拒绝加缓存直到 profiler 证明需要——"手写 TTL 缓存类是个带命中率统计的 bug 农场"。一个示例讲透三级差异，比三段抽象描述省得多。
2.7. 何时不许懒（When NOT to be lazy）——质量护栏的核心
这是回答"为什么不掉质量"最直接的一段，一张永不简化清单：
- 信任边界上的输入校验；
- 防止数据丢失的错误处理；
- 安全措施；
- 可访问性基础；
- 用户明确要求保留的任何东西（用户坚持要完整版 → 建造，不再争论）。
以及三条懒的豁免项：
- 理解问题永远不懒："阶梯缩短的是方案，从不缩短阅读。先完整追踪——改动触碰的每个文件、真实流程——再选台阶。跳过理解去交付小 diff 的懒是危险的那种：它伪装成效率，交付一个自信的错误修复。先读全，再懒。"
- 硬件永远不是纸面理想：真实时钟会漂移、真实传感器会读偏。留校准旋钮——物理世界需要最小模型看不见的调参。
- 没有检查的懒代码是半成品：非平凡逻辑（分支、循环、解析器、金额/安全路径）必须留下一个可运行的检查——最小的、逻辑坏了就会失败的东西：基于
assert的demo()/__main__自检或一个小test_*.py。不要框架、不要 fixtures、不要每函数测试套件。琐碎一行代码不需要测试——YAGNI 同样适用于测试。
2.8. 边界（Boundaries）
声明作用域（管建造不管言谈，可与 caveman 搭配）、停用方式（"stop ponytail" / "normal mode"）、级别持久性（保持到切换或会话结束）。
3. 省 token 的量化链条
官方 agentic 基准（真实 Claude Code 会话改真实 FastAPI + React 仓库，12 个功能任务，Haiku 4.5，n=4，对 git diff 计分）：
| 对比无技能基线 | LOC | tokens | 成本 | 时间 | 安全 |
|---|---|---|---|---|---|
| ponytail | -54% | -22% | -20% | -27% | 100% |
| caveman（只压缩措辞的对照） | -20% | +7% | +3% | +2% | 100% |
| 裸 "YAGNI + one-liner" 提示词 | -33% | -14% | -21% | -30% | 95% |
这张表能读出三层信息：
- token 节省（-22%）远小于 LOC 节省（-54%）。这正是设计意图的证据：阅读和理解阶段没有被压缩（阶梯不缩短阅读），压缩的是产出侧。代码少写了，输出 token、编辑操作、diff 尺寸随之变小，但输入侧的代码阅读量基本不变——所以质量不掉。
- 只压缩措辞的 caveman 反而 token +7%：说得短不等于花得少。真正省钱的杠杆在"建什么"，不在"怎么说"。
- 裸 one-liner 提示词 LOC 只省 33% 却掉了安全，ponytail 省 54% 还是 100% 安全——差别就在那张永不简化清单。基准里的
safe-path任务（把不可信文件名拼进基础目录）是整个论证的浓缩：裸提示词组 4 次里 1 次没防住../../目录穿越（6 行方案），ponytail 组 4/4 全防住（约 9.5 行方案）——多出来的那 3 行恰恰就是路径穿越检查。README 也诚实标注了边界：Haiku 级模型上这个差距就是二十分之一，是地板不是戏剧性结论，确定性检查也不等于安全证明；但在同等信息量下，"写少点"的裸指令掉护栏了，ponytail 没掉——方向与设计假设完全一致。
另外两点诚实的边界也值得学：单次生成场景的 80-94% 老数字被指有会话基线水分（issue #126），作者公开重做了公平基线；且对会花思考 token 反复斟酌的推理模型（GPT-5.5），token 节省可能反向——省的是输出，不是思考。
4. 卫星技能的设计：每个都是一次性、只读、带硬停止条件
4.1. ponytail-review：diff 级过度工程审查
- 只做减法审查：正确性 bug、安全漏洞、性能明确排除在范围外，"路由给正常审查"——技能之间不抢职责。
- 强制输出格式：
L<行号>: <标签> <删什么>. <替代品>.，五个标签delete/stdlib/native/yagni/shrink，每条发现一行，结尾必须有唯一指标net: -<N> lines possible.。 - 对比示例直接教文风：❌ 那条是典型的委婉 reviewer 腔（"这个类是否可能比必要的更复杂……你考虑过吗？"），✅ 是
L12-38: stdlib: 27行校验器类。'@' in email，1行，真正的校验是确认邮件。——用正反例把"发现 → 位置 → 删什么 → 用什么顶替"四元组钉死。 - 硬停止条件：没得删就输出
Lean already. Ship.然后停止。只列清单不动手改。
4.2. ponytail-audit：全仓库版
review 的仓库级变体：同样的五个标签，但按可删行数从大到小排序，结尾指标扩为 net: -<N> lines, -<M> deps possible.，并给了一张"猎物清单"（stdlib/平台已有的依赖、单实现接口、单产品工厂、纯委托的包装层、只导出一个东西的文件、死开关和死配置、手写 stdlib）。
4.3. ponytail-debt：债务台账——激进懒惰的安全阀
这个技能是整个体系的闭环关键。核心技能里规定：所有刻意走捷径的简化必须用 ponytail: 注释标明天花板和升级路径（例：# ponytail: 全局锁，吞吐量成为问题时换按账户锁）。debt 技能负责收割：
grep -rnE '(#|//) ?ponytail:' .扫全仓库，每条命中一行台账：<文件>:<行>, <简化了什么>. ceiling: <标明的上限>. upgrade: <重访的触发条件>.- 烂账风险标记：没写升级路径或触发条件的注释打
no-trigger标签——"这些是会悄悄烂掉的"。 - 结尾统计
<N> markers, <M> with no trigger.，没找到就No ponytail: debt. Clean ledger.
这套机制让 ultra 级别的激进删除变得安全：删狠了不怕，每刀都留了字据，台账随时能查。"later 不等于 never"——债务显性化是懒惰工程学的账本。
4.4. ponytail-gain：记分板 + 反幻觉条款
展示基准收益的纯展示技能，自带一段诚实边界（Honesty boundary）：这些是基准中位数，永远不要打印针对当前仓库的节省数字（"你在这里省了 X 行/token"）——没写的版本从未被写出来，线上仓库没有真实基线可减。唯一真实的仓库级数字来自 /ponytail-debt（可数的台账），记分卡指向它而不是编一个。这是把"禁止编造数据"直接写成技能条款，值得每个展示型 prompt 抄。
4.5. ponytail-help：速查卡
纯参考卡：三级强度表、六技能表、停用方式、默认模式配置（env > config > full）、更新流程。一次性展示，不改模式、不写文件。
5. 可迁移的设计手法总结
从"学习它怎么做到的"角度，提炼成可复用的清单：
- 把"省"定义在产出物上，不在表达上。压缩措辞省的是小钱（caveman 对照组 token 反而 +7%），砍掉不该写的代码省的是大钱（-54% LOC → -22% token）。要省 token，先问"这代码需要存在吗"，不是"这段话能短点吗"。
- 理解豁免 + 阅读豁免必须显式写出来。所有压缩类指令最大的风险都是模型把"少写"泛化成"少想"。ponytail 用两段加粗的段落反复堵这个洞："先读全，再懒"、"跳过理解的小 diff 是伪装成效率的第二个 bug"。
- 永不简化清单要具体到可执行。"注意安全"没有约束力；"信任边界上的输入校验、防数据丢失的错误处理、安全措施、可访问性基础"才有。清单越具体，模型越没空子可钻。
- 用"懒与对同向"的对齐规则替代"懒与对冲突"的权衡规则。修根因比修症状 diff 更小——当质量路线恰好也是省事路线时，模型不需要做取舍。
- 决策透明化格式：
[code] → skipped: [X], add when [Y].三行上限。砍功能必须留字据，用户永远知道少了什么、何时补。 - 债务显性化：
ponytail: <天花板>, <升级路径>注释约定 + 台账收割技能。允许激进，强制留痕。 - 人格原型 > 抽象规则。"凌晨 3 点被页过的懒资深工程师"一个形象顶十条守则。
- 反漂移要写明："ACTIVE EVERY RESPONSE. No drift. Still active if unsure."——不确定时仍生效。
- 一个示例讲完所有分支。三级强度共用同一个"加缓存"示例对照，正反例教审查文风（❌ 委婉腔 / ✅ 四元组一行）。
- 一次性技能要有硬停止条件和范围排除。"Lean already. Ship."、"Clean ledger."、正确性/安全/性能明确 out of scope——没有停止条件的技能会自造工作。
- 反幻觉条款前置。gain 技能"永不打印本仓库节省数字"那段，把模型最爱编的数字直接禁掉。
- 技能本体即论据。383 行写完 6 个技能，注入文本按强度过滤后更小——它自己的 token 占用就是它主张的证明。
贡献者
ruan-cat