Tailwind为何裁掉了3名开发者

开篇

订阅者朋友，今年1月有一则悄悄溜过的新闻。

打造CSS框架Tailwind的公司，裁掉了4名工程师中的3名。同一时期，Tailwind的月下载量达到7,500万次，根据2025年State of CSS¹调查，开发者采用率为51%，成为史上使用最广泛的CSS框架。产品达到了巅峰，公司却把人力砍到了四分之一。

创始人Adam Wathan公开的数字是这样的：官方文档网站流量较2023年下降约40%，营收下降约80%。

这不是一个产品失败的故事。**这是一个产品赢了，但商业模式赖以立足的地面却消失了的故事。**而这块地面并非只属于Tailwind，它是订阅者朋友公司产品所依托的整个软件供应链共同站立的地面。

🚰 管道堵住了

先从技术层面正在发生的事情说起。

如果此刻正在阅读这篇文章，说明订阅者朋友刚刚用过一款名为cURL的软件。即便没有打开浏览器，只要今天摸过智能手机、笔记本电脑、电视、汽车中的任何一样，也同样用过它。cURL的核心组件libcurl，估计已被安装超过200亿次。就像我们打开水龙头时不会想到水泵一样，我们每天使用它却并不意识到它的存在。

cURL是1996年首次发布的开源项目，由瑞典开发者Daniel Stenberg（55岁）创建，至今仍由他全职维护。贡献者名单超过3,000人，但全职人员只有他一个。

“很长一段时间里，我是cURL唯一的全职人力。其余全是志愿者，来来去去。明天还会有谁留下来，我不知道。”（Daniel Stenberg）

Eric S. Raymond把这类人称为“承重的互联网人（load-bearing internet people）”——他们承担着建筑的重量，却没有人会去看一眼那面墙。

然而今年1月，Stenberg终止了他运营了6年的漏洞悬赏²计划。这个计划在6年间发放了8万6,000美元（约合1亿2千万韩元）的赏金，修复了78个真实漏洞。终止的原因只有一个：AI垃圾内容（AI slop）³的暴增。

Stenberg表示，在6年间收到的AI生成的举报中，没有一份找出过真正的漏洞。取而代之的是大量看似煞有介事的假报告，附带引用不存在函数的GDB会话日志和寄存器转储。

他这样写道：

“无穷无尽的垃圾举报要处理，要付出严重的精神代价，反驳它们也要花很长时间。这完全是被浪费掉的时间和精力。而且它还在侵蚀我们活下去的意志。”

同月，数字白板工具tldraw的创始人Steve Ruiz开始自动关闭外部贡献者提交的拉取请求⁴。他并不反对用AI写代码——他自己也用，也鼓励团队使用。问题出在别处。

“如果写代码是简单的那部分，我为什么要指望别人替我写代码呢？”（Steve Ruiz）

AI生成的贡献在形式上没问题，却常常忽略上下文，误解代码库，最重要的是，**作者不会参与后续的讨论。**过去，新贡献者在学习项目的过程中，有朝一日会成长为受信任的维护者。而现在，只需把工具对准项目就够了，即便接受了贡献，这个人也没有理由去真正了解这个项目。

审查成本没有变化，但贡献的生产成本却趋近于零。今年3月发表的一篇论文将这一现象定性为“公地悲剧”，意思是个人生产力的提升，其成本被转嫁给了审阅者、维护者以及整个社区。

💰 货币消失了

现在来看经济层面。这里我们再回到Tailwind。

Tailwind的商业结构曾是这样一个闭环：开发者搜索“如何让div居中”→到达官方文档→看到文档旁附带的付费产品（Tailwind UI）广告→购买。文档流量本身就是营收漏斗。

LLM把这条链条中的第二环整个删除了。现在开发者不再来文档，而是直接去问Claude或ChatGPT。讽刺的是，这些模型之所以能够回答，正是因为它们是用Tailwind的文档和社区讨论训练出来的。

