最好的代码是你没写的那行

“执行越来越不值钱，判断越来越值钱。最难的从来不是把事情做出来，而是想清楚哪些事根本不该做。”

核心观点 / 起源

2026 年初，GitHub 上有个项目一周之内涨了两万颗星。

它没有炫酷的架构图，没有跑分屠榜的模型，核心逻辑加起来不到一百行 Markdown。它的名字叫 Ponytail——马尾辫。作者 DietrichGebert 给它写了一句堪称广告金句的介绍：

让你的 AI agent 像房间里最懒的那个高级开发者一样思考。

附带的数据更诱人：代码量减少 80-94%，任务速度快 3-6 倍，成本便宜 47-77%，在 13 个 agent 上验证过。

听起来像是某种黑科技。但当你真正打开它，会发现里面没有任何“技术”——只有一句话被反复强调：最好的代码，是你根本没写的那行。

这到底是技术突破，还是一堂营销大师课？我花了点时间把它拆开看，结论比“是”或“否”有意思得多。

我的核心判断很简单：Ponytail 在技术上乏善可陈，但它戳中的那个问题永不过时——在动手做任何事之前，先停下来问一句：这件事，真的需要做吗？

细节展开

Ponytail 的全部精华，是一架六级的“决策梯子”。在 AI 动手写任何代码之前，它必须从上到下依次自问：

• 第一级 · YAGNI： 这段代码真的需要存在吗？这个功能真的需要实现吗？不需要，就到此为止。
• 第二级 · 标准库： 语言自带的标准库能搞定吗？能，就别造轮子。
• 第三级 · 平台原生： 浏览器、操作系统、语言本身有没有现成的原生 API？有，就用它。
• 第四级 · 已有依赖： 项目里已经装好的库能不能解决？能，就别加新依赖。
• 第五级 · 一行代码： 能不能一行写完？能，就一行。
• 第六级 · 最小实现： 写能跑起来的最小代码，不多写一个字符。

举个经典例子。让 AI 做一个日期选择器，默认它会给你装上 flatpickr，引入一个第三方库，配一堆参数，写几十行初始化代码。而走完这架梯子，它会停在第三步——浏览器原生就有 <input type="date">，一行 HTML 解决战斗。

你发现了吗？这架梯子最反常的地方，不在于它教你怎么写，而在于它教你在哪一步停下来。

别人讲软件设计，梯子通常是从上往下的：从需求出发，一层层细化到实现。Ponytail 的梯子是反的——它是从最底层往上喊停的。你越早在梯子上喊停，你写的代码就越少。理想状态下，你在第一步就喊停了：这功能压根不用做。

所以这架梯子真正训练的能力，不是“少写代码”。少写只是结果。它训练的是一种判断力：在动手之前，先确认这件事到底要不要做。 真正的懒惰不是少做事，而是有能力拒绝去做那些不需要做的事。

过程 / 推演

第一层：把一个 90 年代的老原则推到极致

如果你做过几年开发，这架梯子的第一级你一定眼熟。

YAGNI——You Aren’t Gonna Need It，“你不会需要它的”——是 90 年代极限编程（Extreme Programming）留下的老话。它的意思很朴素：不要为“将来可能用到”的功能提前写代码，因为那个“将来”大概率不会来，而你为它付出的复杂度是实打实的。

Ponytail 没有发明任何新东西。它只是把这条三十年的老原则，推到了一个更激进的位置。

传统的 YAGNI 主要管“怎么写”——已经决定要做这个功能了，那就别把它写得太复杂、别过度设计。而 Ponytail 把喊停的时机往前挪了一步，挪到了“要不要写”这个层面：在你考虑怎么实现之前，先逼你确认这东西到底该不该存在。

这一步前移，看似微小，却揭示了一个反常识的能力分层：

少写代码，是一种技能。但判断“哪些代码根本不需要存在”，是更高阶的技能。

前者是手上的功夫——你知道用 <input type="date"> 代替 flatpickr。后者是脑子里的功夫——你在需求会议上就敢说“这个功能我们不做”。手上的功夫可以练，脑子里的功夫需要的是对全局的判断和说“不”的底气。Ponytail 用一架梯子，把后者变成了一个可以被强制执行的反射动作。

第二层：这架梯子有个没人提的前提

但我越看这架梯子，越觉得它藏着一个被刻意忽略的盲区。

