a16z最新訪談:說SaaS已死為時尚早,AI會讓這類軟件更有價值

a16z最新訪談:說SaaS已死為時尚早,AI會讓這類軟件更有價值

文章圖片

a16z最新訪談:說SaaS已死為時尚早,AI會讓這類軟件更有價值

文章圖片

a16z最新訪談:說SaaS已死為時尚早,AI會讓這類軟件更有價值

文章圖片



作者|林易
編輯|重點君
在AI沖擊下 , SaaS行業正經歷一場前所未有的信任危機 。 過去這段時間 , 市場中關于SaaS末日的恐慌情緒不斷蔓延 , 許多老牌軟件公司的股價遭遇重挫 。 投資者們集體陷入焦慮:如果AI能夠自動完成所有的企業任務 , 那些以高昂訂閱費為生的SaaS公司 , 是否會徹底走向消亡?
3月6日 , 知名投資機構a16z與軟件公司Atlassian的CEO Mike對此進行了深度探討 。 他們核心觀點是:如果SaaS企業無法適應新的定價模型和人機交互范式 , 確實會被淘汰;但那些掌握了企業核心業務邏輯的系統 , 反而會借助AI構筑起更深的護城河 。
我們梳理了這場訪談的重點信息:
1.軟件的本質正在發生十年來的最大躍遷:從靜態文件柜變成主動執行者
縱觀1960年到2022年的軟件發展史 , 從早期的IBM Saber航空預訂系統 , 到后來的CRM和ERP , 本質都只是在做一件事:把現實世界中的實體文件柜變成了數字化的數據庫 。 過去的軟件是被動的 , 無論界面多么精美 , 依然需要人類員工去檢索文件、閱讀信息并執行操作 。
但在AI時代 , 這些文件柜第一次具備了自主思考和執行任務的能力 。 未來的軟件不再僅僅是記錄數據的容器 。 例如 , 過去的QuickBooks只是讓財務人員從中提取收據來做賬 , 而現在的AI加持下 , QuickBooks可以直接自主完成對賬和催款任務 。 從被動存儲向主動執行的跨越 , 是這一輪軟件革命的真正核心所在 。
2.SaaS行業并沒有迎來末日 , 生存概率取決于定價模式和業務邏輯的深度
市場之所以無差別地拋售SaaS股票 , 是因為投資者沒有看透SaaS公司之間的底層差異 。 Alex指出 , 面對AI的沖擊 , SaaS公司將出現嚴重的兩極分化:
許多SaaS是按賬號座席(Seats)收費的 , 且這些座席直接與工作產出掛鉤 。 例如一旦企業部署了AI客服 , 大部分終端問題能被直接解決 , 企業對人工客服賬號的需求就會趨近于零 。 這類SaaS極度危險 , 如果不改變商業模式 , 其現有的訂閱收入將面臨毀滅性打擊 。
而像Workday等人事財務核心系統的處境就比較安全 。 它們雖然也按員工人數收費 , 但并不與具體的工作產出直接掛鉤 。 更重要的是 , 它們不僅僅是一個數據庫 , 更是企業數十年復雜業務流程、合規要求和隱性規則的集合體 。 AI不僅無法摧毀它們 , 反而會讓它們更有價值 。 比如 , 當企業要在Workday錄入一名新員工時 , AI可以直接調用Workday里的數據去自動完成背景調查和前雇主電話核實 。 AI成為了這些核心系統的放大器 。
3.Vibe Coding只會是核心系統的補充 , 絕非替代品
目前行業內有一種聲音認為:既然普通人可以通過向AI下達自然語言指令來自己寫代碼 , 那企業為什么還要花大價錢買SaaS?大家自己寫一個管理系統不就好了嗎?
Mike認為 , 這種想法完全脫離了真實的商業環境 。 真實的商業世界充滿了無數極其復雜的邊緣場景和特殊法則 。 例如 , 你可以輕易用AI寫一個員工請假應用 , 但當你的印第安納州分公司有員工休產假時 , 當地特殊的法律法規、稅法差異該如何處理?這些隱性知識深深嵌入在大型SaaS的底層代碼中 , 是普通人無法通過幾句提示詞就能復刻的 。
因此 , Vibe Coding的真正價值 , 絕不是去顛覆核心的SaaS軟件 , 而是降低長尾需求的開發門檻 。 比如 , 行政人員可以利用Vibe Coding , 基于Workday的底層數據和規則 , 低成本地為自己的小團隊開發一個會議室預訂小工具 。 這不但不會取代核心SaaS , 反而會使其在企業內部的粘性變得空前強大 。
4.當前AI落地的最大瓶頸已經不是模型智商 , 而是產品設計與人機信任
技術界往往對大模型的參數和跑分極其狂熱 , 但Mike指出:現在AI大模型的能力 , 已經遠遠超出了實際被用戶利用的價值 。
開發者如果只給用戶一個無所不能的空白聊天框 , 只會導致用戶陷入選擇癱瘓 。 要讓AI真正融入工作流 , 需要類似于從PC端到移動端那樣的革命性UI/UX設計 。
而企業級AI落地的最大阻礙是員工的不信任 。 AI Agent在一秒鐘內自動處理了15封郵件和審批 , 用戶的本能反應并不是開心 , 而是恐慌:“它到底發了什么?有沒有出錯?” 。 因此 , 優秀的AI產品必須設計合理的斷點與回路 , 它需要允許用戶在工作流中實時提問“你正在做什么” , 并在關鍵決策前停下來詢問人類的意見 。 只有在不打擾用戶的前提下 , 建立起透明的信任機制 , AI才能真正成為生產力工具 。
面對這一輪技術更迭 , 我們無需為SaaS行業的陣痛而過度悲觀 。 AI在商業軟件中的終局 , 不是建立一座全知全能、徹底淘汰人類和現有系統的神殿 , 而是像基礎設施一樣 , 深深融入到現有的工作流與核心業務中 。 在這場變革中 , 懂得利用AI重構交互、深挖業務邏輯壁壘的軟件公司 , 將迎來比過去十年更加輝煌的黃金時代 。


