Tailwind 为何裁掉了四分之三的工程师

下载量创历史新高，营收却蒸发了 80%

今年 1 月，有一条新闻悄无声息地滑过了公众视野。

开发 CSS 框架 Tailwind 的公司裁掉了 4 名工程师中的 3 名。而就在同一时期，Tailwind 的月下载量达到 7500 万次，在 2025 年 State of CSS¹ 调查中以 51% 的开发者采用率成为了有史以来使用最广泛的 CSS 框架。产品使用量创下历史峰值，公司却把工程师人数从 4 人缩减到了 1 人。

创始人亚当·沃森（Adam Wathan）披露的数据是这样的：官方文档网站的访问量较 2023 年下降了约 40%，营收下滑了约 80%。

这并不是一个产品失败的案例，而是产品变现路径被切断的典型范例。Tailwind 原本依靠向访问官方文档的访客销售付费产品来创造营收，但随着这部分流量的缩减，营收也随之崩塌。 并且，这种结构性困境并非 Tailwind 独有，它正笼罩着各位读者的公司产品所依赖的整个开源软件供应链。

🚰 因为 AI 垃圾（AI slop），接受外部贡献的通道被堵死了

首先来看看技术圈正在发生的事情。

如果您正在阅读这篇文章，那么您刚才就已经用过了 cURL 这款软件。即使您没有打开浏览器，只要今天碰过智能手机、笔记本电脑、电视或汽车中的任何一样，您同样也用过了它。据估计，cURL 的核心组件 libcurl 的安装量已超过 200 亿次。平时我们根本意识不到它的存在，却每天都在使用它。

cURL 是一个始于 1996 年的开源项目。它由瑞典开发者丹尼尔·斯滕伯格（Daniel Stenberg，55岁）创建，至今仍由他全职维护。虽然贡献者名单超过 3,000 人，但全职人员只有他一个。

“长期以来，我都是 cURL 唯一的全职人员。其他人全是志愿者，来来去去。我不知道明天还有谁会留下来。”（丹尼尔·斯滕伯格）

埃里克·雷蒙德（Eric S. Raymond）把这类人称为“承重墙般的互联网人（load-bearing internet people）”。就像一堵默默承受着整栋建筑重力，却从未有人正眼瞧过的承重墙。

然而在今年 1 月，斯滕伯格终止了运营 6 年的漏洞赏金²计划。在这 6 年里，该计划共发放了 8万 6000 美元（约 1.2 亿韩元）奖金，修复了 78 个实际漏洞。终止的原因只有一个：AI 垃圾（AI slop）³的暴增。

斯滕伯格透露，在过去 6 年里，由 AI 生成的漏洞报告中，没有哪怕一份指出了真正的漏洞。相反，涌入的全是看起来煞有介事、附带虚假 GDB 会话日志和寄存器转储（dump），甚至还引用了根本不存在的函数的伪造报告。

他这样写道：

“没完没了的垃圾报告不仅让人付出沉重的精神代价，要驳斥它们也得耗费大量时间。这完全是在浪费时间和精力，甚至在消磨我们活下去的意志。”

同月，数字白板工具 tldraw 的创始人史蒂夫·鲁伊斯（Steve Ruiz）开始自动关闭外部贡献者的 Pull Request⁴。他并不反对用 AI 写代码，他自己也用，而且还鼓励团队使用。问题出在别的地方。

“如果写代码是容易的部分，那我为什么还要指望别人来帮我写代码？”（史蒂夫·鲁伊斯）

AI 生成的贡献在形式上看起来挑不出毛病，却脱离了上下文，误读了代码库，更致命的是，提交者根本不会参与后续的讨论。 过去，新的贡献者会在伴随项目成长的过程中，最终变成值得信赖的维护者。而现在，人们只需把工具对准项目点一下，即使接纳了他的贡献，他也完全没有理由去深入了解这个项目。