**产品使用量史上最高，营收却只剩五分之一。**这正是当下开源生态所发生之事最鲜明的一个切面。

今年1月，中欧大学（CEU）经济学家Miklós Koren的研究团队发表了一篇题为《Vibe Coding Kills Open Source》的论文⁵。这项研究将国际贸易模型应用于开源领域，结论十分尖锐。

研究团队用6个编程模型做实验，确认了模型经常推荐的软件包，下载量会大幅增长，但这种活动完全没有转化为维系维护者生计的互动。机器人会安装，却不留issue，不读文档，也不会道谢。

论文的结论是这样的：“在开发者收益完全依赖直接用户互动的传统商业模式下，开源生态无法承受AI的广泛采用。”

Koren这样说：

“对开发者而言，问题在于：如果我想在人群中获得知名度，那我为什么要去开发一个只有机器在用的东西？”

Stack Overflow的崩塌是同样的结构。在ChatGPT发布前夕，每月还有超过10万个问题，如今不到1,500个。回答率也从80%跌到了大约一半的水平。曾经的公共广场消失了，取而代之的是被大型科技公司据为己有的私人对话记录。

🔑 交汇点：开源真正的通货从来不是代码

这是本文的核心所在。

我们一直把开源理解为“免费分发代码”。但事实上，开源是一个由两种货币运转的系统。

• 表面上——付出：代码 / 得到：（无，免费）
• 实际上——付出：代码 / 得到：关注、声誉、issue报告、文档流量、职业发展

第二行才是真正的资产负债表。看似无偿的劳动，实际上一直是**用“关注”这种货币来结算的。**贡献记录是简历上的一行，文档访问者是付费产品的潜在客户，GitHub星标就是下一份工作。

AI编程工具完美地复制了代码，但**没能复制“关注”，反而把它吸走了。**用户曾经支付给维护者的关注，如今变成了每月100至200美元的订阅费，流向了硅谷。

Rich Harris（Svelte创始人）的一句话精准点出了这一点：

“直到不久前，为了拥有使用软件的特权，而实质上向硅谷公司缴纳租金——这种想法还被视为完全荒谬的事情。”

艺术家Mierle Laderman Ukeles在1969年写下了《维护艺术宣言》。她指出，维护劳动相较于创造劳动总是被低估，社会赋予维护者“低下的地位”。她这样发问：

“革命结束之后，周一早上谁来收拾垃圾？”

这是57年前的提问，如今却在GitHub的issue追踪器上原样重演。生成式AI被设计和营销为创造的工具。订阅者朋友见过哪款AI产品宣传自己“显著改善了维护工作”吗？我没见过。因为维护是一件没有捷径可走的事。

那么我们的产品会怎样

到这里，这个故事就与你我息息相关了。

FT旗下的某款应用，构建在2,000多个开源软件包之上。订阅者朋友公司的产品，情况也不会有太大不同。这2,000多个软件包中，相当一部分正悬于一位维护者一人之手，而这个人此刻正被垃圾报告拖得筋疲力尽。

xkcd有一幅著名漫画描绘了这种结构：一座标着“所有现代数字基础设施”的巨大方块塔，压在一块标着“内布拉斯加州某人自2003年以来无偿维护”的细薄方块之上。

在制定GTM策略的过程中，我翻看过不少技术尽职调查资料，其中的依赖清单通常只确认“许可证是否干净”就算过关了。我自己也是如此。谁在维护这个软件包、这个人是否正在筋疲力尽，从来不在尽职调查项目之列。现在回头看，那才是最大的漏洞。

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

• 确认巴士系数⁶：我们产品的核心依赖中，过去12个月内80%以上的提交都出自一人之手的软件包，有多少个？在GitHub Insights上花30分钟就能查清。
• 确认赞助情况：这些软件包中，我们真正在付费的有几个？大多数会是零。仅仅通过GitHub Sponsors或Open Collective每月捐出几十美元，就能改变维护者离开的概率。
• 完善贡献政策：我们的工程师是否在把AI生成的PR投向外部开源项目？一旦我们公司的名字与制造垃圾内容绑在一起，招聘品牌形象也会受损。

