Ponytail 实例剖析用 Intl.NumberFormat 替代 numeral 完成货币与千分位格式化【免费下载链接】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/number-formatting.md 这一真实基准产出展开面对把数字格式化为货币并带千分位分隔符这一日常任务未加载 ponytail 技能的模型会npm install numeral而加载后的模型直接给出内置的Intl.NumberFormat方案。读完后你能掌握三件事如何用Intl.NumberFormat覆盖货币、百分比、紧凑记数三类格式化场景ponytail 的决策阶梯是如何一步步把解法推向标准库的以及这套少装一个依赖的判断在仓库基准体系中如何被验证和复现。原始任务与两种回答示例文档的完整设定只有一个任务Task:Format numbers as currency and with thousand separators.把数字格式化为货币并带千分位分隔符。同一模型Claude Haiku 4.5、同一任务分无技能基线与 ponytail 两臂各答一次这就是示例文档的对比结构。无 Ponytail安装一个格式库基线臂的回答是先装依赖再用库完成格式化npm install numeral # or: npm install accountingimport numeral from numeral; numeral(1234567.89).format($1,234.00); // $1,234,567.89 numeral(0.745).format(0.0%); // 74.5% numeral(1500).format(0.0a); // 1.5k三条format()调用分别演示了货币格式、百分比缩写格式0.0%和紧凑缩写0.0a把 1500 压成1.5k。功能上都对但代价是一个新的 npm 依赖。有 Ponytail内置的 Intl.NumberFormatponytail 臂的回答不带任何依赖代码首行就是一条自我说明式的注释这是 ponytail 的惯用标记下文会讲// ponytail: Intl.NumberFormat does this, locale-aware new Intl.NumberFormat(en-US, { style: currency, currency: USD }) .format(1234567.89); // → $1,234,567.89 new Intl.NumberFormat(en-US, { style: percent }) .format(0.745); // → 74.5% new Intl.NumberFormat(en-US, { notation: compact }) .format(1500); // → 1.5K示例文档给出的结论只有一行但它就是这个例子的核心论点1 dependency → 0 dependencies.Intl.NumberFormatis built into every JS runtime, handles every locale correctly, and gets currency symbols, decimal separators, and grouping right for any market without a lookup table. A library that hardcodes formats will always be wrong for someone.翻译过来1 个依赖 → 0 个依赖。Intl.NumberFormat内置于每个 JS 运行时按 locale 正确处理货币符号、小数分隔符和分组符而硬编码格式表的库总会在某个市场出错。这组回答的出处它是基准产出不是手写的理解这个示例的前提是知道它不是作者手写的示范而是 ponytail 基准跑出来的逐字模型输出。examples/README.md 说明了出处与复现方式Real model output, verbatim from benchmark runs, the same task answered by the same model with no skill (## Without Ponytail) and with ponytail (## With Ponytail), so you can compare side by side. Model: Claude Haiku 4.5, temperature 1, sourcebenchmarks/output.json.即模型为 Claude Haiku 4.5、temperature 1结果直接取自benchmarks/output.jsonThese are not hand-written。复现命令也写在同一文档里npx promptfoolatest eval -c benchmarks/promptfooconfig.yaml主 README.md 把整个examples/目录称为 More survivors活下来的幸存者示例与开头的input typedate案例并列作为ponytail 生效现场的集合。从仓库的基准实现看两臂的差异完全来自系统提示词而非任务本身benchmarks/arms/ponytail.js 只做一件事——把 skills/ponytail/SKILL.md 全文读出来作为 system prompt再附上用户任务。文件里的注释写明了这是 Single source of truth单一事实来源// Ponytail arm: the repos own SKILL.md (full) as the system prompt. Single source of truth. const system fs.readFileSync(path.join(__dirname, .., .., skills, ponytail, SKILL.md), utf8);也就是说示例中// ponytail: ...这种注释风格、先问该不该写的思考方式都直接来自这份 SKILL.md而不是模型自带的能力。评分侧由 benchmarks/loc.js 和 benchmarks/correctness.js 两个断言构成在 benchmarks/promptfooconfig.yaml 的defaultTest中注册loc.js统计围栏代码块里的非空非注释行code_loc指标只测量不设门槛correctness.js是正确性闸门——一个更短但跑不通的答案会在闸门上失败。这就是为什么示例能同时展示更短和仍然正确两套指标各管一半。运行环境方面benchmarks/README.md 要求 Node.js ≥ 22.22.0promptfoo 引擎约束和环境中的ANTHROPIC_API_KEY本地复现的完整命令是npx promptfoolatest eval -c promptfooconfig.yaml --env-file ../.env --repeat 10--env-file ../.env是因为 promptfoo 从benchmarks/目录读.env而文件在仓库根目录。需要说明的一个细节当前benchmarks/promptfooconfig.yaml的tests列表配置的是五个任务邮箱校验、debounce、CSV 求和、React 倒计时、FastAPI 限流examples/README.md的对照表也只列了这五个number-formatting 这一篇同样标注来源为benchmarks/output.json属于同体系基准产出的示例文档。为什么会停在 Intl.NumberFormat阶梯的第三、第四级这个示例最值得展开的不是代码本身而是为什么是它。ponytail 的核心机制是一条写死在 skills/ponytail/SKILL.md 里的决策阶梯The ladder要求模型在动笔前从第一级开始检查停在第一个成立的那一级1. Does this need to exist? → no: skip it (YAGNI) 2. Already in this codebase? → reuse it, dont rewrite 3. Stdlib does it? → use it 4. Native platform feature? → use it 5. Installed dependency? → use it 6. One line? → one line 7. Only then: the minimum that works主 README.md 的 How it works 一节收录了同一份阶梯。对照本例需要存在吗需要任务明确要求格式化不能跳。本代码库里已有吗示例是独立小任务无现成 helper 可复用这一级在项目内任务上经常命中见下文基准佐证。标准库能做吗命中。Intl是 ECMAScript 标准的一部分Intl.NumberFormat属于标准库/平台内置层阶梯在此停住——后面的一行代码和最小实现级根本不需要爬。SKILL.md 同时规定了阶梯的使用纪律阶梯在理解问题之后运行而不是代替理解两个级别都成立时取更高的那个。它还对故意留下的简化有强制标记规则用ponytail:前缀的注释写明上限和升级路径。示例里那句// ponytail: Intl.NumberFormat does this, locale-aware正是这条规则的产物——它不是装饰性注释而是向后续维护者声明这里刻意选了内置方案理由写在后面。仓库里还有一份专门的佐证文档 docs/platform-native.md标题直译为平台原生解法开篇即 ponytail 的第一问题does the platform already do this?。在其 JavaScript / Browser APIs 一节的对照表中本例的映射关系被逐字列出You think you needWhat the platform hasnumeral/accountingnew Intl.NumberFormat(en-US, { style: currency, currency: USD })同一张表里还并列了date-fns→Intl.DateTimeFormat、plural/i18n复数规则 →Intl.PluralRules(en-US).select(count)等条目说明货币格式化只是 ponytail 反复处理的装库冲动类型之一。该文档结尾的 The Pattern 一节把这个模式抽象成五行可以视为示例结论的通用化Platform team spends years solving the problem. Package author wraps it. You install the wrapper. The wrapper goes unmaintained. You debug the wrapper.结论是 Skip the wrapper. The platform ships with your app for free.并留了一个例外出口当原生方案确实不够老浏览器兼容、边缘用例、规模化后的易用性时库才挣得它的位置——Install it then, not before.三个 Intl.NumberFormat 调用逐项拆解把示例中三条内置写法拆开看可以确认它们与 numeral 的三个用例一一对应且各自覆盖了什么参数1. 货币格式new Intl.NumberFormat(en-US, { style: currency, currency: USD }).format(1234567.89); // → $1,234,567.89style: currency声明货币样式currency: USD给出 ISO 4217 货币代码千分位分隔符,与两位小数.89由 locale 数据自动生成不需要 numeral 那种$1,234.00手工格式串与 numeral 的差异体现在 locale 能力上把en-US换成其他 locale符号、分组、小数位都会跟着变无需查表或换库。2. 百分比格式new Intl.NumberFormat(en-US, { style: percent }).format(0.745); // → 74.5%style: percent内部完成乘 100 加百分号输入保持比例形式0.745避免手工换算出错。numeral 侧的0.0%同样输出74.5%两边等价。3. 紧凑记数compact notationnew Intl.NumberFormat(en-US, { notation: compact }).format(1500); // → 1.5Knotation: compact把 1500 压成1.5K。注意输出与 numeral 的1.5k只有大小写之差en-US下是K这是两个方案在该场景下唯一的可见差异。若需要更细控制Intl.NumberFormat还支持compactDisplay: short | long、maximumFractionDigits等选项但本例用默认值已满足任务。示例文档最后那句 A library that hardcodes formats will always be wrong for someone硬编码格式表的库总会在某人那里出错指向的正是这个维度numeral 的格式串是人写的字符串Intl.NumberFormat的格式来自随运行时/操作系统更新的 CLDR 语言数据——后者的错误面小得多且维护成本不在你这边。仓库内的第二份证据连基准题都在考别手搓格式这个格式要交给已有的正确实现的原则不止停留在示例里它还以测试题的形式出现在仓库的 agentic 基准中。benchmarks/agentic/tasks.py 里的 #217b reuse-money 任务直接围绕货币格式题目背景设定项目里有一个money.py其中format_money是全项目统一的货币格式——a leading $ and a thousands separator, e.g. 1050 - $10.50, 123456 - $1,234.56实现只有两行def format_money(cents): Project-wide currency format: a leading $ and a thousands separator, e.g. 1050 - $10.50, 123456 - $1,234.56. Use this everywhere money is shown. return f${cents / 100:,.2f}任务要求新写的line_item(name, cents, qty)按项目里展示金额的方式展示小计。评分函数score_reuse_moneytasks.py检查两件事小额正确性1050 × 2与999 × 1的普通用例以及复用性——传入能产生四位数总额的参数61728 × 2分 $1,234.56若输出里没有出现$1,234.56就判定为 re-implemented formatting (no grouping)即手搓了一个丢掉千分位逗号的新格式。reused ($1,234.56 in fn(Pallet, 61728, 2)) # 61728*2 123456 cents - $1,234.56 return _ok(correct, reused, reused format_money if reused else re-implemented formatting (no grouping))这与examples/number-formatting.md是同一枚硬币的两面示例文档讲的是没有现成方案时去标准库取阶梯第 3 级#217b 讲的是有现成方案时复用项目里的阶梯第 2 级且 SKILL.md 称重造几米之外已有的 helper is the most common slop。两个方向合起来就是 ponytail 对待格式化这类任务的全部策略先查库内再查标准库/平台最后才轮到第三方包而第三方包只有在原生方案被证实不够时才登场。如何在自己项目里应用这套做法不需要安装任何东西就能借用这个示例的结论但如果你想完整继承 ponytail 的行为仓库给出的路径是直接采纳结论JS 项目中把numeral/accounting替换为Intl.NumberFormat上文的三段代码即可原样复制运行换语言/地区只改第一个参数。安装 ponytail 技能若使用 Claude Code / Codex 等支持技能的主机按 README.md 的安装节操作例如 Claude Code 下执行/plugin marketplace add DietrichGebert/ponytail后/plugin install ponytailponytail两条需分别发送。安装后默认强度为full可用/ponytail lite|full|ultra或环境变量PONYTAIL_DEFAULT_MODE调整用 stop ponytail 或 normal mode 关闭。强度含义见 skills/ponytail/SKILL.md 的 Intensity 表lite只提示更懒的替代方案full默认强制执行阶梯ultra是 YAGNI 极端派。保留ponytail:注释约定即使不装技能在刻意简化的地方留一行说明上限与升级路径的约定本身就值得沿用——示例首行注释正是这个约定的示范。验证ponytail 的边界规则明确Never simplify away: input validation at trust boundaries, error handling that prevents data loss, security measuresskills/ponytail/SKILL.md When NOT to be lazy 一节。就数字格式化而言这意味着可以省掉依赖但上游传来的非数字、NaN、负数等边界处理不能因为更懒而被删掉。小结examples/number-formatting.md 用最小的一个任务演示了 ponytail 的主张货币、百分比、紧凑记数三种格式化Intl.NumberFormat一个内置 API 全覆盖省掉numeral或accounting的依赖与维护成本还顺带获得 locale 正确性。它不是一段手写教程而是基准跑出来的真实模型输出Claude Haiku 4.5temperature 1来源benchmarks/output.json可用npx promptfoolatest eval -c benchmarks/promptfooconfig.yaml复现支撑它做出这个选择的是 skills/ponytail/SKILL.md 中标准库先于依赖的决策阶梯以及 docs/platform-native.md 中把numeral与Intl.NumberFormat直接对位的对照表。对日常开发者的可迁移结论只有一条在为一类格式化需求装库之前先问一句平台是不是已经带了。【免费下载链接】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 实例剖析用 Intl.NumberFormat 替代 numeral 完成货币与千分位格式化【免费下载链接】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/number-formatting.md 这一真实基准产出展开面对把数字格式化为货币并带千分位分隔符这一日常任务未加载 ponytail 技能的模型会npm install numeral而加载后的模型直接给出内置的Intl.NumberFormat方案。读完后你能掌握三件事如何用Intl.NumberFormat覆盖货币、百分比、紧凑记数三类格式化场景ponytail 的决策阶梯是如何一步步把解法推向标准库的以及这套少装一个依赖的判断在仓库基准体系中如何被验证和复现。原始任务与两种回答示例文档的完整设定只有一个任务Task:Format numbers as currency and with thousand separators.把数字格式化为货币并带千分位分隔符。同一模型Claude Haiku 4.5、同一任务分无技能基线与 ponytail 两臂各答一次这就是示例文档的对比结构。无 Ponytail安装一个格式库基线臂的回答是先装依赖再用库完成格式化npm install numeral # or: npm install accountingimport numeral from numeral; numeral(1234567.89).format($1,234.00); // $1,234,567.89 numeral(0.745).format(0.0%); // 74.5% numeral(1500).format(0.0a); // 1.5k三条format()调用分别演示了货币格式、百分比缩写格式0.0%和紧凑缩写0.0a把 1500 压成1.5k。功能上都对但代价是一个新的 npm 依赖。有 Ponytail内置的 Intl.NumberFormatponytail 臂的回答不带任何依赖代码首行就是一条自我说明式的注释这是 ponytail 的惯用标记下文会讲// ponytail: Intl.NumberFormat does this, locale-aware new Intl.NumberFormat(en-US, { style: currency, currency: USD }) .format(1234567.89); // → $1,234,567.89 new Intl.NumberFormat(en-US, { style: percent }) .format(0.745); // → 74.5% new Intl.NumberFormat(en-US, { notation: compact }) .format(1500); // → 1.5K示例文档给出的结论只有一行但它就是这个例子的核心论点1 dependency → 0 dependencies.Intl.NumberFormatis built into every JS runtime, handles every locale correctly, and gets currency symbols, decimal separators, and grouping right for any market without a lookup table. A library that hardcodes formats will always be wrong for someone.翻译过来1 个依赖 → 0 个依赖。Intl.NumberFormat内置于每个 JS 运行时按 locale 正确处理货币符号、小数分隔符和分组符而硬编码格式表的库总会在某个市场出错。这组回答的出处它是基准产出不是手写的理解这个示例的前提是知道它不是作者手写的示范而是 ponytail 基准跑出来的逐字模型输出。examples/README.md 说明了出处与复现方式Real model output, verbatim from benchmark runs, the same task answered by the same model with no skill (## Without Ponytail) and with ponytail (## With Ponytail), so you can compare side by side. Model: Claude Haiku 4.5, temperature 1, sourcebenchmarks/output.json.即模型为 Claude Haiku 4.5、temperature 1结果直接取自benchmarks/output.jsonThese are not hand-written。复现命令也写在同一文档里npx promptfoolatest eval -c benchmarks/promptfooconfig.yaml主 README.md 把整个examples/目录称为 More survivors活下来的幸存者示例与开头的input typedate案例并列作为ponytail 生效现场的集合。从仓库的基准实现看两臂的差异完全来自系统提示词而非任务本身benchmarks/arms/ponytail.js 只做一件事——把 skills/ponytail/SKILL.md 全文读出来作为 system prompt再附上用户任务。文件里的注释写明了这是 Single source of truth单一事实来源// Ponytail arm: the repos own SKILL.md (full) as the system prompt. Single source of truth. const system fs.readFileSync(path.join(__dirname, .., .., skills, ponytail, SKILL.md), utf8);也就是说示例中// ponytail: ...这种注释风格、先问该不该写的思考方式都直接来自这份 SKILL.md而不是模型自带的能力。评分侧由 benchmarks/loc.js 和 benchmarks/correctness.js 两个断言构成在 benchmarks/promptfooconfig.yaml 的defaultTest中注册loc.js统计围栏代码块里的非空非注释行code_loc指标只测量不设门槛correctness.js是正确性闸门——一个更短但跑不通的答案会在闸门上失败。这就是为什么示例能同时展示更短和仍然正确两套指标各管一半。运行环境方面benchmarks/README.md 要求 Node.js ≥ 22.22.0promptfoo 引擎约束和环境中的ANTHROPIC_API_KEY本地复现的完整命令是npx promptfoolatest eval -c promptfooconfig.yaml --env-file ../.env --repeat 10--env-file ../.env是因为 promptfoo 从benchmarks/目录读.env而文件在仓库根目录。需要说明的一个细节当前benchmarks/promptfooconfig.yaml的tests列表配置的是五个任务邮箱校验、debounce、CSV 求和、React 倒计时、FastAPI 限流examples/README.md的对照表也只列了这五个number-formatting 这一篇同样标注来源为benchmarks/output.json属于同体系基准产出的示例文档。为什么会停在 Intl.NumberFormat阶梯的第三、第四级这个示例最值得展开的不是代码本身而是为什么是它。ponytail 的核心机制是一条写死在 skills/ponytail/SKILL.md 里的决策阶梯The ladder要求模型在动笔前从第一级开始检查停在第一个成立的那一级1. Does this need to exist? → no: skip it (YAGNI) 2. Already in this codebase? → reuse it, dont rewrite 3. Stdlib does it? → use it 4. Native platform feature? → use it 5. Installed dependency? → use it 6. One line? → one line 7. Only then: the minimum that works主 README.md 的 How it works 一节收录了同一份阶梯。对照本例需要存在吗需要任务明确要求格式化不能跳。本代码库里已有吗示例是独立小任务无现成 helper 可复用这一级在项目内任务上经常命中见下文基准佐证。标准库能做吗命中。Intl是 ECMAScript 标准的一部分Intl.NumberFormat属于标准库/平台内置层阶梯在此停住——后面的一行代码和最小实现级根本不需要爬。SKILL.md 同时规定了阶梯的使用纪律阶梯在理解问题之后运行而不是代替理解两个级别都成立时取更高的那个。它还对故意留下的简化有强制标记规则用ponytail:前缀的注释写明上限和升级路径。示例里那句// ponytail: Intl.NumberFormat does this, locale-aware正是这条规则的产物——它不是装饰性注释而是向后续维护者声明这里刻意选了内置方案理由写在后面。仓库里还有一份专门的佐证文档 docs/platform-native.md标题直译为平台原生解法开篇即 ponytail 的第一问题does the platform already do this?。在其 JavaScript / Browser APIs 一节的对照表中本例的映射关系被逐字列出You think you needWhat the platform hasnumeral/accountingnew Intl.NumberFormat(en-US, { style: currency, currency: USD })同一张表里还并列了date-fns→Intl.DateTimeFormat、plural/i18n复数规则 →Intl.PluralRules(en-US).select(count)等条目说明货币格式化只是 ponytail 反复处理的装库冲动类型之一。该文档结尾的 The Pattern 一节把这个模式抽象成五行可以视为示例结论的通用化Platform team spends years solving the problem. Package author wraps it. You install the wrapper. The wrapper goes unmaintained. You debug the wrapper.结论是 Skip the wrapper. The platform ships with your app for free.并留了一个例外出口当原生方案确实不够老浏览器兼容、边缘用例、规模化后的易用性时库才挣得它的位置——Install it then, not before.三个 Intl.NumberFormat 调用逐项拆解把示例中三条内置写法拆开看可以确认它们与 numeral 的三个用例一一对应且各自覆盖了什么参数1. 货币格式new Intl.NumberFormat(en-US, { style: currency, currency: USD }).format(1234567.89); // → $1,234,567.89style: currency声明货币样式currency: USD给出 ISO 4217 货币代码千分位分隔符,与两位小数.89由 locale 数据自动生成不需要 numeral 那种$1,234.00手工格式串与 numeral 的差异体现在 locale 能力上把en-US换成其他 locale符号、分组、小数位都会跟着变无需查表或换库。2. 百分比格式new Intl.NumberFormat(en-US, { style: percent }).format(0.745); // → 74.5%style: percent内部完成乘 100 加百分号输入保持比例形式0.745避免手工换算出错。numeral 侧的0.0%同样输出74.5%两边等价。3. 紧凑记数compact notationnew Intl.NumberFormat(en-US, { notation: compact }).format(1500); // → 1.5Knotation: compact把 1500 压成1.5K。注意输出与 numeral 的1.5k只有大小写之差en-US下是K这是两个方案在该场景下唯一的可见差异。若需要更细控制Intl.NumberFormat还支持compactDisplay: short | long、maximumFractionDigits等选项但本例用默认值已满足任务。示例文档最后那句 A library that hardcodes formats will always be wrong for someone硬编码格式表的库总会在某人那里出错指向的正是这个维度numeral 的格式串是人写的字符串Intl.NumberFormat的格式来自随运行时/操作系统更新的 CLDR 语言数据——后者的错误面小得多且维护成本不在你这边。仓库内的第二份证据连基准题都在考别手搓格式这个格式要交给已有的正确实现的原则不止停留在示例里它还以测试题的形式出现在仓库的 agentic 基准中。benchmarks/agentic/tasks.py 里的 #217b reuse-money 任务直接围绕货币格式题目背景设定项目里有一个money.py其中format_money是全项目统一的货币格式——a leading $ and a thousands separator, e.g. 1050 - $10.50, 123456 - $1,234.56实现只有两行def format_money(cents): Project-wide currency format: a leading $ and a thousands separator, e.g. 1050 - $10.50, 123456 - $1,234.56. Use this everywhere money is shown. return f${cents / 100:,.2f}任务要求新写的line_item(name, cents, qty)按项目里展示金额的方式展示小计。评分函数score_reuse_moneytasks.py检查两件事小额正确性1050 × 2与999 × 1的普通用例以及复用性——传入能产生四位数总额的参数61728 × 2分 $1,234.56若输出里没有出现$1,234.56就判定为 re-implemented formatting (no grouping)即手搓了一个丢掉千分位逗号的新格式。reused ($1,234.56 in fn(Pallet, 61728, 2)) # 61728*2 123456 cents - $1,234.56 return _ok(correct, reused, reused format_money if reused else re-implemented formatting (no grouping))这与examples/number-formatting.md是同一枚硬币的两面示例文档讲的是没有现成方案时去标准库取阶梯第 3 级#217b 讲的是有现成方案时复用项目里的阶梯第 2 级且 SKILL.md 称重造几米之外已有的 helper is the most common slop。两个方向合起来就是 ponytail 对待格式化这类任务的全部策略先查库内再查标准库/平台最后才轮到第三方包而第三方包只有在原生方案被证实不够时才登场。如何在自己项目里应用这套做法不需要安装任何东西就能借用这个示例的结论但如果你想完整继承 ponytail 的行为仓库给出的路径是直接采纳结论JS 项目中把numeral/accounting替换为Intl.NumberFormat上文的三段代码即可原样复制运行换语言/地区只改第一个参数。安装 ponytail 技能若使用 Claude Code / Codex 等支持技能的主机按 README.md 的安装节操作例如 Claude Code 下执行/plugin marketplace add DietrichGebert/ponytail后/plugin install ponytailponytail两条需分别发送。安装后默认强度为full可用/ponytail lite|full|ultra或环境变量PONYTAIL_DEFAULT_MODE调整用 stop ponytail 或 normal mode 关闭。强度含义见 skills/ponytail/SKILL.md 的 Intensity 表lite只提示更懒的替代方案full默认强制执行阶梯ultra是 YAGNI 极端派。保留ponytail:注释约定即使不装技能在刻意简化的地方留一行说明上限与升级路径的约定本身就值得沿用——示例首行注释正是这个约定的示范。验证ponytail 的边界规则明确Never simplify away: input validation at trust boundaries, error handling that prevents data loss, security measuresskills/ponytail/SKILL.md When NOT to be lazy 一节。就数字格式化而言这意味着可以省掉依赖但上游传来的非数字、NaN、负数等边界处理不能因为更懒而被删掉。小结examples/number-formatting.md 用最小的一个任务演示了 ponytail 的主张货币、百分比、紧凑记数三种格式化Intl.NumberFormat一个内置 API 全覆盖省掉numeral或accounting的依赖与维护成本还顺带获得 locale 正确性。它不是一段手写教程而是基准跑出来的真实模型输出Claude Haiku 4.5temperature 1来源benchmarks/output.json可用npx promptfoolatest eval -c benchmarks/promptfooconfig.yaml复现支撑它做出这个选择的是 skills/ponytail/SKILL.md 中标准库先于依赖的决策阶梯以及 docs/platform-native.md 中把numeral与Intl.NumberFormat直接对位的对照表。对日常开发者的可迁移结论只有一条在为一类格式化需求装库之前先问一句平台是不是已经带了。【免费下载链接】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），仅供参考
