Tailwind 裁員三名開發者的原因 · 第 188 期

前言

訂閱者，今年一月有一則新聞悄悄溜過去了。

打造 CSS 框架 Tailwind 的公司，裁掉了四名工程師中的三名。同一時期，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）」。就是那面承載著建築重量、卻無人注目的牆。

然而今年一月，Stenberg 終止了運作六年的漏洞賞金²計畫。這六年間共支付了 86,000 美元（約 1.2 億韓元），修復了 78 個真實漏洞。終止原因只有一個：AI 垃圾內容（AI slop）³的氾濫。

Stenberg 表示，六年間 AI 生成的舉報中，沒有一件找到了真正的漏洞。取而代之的是大量看似可信的假報告，附帶引用了根本不存在的函數的 GDB 會話日誌和暫存器傾轉。

他這樣寫道：

「無止境的垃圾舉報讓管理它付出沉重的精神代價，反駁它也需要漫長的時間。完全是被浪費的時間和精力。它甚至侵蝕了我們想要繼續生活的意志。」

同一個月，數位白板工具 tldraw 的創辦人 Steve Ruiz 開始自動關閉外部貢獻者的 Pull Request⁴。他並不反對用 AI 寫程式。他自己也用，也建議團隊用。問題在別處。

「如果寫程式是簡單的那部分，我為什麼還需要別人幫我寫？」（Steve Ruiz）

AI 產出的貢獻在形式上正確，但缺乏脈絡、誤解了程式碼庫，最重要的是作者不會參與後續對話。 以前，新貢獻者會邊學邊做，最終成為受信任的管理員。現在只要把工具對準專案就行，即使收到了貢獻，那個人也沒有理由去了解這個專案。

審查成本沒變，只是貢獻的生產成本趨近於零。去年三月發表的一篇論文將此現象定義為「公地悲劇」。意思是，個人生產力的提升被轉嫁為審查者、維護者和整個社群的成本。

💰 貨幣消失了

現在說經濟端。這裡我們回到 Tailwind。

Tailwind 的商業結構是這樣的鏈條：開發者搜尋「div 置中的方法」→ 到達官方文件 → 看到文件旁邊的付費產品（Tailwind UI）廣告 → 購買。文件流量就是營收漏斗。

LLM 把這條鏈的第二個環節整個刪掉了。現在開發者不再去文件，而是問 Claude 或 ChatGPT。諷刺的是，這些模型能回答的原因，正是它們用 Tailwind 的文件和社群討論訓練過這一點。

產品使用量創歷史新高，營收只剩五分之一。 這就是目前開源生態系中正在發生的事最鮮明的切面。

今年一月，中央歐洲大學（CEU）經濟學家 Miklós Koren 的研究團隊發表了《Vibe Coding Kills Open Source》論文。⁵ 這是一項將國際貿易模型應用於開源的研究，結論非常銳利。

研究團隊用六個編碼模型做實驗，發現模型經常推薦的套件下載量大幅增加，但這些活動完全沒有轉化為能養活維護者的互動參與。機器人會安裝，但不留 issue、不讀文件、也不說謝謝。

論文的結論是：「在開發者收入完全依賴直接使用者互動的傳統商業模式下，開源生態系無法承受大規模的 AI 採用。」

Koren 這樣說：

「從開發者的角度，問題是這樣的：如果我想在人群中獲得關注，為什麼要只為機器打造？」

Stack Overflow 的崩潰也是同樣的結構。ChatGPT 發布前每月超過 10 萬個的問題，現在不到 1,500 個。回應率也從 80% 跌到了一半左右。取代公開廣場的，是大型科技公司擁有的私人對話日誌。

🔑 交叉點：開源真正的貨幣不是程式碼

這裡是這篇文章的核心。

我們一直把開源理解為「免費分享程式碼」。但事實上，開源是一個由兩種貨幣運轉的系統。

表面 — 付出：程式碼 / 獲得：（無，免費）
實際 — 付出：程式碼 / 獲得：關注、聲譽、issue 報告、文件流量、職涯

第二行才是真正的資產負債表。看似免費的勞動，其實是用關注這種貨幣在結算。 貢獻經歷是履歷上的一行，文件訪問者是付費產品的潛在客戶，GitHub star 是下一份工作。