审查成本纹丝未动，生产贡献的成本却已逼近于零。今年 3 月发表的一篇论文将这种现象定性为“公地悲剧”。这意味着个人的生产力提升，最终被作为成本转嫁给了审查者、维护者以及整个社区。

💰 原本赖以变现的路径被切断了

接下来谈谈经济层面。这里我们要再次把视线拉回 Tailwind。

Tailwind 以往的商业模式遵循着这样一条闭环：开发者搜索“如何让 div 居中” → 进入官方文档 → 看到文档边栏推荐的付费产品（Tailwind UI）广告 → 下单购买。官方文档的访问流量，原本就是其核心的销售转化漏斗。

然而，大语言模型（LLM）却硬生生砍掉了“进入官方文档”这一环节。如今开发者不再去查阅文档，而是直接去问 Claude 或 ChatGPT。最具讽刺意味的是，这些模型之所以能给出解答，恰恰是因为它们吸收了 Tailwind 的官方文档和社区讨论作为训练语料。

产品的使用量创下历史新高，营收却骤降至原来的五分之一。 这个数字最直观地揭示了开源生态中正在发生的残酷现实。

今年 1 月，中欧大学（CEU）经济学家米克洛什·科伦（Miklós Koren）的研究团队发表了一篇题为《氛围编码扼杀开源》（Vibe Coding Kills Open Source）的论文。⁵ 该研究将国际贸易模型引入开源生态，得出的结论异常明确。

研究团队利用 6 款编程大模型进行了对照实验，最终证实：虽然模型高频推荐的软件包下载量会大幅攀升，但这些活动根本无法转化为支撑维护者生计的用户参与度（Engagement）。 自动化机器人固然会执行安装，但它们不会提 Issue，不会阅读官方文档，更不会向维护者道一声谢。

论文给出了如下结论：“在开发者的收入完全依赖于用户直接参与度的传统商业模式下，开源生态系统根本无法承受 AI 的大规模普及与渗透。”

科伦对此评价道：

“站在开发者的立场，问题其实就在于：如果我做开源是为了在人群中获得认可与支持，那我凭什么要做一个只有机器在用的东西呢？”

同样的困局也正在 Stack Overflow 上演。在 ChatGPT 问世前，该平台每月新增提问超过 10 万条，而如今却锐减至不足 1,500 条。回答率也从原本的 80% 跌落到了近乎腰斩的水平。原本可供所有人检索、沉淀为公共财富的问答记录日益枯竭，取而代之的，是深锁在大科技公司服务器里的私密对话记录。

🔑 推动开源运转的不仅是代码，还有关注与声誉

我们一直将开源理解为“免费分享代码”。但实际上，这是一种交出代码、换回金钱之外的其他事物的机制。

• 表面——付出：代码 / 获得：（无，免费）
• 实际——付出：代码 / 获得：关注、声誉、Issue反馈、文档流量、职业发展

真正推动开源运转的正是第二行。看似无偿的劳动，实际上是用关注与声誉代替金钱获得了回报。贡献记录化作了简历上的一笔，文档访客是付费产品的潜在客户，GitHub上的Star数量有助于寻找下一份工作。

AI编程工具能够直接生成代码，却不会把原本给予维护者的关注一同传递过去。**相反，它将那份关注吸引到了工具自身身上。**过去用户给予维护者的关注，如今变成了每月100～200美元的订阅费，流向了开发这些工具的硅谷公司。

Svelte创始人理查德·哈里斯（Rich Harris）的话恰好切中了这一点。

“就在不久之前，为了获得使用软件的特权而实质上向硅谷公司支付租金的想法，还被认为是完全荒谬的。”

一位名叫米尔·莱德曼·乌克勒斯（Mierle Laderman Ukeles）的艺术家曾在1969年写下《维护艺术宣言》。她指出，与创造性劳动相比，维护性劳动总是被低估，社会给予了维护者“极其低下的地位”。她还提出了这样的质问：

“革命结束后，周一清晨的垃圾由谁来清理？”

