Ponytail /ponytail-gain 技术解析用一张一次性 ASCII 记分板诚实量化 AI 代码瘦身收益【免费下载链接】ponytailMakes your AI agent think like the laziest senior dev in the room. The best code is the code you never wrote.项目地址: https://gitcode.com/GitHub_Trending/po/ponytail本文围绕 Ponytail 仓库中的 OpenCode 命令定义文件.opencode/command/ponytail-gain.md展开讲清/ponytail-gain这条命令的设计语义它如何把已发布的 benchmark 中位数渲染成一张纯 ASCII 记分板代码行数、成本、速度三条指标为什么它被严格约束为一次性、零副作用、只报告以及为什么它禁止输出任何本仓库节省了 X 行这类数字。读完后你可以完整复刻记分板上的每一组数字理解其背后 5 任务 × 3 模型 × 10 次运行的中位数测量方法并分清基准收益与单仓库收益的诚实边界。1./ponytail-gain是什么一条只读的一次性记分板命令1.1 命令定义本体命令的完整定义在 .opencode/command/ponytail-gain.md结构是 OpenCode 原生的frontmatter 提示词正文形式frontmatter 只有一行description: Show ponytails measured impact scoreboard (less code, cost, time)正文则是一段写给 Agent 的行为指令。把全文的关键约束拆开就是四句话展示记分板把已发布的 benchmark 中位数渲染成纯 ASCII 条形图——Lines of code无技能 100% vs ponytail 6–20%降 80–94%、Cost无技能 100% vs ponytail 23–53%降 47–77%、Speedponytail 快 3–6 倍条形长度表示测量区间标签承载精确数值the bar length shows the measured range, the label carries the exact figureOne shot, change nothing不切换模式、不写 flag 文件、不持久化任何东西Report onlyNEVER print a per-repo savings number永远不输出单仓库节省数字真实数字改指/ponytail-debt与/ponytail-audit。注意数字的出处声明5 everyday tasks; models Haiku, Sonnet, Opus; source benchmarks/ and the README且强调These are benchmark medians, not this repo——记分板展示的是基准测试的中位数不是当前仓库的实测值。这条区分是整条命令的灵魂第 3 节会深入展开。1.2 同一条规则的多平台分发从仓库目录结构看这段记分板规则并非只存在于 OpenCode 一份拷贝中而是被同步分发到各个宿主平台且内容逐字一致拷贝位置形态服务宿主.opencode/command/ponytail-gain.md斜杠命令定义OpenCodecommands/ponytail-gain.tomlTOML 命令descriptionprompt字段与 OpenCode 版正文一致通用命令格式skills/ponytail-gain/SKILL.mdSkill 文件增加触发词/ponytail-gain、ponytail gain、what does ponytail save、ponytail scoreboard 等Claude Code、Codex 等 skill-capable 宿主.openclaw/skills/ponytail-gain/SKILL.mdOpenClaw 技能包由skills/目录生成OpenClawREADME.md 的命令表把它的定位写得很直白/ponytail-gain是六个 ponytail 命令之一作用是 Show the measured impact scoreboard (less code, less cost, more speed) from the benchmark。与/ponytail设置 lite/full/ultra/off 强度不同它不改变任何运行状态——这也是为什么 Skill 版 skills/ponytail-gain/SKILL.md 专门用 One-shot display, not a persistent mode, and not a per-repo number 来描述自己。2. 记分板本体三条指标条与取值规则2.1 渲染模板命令文档要求渲染如下 ASCII 记分板skills/ponytail-gain/SKILL.md 中有完全相同的版本并给出了完整的 5 任务清单email validator、debounce、CSV sum、countdown timer、rate limiter三个模型 Haiku、Sonnet、Opusponytail 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 This repo: /ponytail-debt (shortcuts you deferred) /ponytail-audit (whats still cuttable)渲染约定值得注意条形长度 跨模型测量区间最短到最长右侧标签 精确数值。例如 LOC 行的6–20%表示三个模型上 ponytail 代码量占基线的 6% 到 20%而▼ 80–94%是换算后的削减幅度。底部的 This repo 两行不是指标而是明确的指向真实仓库级数字只能来自/ponytail-debt你延期处理的ponytail:捷径台账和/ponytail-audit当前还能删什么。2.2 逐条验算代码行数 6–20%降 80–94%记分板的每一条都能从 benchmarks/README.md 的中位数表格反推出来源。该基准的设定是三个对照组no skill 基线、caveman、ponytail× 三个模型Haiku/Sonnet/Opus× 5 个日常任务每格 10 次运行、报告中位数代码行数从回答的 fenced code block 中计数。LOC 中位数如下armHaikuSonnetOpusbaseline (no skill)518693256caveman11612067ponytail394451用 ponytail 除以各模型基线39/518 ≈ 7.5%、44/693 ≈ 6.4%、51/256 ≈ 20%——正好落在记分板标注的6–20%区间对应削减幅度80–94%。这与 benchmarks/README.md 的原文 ponytail writes 80-94% less code … on every Claude model 完全吻合。2.3 逐条验算成本与速度成本USD5 个任务2026-06-17 以 30 次运行复核armHaikuSonnetOpusbaseline (no skill)0.0300.1370.137ponytail0.0110.0350.079按 30 次运行复核的表格计算ponytail 成本约为基线的 26–58%即 benchmarks/README.md 原文所称 costs 42-75% less命令文档记分板标签采用的23–53%降 47–77%是同一测量在不同运行批次下的区间口径两者量级一致。延迟秒5 任务中位数armHaikuSonnetOpusbaseline (no skill)37.7124.158.7ponytail9.920.118.037.7/9.9 ≈ 3.8×、124.1/20.1 ≈ 6.2×、58.7/18.0 ≈ 3.3×即记分板上的3–6× faster。这三个区间共同说明一件事记分板上的数字不是拍脑袋的营销口径而是benchmarks/目录下可复现的测量结果。5 个任务分别是 email validator、JS debounce、CSV sum、React countdown、FastAPI rate limit完整定义见 benchmarks/promptfooconfig.yaml。3. 诚实边界为什么永远不输出 per-repo 数字3.1 不存在的基线命令文档中的核心禁令值得逐字理解These are benchmark medians, not this repo. NEVER print a per-repo savings number: the unbuilt version was never written, so there is no real baseline to subtract from in a live repo.逻辑链条是ponytail 的收益来自本来要写但被省掉的代码。在真实仓库里那个未构建版本从未被写出来因此根本不存在可相减的真实基线——任何你在这个仓库节省了 X 行/X token的说法都是虚构的。这正是/ponytail-gain把展示范围锁死在 benchmark 中位数、并明确标注 not this repo 的原因。3.2 单轮数字的自我修正80–94% 是任务上限不是平均值记分板的 LOC 数字来自单轮single-shot基准而仓库自己对这套数字做了严肃的勘误这也是理解/ponytail-gain定位的另一半背景。issue #126 指出单轮基准的两个问题真实 Agent 工作是多轮编辑而非一次补全裸模型基线会输出散文和多个选项答案行数混入了评论而非代码夸大了基线。为此仓库重建了 agentic 基准真实 Claude Code 无头会话编辑真实 FastAPI React 仓库以git diff增行计 LOC结果见 benchmarks/results/2026-06-18-agentic.mdvs no-skill baselineLOCtokenscosttimesafeponytail−54%−22%−20%−27%100%caveman (terse-prose control)−20%7%3%2%100%YAGNI one-liners prompt−33%−14%−21%−30%95%README.md 对此有一句精准的定性单轮基准报告的 80–94% against a fair agentic baseline that is the per-task ceiling, not the average——在存在过度构建陷阱的任务如 date picker 404 行降到 23 行−94%上能到 94%而在代码本已极简的任务上收益接近零12 个功能任务平均下来是 −54%。因此/ponytail-gain记分板展示 80–94% 时配合 benchmark median · 5 tasks · 3 models 的标注读者应理解为这是单轮日常任务上的区间跨任务平均值请参照 agentic 结果。3.3 替代出口/ponytail-debt与/ponytail-audit既然不能输出 per-repo 节省数字命令文档给出了仅有的两个真实仓库级数字来源/ponytail-debtponytail 的约定是用ponytail:注释标记每处被刻意简化的地方含上限与升级路径。该命令扫描全仓库这些注释、汇总成台账file:line, what was simplified. ceiling: … upgrade: …并给没有升级触发的条目打no-trigger标记——deferred 因此不会被静默变成 never。它是唯一可被逐行计数的仓库级账本定义见 .opencode/command/ponytail-debt.md 与 skills/ponytail-debt/SKILL.md/ponytail-audit审计整个仓库不是 diff中还能删的过度工程按delete / stdlib / native / yagni / shrink五类标签输出发现清单结尾给出可移除的净行数与依赖数定义见 .opencode/command/ponytail-audit.md。记分板末尾那两行 This repo: 指针就是这条边界的落点单仓库数字要么来自被逐行点过的 debt 台账要么来自 audit 的可删清单而不是凭空减去一个不存在的基线。4. 复现记分板数字benchmark 的运行方式/ponytail-gain展示的每个区间都可以在本地复现。以下命令均以 benchmarks/README.md 为准。4.1 单轮 promptfoo 复现Claude 三模型前置条件Anthropic API key 与Node.js ≥ 22.22.0promptfoo 引擎约束以及 Python 3、pandascorrectness 检查会调用 Python。cd benchmarks cp ../.env.example .env # 填入 ANTHROPIC_API_KEY npx promptfoolatest eval -c promptfooconfig.yaml --env-file ../.env --repeat 10 npx promptfoolatest view注意--env-file ../.env是必需的promptfoo 从当前目录benchmarks/而非仓库根目录读取.env。10 次重复对应记分板 median of 10 runs 的口径成本在 2026-06-17 曾以 30 次运行单独复核见 benchmarks/results/2026-06-17-cost-verification.md 的入口描述。4.2 本地模型复现Ollama不需要 API key 和 promptfoo直接对 Ollama 提供的任意模型跑ollama pull llama3.2 # 或任意其他模型 python benchmarks/benchmark-local.py --model llama3.2 --repeat 3benchmarks/results/2026-06-15-llama3.2-local.md 记录了预期结论该技能在指令跟随能力强的模型Claude 级别上表现好迁移到小本地模型时多步决策阶梯不能被可靠遵循。4.3 双指标设计loc.js与correctness.js记分板数字之所以敢展示是因为测量管线本身有闸门设计见 benchmarks/README.md 的指标表文件指标行为benchmarks/loc.jsloc纯测量——永远通过只记录行数benchmarks/correctness.jscorrect闸门——生成的代码不工作就判失败correctness.js会提取 fenced code block 并执行按任务的检查email、debounce、CSV 三项实际 spawn Python/Node 运行代码React countdown 与 FastAPI rate-limit 为结构性/关键词检查。这意味着一个坏掉的一行代码在 LOC 上得分再好看也会在 correctness 上失败——LOC 区间的前提是代码仍然正确。4.4 Agentic 基准可信度来源agentic 基准benchmarks/agentic/是记分板数字的防翻车补充值得了解两点隔离性每个 (任务, 组) 单元格独立运行n4每格一份全新仓库副本与全新 Agent 上下文。该文档还记录了一次自查出的污染 bugponytail 插件的SessionStarthook 曾对所有组含基线触发导致基线偷偷跑了 ponytail最终用--setting-sources project,local 每臂仅加载一个--plugin-dir修复——这正是为什么要信任其余数字的原因安全轴6 个手术式任务的安全性要求被刻意保持隐式产出函数随后被对抗性输入执行路径穿越、SQL 注入、伪造 token 等确定性、仅标准库。ponytail 20/20 全部安全而裸 one-liner 提示词组 19/20 丢了一次路径穿越检查。这支撑了 README 的总纲write only what the task needs, and never cut validation, error handling, security, or accessibility。5. 使用边界与触发汇总命令文档的 Boundaries 与 Report only 约束/ponytail-gain的行为契约是一次性展示被调用时渲染记分板仅此而已——不切换 lite/full/ultra 模式、不写 flag 文件、不持久化任何状态、不编辑任何文件数字口径只报 benchmark 中位数5 任务 × 3 模型 × 10 次运行条形表示区间、标签表示精确值绝不输出 per-repo 节省数字指代真实数字仓库级问题一律指向/ponytail-debt已点数的捷径台账与/ponytail-audit仍可削减项退出方式Skill 版明确 stop ponytail 或 normal mode 即可回退——由于该命令本身不改变状态回退的只是用户的提问语境而非任何被修改的配置。适用宿主方面README.md 注明 commands 需要 skill-capable 的宿主Claude Code、Codex、Devin CLI、OpenCode、Gemini、pi、Swival、Hermes Agent、Qoder。对 OpenCode 而言从仓库检出目录运行时.opencode/command/ 下的命令文件即构成斜杠命令集若以插件方式接入opencode.json中指向./.opencode/plugins/ponytail.mjs则额外注入每轮规则集与lite/full/ultra/off级别开关。无论哪种接入方式/ponytail-gain的输出都不依赖接入方式——它读取的永远是同一份已发布基准中位数。小结/ponytail-gain是 Ponytail 六条命令中最克制的一条它的全部产品价值不在于展示数字而在于展示数字的纪律——区间用条形、精确值用标签、来源标注到benchmarks/与 README、单仓库数字一票否决并改指 debt/audit 两条可验证的出口。对使用方而言它的正确读法是LOC 80–94% 削减是单轮日常任务上的测量区间跨任务 agentic 平均约 −54%成本与速度收益为同一测量的派生值且全部可通过第 4 节的命令在本地复现而对仓库开发者而言skills/ponytail-gain/SKILL.md、commands/ponytail-gain.toml 与各平台拷贝必须保持逐字一致node scripts/check-rule-copies.js与npm test是变更这类规则文本时的对齐检查手段。【免费下载链接】ponytailMakes your AI agent think like the laziest senior dev in the room. The best code is the code you never wrote.项目地址: https://gitcode.com/GitHub_Trending/po/ponytail创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Ponytail /ponytail-gain 技术解析：用一张一次性 ASCII 记分板诚实量化 AI 代码瘦身收益
Ponytail /ponytail-gain 技术解析用一张一次性 ASCII 记分板诚实量化 AI 代码瘦身收益【免费下载链接】ponytailMakes your AI agent think like the laziest senior dev in the room. The best code is the code you never wrote.项目地址: https://gitcode.com/GitHub_Trending/po/ponytail本文围绕 Ponytail 仓库中的 OpenCode 命令定义文件.opencode/command/ponytail-gain.md展开讲清/ponytail-gain这条命令的设计语义它如何把已发布的 benchmark 中位数渲染成一张纯 ASCII 记分板代码行数、成本、速度三条指标为什么它被严格约束为一次性、零副作用、只报告以及为什么它禁止输出任何本仓库节省了 X 行这类数字。读完后你可以完整复刻记分板上的每一组数字理解其背后 5 任务 × 3 模型 × 10 次运行的中位数测量方法并分清基准收益与单仓库收益的诚实边界。1./ponytail-gain是什么一条只读的一次性记分板命令1.1 命令定义本体命令的完整定义在 .opencode/command/ponytail-gain.md结构是 OpenCode 原生的frontmatter 提示词正文形式frontmatter 只有一行description: Show ponytails measured impact scoreboard (less code, cost, time)正文则是一段写给 Agent 的行为指令。把全文的关键约束拆开就是四句话展示记分板把已发布的 benchmark 中位数渲染成纯 ASCII 条形图——Lines of code无技能 100% vs ponytail 6–20%降 80–94%、Cost无技能 100% vs ponytail 23–53%降 47–77%、Speedponytail 快 3–6 倍条形长度表示测量区间标签承载精确数值the bar length shows the measured range, the label carries the exact figureOne shot, change nothing不切换模式、不写 flag 文件、不持久化任何东西Report onlyNEVER print a per-repo savings number永远不输出单仓库节省数字真实数字改指/ponytail-debt与/ponytail-audit。注意数字的出处声明5 everyday tasks; models Haiku, Sonnet, Opus; source benchmarks/ and the README且强调These are benchmark medians, not this repo——记分板展示的是基准测试的中位数不是当前仓库的实测值。这条区分是整条命令的灵魂第 3 节会深入展开。1.2 同一条规则的多平台分发从仓库目录结构看这段记分板规则并非只存在于 OpenCode 一份拷贝中而是被同步分发到各个宿主平台且内容逐字一致拷贝位置形态服务宿主.opencode/command/ponytail-gain.md斜杠命令定义OpenCodecommands/ponytail-gain.tomlTOML 命令descriptionprompt字段与 OpenCode 版正文一致通用命令格式skills/ponytail-gain/SKILL.mdSkill 文件增加触发词/ponytail-gain、ponytail gain、what does ponytail save、ponytail scoreboard 等Claude Code、Codex 等 skill-capable 宿主.openclaw/skills/ponytail-gain/SKILL.mdOpenClaw 技能包由skills/目录生成OpenClawREADME.md 的命令表把它的定位写得很直白/ponytail-gain是六个 ponytail 命令之一作用是 Show the measured impact scoreboard (less code, less cost, more speed) from the benchmark。与/ponytail设置 lite/full/ultra/off 强度不同它不改变任何运行状态——这也是为什么 Skill 版 skills/ponytail-gain/SKILL.md 专门用 One-shot display, not a persistent mode, and not a per-repo number 来描述自己。2. 记分板本体三条指标条与取值规则2.1 渲染模板命令文档要求渲染如下 ASCII 记分板skills/ponytail-gain/SKILL.md 中有完全相同的版本并给出了完整的 5 任务清单email validator、debounce、CSV sum、countdown timer、rate limiter三个模型 Haiku、Sonnet、Opusponytail 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 This repo: /ponytail-debt (shortcuts you deferred) /ponytail-audit (whats still cuttable)渲染约定值得注意条形长度 跨模型测量区间最短到最长右侧标签 精确数值。例如 LOC 行的6–20%表示三个模型上 ponytail 代码量占基线的 6% 到 20%而▼ 80–94%是换算后的削减幅度。底部的 This repo 两行不是指标而是明确的指向真实仓库级数字只能来自/ponytail-debt你延期处理的ponytail:捷径台账和/ponytail-audit当前还能删什么。2.2 逐条验算代码行数 6–20%降 80–94%记分板的每一条都能从 benchmarks/README.md 的中位数表格反推出来源。该基准的设定是三个对照组no skill 基线、caveman、ponytail× 三个模型Haiku/Sonnet/Opus× 5 个日常任务每格 10 次运行、报告中位数代码行数从回答的 fenced code block 中计数。LOC 中位数如下armHaikuSonnetOpusbaseline (no skill)518693256caveman11612067ponytail394451用 ponytail 除以各模型基线39/518 ≈ 7.5%、44/693 ≈ 6.4%、51/256 ≈ 20%——正好落在记分板标注的6–20%区间对应削减幅度80–94%。这与 benchmarks/README.md 的原文 ponytail writes 80-94% less code … on every Claude model 完全吻合。2.3 逐条验算成本与速度成本USD5 个任务2026-06-17 以 30 次运行复核armHaikuSonnetOpusbaseline (no skill)0.0300.1370.137ponytail0.0110.0350.079按 30 次运行复核的表格计算ponytail 成本约为基线的 26–58%即 benchmarks/README.md 原文所称 costs 42-75% less命令文档记分板标签采用的23–53%降 47–77%是同一测量在不同运行批次下的区间口径两者量级一致。延迟秒5 任务中位数armHaikuSonnetOpusbaseline (no skill)37.7124.158.7ponytail9.920.118.037.7/9.9 ≈ 3.8×、124.1/20.1 ≈ 6.2×、58.7/18.0 ≈ 3.3×即记分板上的3–6× faster。这三个区间共同说明一件事记分板上的数字不是拍脑袋的营销口径而是benchmarks/目录下可复现的测量结果。5 个任务分别是 email validator、JS debounce、CSV sum、React countdown、FastAPI rate limit完整定义见 benchmarks/promptfooconfig.yaml。3. 诚实边界为什么永远不输出 per-repo 数字3.1 不存在的基线命令文档中的核心禁令值得逐字理解These are benchmark medians, not this repo. NEVER print a per-repo savings number: the unbuilt version was never written, so there is no real baseline to subtract from in a live repo.逻辑链条是ponytail 的收益来自本来要写但被省掉的代码。在真实仓库里那个未构建版本从未被写出来因此根本不存在可相减的真实基线——任何你在这个仓库节省了 X 行/X token的说法都是虚构的。这正是/ponytail-gain把展示范围锁死在 benchmark 中位数、并明确标注 not this repo 的原因。3.2 单轮数字的自我修正80–94% 是任务上限不是平均值记分板的 LOC 数字来自单轮single-shot基准而仓库自己对这套数字做了严肃的勘误这也是理解/ponytail-gain定位的另一半背景。issue #126 指出单轮基准的两个问题真实 Agent 工作是多轮编辑而非一次补全裸模型基线会输出散文和多个选项答案行数混入了评论而非代码夸大了基线。为此仓库重建了 agentic 基准真实 Claude Code 无头会话编辑真实 FastAPI React 仓库以git diff增行计 LOC结果见 benchmarks/results/2026-06-18-agentic.mdvs no-skill baselineLOCtokenscosttimesafeponytail−54%−22%−20%−27%100%caveman (terse-prose control)−20%7%3%2%100%YAGNI one-liners prompt−33%−14%−21%−30%95%README.md 对此有一句精准的定性单轮基准报告的 80–94% against a fair agentic baseline that is the per-task ceiling, not the average——在存在过度构建陷阱的任务如 date picker 404 行降到 23 行−94%上能到 94%而在代码本已极简的任务上收益接近零12 个功能任务平均下来是 −54%。因此/ponytail-gain记分板展示 80–94% 时配合 benchmark median · 5 tasks · 3 models 的标注读者应理解为这是单轮日常任务上的区间跨任务平均值请参照 agentic 结果。3.3 替代出口/ponytail-debt与/ponytail-audit既然不能输出 per-repo 节省数字命令文档给出了仅有的两个真实仓库级数字来源/ponytail-debtponytail 的约定是用ponytail:注释标记每处被刻意简化的地方含上限与升级路径。该命令扫描全仓库这些注释、汇总成台账file:line, what was simplified. ceiling: … upgrade: …并给没有升级触发的条目打no-trigger标记——deferred 因此不会被静默变成 never。它是唯一可被逐行计数的仓库级账本定义见 .opencode/command/ponytail-debt.md 与 skills/ponytail-debt/SKILL.md/ponytail-audit审计整个仓库不是 diff中还能删的过度工程按delete / stdlib / native / yagni / shrink五类标签输出发现清单结尾给出可移除的净行数与依赖数定义见 .opencode/command/ponytail-audit.md。记分板末尾那两行 This repo: 指针就是这条边界的落点单仓库数字要么来自被逐行点过的 debt 台账要么来自 audit 的可删清单而不是凭空减去一个不存在的基线。4. 复现记分板数字benchmark 的运行方式/ponytail-gain展示的每个区间都可以在本地复现。以下命令均以 benchmarks/README.md 为准。4.1 单轮 promptfoo 复现Claude 三模型前置条件Anthropic API key 与Node.js ≥ 22.22.0promptfoo 引擎约束以及 Python 3、pandascorrectness 检查会调用 Python。cd benchmarks cp ../.env.example .env # 填入 ANTHROPIC_API_KEY npx promptfoolatest eval -c promptfooconfig.yaml --env-file ../.env --repeat 10 npx promptfoolatest view注意--env-file ../.env是必需的promptfoo 从当前目录benchmarks/而非仓库根目录读取.env。10 次重复对应记分板 median of 10 runs 的口径成本在 2026-06-17 曾以 30 次运行单独复核见 benchmarks/results/2026-06-17-cost-verification.md 的入口描述。4.2 本地模型复现Ollama不需要 API key 和 promptfoo直接对 Ollama 提供的任意模型跑ollama pull llama3.2 # 或任意其他模型 python benchmarks/benchmark-local.py --model llama3.2 --repeat 3benchmarks/results/2026-06-15-llama3.2-local.md 记录了预期结论该技能在指令跟随能力强的模型Claude 级别上表现好迁移到小本地模型时多步决策阶梯不能被可靠遵循。4.3 双指标设计loc.js与correctness.js记分板数字之所以敢展示是因为测量管线本身有闸门设计见 benchmarks/README.md 的指标表文件指标行为benchmarks/loc.jsloc纯测量——永远通过只记录行数benchmarks/correctness.jscorrect闸门——生成的代码不工作就判失败correctness.js会提取 fenced code block 并执行按任务的检查email、debounce、CSV 三项实际 spawn Python/Node 运行代码React countdown 与 FastAPI rate-limit 为结构性/关键词检查。这意味着一个坏掉的一行代码在 LOC 上得分再好看也会在 correctness 上失败——LOC 区间的前提是代码仍然正确。4.4 Agentic 基准可信度来源agentic 基准benchmarks/agentic/是记分板数字的防翻车补充值得了解两点隔离性每个 (任务, 组) 单元格独立运行n4每格一份全新仓库副本与全新 Agent 上下文。该文档还记录了一次自查出的污染 bugponytail 插件的SessionStarthook 曾对所有组含基线触发导致基线偷偷跑了 ponytail最终用--setting-sources project,local 每臂仅加载一个--plugin-dir修复——这正是为什么要信任其余数字的原因安全轴6 个手术式任务的安全性要求被刻意保持隐式产出函数随后被对抗性输入执行路径穿越、SQL 注入、伪造 token 等确定性、仅标准库。ponytail 20/20 全部安全而裸 one-liner 提示词组 19/20 丢了一次路径穿越检查。这支撑了 README 的总纲write only what the task needs, and never cut validation, error handling, security, or accessibility。5. 使用边界与触发汇总命令文档的 Boundaries 与 Report only 约束/ponytail-gain的行为契约是一次性展示被调用时渲染记分板仅此而已——不切换 lite/full/ultra 模式、不写 flag 文件、不持久化任何状态、不编辑任何文件数字口径只报 benchmark 中位数5 任务 × 3 模型 × 10 次运行条形表示区间、标签表示精确值绝不输出 per-repo 节省数字指代真实数字仓库级问题一律指向/ponytail-debt已点数的捷径台账与/ponytail-audit仍可削减项退出方式Skill 版明确 stop ponytail 或 normal mode 即可回退——由于该命令本身不改变状态回退的只是用户的提问语境而非任何被修改的配置。适用宿主方面README.md 注明 commands 需要 skill-capable 的宿主Claude Code、Codex、Devin CLI、OpenCode、Gemini、pi、Swival、Hermes Agent、Qoder。对 OpenCode 而言从仓库检出目录运行时.opencode/command/ 下的命令文件即构成斜杠命令集若以插件方式接入opencode.json中指向./.opencode/plugins/ponytail.mjs则额外注入每轮规则集与lite/full/ultra/off级别开关。无论哪种接入方式/ponytail-gain的输出都不依赖接入方式——它读取的永远是同一份已发布基准中位数。小结/ponytail-gain是 Ponytail 六条命令中最克制的一条它的全部产品价值不在于展示数字而在于展示数字的纪律——区间用条形、精确值用标签、来源标注到benchmarks/与 README、单仓库数字一票否决并改指 debt/audit 两条可验证的出口。对使用方而言它的正确读法是LOC 80–94% 削减是单轮日常任务上的测量区间跨任务 agentic 平均约 −54%成本与速度收益为同一测量的派生值且全部可通过第 4 节的命令在本地复现而对仓库开发者而言skills/ponytail-gain/SKILL.md、commands/ponytail-gain.toml 与各平台拷贝必须保持逐字一致node scripts/check-rule-copies.js与npm test是变更这类规则文本时的对齐检查手段。【免费下载链接】ponytailMakes your AI agent think like the laziest senior dev in the room. The best code is the code you never wrote.项目地址: https://gitcode.com/GitHub_Trending/po/ponytail创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考