最近總有人問我企業(yè)搞AI落地到底該聽誰的業(yè)務部門說我要上大模型算法團隊說有現(xiàn)成API直接調(diào)老板說必須私有化部署運維反問算力預算從哪里出。七嘴八舌吵到最后真正能把業(yè)務問題翻譯成技術方案、又把技術路線拆回業(yè)務價值的人往往是那個不容易被定義的角色——AI應用架構師。這不是新瓶裝舊酒。傳統(tǒng)軟件架構師解決的是系統(tǒng)怎么穩(wěn)、怎么快、怎么擴展AI應用架構師面對的問題多了一層不確定性模型輸出不可控、效果評測沒有唯一標準、Token消耗直接變成現(xiàn)金。智能化時代企業(yè)競爭力的差距恰恰就體現(xiàn)在誰能把這些不確定性變成可管理、可迭代、可衡量的工程能力。這篇文章我不講虛的就從AI應用架構師的實際工作出發(fā)聊一聊怎么通過技術決策、系統(tǒng)設計、組織協(xié)作來真正提升企業(yè)的競爭力。1. AI應用架構師是干什么的不是換了個名字的軟件架構師1.1 職責光譜從技術選型到業(yè)務翻譯AI應用架構師的日常遠不是畫兩張架構圖、選個模型接口那么簡單。我在幾個不同階段的AI項目里待過最深的感受是這個角色的核心工作其實是一條連續(xù)光譜。光譜的一端是技術深度。你得清楚大模型的推理機制、上下文窗口的邊界、向量檢索的召回率為什么忽高忽低、微調(diào)和RAG各自適用什么場景。另一端是業(yè)務敏感度。你得能走進業(yè)務部門聽懂他們說的幫我把客戶投訴自動分類其實不是分類而是希望找出那些可能導致退費的隱藏風險點聽懂給我做個智能助手并不是要一個聊天機器人而是要把客服團隊人均處理時長壓下來30%。這兩個方向缺一個都會出事。只懂技術不懂業(yè)務做出的系統(tǒng)會變成一個技術玩具——模型效果演示很炫但業(yè)務上根本用不了只懂業(yè)務不懂技術會被算法團隊和供應商牽著走買回來一堆用不上的算力和平臺最后變成沉沒成本。我在某制造企業(yè)做AI應用規(guī)劃時生產(chǎn)部門提的需求是用AI做產(chǎn)品質(zhì)量檢測。乍一聽這是典型的計算機視覺項目要上圖像識別模型。但深入調(diào)研后發(fā)現(xiàn)真正的痛點是產(chǎn)線換型時參數(shù)調(diào)整依賴老師傅經(jīng)驗新員工容易調(diào)錯導致批量不良。最終我們優(yōu)先做的不是視覺檢測而是一個基于歷史參數(shù)數(shù)據(jù)和工藝文檔的知識輔助系統(tǒng)把老師傅的參數(shù)調(diào)整邏輯沉淀成推薦引擎。這個項目上線后換型時間縮短了四成比先做視覺檢測帶來的收益更直接。這就是AI應用架構師的價值——先幫企業(yè)找到真正值得用AI解決的問題再決定怎么用AI解決。1.2 為什么很多企業(yè)AI項目死在架構前夜過去兩年我見過太多失敗的AI項目它們的死因高度相似基本都和架構缺位有關。第一種死法叫POC陷阱。老板在行業(yè)大會上看到大模型演示回來要求所有業(yè)務線都出AI方案。各團隊為了證明自己也在擁抱智能化紛紛做了漂亮的Demo智能問答、文檔總結、代碼輔助全都跑通了。但一到生產(chǎn)環(huán)境就傻眼——線上的數(shù)據(jù)格式和Demo里完全不一樣模型回答的準確性沒人敢擔保出了問題不知道找誰。第二種死法叫模型迷戀。團隊覺得只要用上了最強的模型、最長的上下文、最先進的Agent框架競爭力就自動來了。忽略了一件最基本的事AI系統(tǒng)的競爭力不在模型本身而在模型之外的數(shù)據(jù)管道、評測體系、反饋閉環(huán)和運維能力。模型半年一換但圍繞業(yè)務場景沉淀下來的知識庫、標注數(shù)據(jù)、評測集和工具鏈才是別人短期復制不走的東西。這兩種死法的共同點是缺了一個從業(yè)務價值出發(fā)、對系統(tǒng)全生命周期負責的角色。這個角色不是傳統(tǒng)項目經(jīng)理因為項目經(jīng)理不關心技術架構也不完全是算法研究員因為研究員不背業(yè)務指標。AI應用架構師要做的恰恰是在這兩個角色之間補上那塊拼圖。2. 從模型選擇到系統(tǒng)工程AI應用架構的技術決策清單2.1 模型選型的三個真實約束成本、延遲、可控性很多團隊選模型只看榜單上的跑分。真實企業(yè)環(huán)境里模型選型本質(zhì)上是在三個約束之間做權衡成本、延遲、可控性。先說成本。大模型調(diào)用不是一次性采購而是持續(xù)發(fā)生的運營費用。我習慣在方案階段就算一筆賬假設一個客服助手日均調(diào)用2萬次每次平均輸入3000字、輸出500字按Token計費的話一個月開銷輕松到六位數(shù)人民幣級別。這不是小數(shù)目。如果實際業(yè)務量再翻十倍這筆賬就直接決定了這個項目能不能長期活下去。再說延遲。對話類場景用戶還能接受兩三秒的響應但如果在工單自動分類、實時風控這類鏈路上用大模型幾百毫秒的差異都會拖垮主業(yè)務流程。所以架構上必須做分級簡單任務走規(guī)則引擎或者小模型只有復雜語義理解才路由到大模型。這就是常說的模型路由思路——不是所有請求都值得用最強的模型。至于可控性核心問題是數(shù)據(jù)能不能出域很多企業(yè)的業(yè)務數(shù)據(jù)有嚴格合規(guī)要求API調(diào)用這條路直接被封死只能私有化部署開源模型。但私有化不意味著萬事大吉你得自己處理推理優(yōu)化、顯存管理、并發(fā)調(diào)度這些問題。我的建議是在做技術選型之前先列一份約束清單把成本上限、響應時間要求、數(shù)據(jù)合規(guī)邊界、團隊運維能力逐項寫清楚再倒推選哪類模型。我在某金融客戶那邊就是這么做的。最初大家傾向用效果最好的商用API但數(shù)據(jù)合規(guī)評估直接否決了這個方向。后來改為私有化部署開源模型并搭配一套成熟的知識庫檢索方案實際效果雖然比頂級模型差一些但已經(jīng)能滿足業(yè)務要求成本只有原來的三分之一。下面是我常用的一個選型評估表供參考評估維度商用API私有化部署開源模型兩者混合初始成本低高算力采購中單位調(diào)用成本按量計費波動大邊際成本遞減可分級控制數(shù)據(jù)出域風險有無可控效果上限高中高取決于微調(diào)中高運維復雜度低高中適用場景低敏感、效果優(yōu)先高敏感、數(shù)據(jù)合規(guī)大規(guī)?；旌县撦d2.2 RAG不是萬能藥知識問答系統(tǒng)的架構取舍現(xiàn)在做企業(yè)級AI應用檢索增強生成RAG基本是標配。很多團隊覺得RAG就是向量數(shù)據(jù)庫提示詞模板拼一下招兩個開發(fā)就能做。真做起來才發(fā)現(xiàn)坑多得驚人。第一個坑是切分策略。把文檔切成碎片存入向量庫切大了召回不準切小了丟失上下文。法律合同、技術手冊、客服話術每類文檔的最優(yōu)切分方式都不一樣。我見過更隱蔽的問題如果把表格和圖片直接丟給文本解析器信息就丟了回答錯誤率會顯著上升而這在POC階段根本發(fā)現(xiàn)不了。架構上要提前設計多模態(tài)解析管道把PDF里的表格結構、流程圖里的文字關系盡量還原出來。第二個坑是召回質(zhì)量評估。向量檢索的召回率用一兩個例子看不出問題放到全量知識庫上相關性差的片段混進上下文模型的回答反而被帶偏。所以真實的RAG架構不只是檢索-生成兩步還要有重排環(huán)節(jié)以及一個持續(xù)迭代的知識庫更新機制。文檔更新后舊的向量切片要能自動失效或替換否則今天改的報價政策明天系統(tǒng)還在按舊政策回答。第三個坑更本質(zhì)RAG只能解決知識獲取問題解決不了復雜推理問題。比如對比我們和某競品最近三個季度的產(chǎn)品迭代節(jié)奏預測對方接下來會重點打哪個市場——這類問題需要多源信息整合和推斷單純把文檔片段喂給模型效果會很一般。架構上比較理性的判斷標準是這樣的問題有明確答案且答案分布在有限文檔中優(yōu)先用RAG。問題是多步推理、需要多源信息融合考慮用Agent模式模型調(diào)用工具、多輪檢索。問題高度依賴實時數(shù)據(jù)比如庫存、價格、工單狀態(tài)必須在RAG之上接入實時查詢工具。2.3 Agent應用從Demo到生產(chǎn)環(huán)境的復雜度躍遷最近大家都在聊Agent好像不用Agent就落伍了。但從架構師的視角看Agent從Demo到生產(chǎn)環(huán)境復雜度不是線性增長而是指數(shù)級跳躍。Demo階段的Agent只需要證明模型能調(diào)用工具生產(chǎn)環(huán)境你要面對的是工具調(diào)用失敗怎么重試模型理解錯意圖、調(diào)錯了工具怎么辦多輪對話里狀態(tài)怎么管理一個Agent執(zhí)行到一半用戶改主意了任務怎么取消或切換再加上工具本身的權限邊界——如果Agent可以查訂單、改訂單、退款那它就是一個無人值守的高權限操作員萬一指令注入或者理解偏差后果是災難性的。我的建議是生產(chǎn)級Agent架構必須包含三個核心組件第一個是工具注冊與權限中間層。所有工具函數(shù)都必須走統(tǒng)一網(wǎng)關網(wǎng)關負責鑒權、參數(shù)校驗、限流和審計日志。模型不直接觸達后端系統(tǒng)只感知網(wǎng)關暴露出來的能力列表。第二個是狀態(tài)機與人工介入機制。把Agent任務建模成有限狀態(tài)機每個狀態(tài)定義清楚可轉(zhuǎn)移條件。關鍵節(jié)點必須設計人工確認環(huán)節(jié)比如退款、刪除、發(fā)送外部消息這類不可逆操作一律先暫停等待確認。第三個是沙箱與評測環(huán)境。工具調(diào)用鏈路的每一步都要有輸入的完整記錄和輸出的可回放能力。線上出問題的時候能把這個Agent剛才經(jīng)歷了什么完整還原出來否則根本沒法定位是模型錯了、工具錯了還是狀態(tài)管理錯了。3. 落到業(yè)務場景評估、試點與規(guī)模化推廣3.1 場景篩選矩陣哪里先做哪里緩做AI落地最忌諱的是一上來就想全面智能化。我在所有企業(yè)規(guī)劃里都堅持一個原則用矩陣法選場景而不是憑直覺拍腦袋。我常用的篩選維度有兩個業(yè)務價值和落地難度。業(yè)務價值看的是這個場景如果做好了對營收、成本、體驗能帶來多大可量化的改變落地難度看的是數(shù)據(jù)基礎是否具備、業(yè)務流程是否穩(wěn)定、相關方是否配合。拿兩個典型場景對比一下。一個是銷售日報自動生成業(yè)務價值中等數(shù)據(jù)基本都在CRM里落地難度低適合作為速贏項目能快速建立團隊信心。另一個是供應鏈需求預測業(yè)務價值極高但涉及歷史銷售、促銷計劃、外部市場因素、庫存策略等多方數(shù)據(jù)模型效果又依賴數(shù)據(jù)質(zhì)量落地難度很大貿(mào)然上馬容易失敗。我的篩選步驟一般是這樣先組織業(yè)務和技術團隊一起頭腦風暴列出至少20個候選場景。每個場景都寫清楚現(xiàn)狀痛點、期望效果、涉及數(shù)據(jù)、影響范圍、量化收益預估。按價值-難度矩陣打分布挑出快速見效的一兩個場景作為第一批試點。把大而難的場景拆小找到其中的低垂果實。比如供應鏈需求預測難做但熱銷品的缺貨預警可能只依賴少數(shù)數(shù)據(jù)源可以先做。這個步驟的核心是讓團隊統(tǒng)一對做什么的認知。不少AI項目最后爛尾不是因為技術不行而是從一開始大家對做什么、做到什么程度算成功就各執(zhí)一詞。3.2 評測體系沒有評測就沒有迭代我經(jīng)常跟團隊講一句可能有點絕對的話沒有評測體系的AI項目基本等于沒有方向盤的車。因為大模型應用的輸出是開放式的靠感覺效果還不錯是走不遠的。架構上需要三類評測手段并行。第一類是自動化指標評測。對分類、抽取、標簽這類有標準答案的任務可以用準確率、召回率、F1這些指標持續(xù)跑回歸。我在項目里會搭一個每日自動評測的流水線模型或提示詞一改就全量跑一遍測試集避免修好一個問題、帶崩一片問題的情況。第二類是人工評測。對對話質(zhì)量、文案質(zhì)量這類主觀性強的任務需要建立標注規(guī)則和多人打分機制。比較實用的做法是成對比較把兩個系統(tǒng)的回答放在一起讓標注人員盲選哪個更好再通過統(tǒng)計方法算出勝負率。這種方式比單獨打分穩(wěn)定得多。第三類是線上真實效果評測。比如A/B測試里對比舊流程和新AI助手處理同一批工單的首次解決率、平均處理時長、用戶滿意度。這是最終的裁判。我在某零售公司做智能導購時第一版模型在Demo上表現(xiàn)驚艷可上到線上后發(fā)現(xiàn)用戶根本不按Demo的臺詞提問各種口語化、錯別字、中英混搭的表達全來了。后來我們專門建了一個用戶真實提問的回歸測試集每周把線上日志里新出現(xiàn)的疑難問題補充進測試集效果才慢慢穩(wěn)下來。這個測試集不是一次性的它會隨業(yè)務發(fā)展不斷生長成為團隊最核心的數(shù)據(jù)資產(chǎn)之一。3.3 灰度放量與組織推廣的節(jié)奏系統(tǒng)開發(fā)完不等于可以全量上線。AI應用的問題往往是小流量看不出問題全量才爆發(fā)?；叶鹊囊饬x不只是控制風險更是給組織一個適應和反饋的時間窗口。具體操作上我習慣把上線過程拆成四步第一步是內(nèi)測邀請業(yè)務方的幾個核心用戶來試用重點是收集使用反饋和發(fā)現(xiàn)明顯問題而不是追求使用量。第二步是灰度選一個業(yè)務團隊作為試點開放真實數(shù)據(jù)設定明確的觀察指標和觀察周期。比如智能客服先只接5%的會話對比這5%和另外95%在解決率、滿意度、轉(zhuǎn)人工率上的差異。第三步是逐步放量從試點團隊擴展到更多團隊一邊放量一邊監(jiān)控系統(tǒng)表現(xiàn)和用戶反饋有問題隨時回滾。第四步才是全量推廣同時配好培訓材料和常見問題解答降低用戶上手的心理門檻。組織推廣里最容易被忽略的是使用意愿。再好的系統(tǒng)業(yè)務團隊不愿意用也是白搭。我會在產(chǎn)品上線前主動跟業(yè)務骨干溝通找到他們最頭疼的痛點把系統(tǒng)定位成幫他們解決這些痛點的工具而不是監(jiān)控他們工作的工具。業(yè)務人員的信任是一點點攢出來的。4. 基礎設施與工程質(zhì)量不性感但決定生死的部分4.1 可觀測性設計鏈路追蹤、Token消耗與質(zhì)量監(jiān)控一到生產(chǎn)環(huán)境AI應用和傳統(tǒng)應用的運維思維就有很大差異了。傳統(tǒng)應用關注的是響應時間、錯誤率、吞吐量AI應用還得額外關注三件事Token消耗、模型輸出質(zhì)量和昂貴的失敗模式。Token消耗是最直觀的成本信號。我在系統(tǒng)里會為每個業(yè)務線的調(diào)用加標簽這樣就能清楚看到哪條業(yè)務線燒Token最多哪個Prompt模板的輸入可以精簡哪些請求明明只需要小模型卻路由到了大模型。優(yōu)化Token消耗都是真金白銀運營成本下降就是利潤提升。模型輸出質(zhì)量監(jiān)控要復雜得多。完全自動判斷回答對不對不現(xiàn)實但可以做三件事一是給輸出加置信度信號模型不確定時主動提示或轉(zhuǎn)人工二是對特定高危內(nèi)容做規(guī)則攔截比如涉及價格、法律承諾、醫(yī)療建議等超過邊界寧可不給答案也不能亂答。最容易被忽略的是昂貴失敗模式。一個AI客服答錯問題可能只是用戶不滿但一個AI風控系統(tǒng)誤判可能就是一大筆資金損失。架構上必須區(qū)分低危失敗和高危失敗低危場景可以自動處理高危場景必須保留人工兜底。我的習慣是建立一張質(zhì)量看板把每日調(diào)用量、Token消耗、平均延遲、人工干預率、用戶反饋情緒趨勢全部放在一張圖上。管理層問進展時不用一堆截圖講故事一張看板就夠了上面每一行數(shù)據(jù)背后都對應著一個具體的運營行動。4.2 數(shù)據(jù)安全與權限治理AI系統(tǒng)的高壓線AI系統(tǒng)天然是數(shù)據(jù)密集型的一旦出安全問題影響范圍往往比傳統(tǒng)系統(tǒng)更大。因為大模型會把輸入內(nèi)容加工后再次輸出如果企業(yè)知識庫里的敏感信息被非授權人員通過問答套出來這就是一種新的數(shù)據(jù)泄露方式。我在做架構設計時數(shù)據(jù)安全會卡得非常死。具體有幾個硬性要求所有數(shù)據(jù)訪問必須走權限服務校驗系統(tǒng)在回答前要先判斷當前用戶是否有權限看到這部分內(nèi)容知識庫里的文檔要按密級和歸屬部門打標檢索結果里混入越權文檔時寧可丟棄也不能帶進上下文所有模型輸入輸出都要留審計日志且日志本身要加密存儲并限制訪問范圍。另一個常被忽略的安全問題是提示詞注入。用戶精心構造的輸入可能誘導模型輸出系統(tǒng)指令或越權操作。在工具調(diào)用鏈路里所有用戶輸入都視為不可信數(shù)據(jù)內(nèi)部指令和外部輸入必須隔離開。我會在Agent工具網(wǎng)關里加一道意圖白名單不在白名單里的操作一律拒絕執(zhí)行從上杜絕用戶輸入直接傳遞到高權限工具參數(shù)里的情況。4.3 成本治理讓AI項目從燒錢變成劃算任何AI項目的終局都要回答一個問題投入產(chǎn)出比是否站得住腳。如果不能讓AI項目從燒錢變成劃算哪怕技術再炫最終也會被叫停。成本治理的第一步是評估口徑統(tǒng)一。我把成本拆成三塊模型調(diào)用成本、基礎設施成本、人工介入成本。很多團隊只盯著第一塊忽視了后面兩塊。如果模型答錯的概率太高導致大量人工復核那么人工介入成本會迅速吞掉模型省下來的收益。第二步是架構層面做成本優(yōu)化。比如用小模型做初篩、大模型做精排的級聯(lián)流程在非高峰時段把批量任務壓低優(yōu)先級對上下文做壓縮只保留必要信息進Prompt建立緩存機制高頻相似問題直接命中緩存不重復調(diào)用模型。第三步是用單位成本來倒推業(yè)務效率。我在寫方案時的習慣是把項目的月度成本除以它節(jié)省的人月數(shù)得到一個每節(jié)省一個人月需要花多少錢的數(shù)字。這個數(shù)字如果明顯低于該崗位的綜合用工成本項目在經(jīng)濟上就成立。這樣算出來的賬比單純講效率提升百分之多少更能讓財務和管理層信服。5. 智能化時代的架構演進從單點智能到系統(tǒng)智能5.1 多智能體協(xié)作的工程化挑戰(zhàn)單場景的AI應用做完之后很多企業(yè)會自然走向多智能體協(xié)作——讓幾個AI角色分工配合完成更復雜的任務。這個方向聽起來很美但工程化挑戰(zhàn)很大。多智能體架構首先要解決的是通信協(xié)議問題。兩個Agent之間如何傳遞任務和結果我建議采用結構化消息格式每個消息包含任務類型、執(zhí)行狀態(tài)、產(chǎn)出數(shù)據(jù)、置信度、上下文引用等字段而不是直接讓語言模型自由對話。自由對話看似靈活實際上難以追蹤、難以回放、容易失控。其次要明確編排模式。是中心化編排由一個主控Agent統(tǒng)一調(diào)度其他子Agent還是去中心化協(xié)商讓Agent之間自行互動基于目前工程成熟度我的建議是大部分場景先用中心化編排每個子Agent職責窄而明確主控負責任務分解、順序控制和結果匯總。去中心化的探索可以放在實驗室里做生產(chǎn)環(huán)境先求穩(wěn)。多智能體帶來的故障排查復雜度也值得單獨說。傳統(tǒng)系統(tǒng)出錯通過調(diào)用鏈就能定位到具體服務多智能體系統(tǒng)出錯可能是一連串自然語言交互累積的結果普通日志根本看不明白。所以每個Agent的關鍵決策點都要記錄推理摘要而不是原始對話記錄并配套可視化工具來回放整個任務執(zhí)行過程。5.2 小模型與大模型的分工體系我在前面提過模型路由的思路放到整體架構里其實是一個更大主題小模型和大模型的分工體系。實踐經(jīng)驗是企業(yè)里80%的AI場景需求并不需要最強的模型。簡單文本分類、實體抽取、格式轉(zhuǎn)換、意圖識別這些都是小模型甚至傳統(tǒng)機器學習模型就能出色完成的任務成本低、速度快、穩(wěn)定可控。大模型的正確位置是在復雜語義理解、內(nèi)容生成、跨領域推理這些場景中做最后一道工序。架構上我會設計一個智能路由層請求進入后先做難度與類型判斷能走規(guī)則的不走模型能走小模型的不走大模型只有真正需要大模型能力的請求才被路由過去。這一層的維護成本不算高但它能把整個系統(tǒng)的推理成本降到原來的三分之一甚至更低。同時需要注意小模型不是永遠固定不變的。業(yè)務在變數(shù)據(jù)在變小模型也要有持續(xù)更新的機制。我會定期評估每個小模型的效果指標如果發(fā)現(xiàn)某類請求的準確率開始下滑就觸發(fā)重新訓練或微調(diào)的流程。這種模型運維的概念未來幾年一定會成為企業(yè)AI平臺的標準能力。5.3 AI原生應用對組織能力的反作用力做AI應用架構師久了會發(fā)現(xiàn)技術演進到一定階段會倒逼組織模式跟著變。只要業(yè)務條線各自做各自的AI應用數(shù)據(jù)孤島、能力重復建設成本失控是遲早的事。比較健康的方向是建一個企業(yè)AI能力平臺把通用能力沉淀成服務統(tǒng)一的知識庫管理、統(tǒng)一的模型網(wǎng)關、統(tǒng)一的評測平臺、統(tǒng)一的觀測與審計體系。業(yè)務線在這個平臺上快速集成自己的AI應用而不是每次都從零搭一套基礎設施。這個平臺由誰建設、誰維護、誰定標準恰恰是AI應用架構師可以大有作為的地方。組織能力層面的另一個關鍵點是AI素養(yǎng)的普及。系統(tǒng)做得再好如果一線員工不理解AI的能力邊界要么過度信任導致風險要么過度防備導致棄用。我在項目里會專門組織系列培訓不是講技術原理而是帶著業(yè)務人員實際體驗系統(tǒng)、讓他們理解什么情況下該用、什么情況下不該用同時建立反饋渠道讓使用中的問題能快速回到研發(fā)團隊。這個環(huán)節(jié)看起來不硬核但對落地效果的塑造往往比技術細節(jié)還重要。最后再分享幾句實在話做了這么久的AI應用架構工作我的體會是這個崗位的技術能力當然重要但更核心的是把技術變成企業(yè)競爭力的閉環(huán)能力。模型在快速迭代今天的最優(yōu)選擇半年后可能就過時了但一個企業(yè)能不能持續(xù)吸收新技術、能不能快速試錯、能不能把數(shù)據(jù)資產(chǎn)和評測資產(chǎn)沉淀下來這才是長期競爭力的來源。所以如果你正在規(guī)劃企業(yè)AI落地我的建議是別把目光全放在用多強的模型上多花精力去設計反饋閉環(huán)、評測體系、權限邊界和成本模型。這些不起眼的基礎工作恰恰是智能化時代企業(yè)真正拉開差距的地方。最后分享一個小技巧無論項目多忙都要留出一部分時間讓團隊做無目標的探索實驗。AI技術演進太快如果團隊只會按既定方案執(zhí)行那企業(yè)的AI能力就永遠鎖死在當前水平上。保持一點技術好奇心定期做一點小實驗是這個領域最值得的投資。