企业官网建设流程全解析

摘要：一个十七万星的开源 skill，全部内容是一段叫你别写代码的提示词。它能让 Agent 少写一半代码，但正确性一格没涨。这篇讲清六级台阶怎么走，以及它的数字为什么被改过两回。

你让 Agent 加一个日期选择器。

它大概率会装个日期库，包一层组件，配好样式，再补几个测试，最后跟你解释时区该听谁的。

这种活儿在基准里真跑过。同一个需求，不带 skill 的 Agent 交上来三百三十五行的 diff。

你把这段 diff 发给组里那个话最少的人。他看了两秒，删掉三百二十五行，留下一个<input type="date">。

这不是段子。在他动手之前，浏览器就已经支持日期选择了。Agent 不是不知道，是没人告诉它「可以不写」。

可为什么它默认就来一遍全套？

这个问题，是下面整篇文章的起点。

一段提示词，十七万星

GitHub 上有个项目叫 ponytail，作者是 Dietrich Gebert。我查的时候是十七万零三百颗星，九千二百个 fork，MIT 协议，六月十二号建的仓。核心就是一段提示词，一个SKILL.md，加一份压缩版AGENTS.md。

它的自我介绍很直接：「让你家 AI Agent 像屋里最懒的那个资深开发一样思考。最好的代码，是你从没写过的代码。」

你大概会想，凭什么？一个 prompt 卖得比很多完整工具还热。

原因在于它解决的不是「模型会不会写」，而是「模型从哪儿开始写」。

你把「加个日期选择器」丢给现在的 Agent，它的起点是「写」。装库、封组件、配样式、加测试，一路往上加。整条路径里没有一站叫「这东西需要存在吗」。

ponytail 干的事，是硬塞进去五站，让它先往后退。

六级台阶，前五级都是别写

原文的阶梯是这样排的，取第一条真正成立的往下走：

站到最上面一级，先问这东西需要存在吗。没人要的功能、选项、灵活性，砍掉，然后用一行话说明你砍了什么。一个含糊的需求，给那个能干活的最小版本。

往下走一级，问代码库里是不是已经有了。有 helper、有组件、有 service、有现成写法，就按周围代码的用法用它。

再往下，看标准库或者平台自带。有就用，除非项目自己有。项目自己的组件胜过平台原生控件。

再往下，看已经装了的依赖。用它，绝不为几行代码加一个新依赖。

只剩最后两级才轮到写。能写成一行、读者一眼看懂的，就一行；实在不行，写能跑通的最小代码。

你数一下，六级里五级是「用现有的」，只有最后一级才是「新写」。

作者还专门写死了一条不剪的清单：信任边界的校验、防止数据丢失的错误处理、安全、可访问性、真实硬件需要的标定、用户明确要的东西。这六样永远不在削减之列。原话是，对方案懒，对改动本身绝不懒。

还有一句更要紧，容易被忽略：阶梯跑在读懂代码之后，不是代替读懂。动手前先读这次改动会碰到的代码，把每一处会波及的地方列出来，调用方、测试、fixture、配置、导出，再看这个改动会毁掉或者暴露哪些用户数据。

先搞清边界，再决定少写。这两步顺序反了，就是另一种事故。

省下来的不是代码，是那个「以防万一」

看它的实测表，省得最多的地方很有规律。

日期选择器，三百三十五行走十行。颜色选择器，一百三十五行走二十六行。拖拽上传，二百四十七行走六十二行。向导，三百一十一行走九十行。命令面板，三百一十九行走一百三十一行。

这些任务的共同点是：平台原生就有，而 Agent 习惯自己造一个。

反过来看那些几乎没动的。缓存任务十一行对十一行，金额复用九行对九行，转账追踪二十七行对二十行。这些本来就没什么可省的。

作者自己的结论是一句话：有冗余的地方省，没冗余的地方别指望有效果。

那它凭什么在冗余的地方省这么多？

