Atlassian CEO 反駁 SaaS 末日論：市場搞混了三種完全不同的公司

本文整理自 a16z Podcast（The a16z Show）2026 年 3 月播出的單集。

{{< youtube 0lzo2tFBFy8 >}}

{{< spotify "episode/55srQBzdKlsma2eWaUCJOb" >}}

{{< apple-podcast "tw/podcast/atlassian-ceo-on-the-saas-apocalypse-ai-agents-what/id842818711?i=1000753665013" >}}

---

2026 年初，軟體產業經歷了一場血洗。從一月中旬到二月中旬，短短一個月內，全球軟體板塊蒸發了約兩兆美元的市值。這場被媒體稱為「SaaSpocalypse」的恐慌，核心邏輯很簡單：如果 AI agent 能做十個業務員的工作，企業只需要十個 Salesforce 帳號而不是一百個，那按人頭收費的 SaaS 公司不就完蛋了？Atlassian 兩位創辦人的個人財富在這波下跌中縮水了 72 億美元。但 Atlassian 執行長 Mike Cannon-Brookes 顯然不同意這個敘事。

他登上 a16z Podcast，與 a16z 合夥人 Alex Rampell 進行了一場近一小時的深度對談。Rampell 不是一般的投資人，他是 Affirm 的共同創辦人、連續創業者，在 a16z 領導規模十億美元的應用投資，曾提出科技圈廣為流傳的「Distribution vs. Innovation」框架。這兩個人的對話，提出了幾個在 SaaS 末日論的喧囂中被嚴重忽略的觀點。而讓這場對談更耐人尋味的是：播出五天後，Cannon-Brookes 就宣布裁掉 Atlassian 10% 的員工。

三種 SaaS，三種命運

Rampell 在節目中提出了一個分析框架，直指 SaaS 末日論的根本問題：公開市場根本分不清三種本質上完全不同的 SaaS 公司，卻用同一把標尺把它們全部打趴。

第一種是「席位綁定工作產出」的公司，Zendesk 是最典型的例子。客服人員一人一個帳號，每個帳號對應實際的客服工作量。當 AI agent 能直接處理客服請求，企業需要的客服人員變少了，帳號數也跟著歸零。這類公司面臨的是真實的、結構性的威脅，除非它們能徹底轉型定價模式，否則營收基礎會被 AI 從根部挖空。

第二種是「席位做為定價代理」的公司，Workday 是代表。企業按員工人數付費，但員工並不是天天登入 Workday 產出什麼東西。按人頭收費只是一種公平的計價機制，跟實際產出無關。AI 不會減少企業的員工總數（至少短期內不會），反而會在 Workday 上增加新功能，像是用 AI 分析薪資結構、預測離職風險。這類公司的 AI 故事其實是正面的。

第三種是混合型，Adobe 和 Salesforce 都屬於這類。Rampell 的分析特別精準：Salesforce 的「前端」，也就是業務員每天使用的介面，確實可能因為 AI agent 減少使用者數量。但 Salesforce 的「後端」，那個記錄所有客戶關係、交易歷史的系統紀錄，仍然不可或缺。即便你的 AI agent 透過 MCP 伺服器串接 Salesforce，你還是需要 Salesforce 帳號和流程治理。Adobe 也類似：Creative Cloud 的使用者可能會因為 AI 生成工具而減少，但 Acrobat 和企業文件管理的需求不會消失。

問題在於，公開市場的投資人看不到這些區別。他們看到的是「AI 會取代軟體」這個籠統敘事，然後把所有 SaaS 股票一起砍。這就像因為電動車會取代油車，就把所有跟「車」沾上邊的公司一起拋售，不管它是做輪胎的、做 GPS 的、還是做加油站的。

Vibe coding 取代企業軟體？「這想法很恐怖」

SaaS 末日論的另一個核心假設是：隨著 vibe coding 興起，企業可以直接用 AI 生成自己的軟體，不再需要買現成的 SaaS 產品。Cannon-Brookes 對這個想法的回應非常直白：「我自己用 vibe coding 寫一套 Workday 然後拿來用，光想就覺得恐怖。」

Rampell 用經濟學大師大衛．李嘉圖（David Ricardo）1817 年提出的比較優勢理論來解釋這件事。即便你理論上「可以」自己寫一套 HR 系統，你也不應該這樣做，因為你在自己的核心業務上有比較優勢。一家製造業公司的比較優勢在製造，不在寫 HR 軟體。把工程資源拿去寫一套功能遠不如 Workday 的半成品，是經濟學上的非理性行為。

但更深層的理由不在經濟學，而在知識積累。Rampell 指出，大量的企業軟體其實就是一堆確定性規則，而這些規則是幾十年來從真實業務運作中一點一點學來的。印第安納州的產假規定跟加州不一樣，某些稅務減免只適用於特定產業的特定規模企業，合規要求會隨著每次法規更新而改變。這些邊緣案例（edge cases）沒有發表在任何地方，你不可能透過 prompting 就複製出來。它們是在系統上線後，被真實使用者用真實業務流程撞出來的。