以下為a16z訪談實錄:
1.SaaS風險水平已上升
Alex:從1960年到2022年 , 軟件的全部歷史就是把文件柜變成數據庫 。 第一個例子是1960年IBM與美國航空合作開發的SABRE系統 。 它取代了以前由眾多秘書管理、存放在保險柜里的紙質預約系統 , 將這些數據存入了早期的數據庫中 。 要知道 , 在那個年代 , 10MB的硬盤可能要花費數億美元 。 電子健康檔案的發展也是如此 , 馬薩諸塞州綜合醫院(Mass General Hospital)開發了最早的系統MUMPS 。 同樣地 , Salesforce以及1987年成立的第一家CRM公司也是如此 , 它們本質上都是把文件柜變成了數據庫 。
這種做法確實有好處 , 但并沒有讓世界變得多高效 。 以前如果要找Eric的資料 , 你會讓專人去人力資源部的文件柜里調取 。 現在雖然數據都在Workday里了 , 但你必須設立首席信息安全官以防系統被黑 , 還需要IT人員在單點登錄系統中為你配置賬號(seats) 。 只有在跨地區協作時效率才有所體現 , 人們現在可以協同工作 , 并在數據庫上執行復雜的連接查詢 , 這在紙質文檔時代要困難得多 。 但本質上 , 從1960年到2022年的軟件依然只是靜態的 , 因為文件柜本身無法思考 。
而如今AI領域正在發生的最酷的事情 , 就是文件柜可以自己干活了 。 比如QuickBooks現在實際上可以獨立完成某項任務 , 而不再僅僅依賴人類從系統里檢索文件 , 這就像徹底告別了16世紀老派會計部門去檔案柜翻找資料的時代 , 非常有趣 。
Erik:這確實是個很好的切入點 。 大家現在都在討論“SaaS末日”甚至“SaaS大災難” , 這顯然是指公開市場上正在發生的事情 。 關于它的重大意義 , 很多人都有不同的觀點 。 我想聽聽你們兩位是如何解讀的?到底發生了什么?更重要的是 , 我們該如何理解這一切?為什么大家對此感到如此恐懼?
Mike:我認為 , 全世界目前都在試圖弄清楚 , 在這個高度顛覆性的階段 , 該如何對軟件業務進行評級或估值 。 每個人對未來會是什么樣子都有自己犀利的見解 。 不同的觀點描繪出了兩種極端的未來:對整個軟件行業、某些特定公司或類別而言 , 要么極好 , 要么極壞 。 毫無疑問 , 目前的風險水平已經上升了 。
從投資者的角度來看 , SaaS曾經是一個非常穩定的類別 , 現在由于風險變高 , 人們會選擇退后一步保持觀望 。 正如我經常說的 , 投資者并不一定是在試圖通過現金流折現模型來計算一家公司歷史上所有的利潤 , 他們其實是在揣摩其他投資者會怎么做 , 或者說 , 他們押注的是別人眼中的未來走向 。
目前的恐慌其實有些脫離現實 。 大家總是在想:“如果AI在兩三年內就能實現某個功能 , 那意味著什么?”我認為這種擔憂源于一種非常靜態的思維方式 , 仿佛人們不會去適應、世界不會改變 , 就好像只有AI這一項技術在變 , 而其他所有事情都將保持靜止 。 所以現在的局面很有趣:像我們這樣的企業依然表現出色 , 已經連續三個季度業績優異 。 盡管我們不是在這里為整個軟件行業辯護 , 但就我們自己的業務而言 , 我們對當前的機會感到非常樂觀 , 這也是我們不斷展示出的數據和結果所證明的 。
當然 , 這并不意味著我們不需要去適應 。 我們正在像過去幾年一樣 , 徹底、迅速地改變我們的工作方式 。 許多人誤以為我們無法改變或應對 , 這顯然是不對的 , 雖然前路確實有許多戰略上的變數 。 現實情況是 , 并非每一家SaaS公司都能在未來十年中繁榮發展 。 就像從Windows時代跨越到互聯網時代 , 有一大批公司未能成功轉型云端一樣 , 不可能100家SaaS公司都能挺過難關并繼續壯大 。 也有人認為軟件在某種程度上會消亡 , 或者最終只淪為一種現金收入流 。 但我可以代表我們公司發言:這是我們業務中發生過的最好的事情 。 我們身處一個知識的世界 , 擁有利用知識進行探索和行動的工具 , 以此來完成客戶雇傭我們去解決的任務 。 這在邏輯上是非常完美的 , 但我們必須在轉型過程中將其付諸實踐向人們證明 , 畢竟讓市場保持耐心是很困難的 。

2.三類SaaS公司
Erik:Alex , 你呢?你對最近發生的事情有什么反應 , 或者你如何理解正在發生的事情?
Alex:我希望從長遠來看我的判斷是正確的 , 因為現在發生的一切實在太瘋狂了 。 幾周前我就此發過一條推文 , 我初步觀察發現 , 目前市面上大概有三種不同類型的SaaS公司 , 但公開市場無法區分它們 。 其中一種公司的賬號(seats)權限是與產出掛鉤的 , 賬號(seats)由真正使用系統的人占據 , 這就好比又回到了剛才那個文件柜的比喻 。
在深入探討之前 , 我想先退一步回答你的問題 。 丹·艾瑞里(Dan Ariely)寫過一本非常棒的書叫《怪誕行為學》 。 我以前常把這本書發給公司的所有產品經理 , 讓他們通過學習這本書來搞清楚我們該如何向用戶收費 。 書中有一個很經典的例子:想象一下 , 半夜12點你被鎖在公寓外面 , 你叫了一名鎖匠 。 他1分鐘就趕到了 , 花了30秒幫你開了門 , 然后向你收費500美元 。 你心里肯定會想:“就干了90秒的活 , 居然收我500美元?搞什么鬼!”于是你會在Yelp上給他留個一星差評 , 不給小費 , 甚至可能向信用卡公司申請撤銷這筆扣款 。
【a16z最新訪談:說SaaS已死為時尚早,AI會讓這類軟件更有價值】現在想象一下另一個平行時空:鎖匠來了 , 花了9個小時嘗試幫你開門 。 他中途回辦公室拿了更多工具 , 折騰到早上9點半 , 終于讓你進了家門 。 此時你會對他花了九個半小時幫你開門感激涕零 , 不僅給了他200美元的小費 , 還在Yelp上留了五星好評 。
這個例子基本上說明了 , 人類在某種程度上能夠并且愿意為“無能”買單 。 很多定價策略其實關乎心理上的公平性 。 我們覺得給那個折騰了一晚上的人多付錢是公平的 , 哪怕他完全不稱職;而面對那個能力極強的同行 , 我們卻因為覺得他收費過高而感到極其憤怒 。 這在邏輯上毫無道理 , 但在情感上卻讓人感覺很公平 。
如果你回想一下我們是如何演變成SaaS模式的 , 比如按人頭每月計費這種 。 當你免費提供時 , 很多情況下的數字化配置成本幾乎趨近于零 。 這并非針對所有事物 , 大家只是覺得這樣才公平 。 比如你有500個賬號(seats) , 你支付的費用自然比只有一個賬號(seats)時更多 , 盡管后臺運行的機制其實大同小異 。
所以我認為SaaS公司可以大致分為三類 。 第一類是你原本需要賬號(seats)來產出某些工作要素 , 但現在不再需要了 。 Zendesk就是這里的“一號病人” 。 如果Zendesk客戶現在使用Sierra、Decagon或者選擇自研方案 , 他們需要的賬號(seats)可能就是零 。 因此對于Zendesk來說 , 我們談論的是未來現金流的現值 。 他們正處于危險之中 , 因為如果只針對現有產品按每月每賬號(seats)收費 , 永遠不對代碼或定價做出任何改變 , 那項收入流百分之百會歸零 。 但另一方面 , 如果他們轉向基于結果的定價并放棄原有模式 , 收入也可能會翻三倍或四倍 。 這仍然受制于公平法則和可預測的非理性 。 像Zendesk這樣的產品可能上漲也可能下跌 , 但除非發生改變 , 否則默認路徑就是走向歸零 。

