Ponytail v4 强化基准：三条约十行的新规则，如何在不增加一行膨胀代码的前提下同时赢得 Caveman 对决

本文基于 Ponytail 仓库中 2026-06-12 的基准报告 2026-06-12-v4-hardening-vs-caveman.md，完整还原 Ponytail v4「强化版」（hardening）的规则改动、六个构建任务 + 两个扩展任务的 A/B 实测数据、对抗性安全探针结果与验收标准，并结合 skills/ponytail/SKILL.md、scripts/check-rule-copies.js 等仓库源码，说明这些规则如何在运行时被注入、被一致性校验保护，以及为什么「加测试反而更小」是本次实验最核心的结论。读完后你可以理解一个极简主义 Agent 技能从「写得更少」进化到「写得更少且更可靠」的完整方法论与验证体系。

1. 实验背景：一次针对强化简报的回应

Ponytail 是一个让 AI Agent「像房间里最懒的资深工程师一样思考」的技能（skill），核心理念是「最好的代码是你从未写过的代码」。它的对标者 Caveman（JuliusBrussee/caveman）是一个「措辞压缩」技能：把回答压成电报体以省 token，但明确要求代码保持正常写法（其 存档副本 的 Boundaries 一节原文即 "Code/commits/PRs: write normal"）。两者的差异是结构性的：Ponytail 管的是「写什么代码」，Caveman 管的是「怎么说话」。

2026-06-12 这次基准是对一份外部强化简报（hardening brief）的回应。实验设置如下：

• 同一套任务：6 个编码任务（A 日志分析 CLI、B 文件同步、C 分发器、D 校验、E 认证、F 账本），规格说明为事后重建（原始规格未保留，两个新臂拿到的文本完全一致）；
• 同一套评分器：LOC 计分器自动发现各臂，成本口径统一为「git diff --numstat 插入行数 + 新文件 LOC」；
• 同一套对抗探针：独立执行的安全/并发检查脚本；
• 同一模型、每任务 × 每臂各开一个全新 subagent（共 16 次运行）；
• 明确的适用前提：该 harness 与更早的 Cursor 原始运行不同，因此对旧 treatment 数字的对比只是方向性的（directional）；但 ponytail v4 对 Caveman 的正面对决是同模型、同 harness 的，可直接比较。

一个细节值得注意：Caveman 臂使用的是其 SKILL.md 原文（full 强度级别），并原样保存在 benchmarks/arms/caveman-SKILL.md，保证了对方的规则是逐字复制的，没有经过裁剪。

2. v4 的三条强化规则（约 10 行提示词）

报告标题里的 "hardening" 指的是给 Ponytail 补上三类此前缺失的行为约束。三条规则总共只花了约 10 行提示词，但它们分别回应了极简主义写法的三个经典质疑：没有检查的懒代码是半成品、砍掉的角落必须留名、两个一样短的 stdlib 方案该选哪个。

2.1 测试反射（Test reflex，简报 5.1）

非平凡逻辑必须留下一个可运行的检查：assert 风格的 demo()/__main__ 自检，或一个小的 test_*.py。不用测试框架，一行代码级别的改动不需要测试。

这条规则直接写进了当前的 skills/ponytail/SKILL.md，「When NOT to be lazy」一节的原文是：

Lazy code without its check is unfinished. Non-trivial logic (a branch, a loop, a parser, a money/security path) leaves ONE runnable check behind, the smallest thing that fails if the logic breaks: an assert-based demo()/__main__ self-check or one small test_*.py. No frameworks, no fixtures, no per-function suites unless asked. Trivial one-liners need no test, YAGNI applies to tests too.

注意措辞中的两处克制：「ONE runnable check」（恰好一个，防止顺手写全套件）和「YAGNI applies to tests too」（测试也要做减法）。这条规则在规则副本体系里的地位见 scripts/check-rule-copies.js：'ONE runnable check' 被列为 must-not-drift 的规则不变量之一，只要 SKILL.md 或 AGENTS.md 中这句措辞被改动，check-rule-copies.js 就会失败并提示「propagate it everywhere」。

2.2 天花板注释（Ceiling comments，简报 5.2）

任何带有已知上限（ceiling）的 ponytail: 捷径，必须在注释中同时写清上限是什么和升级路径。对应 SKILL.md 第 64 行：

