許多 SaaS 產品現在面臨的競爭，早已不是來自其他 SaaS 產品，而是來自可組合的開源 AI 技術棧。
開源 AI 已經發展到一個階段，許多公司不再需要為每一個狹隘的工作流程都單獨訂閱一個服務。取而代之的是，他們可以自行組裝一個靈活的技術棧，包含開源模型、編排層、資料庫、自動化工具，以及輕量化的使用者介面，來處理過去 SaaS 工具所負責的越來越多工作。
這不代表 SaaS 已死。
這意味著，預設的提問正在從：
「我們該買哪個工具？」
轉變為：
「我們該買這個工具，還是用開源 AI 自己組一個？」
這是一個重大的轉變。
而這個轉變之所以發生，是因為開源生態系不再只是研究實驗室、業餘愛好者或基礎設施龐大的工程團隊的專利。它正逐漸變得適用於新創公司、代理商、營運人員，以及那些想要擁有更多控制權、更低邊際成本、更少供應商依賴的技術團隊。
這篇文章將深入探討 開源 AI 技術棧 究竟是什麼、它為何開始取代部分 SaaS、哪些類別最易受到衝擊、現代的技術棧長什麼樣子、它的優勢與不足之處在哪裡，以及如何在讓公司不至於陷入無止境的維護泥沼的前提下，思考如何採納它。
當人們說「開源 AI 正在取代 SaaS」，他們真正的意思是什麼
這句話很容易被誇大。
開源 AI 並不是要一舉取代所有 SaaS 公司。它正在取代的，是一類持續增長的、特定於工作流程、偏重中間層、使用者介面較薄弱的產品，而這些產品核心價值的可複製性正越來越高。
具體來說，這包含了圍繞以下工作而構建的軟體：
- 回答內部文件的問題
- 總結會議記錄或逐字稿
- 分類並分派客服單據
- 生成報告或提案
- 自動化重複的後台行政任務
- 豐富潛在客戶資料與 CRM 數據
- 建立內部專屬的 AI 助手（Copilot）
- 從雜亂文件中提取結構化資料
- 建立輕量級客服助手
- 透過規則與觸發條件連接不同工具
這類別中數量驚人的 SaaS 產品，並非因其工作流程設計有難以逾越的護城河。它們的優勢往往來自於產品包裝、通路佈局、使用者體驗以及信任感——而非一個無可取代的技術核心。
這之所以重要，是因為這個技術核心，正是開源 AI 正在讓其複製成本大幅降低的部分。
為什麼這個轉變現在發生
這不僅僅是因為模型變好了。
這是五個變化同時發生的結果。
- 開源模型對許多商業任務來說已經「夠好」
最大的突破點，並非開源模型在每一個基準測試上都超越了最先進的封閉模型。
而是它們「不再需要」做到這一點。
對於許多商業工作流程來說，「世界頂尖」並非必要。團隊實際需要的是：
- 穩定的結構化輸出
- 可接受的推理能力
- 強大的摘要能力
- 良好的檢索基礎
- 可接受的延遲
- 隱私保護與部署控制權
這個門檻遠比最先進模型所營造的 hype 來得低。
在許多使用案例中，開源模型已經超越了這個門檻。
- 模型周邊的基礎設施已趨成熟
單單一個模型，無法取代一個 SaaS 工具。
一個模型還需要搭配：
- 推理層
- 使用者介面
- 檢索系統
- 自動化邏輯
- 日誌記錄
- 權限管理
- 儲存
- 評估機制
這樣組合起來，才開始像個產品。
而這個周邊生態系的存在，正是開源技術棧能夠可行的關鍵。
- SaaS 的「服務 sprawl」變得既昂貴又營運混亂
團隊已經對不斷疊加的訂閱感到疲憊。
每新增一個工具，就意味著：
- 多一張帳單
- 多一個登入系統
- 多一次供應商評估
- 多一個資料孤島
- 多一個整合介面
- 多一次續約決策
當一個開源技術棧能夠取代三到六個功能範圍狹窄的工具時，其經濟效益很快就會引起關注。
- AI 原生的工作流程本質上就是可組合的
傳統 SaaS 通常假設了固定的工作流程。
而開源 AI 技術棧則獎勵「組合」這件事。
這意味著，公司可以越來越有能力建立專為其實際營運而量身打造的系統，而不是反過來迫使營運流程去適應預先打包好的軟體假設。
- 掌控權正變得具有戰略意義
現在，有更多團隊深切關心：
- 他們的資料儲存在哪裡
- 他們依賴哪個模型供應商
- 規模化後的實際使用成本是多少
- 他們能否更換供應商
- 他們 AI 產品的行為是否可以被檢查與審視
開源技術棧在某些方面提供了 SaaS 產品難以比擬的掌控權。
最容易受到開源 AI 衝擊的 SaaS 類別
並非所有 SaaS 都同樣脆弱。
最容易受到衝擊的類別通常共享四個特徵：
- 工作流程是重複性的
- 使用者介面相對較薄（功能單純）
- 其「智慧」核心主要是文字轉換或分流
- 該產品可以透過組合模型、提示詞、檢索和自動化來重建
最容易受衝擊的類別
- 內部知識助手
許多團隊如今建立內部「文件問答系統」的速度，比他們評估企業級 AI 知識工具還要快。
- AI 寫作與摘要工具
如果產品核心是「輸入文字，輸出更好的文字」，那麼複製它的門檻已經急遽降低。
- 基礎客服助手與常見問題機器人
一旦檢索、護欄（Guardrails）和升級處理得當，許多客服使用案例在技術上已不再複雜到需要專業供應商。
- 帶有 AI 層的工作流程自動化工具
「AI 自動化」產品中，有相當大的比例正面臨著開源編排工具、API 以及本地或託管模型的組合挑戰。
- 潛在客戶開發與研究助手
這類工具仍需謹慎的資料來源與合規處理，但工作流程中的大部分，現在已可透過開源資料、適當的爬取管道、資料豐富化 API 以及 AI 摘要來重建。
- 文件提取與分類軟體
這是一個主要的類別。
對於許多結構化文件的工作流程，團隊現在可以結合 OCR、提取管道、驗證邏輯和 LLM，來取代昂貴的單點解決方案。
較不易受衝擊的類別
有些 SaaS 產品因其依賴以下因素而較具防禦力：
- 專有的通路
- 特定的合規認證
- 網路效應
- 受監管的工作流程
- 深度嵌入的整合
- 企業級規模所需的信任與可稽核性
- 獨特的數據集或營運記錄系統
換句話說，開源 AI 的強項在於解決 工作流程的智慧問題，而不是在於 機構信任、通路或基礎設施的慣性 這些護城河。
現代的開源 AI 技術棧實際長什麼樣
當人們提到「開源 AI 技術棧」時，他們的描述通常過於模糊。
實際上，它通常由以下幾個層次構成。
- 模型層
這是語言或多模態智慧所在之處。
常見的選擇包括：
- 用於推理和生成的開放權重 LLM
- 用於低成本分類和提取的較小本地模型
- 用於嵌入、轉錄、OCR 或重新排序的專業模型
關鍵的轉變在於，模型不再是整個產品。它只是一個更大系統中的一個層。
- 推理層
這是實際提供模型服務的運行時環境。
常見的模式包括：
- 用於實驗和私有工作流程的本地運行時
- 為團隊提供的自託管推理伺服器
- 當管理 GPU 顯得不必要時，使用託管的開源模型供應商
這一層決定了成本、速度、營運複雜度和隱私保護策略。
- 檢索與資料層
這是將通用模型轉變為商業工具的關鍵。
典型組件包括：
- Postgres 或其他結構化儲存
- 用於語意檢索的向量搜尋
- 文件儲存與物件儲存
- 元資料與過濾系統
- 資料連接器與攝取管道
AI 產品的大部分實用性來自於這一層，而非基礎模型本身。
- 編排層
這一層控制系統的行為。
它決定：
- 何時呼叫模型
- 使用哪個模型
- 如何檢索上下文
- 何時呼叫工具
- 如何將步驟串連起來
- 如何處理失敗和重試
這正是自動化平台、工作流程引擎和 Agent 框架變得有價值的地方。
- 介面層
這是使用者實際接觸的部分。
它可能是：
- 聊天 UI
- 儀表板
- 瀏覽器擴充功能
- 內部管理工具
- Slack 機器人
- API 端點
- 基於表單的工作流程畫面
開源技術棧現在能夠競爭的一個關鍵原因，在於許多商業工具並不需要極其複雜的使用者介面來傳遞價值。
- 可觀測性與評估層
這是區分玩具與可靠系統的關鍵。
你需要知道：
- 哪些提示詞被執行
- 哪些上下文被檢索
- 請求花了多少時間
- 推理成本是多少
- 哪些部分失敗了
- 輸出品質是改善了還是退步了
隨著 AI 產品日趨成熟，這一層正逐漸成為整個技術棧中最具戰略重要性的部分。
一個實際例子：技術棧如何同時取代多個工具
想像一個小型銷售或營運團隊。
過去，他們可能需要分別為以下服務付費：
- 會議轉錄
- AI 摘要
- CRM 資料豐富化
- 內部搜尋
- 提案草稿撰寫
- 工作流程自動化
- 支援文件搜尋
一個現代的開源技術棧可以將其中大部分功能整合進一個內部系統中。
例如：
- 用於通話的轉錄模型或 API
- 用於儲存指南、逐字稿和提案的文件儲存庫
- 用於知識搜尋的向量檢索
- 用於將摘要導入 CRM 的工作流程引擎
- 用於生成後續跟進草稿的提示詞模板
- 供團隊存取的儀表板或聊天 UI
- 用於衡量答案品質與工作流程可靠性的評估層
這單一技術棧就能取代多個狹義工具，同時給予團隊對輸出格式、模型選擇和成本行為更大的控制權。
這正是許多 SaaS 類別之所以脆弱的原因。
並非因為開源 AI 在理論上多麼強大。
而是因為它越來越有能力將多個軟體採購，收斂成一個可組合的單一系統。
目前最常見的開源 AI 技術棧模式
不同的團隊根據其成熟度和目標，採用不同版本的技術棧。
模式一：個人開發者技術棧
這在獨立開發者、技術創作者和顧問之間很常見。
典型組件：
- 本地或低成本模型運行時
- 簡單的資料庫
- 工作流程自動化工具
- 輕量化前端
- 一個檢索層
- 一個部署目標
此技術棧專為速度和成本紀律而優化。
模式二：新創公司內部工具技術棧
這在建立內部 AI 助手或流程自動化的公司中很常見。
典型組件：
- 託管或自託管模型層
- Postgres + 向量支援
- 文件攝取
- 認證與角色存取控制
- 工作流程引擎
- 日誌記錄與追蹤
- 管理儀表板
此技術棧專為快速實現內部槓桿效應而優化。
模式三：代理商或營運人員技術棧
這種模式常被代理商用來為自己或客戶取代多個重複的 SaaS 工具。
典型使用案例：
- 潛在客戶研究
- 提案生成
- 報告自動化
- 客戶支援助手
- 內容工作流程
- 案件受理與分流系統
此技術棧專為跨專案的可重用性而優化。
模式四：產品化的 AI SaaS 替代技術棧
這是當團隊不僅僅在內部使用這個技術棧，而是將其打造成一個產品時的情況。
此時，技術棧通常會加入：
- 計費系統
- 多租戶架構
- 細粒度的權限管理
- 更穩健的監控
- 反饋與品質保證工作流程
- 更強的資料治理
這時，開源組合就成為了 AI-first SaaS 公司的直接威脅。
這些技術棧中反覆出現的工具
具體的技術棧不斷在變化，但某些類別的工具反覆出現。
按層次劃分的常見構建模組
層級
常見的開源選擇
為何重要
模型
開放權重 LLM、嵌入模型、重新排序器
核心推理與檢索品質
推理
Ollama、vLLM、自託管運行時、開源模型 API
成本、隱私、部署靈活性
資料庫
Postgres、pgvector、文件/物件儲存
結構化與語意記憶
自動化
n8n 及類似的工作流程工具
連接系統、減少人工操作
應用層
Next.js、React、內部儀表板、API
輕量化產品表面
聊天/搜尋 UI
Open WebUI、自訂介面
快速存取內部 AI 工作流程
可觀測性
Langfuse、追蹤工具、自訂日誌
可靠性、品質與迭代速度
認證/後端
Supabase、自訂認證、託管資料庫層
快速產品組裝
評估
提示詞測試、回歸測試套件、評分量表
防止品質無聲衰退
重點不在於每個工具的具體品牌名稱。
重點在於，每個主要的層級現在都有可信賴的開源或開放標準選項。
這正是改變「自建 vs. 購買」決策方程式的原因。
為什麼團隊在 SaaS 看似更簡單時，仍選擇開源路線
乍看之下，SaaS 仍然看起來更簡單。
通常也確實如此。
那麼，為什麼還有更多團隊選擇這條更難的路？
因為在適當的情境下，這條更難的路在戰略上更勝一籌。
- 較低的長期成本
一個訂閱看起來很便宜。
七個功能重疊的訂閱就不便宜了。
開源技術棧通常有較高的初始設置成本，但邊際成本更低，特別是對於已經擁有內部技術人才的團隊而言。
- 更好的客製化能力
大多數 AI 工作流程在不同團隊間並非完全相同。
SaaS 工具常常迫使團隊採用一個「中庸」的工作流程。
而透過組合的系統，團隊可以將自己的邏輯、提示詞、審批流程和檢索行為編碼進去。
- 隱私與資料控制
當許多企業可以自行託管或管理更大比例的技術棧時，他們對於將敏感的內部資料透過一連串第三方工具發送感到越來越不自在。
- 較少的供應商鎖定
開源技術棧使得更換組件更加容易。
你可以更換：
- 模型供應商
- 推理策略
- UI 層
- 自動化引擎
- 評估流程
而不需要從頭重建整個系統。
- 更快的學習循環
當你擁有整個技術棧時，你才能了解工作流程實際在哪裡卡住。
這通常比過早購買一個包裝精美的抽象層更有價值。
SaaS 仍然明顯佔優的地方
一個成熟的分析也必須坦白地說：
在許多情況下，SaaS 仍然是更明智的選擇。
當你需要以下條件時，SaaS 仍然佔優：
- 立即部署，只需極少的工程投入
- 合規性、服務等級協議（SLA）和採購準備度
- 企業級支援和明確的責任歸屬
- 為非技術團隊提供高度精美的使用者體驗
- 深度、專有的整合
- 那些不值得為其建立客製化所有權的工作流程
- 一個「記錄系統」，而非一個「工作流程層」
這就是為什麼最優秀的營運者不會陷入教條主義。
他們不是因為開源 AI 很時髦才取代 SaaS。
他們是在經濟效益、控制權和產品靈活性證明其合理時，才會取代 SaaS。
團隊在採納開源 AI 時最常犯的錯誤
他們試圖太早取代太多東西。
這通常會導致以下兩種糟糕結果之一。
結果一：技術棧變成一個內部科學專案
團隊花了數月時間組裝基礎設施，卻遲遲未能交付商業價值。
結果二：他們推出了一個脆弱的原型，卻誤以為它是一個產品
這個工作流程在展示時運作良好，但在實際使用中卻會崩潰，因為可觀測性、權限、評估和復原邏輯都被忽略了。
採用這個技術棧的正確方式，不是從頭重建你的整個軟體棧。
而是從一個工作流程開始，這個工作流程必須具備：
- SaaS 成本很明顯
- 工作流程是重複性的
- 邏輯是可解釋的
- 掌握控制權的投資報酬率很高
這正是開源 AI 表現最好的地方。
一個更聰明的技術棧採用方式
最強大的團隊通常遵循一個順序。
第一步：識別一個高摩擦的工作流程
好的例子包括：
- 跨文件和錄音的內部搜尋
- 重複性的報告生成
- 潛在客戶資格審查與資料豐富化
- 客服回覆草稿生成
- 文件提取
第二步：先只重建智慧層
不要一次性替換所有東西。
從替換成本最高或靈活性最低的部分開始。
第三步：在覺得必要之前，就及早加入可觀測性
記錄以下內容：
- 輸入
- 輸出
- 檢索上下文
- 失敗
- 成本
- 延遲
沒有這些，你將無法判斷系統是否在變好。
第四步：保持介面簡單
一個能用的基本 UI，勝過一個導致延遲上線的複雜 UI。
第五步：在擴展技術棧之前，先證明商業價值
一旦一個工作流程運作成功，再謹慎地擴展。
如此一來，開源 AI 技術棧才能成為營運上的槓桿，而非技術作秀。
對 SaaS 真正的競爭威脅並非模型本身
而是「組合」這件事。
這是許多人仍然忽略的戰略性觀點。
SaaS 公司面臨的主要威脅，並非來自一個更厲害的模型。
他們面臨的威脅，來自於一個公司可以越來越多地自行組合自己系統的世界，這些系統來自：
- 開源模型
- 開放基礎設施
- 靈活的自動化工具
- 大眾化的資料庫
- 輕量化的介面
- 可重複使用的提示詞與評估層
一旦這成為常態，重心就會轉移。
勝出的產品不再自動是擁有最漂亮儀表板的那一個。
它可能是最容易適應、最便宜運作、且最無痛整合到現有工作流程的那一個。
這將從根本上改變競爭格局。
這對創辦人和營運者意味著什麼
如果你現在正在建構或採購軟體，實際的教訓很簡單。
你應該停止將每一個 AI 工作流程問題都視為一個軟體採購問題。
有時候它確實是。
但越來越多的情況是，它是一個 技術棧設計問題。
這意味著，值得提出的問題是：
- 這個工作流程在戰略上重要到值得我們自行擁有嗎？
- 我們是否正在為現在已經可以被複製的東西支付 SaaS 的價格？
- 一個可組合的內部技術棧能否取代多個單點工具？
- 真正的護城河是來自於供應商本身，還是僅僅來自於執行速度和產品包裝？
- 我們需要一個精美的外部產品，還是一個可靠的內部系統？
能夠很好地提出這些問題的團隊，將在未來幾年做出更好的技術決策。
最終思考
開源 AI 技術棧並非在取代所有 SaaS。
但它正在取代足夠多的 SaaS，以至於軟體市場被迫進入一個新的現實。
越來越多的工具不再僅僅因為它們方便就安全無虞。
如果它們的核心價值可以透過開源模型、檢索、編排、儲存和一個薄薄的介面來重建，那麼它們所屬的類別就正承受著壓力——無論他們承認與否。
這並不意味著每家公司都應該急著把所有東西都自託管。
它確實意味著一個舊有的假設——先買，只有在絕對必要時才自建——正在變得越來越弱。
在 AI 密集型的工作流程中，一個新的假設正在浮現：
當邏輯是可複製時，優先考慮組合；唯有當信任、規模或複雜性確實證明其必要時，才選擇購買。
這就是那個轉變。
而對於現代軟體中相當大的一部分來說，這個轉變才剛剛開始。