第二類是按賬號(seats)付費的定價 , 這感覺很公平 , 但賬號(seats)并沒有綁定到某個結果上 。 比如Workday有這樣一個很棒的定價模型 , 由于你有34萬名員工 , 我就按每人每月向你收費 。 為什么收費?我不知道 , 只是覺得這樣公平 。 但是GE的那些員工并不是在使用Workday來產出成果 。 我覺得Workday挺好的 , 這其實涉及到你可以用AI工具做什么 。 比如在GE招聘員工時 , HR必須去查看Workday中的文件并致電那三家前司來進行背景調查 , 確保候選人的履歷真實 。 但AI工具完全可以做到致電公司這一點 , 前提是你必須是核心業務系統 。 目前IT領域下跌了45% , 但沒有人會棄用QuickBooks 。 這兩個支柱就是按賬號(seats)計費且與某種工作量掛鉤 , 賬號(seats)只是一種聰明的定價策略 。
第三類是處于中間狀態的產品 , 比如Adobe 。 你可能需要更多或更少的賬號(seats) , 但情況既不像Zendesk那樣極端 , 也不像Workday那樣脫節 。
在這些情況之外還存在一種認為用AI能編寫所有代碼的潛流 , 作為一名資深軟件開發人員 , 我認為這簡直荒謬 。 我想引用經濟學家大衛·李嘉圖在1817年提出的比較優勢理論 。 比如你可以自己種糧食或焊接鋁材 , 但即使是這些簡單的例子也不恰當 。 這就好比在和你一起錄制播客這件事上我擁有比較優勢 , 我做這個能賺得更多 , 即使我可能比水管工更有生產力 , 我還是應該專心做播客 。
更重要的是那些隱藏在底層的邊緣情況 。 理論上我可以通過AI自動編程搞定一些Workday的流程 , 但如果印第安納州的那個員工離職了且當時正在休產假呢?除非你親身遇到過 , 否則你根本無從知曉這些邊緣情況 。
許多軟件其實是一套經過數十年學習積累而成的確定性規則 , 這些規則并未公開且內嵌其中 , 你無法直接復制 , 需要通過經驗來復現 。 如果這是一個非常簡單且沒有邊緣情況的子任務 , AI確實可以勝任 。
但我認為真正的核心業務系統、具有粘性、人們所依賴且內置了所有邊緣情況的軟件將會大有作為 。 它們將開始增加由AI完成工作的功能 , 比如詢問你是否需要進行背景調查或催收逾期的應收賬款 。 你不需要雇傭人工 , 雇傭你的軟件即可完成這些任務 。 當這一切真正發生時 , 未來的現金流將會大幅增長 , 這令我震驚 。
許多公開市場投資者無法區分這些不同的范疇 , 他們對AI非常興奮 , 卻不知道必須通過作為核心業務系統的軟件來部署AI 。 我認為現在正是每個人回歸商業本質第一性原理的迷人時刻 。
Mike:我個人很討厭“核心業務系統”這個說法 , 因為它聽起來就像是一個靜態的數據庫 , 把東西放進去再取出來 。 這種將業務視為文件柜歸檔系統的觀點 , 是處于一種非常工業化的時代背景下 , 與前工業時代的商業模式截然不同 。
我明白為什么會有這個術語 , 但這感覺有點像我們還在用實體軟盤圖標作為保存按鈕 。 孩子們根本沒見過實體軟盤 , 卻一直用著這個圖標 。 我質疑這一點是因為對我來說 , 業務是一套基于流程的系統 , 而不是記錄系統 。
Alex剛才所說的一切完全正確 , 企業中存在諸如背景調查或其他類似流程 。 你能以盡可能低廉、高效且快速的方式協調一系列流程發生 , 這實際上是知識型業務的核心 。 在知識時代的業務中 , 我有上萬名每天走進大樓帶著大腦工作的員工 , 下班離開時又帶走大腦 。 我沒有任何原子資產、鉆頭或鋼材 , 甚至連文件柜都沒有 。 我所做的一切都是關于協調那一套套的流程 , 我認為大多數現代企業可能都是如此 。
談到這一點與Alex的評論有什么關系?我認為這完全正確 。 我們在業務中有不同類型的流程 , 我喜歡將其稱為輸入受限型和輸出受限型流程 。 以Zendesk的客戶服務為例 , 那就是輸入受限 。 你的客戶會提出一定數量的問題 , 你處理這些問題的速度關系到運行該隊列的效率、成本、速度和質量 。 如果你處理的速度快了10倍 , 你并不會因此得到10倍數量的問題 , 因為客戶數量是固定的 。 你面臨的問題是該如何讓他們減少提問 , 或者更快地處理問題 。 實際上 , 企業中有很多流程都屬于輸入受限型 。
我總是拿我們的法務團隊舉例 , 他們的工作不是去主動創造法務工作 , 而是去響應和處理這些工作 。 比如我們有多少份租賃合同?有多少份NDA保密協議?有多少份常規合同?這就像是一個固定的總量 。 為了完成那項工作 , 我正試著盡可能高效地進行 , 這部分屬于有著完整執行進程的輸入受限工作 。 但隨后我也會面臨某種輸出受限的工作 , 比如創意、營銷甚至是軟件開發和技術領域 , 在這些領域理論上我可以完成無限的任務 。
我的瓶頸在于我的創造力 , 或者說取決于我能想到多少可以做的事情 , 以及我能為客戶交付多少價值 。 這些才是我獲取效率提升并且產出更多內容的地方 , 而不是僅僅在范圍內限制輸入來讓公司盈利 。
關于印第安納州的說法完全正確 , 因為有些流程必然受到外部規則的約束 , 比如法律、治理和合規性要求 。 在印第安納州我必須為員工履行某些特定程序 , 這些流程既是我希望業務運行的方式 , 也是它必須運行的方式 , 企業實際上就是所有這些流程組合在一起的集合 。 從某種角度來看 , 我們擁有記錄系統和執行系統 。 我的想法是大多數企業的實際運作方式并非如此 , 但我們通常是這么理解它的 。
Alex:我完全同意 , 我認為這是一個非常棒的框架 。 我很喜歡Intuit就像TurboTax那樣 , 既然稅法是公開出版的你完全可以去下載所有規則 , 它具有高度的確定性 , 你可以讓報稅和那些亂糟糟的下載文件夾同時處理 。 在這種情況下一切規則都是透明的 , 但我認為邊緣案例被公開發布出來其實是一種相當罕見的情況 。
企業是有價值的 , 理論上有很多偏向知識經濟的企業 , 他們所有的資產每天晚上都會乘電梯下樓回家 , 但這些業務確實具有核心價值 。 比如McKinsey在脫離所有員工之后是否還具有價值?因為那是一家靠知識經濟產出成果的業務 , 它與勞動力深度掛鉤而不像實體產品那樣 。 盡管如此 , 他們可能擁有一本絕密的內部手冊 , 規定了如何運作、如何招聘解雇員工以及如何為客戶帶來成果 。 我還沒見過這種手冊 , 正因為沒見過所以也無法復制 , 而它可能已經建立并延續了一百多年 。
非數字、非軟件公司的產品是什么?他們的產品可能就是長達幾個世紀或幾十年的知識積累 。 我喜歡去日本 , 你會看到有些面館大約從1587年就開了 , 能傳承這么久肯定是有名堂的 。 這是一種長期積累而成的文化、知識和技能訣竅 , 當然也會有一份制作面條的食譜清單 。 做面條可能稍微簡單些沒有那么多邊緣情況 , 但也可能會遇到極端情況 。 比如如果面粉用完了你會怎么做?面館是如何在1623年的大面粉饑荒中幸存下來的?他們必然采取了某些措施 , 而這些經驗就這樣積累在那本秘而不宣的訣竅之書中 , 而不是去復制那些已經向公眾公開的東西 。
Mike:這就是我認為它如此迷人的地方 , 它迫使我們重新思考自己的業務 。 真的是Intuit在為你填寫稅法嗎?還是說Intuit對稅法的了解程度已經達到了無人能及的地步? 。 他們所提供的核心價值是幫助你處理生活數據并梳理你的理解 , 向你提出正確的問題 , 從這點來看Intuit現在更像是一家McKinsey 。 這是他們的特殊能力 , 即如何向你提出正確的問題來填寫稅務表格 , 而不是單純地去填表 。
現在所有企業都不得不重新審視自己 , 也許我內部有50個流程曾被我認為是獨一無二的核心秘訣 , 但實際上只有20個是真正的核心 。 我現在必須認真考慮在這些流程中哪些確實是獨特的而哪些不是 , 因為我們以前從未需要以這種方式進行思考 。
Alex:我認為這在某種程度上是一個關于如何平衡的問題 。 關于這是否值得親力親為 , 如果你采用第三方工具 , 它不是不可觸碰的紅線而更像是一種獨立的變量 。 我現在應該用Claude Code自己寫代碼嗎?如果某家公司對軟件收費過高甚至會導致我的業務失敗 , 且自己開發已經能完成99%的需求并覆蓋成本 , 那么自己寫代碼就是有意義的 。 但如果那個軟件每年只需一美元那自己開發就沒有意義了 。
而且并非所有的記錄系統價值都是相等的 。 我傾向于將記錄系統看作是某種業務的原子單位 。 比如日歷是時間的記錄系統 , ERP是庫存的記錄系統 , 你擁有所有這些不同維度的記錄系統 。 我給別人舉過一個例子 , 比如我在邁阿密有一個不經常去的辦公室 , 那里有一套像Google Calendar一樣的會議室登記系統 , 我是否愿意花精力去更改那個系統?顯然愿意 , 因為那個辦公室一年才去一次誰在乎它穩不穩定呢?
相比之下有些系統可是會直接影響我收入的 , 而且它們本身并不昂貴 。 我真的要為了吃飯自己去種糧食嗎?采用農業隱喻的話去餐廳吃飯其實要便宜得多 。 如果我只是想要一個漢堡 , 肯定沒必要自己去買一頭牛然后喂養等待 , 由于比較優勢和規模經濟的作用在餐廳消費大量的食物實際上成本更低 。
所以存在一些記錄系統更容易受到影響 , 僅僅是因為它們的定價過高 , 或者就其存儲和記錄的內容而言它們的價值并沒有那么高 。 Carta為很多公司追蹤管理股權結構表 , 你多久查看一次股權結構表?雖然不怎么頻繁但它非常重要絕對不能搞砸 。 所以我很可能愿意繼續使用Carta因為他們收費并不高 , 而且它不是那種日常高頻使用的產品 , 所以它甚至不在被替代的考慮維度上 。