Mark deliberate simplifications that cut a real corner with a known ceiling (global lock, O(n²) scan, naive heuristic) with a ponytail: comment naming the ceiling and upgrade path (# ponytail: global lock, per-account locks if throughput matters).

规则里自带的示例就是本报告 F 任务账本的真实场景：全局锁 + 「吞吐量重要时换每账户锁」。它的工程意义在于把「简化决策」从聊天上下文里搬到代码里——后来的审阅者不需要知道当时 Agent 是怎么想的，代码本身自解释。

2.3 稳健变体规则（Robust variant rule，简报 5.3）

两个大小相同的 stdlib 方案之间，选边界情况正确的那个。对应 SKILL.md 第 63 行：

Two stdlib options, same size? Take the one that's correct on edge cases. Lazy means writing less code, not picking the flimsier algorithm.

这句话的后半句是对「lazy」一词的再定义：懒是少写代码，不是选脆弱的算法。check-rule-copies.js 中用 'flimsier algorithm' 作为这条规则的不变量指纹。

2.4 落点：五处副本 + hook 兜底 + 一条审查护栏

报告强调这三条规则不是只改了 SKILL.md 一处，而是同步落到了所有五处跨 Agent 规则副本、hook 兜底指令、以及 ponytail-review 的一条护栏。仓库中这套多副本机制可以逐一验证：

• hooks/ponytail-instructions.js 是 Claude hook 与 Pi extension 共用的指令构建器：正常运行时读取 SKILL.md 并按强度级别过滤（filterSkillBodyForMode），读文件失败时降级到内置的 getFallbackInstructions 兜底文本——兜底文本里同样包含「Between two same-size stdlib options, pick the one correct on edge cases」（第 63 行）和「non-trivial logic leaves ONE runnable check behind」（第 72 行），三条强化规则在兜底路径上也没有丢失；
• scripts/check-rule-copies.js 逐字节比对 .cursor/rules/ponytail.mdc、.windsurf/rules/ponytail.md、.clinerules/ponytail.md、.agents/rules/ponytail.md、.qoder/rules/ponytail.md、.github/copilot-instructions.md、.kiro/steering/ponytail.md 这些副本与 AGENTS.md 是否漂移；由于 SKILL.md 比压缩版 AGENTS.md 长，它改用「关键短语存在性」校验（INVARIANTS 列表），其中同时固定了 'ONE runnable check'、'naive heuristic'、'flimsier algorithm'——恰好覆盖 v4 的三条规则，外加四条「不许偷懒的安全例外」（信任边界校验、防数据丢失、安全、无障碍）；
• ponytail-review 的护栏见 skills/ponytail-review/SKILL.md 第 54-55 行：「A single smoke test or assert-based self-check is the ponytail minimum, not bloat, never flag it for deletion.」——保证审查技能不会把新加的最低限度检查当作「膨胀」建议删掉。

这条「护栏」正是报告验收标准里 Reviewability 一项能成立的前提：如果 ponytail-review 把测试反射当成要删的东西，v4 的规则体系就自相矛盾了。

3. 构建阶段：v4 在全部六个任务上不劣于 v3，且带着检查

构建阶段的指标是非空 LOC / .py 文件数（评分器验证）。四个臂分别是：Control（无技能，继承自原始 Cursor harness）、Treatment v3（Ponytail v3 的历史数据）、Ponytail v4（本次）、Caveman（本次同模型）。

任务	Control (orig)	Treatment v3 (orig)	Ponytail v4	Caveman
A 日志 CLI	970 / 13	150 / 1	145 / 2	283 / 1
B 文件同步	587 / 9	175 / 2	99 / 1	228 / 2
C 分发器	726 / 13	85 / 1	73 / 1	396 / 10
D 校验	343 / 8	93 / 1	70 / 1	218 / 3
E 认证	155 / 1	74 / 1	49 / 1	148 / 1
F 账本	162 / 1	86 / 1	54 / 1	167 / 1
合计	2943	663	490	1440

两个结论：

1. 测试反射没有造成膨胀蠕变（bloat creep）：v4 在每个任务上都低于或持平 v3（−3% 到 −43%），前提是它这次在全部六个臂里都交付了一个可运行检查。这是整篇报告最有信息量的事实——「加检查必然变长」的直觉被数据否定了。
2. v4 总量只有 Caveman 的 34%。唯一 Caveman 文件数占优的地方是任务 A（1 个文件 vs 2 个）：v4 多出的第二个文件是 24 行的回归检查脚本，Caveman 没有交付。报告明确拒绝「删掉这个检查来赢文件数」：那等于为赢尺寸而牺牲安全条款，简报禁止这样做。

Caveman 在任务 C 上输得最多（396 LOC / 10 个文件 vs v4 的 73 LOC / 1 个文件），与其「代码写正常」的自述定位一致：它省的是话语 token，不是代码体量。

4. 扩展阶段：惊喜需求下 v4 便宜 74–79%

扩展阶段给已交付的 C（分发器）和 D（校验）追加「意外需求」，用 git 度量改动量：

指标	C v4	C caveman	D v4	D caveman
改动行数（插入 + 新文件 LOC）	41	156	55	257
触及文件数	1	7	1	3
扩展后仍正确	yes	yes	yes	yes

两个臂都满足了需求：C 中是鸭子类型的 registry，D 中是 @rule 注册表；扩展后两臂的 demo 重跑都 exit 0。这一节验证的是极简代码的可成长性——代码小不等于难以改动，v4 的结构在吸收新需求时的 diff 反而比 Caveman 小一个数量级（41 vs 156、55 vs 257）。

5. 安全性：对抗探针独立执行，两臂均满分

对抗性探针（adversarial probes）在构建产物上独立执行，不依赖 Agent 自述：

探针	v4	caveman
安全探针（任务 E，8 项检查）	8/8	8/8
并发探针（任务 F，6 项检查）	6/6	6/6

即新增三条规则没有引入任何安全回退。v4 在任务 E（认证）的具体实现是：PBKDF2-HMAC-SHA256（60 万次迭代）+ 16 字节 secrets 盐 + hmac.compare_digest 常数时间比较 + token_urlsafe(32)。任务 F（账本）保留「整数分 + 全局锁」，天花板注释按 5.2 设计点名了升级路径（换每账户锁）——而 Caveman 直接实现了每账户锁，代码量是 v4 的 3 倍。两者都安全，差别在于 v4 把「何时需要加锁粒度」的决策显式留给了未来的维护者，而不是预付 3 倍代码。

6. 正确性：19/19 独立重跑全部通过

19 次独立重跑（14 次构建阶段的 demo/测试 + 5 次扩展后）全部 exit 0。正确性的验证方式与 benchmarks/README.md 中 correctness.js 的「gate」思路一致：不是看 Agent 说什么，而是把产出的代码真正跑一遍，跑不过直接判负。

7. 验收标准（简报 §5.6）逐条核对

报告按简报的五条验收标准逐条判定：

1. 探针 100% — 通过（8/8 + 6/6）；
2. 每个 treatment 臂都交付可运行检查 — 通过（A：test_loganalyze.py；B–F：assert 风格 __main__ 自检；全部实际执行过）。这是此前最大的缺口（原先只有 1/4 达标）；
3. LOC 在 v3 的 ~20% 以内 — 意图上通过：每个臂都低于或持平 v3（A −3%、C −14%；B/D/E/F 低于 25–43%——是更瘦，不是膨胀）；
4. 带天花板的 ponytail: 注释点名升级路径 — 通过，逐臂验证：F 全局锁→每账户锁、E 无 token TTL→加 TTL、C 顺序发送→异步/多线程 + 硬编码路由→路由表、D 特判 unique→DATASET_RULES 注册表、A 观测小时统计→全区间插补、B 无空目录处理→目录参数；
5. 对 Caveman 正面交锋 — 通过：每个维度都不劣，其中三个维度严格更优：
   • 安全：100% 打平（「≥」语义，从不为赢尺寸而回退安全）；
   • 尺寸：LOC 6/6 严格更优，文件数 5/6 不劣（任务 A 的备注见第 3 节）;
   • 扩展成本：两个任务均严格更优；
   • 可审查性：严格更优——v4 的每处简化都带 ponytail: 标记和天花板说明；Caveman 的代码只标记了规格允许的模拟传输，其余设计权衡写在聊天报告里，对后来的审阅者不可见。

第 5 条里的 Reviewability 维度值得单独强调：它度量的是「决策信息是否随代码交付」。天花板注释（5.2）的价值正是在这里兑现——设计权衡被编码为注释后，代码库本身就是文档。

8. 补遗：同模型 Control2 臂（同一天补齐）

原始表格里的 Control 数字继承自早期 Cursor harness，那个 harness 无法暴露 token 计数，因此 Control 臂严格说不是同模型可比。同一天补跑的六个 task*-control2 臂（无技能、「按生产常规构建」、同模型、同规格）把三个臂拉齐到同模型，得到完整的三方数据集（覆盖 6 次构建 + C/D 扩展）：

指标	Control2	Caveman	Ponytail v4
构建 LOC	3,629	1,440	490
分任务构建 LOC（A–F）	946/656/808/677/260/282	283/228/396/218/148/167	145/99/73/70/49/54
C/D 扩展改动行	378, 737	156, 257	41, 55
Agent token 合计	430,697	290,546	229,370（较 control2 −47%）
Agent 墙钟合计	2,749s	1,596s	821s（3.3x）
探针	8/8 + 6/6	8/8 + 6/6	8/8 + 6/6

两个诚实的限定：

• 墙钟时间带并行调度噪声（各臂并发运行，每格 n=1）；token 计数来自 Agent 遥测，是精确值；
• Control2 也通过了两套探针（8/8、6/6）和全部 10 次 demo/测试重跑，C/D 扩展同样复验。

这份同模型数据集后来取代了 README 中旧的 5 任务 v3 数字（旧数字仍存档于 2026-06-12-caveman-vs-ponytail.md）。从这份数据看，v4 相对无技能基线把 token 降了 47%、墙钟快了 3.3 倍、LOC 只有基线的约 13%，而安全探针不丢一分。

9. 残余问题：报告自己承认的边界

好的基准报告应该留「Residual」一节，这篇留了两条：

1. 任务 A 的尖峰检测算法仍是「观测小时均值 + 3σ」，没有用留一法/插补基线（Caveman 对小时区间做了零填充）。5.3 规则软化但没有消除朴素算法倾向——至少现在选择被文档化了（升级路径已按 5.2 写明），如果实践中出问题，是未来评测的候选项；
2. Caveman 是「代码按正常写」的措辞压缩技能，输在代码尺寸上是它的设计使然。报告认为真正有意义的结果不是「v4 更小」，而是「加上测试反射之后，Ponytail 的尺寸优势和 100% 探针纪录都没有被侵蚀」。

10. 对仓库的映射：这些数字背后有哪些可以读的实现

如果你想从这份基准报告继续深入仓库，以下路径构成了完整的证据链：

• 技能本体：skills/ponytail/SKILL.md——三条 v4 规则分别落在第 63-64 行（稳健变体、天花板注释）和第 107-112 行（测试反射）；
• 压缩版规则：AGENTS.md——同样三条规则的短表述，是各编辑器规则副本的规范来源；
• 一致性守护：scripts/check-rule-copies.js——用 INVARIANTS 列表保证规则措辞在 SKILL.md 与 AGENTS.md 之间不被悄悄改写，任何一条规则改动都会触发 CI 提醒传播；
• 运行时注入：hooks/ponytail-instructions.js——按 lite/full/ultra 过滤 SKILL.md 注入会话，文件读取失败时降级到内置兜底文本，兜底文本同样包含三条强化规则；
• 审查护栏：skills/ponytail-review/SKILL.md——明确「最低限度自检不算膨胀，永不建议删除」；
• 对照技能存档：benchmarks/arms/caveman-SKILL.md 与 benchmarks/arms/caveman.js、benchmarks/arms/ponytail.js、benchmarks/arms/baseline.js——三个臂的规则与调用封装；
• 同系列报告：2026-06-12-caveman-vs-ponytail.md（v1→v3 的迭代史，说明 v4 的起点）、2026-06-16-robustness-audit.md（回答「极简是否让弱模型写出错代码」的后续审计）。

11. 小结

Ponytail v4 强化实验用一次同模型的 A/B 基准回答了一个对极简主义 Agent 很关键的问题：补上「一个可运行检查、一条天花板注释、一条稳健变体选择」之后，极简写法会不会变胖、变脆？ 数据的答案是没有：构建 LOC 全任务不劣于 v3、总量仅为 Caveman 的 34%、扩展 diff 便宜 74–79%、对抗探针 14/14、19/19 独立重跑通过、token 较同模型无技能基线降 47%。而支撑这套规则不散架的，是仓库里一套可验证的工程机制：多副本字节级比对、规则不变量校验、hook 兜底文本同步、审查技能护栏。规则写在 SKILL.md 里，守规则的方式写进了脚本——这本身就是一种「天花板注释」：把每个约定的维护路径都显式点名。