人工智慧商業化定價模式的變化
從基於功能的定價轉向基於技能的定價？+ 淺談Meta’s AI Engineer
Hi, this is Robert. Here I share top of minds about tech, PM career, and product development. Your support means a lot to me, and if there’s a topic you’d like to explore together, don’t hesitate to reach out 🤝
跟大家拜個晚年，希望在新的蛇年各位朋友們都一切順心，身體健康！上週停更休息一週，這週想來聊聊AI商業化定價模式的變化趨勢觀察，也感謝兩位創業家鄰居Johnny, Sam聊天中對AI商業化定價的啟發。
---
傳統的SaaS（軟體即服務）定價依賴於基於功能的「好-更好-最好」分層模式，但AI產品正逐漸轉向基於技能的定價，客戶支付的是服務品質和能力，而不是功能的使用權限。
企業不再以功能設限，而是基於服務水準（如準確性、速度和模型能力）收費——類似於支付初級人才與高級人才不同費率的方式。
---
最近，有關AI商業化的幾項重大宣佈：
- OpenAI 推出了 ChatGPT Pro，每月單用戶費用為 200 美元，價格是 ChatGPT Plus 的 10 倍。
- OpenAI 的執行長山姆·阿特曼（Sam Altman）稍後在 X 上表示，OpenAI 在這些訂閱上是虧損的——「人們的使用量遠超我們的預期」，並且他「親自決定了價格」。
- 由 Salesforce 前聯合執行長創立的 AI 初創公司 Sierra 宣佈，他們全面採用基於成果的定價模式，目前估值達到 45 億美元。
- 僅創立 6 個月估值就達 20 億美元的 AI 公司 Cognition，將其 AI 程式設計代理 Devin 上市，月費 500 美元，且「無席位限制」（但有使用額度），這一服務迅速在網路上走紅。
- 客戶支援平台 Help Scout 宣佈，作為公司 14 年歷史中「最激進的決策」（由共同創辦人兼執行長 Nick Francis 表示），他們取消了席位限制，定價改為按團隊每月幫助的客戶數量計算。
以上只是過去幾週的部分亮點！
與其說AI商業化的模式正在趨同，不如說正朝著相反的方向發展：定價方式越來越多元化。
人工智慧定價方式的多樣化
許多公司仍然採用基於席位(seat-based subscriptions)的訂閱模式（例如：Notion）。另一些公司則根據AI agent的技能水準來區分價格（如 ChatGPT Plus 與 ChatGPT Pro）。
除了經典的基於使用量定價模式（如 Clay 的使用額度），還有一些變體，如根據使用結果收費（例如：11x 的完成任務數）或成果收費（例如：Intercom 的成功自主解決數）。此外，還有結合固定訂閱費與使用量的混合模式。
鑑於這種快速的變化，我們來分析這些趨勢及其啟示。讓我們深入探討。
---
為「AI全職員工」收費
雖然對下一代定價模式的興趣不一定能轉化為實際採用，但根據2024年SaaS基準數據，54%的AI產品已超越傳統的基於席位的訂閱模式，這一數據高於普通SaaS產品的41%。目前，我們看到使用量定價（25%）與混合定價（22%）占主流，另有少部分基於成果的定價（7%）來自於破局者（如 Sierra、Chargeflow 和 Intercom）。
隨著AI代理業務逐漸從基於席位的定價轉向基於工作單元交付的收費模式，他們往往會遇到客戶的一個困擾：你的定價太複雜，太難預測。
解決此問題的一種方法是：將定價定位為AI「全職員工」（FTE）的等效費用，而不是一組額度。
具體方法如下：
- 繪製出某一特定角色（例如：銷售開發代表、銷售工程師或客戶支援代表）的典型產出或工作產品。
- 例如，銷售開發代表可能會研究X個帳戶，發送Y封外部郵件，並撥打Z次外部電話。
- 將這些產出打包成一個SKU（標準化單位），供客戶購買。
- 將SKU的定價設定為一名全職人員（包括稅金、福利、軟體許可費等）成本的20%-35%。
這正是由a16z和Benchmark支持的AI銷售代表公司11x採用的方式。
根據創始人兼執行長Hasan Sukkar的說法，11x的定價基於AI銷售開發代表完成的任務數，例如識別帳戶、研究帳戶、撰寫和發送消息，或者當潛在客戶回應時安排會議。11x通過將其定價簡化為「一位頂尖銷售開發代表的產出，且成本比招聘一位員工低5倍且部署更快」，讓購買過程更加輕鬆。
為何部分早期採用者看好這一模式：
1. 觸及招聘預算。
公司在招聘人員上的花費遠高於技術預算。當發布職缺時，這表示預算已準備好，為何不利用它？
2. 價值主張無需多言（前提是技術可行）。
客戶可以用更短的招聘與培訓時間、更大的靈活性、更少的休假日，以三分之一的成本獲得相同（或更好）的產出。
3. 簡化的潛在客戶開發。
給招聘經理的外部郵件幾乎不需要撰寫。某人在你的理想客戶群（ICP）中發佈了新職缺？這意味著他們有意向。某職位發布超過30天但尚未完成招聘？這意味著他們有意向且急迫性高。
4. 將複雜的定價轉化為易於理解的價值型定價。
為AI銷售開發代表完成的「任務」支付AI額度感覺過於繁瑣。購買與人類銷售開發代表產出相當的服務則更容易理解。
需要注意的是，這一模式並不一定取代基於使用量或混合定價模式。它是一種簡化某些客戶定價的方式，讓產品更易於購買。
---
從基於功能的定價到基於技能的定價
大約70%的SaaS公司採用某種形式的基於功能定價，通常是組成「好-更好-最好」的套餐。
在這種模式下，SaaS公司通過提供高級功能向客戶追加銷售，從「好」升級到「更好」再到「最好」。這些高級功能通常包括進階管理權限、角色管理、整合功能以及單一登入（SSO）。
正如我之前所說，如果不確定，SaaS公司應默認使用「好-更好-最好」的模式。這種模式讓購買決策對買家（以及銷售）而言相對簡單。隨著客戶加深對產品的使用，它提供了明確的追加銷售路徑，並為新產品開發提供資金。
經典的套餐設計框架是根據以下兩個軸線對功能進行分類：需求度與支付意願（WTP）。
高需求，高支付意願 = 核心（所有套餐的基石）
高需求，低支付意願 = 填充物（追加銷售的好候選）
低需求，高支付意願 = 套餐殺手（附加功能的好候選）
低需求，低支付意願 = 試著移出產品開發計畫！
—
然而，這一框架對於新興的AI代理產品來說，越來越無法適用。
如果我們雇用AI完成工作，我們希望解除對完成工作所需功能的限制。更多功能的開放意味著完成更多工作，而這將帶來更多收入，尤其是在按工作單位收費的情況下。
但客戶願意為更高技能的工作支付更多費用，就像他們願意支付更多薪酬僱用博士畢業生而非大二實習生一樣。
未來，我們可能會為以下內容收取更多費用：
服務水準協議（SLA）
更高的準確性保證
更快的工作輸出或處理能力
更好的模型能力
「人類參與」來驗證準確性
如果你認同這一方向，你可能仍希望為客戶提供多種選擇。但你需要將這些選擇定位為低技能（好）、中技能（更好）和高技能（最好）。將價值主張的階梯化理解為：低成本完成工作 vs. 以合理價格完成工作 vs. 快速且完美地完成工作。
---
當創始人模式碰上定價
今年最具傳播性的定價事件來得早：山姆·阿特曼在 X 上表示，他「親自決定」了 ChatGPT Pro 的價格，並且OpenAI因高使用量而在這一訂閱上虧損
我不想從這個明顯是marketing手段的行為中得出過多結論。但我認真看待這一事件，因為OpenAI的定價是市場 (無論是供應商還是客戶)的核心基準。
我們能思考的幾個問題：
1. 這一現象有多大可能是暫時的？
如果成本快速下降，或產品超越了高使用量的早期採用者，我們可能會看到200美元每月的定價變得更具利潤潛力。
2. 按用戶計費對大多數B2B AI產品並不特別兼容，尤其是在我們從助手轉向代理的情況下。
但在消費者領域，固定費率定價對用戶行為可能產生重大影響。還記得AOL從按小時收費轉變為固定費率19.95美元提供無限制上網嗎？（這是在1996年）。
這一舉措對互聯網造成了「良性破壞」。在定價改變的一年內，線上使用時間據報增加了三倍，達到每月23小時。OpenAI的定價可能會產生類似的影響。
然而，在B2B領域應謹慎套用這一現象。商業用戶的心理不一定相同；使用公司帳戶消費比用私人信用卡支付更不痛苦！此外，商業用戶將產品應用於公司工作流程中的特定部分，並直接與ROI相關——相比B2C的用例較少任意性。
3. 我希望估值4500億美元的公司在制定定價決策時更嚴謹。
創始人幾乎總是定價的決策者——即使公司有專門的定價團隊。
但定量調查、小規模定價測試和「假設」情景測試可以帶來更多的客觀性，幫助做出更好的定價決策。
—
Bonus - 淺談Meta’s AI Engineer
我們在meta已構建 Meta AI engineer的早期版本
我們已在內部部署了 Meta AI engineer 的早期版本，以自主解決工程任務。例如，當測試失敗時，該agent能夠找出問題根源並修復。
此外，它還可以在我們的程式碼庫中找到並修正程式碼品質問題，從而防止 SEV（嚴重事件）發生，並幫助工程師更輕鬆地導航程式碼庫。該代理具備兩種運作模式：自主模式與人機協作模式。我們認為有巨大潛力可將此代理擴展至更多類型的程式碼現代化任務，讓軟體工程師（SWEs）能專注於創新與更具挑戰性的問題。
打造全新類型的代理，超越業界現有解決方案
我們也開始開發一種新型代理，期望能超越業界現有的多種程式碼agent（例如 Replit、Cursor、Devin 等）。其概念十分簡單：目前，程式碼是應用程式運作內容與實現方式的主要事實來源。
這使得維護程式碼、進行修改及修復錯誤變得非常困難，因為開發者需要同時理解「做什麼」與「如何做」。以 Meta 為例，60% 的程式碼差異（diffs）與改善現有程式碼庫有關，包括程式碼重構、遷移、修復錯誤與提升效能。
我們的願景是讓開發者專注於定義應用程式「應該做什麼」，並以清晰的規格表達。
AI engineer則負責將該規格轉換為程式碼，無論是 iOS、Android 或 Web 程式碼。只要遵循規格，agent可以持續維護與優化程式碼，並協助開發者編寫規格，
與現有程式碼agent的差異
當前市場上的程式碼agent大多以聊天為基礎：開發者透過多次與agent的對話，以暫時性的方式表達規格。而這種方法通常表達不夠清晰，導致agent需要做出大量假設。開發者也無法確保最終生成的程式碼能準確實現他們的需求。此外，閱讀他人撰寫的程式碼也變得困難。
我們所探討的概念是：開發的新典範是否應更注重「規格為中心」（spec-centric）而非「程式碼為中心」（code-centric）。我們的假設是，透過提升開發抽象層次，開發者將能更快速地構建與創新。近兒實現人人都可以是tech lead以一擋百效率百倍。
More reading on AI pricing
I post regularly on:
Threads (by Meta): https://www.threads.net/@robertchen0225
Thank you,