3.Vibe Coding替代論難實現
Mike:我覺得vibe coding這件事太迷人了 , 作為軟件圈子里的人 , 感覺人們以后直接靠氛圍寫代碼vibe code就能把那些傳統工具全替換掉 。 但轉念一想如果我靠氛圍寫代碼來搞定一整天的工作然后直接運行它 , 那簡直太可怕了 。 這背后依然得有一些真正聰明的工程師兜底才行 , 首先我有其他更重要的事情要讓他們去做 , 其次我覺得徹底依賴這種方式目前對我來說弊大于利 。 然而這就是所謂的替代論趨勢 。
不可否認的是 , 我們看到內部在軟件的可擴展性方面通過使用AI coding等方式獲得了巨大的提升 。 大多數此類應用程序都具有高度的可配置性和可定制性 , 在我們的案例中甚至實現了真正的可擴展性 。 你可以編寫運行在平臺之上的、涵蓋各種不同領域的軟件應用程序片段 , 許多客戶也確實是這么做的 , 但以前他們需要投入一支龐大的技術團隊來完成這項工作 。
現在他們利用vibe code的能力 , 就可以針對特定用例去擴展和高度定制應用程序 。 比如我想要一個為邁阿密Miami團隊開發的會議室預訂App , 由于邁阿密有一些奇怪的HR政策 , 所以那個供20人使用的App需要隨時查看Workday以及其他各種系統 。 過去我肯定負擔不起讓內部團隊投入IT資源構建它的成本 , 因為賬單金額會太高 , 但現在我也許可以輕松構建它 。 這個App在底層使用了Workday在全球的數據和規則 , 但它給了我一個非常定制化的interface , 去為邁阿密前臺完成一些非常針對他們需求的特定工作 。 這非常強大 , 但它并不能完全取代人類的工作 。
說起來可憐的Workday , 我覺得Aneel就像是這些概念性示例中經常被調侃的對象 。 但這其實真的很強大 , 它實際上讓Workday在企業級市場中更具粘性也更有價值 , 因為你可以基于它構建所有這些定制應用程序 , 這就是AI、Vibe Coding和創造力的力量 , 使底層系統能更貼合我的具體需求 。
但我們必須非常謹慎地處理穩定性、規則流程與高度定制化之間的平衡 。 你甚至可以認為像openclaw之類的例子就是為了給個人量身定制非常私人化的App 。 構建這些應用的人大多數并不是軟件開發人員 , 他們只是在Gmail之上構建僅供自己使用的App或者其他小工具 。 但這仍然是將Gmail作為軌道 , 他們依然需要去Gmail閱讀和處理郵件 , 只不過他們為自己構建了一些特定的東西來解決只有自己才會遇到的問題 。 其中有幾個項目可能會演變成公司 , 但大多數僅僅是在解決他們自己需要處理的事情 , 這確實非常強大 。

