房間里的大象：AI大部分輸出根本沒被用戶采納，都浪費了

如今，每個人都感覺 AI “ 特別厲害 ”、“ 特別有用 ”。

但實際上，我們應該警惕一件事：AI 產品很容易給工作帶來一種 “ 虛假的生產力膨脹 ” 。

在開發者群體中，AI 編程已經有了很高的采用率。比如據 IDC 2025 年 6 月發布的《 中國市場代碼生成產品評估，1H25 》，彼時美國已有 91% 的開發者使用 AI 工具，而中國開發者的 AI 覆蓋率在 30% 。

但另一方面，有一個核心指標卻鮮被提及，這個指標其實更加接近個人和企業是否接受 AI 的核心目標，也就是 ROI 的提升。

這個指標叫采納率。

采納率是指，AI 生成的所有內容中，人類最終采納的內容量的比例。比如 AI 生成了 1000 行代碼，人類采納了其中 300 行，那采納率就是 30% 。

對內容量的量化方式可以有很多種，可以是最精細的 Token 級別，可以是代碼行數，也可以是程序員在使用 AI IDE 時 Tab 鍵采納數的占比，甚至是代碼庫中由 AI 生成的功能模塊數的占比等等。

比如，基于 Zoominfo 2024 年 11-12 月的內部調研顯示（ 團隊涉及 400 多名開發者 ），他們對 GitHub Copilot 生成的代碼的平均采納率為 20%（ 按接受代碼行數衡量 ）。

圖源：https://arxiv.org/abs/2501.13282

基于 SoftDoc 2025 年上半年的內部調研顯示，該公司的 AI 生成代碼建議被接受比例在 13% 到 21% 之間（ 按接受代碼行數衡量 ）。

圖源：https://softdocs.com/blog/measuring-generative-ai-coding-adoption-in-softdocs-engineering

最新數據由 DX AI 提供，他們發布的《 AI-assisted engineering: Q4 impact report 》（ 對 13.5 萬多名開發人員的分析 ）顯示，合并代碼中有 22% 是由 AI 編寫的。

所以，按照目前公開數據顯示，雖然從 24 年至今大家覺得 AI 一直在變強，但 AI 編程工具的輸出采納率總體還是偏低的，在 20% 左右。

并且，目前關于 AI 輸出采納率的相關數據極少。

知危接觸并詢問國內一些大模型廠商的工作人員，未能得到相關數據。并且不管是使用方還是供應商，都認為這個指標是不容易衡量和獲取的。

這一點不難理解，如果每一個用戶都回顧一下自己長期使用 AI 的經歷，肯定能感受到自己在很多場景下對 AI 輸出的采納率其實并不高，但 AI 即時反饋的特性、類似抽盲盒的體驗簡直讓人上癮，使得人們醉心于跟 AI 來回糾纏或大量抽卡，很難注意到實際采納率。

至此，AI 輸出內容的采納率實際上成了 “ 房間里的大象 ” 一般的存在，它很重要且不容忽視，但由于大家對 AI 的狂熱，人們選擇性的忽視掉了這個問題。

AI 產品設計師 John 告訴知危，“ AI 輸出采納率是需要被行業重視的，因為現在網絡充斥著大量 AI 生成的低質量內容，很多發布者不關心內容是否對用戶有價值。但 ‘ 是否提供價值 ’ 應該是所有產品需要面對的問題，也包括 AI 產品。”

“ 如果繼續靠點贊、點踩這種方式，本身的邊際效益已經很低，在現有的 AI 產品交互方式下，用戶很少去做這種反饋。”

John 認為，采納率指標對衡量 AI 賦能程度、采用 AI 的實際 ROI、資源浪費程度、合理使用 AI 的重要性非常高，“ 并且不僅是采納率本身，更是要在意定義 ‘ 采納 ’ 的邏輯，即 ‘ 我因為什么而覺得這個結果有用 ’。”