因为模型的默认动作是「把活干漂亮」。你要一个日期选择器，它给你一个「可复用、可扩展、带时区处理、符合设计规范」的日期选择器。每一条单拎出来都算优点，加在一起就是三百三十五行的沉没成本。

你翻翻自己的代码，有没有这种「顺手做全了」的工具类？这种类一般三个月没人碰，注释里还写着「预留扩展」。

而人不是这么想的。资深的人先问「这玩意儿非写不可吗」，再问「有没有现成的」，最后才动手。这套判断他做了二十年，快到自己都意识不到在做。

ponytail 做的就是把这套判断从直觉里捞出来，排成队，逼 Agent 一级一级过。

中途有个陌生人，把它的数字按住了

到这里故事本来可以结束了。一个聪明的 prompt，一组漂亮的数据，一个开源项目。

但真正值得写的是后面这段。

六月中旬，一个叫 Colin Eberhardt 的人跑了一遍它的基准，然后在 issue 126 里提出了两个问题。

第一个问题最要命。他说你的基线不公平：裸模型接到任务会像聊天一样，给你五个方案，每个方案配三段解释。这些东西在统计时全被算成了「代码行数」。

他加了一句系统提示：「只给一个例子，不要评论，不要用法示例。」

他跑的是 Haiku，还把有歧义的 debounce 那道题剔掉了。基线从一百零八行掉到十六行，ponytail 是八点二五行。

也就是说，基线自己先好了约七倍。那组数据里 ponytail 的领先幅度，从十几倍缩到两倍上下。

他在 issue 里写，因此这个项目的核心主张应该收敛一点。

换你，被人当面指出你一半的优势来自一次不公平的对比，你会怎么回？

作者的回帖我看了一遍。他没有辩解。原话是：「你说得对，标题里的那个数字太强了，等数字公平了我就把它改温和。」

接着他把整套基准重做了。每次运行都是真实的 headless Claude Code 会话，不是裸 API；改的是一个真实公开仓库，tiangolo 的 full-stack-fastapi-template；基线换成同一个 Agent 不带 skill，这样差距只能来自 skill 本身，不来自模型啰不啰嗦。

结果从「百分之八十到九十四」掉到百分之五十四。

后来又重做一轮，变成百分之五十三。

一个十七万星的项目，把自己的看家数字砍掉四成，还写在了仓库里。

我见过太多项目把跑分当资产护着。这个作者把它当负债清了。

数字降了，东西变差了吗

没有。但也没变好——这句话得说清楚。

最新一轮基准，Opus 5.5，三十九个任务，每个跑五次，一共五百八十五次会话。

代码行数少百分之五十三，输出 token 少百分之四十五，耗时少百分之四十一，成本少百分之二十六。单次会话平均花费从两毛美金降到一毛四分二。

正确性呢？

三十九个任务里只有十八个带隐藏检查——真的把代码跑起来，验证结果对、没有安全洞和隐私洞。这十八个任务九十个格子里，不带 skill 通过八十六个，ponytail 5 通过八十七个。

差一格。

安全这块它守住了。六个安全任务——SQL 注入、路径穿越、伪造令牌、限流、畸形 CSV、缓存——三个实验组各三十次运行全过。

但剩下二十一个任务根本没有正确性检查。作者自己在文档里写得很清楚：这二十一个任务是用来看代码体积的，它们的「通过」只代表代码交付了或者能编译，我不把它们算作品质结果。

这句自我限制，比任何漂亮数字都可信。

还有一处更细的反转，藏在测试那一节。

规则要求：带分支、带循环、带解析、碰钱或者碰安全的新逻辑，必须留一个小测试或者一个 assert 自检，琐碎改动不用。

按这个标准分类，二十二个任务该有测试，十一个不该。

结果：该有测试的任务里，不带 skill 只有百分之六十八写了一个，ponytail 5 是百分之九十八。这一项涨得最漂亮。