4.定價的公平性
Alex:這就是為什么我對前端與后端不一致帶來的定價公平性感到好奇 。 以Salesforce為例他們是按許可證收費的 , 我想我們公司大概有600人 , 可能就買了600個Salesforce許可證 。 我其實從沒登錄過Salesforce但我敢打賭公司也為我付了費 , 然而我有時確實會使用它的輸出 , 因為它實際上是我們的記錄系統 。 不想過度使用這個詞但它確實存儲了我們所有的業務關系 , 而我就像是關系型數據庫表table里的一部分 , 比如我是422號userid 。
每當我與一家公司對接時就像在另一個數據庫中匹配上了 , 但我們其實只想為一個底層數據庫付費 。 現在就像是在一個前端與后端逐漸分離的世界里 , 事實就是這樣 。 我覺得Workday想出了一個非常聰明的定價策略 , 這是一種強大且讓人感覺公平的定價范式 。 你的員工越多付費就越多 , 為什么那樣才公平?因為GE的利潤顯然比一家10人的公司要多 , GE理應為此支付更多的費用 , 而這筆錢對他們來說仍然只是九牛一毛 。 它的定價完全處于最理想的黃金區間 , 我認為沒有人會對此產生異議 。 他們未來將增加大量AI營收 , 但最重要的是他們的底座定價讓人感覺很公平 。
然而對于這些前端與后端在某種程度上已經分離的產品 , 我不知道什么是公平的定價模式 , 也不確定未來的軟件定價會發生什么變化 。 顯而易見如果沒有人愿意買賬 , 大家都去編寫自己的代碼而不再有任何競爭 , 那么定價邏輯將保持不變 , 但你可以想象未來人們都在定制化的前端上構建東西然后直接從底層數據庫中讀取數據 。 因為所有的記錄系統都有一個數據庫代表了底層的一切抽象層 , 那么這些類別中的任何一個是否會面臨價格壓力?
對我來說如果前端不再等同于后端 , 它會比緊密交織在一起的情況面臨更大的易感性和沖擊 。 比如QuickBooks是由小微企業使用的 , 他們沒有賬號(seats)概念 , 企業主直接登錄QuickBooks即可 , 所以它的前端在某種程度上就是后端 。 相反就像Salesforce你可以想象雖然沒有人會徹底棄用它 , 但他們可能會大幅減少賬號(seats)數量 , 因為底層的后端依然必不可少但對昂貴前端的需求減少了 。 他們不會消除或者對后端做任何改動 , 只會優化前端的成本 。
Mike:我一直認為定價的公平性和客戶觀感非常重要 , 人們需要理解他們為何付費 , 并覺得他們所支付的費用在某種程度上與其真實的使用情況相關聯 。 一家擁有1萬名員工的公司在購買Workday時很可能要支付兩倍以上的費用 , 外加一些批量折扣 , 因為他們購買的量更大且業務具有兩倍的復雜度 , 他們自己也認為這很公平 。 這里看起來合理的原則就是:我愿意按員工人數為我的HR系統付費 。
我認為這類事情的核心問題在于它不僅僅是一個數據庫 , 它是一個數據庫加上一組復雜的進程 , 在我成長的那個年代我們管這叫業務邏輯 。 這些業務邏輯絕非無關緊要 , 為什么企業會有這些邏輯?因為企業本身就是作為一系列流程的集合來運行的 , 而且管理者追求標準化以在某種程度上實現流程化 。 這是為了讓不同的團隊以同樣的方式工作 , 以便有人可以管理、理解他們并精準追蹤輸出 。
就像如果我擁有一堆汽車工廠 , 我想要持續跨越它們去追蹤進出的汽車總數 , 業務邏輯被嵌入其中的地方在某種程度上就是護城河和價值所在 。 就傳統方式而言那里的銷售額實際上非常巨大 , 你為銷售團隊制定的那些流程對你來說極具價值 , 而且你會認為這是一種公平的付費方式 。 但問題在于你的銷售協作團隊即那些協作者而非核心用戶 , 他們究竟有多大程度需要這些流程又在多大程度上不需要?
我假設Salesforce Sales Cloud有一個MCP server , 那個MCP server并不直接訪問數據庫 , 它主要涉及你的業務流程以及執行過程中的規則 。 現在的爭議點是某些銷售相關人員如果在市場部門或客戶成功職能 , 他們是否需要那些沉重的流程、治理、控制和規則 。 比如系統規定我們在日本只為客戶提供X服務、為該地區的客戶提供Y服務之類的事情 , 甚至連他們的MCP server都需要專門開一個賬號(seats) 。 至于客戶是否認為這種捆綁收費公平 , 那就是另一個懸而未決的問題了 。
沒錯 , 挑戰在于這該如何定價 。 我想告訴你 , 在討論消費型定價或按需計費定價時 , 基于結果的定價在很多領域都是合理的 , 但我絕對不認為它會成為主流的軟件定價方式 , 或者說不適用于所有的SaaS軟件 。
因為當你與客戶交流時 , 你會發現他們非常討厭這種方式 , 他們真的很反感星號附加條款 。 這與他們認為自己投入的價值無關 。 比如我對Splunk采用的是按量計費 , 如果我發送給他們的日志量翻倍 , 我就得付更多的錢 。 我明白這個邏輯 , 但日志記錄是由我決定的 。 我可以多記一些 , 也可以少記一些 。 我可以對團隊說 , 你們為什么記錄這么多日志 , 這太貴了 , 而且你們真的在用這些日志嗎?我是可以控制我投入的數據量的 。 這與存儲和S3或其他典型服務的模式相同 。 我存入1GB或2GB都沒問題 。 問題在于 , 這些對于我作為客戶來說是相對可轉移且可控的 。
但人們給出的許多關于基于結果或基于消耗定價的例子 , 作為客戶我是無法控制的 , 而且它們也是不可兌換的 。 所以AI Token的世界和AI積分的世界 , 對客戶來說真的非常困難 。 他們會覺得不明白你給我的這種代幣或籌碼到底是什么 。
我可以從AWS獲取1GB的存儲空間并將其部署到Azure , 而且我知道他們會收我多少錢 , 因為每GB的費用基本上是固定的 。 但當我擁有這些AI額度時 , 我不知道你的額度是否和別人的一樣 。 供應商一直在增加新功能 , 我的用戶在使用這些功能 , 所以消耗了我的額度 。 但我不知道他們用這些額度做了什么 。
這并不是公司主動選擇去使用它們 , 而是供應商在添加那些讓軟件變得更好的功能 , 而這些改進似乎是自然而然發生的 。 我可以讓我客戶的額度消耗在一夜之間翻十倍 , 僅僅通過添加一大堆類似為你生成很棒的摘要這樣的功能 。 客戶會覺得我并沒有要求做那個 。
所以我覺得在談論基于成果的使用計費時 , 當你和客戶溝通 , 他們還是想要按賬號(seats)計費 。 這可能是因為他們現在更理解這種模式 , 并且他們被很多按量計費模式坑過 , 這種模式會導致賬單金額大幅飆升 , 他們會不知道該如何控制 。
是的 , 這需要一些時間來適應 。 它肯定會出現在很多類別中 。 我們在Atlassian的業務涵蓋了很多領域 , 你可以稱之為基于用量的定價 , 或者字面意義上的按需計費 。 但我們盡量專注于那些客戶業務量翻倍時 , 他們能獲得兩倍的價值同時也支付兩倍費用的領域 , 而且這一切都在他們的控制之下 。 許多其他定價模式并不在客戶的控制范圍內 。
基于結果定價的最后一個例子是 , 這些結果也是動態的 。 比如在客戶服務方面 , 我為你節省了成本 。 你過去在客服上花20塊 , 使用我們的工具你只需要花10塊 。 在第一年這是一個非常棒的銷售說辭 。 但到了第二年 , 客戶會說我只花了10塊 , 現在我想花5塊 , 否則你沒有提供任何價值 。 而供應商回答說如果把我踢出局 , 你得花20塊 。 客戶就會覺得但我現在只花10塊 。 所以每年能為客戶省錢的能力從結果的角度來看很難衡量 , 即使我正在消除一些繁瑣的任務 。
Alex:我認為從銷售的角度來看也是如此 。 我創辦過兩家支付公司 。 我非常羨慕Workday , 我常會和我的銷售團隊談起Workday , 因為他們對外部情況了如指掌 。 他們知道能從GE賺多少錢 。 他們會說GE有33萬名員工 , 也許我們每個月向他們收取每位員工5美元 , 這就是能從該賬戶中賺到的錢 。
如果你在銷售一款軟件產品 , 這樣去規模化組建銷售團隊要容易得多 。 因為你知道那家公司會付給我們300萬美元 。 相比之下 , 當我們剛創辦公司時 , 簽約了1800個公司 , 我們完全不知道能從他們身上賺多少錢 。 結果真正讓業務運轉起來的是Casper這家床墊公司 。 你根本無法預測 。 你以為拿下了沃爾瑪這樣的大客戶 , 但剛開始進展得并不順利 , 反而是簽下Casper后業績驚人 。
Workday具有這種雙向的可預測性 , 對于出資方的客戶而言是可預測的 , 對于管理團隊來說也是可預測的 。 你能明確應該把時間花在爭取簽下GE這樣的客戶上 , 而不是簽約一家10人的公司 , 因為GE規模更大 。 但在互聯網世界里情況卻非常瘋狂 , Stripe從一家10人公司賺到的錢可能比從GE賺到的還要多 。 在那種模式下你可以獲得更高水平的可預測性 。
但采用基于結果的定價或者基于消耗的定價 , 雖然基于消耗的定價本身并不壞 , 但如果你無法從外部了解一個賬號(seats)能賺多少錢 , 擴展銷售和營銷團隊就會變得呈指數級困難 。