“AI 產品很容易給工作帶來虛假的生產力膨脹，無論是因為大環境的 FOMO，還是因為過于放任 AI 自主執行導致項目失控的沉默成本，有許多的 ‘ 采納 ’ 其實是個體為了迎合自己的某種情緒而做的，或是為了 ‘ 采納的結果 ’ 而制造出來的問題。做的越多一定會產生更多要解決的問題，不想清楚的話就會在解決這些新問題的 ‘ 動作 ’ 里麻痹自己。”

當然，采納率指標本身不能直接代表最終的目標，“ 單從采納率這一個角度很容易迎合越來越多的 ‘ 生產力似乎提升了 ’（ 采納高 ），但是人越來越忙且沒真正帶來什么改變。這時，實際 ROI 和資源浪費程度等指標就是一些很重要的客觀補充視角。”

對于 AI 產品企業而言，需要更多意識到，采納率最終會極大影響用戶付費意愿。

“ 我經常對某知名通用型 Agent 產品有一個評價：如果它的 Token 價格能便宜 10 倍，它其實有機會成為團隊內部做 Web Demo 的主流工具。”

“ 當然這句話還需要加很多前置定語，除了成本太高，它在使用過程中也需要大量試錯，采納率低，而這些消耗其實和最終的交付物并不直接相關，更多是Debug、潛在的網絡崩潰等問題。”

“ 對于很多個人項目而言，它們往往是個人對現有的解決方案有些不滿的地方，想要做出一個完美適配自己使用需求的體驗。但這些 ‘ 不滿的地方 ’ 往往沒有那么疼，價值有限。尤其是假設我們把這種場景從小部分懂技術的極客推向大眾的時候（ 所謂用動態定制 App 代替傳統靜態 App），Vibe Coding 所帶來的不確定終點的 Token 投入 （ 產品往往都沒有一個預算估計，可能上百美元 ）、潛在的時間與情緒投入，很容易就讓人放棄個人的小需求，向現有產品妥協。”

另一方面，從模型角度，采納率取決于模型在上限和下限的突破。宣傳上大家一般更強調上限，但保證了下限才能讓模型真正成為生產力，這其中的典型是代碼生成領域的 Claude，圖像生成領域的 Nano Banana，以及視頻生成領域的 Seedance 2.0，實際上這幾款模型也是用戶付費意愿在第一梯隊的。

John補充道，“這里需要劃分勞務型（Labor Work）產品和信息型（ Informative ) 產品。對于勞務型產品，比如編程類 Agent，穩定性和可用性肯定是最基本的決定因素。我不可能為了一個不穩定的產品付費或者時間。”

“ 對于信息型的產品，比如問答或 AI 搜索，我是可以接受不穩定但可能會有極限表現的產品的，雖然不一定會付費，但因為不像勞務型產品一個方向只用一款，信息型我永遠會用好幾個產品來豐富視角和信源。所以我會把這樣的產品盡可能加到我的‘信息池’里，不采納也沒關系。”

下文中，知危也將展示從不同企業零星地獲得的一些相關數據，這些數據和上述公開數據相去甚遠，或偏高或偏低，或者只能定性描述，卻也值得注意。畢竟大模型發展太快，一個驗證可行的場景真正的核心影響因素也還沒被探索明白，以及還有大量未被驗證的場景。

在個體體感上來講，一名字節員工程磊（ 化名 ）告訴知危，其用 AI 寫代碼的采納率基本上是 100%，即便有些微不足，也會用 Agent 來修改，“ 今年年后我已經沒有印象自己親手寫過代碼了。”

在程磊看來，采納率本質上依賴模型能力，另外也取決于公司（ 或員工自己 ）肯不肯給員工花錢用最新最可靠的模型來完成任務，“ 我現在用的模型是 Claude Opus 4.6 + GLM5 + Kimi2.5，都是最新的、最貴的，會用在所有寫代碼場景。當然目前 AI 的視覺模態還不行，比如無法準確地操作和測試 GUI。” 而從當前行業更一般的認知看來，采納率的主要影響因素不只是模型能力本身，還有企業的流程成熟度、信息化基礎、管理模式等。

