深入解析 Ponytail 的 CSV Sum 案例同一模型如何让读 CSV 求和从 20 行缩到 3 行【免费下载链接】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 仓库的官方示例 examples/csv-sum.md 为主体逐字解析同一模型、同一提示词下无技能与加载 ponytail 技能两种输出为何相差 17 行代码并结合仓库中的基准配置benchmarks/promptfooconfig.yaml、行数统计benchmarks/loc.js与正确性闸门benchmarks/correctness.js源码讲清这个数字背后的度量方法、验证链路与适用边界。读完后你将掌握如何复现该示例的基准运行、如何用 LOC 与正确性双指标评判更少代码是否等于更坏代码以及 ponytail 技能文件中的决策阶梯是如何具体作用于一个 CSV 求和任务的。示例的出处基准运行的逐字记录不是手写样板csv-sum.md 开头的定位声明非常关键这是基准运行benchmark run中模型的逐字输出verbatim model output而不是人工编写的演示。其实验条件在原文档中已经完整给出任务提示词Write Python code that reads sales.csv and sums the amount column.写 Python 代码读取 sales.csv 并对 amount 列求和模型Claude Haiku 4.5对照组no-skill arm无技能基线vs ponytail arm加载 ponytail 技能采样参数temperature 1数据来源benchmarks/output.json复现命令npx promptfoolatest eval -c benchmarks/promptfooconfig.yaml这个任务在 examples/README.md 的定位是真实模型输出逐字来自基准运行同一任务由同一模型在无技能## Without Ponytail与加载 ponytail## With Ponytail下分别作答供并排对比。该任务同时出现在基准配置 benchmarks/promptfooconfig.yaml 的五个日常任务之中与 email 校验、debounce、React 倒计时、FastAPI 限流并列。复现所需的完整环境仅知道一条命令还不够。根据 benchmarks/README.md完整复现需要cp ../.env.example .env # 添加你的 ANTHROPIC_API_KEY npx promptfoolatest eval -c promptfooconfig.yaml --env-file ../.env --repeat 10 npx promptfoolatest view环境前提以仓库实际要求为准依赖要求原因ANTHROPIC_API_KEY必需三个 provider 都是 Anthropic 模型Node.js≥ 22.22.0promptfoo 引擎的版本约束用node --version检查Python 3 pandas必需正确性闸门会真实执行生成的 CSV 代码注意--env-file ../.env是必需的promptfoo 从当前目录benchmarks/读取.env而该文件实际位于仓库根目录。基准共设三个 arm、三个模型、每个任务 10 次运行、取中位数报告。三个 arm 的定义在 promptfooconfig.yaml 中prompts: - id: file://arms/baseline.js label: baseline (no skill) - id: file://arms/caveman.js label: caveman - id: file://arms/ponytail.js label: ponytail从源码看两个 arm 的实现差异极其干净这正是同一模型、同一提示词得以成立的原因benchmarks/arms/baseline.jsmodule.exports ({ vars }) [{ role: user, content: vars.task }];—— 只有任务本身无系统提示。benchmarks/arms/ponytail.js读取仓库自己的 skills/ponytail/SKILL.md 全文作为 system prompt注释明确写着 Single source of truth用户消息仍是同样的vars.task。而采样参数在 promptfooconfig.yaml 中固定claude-haiku-4-5-20251001、claude-sonnet-4-6、claude-opus-4-8均为max_tokens: 8192, temperature: 1。示例文档标注的 Claude Haiku 4.5, temperature 1 与配置完全一致。无 Ponytail 时的完整输出20 行代码 三个备选方案以下是 no-skill arm 的逐字输出与 csv-sum.md 原文一致包含模型给出的主方案、两个备选方案和一节推荐说明——这正是无约束模型的典型形态不止一个答案还附带大量解释性文字Python code to read sales.csv and sum the amount columnimport pandas as pd # Read the CSV file df pd.read_csv(sales.csv) # Sum the amount column total_amount df[amount].sum() # Print the result print(fTotal amount: ${total_amount:,.2f})Alternative methods:Using CSV module (without pandas):import csv total_amount 0 with open(sales.csv, r) as file: reader csv.DictReader(file) for row in reader: total_amount float(row[amount]) print(fTotal amount: ${total_amount:,.2f})Using pandas with error handling:import pandas as pd try: df pd.read_csv(sales.csv) total_amount df[amount].sum() print(fTotal amount: ${total_amount:,.2f}) except FileNotFoundError: print(Error: sales.csv not found) except KeyError: print(Error: amount column not found)The pandas method is recommendedbecause its:More concise and readableHandles data types automaticallyProvides built-in error handlingEfficient for large files按 benchmarks/loc.js 的口径这段输出计为20 行代码。注意其形态一个主方案pandas、一个不用 pandas的备选csv 模块手写循环、一个带错误处理的增强版外加一段论证为什么推荐 pandas。对求和一个列这个任务而言后两者属于未被请求的扩展。加载 Ponytail 后的输出3 行代码 一句跳过清单同一模型、同一提示词ponytail arm 的逐字输出是import csv total sum(float(row[amount]) for row in csv.DictReader(open(sales.csv))) print(total)紧随其后的只有一行说明Skipped: pandas, error handling, file closing, add when the CSV is large, malformed, or you need more analysis.原文档的收尾结论是20 → 3 行代码same model, same prompt同一模型、同一提示词。这 3 行代码恰好对应了基准正确性闸门实际执行的验证对象标准库csv.DictReader 生成器表达式求和无任何第三方依赖。而那句 Skipped: … add when … 并非模型随机的行文习惯它是 skills/ponytail/SKILL.md 中Output一节强制规定的输出模式Code first. Then at most three short lines: what was skipped, when to add it. Pattern:[code] → skipped: [X], add when [Y].即先给代码之后最多三行跳过了什么、何时再加回来。csv-sum 示例里被跳过的三项——pandas 依赖、错误处理、显式关闭文件——以及何时再加回的条件CSV 变大、数据可能畸形、需要更多分析正是这一模式的落地实例。20 → 3 的差距从何而来SKILL.md 的决策阶梯skills/ponytail/SKILL.md 的核心是一套七级阶梯The ladder要求停在第一个成立的 rung横档上级别问题1这东西根本需要存在吗YAGNI投机性需求 跳过并一句话说明2本代码库里已经有了吗复用优先于重写3标准库能做吗能用。4平台原生能力覆盖吗如input typedate优于选择器库5已安装的依赖能解决吗绝不为了几行代码能搞定的事新增依赖6能写成一行吗那就一行7最后才轮到能工作的最小代码把 CSV sum 任务放进这架阶梯对照两组输出无技能输出停在 rung 5 的反面——引入了一个新依赖 pandas且附带了未请求的错误处理增强版和三个方案加论证。ponytail 输出落在 rung 3/6csv模块是标准库rung 3sum(...)生成器表达式是一行完成rung 6最小能工作的代码只用了 3 行。SKILL.md 的 Rules 一节进一步解释了被跳过的每一项错误处理try/except属于未请求的样板。但注意 SKILL.md 的When NOT to be lazy一节同时划了红线——信任边界的输入校验、防止数据丢失的错误处理、安全措施、可访问性基础以及用户明确请求的内容一律不得简化掉。csv-sum 是一个本地读文件求和的场景不涉及这些红线所以跳过错误处理是安全的。跳过文件关闭open(sales.csv)未包在with里属于刻意简化。SKILL.md 要求对此类有已知天花板的简化用ponytail:注释标明天花板与升级路径示例中模型改用 Skipped: … add when … 的输出一句话承担了同样职能。另外SKILL.md 强调阶梯是反应而非研究项目但必须在理解问题之后运行Read the task and the code it touches first, trace the real flow end to end, then climb.先读懂任务与它触及的代码追完真实流程再爬阶梯。——省的是写代码的步骤不是读题的步骤。更少代码如何被证明没有更坏LOC 度量与正确性闸门示例文档只给了 20 → 3 的结论仓库里真正让这个数字可信的是 promptfooconfig.yaml 中挂在每个测试上的两个断言defaultTest: assert: - type: javascript value: file://loc.js metric: code_loc - type: javascript value: file://correctness.js metric: correctbenchmarks/README.md 对两者的分工有明确定义文件指标行为loc.jsloc度量——永远通过只记录行数correctness.jscorrect闸门——生成代码不能工作就判失败LOC 的计数口径benchmarks/loc.js 的统计规则从围栏代码块中取出代码若模型输出的是无围栏裸代码则整段响应用作代码先剥离/* ... */块注释再统计非空、非注释行。示例中标注的 20 lines 与 3 lines 均按此口径得出——也就是说无技能输出里的三处代码块主方案 两个备选的行数是被合并计入的这本身也说明基准统计的是模型总共写了多少代码而非最优方案多少行。CSV 任务的正确性闸门真实执行而非结构检查benchmarks/correctness.js 的设计目标是证明更少代码不等于坏代码它提取围栏代码块按任务追加断言然后真的 spawn Python/Node 去执行。对 CSV sum 任务correctness.js 的csv检查生成一个临时测试 CSVname,amount表头下三行数据——Alice 100.5、Bob 200.0、Charlie 50.5把生成代码中对sales.csv的文件名引用打补丁替换为该临时文件路径兼容open()调用形式捕获print输出用正则(?!\d)351(?:\.0)?(?!\d)校验输出中出现了独立数字351即 100.5 200.0 50.5匹配即 PASS否则打印实际输出前 200 字符并失败。这意味着 ponytail arm 那 3 行代码在每次基准运行时都被真实执行过csv.DictReader逐行读入、float()转换、sum()累加输出 351 才计为通过。仓库的 benchmarks/README.md 也明确区分email、debounce、CSV 三项是执行型检查而 React 倒计时与 FastAPI 限流只做关键词/结构检查无运行时执行验证的是可信的结构而非完整正确性。闸门的健壮性还有回归测试守护benchmarks/correctness.test.js 针对 issue #65 修复的两个闸门缺陷做回归——无围栏裸代码曾被误判为没有代码块、debounce 任务曾检查了提示词没要过的交付物。修复记录见 benchmarks/results/2026-06-16-correctness-gate-fix.md修复前简洁模型的失败大量来自闸门读不懂自己的简洁输出而非技能导致退化。理解这一点很重要csv-sum 的 20 → 3 之所以是正确性持平下的行数缩减前提是这个闸门本身被证明能正确读取 terse 输出。把 csv-sum 放回全局五个任务的中位数结果csv-sum.md 只是五个官方示例之一。examples/README.md 汇总了同一模型Claude Haiku 4.5, temperature 1下各任务的无技能/有技能 LOC 对比示例无 ponytail (LOC)有 ponytail (LOC)Email Validation753Debounce11610CSV Sum203Countdown Timer2679Rate Limiting12810csv-sum 是五个案例中绝对行数最小的一对但缩减比例20 → 3约 85%与其余案例同量级。再看跨模型的汇总数据benchmarks/README.md5 任务 × 3 arm × 10 次取中位数代码行数中位数armHaikuSonnetOpusbaseline (无技能)518693256caveman11612067ponytail394451即相对 baselineponytail 在全部三个 Claude 模型上写出80–94% 更少的代码、成本42–75% 更低、快3–6 倍成本数字在 30 次运行下复核过另含 OpenAI 与 Gemini arm见 benchmarks/results/2026-06-17-cost-verification.md。适用边界这个数字该怎样诚实地读csv-sum 示例容易被简化为ponytail 让模型少写 85% 代码但仓库自己给出的限定条件同样值得读者掌握全部有据可查单次生成口径benchmarks/README.md 的诚实说明指出上述差距是single-shot对比对手是给多个方案加一大段评论的裸模型计数包含散文而不仅是代码因此高估了实际收益。更严格的可辩护数字来自 agentic 基准真实 Claude Code 会话在真实公开仓库上运行在过度构建陷阱类任务上 ponytail 缩减 60–94%在已极简的代码上打平从不写更多且保持 100% 安全——详见 benchmarks/results/2026-06-18-agentic.md。模型依赖benchmarks/results/2026-06-15-llama3.2-local.md 显示该技能在指令遵循能力强的模型Claude 级上效果好但迁移到小型本地模型如 llama3.2时多步决策阶梯不被可靠地遵循收益会显著减弱。csv-sum 的 20 → 3 是 Haiku 4.5 在 temperature 1 下的记录复现到其他模型时应预期数值漂移。偷懒有明确禁区skills/ponytail/SKILL.md 的 When NOT to be lazy 规定信任边界输入校验、防数据丢失的错误处理、安全措施、可访问性基础以及用户显式请求的内容不可简化。csv-sum 跳过错误处理之所以成立是因为它恰好不落在这些红线上把同一模式套用到处理用户上传 CSV的场景时跳过清单里就不该再出现 error handling。成本口径基准成本反映单次调用一次提示、一次补全不是多轮 agent 会话成本。会话中规则集每轮重注入、阶梯每轮 deliberation单会话成本可能高于这些数字README 的 Notes 一节有专门说明。小结csv-sum.md 用最小的一个日常任务读 CSV、对 amount 列求和完整演示了 ponytail 方法论的闭环无技能模型输出 20 行代码外加两个未请求的备选方案与推荐论证加载 ponytail SKILL.md 后同一模型在 temperature 1 下落到标准库csv 3 行生成器表达式并按规定格式附一句 Skipped: …, add when …。这一对比的说服力来自仓库内完整的验证链arms/baseline.js 与 arms/ponytail.js 保证同模型同提示词loc.js 给出确定性行数口径correctness.js 用 100.5 200.0 50.5 351 的临时 CSV 真实执行生成代码作为正确性闸门correctness.test.js 回归守护闸门本身。复现路径始终是同一命令npx promptfoolatest eval -c benchmarks/promptfooconfig.yaml需 ANTHROPIC_API_KEY、Node.js ≥ 22.22.0、Python 3 pandas。【免费下载链接】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），仅供参考