Cannon-Brookes 進一步把企業重新定義為「流程的集合」而非「系統紀錄」。他區分了兩類流程：一種是「輸入受限」的流程，像客服和法務，工作量基本固定，AI 的價值在於提升效率、降低成本。另一種是「輸出受限」的流程，像工程和行銷，潛在產出幾乎無上限，AI 的價值在於增加創意產出。這個區分很重要，因為它決定了 AI 對不同企業功能的影響方向完全不同：前者是省錢，後者是賺更多。

那 vibe coding 的真正價值是什麼？Cannon-Brookes 認為是「延展性」（extensibility）。不是用 AI 取代 Workday，而是在 Workday 上面用 AI 快速開發客製化的小工具。比如說，邁阿密辦公室有一套獨特的 HR 政策，過去需要找開發團隊客製化，現在可以用 vibe coding 快速搭建一個連接 Workday 的小應用。這不但不會讓 Workday 過時，反而讓平台更黏，因為上面的客製化應用越多，遷移成本就越高。

定價的公平性陷阱：為什麼按人頭收費不會消失

如果 AI 讓每個帳號能做更多事，SaaS 公司為什麼不乾脆改成按使用量或按成果收費？Rampell 用行為經濟學家丹．艾瑞利（Dan Ariely）在《誰說人是理性的》（Predictably Irrational）中的鎖匠寓言來回答這個問題。

故事是這樣的：一個新手鎖匠花了九個小時幫你開鎖，手忙腳亂，把鎖都弄壞了，你付了兩百美元覺得合理。同一個鎖匠經過多年訓練，現在九十秒就開好了，鎖完好無損，你卻覺得兩百美元太貴。人的心理就是這樣：我們根據「看起來投入了多少努力」來判斷價值，而不是根據實際產出。按人頭收費之所以持久，正是因為它讓人感覺「公平」，你有一百個員工就付一百份的錢，很直覺，可以預期，兩邊都好控制。

消費型定價（consumption-based pricing）的問題在於 AI credits 跟過去的雲端用量單位完全不同。一個 gigabyte 就是一個 gigabyte，你可以在不同供應商之間比較。但一個 AI credit 是什麼？每家供應商的定義不同，而且供應商可以在你沒要求的情況下突然增加新功能，一夜之間讓你的 credit 消耗量暴增十倍。客戶無法預測、無法控制、無法比較，這讓財務長們抓狂。

結果導向定價（outcome-based pricing）聽起來最理想，但 Cannon-Brookes 一語道破它的致命缺陷：第二年問題。假設一套 AI 工具第一年幫你省了十萬美元，按成果分潤收了三萬。到了第二年，你的成本基線已經降低了十萬，所以這套工具需要在新的基線上再找出額外的節省空間才能收到同樣的錢。每過一年，供應商的價值基線都在侵蝕，而客戶會理所當然地認為「去年省下來的是我的，今年你得省更多」。這個結構性矛盾讓結果導向定價在長期幾乎無法維持。

所以，儘管按人頭收費看起來「不夠 AI 時代」，它很可能會繼續存在。因為在所有定價模式中，它是唯一讓買賣雙方都能預測、都覺得公平的選擇。

給人一個無限能力的聊天框，他們說：講個爸爸笑話

如果 SaaS 不會死，那 AI 的價值瓶頸到底在哪？Cannon-Brookes 的回答出乎很多人意料：不是模型能力，是設計。

他的觀察是，目前的 AI 模型能力遠遠超過它們實際交付的價值。這個能力差距不是因為技術不夠好，而是因為沒有人知道怎麼把這些能力包裝成普通人真的會用的東西。他用了一個一針見血的描述：「給人一個可以做任何事的聊天框，他們的反應是叫你講個爸爸笑話。」這不是使用者的問題，是介面的問題。一個空白的無限可能輸入框造成的不是賦能，而是癱瘓。

這個設計難題有三個層次。第一是信任迴圈（trust loop）：使用者害怕 AI 做出他們無法驗證的事情，但如果每一步都要人工確認，那 agent 的效率優勢就蕩然無存。多少個檢查點是對的？什麼時候該中斷使用者？什麼時候該靜靜地做完？這個「人機信任迴圈」的設計是一個根本性的 UX 問題，目前沒有標準答案。

第二是脈絡選擇（context selection）：當 AI 需要搜尋資料來回答問題，它應該搜整個網路？還是只搜公司內部文件？還是只搜你所在的團隊？現在很多 AI 產品用一堆開關讓使用者自己選，但多數使用者根本不知道怎麼選才對。太多選項反而是負擔。

第三是迭代介面的問題。Cannon-Brookes 觀察到，用聊天介面來修改 AI 生成的文件內容，體驗極度挫折。你跟 AI 說「第三段改短一點」，它可能把整篇文章重寫了。這種互動模式本質上是把舊的「游標編輯」思維硬套在新的 AI 協作情境上，完全是 skeuomorphic（擬物化設計）的。