白鯨開源 CEO 郭煒則配合知危對公司內部員工使用 AI 編程的采納率做了初步的調查，其中使用場景分為問答和 Agent。

數據顯示，對于問答場景，主要使用 ChatGPT，調用失敗率幾乎為零，低復雜場景下 AI 輸出采納率（ 只看答案是否帶來信息增益 ）接近 100%，中等復雜場景約 80%，高復雜場景約 60%，其中，三種復雜度場景的任務量占比為 1:7:2 。

郭煒表示，“ 問答場景還是簡單的，一般是問產品相關問題以及寫文章等場景，不要求結果，給我一些提示，我做就行。”

對于 Agent 場景，主要使用 Claude Code，并且會有一定的調用失敗率，低復雜場景（ 比如算法題、日志清洗、爬蟲、API 封裝等 ）為5%，中等復雜場景（ 比如用戶系統、風控規則、緩存優化等 ）為 10%，高復雜場景（ 比如分布式數據庫、云平臺、模型訓練等 ）為 20%；低復雜場景下 AI 輸出采納率（ 基于接受代碼行數 ）也是接近 100%，中等復雜場景約 80%，高復雜場景約 50%，其中，三種復雜度場景的任務量占比為 2:3:5 。

“ 場景越復雜，采納率越低，一般是因為高復雜場景下 AI 對需求的理解不夠到位。要提升采納率，相關經驗已經很多，例如寫好 Code Wiki、用好 Plan 模式等。”

“我們也很重視采納率這個指標，但重視不是因為錢，因為采納率低太浪費時間，要用 AI 寫代碼，就用全球最好的模型。對我們而言，時間比 Token 更值錢。”

“ 我們的 Agent 執行有較大量的高復雜場景，但要讓 Agent 改代碼很難，一般還是人來改。也可以讓 AI 改，但需要掰開了揉碎了給 AI 講，這個過程不容易，我們大概有 400 多萬行代碼，目前的 AI 上下文長度還是不太夠用。”

至于更通用的 Agent，通過一個月的深度使用 OpenClaw，游戲制作人王鯨對龍蝦在游戲開發的相關任務（ 比如辦公、開發、數據分析、咨詢等 ）的采納率也有較深的體會。

不過在實際輸出結果前，龍蝦首先讓人頭疼的是較嚴重的執行失敗問題。

王鯨表示，“ 龍蝦還是比較經常翻車的，問題有大有小。其中比較嚴重的是讓龍蝦去做和網關、基礎配置相關的工作，它會信誓旦旦給你保證執行順利，但其實只是膽子大，實際上經常把自己配死。比如一個簡單的增加新模型的操作，切換模型堪比機器人給自己換電池，拆下電池的那一刻它就死了（ 斷網 ）。在配置文件這塊，很多Agent會調用一個文件，但彼此之間如果沒有很好調和（或溝通），容易把文件改壞。”

“ 記憶也存在調用問題，即便是人工強調過，也有可能因為沒有調用記憶，然后犯下重復執行的錯誤。”

當然王鯨也認為，既然要用，就盡量授權都給龍蝦，這樣才能正常工作，“ 而且像飛書插件這種授權帶時效性的，還需要經常手動檢查授權。”

“ 但為了安全，一定要在虛擬機中使用。我自己使用的是兩層虛擬機也就是虛擬機里的虛擬機，來保障安全。龍蝦的潛在風險還是很高的，即便不提黑客的問題，它也是拿著刀的猴子，可以砍椰子，但是誰知道什么時候會不小心砍到人。”

“ 幻覺是必然存在的，當它說自己沒有辦法 ‘ 看 ’ 網頁的時候，只要告訴它 ‘ 你自帶一個瀏覽器 ’，就能解決很多問題。最后就是記得留各種幫助文檔，讓龍蝦操作之前去讀一下。”