这是57年前的疑问，如今却在GitHub的Issue追踪器里原封不动地重演。生成式AI是作为创造的工具被设计与营销的。您见过有哪款AI产品宣称“颠覆性地改善维护工作”吗？我从未见过。因为维护是一项没有任何捷径可走的工作。

那么我们的产品会怎样呢

FT 的一款应用就依赖了 2,000 多个开源软件包。读者朋友所在公司的产品大概也不会相差太远。这 2,000 多个包中，有相当一部分维系在单个维护者身上，而那个人眼下正被垃圾报告折磨得心力交瘁。

xkcd 的一幅知名漫画曾描绘过这种结构：一座写着“全部现代数字基础设施”的巨大积木塔，摇摇欲坠地架在某块“内布拉斯加州某人自 2003 年以来毫无报酬地默默维护着”的单薄积木之上。

在制定 GTM 战略并审查技术尽调资料时，我经常需要翻阅依赖项列表，但过去通常只确认一下“许可证是否合规”就略过了。我也曾如此。究竟是谁在维护它、那个人是否已精疲力竭，从未出现在尽调清单里。现在回想起来，那才是最大的漏洞。

以下是当下值得立刻排查的三件事：

• 排查巴士因子（bus factor）⁶：在我们产品的核心依赖项中，最近 12 个月内超过 80% 的提交都出自同一人的软件包有几个？在 GitHub Insights 里花 30 分钟就能查清楚。
• 确认赞助情况：在这些软件包中，我们实际出资资助过的有几个？大概率是 0 个。哪怕只是通过 GitHub Sponsors 或 Open Collective 每月资助几十美元，维护者离开的概率就会大不相同。
• 规范贡献策略：我们公司的工程师是否也在把 AI 生成的 PR 随意甩给外部开源项目？一旦制造垃圾内容的那一方贴上了我们公司的名字，对雇主品牌也是一种伤害。

Oswarld视角

坦白说，我很警惕将这个问题简单归结为“AI是坏的”。

就连斯滕贝格（Stenberg）本人也不反对 AI 工具。他曾公开称赞过一位利用 AI 辅助工具发现大量真实问题的开发者。他所表达的核心是：

“通常来说，写出第一批代码在任何项目中从来都不是难事。项目的挑战在于日复一日地维护它、修复 Bug。（AI）在修复问题方面并没有那么出色，它更擅长的是发现问题。”

审视这种结构，我的看法是：这并非技术问题，而是结算结构的问题。

在近 20 年制定 GTM 战略的过程中，我反复看到一个规律：在市场上真正崩溃的从来不是产品本身，而是价值创造之处与资金收取之处脱节的商业模式。Tailwind 在代码中创造价值，却依靠文档流量来变现。AI 只不过切断了连接二者的搜索引流路径而已。问题本就在于，当初连接这两个节点的通道仅仅只有文档访问这一条。

因此，与其说“开源正在走向灭亡”，我更倾向于认为“开源的结算方式正在被强制重构”。而这次重构所需的成本，最终将由所有销售软件的公司——也就是我们所有人——共同承担。眼下，维护者们正在用个人的时间和精力替大家硬扛这笔代价。一旦他们再也撑不下去，我们每天所依赖的软件包将不再有人来修补漏洞。

软件自由保护组织（Software Freedom Conservancy）的卡伦·桑德勒（Karen Sandler）所说的一句话让我记忆犹新。她说，这些工具拥有“让每个人都能亲手修补自己所依赖的软件的潜力”。我也相信这种可能性。然而，这种未来绝不会凭空降临，唯有在懂得如何修补的人依然存在的前提下，它才有可能实现。

结语

总结如下：

• **接受外部贡献的通道被堵死了。**cURL 叫停了漏洞赏金计划，tldraw 关闭了外部贡献通道。AI 垃圾（AI slop）的审查成本全由维护者个人独自承担。
• **资金进账的路径断裂了。**Tailwind 的月下载量达到 7,500 万次，收入却锐减了约 80%。维护者此前获得的报酬，与其说是金钱，不如说是文档访问量和 Issue 提交等关注度，而如今这些关注度全部流向了 AI 工具。
• **代价最终会反噬到我们身上。**我们产品所依赖的数千个开源包的维护者，正一个接一个因心力交瘁而离开。建议大家今天至少确认两件事：巴士因子以及是否有赞助支持。