回头看那六级台阶：标准库能搞定吗？平台有没有原生 API？已有依赖能不能解决？——这三问都建立在同一个隐藏前提上：你已经知道标准库里有什么、平台提供了什么、项目装了哪些依赖。

对一个资深开发者，这个前提成立。他脑子里有一张完整的认知地图：他知道 Python 的 itertools 里藏着什么，知道浏览器原生支持 <input type="date">，知道 Intl.NumberFormat 能格式化货币而不用引第三方库。所以他能在梯子的第二、三、四级精准喊停。

但对一个新手呢？

新手不知道 <input type="date"> 存在。所以当他走到梯子第二步“平台原生能搞定吗”，他诚实的答案是“我不知道”——于是梯子就卡在这里，他只能滑到下面，去装 flatpickr。他不是不想偷懒，是他没有偷懒的资本。

这就是 Ponytail 最深的一个矛盾：

它需要“资深开发者的认知地图”才能被正确使用——但它本身又号称要教人变得像资深开发者一样思考。

换句话说，这架梯子是一面镜子，不是一架梯子。它照出的是你已经有多少积累：你的认知地图越完整，你能在越上层喊停，你就显得越“懒”、越“高级”。它并不能凭空给你那张地图。

而这个盲区，远不止存在于写代码。它存在于一切“先判断、再行动”的场景里——你只有先知道有哪些选项，才谈得上做减法。一个不知道图书馆有什么的人，没法“精准借书”；一个不知道市面上有什么工具的人，没法“只买需要的”。减法的前提，是你得先拥有那个可供削减的全集。

第三层：如果判断也被 AI 接管了，人还剩什么

顺着这架梯子再往前想一步，会撞上一个更不舒服的问题。

Ponytail 现在做的事，本质上是把资深开发者的判断力，封装成一段提示词，交给 AI 去执行。也就是说——“这段代码不需要写”的判断，AI 来做；“标准库里有现成的”的回忆，AI 来做；“写出最小实现”的执行，AI 来做。

那人还干什么？

如果连“判断要不要做、回忆有什么现成的、写出最精简的实现”这些原本属于资深开发者的核心能力，都能被一段提示词复刻并交给 AI，那么人类开发者的护城河到底在哪？

我的推论是：真正不可替代的，恰恰是这架梯子够不到的那些东西——

• 判断方向： Ponytail 能帮你把“做这个功能”做得最精简，但它不能替你决定“该不该立这个项目”“产品该往哪个方向走”。它优化的是路径，不是目的地。
• 批判思考： AI 给出的“最小实现”是不是真的对？它有没有在某个你没说出口的约束上栽跟头？判断 AI 是否出错，本身需要人。
• 建立连接： 把两个看似无关的领域接起来，从日期选择器联想到“消费主义”，从一架代码梯子联想到“判断力的稀缺”——这种跨域的联想，是 AI 目前最弱的一环。
• 用自己的语言输出： 把想清楚的东西，用别人能懂、能被打动的方式讲出来。这件事，你正在读的这篇文章本身就是证明。

所以我反而觉得，Ponytail 不是那把让程序员失业的剪刀。它更像一架阶梯，把人从“码农”那一层，往上抬到“判断者”那一层：当写代码这件事的边际价值被 AI 不断压低，你的价值就必须迁移到 AI 够不到的地方——判断、批判、连接、表达。 这不是安慰，这是一个相当现实的职业建议。

把这架梯子搬出代码：它在生活里的三个投影

如果 Ponytail 的内核只是“动手前先问需不需要”，那它就不该只属于写代码。我试着把这架梯子搬进三个日常场景，发现它意外地好用。

• 学习上 · 用情报收集替代盲目启动。 很多人学一门新东西的第一反应是“从第一章开始地毯式啃”。但走 Ponytail 的梯子，第一问应该是：我学这个要解决什么具体问题？如果只是为了解决一个具体问题，那我根本不需要通读，我需要的是精准定位到那一章。先花十分钟做“情报收集”，再决定动手的范围。
• 读书上 · 先问目的，再定深度。 不是所有的书都值得从第一页读到最后一页。为解决问题，直接翻到相关章节；为建立体系，才需要通读和做笔记；为判断价值，先读序言、目录和结论。把“读完一本书”这个执念，换成“从这本书里取到我需要的东西”。
• 消费上 · 购物车版的 YAGNI。 下单之前，把那六级梯子原封不动地搬过来：我真的需要它吗？我已经有的东西能不能替代？有没有更简单、更便宜的方案能达到同样目的？光是认真走完第一级，大半冲动消费就会停在购物车里。