雖然使用龍蝦的起步有各種阻礙，但工作流跑通以后，采納率還是挺高的，整體能達到七成。

“ 為什么采納率高呢？一般我會把需求說清楚，比如詳細說明格式要求，把偏好和原則都記下來，龍蝦會記住，發現問題馬上指出，龍蝦會改進。”

“如果從 ROI 的角度看，龍蝦的高 ROI 場景主要是辦公場景，比如飛書群消息統計/群秘書、周報匯總整理、AI 公司團隊（ 創建多個 AI 員工分工協作 ）、飛書文檔批量處理、日程/任務管理、PM 項目管理助手等，能把 1-2 小時的工作時長壓縮到分鐘級，強烈推薦落地；中 ROI 場景主要是開發分析類，比如網頁生成、代碼片段生成、數據查詢分析/透視，可用但有局限；低 ROI 場景比如復雜工作流編排，出錯后處理復雜，維護麻煩，還有瀏覽器自動操作，只能查看頁面，無法真正操作，這些都不推薦落地。

“ 龍蝦最適合的場景有這些特性：文件/數據密集、重復性、本地集成、異步執行（ 接受分鐘級延遲 ）等，而需要秒級響應、復雜UI操作、調用多個外部 API 的復雜流程、大量主觀判斷的場景則不適合龍蝦。”

王鯨總結道，“ 綜合來說，我現在把龍蝦當做我的 AI 分身加入了公司，進入項目當 PM、秘書以及執行策劃，極大節省了我個人的精力。并且在人際關系處理上，因為 AI 給人的刻板印象就是會得罪人的，所以很多流程化的、不講人情的公式化要求，可以讓 AI 替自己唱黑臉。”

相對于標準化程度高的開發、辦公領域，由于主觀性和創意要求高，設計領域的 AI 輸出采納率特點呈現出極大的不同。

接下來，我們將跟隨 John 的視角，來看看在產品設計領域的不同場景下，AI 輸出的采納率的現狀和特點，由于在該領域很難像代碼一樣進行簡單快速的采納率統計，所以這部分大多是主觀或者體感上的描述，但我們認為依舊很有價值，值得分享。

首先要清楚一點，要在各種場景把采納率量化是很難的事情，比如基于代碼行數的量化指標肯定不適用于產品設計領域。

John 表示，“ 采納率不好清晰定義，因為很難將內容顆粒度拆得很細來衡量，畢竟你很難把 AI 的一個輸出一刀切分，說這一部分全部是 AI 生成的，那一部分完全不是。目前只能定性描述為主。”

要更精確理解工作場景的采納率情況，可以先以生活場景為參考。AI 在生活場景中的應用和搜索引擎沒太大區別，目前落地是比較成熟的。

“ 在生活場景中，AI 基本只有一類使用方式，就是信息查詢，一般是查詢比較簡單的事實型信息。”

“ 比如挑選男性維生素的時候，會提問：應該注意配料表里的哪些成分？但一般不應該直接將 AI 提供的結果拿來用，而是把它當作一個搜索或了解問題的起點。”

“ 模型在回答中通常會提到一些關鍵詞，我會先評估這些關鍵詞或者整段描述的可信度，再通過搜索引擎做一次 Double Check。在 Double Check 之后，如果覺得基本是正確的，就會采納這些信息。”

“ 總體來說，目前這個場景下幻覺率已經相對比較低，尤其是在非常具體的事實型問題上，采納率其實是比較高的。”

“ 這里說的 ‘ 采納 ’，是指我會把這些信息記在腦子里，比如知道男性維生素在配料上可能需要注意什么，之后在實際購買時，會刻意去注意這些信息。” 由于 AI 反饋有即時性，這就催生了一個很重要的新場景，就是靈感探索，這是傳統搜索引擎無法很好支持的。