创造比破坏更难，而维持又比创造更难。我们通常在东西彻底损坏之前很难意识到维护的存在，往往只有当维护者离开之后，才会发觉那个人曾一直在那里。

💬 在读者您所在公司的产品所依赖的开源项目中，您是否知道有哪些包实质上只有一名维护者？或者相反，如果您曾有过将 AI 工具生成的 PR 提交给外部项目的经历，对方又是怎样的反应？欢迎在评论区分享，我们会将其作为下一期的素材探讨。

---

💬 欢迎在评论区留言分享您对上述问题的经历 · 📨 如果您身边有正在为依赖项管理而烦恼的同事，请将本文分享给他们

---

参考资料与延伸阅读

核心来源

• Koren, M., Békés, G., & Hinz, J., “Vibe Coding Kills Open Source”, arXiv:2601.15494, 2026 年 1 月。：本文的经济学骨架。将国际贸易模型应用于开源的切入点尤为引人入胜。如果时间有限，单读结论部分也足够了。
• Daniel Stenberg, “The end of the curl bug-bounty program”, 2026 年 1 月。：维护者本人的心声。比起数字，字里行间的疲惫感诉说了更多。
• Steve Ruiz, “Stay away from my trash!”, tldraw blog, 2026 年 1 月 17 日。：“如果写代码是容易的部分，为什么还要别人代劳呢？”这一发问是整篇文章的起点。
• DevClass, “Tailwind Labs lays off 75 percent of its engineers thanks to ‘brutal impact’ of AI”, 2026 年 1 月 8 日。：开源商业模式崩溃的最具体案例。

背景知识

• Mierle Laderman Ukeles, “Manifesto for Maintenance Art 1969!”, 1969。：探讨维护劳动的贬值问题的经典文献。虽非关于软件，读来却宛如在谈软件。
• xkcd, “Dependency”, xkcd #2347。：用一张漫画概括了本文的全部内容。

作者 安光涉（Oswarld） 现任世宗大学兼任教授，INLEVEL9 战略顾问。职业经历、研究、著作与近期活动会持续更新在作者简介。 最新动态 · 2026年7月：HEMA-2: A Consolidation-Aware Tri-Memory Architecture with Multi-Channel Scheduling for Lifelong Conversational AI。

📝 术语说明

注释

1. State of CSS：每年面向全球 Web 开发者开展的 CSS 工具使用现状调查。在业界被视作采纳率的事实标准指标。 ↩

2. 漏洞赏金（Bug Bounty）：指外部开发者发现并报告软件的安全漏洞即可获得赏金的机制。这一机制旨在捕获仅靠内部人员难以发现的缺陷，但由于附带赏金，也招致了大量博取赏金的钓鱼式报告。 ↩

3. AI 废料（AI slop）：指 AI 大量生成的看似煞有介事却空洞无物的内容。在代码领域，指“形式无可挑剔，语境却全盘皆错”的问题报告或代码提议。 ↩

4. 拉取请求（Pull Request，PR）：向开源项目提交“请这样修改代码”提议的流程。必须由项目受信任的管理者审查并批准后，才会合入实际代码。提交只要几秒，审查却要数小时，这正是当下问题的核心。 ↩

5. 氛围编码（Vibe Coding）：比起亲自阅读与编写代码，更倾向于通过自然语言下达指令、直接采用 AI 生成成果的开发方式。虽然速度快，但若缺乏验证产出物的能力，一旦出现问题便会束手无策。 ↩

6. 巴士因子（Bus Factor）：衡量“有多少核心成员被巴士撞倒就会导致项目停摆”的指标。巴士因子为 1，意味着整个项目的命运完全系于一人之身。 ↩