5.為什么在AI時代 , 客戶信任如此艱難
Eric:作為一名企業家 , 我想回到的一點是 , 在這個時代 , 你能分享一下這對你來說最主要的體現方式是什么嗎?以及它是如何讓你改變業務的?
Mike:我們的看法是 , 我們銷售的是解決人類協作問題的協作工具 。 在許多不同的領域 , 包括服務團隊、廣泛的業務團隊、人力資源、財務、軟件團隊等 , 許多不同類型的團隊通過我們購買不同的應用套件和組合 。 從根本上說這些都是涉及大量文本的協作問題 。 這對我們非常有利 。 那些人在做什么才是最重要的部分 。
技術世界往往趨向于重塑一切 , 并認為這是未來的方向 。 從中長期的視角來看這通常是正確的 。 但我們面臨的挑戰始終是 , 我們擁有大量以現有方式工作的客戶 , 如今各種App中的工作流其實并不怎么智能 。 他們想要邁向未來 , 但同時也必須帶動大量的用戶 。 所以當我們構建AI功能時 , 首先考慮的是我們需要理解這項技術是什么 , 以及它能如何幫助我們 。 其次 , 我們需要構建什么樣的基礎平臺組件來應對未來的變化 , 因為這些技術的發展速度實在太快了 。
這就是我們開發AI Gateway、團隊協作圖譜以及企業級合規性與控制功能的初衷 。 你必須將這些內容與你在特定App中為客戶構建的功能區分開來 。 那么你把這些功能放在哪里?這些功能具體是什么?其中很大一部分存在于現有的工作流中 , 旨在幫助客戶更快、更好、更高質量、更高效地完成現有的工作流 。 這些功能往往非常平淡無奇 , 這就像X平臺上那段30秒的動畫GIF走紅一樣 。 但這對于客戶來說非常令人興奮 , 因為他們現在就可以使用 , 他們現有的工作方式變得更出色了 , 他們會覺得這太棒了 。 在AI世界里我卻覺得那其實挺簡單的 , 而且這在今天確實能給他們帶來巨大的幫助 。
我常對內部人員說 , 光舉一個服務方面的例子還不夠 , 你需要利用他們現有的工作流程 , 結合新應用或者查看新的工作流來處理問題 。 所以我們必須完成所有這些 。 如果你看Jira這個典型的例子 , 在我們的HR和IT服務管理產品的服務集合中 , 正在進行工單總結 。 這是我們可以做得比以往任何時候都好得多的事情 。
內部大概有四五個人在處理同一個工單 , 試圖解決一個問題 。 當第四個人介入時 , 已經有了大量的附件和對話記錄 。 通常情況下他們可能需要花費30分鐘才能讀完所有內容并理解到底發生了什么 , 這樣才能發揮專業知識來解決問題 。 總結并不只是簡單地將內容輸入到LLM中然后獲取摘要 。 上下文對模型來說非常強大 , 但客戶的工作流程卻沒發生哪怕一點點改變 。 它仍然是Alex對Eric說你能來幫我處理一下這張工單嗎?Eric走過來必須先將大腦中所有的相關信息進行加載 。 這就像是一個現有的工作流 , 我們可以利用LLM讓客戶體驗變得更好 , 而且他們非常喜歡 , 對這類功能贊不絕口 。 但這些功能通常不具備智能體特性 。
那么我們可以說 , 對于那個服務工作流 , 我們需要在各個環節中加入智能體 。 大多數人正在處理一個工作流 , 然后發現這一步經常讓人栽跟頭 , 耗費大量時間 。 我們能讓這一步變得更快嗎?這絕對是我們必須親自為智能體框架提供的功能 。
我們有一個非常棒的智能體框架供整個團隊使用 , 結合圖譜和你已經擁有的所有上下文 。 這非常簡單 , 價格也非常親民 。 或者你也可以自帶智能體框架 。 我認為大多數企業內部都會運行三到五個大型智能體平臺 。 他們可能會說我用Agentforce來處理這個 , 或者我用Gemini來處理那個 。 把那個智能體帶過來 , 我們會把它放入工作流中讓它運行起來 。 我們必須能夠做到這一點 。
但你仍然完全處于現有的工作流世界中 , 只是在現有的工作流中執行一種新的高效的任務 。 接著你會遇到這樣的人 , 他們會問如果服務工單根本不存在會怎樣?所以你正在重新構思整類軟件到新的工作流 。 我們必須幫助客戶跨越這一鴻溝 , 因為他們通常不只有一個服務團隊 , 他們有數百個 。 如果他們運行著數百個不同的服務臺 , 他們可能會說這20個將以新方式工作 , 但他們必須對所有這些進行管理 。 所以我們正嘗試將團隊協作圖譜中的數據與此結合起來 , 并且是從客戶驅動的角度出發 。 這一點經常被忽略 , 我們正試圖帶他們走向5年后的未來 , 但我們的職責是切實帶他們走向1年后、2年后以及5年后的未來 。
最后我想說的是 , 我們在設計方面投入了大量精力 。 在任何對話中這一點總是被忽略 , 因為在它的運作機制中有很多基礎性的設計工作要做 。 如果回顧移動互聯網時代 , 第一批應用基本上只是將桌面端或網頁端的內容直接搬到手機上 , 然后我們才演進出了新的交互模式和體驗 。
不僅僅是視覺層面的演進 , 還包括我們該如何使用這些東西 。 推送通知最初是用來做什么的?下拉刷新是一個非常顯而易見且簡單的例子 , 它是一個非常經典的設計模式 。 整個過程就像是我該如何讓移動端和桌面端協同工作 , 該如何來回切換 。 我們有如此多的設計挑戰需要解決 。 這實際上是幫助普通用戶理解其中的內容 。 他們并不想深究 , 如果AI對他們來說不存在也無所謂 , 他們想要的是AI帶來的結果 , 不需要了解所有的技術細節 。 我們的工作就是隱藏這些細節 , 直接把結果交給他們 , 或者使任務更有效、更高效 。 在技術領域 , 有時我們太癡迷于模型質量之類的東西了 。
現在說模型已經遠遠領先于實際交付的價值幾乎成了陳詞濫調 。 未被充分利用的潛能是如此巨大 。 這其中的一部分實際上在于設計和體驗 。 我該如何獲得這個?給人們一個擁有無限能力的聊天框 , 他們卻只會說給我講個冷笑話 。 這就像是擁有無限的力量 , 但很難幫助他們利用這種力量 。 這也是我們面臨巨大挑戰的地方 , 即如何將智能體及其所有能力引入工作流和協作循環中 , 并讓人類與智能體協同工作 。
Alex:我喜歡擬物化設計(skeuomorphic) 。 早期Web的形態就像你擁有幾張實體紙一樣 , 這也是它被稱為網頁(web page)的原因 , 就好比一張8.5x11英寸的紙 。 后來到了移動端 , 大家最初的設想只是做一個微縮版的網頁 。 但事實證明 , 如果你不局限于擬物化思維 , 而是基于第一性原理進行思考并充分利用設備的性能 , 你就能創造出全新的交互方式 。 比如下拉刷新 , 這就是伴隨移動端誕生的新概念 。 我前幾天還在琢磨這件事 。 你試過Nano Banana 2嗎?
Mike:試過 。
Alex:沒錯 。 我的一位同事剛跟我說 , 他用它為去日本旅游的美國游客做了一份關于注意事項的信息圖表 。 那種一鍵生成(one-shot)的效果簡直令人驚嘆 。 但這引出了一個問題:你該如何編輯這些輸出結果?現在的編輯方式感覺非常擬物化 , 依然是那種經典的GUI操作邏輯 , 比如點一下這里 , 再修改一下那里 。 所以我想問你 , 關于編輯AI輸出的內容 , 你認為目前業界的最高水是什么樣的?或者說理想狀態應該是什么樣的?既然你提到了設計 , 最近你在這方面有什么深層思考?
Mike:這是一個非常棒的問題 , 我想先退兩步來回答它 。 首先 , 在AI領域建立客戶信任是非常困難的 。 我們在做用戶調研時發現 , 人們害怕AI并不是因為它的能力有多強 , 而是因為它的運作像個黑盒 。 比如你的AI助手瞬間清理了收件箱、發了十幾封郵件 , 用戶的第一反應往往是:“我怎么知道它做對了沒有?”為了贏得信任 , AI必須向用戶及時反饋它的意圖并請求確認 , 但同時又不能頻繁到讓人覺得煩躁 , 否則用戶會覺得還不如自己動手 。 所以交互頻率和信任機制本身就是一個完整的系統設計問題 。
其次 , AI的訓練和應用離不開大量數據與不斷的迭代 。 現在社交媒體上充斥著關于神級提示詞的炒作 , 仿佛念一句哈利波特的咒語就能讓AI自動幫你經營一家十億美元的公司 , 這太離譜了 。 一鍵到位固然有用 , 但在現實業務中 , 你通常需要不斷去修改輸入和輸出 。 比如你讓大語言模型(LLM)寫篇論文 , 生成后你發現方向不對 , 這就需要通過改變輸入來進行迭代 。 但如果你曾嘗試通過純聊天的方式來迭代編輯圖像 , 你會發現體驗非常令人沮喪 , 因為你很難精準控制AI不擅自改動其他部分 。 這本質上也是一個關于輸入的體驗設計問題 。
以我們公司的產品為例 , 我們的團隊協作圖譜擁有海量的組織知識和極高的準確度 , 甚至能記住我十幾年前寫過的代碼 。 但如果因為AI知道我有計算機科學背景 , 就自動用極其硬核的技術語言回答我的所有問題 , 這其實是沒用的 。 如果我們在界面上設置一堆勾選框 , 讓用戶自己決定“是否搜索網絡”或“是否搜索組織數據” , 這也完全違背了設計初衷 。
AI應該具備主動預判的能力 。 你在Deep Research等工具中能看到一些這類嘗試 , 但有時也很讓人沮喪 。 這就好比你手下有50個實習生 , 雖然能干很多活 , 但他們每分鐘會問你50個問題 , 導致你整天什么也干不成 , 全在回答問題了 。
此外 , 在企業環境中實現工作流的迭代要困難得多 。 比如頭腦風暴通常需要團隊協作 , 在我們的Whiteboard和Confluence中 , 你可以引入智能體來輔助 。 它們非常擅長從組織內部提取知識并生成優秀的方案 。 但如果沒有任何人工干預直接讓AI包辦一切 , 就會失去團隊的信任 。 正常的流程應該是我們先開會收集想法 , 加入人類的直覺判斷 , 篩選出有用的部分 , 然后再把這些反饋給另一個智能循環 。 因為AI的輸出質量具有很強的非確定性 , 這就注定了系統必須包含一個人工介入循環 。 沒錯 , 如何把握這個人工介入的度是個極大的設計考驗 。 循環確認的步驟太多會讓人感到沮喪 , 步驟太少又會失去用戶的信任 。
我們剛在Jira中發布了Agent功能 。 當你把任務分配給Agent時 , 它就會去執行 。 但用戶往往會問:“它現在到底在干什么?”如果你給他們展示上千個底層執行步驟 , 他們又會覺得你在給他們塞廢話 。 所以僅僅是將AI引入工作流 , 就面臨著海量的設計挑戰 。
回到實際的業務審批流程上來 , 比如一項交易需要經過安全、會計、財務和銷售等多個部門的審核 , 你該如何用AI優化這個工作流?當你將任務分配給Agent時 , 你需要非常小心地設計用戶體驗:它什么時候返回結果?以什么方式返回?用戶能否在它工作時主動詢問進度?
我們相信 , 允許用戶隨時查看進度有助于在短期內建立信任感 。 但從長期來看 , 如果這個Agent連續二十次都出色地完成了任務 , 用戶最終會選擇完全放權 。 這些全都是根本性的基礎設計與體驗問題 , 而不是純粹的技術問題 。 核心挑戰在于如何讓每天使用App的數百萬用戶對產品產生信任 , 并消除那種黑盒感 。 盲目承諾“我可以為你做任何事” , 只會讓用戶無所適從 。