“ 如果涉及到一些比較主觀的問題，夾雜在工作和生活之間比如創意相關的場景，我對 AI 的用法是：要的不是輸出，而是輸入。”

“ 我會把和AI一來一回對話的過程當成一種 ‘ 思考實驗 ’。”

“ 比如我會先描述一個問題或想法，看它怎么回應，再反復重啟這輪對話，不斷修改 Prompt，逐漸逼近我要表達的東西。前幾輪輸出的結果哪怕很差，我也能接受。”

“ 一般平均情況下，可能需要輸入 10 輪才能得到自己想要的結果。之所以會超過 10 輪，是因為想法一開始是很模糊的，而討論過程中又會不斷產生新的點。有時候我會發現一些自己之前完全沒有想到的東西。這是在對話中被激發出來的。但當這些新的點加入之后，又會產生新的模糊之處，所以這個過程會不斷延伸。”

“ 直到我把 Prompt 修改到一個程度，使得 AI 的回答足夠接近我真正想表達的東西，說明我對這個問題或想法已經想得足夠清楚，表達也足夠準確。”

“ 這時我其實也不會去用它給出的答案，只會拿走最后寫出來的 Prompt，一般來說，這個 Prompt 會分成兩部分：一部分是我想要什么，另一部分是怎么驗收它。然后，用畫圖、原型設計、用戶調研等方式來實現我的想法。”

“ 至于AI給我的那些具體建議，比如AI可能說 ‘ 基于我們剛才討論的內容，你可以這樣設計，或者在這個界面上做這樣的調整 ’，這些我基本不看。”

“ 所以在這種場景下，如果說的是 ‘ 結果的采納率 ’，那基本是 0。不過這種場景在創意工作的使用頻率非常高。”

事實查詢和靈感探索可以說是 AI 場景的兩個相反的端點，也就呈現出采納率的極大區別，“ 總體來說，信息越 ‘ 薄 ’ ，也就是越簡單、越偏事實型的內容，采納率就會越高；越主觀的內容，采納率就會更低。”

John 對 AI 的采納相比普通用戶是克制很多的，因為在他看來，大語言模型生成的內容本質上只是一種觀點，是對很多觀點的一種抽象總結，而不是真理，“ 我從來不會把它當成一種 ‘ 真理機 ’，不會覺得它說出來的東西天然就是對的。對我來說，它更像是一種非常廉價地獲取一個視角的方式。”

降低期待其實更有利于提升采納率，很多 AI 輸出未被采納，除了技術問題，也經常和使用方式不當或者期待過高有關，“ 用戶對大模型理解越少，反而期待越高。尤其是如果把它當成一種 ‘ 真理機 ’，也就是 ‘ 一次提問就能把答案完善地給出來 ’，就很容易出現極端的情況：要么全部采納，要么完全不采納，或者直接覺得它沒有什么用。”

“ 關于使用方式不當，比如在寫 Prompt 的時候，其實很多人自己都沒有把問題想清楚，沒有經歷反復迭代的過程。很多時候他們給出的需求非常抽象，既沒想清楚要什么，也沒想清楚怎么驗收。這種情況下，其實很難判斷輸出質量，因為連評價標準都沒有。”

“ 寫 Prompt 還是一種挺難的能力，而且是需要花時間的，但很多人不太愿意花這個時間，他們會把這件事當成一個 One-Shot 的過程。” “ 即便現在的大模型產品在不斷積累用戶記憶，也沒法讓模型很準確地判斷用戶意圖，更何況模型還經常引用不相關的記憶。”

“ 還有另外一個問題，是記憶本身解決不了的。”

“現在的 AI 記憶更多是 ‘ 事實型記憶 ’，而不是 ‘ 行為型記憶 ’，最多是在缺少上下文的時候，幫用戶補充一點背景信息。但很多用戶的問題其實不是缺少背景，而是表達本身。如果用戶從一開始就說不清楚自己的需求，那模型就算記住再多也沒用。”

