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