再看测试有没有用。作者往 Agent 写的代码里注入了小 bug——翻个比较符、删个 if、错个边界——然后拿 Agent 自己写的测试去跑。

所有格子里，抓到的比例从百分之四十六提到百分之六十六。

但在本来就有测试的格子里，这个比例从百分之七十七降到百分之六十九。

也就是说，它让你更可能有测试，但那个测试本身抓 bug 的能力弱了一点。原因作者也写了：它新增的测试里，二十五个格子中有二十个是「两到四行 assert 写在示例代码里」，只有五个是正经加进仓库测试套件的接口测试。

三行 assert 能证明「这个函数跑通了一次」，证明不了「这个函数在边界上不出错」。

所以这个 skill 买到的到底是什么？

它买到的是少写，不是更稳。它没有让代码更正确，也没有让代码更不安全，它只是让代码变短，同时把「有没有测试」这件事从六成八推到了九成八。至于测试本身严不严，它没管。

这跟一个写 Java 的人有什么关系

有，而且比你想的直接。

你接了个需求：给现有列表加个导出 Excel 的接口。

默认动作是新建一个ExportService，写一个ExcelUtil，加两个配置项控批次大小和超时，再加一层重试。

按阶梯走一遍。项目里已经有导出吗？大概率有，就在某个 handler 里躺着一个私有方法。POI 已经是依赖了吗？是，三个月前另一个需求就引了。那这次需要的，可能就是一个方法加一行调用。

我翻过自己手头一个模块，四个类里只有一个真正被别处调着。另外三个是我当初「先把架子搭起来，以后扩展方便」搭的。以后一直没来。

阶梯的价值就在这儿：它把「该不该写」从判断题变成了选择题。判断题需要品味，选择题只需要按顺序往下走。Agent 没有品味，但会做选择题。

顺带说一个比阶梯更值得抄的东西。

规则里要求：每个带已知局限的捷径，留一行这种格式的注释——shortcut: <局限是什么>, <什么时候该升级它>。

然后给了一个/ponytail-debt命令，把这些注释收进一个台账，按重要性排。

这一手解决的是技术债里最滑的那种：不是不想还，是还的时候忘了当初为什么这么写、什么时候必须改。// TODO写一万个也没人看，因为 TODO 不带触发条件。shortcut: 单批上限五千行，超过就走流式这样的写法带了。

你的项目里要真能坚持这个格式，比装不装这个 skill 重要得多。

那你上一次主动放弃写一个类，是什么时候？

回头看

那句叫你别写代码的提示词，值十七万星，不是因为它聪明，是因为它替 Agent 补了一个所有模型都缺的问句：这东西需要存在吗。

六级台阶前五级都是「用现有的」，写代码排在最后。这个顺序给人的震撼，比给模型的更大。

阶梯必须跑在读懂代码之后。先读、先列波及面、先看会不会毁数据，然后才准少写。顺序反了就是事故。

它买到的是少写，不是更稳。行数砍了一半，正确性一格没涨；有测试的比例冲到九成八，但测试抓 bug 的能力反而从七成七掉到六成九。

那个作者最该被记住的动作不是写规则，是被人按住之后把看家数字砍掉四成。跑分是负债，不是资产。

真要抄一样东西，抄那个带触发条件的shortcut:注释。放弃一个东西的时候写清什么时候回来，比什么都写 TODO 强。

作者：唐悦玮 | 从后端出发，用 AI 拓展到全栈的工程师。

参考资料

• DietrichGebert/ponytail——项目仓库，MIT
• AGENTS.md 原文——六级阶梯与不剪清单的出处
• Agentic benchmark 结果——三十九任务、五百八十五次会话、逐任务表与局限说明
• Issue 126：baseline scores are ~7 times better——基线争议与作者回应的完整对话
• fastapi/full-stack-fastapi-template——基准所用的真实仓库