“所以，更理想的情況其實是 ‘ 行為型記憶 ’，比如模型能記住這個用戶經常會漏掉什么信息，或者表達上有哪些習慣，目前我還不確定哪個模型具備這種能力。如果沒有的話，過度依賴歷史上下文，反而可能讓體驗越來越差。”

多去探索 AI 生成的新玩法其實也能提高采納率，“ 這其實就是探索 AI 產出在一些不同場景的可能性。同樣的內容用在不同場合確實可以發揮出不同的價值。比如生成視頻用作內容消費的采納率，和生成視頻用作用戶調研的采納率，可能在前者被淘汰的內容可以用在后者場景里。”

“ 對于近期大火的 Seedance 2.0，我也有一個比較感興趣的場景：比如 Figma 的交互原型可能都不需要做，只需要準備幾張關鍵畫面，然后讓視頻模型生成一個 ‘ 用戶在使用這個產品原型 ’ 的視頻，再把這個演示視頻拿給別人看。這樣別人看到的是一個動態的演示過程，而不是幾張靜態圖。對于早期測試來說，這種方式其實更容易理解。”

“ 尤其是在游戲領域，這種方式可能很有價值。比如游戲開發里有一個概念叫 ‘ 垂直切片 ’：開發團隊會把核心玩法和一個關鍵場景做成一個可玩的版本，然后拿這個去做融資或者找發行商。但其實在更早期階段，很多驗證完全可以用視頻來完成，甚至不需要真正開發。”

“ 我印象特別深的一個案例是 TikTok 上曾經很火的一個游戲概念叫《 Bird Game 3 》，當時很多短視頻都在傳播，看起來像一個真實存在的游戲，但后來發現它根本不存在，只是大家基于一個梗想象出來的 ‘ 虛構游戲 ’。很多用戶其實是在 ‘ 云游戲 ’，看視頻覺得好笑就會轉發。這種傳播本身就已經驗證了這個游戲創意具有傳播性。對于現在很多高度依賴傳播屬性的游戲來說，用視頻生成來做這種早期驗證，其實是一種非常有效的方法。”

如果要再深入到交付階段，則涉及界面設計、原型開發等場景。“ 界面設計過程主要涉及圖像素材的生成，采納率大概是 50%，大部分生成的圖像是不可用的。”

“ 至于是否需要做后期修復，很難一概而論。因為這類內容覆蓋的范圍比較廣，比如在設計的不同階段，插圖的需求也不一樣，需要修復的程度也不同。舉一個比較具體的例子：如果我讓它生成一個像素風格的 icon，那AI生成的幾乎是永遠不可用的。因為像素風 icon 的核心是每一個 Pixel 都非常清晰、非常規則，而模型生成出來的本質上是渲染的一整幅圖，只是 ‘ 看起來像 ’ 像素風。它的邊緣不是真正的像素結構。所以像這種需求，采納率基本就是 0。” “ 我一般會把 AI 生成的圖拖到 Figma 或 Illustrator 里，再自己重畫一遍，AI 圖更多是作為一個參考底板。”

“ 如果是用作演示內容的配圖，大概也是 50% 的采納率，比如 Placeholder 型的插圖，只要整體風格大體能接受，其實就可以采納。”

“ 如果是在實際生產中，已經把 AI 整合進一個自動化 Workflow ，那生成的內容基本都會被采納。”

“ 當然，在生產級工作中，主要的界面設計工具還是 Figma，而圍繞 Figma 的整個工作流程，目前沒有任何一個其它工具能在關鍵環節上做到生產級別的可用生成，比如設計系統、具體界面的設計等。”

“有些產品會號稱可以做設計系統，也可以自動生成界面，能把流程跑通并做到生產級別。但這些產品往往脫離了 Figma 生態。對我來說，這其實沒有意義，因為我最終還是要在 Figma 里完成很多后續工作。它們最多只能在一種情況下有用：對界面要求不高，或者是讓一個完全不懂界面設計的人快速做出一個 ‘ 看起來還行 ’ 的頁面，用來達到一個非常低的基礎標準時。”

