這三樣技術(shù)再不分開看AI產(chǎn)品經(jīng)理的選型會越做越糊涂先說個我前段時間評審會上真實發(fā)生的場景某供應(yīng)鏈項目要做采購發(fā)票的自動化處理業(yè)務(wù)方提了一堆需求老板問用RPA還是低代碼還是大模型現(xiàn)場三個名詞來回拋最后誰也沒說清楚為什么選這個、不選那個。這其實不是個別現(xiàn)象AI產(chǎn)品經(jīng)理這兩年越來越頻繁地被推到技術(shù)選型的決策位上但RPA、低代碼、大模型這三樣?xùn)|西在很多人腦子里的邊界是模糊的——一說到自動處理就全往大模型上靠一說到搭個頁面就只知道低代碼一說到機(jī)器人就默認(rèn)RPA。這篇指南就專門解決這個問題。我按自己實際做項目的思路把三者的本質(zhì)拆開、把選型判斷框架列出來再給幾組高頻場景的組合配方最后聊聊產(chǎn)品經(jīng)理在這類選型里最容易踩的坑。寫之前先說明白這是一篇偏決策視角的選型指南不是技術(shù)源碼分析——適合AI產(chǎn)品經(jīng)理、數(shù)字化轉(zhuǎn)型負(fù)責(zé)人、以及需要給業(yè)務(wù)方拍板技術(shù)路線的同學(xué)收藏著用后面做方案評審時可以直接拿出來對照。1. 三者到底是干什么的先把邊界畫清楚選型才有的聊選型為什么會亂根源在于大家把RPA、低代碼、大模型放在了一條線上比較好像它們是功能重疊的同類工具。其實它們的解決問題方式完全不同看問題的維度也不一樣。我給三者的定位是RPA管手低代碼管骨架大模型管腦子。1.1 RPA的本質(zhì)模仿人類操作電腦的數(shù)字員工RPA的核心邏輯不是編程而是模擬人在圖形界面上的操作——打開某個業(yè)務(wù)系統(tǒng)、登錄、找到某個頁面、讀取字段、錄入數(shù)據(jù)、點擊按鈕、下載文件、再切到另一個系統(tǒng)粘貼。它走的是看見什么操作什么的路子依靠界面元素定位控件識別、圖像識別、OCR輔助來驅(qū)動業(yè)務(wù)流程。我在某供應(yīng)鏈項目里實際見過一個典型的RPA場景采購部門每天要把ERP里的到貨單逐條錄入到另外一套財務(wù)系統(tǒng)再做一次三單匹配。人工操作平均一單要6分鐘上了一個RPA流程之后變成40秒準(zhǔn)確率從97%提到99.5%。但要注意RPA解決的是流程確定、規(guī)則明確、重復(fù)勞動的問題。它不理解業(yè)務(wù)含義只執(zhí)行動作。你讓它處理一份沒有固定格式的合同、判斷條款是否合理它就傻眼了——因為它根本不是在理解文檔它只是在搬運和填表。RPA最大的特點也是它最大的軟肋依賴界面穩(wěn)定性。只要業(yè)務(wù)系統(tǒng)改版、按鈕位置變了、登錄頁加了驗證碼流程就斷給你看。我見過某項目上線兩周后因為目標(biāo)系統(tǒng)發(fā)了一次前端版本升級整個自動化流程癱瘓了大半天。所以選RPA之前必須先確認(rèn)你面對的系統(tǒng)有沒有穩(wěn)定的操作界面、有沒有可用的API這兩個條件至少要占一個。1.2 低代碼的本質(zhì)快速搭建業(yè)務(wù)應(yīng)用的腳手架低代碼要解決的是應(yīng)用系統(tǒng)建設(shè)速度慢的問題。傳統(tǒng)開發(fā)一個后臺管理系統(tǒng)前后端聯(lián)調(diào)、數(shù)據(jù)庫設(shè)計、權(quán)限控制、測試上線沒有幾個月下不來。低代碼平臺把這些東西模板化、組件化、可視化拖拖拽拽就能搭出表單、列表、審批流、儀表盤、權(quán)限模型。很多平臺還內(nèi)置了數(shù)據(jù)庫、用戶體系、API網(wǎng)關(guān)連數(shù)據(jù)處理邏輯都可以通過配置完成。低代碼最典型的應(yīng)用場景是公司內(nèi)部缺一個小工具——比如一個項目進(jìn)度跟蹤看板、一個銷售周報收集表、一個工單派發(fā)系統(tǒng)。這類需求的特點是邏輯不復(fù)雜、用戶量不大幾十到幾百人、迭代頻繁用傳統(tǒng)開發(fā)方式太慢太貴用低代碼平臺一兩周就能出可用版本。它和大模型的區(qū)別很直接低代碼能幫你把應(yīng)用框架搭好但它不提供智能。你可以在低代碼系統(tǒng)里做數(shù)據(jù)統(tǒng)計、做流程審批但它沒法跟你對話、沒法幫你寫總結(jié)、沒法理解用戶隨口說的一句話。低代碼是骨架它把應(yīng)用的形態(tài)撐起來但里面裝的業(yè)務(wù)流程是固定的、規(guī)則是寫死的。遇到那種需求還沒想清楚的項目低代碼也有風(fēng)險——因為它把業(yè)務(wù)邏輯固化成了表單和流程改一次需求就是改一次模型頻繁改起來并不輕松。1.3 大模型的本質(zhì)具有生成與理解能力的智能內(nèi)核大模型和前兩者的差別是代際的。RPA和低代碼都是確定邏輯的執(zhí)行器和容器大模型則是用參數(shù)化方式壓縮了海量知識的概率引擎它能理解自然語言、生成自然語言、抽取信息、分類歸納、總結(jié)推理。它會寫一段周報、會從合同里提取關(guān)鍵條款、會根據(jù)對話上下文回答用戶問題——這些都是規(guī)則寫不出來的能力。但正因為它是概率模型它有兩個天然的邊界。第一是不確定性同一個問題問兩次答案可能不一樣面對需要精確計算、嚴(yán)格強校驗的場景它不適合單獨使用第二是幻覺它可能在信息不足時一本正經(jīng)地編造內(nèi)容。我用大模型做過一段合同摘要抽取正常條款它抽得又快又準(zhǔn)但遇到那種末尾附加的特殊約定模型會把不存在的違約責(zé)任條款也腦補出來。這就是選型里最關(guān)鍵的一個分水嶺你的業(yè)務(wù)到底容不容忍可能出錯且錯誤不固定的結(jié)果。1.4 三者不是三選一而是三層架構(gòu)想明白三者的本質(zhì)之后正確的問題就不是用哪個而是哪個為主、哪個為輔、怎么組合。我自己的實踐經(jīng)驗是一個完整的自動化智能化系統(tǒng)往往是三層結(jié)構(gòu)底層RPA負(fù)責(zé)和外部系統(tǒng)打交道承擔(dān)手腳的角色把數(shù)據(jù)取回來、把結(jié)果寫回去中間層低代碼負(fù)責(zé)把業(yè)務(wù)流程編排成應(yīng)用做數(shù)據(jù)存儲、權(quán)限控制、人工審核節(jié)點保證整條鏈路是可見、可控、可改的最上層大模型負(fù)責(zé)真正需要理解力的部分比如文檔理解、對話、分析、總結(jié)輸出結(jié)果后再交給RPA去執(zhí)行或者低代碼去流轉(zhuǎn)。這套組合我后面會在場景案例里展開說?，F(xiàn)在先把結(jié)論放在這選型的本質(zhì)是給需求里不同的環(huán)節(jié)找對應(yīng)能力最匹配的技術(shù)層而不是找一個大而全的萬能工具。2. 選型判斷框架五個維度決定需求落在哪個技術(shù)層理解了邊界之后下一步就是建立一個可復(fù)用的判斷框架。我自己在項目里用的是一套五維判斷法每來一個需求就拿著五個問題過一遍基本能定調(diào)。判斷維度核心問題偏向RPA偏向低代碼偏向大模型流程確定性規(guī)則能否被完整寫下來規(guī)則明確、步驟固定流程可建模、節(jié)點清晰規(guī)則無法窮舉、需要語義判斷交互形態(tài)用戶和系統(tǒng)的交互方式系統(tǒng)對系統(tǒng)、界面操作人用瀏覽器/APP操作自然語言對話、文本生成交付物形態(tài)最終交付的是什么自動化執(zhí)行流程可訪問的業(yè)務(wù)應(yīng)用智能問答/生成/抽取能力變更與維護(hù)業(yè)務(wù)和界面多久變一次界面穩(wěn)定但業(yè)務(wù)易變需維護(hù)腳本流程變更需改模型模型需要Prompt調(diào)優(yōu)和數(shù)據(jù)治理容錯與合規(guī)出錯代價有多大中需要人工復(fù)核兜底低規(guī)則內(nèi)可完全確定高幻覺不可消除這五個維度不是并列的判斷順序很重要。我實際使用時的判斷邏輯是這樣的——先看第一維度流程確定性如果業(yè)務(wù)流程連最熟悉業(yè)務(wù)的人都說不清楚那就是規(guī)則無法窮舉直接引導(dǎo)往大模型方向考慮如果規(guī)則能寫得一清二楚再看最終要交付什么。要是交付物是一個自動執(zhí)行的流程比如定時抓取數(shù)據(jù)、批量錄入、跨系統(tǒng)搬運那RPA是主干要是交付物是一個別人要天天用的系統(tǒng)比如審批、看板、數(shù)據(jù)填報那低代碼是主干要是交付物是一個智能交互能力比如客服問答、文檔審核、內(nèi)容生成大模型跑不掉。2.1 關(guān)鍵細(xì)節(jié)規(guī)則能不能寫清楚是所有判斷的起點我在多個項目里驗證過一件事很多需求剛開始看起來都很適合大模型但聊深了發(fā)現(xiàn)90%的環(huán)節(jié)其實是有標(biāo)準(zhǔn)規(guī)則的。比如客服系統(tǒng)用戶問我的訂單到哪了規(guī)則是查物流接口返回狀態(tài)這是確定性邏輯用戶問幫我看看我為什么被扣了這筆錢很可能涉及賬單、優(yōu)惠券、活動規(guī)則疊加規(guī)則復(fù)雜但勉強可窮舉只有用戶問你覺得我應(yīng)該選哪個方案這才真的需要生成式理解和推理。所以我會建議產(chǎn)品經(jīng)理在選型第一輪先做一個動作和業(yè)務(wù)方做一次規(guī)則窮舉工作坊把所有已知的判定條件列出來看能不能畫成流程圖。能畫的就是RPA或低代碼的范疇畫不出來的才是大模型的菜。這個工作坊能幫你避免大量用大炮打蚊子式的選型錯誤。2.2 成本模型單價便宜的RPA三年總成本未必便宜第五個維度成本模型單獨說一下因為它最容易讓人誤判。很多決策者第一眼看到的差異化因素就是價格RPA單個機(jī)器人一年幾萬塊低代碼平臺按用戶訂閱大模型API按token計費看起來差別很大。但真正比較的應(yīng)該是三年總擁有成本TCO包括采購/訂閱費、實施和定制費、維護(hù)人力和培訓(xùn)費、規(guī)則變更時的調(diào)整成本、基礎(chǔ)設(shè)施如果私有化部署還要算算力、出錯帶來的風(fēng)險補償成本。我見過一個典型誤判某財務(wù)共享中心選了RPA來做單據(jù)錄入采購成本不貴但后續(xù)每個新供應(yīng)商的單據(jù)格式不同都得改腳本一改就是半天起三個業(yè)務(wù)系統(tǒng)升級一次所有流程重新測一遍一年花在維護(hù)上的人力超過當(dāng)初采購價的數(shù)倍。反觀另一個項目直接用低代碼平臺做了個數(shù)據(jù)錄入應(yīng)用讓供應(yīng)商自己填結(jié)構(gòu)化表單徹底繞開了“識別非標(biāo)準(zhǔn)單據(jù)”的坑。選型不能只比較技術(shù)單價要把后續(xù)生命周期成本一起拉進(jìn)表里。3. 高頻場景選型組合六類真實需求直接對照參考判斷框架是道具體場景是術(shù)。下面這幾類場景是我在各類項目里反復(fù)遇到的高頻需求每個都給了推薦的技術(shù)組合和理由你拿自己正在碰的需求對照一下大概率能找到對應(yīng)項。3.1 跨系統(tǒng)數(shù)據(jù)搬運與批量錄入RPA單干偶爾OR輔助典型例子ERP系統(tǒng)里的采購單需要人工搬運到財務(wù)系統(tǒng)、政務(wù)審核結(jié)果的批量回填、多平臺店鋪訂單的匯總導(dǎo)出。這類需求的核心是系統(tǒng)間沒有API或者有API但開放權(quán)限申請不下來而界面操作路徑固定、規(guī)則簡單。推薦方案是RPA單干。實施要點先梳理清楚源系統(tǒng)和目標(biāo)系統(tǒng)的界面操作路徑錄制腳本然后對異常分支做兜底——比如頁面加載超時、目標(biāo)字段彈校驗、數(shù)據(jù)重復(fù)提示這些都要提前埋重試和告警。OCR是否加取決于源系統(tǒng)是不是有非結(jié)構(gòu)化圖片比如掃描件里的單據(jù)編號如果全是文本框OCR完全是多余成本。這套方案上線最快、見效最直接但要在運維SLA里寫清楚源系統(tǒng)每次發(fā)版后48小時內(nèi)必須跑一次回歸驗證要不然斷了沒人知道。3.2 內(nèi)部管理工具的快速搭建低代碼主導(dǎo)別扯上大模型典型例子銷售團(tuán)隊的周報收集與匯總、項目進(jìn)度跟蹤看板、內(nèi)部工單流轉(zhuǎn)、行政采購審批應(yīng)用。這類需求的典型特征是有明確的使用群體內(nèi)部員工、明確的流程節(jié)點填表→審批→歸檔、不需要對外暴露也沒有復(fù)雜的智能判斷。推薦方案就是低代碼平臺直接搭。有人會覺得現(xiàn)在不加上AI都不好意思立項但我建議這種需求克制一點。銷售周報收集就是表單審批匯總統(tǒng)計你非要嵌入一個用大模型自動給每個銷售的周報打分先不說Prompt怎么寫才能評得公平光是銷售為什么愿意被AI點評這個組織問題就夠你吃一壺的。低代碼在這里的價值是快速交付、靈活迭代——你花一周搭出來的版本用兩周時間根據(jù)用戶反饋改了三個迭代這種節(jié)奏只有低代碼能給到。3.3 非結(jié)構(gòu)化文檔處理大模型負(fù)責(zé)理解RPA負(fù)責(zé)端到端執(zhí)行典型例子每天收到幾百份來自不同供應(yīng)商的合同文本、掃描版發(fā)票、PDF對賬單需要把核心字段抽出來進(jìn)系統(tǒng)做比對、觸發(fā)后續(xù)流程。這類需求單靠RPA做不了——RPA能做的是找到文件→打開文件→復(fù)制粘貼的機(jī)械動作它不認(rèn)識合同里的違約責(zé)任和付款條件單靠大模型也做不了端到端——大模型能抽取但誰來觸發(fā)任務(wù)、誰來把抽取結(jié)果寫回系統(tǒng)、誰來處理失敗任務(wù)這時候就是組合最典型的架構(gòu)RPA負(fù)責(zé)編排任務(wù)定時掃描郵箱/共享目錄下載文件按規(guī)則重命名歸檔大模型負(fù)責(zé)抽取調(diào)用OCR識別掃描件文字LLM按既定字段清單提取關(guān)鍵信息輸出JSON低代碼或簡單后端服務(wù)負(fù)責(zé)結(jié)果流轉(zhuǎn)抽取結(jié)果寫入數(shù)據(jù)庫匹配規(guī)則庫做初步校驗異常項推送給人工審核處理。我做過一個相對成功的合同要素抽取項目就是用這個組合跑的。項目上線后人工介入率從100%降到20%但要注意剩下的20%是必須留給人審的因為模型在長段落、多義表述上依然會出錯靠規(guī)則兜不住。3.4 企業(yè)知識庫問答大模型為核心低代碼做編排界面典型例子企業(yè)內(nèi)部政策問答機(jī)器人、設(shè)備運維知識庫助手、培訓(xùn)資料智能檢索。這類需求的核心是要讓用戶用自然語言問問題并且基于企業(yè)內(nèi)部的文檔作答——不是開放域閑聊要引用依據(jù)、要來源可溯。推薦架構(gòu)是大模型RAG檢索增強外面套一層低代碼做的問答工作臺。RAG的思路說起來很簡單先把企業(yè)知識文檔做向量化入庫用戶問題進(jìn)來后先檢索最相關(guān)的片段再把片段作為上下文丟給大模型生成回答。這樣做的好處是大模型不需要重新學(xué)習(xí)企業(yè)內(nèi)部資料更新知識庫就是更新索引成本低、可控性強。難點在于知識庫的切分粒度、檢索召回質(zhì)量、以及答案引用來源標(biāo)注——這些要花大量時間調(diào)。產(chǎn)品經(jīng)理在這里要把握一條底線凡是回答里標(biāo)注僅供參考的場景大模型可以上凡是回答結(jié)果直接驅(qū)動業(yè)務(wù)動作比如決定是否放款、是否審批通過的場景必須有人工復(fù)核節(jié)點大模型只能做初篩建議。3.5 報表生成與推送三層各干一段最出團(tuán)隊效率感典型例子經(jīng)營日報自動生成每天早上9點前把前一天的銷售、庫存、履約數(shù)據(jù)匯總成圖文報告推送給管理層。這個場景特別適合給剛接觸這套組合的業(yè)務(wù)團(tuán)隊當(dāng)入門樣板因為每個環(huán)節(jié)都清晰RPA或應(yīng)用內(nèi)的數(shù)據(jù)接口負(fù)責(zé)跨系統(tǒng)取數(shù)——從ERP、CRM、物流系統(tǒng)拉數(shù)據(jù)低代碼負(fù)責(zé)數(shù)據(jù)匯聚和中間表存儲——定好口徑算出指標(biāo)GMV、訂單量、轉(zhuǎn)化率、異常提醒大模型負(fù)責(zé)把指標(biāo)數(shù)據(jù)轉(zhuǎn)寫成自然語言段落——昨日GMV環(huán)比上升12%主要受某區(qū)域促銷帶動但華東倉履約異常率有所上升需關(guān)注低代碼再負(fù)責(zé)最后一步的發(fā)布——生成H5頁面或接入IM機(jī)器人推送。這套鏈路跑通之后日常寫周報的時間能壓掉70%以上而且口徑一旦鎖死就不會再出現(xiàn)每個部門報的數(shù)對不上。唯一的提醒是大模型生成的文字結(jié)論要接入人工抽檢機(jī)制不能默認(rèn)無條件信任尤其涉及對外發(fā)布的內(nèi)容。3.6 踩過才知道的禁忌別用大模型硬扛確定性規(guī)則流程最后給一個反向場景。某項目想做采購訂單的自動審批原先的設(shè)想是訂單進(jìn)來大模型讀一遍訂單內(nèi)容再結(jié)合供應(yīng)商歷史表現(xiàn)自動決定是否放行。這個方案我一聽就覺得有問題——訂單審批是典型的強規(guī)則場景金額超預(yù)算就駁回、新供應(yīng)商必須先審資質(zhì)、歷史有三次以上延遲交付就自動降級。這些都是可以用規(guī)則引擎明確寫出來的判定條件為什么非要讓大模型來做一旦模型判斷邏輯漂移連出錯的依據(jù)都沒有。我給這個項目的建議是訂單信息用OCR或API結(jié)構(gòu)化判斷邏輯全部用確定性規(guī)則寫大模型最多用來做一件事——給審批人生成一句話的決策摘要輔助人做判斷。規(guī)則給確定性大模型給解釋性分工各得其所。這算是我在做選型組合時一條很重要的經(jīng)驗讓能力歸位別為了AI而AI。4. 選型之后的落地關(guān)鍵動作一周PoC、供應(yīng)商清單與退出機(jī)制技術(shù)選型最容易犯的錯是把它當(dāng)成一次性決策——選完了寫進(jìn)PPT了就以為結(jié)束了。實際上選型方案只是一個假設(shè)需要通過小范圍驗證來證明它成立。我建議每個項目在正式立項之前留出一到兩周做PoC概念驗證并且按照標(biāo)準(zhǔn)動作來檢查候選技術(shù)方案。4.1 一周PoC該驗證什么不能只演示跑通了PoC的目的不是看供應(yīng)商演示Demo而是回答三個問題第一方案在你的真實數(shù)據(jù)和真實環(huán)境里能不能跑通第二異常情況出現(xiàn)時是誰、用什么方式兜底第三這個方案維護(hù)起來要什么級別的人力和成本。我一般把PoC壓成五天頭兩天拿真實數(shù)據(jù)跑核心鏈路比如100份真實單據(jù)過一遍模型抽取第三、四天人為構(gòu)造異常場景壞數(shù)據(jù)、重復(fù)數(shù)據(jù)、超大文件、字段缺失第五天讓一個沒有參與前期配置的同學(xué)嘗試自己調(diào)整規(guī)則或Prompt看釋放維護(hù)門檻高不高。很多項目在PoC第三天就會暴露問題——比如某個RPA流程在鎖屏狀態(tài)下跑不了、某個低代碼平臺和公司現(xiàn)有的統(tǒng)一登錄系統(tǒng)對接不上、某個大模型在特定格式合同上漏抽率超過30%。這些問題在PPT階段永遠(yuǎn)看不到但在第五天你會對自己的選型方案有一個非常清醒的判斷。4.2 供應(yīng)商方案能力評估清單四個必看項不管選RPA、低代碼還是大模型方案我都建議從四個角度去評估供應(yīng)商而不是被功能清單牽著走集成能力是否能和你現(xiàn)有的賬號體系、權(quán)限體系、數(shù)據(jù)源無縫對接。很多平臺演示時很漂亮但接企業(yè)微信/釘釘?shù)卿浘涂み@個必須在PoC前就確認(rèn)?？删S護(hù)性是否有完善的開發(fā)/配置界面、日志、監(jiān)控告警。這意味著以后業(yè)務(wù)變了是自己人改還是天天找供應(yīng)商排隊。審計日志尤其重要自動化系統(tǒng)一旦在合規(guī)審查時拿不出操作記錄麻煩很大。私有化/混合部署能力數(shù)據(jù)要不要出域、出域是否符合合規(guī)要求這是硬底線。大模型方案尤其要弄清楚敏感數(shù)據(jù)是否會被用于模型訓(xùn)練是否支持私有化部署或脫敏后再調(diào)用云端API。生態(tài)完整度RPA看有沒有組件市場、低代碼看有沒有行業(yè)模板、大模型看有沒有配套的向量數(shù)據(jù)庫和標(biāo)注工具。生態(tài)完整度直接決定你后續(xù)擴(kuò)展功能的成本。4.3 提前寫好退出機(jī)制和技術(shù)方案一起過會我強烈建議在立項文檔里專門留一頁寫失敗條件包括PoC階段核心指標(biāo)不達(dá)標(biāo)、上線后X個月內(nèi)人工復(fù)核率超過預(yù)設(shè)閾值、年度總維護(hù)成本超出預(yù)算比例上限、關(guān)鍵供應(yīng)商出現(xiàn)服務(wù)中斷或者重大安全事件。這些條件一旦觸發(fā)方案就該啟動降級或切換流程。很多團(tuán)隊不喜歡寫這種東西覺得晦氣。但據(jù)我的項目經(jīng)驗寫了退出機(jī)制的項目往往更敢于嘗試并更快拿到結(jié)果不寫的項目反而會在一個不太合適的方案上反復(fù)打補丁越陷越深。退出機(jī)制不是給項目判死刑而是給決策者一個心理安全墊——我們試過指標(biāo)不行所以換路比我們也不知道行不行但PPT已經(jīng)報上去了要體面得多。5. 產(chǎn)品經(jīng)理最容易踩的四個坑花錢買來的項目教訓(xùn)最后這部分是我最想講的——前面都是方法論這里全是真金白銀買來的經(jīng)驗教訓(xùn)。產(chǎn)品經(jīng)理在這個領(lǐng)域踩坑往往不是技術(shù)理解不到位而是在決策機(jī)制、溝通口徑和預(yù)期管理上出了問題。5.1 把流程自動化包裝成AI項目導(dǎo)致預(yù)期管理全面失控有個項目原本只想解決財務(wù)對賬自動化的問題一套RPA配上幾條規(guī)則就能完成80%的工作。但匯報的時候團(tuán)隊用了打造財務(wù)智能大腦這類措辭結(jié)果老板和業(yè)務(wù)方對系統(tǒng)的預(yù)期直接變成了以后任何財務(wù)問題它都能回答異常數(shù)據(jù)它能自己分析和解釋。上線后發(fā)現(xiàn)它只能做對賬不能做預(yù)測業(yè)務(wù)方當(dāng)場就覺得被欺騙了。我的建議是匯報時寧可說的保守把智能的邊界講清楚——它能自動執(zhí)行X類流程能輔助做Y類判斷遇到規(guī)則之外的Z類情況會轉(zhuǎn)人工。預(yù)期這個東西一旦被拔高再要降下來代價非常大。把自動化說成智能化來立項短期好看長期爆炸。5.2 低估了權(quán)限申請和合規(guī)審批的時間消耗技術(shù)上兩星期能跑通的PoC往往要等一個月的系統(tǒng)權(quán)限審批。某項目做RPA要對接核心業(yè)務(wù)系統(tǒng)的數(shù)據(jù)庫只讀賬號安全團(tuán)隊要求先做半年的操作審計、限定操作時間段、配備錄屏留痕一等就是兩個季度。還有項目用了大模型API來處理合同數(shù)據(jù)法務(wù)直接要求數(shù)據(jù)脫敏、簽署數(shù)據(jù)處理協(xié)議、限定模型供應(yīng)商只能按請求處理不能留存數(shù)據(jù)——這一個合規(guī)流程走下來又是大把時間。產(chǎn)品經(jīng)理在做項目排期時必須把權(quán)限申請、安全評審、法務(wù)合規(guī)這三項時間單獨列出來不能默認(rèn)技術(shù)驗證通過可以上線。提前把相關(guān)團(tuán)隊拉進(jìn)項目周會里讓他們從第一天就知曉自動化方案要做什么、數(shù)據(jù)流向是什么永遠(yuǎn)是值得的投資。5.3 沒有提前定義AI出錯到多少要熔斷的閾值大模型方案的容錯率必須在立項時量化。你說準(zhǔn)確率98%聽起來很高但你們每天處理10000個請求2%就是200個錯誤請求如果每個錯誤請求都會觸發(fā)下游一個人工處理甚至一次客訴那實際可接受閾值可能是99.9%。我在某文檔抽取項目里就吃過這個虧上線前測下來字段抽取準(zhǔn)確率99.2%覺得穩(wěn)了結(jié)果上線后發(fā)現(xiàn)有個特定供應(yīng)商的單據(jù)格式一直搞錯出錯率集中在該類單據(jù)上導(dǎo)致對應(yīng)流程頻繁卡住。后來補了一個分維度監(jiān)控熔斷機(jī)制——某個來源、某類格式、某個字段的準(zhǔn)確率下降到閾值系統(tǒng)自動停用自動化轉(zhuǎn)為人工處理。產(chǎn)品經(jīng)理在做大模型方案時一定要和業(yè)務(wù)方一起定義清楚錯誤率指標(biāo)拆到哪些細(xì)分維度達(dá)到什么數(shù)值就停線上自動流程停掉之后誰來兜底。這些細(xì)節(jié)寫在方案里比上線后再開會救火強一百倍。5.4 只算機(jī)器人單價和API單價忽略隱性成本前面提過TCO了但正因為太多人忽視我再強調(diào)一遍。某RPA項目的隱性成本包括每次上游系統(tǒng)改版后的腳本修復(fù)和回歸測試平均每次消耗2-3個人日、日常監(jiān)控和異常處理值班每周至少一個人半天、以及流程優(yōu)化的持續(xù)投入。三個隱性成本加起來往往超過采購本身。低代碼平臺的隱性成本在業(yè)務(wù)變了之后模型怎么改版本、平臺本身升級時二次開發(fā)的兼容成本。大模型的隱性成本在Prompt調(diào)優(yōu)、知識庫更新、標(biāo)注數(shù)據(jù)準(zhǔn)備和每次效果回歸測試——這些都要持續(xù)投入人力。產(chǎn)品經(jīng)理一定要在方案通過前把第一年維護(hù)人力清單做出來并且在立項材料里寫清楚第二年起每年預(yù)計的維護(hù)投入會落在哪個團(tuán)隊、多少人天避免上線后無人維護(hù)的情況。最后說點我的個人體會做這類選型做得多了我自己的習(xí)慣逐漸沉淀成一套三層過濾法每次遇到新需求都會走一遍第一層問業(yè)務(wù)流程的規(guī)則能不能窮舉——能就往RPA或低代碼走不能才考慮大模型。第二層問最終要交付的是執(zhí)行流程、業(yè)務(wù)應(yīng)用、還是智能能力——這就決定了三者的主從關(guān)系。第三層問誰來做異常兜底和日常維護(hù)——如果沒人兜底不管技術(shù)多先進(jìn)都一票否決。最后再分享一個小技巧我寫選型方案時習(xí)慣在文檔第一頁放一張決策否決項清單把數(shù)據(jù)不出域、權(quán)限可審計、有監(jiān)控告警、有維護(hù)責(zé)任人這幾條列在最前面。只要有一條不滿足這個方案就不值得往下細(xì)化。這樣不但能幫自己快速過濾不合適的技術(shù)路線也能讓評審會上的各位把注意力從哪個技術(shù)很酷拉回哪個方案真的能長期運作。這個習(xí)慣幫我擋掉了很多后期麻煩也算是一次次踩坑之后的自我修正吧。