Cannon-Brookes 用了一個精準的比喻來形容目前 AI agent 的狀態：「50 個實習生的問題。」擁有 50 個實習生聽起來很美好，產能大增。但實際情況是，50 個實習生每分鐘問你 50 個問題，你整天都在回答實習生的問題，自己什麼事都做不了。目前的 AI agent 就是這個狀態：潛在產出巨大，但人類管理和指揮它們的開銷更大。

Atlassian 怎麼做：三層並進的 AI 策略

Cannon-Brookes 透露了 Atlassian 內部的 AI 落地策略，分成三個同步推進的層次。

第一層是在現有流程中加入 AI 功能。聽起來不性感，但這是客戶最愛的。自動摘要 Jira ticket、在 Confluence 文件中生成重點整理、用 AI 加速已有的工作流程。這些功能不會重新定義任何東西，但它們立刻有用，使用者的採納率也最高。

第二層是在現有流程的瓶頸步驟導入 agent。找出每個工作流程中最卡人的那個環節，讓 AI agent 接手。Atlassian 在 2026 年 2 月底正式開放了「Agents in Jira」的公測版本，團隊可以直接在 Jira 中把工作指派給 Rovo（Atlassian 的 AI agent 品牌）或第三方 agent，在留言串中跟 agent 互動、把 agent 嵌入工作流程。這不是實驗性功能，是已經有 500 萬月活用戶的 Rovo 平台在生產環境中的正式應用。

第三層才是最困難也最具想像力的：徹底重新想像工作流程。如果客服工單這個概念本身就不需要存在呢？如果文件不是從空白頁開始寫，而是從一個 prompt 開始生成呢？Atlassian 的 Create with Rovo 就在做這件事。它提供了一個雙面板介面，左邊是正在生成的文件，右邊是跟 AI 對話的聊天視窗，使用者可以在兩者之間來回切換、迭代。Cannon-Brookes 坦承，重度使用者很愛這個模式，但一般使用者還在適應這個全新的互動典範。他把這比作早期的智慧型手機或 Excel：新的互動模式需要好幾年才會變成主流。

支撐這三層策略的基礎是 Atlassian 的「Teamwork Graph」，一個統一的組織記憶層，追蹤超過一千億個物件和它們之間的關聯，涵蓋知識庫、目標、工作項目和團隊結構。這讓 Rovo 的搜尋和推薦能夠跨越所有 Atlassian 產品，提供有脈絡的 AI 回應，而不是無腦地搜尋全網。

Cannon-Brookes 也預期，未來多數企業內部會同時運行三到五個大型 agent 平台。客戶會想要把自己選擇的 agent（不管是 Salesforce 的 AgentForce、Google 的 Gemini、還是其他的）帶進現有的工作流程中，而不是被迫只用一家。這意味著 SaaS 平台的競爭不再只是功能，而是誰能提供最好的 agent 互通生態。

我的觀察：說歸說，裁員歸裁員

這集 Podcast 在 3 月 6 日播出。五天後的 3 月 11 日，Cannon-Brookes 宣布裁掉 1,600 名員工，約佔 Atlassian 總人力的 10%，同時技術長 Rajeev Rajan 也將在月底離職。官方理由是「自籌資金投資 AI 與企業銷售」，預計將產生 2.25 至 2.36 億美元的重組費用。

乍看之下，這跟他在 Podcast 中的樂觀論調矛盾。但如果仔細想，其實完全一致。Cannon-Brookes 的核心論點不是「什麼都不會改變」，而是「改變的方向跟市場以為的不一樣」。SaaS 不會死，但 SaaS 公司必須大幅重新配置資源。裁掉 10% 的人力，把省下來的錢砸進 AI 和企業級銷售，這正是他在節目中描述的「三層並進」策略在現實中的樣子。

更值得注意的是 Atlassian 在同一時期的另一個動作：以 6.1 億美元收購 The Browser Company，也就是 Arc 和 Dia 瀏覽器的開發團隊。一家做專案管理和協作工具的公司為什麼要買一家做瀏覽器的？如果你回想 Cannon-Brookes 在節目中反覆強調的「設計是最大瓶頸」，這筆收購就說得通了。The Browser Company 在瀏覽器 UX 創新上的功力在業界有目共睹，而 Atlassian 最缺的，恰恰是把強大 AI 能力轉化為直覺介面的設計能量。

把這些拼在一起看，Cannon-Brookes 的邏輯其實自洽：SaaS 不會死，但 SaaS 公司必須徹底重組來迎接 AI。裁人、買設計團隊、開放 agent 生態、用 Teamwork Graph 建資料護城河，每一步都指向同一個方向。Atlassian 沒有在恐慌中隨波逐流，它在用真金白銀重新定義遊戲規則。至於公開市場什麼時候能分辨三種 SaaS 的不同命運，那是另一個問題了。