Figma 本身其實也在逐漸加入一些 AI 或 Agent 功能，比如 “ Figma Make ”，對此 John 的期待也不高，“ 我基本不用。我會用的更多還是一些比較傳統的或更接近 Machine Learning 的功能，比如移除背景、向量化功能等（ 比如輸入一張普通圖片，輸出一張矢量圖，這樣原本不能修改的圖片就可以修改了 ）。”

在界面設計以外，有時候 John 需要把一些想法快速做成原型，比如一個 Web Demo，這樣在和前端、后端溝通時，可以更清楚地表達視覺、數據關系等需求，“ 不然僅靠設計師的語言，其實他們很難想象具體是什么樣子。”

“ 如果使用一些通用型 Agent 或代碼類 IDE 來實現，采納率是非常高的。”

“ 畢竟我的要求是只要能演示效果，不太在意它是否能上生產環境，也不太在意代碼質量或數據安全問題。這種原型基本就是一次性的 APP（ Disposable APP ）。” “ 但會根據原型的復雜程度有所區別。有的原型需要嘗試很多次，而且迭代結果不是線性的過程，只想微調局部元素卻導致整個頁面布局完全改變，這種情況其實一直都存在，不管用什么 AI 產品。當然最終的結果基本都會被采納，畢竟要求不高。”

還有一個比較特殊的場景，要求會更低一些，就是 John 的個人項目開發，“ 很多時候是用部署在純本地環境的模型，這時不需要考慮數據安全問題。在這種情況下，和原型開發有一定相似性，對可靠性的要求也不高，只要能跑起來就可以。”

“ 比如我會根據自己家庭的需求做一個記賬軟件。因為我發現市面上的很多記賬軟件，其實都不能完全滿足我的需求，總是缺一些我需要的功能。”

” 而且，這個軟件不止我一個人在用，還需要讓家庭里的其他人也能用，所以把這個應用部署在了自己家的網絡，相當于是在內網部署一個小型業務系統，這種級別的項目基本上可以完全用 AI ‘ Vibe ’ 出來，我只負責提需求。” 在界面設計中，AI 的視覺理解瓶頸目前還很明顯，“ 任何想把設計往上提升比如加入風格、加入自己對界面的理解的需求，AI 其實都做不到。”

“ 主要問題是調整成本非常高。一種情況是，比如只讓它把某個按鈕往旁邊挪兩個 Pixel，結果整個頁面的布局都會發生變化。”

“ 另一種情況是表達需求的成本很高。很多設計需求其實很難用語言準確表達，比如希望頁面有一些孟菲斯設計風格，大語言模型往往會用一種非常膚淺的方式去理解這種概念。比如它會理解為：孟菲斯風格就是大量鮮艷的顏色，比較突出的幾何形狀，輪廓明顯的圖形。然后，它就會把整個界面鋪滿各種彩色元素，看起來非常幼稚。”

“ 相比之下，在我腦子里的想象，可能只是一些很細微的調整：某些元素的顏色要更鮮亮一點，顏色選擇要更大膽、更跳躍；或者讓頁面的輪廓線更加明顯一些。”

“ 我目前試過的很多模型，沒有一個真的能理解這些東西，而且做界面生成的Token 成本通常也比較高。很多時候，如果我把時間花在和模型反復解釋這些需求上，還不如自己直接在設計工具里試幾種方案，很快就能得到結果。”

“ AI 對界面的理解，很難做到結構化地拆解再理解再生成，更多是直接給你一個整體性的效果。”

“ 有一個場景我也一直比較期待：在設計早期，只有一些風格關鍵詞，再加上一個很粗略的結構草圖，我希望有一個工具能把這些信息結合起來，模擬出一個可能的界面，這樣可以幫助我們在早期確定視覺方向。但目前沒有產品能做到這一點。”

