1. 大模型 Demo 和可用產(chǎn)品之間隔著一條什么河這兩年我參與過不少 AI 輔助軟件的評(píng)審和落地也幫幾個(gè)團(tuán)隊(duì)做過從原型到上線的技術(shù)把關(guān)。一個(gè)越來越明顯的現(xiàn)象是大模型 Demo 跑通的那一刻往往是團(tuán)隊(duì)信心最膨脹、也最容易翻車的時(shí)刻。你在本地用幾十行代碼調(diào)通一個(gè)接口輸入一段文字模型吐出一段像模像樣的回答演示給領(lǐng)導(dǎo)看掌聲一片。然后呢然后就沒有然后了——真正推到用戶面前問題像潮水一樣涌上來。我先把結(jié)論擺在前面Demo 驗(yàn)證的是“模型能不能出結(jié)果”產(chǎn)品驗(yàn)證的是“結(jié)果在真實(shí)場(chǎng)景下能不能穩(wěn)定、可控、可解釋、可兜底”。這兩件事的難度差了一個(gè)數(shù)量級(jí)。Demo 是實(shí)驗(yàn)室里的理想氣體產(chǎn)品是工地上的混凝土——配比、養(yǎng)護(hù)、承重、裂縫控制每一項(xiàng)都得單獨(dú)較真。這篇文章想聊的就是這條河怎么過。適合誰看如果你正在做 AI 輔助軟件的產(chǎn)品化或者你是個(gè)開發(fā)者手里有個(gè)跑得挺歡的大模型 Demo正準(zhǔn)備往生產(chǎn)環(huán)境推那這篇內(nèi)容應(yīng)該能幫你省下不少返工的時(shí)間。我會(huì)從整體設(shè)計(jì)思路、核心細(xì)節(jié)、實(shí)操落地、問題排查幾個(gè)層面把“Demo 到產(chǎn)品”這段路拆開講盡量說人話也盡量給能直接抄的作業(yè)。先明確一個(gè)概念邊界。我這里說的“AI 輔助軟件”指的是把大模型能力嵌入到具體業(yè)務(wù)流程里、幫用戶完成某類任務(wù)的工具型產(chǎn)品比如文檔輔助、代碼輔助、客服輔助、設(shè)計(jì)輔助這類。它不是一個(gè)純聊天窗口而是有明確任務(wù)閉環(huán)的軟件。這類產(chǎn)品對(duì)穩(wěn)定性和可控性的要求比一個(gè)開放域聊天機(jī)器人要高得多因?yàn)橛脩羰菐е唧w目的來的答非所問一次信任就掉一截。2. 內(nèi)容整體設(shè)計(jì)與思路拆解2.1 為什么 Demo 思維會(huì)害了你Demo 思維的核心特征是以“能跑通”為終點(diǎn)。開發(fā)者關(guān)心的是接口通不通、返回有沒有內(nèi)容、格式對(duì)不對(duì)。只要這幾項(xiàng)過了就覺得事情成了。但產(chǎn)品思維的核心是以“用戶任務(wù)完成”為終點(diǎn)。用戶關(guān)心的是我這件事辦沒辦成、辦得對(duì)不對(duì)、出錯(cuò)了怎么辦、下次還敢不敢用。這兩種思維的差距體現(xiàn)在幾個(gè)具體維度上。我列個(gè)表對(duì)比一下你對(duì)照自己的項(xiàng)目看看處在哪一檔。維度Demo 階段產(chǎn)品階段輸入精心挑選的樣例千奇百怪的真實(shí)輸入輸出有內(nèi)容即可準(zhǔn)確、合規(guī)、格式穩(wěn)定延遲能等就行有明確上限超時(shí)要兜底成本不計(jì)較每次調(diào)用都要算賬失敗重試或忽略必須有降級(jí)和提示數(shù)據(jù)用完就扔留存、脫敏、可追溯迭代改代碼重啟灰度、回滾、監(jiān)控這張表不是嚇唬人是我踩過坑之后總結(jié)的。Demo 階段你面對(duì)的是“最好情況”產(chǎn)品階段你面對(duì)的是“最壞情況”。而產(chǎn)品的口碑恰恰是由最壞情況決定的。2.2 從 Demo 到產(chǎn)品的三層架構(gòu)思路我的建議是把整個(gè)系統(tǒng)拆成三層來設(shè)計(jì)這樣每一層的問題可以獨(dú)立解決不會(huì)互相污染。第一層是模型層。這一層負(fù)責(zé)“生成”核心問題是選型、微調(diào)、提示詞工程、上下文管理。你要決定用哪個(gè)大模型、要不要私有化部署、上下文長(zhǎng)度設(shè)多少、要不要做微調(diào)。這一層的產(chǎn)出是“原始生成結(jié)果”。第二層是編排層。這一層負(fù)責(zé)“控制”核心問題是任務(wù)拆解、多步調(diào)用、結(jié)果校驗(yàn)、格式約束、重試策略。大模型不是萬能的很多任務(wù)需要拆成多步中間還要做校驗(yàn)和修正。這一層的產(chǎn)出是“經(jīng)過校驗(yàn)的候選結(jié)果”。第三層是產(chǎn)品層。這一層負(fù)責(zé)“交付”核心問題是交互設(shè)計(jì)、錯(cuò)誤提示、降級(jí)方案、數(shù)據(jù)留存、成本控制。用戶看到的是這一層前面兩層再漂亮這一層拉胯產(chǎn)品就是不行。為什么要這么分因?yàn)椴煌瑢拥膯栴}解決手段完全不同。模型層的問題靠選型和調(diào)參編排層的問題靠工程邏輯產(chǎn)品層的問題靠交互和運(yùn)營(yíng)?；煸谝黄鸶耐前聪潞J浮起瓢。我見過太多團(tuán)隊(duì)用戶反饋“答得不準(zhǔn)”他們就去換模型結(jié)果換了模型發(fā)現(xiàn)是提示詞的問題又去改提示詞改完發(fā)現(xiàn)是上下文截?cái)鄬?dǎo)致的。分層之后定位問題的效率會(huì)高很多。2.3 方案選型背后的取舍邏輯選型這件事沒有標(biāo)準(zhǔn)答案只有取舍。我把我做過的幾次選型決策的邏輯說一下你可以參考這個(gè)思路。要不要私有化部署這個(gè)問題的核心不是技術(shù)是數(shù)據(jù)敏感度和成本。如果業(yè)務(wù)數(shù)據(jù)涉及用戶隱私或商業(yè)機(jī)密那私有化部署基本是必選項(xiàng)。但私有化部署意味著你要自己扛硬件成本、運(yùn)維成本、模型更新成本。我一般會(huì)算一筆賬把預(yù)期的日均調(diào)用量、單次調(diào)用的平均 token 數(shù)、模型的顯存占用估出來再對(duì)比云服務(wù)的按量計(jì)費(fèi)看哪個(gè)更劃算。小規(guī)模起步階段云服務(wù)通常更靈活規(guī)模上來之后私有化部署的邊際成本優(yōu)勢(shì)才顯現(xiàn)。要不要微調(diào)微調(diào)不是萬能藥。很多團(tuán)隊(duì)一上來就想微調(diào)覺得微調(diào)了模型就“懂業(yè)務(wù)”了。但實(shí)際上大部分場(chǎng)景下好的提示詞工程加上少量示例效果已經(jīng)夠用。微調(diào)適合的是任務(wù)格式非常固定、對(duì)輸出風(fēng)格有強(qiáng)要求、或者需要模型掌握特定領(lǐng)域術(shù)語的場(chǎng)景。微調(diào)的成本不只是訓(xùn)練那一下還有數(shù)據(jù)標(biāo)注、效果評(píng)估、版本管理、后續(xù)更新這些隱性成本很高。我的建議是先用提示詞和檢索增強(qiáng)頂一頂確實(shí)頂不住了再考慮微調(diào)。上下文長(zhǎng)度設(shè)多少這個(gè)直接關(guān)系到成本和效果。上下文越長(zhǎng)單次調(diào)用越貴而且模型對(duì)長(zhǎng)上下文的注意力會(huì)衰減中間部分的信息容易被忽略。我的經(jīng)驗(yàn)是能短則短把最相關(guān)的信息放在開頭和結(jié)尾。如果任務(wù)需要長(zhǎng)文檔優(yōu)先考慮分段處理加摘要而不是一股腦塞進(jìn)去。3. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)3.1 提示詞工程從“能答”到“答得對(duì)”提示詞是 Demo 和產(chǎn)品之間最容易被低估的一環(huán)。Demo 里你可能就寫了一句“請(qǐng)幫我總結(jié)這段文字”產(chǎn)品里這句話得變成一套結(jié)構(gòu)化的指令。我常用的提示詞結(jié)構(gòu)是這樣的角色設(shè)定 任務(wù)描述 輸入數(shù)據(jù) 輸出格式 約束條件 示例。這六塊不一定每次都用但結(jié)構(gòu)化的思路要有。舉個(gè)例子假設(shè)你做一個(gè)合同條款輔助審查的工具。Demo 版的提示詞可能是“幫我看看這份合同有沒有問題?！碑a(chǎn)品版的提示詞應(yīng)該是你是一名合同審查輔助助手負(fù)責(zé)識(shí)別合同中的風(fēng)險(xiǎn)條款。 任務(wù)閱讀以下合同文本找出其中可能對(duì)甲方不利的條款。 輸入{合同文本} 輸出格式以 JSON 數(shù)組返回每個(gè)元素包含 clause條款原文、risk風(fēng)險(xiǎn)說明、level風(fēng)險(xiǎn)等級(jí)高/中/低。 約束只返回確實(shí)存在風(fēng)險(xiǎn)的條款不要臆造如果未發(fā)現(xiàn)風(fēng)險(xiǎn)返回空數(shù)組。 示例{一個(gè)標(biāo)準(zhǔn)示例}這個(gè)結(jié)構(gòu)的好處是輸出可解析、可校驗(yàn)、可展示。Demo 階段你可能直接看模型返回的文字產(chǎn)品階段你需要程序去解析這個(gè)結(jié)果所以格式必須固定。注意提示詞里的示例非常關(guān)鍵它比任何描述都更能約束模型的輸出風(fēng)格。但示例不要太多兩三個(gè)足夠太多會(huì)擠占上下文也會(huì)讓模型過度模仿示例而忽略實(shí)際輸入。還有一個(gè)實(shí)操心得把提示詞當(dāng)成代碼來管理。版本化、可回滾、有測(cè)試用例。我見過團(tuán)隊(duì)把提示詞硬編碼在業(yè)務(wù)代碼里改一次要發(fā)一次版效率極低。正確的做法是把提示詞抽出來放在配置里配合一套回歸測(cè)試集每次改動(dòng)都跑一遍看效果有沒有退化。3.2 輸出校驗(yàn)別信模型要驗(yàn)?zāi)Ｐ痛竽Ｐ偷妮敵鍪遣淮_定的這是它的特性不是 bug。產(chǎn)品里必須假設(shè)“模型隨時(shí)可能輸出亂七八糟的東西”然后設(shè)計(jì)校驗(yàn)機(jī)制。校驗(yàn)分幾層。第一層是格式校驗(yàn)檢查返回是不是合法 JSON、字段全不全、類型對(duì)不對(duì)。第二層是內(nèi)容校驗(yàn)檢查關(guān)鍵字段有沒有超出預(yù)期范圍比如風(fēng)險(xiǎn)等級(jí)只能是高/中/低出現(xiàn)了別的值就是異常。第三層是業(yè)務(wù)校驗(yàn)結(jié)合業(yè)務(wù)規(guī)則判斷結(jié)果是否合理比如合同審查里如果模型說某個(gè)條款有風(fēng)險(xiǎn)但這個(gè)條款其實(shí)是標(biāo)準(zhǔn)條款那就需要人工復(fù)核。校驗(yàn)不通過怎么辦重試是下策兜底是中策預(yù)防是上策。重試會(huì)增加延遲和成本而且模型可能反復(fù)犯同樣的錯(cuò)。兜底是給用戶一個(gè)“暫時(shí)無法處理”的提示體驗(yàn)不好但至少不崩。預(yù)防是在提示詞和編排層就把可能的錯(cuò)誤堵住比如用結(jié)構(gòu)化輸出約束、用少樣本示例引導(dǎo)。我實(shí)測(cè)下來結(jié)構(gòu)化輸出約束比如要求返回 JSON配合格式校驗(yàn)?zāi)軗醯舸蟛糠值图?jí)錯(cuò)誤。但要注意有些模型對(duì) JSON 格式的支持不穩(wěn)定可能會(huì)在 JSON 外面包一層文字這時(shí)候需要寫個(gè)解析器把 JSON 摳出來。3.3 上下文管理長(zhǎng)文檔怎么喂長(zhǎng)文檔處理是 AI 輔助軟件的常見需求也是 Demo 最容易翻車的地方。Demo 里你可能直接截取前幾千字丟進(jìn)去產(chǎn)品里用戶上傳的是一份幾十頁的文檔怎么辦我的做法是分段 摘要 檢索。先把文檔按語義切成小塊每塊做一個(gè)摘要然后根據(jù)用戶的具體問題檢索出最相關(guān)的幾塊連同摘要一起喂給模型。這樣既控制了上下文長(zhǎng)度又保證了相關(guān)性。切分的時(shí)候有個(gè)細(xì)節(jié)不要按固定字?jǐn)?shù)硬切要按語義邊界切。比如按段落、按章節(jié)、按標(biāo)題切。硬切會(huì)把一句話切成兩半模型理解起來會(huì)出問題。如果文檔沒有明顯的結(jié)構(gòu)可以用一些啟發(fā)式規(guī)則比如按句號(hào)、換行符切再合并過短的塊。檢索這塊可以用關(guān)鍵詞匹配也可以用向量檢索。向量檢索效果通常更好但需要額外的嵌入模型和向量庫成本高一些。我的建議是文檔量小的時(shí)候用關(guān)鍵詞量大了再上向量。不要一上來就搞復(fù)雜的架構(gòu)先用簡(jiǎn)單的方案跑通遇到瓶頸再升級(jí)。提示上下文里的信息順序會(huì)影響模型的表現(xiàn)。我一般把最相關(guān)的信息放在開頭把任務(wù)指令放在結(jié)尾中間放補(bǔ)充材料。這樣模型在生成時(shí)最近的指令和最早的關(guān)鍵信息都在注意力范圍內(nèi)。3.4 成本控制每一次調(diào)用都是錢Demo 階段你可能不在乎成本產(chǎn)品階段成本直接決定商業(yè)模式能不能成立。我算過一筆賬如果一個(gè)功能每次調(diào)用消耗 2000 個(gè) token按某個(gè)模型的定價(jià)一天一萬次調(diào)用一個(gè)月下來就是一筆不小的開支。如果這個(gè)功能是免費(fèi)的那成本就是純虧損?？刂瞥杀镜氖侄斡袔讉€(gè)。一是緩存相同或相似的輸入直接返回緩存結(jié)果不重復(fù)調(diào)用。二是分級(jí)簡(jiǎn)單任務(wù)用小模型復(fù)雜任務(wù)用大模型。三是壓縮把提示詞和上下文精簡(jiǎn)到最少必要信息。四是限流對(duì)免費(fèi)用戶設(shè)置調(diào)用頻率上限。緩存這塊有個(gè)坑大模型的輸出是不確定的同樣的輸入可能得到不同的輸出。所以緩存的時(shí)候要接受“緩存結(jié)果可能和實(shí)時(shí)結(jié)果略有差異”或者把溫度參數(shù)設(shè)低讓輸出盡量穩(wěn)定。我一般對(duì)格式固定、答案唯一的任務(wù)用緩存對(duì)創(chuàng)意類任務(wù)不用。分級(jí)策略也很實(shí)用。比如一個(gè)客服輔助工具用戶問“退貨政策是什么”這種問題用小模型加檢索就能答用戶問“我這個(gè)訂單為什么還沒發(fā)貨”這種需要查數(shù)據(jù)庫、做推理的再用大模型。不是所有任務(wù)都值得用最貴的模型。4. 實(shí)操過程與核心環(huán)節(jié)實(shí)現(xiàn)4.1 環(huán)境準(zhǔn)備與模型接入假設(shè)你現(xiàn)在要從零搭一個(gè) AI 輔助軟件的產(chǎn)品化框架我按我的習(xí)慣走一遍流程。首先是環(huán)境。Python 環(huán)境是標(biāo)配建議用虛擬環(huán)境隔離依賴。核心依賴包括模型調(diào)用 SDK、Web 框架比如 FastAPI、向量庫如果需要檢索、緩存組件比如 Redis。如果你打算私有化部署模型還需要考慮推理框架和硬件。模型接入這塊我建議抽象一層接口不要把某個(gè)具體模型的調(diào)用代碼散落在業(yè)務(wù)里。定義一個(gè)統(tǒng)一的調(diào)用接口輸入是提示詞和參數(shù)輸出是生成結(jié)果和元信息token 數(shù)、耗時(shí)等。這樣以后換模型、加模型只需要改這一層。class LLMClient: def generate(self, prompt, temperature0.7, max_tokens1000): # 調(diào)用具體模型返回結(jié)果和元信息 pass這層抽象看起來簡(jiǎn)單但能省很多事。我見過項(xiàng)目里直接調(diào)某家 API 的代碼寫了幾十處后來要換模型改到崩潰。4.2 提示詞模板與版本管理提示詞不要硬編碼。我一般用一個(gè)模板文件管理每個(gè)模板有 ID、版本、內(nèi)容、適用場(chǎng)景。業(yè)務(wù)代碼通過 ID 引用模板模板更新不影響業(yè)務(wù)代碼。templates: contract_review: version: 3 content: | 你是一名合同審查輔助助手... variables: - contract_text版本管理的好處是你可以同時(shí)保留多個(gè)版本做 A/B 測(cè)試也可以快速回滾。每次改提示詞先在小流量上驗(yàn)證效果好了再全量。4.3 編排層的任務(wù)拆解復(fù)雜任務(wù)不要指望一次調(diào)用解決。我以“合同審查”為例拆一下編排邏輯。第一步文檔解析。把上傳的合同文件可能是 PDF、Word轉(zhuǎn)成純文本保留段落結(jié)構(gòu)。這一步用現(xiàn)成的解析庫就行注意處理表格和特殊格式。第二步分段與摘要。把合同按條款切分每段生成一個(gè)簡(jiǎn)短摘要。摘要的作用是后續(xù)檢索和上下文壓縮。第三步風(fēng)險(xiǎn)識(shí)別。對(duì)每個(gè)條款調(diào)用模型判斷是否有風(fēng)險(xiǎn)。這一步可以并行處理提高速度。第四步結(jié)果聚合。把所有條款的風(fēng)險(xiǎn)結(jié)果匯總按風(fēng)險(xiǎn)等級(jí)排序生成最終報(bào)告。第五步人工復(fù)核入口。高風(fēng)險(xiǎn)條款標(biāo)記出來提供人工復(fù)核的界面。這個(gè)流程里第三步是核心也是最容易出問題的。我的經(jīng)驗(yàn)是單條款判斷比整篇判斷準(zhǔn)確率高很多因?yàn)樯舷挛亩棠Ｐ妥⒁饬小５珕螚l款判斷會(huì)丟失條款之間的關(guān)聯(lián)所以第四步聚合的時(shí)候要加一些規(guī)則來補(bǔ)充比如“如果付款條款和交付條款的風(fēng)險(xiǎn)同時(shí)存在整體風(fēng)險(xiǎn)等級(jí)要上調(diào)”。4.4 產(chǎn)品層的交互與兜底用戶看到的界面要處理好幾種狀態(tài)正常返回、部分返回、超時(shí)、失敗。正常返回不用多說。部分返回是指模型只處理了一部分內(nèi)容比如合同太長(zhǎng)只分析了前一半。這時(shí)候要明確告訴用戶“已分析前 X 條剩余部分正在處理”而不是假裝全部完成了。超時(shí)要有進(jìn)度提示讓用戶知道系統(tǒng)還在工作。失敗要給明確的錯(cuò)誤信息和下一步建議比如“當(dāng)前請(qǐng)求較多請(qǐng)稍后重試”或者“該文檔格式暫不支持請(qǐng)轉(zhuǎn)換為 PDF 后重試”。注意錯(cuò)誤提示不要暴露技術(shù)細(xì)節(jié)比如“模型返回 500”這種話對(duì)用戶毫無意義。要說人話告訴用戶發(fā)生了什么、能做什么。還有一個(gè)細(xì)節(jié)給用戶反饋的入口。用戶覺得結(jié)果不對(duì)要能一鍵反饋。這些反饋數(shù)據(jù)是后續(xù)優(yōu)化提示詞和微調(diào)的寶貴素材。我一般會(huì)在結(jié)果旁邊放一個(gè)“有幫助/沒幫助”的按鈕再配一個(gè)可選的文本框讓用戶說明原因。5. 常見問題與排查技巧實(shí)錄5.1 輸出不穩(wěn)定同樣的輸入結(jié)果差異大這是最常見的問題。原因通常是溫度參數(shù)設(shè)太高或者提示詞約束不夠。解決辦法把溫度降到 0.2 以下增加輸出格式約束增加少樣本示例。如果還是不穩(wěn)定考慮用結(jié)構(gòu)化輸出或者后處理校驗(yàn)來兜底。5.2 模型答非所問忽略指令通常是提示詞太長(zhǎng)關(guān)鍵指令被淹沒。解決辦法把核心指令放在提示詞的開頭和結(jié)尾中間放補(bǔ)充信息。另外檢查一下上下文是不是超了模型的有效長(zhǎng)度超長(zhǎng)會(huì)導(dǎo)致模型“忘記”前面的內(nèi)容。5.3 處理長(zhǎng)文檔時(shí)速度慢、成本高分段處理加檢索是標(biāo)準(zhǔn)解法。如果文檔特別長(zhǎng)可以考慮先做一次粗篩把明顯不相關(guān)的段落去掉再對(duì)剩下的做精細(xì)處理。另外并行調(diào)用能顯著降低總耗時(shí)但要注意控制并發(fā)數(shù)避免觸發(fā)接口限流。5.4 模型輸出包含不當(dāng)內(nèi)容這是產(chǎn)品化必須面對(duì)的問題。解決辦法分兩層輸入層做過濾把明顯不當(dāng)?shù)恼?qǐng)求擋掉輸出層做校驗(yàn)對(duì)生成結(jié)果做敏感詞和合規(guī)檢查。如果業(yè)務(wù)場(chǎng)景對(duì)合規(guī)要求高建議加一道人工審核或者用專門的審核模型。5.5 成本超預(yù)期先做成本歸因看錢花在哪里了。是調(diào)用次數(shù)太多還是單次 token 太多還是用了太貴的模型。然后針對(duì)性優(yōu)化加緩存、做分級(jí)、壓縮上下文、限流。我一般會(huì)設(shè)一個(gè)成本告警超過閾值就通知避免月底看賬單嚇一跳。問題現(xiàn)象可能原因排查方向解決手段輸出格式錯(cuò)亂提示詞約束不足檢查輸出格式描述加結(jié)構(gòu)化約束和示例答非所問指令被淹沒檢查提示詞長(zhǎng)度和結(jié)構(gòu)核心指令前置后置長(zhǎng)文檔處理慢上下文過長(zhǎng)看 token 消耗分段加檢索內(nèi)容不合規(guī)缺少過濾檢查輸入輸出加過濾和審核成本飆升調(diào)用量或 token 失控看用量統(tǒng)計(jì)緩存、分級(jí)、限流5.6 幾個(gè)我踩過的坑第一個(gè)坑以為換了更強(qiáng)的模型就能解決所有問題。實(shí)際上很多問題是提示詞和編排的問題換模型只是治標(biāo)。我建議先把提示詞和流程優(yōu)化到位再考慮換模型。第二個(gè)坑忽略冷啟動(dòng)階段的數(shù)據(jù)積累。產(chǎn)品剛上線用戶量小反饋少這時(shí)候要有意識(shí)地收集數(shù)據(jù)哪怕是人工標(biāo)注一些樣例對(duì)后續(xù)優(yōu)化幫助很大。第三個(gè)坑把 Demo 的評(píng)估標(biāo)準(zhǔn)帶到產(chǎn)品。Demo 階段你可能看幾個(gè)樣例覺得不錯(cuò)就過了產(chǎn)品階段要有系統(tǒng)的評(píng)估集覆蓋各種邊界情況每次改動(dòng)都跑一遍用數(shù)據(jù)說話。6. 一些關(guān)于落地節(jié)奏的個(gè)人體會(huì)做 AI 輔助軟件最忌諱的就是“一步到位”的心態(tài)。我見過團(tuán)隊(duì)想一次性把功能做全、做完美結(jié)果拖了半年沒上線市場(chǎng)窗口錯(cuò)過了。我的建議是小步快跑先上線一個(gè)最小可用版本哪怕它只覆蓋 60% 的場(chǎng)景先讓用戶用起來收集真實(shí)反饋再迭代。真實(shí)用戶的輸入永遠(yuǎn)比你想象的更離譜。你在 Demo 階段設(shè)計(jì)的那些邊界情況可能只覆蓋了真實(shí)情況的十分之一。只有上線了你才知道用戶會(huì)怎么用、會(huì)在哪里卡住、會(huì)對(duì)什么結(jié)果不滿意。這些信息坐在辦公室里是想不出來的。另外不要把大模型當(dāng)成黑盒魔法。它是個(gè)工具有它的脾氣和局限。理解它的原理知道它擅長(zhǎng)什么、不擅長(zhǎng)什么才能用好它。比如它擅長(zhǎng)語言理解和生成不擅長(zhǎng)精確計(jì)算和事實(shí)核查那涉及數(shù)字和事實(shí)的部分就要用外部工具來補(bǔ)而不是硬讓模型去算。最后分享一個(gè)我常用的判斷標(biāo)準(zhǔn)如果一個(gè)功能模型答錯(cuò)了用戶會(huì)遭受明顯損失那這個(gè)功能就不能完全交給模型必須有人工復(fù)核或者強(qiáng)校驗(yàn)。AI 輔助關(guān)鍵詞是“輔助”最終決策權(quán)要留在人手里。這個(gè)邊界劃清楚了產(chǎn)品的定位和設(shè)計(jì)思路也就清晰了。