Alex:這確實還是一個懸而未決的問題 。 因為未來的理想交互方式顯然既不像過去那樣單純地點擊鼠標 , 也不像現在這樣只是不斷地重新輸入提示詞 , 它更像是兩者的結合 。
只要工具是為人類服務的 , 就一定離不開人類的參與 。 你需要讓用戶能夠直觀地深入理解模型內部的運作邏輯 , 無論是出于建立信任的目的 , 還是為了方便后續的修改迭代 。 這本質上是一個設計問題 , 而且我認為目前業界可能還沒有人完美解決它 , 我們正處于這一探索過程的最早期階段 , 大家都在為如何更好地調整和編輯那些一鍵生成的內容尋找最優的設計方案 。
Mike:我想舉一個文檔編寫的例子 。 知識工作者幾十年來都習慣了以固定的模式寫文檔:打開一個空白頁面 , 輸入標題、打字、列出符號或者插入表格 。 現在我們推出了Create with Rovo功能 , 你完全可以從一個提示詞開始 , 讓AI根據模板生成內容 , 甚至讓它先去調研各個維度的信息并整合帶回 。
但要改變用戶根深蒂固的習慣是非常困難的 。 現在界面變成了左右兩部分 , 左邊是文檔實體 , 右邊是聊天窗口 。 想象一下這是一個沒有任何工具欄、只能通過對話來排版的Word 。 我們需要鼓勵用戶:“你可以直接在左邊修改任何文本 , 也可以在右邊輸入指令 , 比如讓它添加一個新章節、去研究其他資料并補充到摘要后面 。 ”
當我們觀察那些高級用戶時 , 發現他們非常享受這種模式 , 他們能熟練地在兩種操作間來回切換 , 領會了這種全新的范式 。 他們可以下達貫穿整篇文檔的全局指令 , 比如“把所有標題變成藍色” , 這在傳統編輯器里是很難一鍵做到的 。 他們甚至可以要求AI從董事會成員的視角來重新評估并精簡這份文檔 。
但對于普通的商務用戶來說 , 他們的第一反應往往是困惑:“所以我只需要在左邊打字就行了?”這實際上是一場深刻的范式轉移 。 我懷疑隨著AI工具的普及 , 就像移動互聯網時代剛到來時那樣 , 大概兩到五年后 , 這種全新的交互方式會變得非常普遍 。 這就好比大家第一次看到Excel時 , 也會茫然地問“我該在哪里輸入段落” , 但現在所有人都知道Excel是怎么運作的了 。
我們面臨的最大挑戰 , 就是如何將所有這些強大的AI能力自然地融入到極簡的界面中 , 去協助人們真正調用整個組織的知識來生成文檔 。 我知道這在底層算法和數學邏輯上是完全可行的 , 但要通過優秀的體驗設計來引導用戶接受并掌握它 , 依然充滿挑戰 , 同時也令人無比興奮 。 我們需要花費大量時間來不斷完善這些體驗 。
Eric:這是一個非常適合作為結尾的話題 。 Mike , 非常感謝你參加我們的播客 , 這是一次非常精彩的討論 。
Mike:好的 , 沒問題 , 伙計們 。 希望這些分享能對大家有所幫助 。

    推薦閱讀