“ 當然，如果你讓它生成一個 Dashboard，這是結構性非常強、功能性強于美術表達的界面類型，模型其實是可以做出來的。”

“ 但又會出現另一個問題：它生成的界面往往不遵循你的設計系統。所謂設計系統，其實就是一整套規范。比如界面里的顏色、線條粗細、間距、邊框寬度等，通常不會直接用具體數值標注，而是用變量來定義。比如邊距可能是 1px、2px、4px，或 S、M、L 這樣的等級，圓角也可能是 2%、4%、6% 等不同級別。”

“ 如果讓生成式工具來做界面，它雖然能生成看起來類似的界面，但實際上用的都是具體數值，而不會調用你定義好的變量。從設計系統的角度來說，它并沒有真正遵循你的規范。”

“ 如果模型不能直接使用我的設計系統，我基本不會去用。原因很簡單：后續的調整成本會非常高。”

“ 比如現在覺得整個頁面的矩形圓角太硬了，想把圓角從 2 Pixel 改成 4 Pixel。在設計系統里，只需要改一個變量，整個界面里的相關元素都會一起更新。但如果界面沒有使用變量系統，我就必須一個一個去找頁面里的矩形，把它們的圓角逐個改掉，這就變成了完全手動的工作。”

“ 目前我還沒有發現一個 Figma 工作流能解決這個問題。這個問題的技術難度其實未必很高，可能只是沒有找到一套合適的工具流或者工具鏈能夠實現它。”

因此，總體而言，以設計場景為典型，其實在除了代碼生成以外的大部分場景中，人們都感覺 AI 的實際采納率并沒有特別高。客觀因素比如模型能力有限、記憶類型不完備等自然很重要，主觀因素特別是不合理的期待卻較少為人注意，如果大模型不是 “ 真理機 ” 而是 “ 觀點機 ”，那它本質是面向未來的，幻覺是基本屬性，知識再豐富，也不是可靠的百科全書，執行能力再強，驗收環節也必不可少，這一點倒和人類沒太大區別。

現實層面看，近幾個月 SaaS 市場被全面看空，在 John 看來，這更多還是市場對于 “ SaaS 泡沫 ” 的情緒波動，有不少恐慌的成分，有點非理性。

“ 一方面，人們都覺得 AI 很有前景，敘事也很龐大，但另一方面，很多人心里都有點虛，不確定它的潛力邊界。”

“ 我之前聽過一句話，感覺挺有道理的：如果你現在去問大家，有多少人覺得 AI 可能存在泡沫，其實有不少人是有這種擔心的。但如果回看 2000 年互聯網泡沫的時候，當時其實很多人并不覺得有泡沫。所以換個角度看，如果現在已經有這么多人在擔心泡沫，反而說明可能離真正的泡沫階段還有一點距離。因為這至少說明整體市場還是比較謹慎的。”

在過去幾年，問答場景和人類監督的 Agent 場景下，Token 消耗一般不為人過度關注，但在龍蝦時代，24 小時在線燒 Token 的龍蝦直接點燃了大家的 Token 焦慮。

王鯨表示，“ 傳統對話式 AI 一句話消耗一兩千 Token，現在用龍蝦隨便一句話就 20 萬 Token，就算和其他 Agent 場景相比也是消耗更大的，比我寫代碼用的 Qwen Coder 高了很多倍。”

“ 究其原因，還是因為 Skill 裝的多，工具調用的多。畢竟長了手，工作范圍廣，比起純文本操作，基礎消耗自然高了很多。”

“ 而且現在很多操作不是軟件化的、模塊化的，而是 AI 現場思考以后去操作的，類似于每次按按鈕都全屏截圖識圖一次，每一次操作都要思考一次，能效比很差，就像大炮打蚊子。”

用得少怕落后，用得多怕看賬單。

從這個節點開始，AI 輸出的采納率這個 “ 房間里的大象 ”，或許會越來越被人們在意。