Ed Zitron 對 AI 的整體判斷是近兩年科技圈最容易被轉發(fā)的觀點之一。他批評AI營銷話術、企業(yè)為概念買單、估值和真實收益嚴重脫節(jié)這些批評放在很多發(fā)布會場景里確實成立。但我做完一批AI編程、AI Agent、AI應用開發(fā)的落地測試之后越來越覺得至少在“AI沒有真實價值”這個方向性結論上Ed Zitron 的判斷是錯的。把AI當成一個懸浮在PPT里的概念確實看不到價值把AI當成一組有明確邊界、可驗證、可迭代的工具價值會變得非常具體。這篇不是要全面否定一位評論者而是要把“AI到底有沒有用”從一個情緒問題改造成一個工程問題。1. 為什么“AI是泡沫”很流行卻解釋不了大量真實工具在跑1.1 批評者的素材來源大多停留在發(fā)布會和財報Ed Zitron 式的批評能引發(fā)共鳴是因為他提供了很多看起來特別真實的素材一家公司改個名字股價就漲、一個產(chǎn)品發(fā)布會講了一堆愿景但沒有具體性能、一個平臺投入巨大卻看不到用戶留存。這些話術在資本市場上確實大量存在很多企業(yè)高管也確實說不清楚自己為什么要上AI項目。但這里有一個容易被混淆的地方資本市場的現(xiàn)象不能直接等同于技術能力。估值漲跌反映的是參與者的預期和情緒不是模型在代碼補全、文本抽取、工單分類、知識庫問答這些具體任務上的實際輸出質量。如果想要判斷AI是不是泡沫應該看生產(chǎn)環(huán)境里的調用日志、錯誤率、人工修正量、用戶實際使用時長而不是只看新聞標題。我最早也容易被這類批評帶偏。后來連續(xù)參與幾個內(nèi)部AI項目才發(fā)現(xiàn)那些在輿論上沒有影響力的工具可能正在每天處理幾萬條工單。它們沒有開發(fā)布會不叫“大模型產(chǎn)品”只是一個很小的AI服務嵌在審批流里輔助分類但價值是能算出來的。1.2 “估值貴”和“能力假”是兩件完全不同的事很多人把“AI創(chuàng)業(yè)公司估值過高”直接理解成“AI技術上做不到”。這是兩回事。一個領域可以同時具備兩個特征資本層面有泡沫技術層面有真實進展。20世紀90年代互聯(lián)網(wǎng)也有大量泡沫但網(wǎng)絡基礎設施、在線交易、信息檢索這些能力后來都被證明是真實價值。批評者如果只看到泡沫就會錯過一個更重要的問題泡沫破掉之后哪些能力會留下來?，F(xiàn)在可以觀察到的一個趨勢是AI基礎設施、AI編程、AI Agent、私有化部署、AI數(shù)據(jù)分析這些方向不是靠發(fā)布會撐起來的而是靠開發(fā)者一遍遍調用跑出來的。一個工具如果連續(xù)幾個月都有穩(wěn)定的調用量那它一定解決了某些人的某些問題。1.3 被大量評論忽略的中間層AI不只有對話機器人公開報道里AI總是被塑造成一個全知全能的通用助手。但在真實生產(chǎn)環(huán)境里AI最常見的形態(tài)是小任務、窄場景、低姿態(tài)。比如用戶反饋自動分類客服對話摘要合同條款信息抽取代碼注釋和單測生成商品標題改寫會議紀要素材整理這些場景不會出現(xiàn)在科技媒體的頭條里因為它們不夠性感也不具備“顛覆一切”的戲劇沖突。但恰恰是這些任務讓AI在很低的容錯成本下產(chǎn)生了明確收益。這里的關鍵不是模型能不能像人一樣思考而是流程設計者能不能找到那些“輸入輸出穩(wěn)定、重復度高、錯誤可修正”的任務。注意判斷AI有沒有用不能只看一個演示視頻也不能只聽一篇評論文章。正確做法是選一兩個具體任務跑完幾十條真實樣本再下結論。2. 批評者最常犯的錯把一次糟糕的演示當成全部結論2.1 用錯誤的任務去測試文本生成模型很多針對AI的批評測試方式本身就存在問題。有人拿一個沒有聯(lián)網(wǎng)能力、沒有內(nèi)置實時數(shù)據(jù)接口的模型去問“今天北京的天氣怎么樣”得到錯誤答案后就宣布“AI是弱智”。這其實是把信息檢索任務和語言理解任務混在了一起。大語言模型本質上是概率性的文本生成器它既不是一個完整知識庫也不是搜索引擎。如果你需要實時天氣應該給它查詢天氣的API如果你問的是私有知識庫內(nèi)容應該先接RAG如果你要算精確財務數(shù)據(jù)應該用代碼執(zhí)行引擎而不是讓模型直接心算。這就像一個測試者要求一把錘子去擰螺絲失敗后得出結論“所有工具都沒用”。問題不在模型而在需求定義。2.2 單次主觀體驗好或壞不能替代統(tǒng)計驗證AI輸出存在隨機性。同一個問題兩次問可能得到不同的表述甚至有個別錯誤。批評者很容易抓住一次離譜的回答支持者也很容易展示一次驚艷的回答。這兩種方式都是典型的采樣偏差。我在做評測時一般會這樣做把temperature調到一個合適水平固定模型版本用同一條輸入反復跑20到50次再統(tǒng)計錯誤類型。很多看似“智力不夠”的問題拆開來看其實是兩類第一類答案內(nèi)容是對的但格式不滿足要求。第二類關鍵字段出現(xiàn)幻覺屬于事實錯誤。第一類通過約束輸出格式、增加解析校驗就能解決。第二類需要加檢索、工具、人工兜底或者調整任務邊界。如果批評者把所有錯誤都歸結為“AI不行”就錯過了非常具體、可修的工程問題。2.3 拿“不能替代人”去否定“不能輔助人”另一個常見的邏輯跳躍是拿“AI不能自動完成整個崗位的工作”來否定AI的價值。這個標準定得太高了?，F(xiàn)實中幾乎沒有任何軟件能直接替代一個完整崗位但幾乎每個軟件都可以提升某個環(huán)節(jié)的效率。拿客服場景來說AI客服單獨回答用戶問題確實可能只有70%的準確率如果讓AI直接面對所有用戶會產(chǎn)生災難性體驗。但如果換一種用法讓AI先處理重復度高、規(guī)則明確的前置問題再把復雜問題轉給人工效果就完全不同。它沒有替代客服但減少了客服的重復勞動讓有經(jīng)驗的客服能把時間花在真正需要判斷的溝通上。AI編程也一樣。它不能自己理解一套亂糟糟的業(yè)務需求并完成系統(tǒng)重構但它可以幫你生成樣板代碼、補一個單元測試、解釋一個陌生報錯、把一段長函數(shù)拆成更小的模塊。這些收益不需要AI達到“全自動程序員”水準只需要比“從零開始寫代碼”少花十分鐘就已經(jīng)是正向收益。3. 正確判斷AI有沒有用先給任務分類再定驗收指標3.1 不是所有任務都適合用大模型最容易翻車的AI項目往往是從“這事看起來很適合”開始而不是從“這事在工程上可以被校驗”開始。判斷任務適不適合用大模型可以先看幾個條件任務描述是不是清晰輸入輸出是否可以被結構化記錄錯誤是否容易被發(fā)現(xiàn)和修正數(shù)據(jù)量是否足夠支撐效果評估業(yè)務能否容忍一定比例的錯誤或者是否有兜底機制如果這些條件大部分成立項目就值得小規(guī)模嘗試。如果任務本身模糊、沒有固定輸入格式、結果也無法評判那無論用多少層語義推理都會變成黑箱。3.2 任務分類是選型的第一步在實際落地時可以把任務粗略分成三類A類任務信息抽取、格式轉換、標題生成、摘要、關鍵內(nèi)容歸類、代碼片段輔助。這類任務通常只需要模型在給定文本上做轉換輸出容易驗證錯誤成本低適合直接使用大模型。B類任務專業(yè)問答、數(shù)據(jù)分析、企業(yè)知識庫服務。這類任務需要接入外部知識庫、數(shù)據(jù)庫或工具不能單靠模型記憶。它同樣可行但工程復雜度明顯上升。C類任務關鍵業(yè)務決策、高精度計算、實時狀態(tài)判斷、需要嚴格審計的流程。盡量避免讓純模型直接完成最終判斷應該把模型結果當作草稿由規(guī)則、程序或人來復核。3.3 最小驗證實驗怎么設計如果條件允許我更建議做一個最小可行實驗而不是先爭論“AI有沒有用”。實驗流程大概是選擇一條真實業(yè)務流程中的具體任務。收集20到100條歷史輸入最好覆蓋不同寫法、不同長度、不同風格的樣本。由業(yè)務方先給出參考輸出作為質量基準。先用規(guī)則、模板或人工方式記錄基線耗時和正確率。再用大模型對同樣樣本生成結果。讓人對輸出做盲評判斷結果是否可用、需要改多少、單條能節(jié)省多少時間。為什么要用20條以上因為2條樣本只能給你一個方向性感覺覆蓋不了輸入多樣性。為什么一開始不用1000條因為標注成本太高而且還不確定方案是否值得投入。先用小樣本把方向走通再擴大樣本量是比較穩(wěn)妥的路徑。3.4 驗收指標要提前定好很多AI項目失敗不是模型調用失敗而是沒有在開始前定義“什么叫做成功”。建議至少記錄以下幾個維度指標含義判斷口徑可用率輸出不需要修改或僅輕微修改就能使用的比例由業(yè)務方按自己標準打分人工修正量每個輸出平均需要改多少字或多少字段修正量越小自動化價值越高單條耗時從調用到返回結果需要多少秒要和業(yè)務流程可接受時延對比失敗率輸出空、超時、解析失敗的占比生產(chǎn)環(huán)境必須記錄單條成本包括模型調用、人工審核、重試費用的總成本不計失敗和審核的成本沒有意義這些指標不能拍腦袋。如果某個任務人工處理一共需要兩分鐘AI處理后還需要業(yè)務人員改三分鐘那這個項目就不該繼續(xù)。好與不好要看數(shù)據(jù)說話。注意設置temperature、max tokens、重試次數(shù)等參數(shù)時一定要先確認線上使用的模型版本和評測時一致。否則你辛苦調好的效果可能換一個模型版本就完全變了。4. AI Agent、AI編程和模型部署從 Demo 到生產(chǎn)的細節(jié)4.1 Demo能跑通不代表任務能閉環(huán)很多AI項目在Demo階段表現(xiàn)非常好。給一段輸入模型輸出一段像模像樣的結果所有人都很高興。但放到生產(chǎn)環(huán)境后問題才會逐漸暴露輸入文檔可能帶掃描噪聲用戶可能傳了一個十幾頁的PDF某個字段可能為空網(wǎng)絡請求可能超時返回結果可能被截斷。以AI編程工具為例單個函數(shù)的自動補全可能讓人驚喜但放到真實項目里還要面對依賴版本沖突、編譯錯誤、測試失敗、代碼風格不一致等問題。工具能幫你補全一段函數(shù)但它不能保證這段函數(shù)能融入現(xiàn)有架構。所以我一般建議任何AI能力在上線前都要拆成兩層看第一層單次能力是否可用。第二層連續(xù)跑20次甚至100次后錯誤率、穩(wěn)定性、異常處理是否可接受。單次能力像一道閃光連續(xù)跑完一批真實輸入才像一盞穩(wěn)定的臺燈。你要的是燈不是閃光。4.2 生產(chǎn)環(huán)境需要盯住的核心參數(shù)模型部署和API調用不是把請求發(fā)出去就完事了。以下是幾個最容易被忽略、但對結果影響很大的參數(shù)參數(shù)影響常見處理思路模型版本不同版本能力差異很大測試、灰度、生產(chǎn)必須鎖定同一個版本temperature影響隨機性抽取、分類任務調低創(chuàng)意寫作可稍高max tokens輸出太長會截斷太短不夠用根據(jù)任務最大輸出預留余量超時時間請求阻塞會拖垮流程按任務耗時給合理超時避免無限等待重試次數(shù)網(wǎng)絡抖動可能造成偶發(fā)失敗設置重試但要防止雪崩并發(fā)數(shù)同時請求太多會被限流小樣本測試時不要一上來就開高并發(fā)prompt 版本每次修改都會改變輸出建議對prompt做版本管理輸出格式模型可能不按格式來用JSON Schema或正則校驗失敗重試這些參數(shù)不存在統(tǒng)一的“最佳配置”。每類任務的合理值不同。比如代碼生成任務適合稍微高一點的temperature因為它需要多樣性合同信息抽取任務則應該盡量讓輸出固定所以temperature要低。4.3 AI Agent的評價不能只看最終結果AI Agent 比單純的大模型調用更復雜。它可能會拆解任務、調用工具、讀取結果、再次決策形成多輪操作。這時如果只看它最終返回的結果你很難判斷問題出在哪一步。建議對Agent的每次運行都記錄以下信息任務輸入和預期結果Agent拆解出的步驟列表每一步調用了什么工具工具返回了什么內(nèi)容每一步耗時和token消耗最終結果是否滿足預設格式連續(xù)多次運行的成功率如果Agent經(jīng)常失敗先不要急著換更大的模型先看日志里哪一步出錯。很多失敗來自工具參數(shù)不對、搜索返回內(nèi)容不相關、輸入文本太長、Agent在步驟中陷入循環(huán)。這些問題通過增加最大步數(shù)上限、優(yōu)化工具描述、補充錯誤提示就能解決。5. 什么時候批評是對的什么時候批評會誤導選型5.1 Ed Zitron式批評在哪些場景成立Ed Zitron 的批評并不是完全沒有道理。如果一個企業(yè)的立項理由是“別人都在做AI”那么它大概率會失敗。如果一個項目不定義業(yè)務指標只看模型演示效果那么它也確實可能成為成本黑洞。如果管理者相信AI可以完全替代有經(jīng)驗的專業(yè)人員而不考慮錯誤兜底這類項目翻車只是時間問題。在這些場景里批評者不是無聊而是在給過熱的市場降溫。AI行業(yè)確實有太多只是為了故事而存在的產(chǎn)品?？吹竭@些項目翻車并提醒大家謹慎是有價值的。5.2 但“AI公司有泡沫”推導不出“AI工具沒有價值”Ed Zitron 那類觀點最值得商榷的地方在于把資本市場上的泡沫等同于技術能力上的虛妄。很多AI公司估值高是因為資本集中在頭部玩家手里不是因為每一家大模型公司都能兌現(xiàn)所有承諾。同樣很多AI項目失敗是因為選錯了任務、定義不清指標、沒有工程兜底不是因為底層模型完全沒用。我在使用AI編程工具時大量樣板代碼、重復性測試、格式轉換工作確實被明顯壓縮了。這個收益不需要依賴某一家公司的股價上漲。只要模型能穩(wěn)定完成一個具體任務哪怕它有明顯邊界它的價值就是可以被測量的。評論者可以嘲笑PPT里的宏大敘事但不應該忽略代碼編輯器里實實在在的補全建議。5.3 更準確的說法是什么如果讓我把“Ed Zitron Was Wrong About AI”翻譯成一個更精確的觀點我會這樣說他把“很多AI公司在浪費錢”和“AI沒有創(chuàng)造真實價值”混成了一個判斷。前一句話在不少公司身上成立后一句話在大量實測任務里不成立。一篇好的技術批評應該指出技術被夸大的地方也承認技術已經(jīng)改變的部分。如果批評最后變成一個全稱否定它就會誤導一批本來能從AI輔助中獲益的普通用戶和中小企業(yè)。他們可能因為一篇文章拒絕嘗試一個實際能提升效率的小工具。5.4 別被輿論鐘擺帶著跑技術輿論經(jīng)常在兩個極端之間擺動。今天說AI萬能明天說AI是騙局。對于長期做實操的人來說這兩種姿態(tài)都是噪聲。正確的做法是回到自己的任務里用一組真實的輸入、明確的指標、可接受的人機協(xié)作方式去驗證它到底適不適合自己。資本市場的情緒會波動模型版本會迭代但一個穩(wěn)定跑通的任務閉環(huán)不會因為一篇評論消失。6. 與其爭論AI有沒有用不如跑一輪樣本測試6.1 一個團隊可以快速執(zhí)行的驗證思路如果現(xiàn)在你的團隊還在因為“AI到底有沒有用”爭論不休我建議花三到五天做一輪最小的驗證。不要一開始就規(guī)劃一個大型AI平臺先選一條具體的、重復度高的業(yè)務動作。比如把客服對話整理成結構化摘要把銷售線索描述歸類到對應行業(yè)把代碼補全工具接入編輯器試用把產(chǎn)品評論自動生成簡短標簽然后按下面這個節(jié)奏推進第一天收集20到100條真實歷史數(shù)據(jù)。第二天讓業(yè)務人員給出參考輸出建立基礎答案。第三天用規(guī)則或人工跑一遍基線記錄耗時和成本。第四天調用大模型接口或部署一個開源模型嘗試生成同樣輸出。第五天讓業(yè)務人員盲評同時記錄成本和修正量。這一輪結束后你不需要看任何人的觀點文章也能知道AI在這個任務上是否值得投入。6.2 成本不能只算API費用很多人在評估AI成本時只算顯式費用比如每次調API花多少錢或者買顯卡花多少錢。但真正落地時還有隱性成本讓業(yè)務方寫參考輸出要時間產(chǎn)品經(jīng)理調prompt要時間開發(fā)人員接接口和寫校驗邏輯要時間線上出現(xiàn)異常時人工排查也要時間。所以成本測算至少應該包含以下幾塊模型調用費用或本地部署資源數(shù)據(jù)準備和輸入清洗成本Prompt開發(fā)和版本維護成本輸出格式校驗、錯誤重試處理成本人工審核或修正成本線上日志、監(jiān)控和問題修復成本把這幾項全部攤到單條任務上再對比原有人工處理的單位成本結論才有說服力。6.3 什么情況下可以說“這條任務真的有效”當滿足以下幾個信號時基本可以認為AI在任務中產(chǎn)生了實際價值連續(xù)跑完一批真實樣本后可使用率達到業(yè)務方接受的范圍。人工修正每條結果所花的時間明顯少于從零處理同樣任務的時間。單條總成本低于原有處理成本或者雖然略高但處理速度換來了更大價值。錯誤類型可以追溯并且能通過規(guī)則校驗、更清晰的prompt或檢索增強來降低。流程在連續(xù)運行一段時間后仍然穩(wěn)定不會因為個別異常輸入直接崩潰。如果這些信號一條都不滿足那批評者的觀點在這個具體項目里就是成立的。你就不該繼續(xù)投入更不要強行包裝概念。這時果斷停下來反而是明智的決策。6.4 最終判斷要落到樣本和指標上我看過太多討論AI價值的場合最后都變成立場之爭支持的人反復強調某個驚艷案例反對的人不斷引用某個翻車現(xiàn)場。這兩種討論都不能幫一個具體業(yè)務負責人做出決定。真正能決定“要不要用”的只有你自己的場景、樣本和指標。評論文章可以提醒風險發(fā)現(xiàn)容易踩坑的地方但它替代不了你對真實輸入的處理。Ed Zitron 那些批評給我最大的提醒是不要為了一個宏大概念去投入資源。反過來他對AI價值全盤否定的趨勢也會讓一部分人在可能有效的任務前浪費一次低成本驗證機會。與其說服別人不如花兩天時間收集100條真實樣本跑一輪評測。數(shù)據(jù)和結果是爭論里最有說服力的東西。