Oswarld视角

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

就连Stenberg本人也不反对AI工具本身。他曾公开表扬过一位借助AI辅助工具发现了大量真实issue的开发者。他所说的核心在于：

“一般来说，最初写代码从来都不是任何项目的难题。项目的挑战在于随着时间推移去维护它、修复bug。（AI）在修复问题方面并不那么擅长，在发现问题方面要出色得多。”

我看着这个结构，脑中浮现的想法是：这不是技术问题，而是结算结构的问题。

在近20年制定GTM策略的过程中，我反复看到一个模式：市场上真正崩塌的从来不是产品，而是价值产生的地点与金钱被收取的地点发生错位的商业模式。Tailwind在代码中创造价值，却在文档流量上收钱。连接这两点的那座桥，只是被AI斩断了而已。问题在于，那座桥原本就那么细。

所以比起说“开源正在死去”，我更倾向于认为“开源的结算方式正在被迫重新设计”。而这场重新设计的账单，最终会寄到所有销售软件的公司手上，也就是我们自己头上。眼下，维护者们正在用个人的体力去吸收这笔成本。等他们的体力耗尽的那一天，就算打开水龙头，也不会再有水流出来了。

Karen Sandler（Software Freedom Conservancy）的一句话让我久久难忘。她说这些工具具有“让任何人都能亲自修复自己所依赖软件”的潜力。我也相信这种可能性。只不过它不会自己到来，**只有当懂得如何修复的人还留在原地，**这样的未来才可能实现。

结语

总结一下：

• **管道堵住了。**cURL关闭了漏洞悬赏计划，tldraw关闭了外部贡献通道。AI垃圾内容的审查成本，正由维护者个人独自扛下。
• **货币消失了。**Tailwind下载量7,500万，营收却下滑80%。开源真正被结算的通货不是代码，而是“关注”，而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。：这幅漫画用一张图概括了本文的全部内容。

作者安光涉是世宗大学经营学教授，也是 OBF（Oswarld Boutique Consulting Firm）首席顾问。他在大学教授经营数据管理、商业分析等统计与数据分析课程，同时在产业现场负责 GTM 与人工智能战略咨询，设计技术与商业的连接方式。他曾发表关于 AI 对话系统记忆架构（HEMA）的学术论文，并运营每日策展全球 AI 论文的 Daily Arxiv 项目。他毕业于高丽大学技术经营专业研究生院与 KMBA，著有《把思考交出去的人：Homo Brainless》。

📝 术语说明

注释

1. State of CSS：一项每年针对全球网页开发者进行的CSS工具使用情况调查，在业内被视为采用率的事实标准指标。 ↩

2. 漏洞悬赏（Bug Bounty）：一种制度，外部开发者若发现并报告软件的安全漏洞，即可获得奖金。这是为了捕捉仅靠内部人力无法发现的缺陷而设立的机制，但由于设有奖金，也因此招来了大量钓鱼式的虚假举报。 ↩

3. AI垃圾内容（AI slop）：指AI大量生成的、看似煞有介事却毫无实质内容的产物。在代码领域，指的是“形式完美但语境错误”的举报或代码建议。 ↩

4. 拉取请求（Pull Request，PR）：向开源项目提交“请这样修改代码”的建议流程。需要经过项目受信任的管理者审阅并批准，才能真正合并进代码库。提交建议只需几秒钟，审阅却要花上几个小时——这正是当下问题的核心所在。 ↩

5. 氛围编程（Vibe Coding）：一种开发方式，不直接阅读和编写代码，而是用自然语言下达指令，直接使用AI生成的结果。速度快，但如果不具备验证结果的能力，一旦出问题就无从下手。 ↩

6. 巴士系数（Bus Factor）：衡量“需要多少人被巴士撞到，这个项目才会停摆”的指标。巴士系数为1，意味着整个项目全部悬于一人之手。 ↩