如果你想试，这里有一个一周实验：接下来七天，每当你准备开始做一件事——学一个新工具、买一样东西、启动一个新项目——强迫自己先问梯子的第一问：“这件事真的需要做吗？”把答案是“不”的那些记下来。一周后你会惊讶于，有多少你以为非做不可的事，其实根本不用做。

一点补充：但它真的值两万颗星吗？

讲到这里，我得给你泼盆冷水——而且这盆冷水非常重要，因为它本身就是 Ponytail 哲学最好的注脚。

2026 年 6 月，Scott Logic 的博客发了一篇尖锐的拆解，把这个项目扒了个底朝天，结论相当不客气。

第一刀：它就是一百行 Markdown 重读了一遍 YAGNI。 这个仓库号称有 6232 行代码、横跨 90 个文件，听着很唬人。但真正起作用的逻辑，就是那个不到一百行的 Markdown 文件，而它的内容用作者的话说“不过是对 90 年代 YAGNI 原则的一段描述”。剩下的几千行，是测试、是脚手架、是包装。

第二刀，也是最致命的一刀：那套漂亮的基准数据，是靠让对手“放水”放出来的。 Ponytail 的跑分逻辑是比代码行数（LOC）。但它的对照组——没装任何技能的“裸 agent”——在回答时往往会礼貌地列出好几个备选方案、附上解释和注意事项，这些全被算进了代码行数里。换句话说，对照组不是“写了很多代码”，而是“说了很多话”，然后这些话被当成代码量记在了它头上。 真实世界里的编程 agent 有系统提示词压制这种啰嗦输出，根本不会这么“输”。

作者干脆自己上手做了个实验，数字一目了然（Haiku 模型，比代码行数，越少越“好”）：

看明白了吗？仅仅在提示词里加一句“遵循 YAGNI 原则，用一行代码解决”——七个词——就在 Ponytail 自己的基准测试上击败了 Ponytail。 那个号称 6232 行、横扫 13 个 agent 的项目，被七个英文单词干翻了。

更尴尬的是，作者还发现 Ponytail 自带的一个去抖（debounce）测试在所有用例上反复失败——因为那段代码默认假设运行环境里有 DOM，而这个前提在很多场景根本不成立。这恰好印证了前面说的：最小实现要是建立在一个错误的隐藏前提上，它就不是“优雅”，而是“脆弱”。

那么，Ponytail 一文不值吗？也不是。我的判断是：它在技术上是彻头彻尾的“旧酒装新瓶”——但它真正的创新，从来就不在技术那一层，而在品牌那一层。 它把一个三十年的老原则，用“房间里最懒的高级开发者”这个精准比喻重新包装了一次。两万颗星投的不是那一百行 Markdown，是这个比喻。这件事本身就很 Ponytail：真正稀缺的价值，不是那段谁都能写的代码，而是那个让所有人记住它的判断和表达。

结语 / 反思

绕了一大圈，我们回到最开始那句广告语：最好的代码，是你没写的那行。

Ponytail 真正教给我们的，其实不是任何一种新技术。它甚至在技术上乏善可陈，经不起一篇博客的拆解。它真正戳中的，是一个古老到所有人都知道、又古老到所有人都忽略的问题：

在动手做一件事之前，先停下来问一句——这件事，真的需要做吗？

写代码如此，装依赖如此，学习、读书、消费，无不如此。我们这个时代不缺执行力——AI 已经把执行的成本压到了地板上，你想写一万行代码，它几秒钟就给你。我们缺的，是在所有人都急着动手的时候，有人敢先停下来问“要不要做”的那份判断力。

执行越来越不值钱，判断越来越值钱。

这才是那架小小的梯子，在它那点单薄的技术含量之外，真正留给我们的东西：最难的从来不是把事情做出来，而是想清楚哪些事根本不该做。

本文资料来源：DietrichGebert/ponytail GitHub 仓库；Scott Logic 博客《Ponytail, YAGNI, and the Problem with Prompt Benchmarks》(2026.6.16)；The AI Leverage《Ponytail: Less Slop, Cleaner Outputs》。基准测试数据（Haiku 模型 LOC 对比）引自 Scott Logic 复现实验。