AI 編碼工具完美複製了程式碼。但關注無法被複製，反而被吸收了。 使用者原本付給維護者的關注，現在變成了每月 100 到 200 美元的訂閱費，流向矽谷。

Rich Harris（Svelte 創辦人）的話精準地點出了這一點。

「直到非常近期，為了使用軟體的特權而向矽谷公司實質上支付租金這個想法，還被認為完全荒謬。」

藝術家 Mierle Laderman Ukeles 在 1969 年寫了《維護藝術宣言》。她指出維護勞動相對於創造勞動始終被低估，社會給予維護者「可憐的地位」。她這樣問：

「革命結束後，週一早上垃圾誰來清？」

這是 57 年前的問題，現在就在 GitHub issue 追蹤器中原封不動地上演著。生成式 AI 是作為創造工具被設計和行銷的。宣稱「徹底改善維護」的 AI 產品，訂閱者有沒有見過？我沒有。維護沒有捷徑可走。

那我們的產品呢

到這裡，這件事就不再是別人的事了。

FT 的一個應用程式就建立在超過 2,000 個開源套件之上。訂閱者公司的產品大概也差不多。其中相當一部分依賴單一維護者，而那個人現在正被垃圾報告折磨得筋疲力盡。

xkcd 一幅著名的漫畫畫出了這個結構。一座標註著「所有現代數位基礎設施」的巨大積木塔，疊在一塊寫著「內布拉斯加州某個人從 2003 年開始無償維護」的薄積木上。

在制定 GTM 策略時，我經常翻閱技術盡調資料，依賴清單通常只確認「授權是否乾淨」就過去了。我也是。誰在維護它、那個人是否正在耗盡，從來不在盡調項目裡。現在回頭看，那才是最大的漏洞。

有三件事可以立即檢查。

巴士因子（bus factor）⁶檢查：我們產品的核心依賴中，最近 12 個月 commit 80% 以上來自同一個人的套件有幾個？在 GitHub Insights 上 30 分鐘就能確認。
贊助情況確認：這些套件中，我們實際在付費的有幾個？大概都是 0。透過 GitHub Sponsors 或 Open Collective 每月寄幾十美元，就能改變維護者離職的機率。
貢獻政策整頓：我們的工程師有沒有把 AI 生成的 PR 丟到外部開源專案？一旦我們公司名字出現在生產垃圾的那一方，招聘品牌也會受損。

Oswald 的視角

老實說，我警惕這個問題被簡化為「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. ：用一幅圖總結了這篇文章的所有內容。

作者 安光涉（Oswarld） 現任世宗大學兼任教授，INLEVEL9 策略顧問。職涯經歷、研究、著作與近期活動會持續更新在作者介紹。最新動態 · 2026年7月：HEMA-2: A Consolidation-Aware Tri-Memory Architecture with Multi-Channel Scheduling for Lifelong Conversational AI。

📝 術語說明

각주

State of CSS：每年針對全球網頁開發者進行的 CSS 工具使用現狀調查。在業界被視為採用率的實質標準指標。 ↩
漏洞賞金（Bug Bounty）：外部開發者找到軟體安全漏洞並舉報後獲得賞金的制度。是為了捕捉內部人力無法發現的缺陷而設的機制，但因為有賞金，釣魚式舉報也會跟著湧來。 ↩
AI 垃圾內容（AI slop）：指 AI 大量產出的、看似可信但缺乏實質的內容。在程式碼領域，指「形式完美但脈絡錯誤」的舉報或程式碼建議。 ↩
Pull Request（PR）：向開源專案提交「請這樣修改程式碼」提案的流程。需要專案受信任的管理員審查並核准後，才會實際反映到程式碼中。提案只需幾秒，審查卻要幾小時——這就是目前問題的核心。 ↩
Vibe Coding（氛圍編碼）：不直接讀寫程式碼，而是用自然語言下指令、直接使用 AI 產出結果的開發方式。速度快，但如果沒有驗證結果的能力，出了問題就無從下手。 ↩
巴士因子（Bus Factor）：衡量「幾個人被巴士撞了這個專案就會停擺」的指標。巴士因子為 1 意味著整個專案繫於一人。 ↩