夜雨聆风
嗨大家好，这里是硅潮。
你肯定遇到过这种场景。
你只是想把一批实验目录扫一遍：读几个 csv，抓几行日志，把没收敛的样本挑出来，最后吐一个 summary.csv。结果 AI 一上来给你建了 src/、config/、services/、validators/，再塞一个 CLI 框架、一个日志系统、一个缓存层，甚至还准备了“未来可扩展插件接口”。
问题是，你今晚根本不需要一个平台。
你只需要知道：哪几个结果能用，哪几个要重跑，哪几个只能当参考。
AI 写代码现在最大的副作用之一，就是它太会“显得专业”了。它不累，不心疼行数，也不怕明天维护。于是很多一次性科研脚本、数据清洗脚本、小型自动化任务，会被它写成一个小型企业系统。
这也是我觉得 Ponytail 值得看的原因。
Ponytail 是 DietrichGebert 放在 GitHub 上的一个开源 Skill。项目 README 的设定很有画面感：一个留着马尾、戴椭圆眼镜、在公司待得比版本控制还久的老开发，看你写了 50 行，沉默几秒，然后换成 1 行。
Ponytail 要做的事，就是把这个人塞进你的 AI agent 里。
它不是新模型，也不是新的代码生成器。更准确地说，它是一组“反过度工程规则”：让 Claude Code、Codex、OpenCode、Cursor、Windsurf、Cline、Copilot、Aider、Kiro 这类写代码工具，在动手前先问几个讨厌但必要的问题。
第一个问题最狠：这东西需要存在吗？
如果只是想“以后也许会用”，那就别写。
Ponytail README 里把这套判断叫成一架梯子。AI 写代码前，先从第一阶开始停：能不写就不写；标准库能做，就不要手搓；浏览器、数据库、操作系统这些原生能力能做，就不要再包一层；项目里已经有依赖能做，就不要再加新的；一行能解决，就不要写五十行。最后才是“写最小可用实现”。
这听起来很像一句老话：YAGNI，You Aren’t Gonna Need It。
但放到 AI 编程里，它突然变得更重要了。
因为人写一套抽象，至少会心疼半小时。AI 写一套抽象，只要十几秒。成本一低，垃圾就会变多。你让它“严谨一点”，它可能理解成“多写几层”。你让它“可维护一点”，它可能理解成“先造一个框架”。
Ponytail 干的事，就是把“少写代码”从一句口头提醒，变成每次输出前的默认动作。
README 里有个很典型的例子：你让 agent 给表单加一个 date picker。没有约束时，它可能安装 flatpickr，写 wrapper component，加 stylesheet，再讨论 timezone。Ponytail 给的版本是：
这个例子甚至有点好笑，但它非常准确。
很多时候，我们不是缺代码能力，而是忘了平台已经提供了答案。浏览器有日期控件，Python 有 csv、json、pathlib、sqlite3、functools.lru_cache，数据库有唯一约束和事务，操作系统有临时文件和原子替换。你让 AI 从零写一个“高级方案”，它很乐意。你让它先查标准库，它才会冷静下来。
科研脚本尤其适合这套思路。
科研里的很多代码，不是要服务十万用户的 SaaS。它是胶水：把上游软件的输出接住，把一堆文件名、能量、收敛状态、图表路径整理出来，让人能继续做判断。它最需要的不是“架构感”，而是三件事：短、直、可复跑。
短，意味着你明天还能读懂。
直，意味着输入、处理、输出在一条线上，不要绕进类继承和事件总线。
可复跑，意味着它至少有一个最小检查，能证明关键逻辑没坏。
这也是 Ponytail 比普通“少写点”提示更完整的地方。它不是让 AI 变莽。项目 Skill 里明确写了几条不能砍的东西：信任边界上的输入验证、防止数据丢失的错误处理、安全措施、可访问性，以及用户明确要求的内容。非平凡逻辑还要留下一个最小可运行检查，比如一个 assert demo、一个 __main__ self-check，或者一个很小的测试文件。
换句话说，它要砍的是“为了显得高级而长出来的代码”，不是砍掉安全带。
项目 README 还给了一组 benchmark 数字。这里要说清楚：这些数字来自项目 README 和同仓库 benchmark 自述，硅潮本轮没有独立复测，所以只能按“项目自述声称”处理。
按照 README 的说法，它们拿六个任务做对比：streaming log parser、atomic file sync、notification dispatcher、validation engine、auth module、concurrent money ledger。三组分别是无 skill、Caveman skill、Ponytail。同一模型，同一组安全和并发 probe。README 声称 Ponytail 相比无 skill 少 47% tokens，快三倍，代码量约为七分之一；同仓库 benchmark 里还写到，构建阶段 LOC 是 no-skill 3629、Caveman 1440、Ponytail 490。benchmark 自己也备注了：wall time 有并行调度噪声，n=1。
所以这些数字不要当成行业结论。
但它们至少说明了一个值得继续看的方向：给 AI 一个“少写代码”的强约束，可能不只是让代码短一点，也可能让后续改动便宜一点。README 里还自述，两个 surprise feature request 下，Ponytail 的改动行数是 96，Caveman 是 413，无 skill 是 1115。这个结论也只能按项目自述看，但方向很符合直觉：你一开始没造十层楼，后面改门牌号就不会先跑消防验收。
如果你想马上把这件事用到自己的科研脚本里，不一定非要先装插件。你可以先把下面这段当作 prompt pack，用在 Codex、Claude Code 或其他会写代码的 agent 前面。
写代码前按顺序检查：1. 这件事是否真的需要写代码？能用现有命令/标准工具完成就不要新写。2. Python 标准库或系统命令能否完成？优先用它们。3. 项目已有依赖能否完成？不要为了几行逻辑新增依赖。4. 一行或一个短函数能否完成？不要创建框架、基类、插件系统。5. 最后才写最小可用版本。
输出要求：只交付能跑的最短实现。非平凡逻辑留下一个最小 assert/demo/self-check。所有故意简化用 # ponytail: 注释写清楚边界和升级路径。
如果你的场景更具体，可以这样问：
真正落地时，我建议你把它放到项目级说明里，而不是每次聊天临时补一句。比如在科研项目的 AGENTS.md，或者你的 agent 支持的项目规则/仓库说明里写清楚：这是分析脚本优先的仓库，标准库优先，禁止未来式架构，所有故意简化都要留下升级触发条件。
这样做有个好处：AI 不会每次重新揣测你的口味。它会默认知道，这个目录里最重要的不是“看起来像大工程”，而是让实验记录更清楚、让结果更快回到人手里判断。等某段脚本真的被反复使用、多人依赖、出现性能瓶颈，再升级成模块、CLI 或服务也不迟。
已经让 AI 写完了，也可以反过来审一遍：
你可以把这套 review 当成科研脚本的“红旗检查”。
如果 AI 一上来建 Manager、Factory、Provider，先按暂停。
如果一个常量只有一个值，却被抽成配置文件，按暂停。
如果一次性目录扫描，被写成插件系统、任务队列、服务层和 domain model，按暂停。
如果一个小 CSV 统计任务，上来就引入 Dask、Ray 或数据库，而你本地 csv/pandas 已经够用，按暂停。
如果没有测量就加缓存，没有第二个实现就加接口，没有第二种输出就加 exporter，也按暂停。
但还有另一种红旗也要看：它是不是为了短，把输入边界、文件覆盖保护、金额/权限/安全逻辑也砍了。如果是，这不是 Ponytail，这是偷懒。
我喜欢 Ponytail 的地方，是它对“懒”的定义很工程化：懒不是少负责，懒是不拥有本不该拥有的复杂度。
你写一个科研脚本，最怕的不是它今天只有 60 行。很多 60 行脚本，反而是最可靠的，因为每一行都能看见。真正可怕的是它为了“未来”，提前长成 600 行。半年后你回来，只记得它很完整，但已经看不懂哪里能动。
AI 让写代码变便宜了，但维护没有变便宜。你今天让它多写出来的每一层，明天都要有人负责理解、调试、解释、删掉。
所以我会把 Ponytail 当成一个很实用的刹车。
不是所有项目都该极简。长期系统、多人协作、强安全边界、明确可扩展需求，当然需要设计。但大量科研脚本、实验工具、一次性数据处理、小型自动化，本来就不该被写成平台。
你要的不是一个宏伟架构。
你要的是今晚能跑，明天能懂，下个月还能删。
Ponytail 的价值就在这里：在 AI 准备大展身手之前，先让它问一句——这段代码，真的需要出生吗？
往期推荐 / 延伸阅读
别再把 Codex 只当聊天工具了，装上这套技能以后，它更像一个能交付的工程队友
同样讲 Skill 如何改变 Agent 的工作方式。
AI 编程 Agent 第一份全栈榜单：Cursor 第一，Gemini 垫底，真正的战争变了
接着看 AI 写代码从“能写”走向“能交付”的验收问题。
把 VASPKIT 交给 Codex，晶体计算的苦活会少很多
科研脚本/计算任务里，少写代码和保留验收边界同样重要。
参考来源
• DietrichGebert/ponytail GitHub README：https://github.com/DietrichGebert/ponytail
• Ponytail Skill：skills/ponytail/SKILL.md
• Ponytail Review Skill：skills/ponytail-review/SKILL.md
• Benchmark 自述：benchmarks/results/2026-06-12-v4-hardening-vs-caveman.md
• Examples：examples/date-picker.md、examples/caching.md、examples/email-validation.md
