每年高考出分后的那兩周是做志愿咨詢類產(chǎn)品的團隊最緊張的時候。我在這行折騰過好幾個版本也踩過不少坑今天拿“高考志愿AI”這個場景把FDE落地時最關(guān)鍵的一層窗戶紙捅破AI到底應(yīng)該怎么“給建議”而不是“替人做決定”先把這個系列里我理解的FDE定義一下。FDE不是某個神秘框架而是 Feature-Driven Engineering功能驅(qū)動工程。核心思路是先把用戶真實場景里的功能拆出來再決定哪些環(huán)節(jié)用大模型、哪些環(huán)節(jié)用規(guī)則、哪些環(huán)節(jié)必須讓人來確認。這套思路用在高考志愿AI上特別合適因為這個場景容錯率極低一條建議錯了影響的是一個年輕人接下來四年的軌跡。這篇文章不是教你怎么搭一個看起來能聊天的空殼而是講清楚“參謀式AI”的功能拆解、實現(xiàn)細節(jié)和避坑經(jīng)驗。不管你是準(zhǔn)備用大模型做類似教育咨詢產(chǎn)品還是單純對AI輔助決策的邊界感興趣下面這些內(nèi)容都值得耐心看完。1. 項目整體設(shè)計與思路拆解1.1 先把“建議”和“決定”的邊界畫出來做高考志愿AI之前我團隊內(nèi)部先吵了一輪產(chǎn)品到底該做到哪一步有人覺得AI應(yīng)該直接輸出“你就報A大學(xué)B專業(yè)”體驗直接、轉(zhuǎn)化率高也有人堅持做“參謀”型給信息、給對比、給風(fēng)險提示最后讓學(xué)生和家長自己拍板。后來我們達成一致AI可以無限逼近一個資深咨詢師但絕不能扮演家長的角色。資深咨詢師怎么干活他會問你的分數(shù)、位次、選科、想去哪個城市、家里經(jīng)濟條件如何、有沒有特別感興趣的專業(yè)然后給你三五個方案告訴你每個方案的收益和風(fēng)險最后加一句“這個選擇最終還是看你”。這背后有個很樸素的理由志愿填報是一個高度個人化的決策。同一個位次有人愿意去偏遠985圖個名校光環(huán)有人寧可留在本省上個普通一本方便就業(yè)這兩種選擇沒有絕對的對錯。AI如果默認了一套價值排序就是在替用戶做價值判斷——這比給錯一個數(shù)據(jù)更危險。所以項目啟動的第一件事不是調(diào)模型而是寫一份“功能邊界文檔”。這份文檔明確了幾條硬約束所有輸出必須包含“前提假設(shè)”和“不確定度”最終給的是“方案集合”不是“唯一答案”硬性限制選科、體檢、招生要求用規(guī)則引擎攔截不讓大模型自由發(fā)揮這個過程其實就是FDE的“需求澄清”環(huán)節(jié)。很多AI項目翻車不是模型不行而是一開始就沒想清楚功能邊界最后做出來的東西既不像工具也不像專家。1.2 替人做決定的AI為什么必然會翻車把“替人決定”這條路堵死不是道德潔癖而是純技術(shù)層面的理性選擇。我總結(jié)下來有三個很現(xiàn)實的原因。第一信息永遠是不完備的?？忌恼鎸嵠糜袝r連他自己都說不清。你說“我想學(xué)計算機”但他可能只是覺得程序員收入高實際上完全不能接受每天面對代碼的生活。AI再強也讀不到這些隱藏信息。模型基于一個殘缺的畫像強行輸出唯一答案本質(zhì)上就是閉著眼睛做判斷。第二價值排序因人而異。有的家庭認為“城市 學(xué)校 專業(yè)”有的認為“專業(yè) 學(xué)校 城市”還有的認為只要離家近什么都好。這些排序沒有對錯但會徹底改變最優(yōu)解。AI一旦在Prompt里預(yù)設(shè)了“學(xué)校越好越值得報”就已經(jīng)失去客觀性了。第三責(zé)任鏈會反噬產(chǎn)品。志愿填報出問題之后用戶的情緒是非常強烈的。如果AI當(dāng)初信誓旦旦說“按這個順序填肯定沒問題”最后滑檔了用戶不會怪大模型只會怪這個產(chǎn)品。但如果你給的是“三個方案風(fēng)險分析”用戶自己做了選擇他會把這次經(jīng)歷理解為“我綜合了各方信息后的決定”對產(chǎn)品的質(zhì)疑就會小很多。所以設(shè)計系統(tǒng)時我反復(fù)強調(diào)一句話AI負責(zé)把決策所需的信息成本降到最低把決策權(quán)完整留在用戶手里。這句話是后面所有Prompt、所有規(guī)則、所有交互設(shè)計的總綱。1.3 FDE視角下的用戶旅程拆解用FDE方法做這個項目第一步不是寫代碼而是畫用戶旅程。我把一次完整的志愿咨詢拆成了六段信息采集分數(shù)、位次、省份、選科、體檢情況偏好澄清城市傾向、專業(yè)方向、學(xué)校層次接受度候選生成根據(jù)硬條件和偏好召回一批可報院校梯度分析把候選分為“沖、穩(wěn)、?！比龣n方案展示讓用戶看到每個方案的優(yōu)劣和權(quán)衡風(fēng)險確認提示退檔風(fēng)險、專業(yè)調(diào)劑風(fēng)險、就業(yè)不確定每一段都要回答三個問題這段要什么數(shù)據(jù)這段該不該用大模型這段的結(jié)果怎么防錯有意思的是拆完之后我們發(fā)現(xiàn)真正適合大模型的只有第2段和第5段。第1段和第6段是典型的結(jié)構(gòu)化表單和規(guī)則判斷第3段和第4段用結(jié)構(gòu)化查詢加打分腳本更可靠。這個結(jié)論可能出乎很多人的意料但偏偏就是這個“少用大模型”的決策讓整個系統(tǒng)的穩(wěn)定性和可信度上了一個臺階。后面我會詳細說每段怎么實現(xiàn)。2. 核心功能實現(xiàn)與實操細節(jié)2.1 一個Agent底座讓對話有狀態(tài)很多新手做對話型AI直接調(diào)大模型API一問一答發(fā)現(xiàn)用戶多聊幾句就暈了。原因是大模型沒有會話狀態(tài)——你上句話說完它記不住有位次、選科、地域這些關(guān)鍵信息。我在項目里搭的是一個很輕的Agent底座核心就三件東西狀態(tài)槽位、意圖路由、動作調(diào)度。狀態(tài)槽位是一張表記錄了當(dāng)前對話里已經(jīng)收集到的字段比如位次、省份、選科組合、城市偏好意圖路由負責(zé)判斷用戶這句話是在回答問題、提出新要求還是修正信息動作調(diào)度則決定下一步調(diào)用搜索工具、評分腳本還是直接生成文案。這套東西不復(fù)雜但能解決90%的“對話失憶”問題。比如用戶先說“我是四川考生理科位次12000”聊了一會兒又問“那成都的學(xué)校有哪些能報”系統(tǒng)能從槽位里拿出來“四川、理科、12000”去查而不是讓用戶重新說一遍。做主控的時候我的經(jīng)驗是用狀態(tài)機管流程用大模型管表達。狀態(tài)機保證每個環(huán)節(jié)不遺漏大模型把用戶表達轉(zhuǎn)換成結(jié)構(gòu)化意圖再用規(guī)則把意圖映射到動作。完全依賴大模型做狀態(tài)跳轉(zhuǎn)我試過復(fù)雜對話下經(jīng)常出現(xiàn)不可控的跳變。2.2 關(guān)鍵Prompt把自己定位成“參謀”而不是“家長”Prompt是整個“給建議”體驗的靈魂。我最初的版本寫的角色設(shè)定是“你是高考志愿專家”結(jié)果模型輸出非常教科書喜歡用“應(yīng)該報考”“建議首選”這類指令式口吻。后來我把角色描述改成了一段很長的“參謀行為守則”效果立刻不一樣。下面這段Prompt模板經(jīng)過了幾輪線上驗證你可以直接參考你是一名高考志愿輔助參謀任務(wù)不是替用戶做決定而是幫用戶把選擇空間看全、看懂。 你在回答時必須遵守以下原則 1. 不要使用“你應(yīng)該”“我推薦你直接報”這類表達改用“如果看重...可以優(yōu)先考慮...”“相比而言...更適合...”。 2. 每條實質(zhì)建議都要附帶依據(jù)依據(jù)可以是往年位次、招生計劃、院校層次、專業(yè)方向也可以是明確的常識性假設(shè)。 3. 如果你使用的信息存在不確定性必須說明“這個數(shù)據(jù)存在波動”或“這是我基于你剛才提供的信息做的推斷”。 4. 在給出方案時同時輸出方案的收益、代價和潛在風(fēng)險不得只講優(yōu)點。 5. 如果用戶的提問信息不足禁止直接開藥方先列明“我還需要了解的信息”。 6. 不允許用絕對化表述禁止出現(xiàn)“一定錄取”“肯定穩(wěn)”“百分百不會退檔”等說法。這段Prompt的價值不是讓模型更聰明而是給模型的表達套上了一條護欄。很多用戶分不清AI是在建議還是在指揮往往就是被幾個詞影響的。把“你應(yīng)該”換成“如果你更看重...那么...”整個對話的主動權(quán)就回到了用戶那邊。2.3 讓輸出可追溯、可反駁就算Prompt寫得再好大模型也難免編數(shù)據(jù)。為了減少這種“一本正經(jīng)胡說八道”我給系統(tǒng)加了一個硬性要求模型輸出必須走JSON格式且所有數(shù)據(jù)類結(jié)論必須帶上來源ID。具體做法是讓輸出符合這樣一個結(jié)構(gòu){ assumptions: [用戶希望留本省就業(yè)], options: [ { school: 某大學(xué), major: 軟件工程, evidence: [ {type: 位次, value: 去年最低錄取位次約9000, source_id: data_2024_sichuan_0032}, {type: 招生人數(shù), value: 2025年計劃招生120人, source_id: plan_2025_sichuan_0032} ], risk: 該校在四川投檔線近年波動較大存在大小年現(xiàn)象, uncertainty: 中 } ] }為什么強制JSON而不是直接生成自然語言因為JSON格式讓下游校驗變得非常容易。程序可以先檢查每個source_id是否能檢索到再檢查位次數(shù)字是否在合理區(qū)間。如果模型幻覺出了一個根本不存在的專業(yè)校驗?zāi)K直接丟棄這條結(jié)果而不是讓它混進最終文案。用戶界面上還會加一個“為什么推薦這所”的按鈕點擊后展開的正是這些證據(jù)ID和原始數(shù)據(jù)截圖。這個功能極大提升了用戶信任感——很多人一開始懷疑AI但看到AI能把依據(jù)攤開反而愿意聊得更多。2.4 多AI協(xié)作別讓一個大模型干所有事項目做到中期我發(fā)現(xiàn)讓一個模型既做意圖理解、又做信息檢索、又做方案推薦、又做風(fēng)險審查效果非常不穩(wěn)定。同時并發(fā)量上來后一次調(diào)用能省幾十毫秒都是好的可功能混在一起導(dǎo)致 Prompt 越來越長反而拖慢響應(yīng)。后來我按“多AI協(xié)作”的思路把系統(tǒng)拆成了四個角色子看門領(lǐng)航員Agent負責(zé)對話主流程維護槽位判斷什么時候該問、什么時候該答檢索Agent接收結(jié)構(gòu)化查詢條件從本地知識庫和數(shù)據(jù)庫中檢索院校專業(yè)信息分析Agent接收“沖穩(wěn)?！碧荻冉Y(jié)果生成自然語言解釋質(zhì)檢Agent對任意Agent的輸出做合規(guī)檢查攔截絕對化表達、非法院校名稱、過期分數(shù)線這些子Agent可以共用一個大模型底座但Prompt各自獨立也可以把某些Agent降到規(guī)則腳本。比如“檢索Agent”本質(zhì)上是我寫的一個Python函數(shù)加上少量Embedding召回根本不需要大模型下場“質(zhì)檢Agent”則是一組敏感詞和格式校驗規(guī)則。多AI協(xié)作在實際運行中最大的收益是各個模塊可以獨立升級、單獨測試。我調(diào)分析Agent的口吻時完全不用擔(dān)心檢索數(shù)據(jù)被帶偏發(fā)現(xiàn)質(zhì)檢規(guī)則漏了某個限制條件直接加正則就行不用重新調(diào)Prompt。3. 實操過程與核心環(huán)節(jié)實現(xiàn)3.1 數(shù)據(jù)準(zhǔn)備志愿填報的“食材”先從源頭把關(guān)高考志愿AI的地基不是模型是數(shù)據(jù)。沒有一份干凈的招生計劃和往年錄取數(shù)據(jù)模型說什么都是空中樓閣。這個項目的數(shù)據(jù)準(zhǔn)備我踩過的坑比模型調(diào)優(yōu)踩過的坑多得多。我需要準(zhǔn)備的核心數(shù)據(jù)有四類數(shù)據(jù)域關(guān)鍵字段更新頻率常見問題招生計劃院校代碼、專業(yè)代碼、選科要求、招生人數(shù)每年一次專業(yè)代碼歧義、大小年合并歷年錄取院校、專業(yè)、最低分、最低位次每年一次位次口徑不統(tǒng)一、數(shù)據(jù)缺失院校屬性所在城市、985/211/雙一流、學(xué)科評估低頻院校更名、合并限制規(guī)則體檢限制、單科成績要求、性別限制每年一次規(guī)則分散、描述口語化其中最容易翻車的是招生計劃里的選科要求。新高考改革后每個專業(yè)的選科要求五花八門有的要求“物理化學(xué)”有的要求“物理或化學(xué)均可”。我一開始用規(guī)則腳本解析后來發(fā)現(xiàn)人工整理時經(jīng)常出現(xiàn)“物理和化學(xué)”和“物理或化學(xué)”混在一起導(dǎo)致推薦結(jié)果出錯。最終我干脆把選科要求做成結(jié)構(gòu)化字段每個專業(yè)存一個允許選的組合列表查詢時直接集合運算絕不依賴文本匹配。數(shù)據(jù)清洗是RAG項目的靈魂。院校名稱這一步尤其要小心有些學(xué)校叫“某學(xué)院”實際是一本院校有些叫“某大學(xué)”實際錄取位次很低。建議做一個別名表和層級表把所有官方名稱、簡稱、歷史名稱都映射到一個統(tǒng)一ID上否則向量檢索一召回模型很容易被別名繞暈。3.2 用混合檢索而不是純向量檢索一開始我天真地認為搞個Embedding模型把所有院校專業(yè)信息向量化用戶提問后做相似度檢索就行了。后來發(fā)現(xiàn)高考志愿場景里用戶的問法既有語義模糊的部分“有沒有計算機比較強的學(xué)?！庇钟薪Y(jié)構(gòu)化硬條件“位次12000四川理科”純向量檢索對硬條件的處理非常糟糕。實踐中我更依賴混合檢索粗召回用向量或關(guān)鍵詞先撈出一批候選院校比如按語義匹配“計算機強校”“軟件工程老牌”這類說法精過濾用結(jié)構(gòu)化的硬條件做SQL或內(nèi)存過濾比如位次范圍、選科組合、所在省份、招生名額大于0再排序用規(guī)則評分按“沖穩(wěn)?！贝驑?biāo)簽再讓大模型對Top候選做解釋這一步的核心收獲是大模型只做它擅長的事情——理解語義和生成解釋硬條件篩選一定要交給確定性的代碼。你把“位次12000”丟給大模型讓它自己過濾它就給你漏數(shù)據(jù)但你把經(jīng)過過濾后的候選列表丟給大模型“用自然語言總結(jié)”效果非常穩(wěn)定。我記得第一次混合檢索聯(lián)調(diào)時系統(tǒng)從1200多所院校里篩出來37所符合條件的排序后用戶問“為什么沒有某大學(xué)”一查才發(fā)現(xiàn)那所大學(xué)當(dāng)年沒在四川招生。這就是硬條件過濾的價值——模型可能不知道某校今年不在某省投放計劃但數(shù)據(jù)表知道。3.3 沖穩(wěn)保的評分透明規(guī)則比黑盒概率更好用很多AI產(chǎn)品喜歡給用戶呈現(xiàn)一個“錄取概率85%”的數(shù)字看上去很專業(yè)實際上經(jīng)不起推敲。概率來自歷史數(shù)據(jù)的統(tǒng)計推斷不同年份的位次波動、招生計劃變化都會讓這個數(shù)字嚴重失真。我最終采用的做法是給梯度標(biāo)簽不報精確概率。計算方式用一套公開、可驗證的規(guī)則假設(shè)考生位次為 rank_student 某院校專業(yè)近三年最低位次分別為 p1, p2, p3 取中位數(shù) median_rank。 條件判斷 - 如果 rank_student median_rank * 0.75標(biāo)簽“沖”提示錄取存在不確定性 - 如果 rank_student median_rank * 1.15標(biāo)簽“穩(wěn)”提示錄取把握較大 - 如果 rank_student median_rank * 1.5標(biāo)簽“?！碧崾究勺鳛楸５走x擇 - 其余落在中間區(qū)間的標(biāo)簽“較穩(wěn)”提示屬于正常波動范圍為什么用位次而不是分數(shù)因為高考每年的批次線會變但位次具有跨年可比性。為什么不做精確概率因為樣本量只有三年任何超過兩位小數(shù)的概率都是假精確。用戶看到“沖、穩(wěn)、保”標(biāo)簽后對不同檔位隨便輸入系統(tǒng)還配了一段解釋“沿用近三年最低錄取位次中位數(shù)對比你的位次計算得出。該判斷受招生計劃變動影響僅供參考?！边@樣用戶既理解結(jié)論怎么來的也知道結(jié)論有邊界。后臺另外做了一層“覆蓋率檢查”如果候選方案里保底學(xué)校少于兩所就強制提示“當(dāng)前方案保底不足存在滑檔風(fēng)險”這是規(guī)則層面的最后一條防線。3.4 一次完整的咨詢對話還原紙上談兵沒意思我把系統(tǒng)上線后的一次真實對話簡化出來給你看看“給建議”到底長什么樣。用戶文本輸入我是四川考生理科位次12000左右不想出省對計算機相關(guān)專業(yè)有興趣。系統(tǒng)先做意圖路由和槽位更新確認省份四川、科類理科、位次12000、地域偏好本省、專業(yè)意向計算機。然后系統(tǒng)認為還缺兩個關(guān)鍵信息選科組合和有沒有特別不能接受的專業(yè)類型于是多問了一句。系統(tǒng)已記錄你的基本信息。還想跟你確認兩點你的選科組合是“物理化學(xué)生物”嗎另外你能接受軟件工程、人工智能這類偏應(yīng)用型的專業(yè)嗎還是只考慮傳統(tǒng)的計算機科學(xué)與技術(shù)用戶選科是物理化學(xué)生物專業(yè)方面應(yīng)用型也可以。系統(tǒng)這時才進入候選生成。檢索Agent從數(shù)據(jù)表里篩出四川本地院校、計算機相關(guān)專業(yè)、選科要求匹配、招生計劃向下等條件再用評分腳本打梯度標(biāo)簽。系統(tǒng)輸出的最終回答做了分塊展示核心內(nèi)容大概是這樣沖某大學(xué)“計算機類”去年最低位次約8000屬于沖刺檔。優(yōu)點是985平臺就業(yè)認可度高風(fēng)險是位次差距明顯錄取概率較低且可能被調(diào)劑到非熱門專業(yè)。穩(wěn)某211大學(xué)“軟件工程”去年最低位次約11000比較匹配。該校軟件工程學(xué)科評估不錯成都本地互聯(lián)網(wǎng)就業(yè)機會多風(fēng)險是專業(yè)熱度上升可能拉高位次。保某省屬重點“計算機科學(xué)與技術(shù)”去年最低位次約18000位次充裕?？勺鳛槎档走x項同時該校在大三有校企聯(lián)合培養(yǎng)項目就業(yè)出口穩(wěn)但學(xué)校整體層次低于前兩項。每個條目后都掛了一個“查看依據(jù)”按鈕點擊后能看到近三年的位次曲線和招生計劃數(shù)。最后系統(tǒng)固定加了一句話“以上方案基于你提供的信息和公開錄取數(shù)據(jù)推算最終請結(jié)合你家庭的實際偏好綜合判斷?！睕]有替用戶按下那個確認鍵。用戶看完后追問“那第一所值不值得沖”系統(tǒng)沒直接回答“值”或“不值”而是把兩種決策邏輯擺出來如果更看重名校平臺且能接受專業(yè)被調(diào)劑沖一沖是值得的如果對專業(yè)有明確偏好不接受調(diào)劑那么同檔次的偏冷門院?？赡芨€(wěn)。用戶自己做了權(quán)衡說“我再想想”結(jié)束了對話。3.5 用戶不說清楚時用默認假設(shè)推動對話真實用戶遠比測試集復(fù)雜很多人上來就問“幫我看看能報什么學(xué)?！奔炔惶峁┪淮我膊徽f省份。如果系統(tǒng)機械地回復(fù)“請?zhí)峁┪淮巍睂υ捑屠涞袅?。我后來在領(lǐng)航員Agent里加了一套“默認假設(shè)”機制用戶信息不全時系統(tǒng)可以先按常見情況假設(shè)但必須明確告訴用戶“我先做一個假設(shè)”。比如用戶只說“理科生450分”沒說省份系統(tǒng)會回復(fù)“我先假設(shè)你在四川參加高考如需修改省份請告訴我按去年理科450分對應(yīng)位次約15萬左右你需要把保底學(xué)校數(shù)量提高一些填報策略會偏保守?！边@種回復(fù)既推進了對話又把主動權(quán)留給了用戶。用戶如果糾正槽位更新就行用戶不糾正系統(tǒng)也不會假裝自己無所不知。這個機制上線后對話完成率提升非常明顯。4. 常見問題與排查技巧實錄4.1 模型順嘴編數(shù)據(jù)怎么攔截這是大模型落地所有高嚴謹場景時遇到的頭號問題。我在項目里用了三層攔截第一層輸出約束。Prompt里強制要求所有數(shù)據(jù)必須來自檢索結(jié)果如果檢索結(jié)果里沒有就輸出“未查詢到相關(guān)數(shù)據(jù)”禁止自行估算。這屬于提示詞層面的約束能擋住一部分幻覺但擋不住全部。第二層JSON校驗。模型輸出JSON后程序?qū)λ衧ource_id做存在性檢查對數(shù)字做區(qū)間檢查比如位次不能小于0錄取分數(shù)不能超過總分上限。任何一個字段不合法直接丟棄整條建議并觸發(fā)“重新生成”。實測下來這一層能攔住絕大多數(shù)胡編的數(shù)值。第三層規(guī)則兜底。Query和結(jié)果之間做一個一致性比對。例如用戶選科是“歷史政治地理”但推薦專業(yè)要求“物理化學(xué)”這屬于硬沖突不管模型怎么解釋一律過濾。這一層不依賴大模型是純粹的業(yè)務(wù)規(guī)則。過程很痛苦但這一套組合拳打下來線上幻覺率從我初版的30%以上降到了可接受的1%到2%。順便說一句不要迷信換一個更大的模型就能徹底解決問題更大模型一樣會幻覺只是編得更像真的而已。4.2 忽略選科和體檢限制怎么堵漏有一次測試模型給一位色弱考生推薦了某臨床醫(yī)學(xué)專業(yè)理由還寫得很充分“該校醫(yī)學(xué)實力雄厚建議沖刺?！蔽耶?dāng)時冷汗就下來了——這個錯誤如果上線后果非常嚴重。后來我把所有限制條件做成了獨立的規(guī)則表不入Prompt。數(shù)據(jù)表里每一對“院校專業(yè)”都帶有一份限制標(biāo)簽比如是否要求色覺正常、是否要求單科成績、是否限制性別、是否有額外面試。候選生成階段直接對這些標(biāo)簽做硬過濾大模型根本看不到不滿足條件的專業(yè)自然也就沒有幻覺的機會。這類“硬規(guī)則不進Prompt”的原則我建議所有做教育、醫(yī)療、法律等高嚴謹場景的團隊都記下來。大模型可以幫你總結(jié)規(guī)則但不能讓它直接執(zhí)行規(guī)則。4.3 把位次預(yù)估說成鐵板釘釘怎么扭轉(zhuǎn)早期的回復(fù)文案里系統(tǒng)會說“該專業(yè)錄取概率較高”但用戶往往把這句話理解成“基本穩(wěn)了”。后來我們統(tǒng)一把話術(shù)改成三層結(jié)構(gòu)先說結(jié)論標(biāo)簽沖/穩(wěn)/保再說依據(jù)近三年位次對比最后說不確定性來源招生計劃變化、專業(yè)熱度波動。所有地方禁止出現(xiàn)“必定”“肯定”“百分百”這類詞。質(zhì)檢Agent里專門維護了一個“絕對化表述黑名單”包括“穩(wěn)了”“一定能上”“閉眼報”“沒問題”等。只要檢測到自動讓回復(fù)重新生成一次。用戶可能覺得這個系統(tǒng)有點保守但保守在志愿填報這種場景里恰恰是專業(yè)感的來源。4.4 用戶問“哪所更好”時AI該怎么接話“某大學(xué)和某大學(xué)哪個更好”是高頻問題也是最容易把AI帶偏的問題。我的經(jīng)驗是不要回答“A好”而是把“好”拆解成可比較的維度。系統(tǒng)會生成一個對比矩陣列出兩所學(xué)校與目標(biāo)專業(yè)相關(guān)的學(xué)科評估、所在城市就業(yè)環(huán)境、往年錄取位次、深造比例等然后反問用戶“你覺得哪個維度對你更重要”如果用戶說“我主要想考研”系統(tǒng)就把深造出口數(shù)據(jù)單獨拿出來講。如果用戶說“我更在乎就業(yè)”就側(cè)重分析兩校在當(dāng)?shù)鼗蛉珖木蜆I(yè)結(jié)構(gòu)。這個過程實際上是用結(jié)構(gòu)化對比替代價值判斷。AI充當(dāng)磨刀石幫用戶把模糊的問題磨成清晰的選項但刀往哪砍還是用戶自己的決定。4.5 多輪對話中狀態(tài)丟失怎么排查我踩過一個很實際的坑用戶聊到第三輪說“那個學(xué)校怎么樣”對話里指代的是前面提到過的某211但系統(tǒng)已經(jīng)把上下文丟了反而去理解成另一個學(xué)校。排查下來的根因是我把上下文窗口設(shè)置得太短只保留最近兩輪對話而指代詞跨越了更多輪次。解決辦法很簡單把對話歷史合并進槽位摘要系統(tǒng)不再依賴原始對話文本而是維護一個“目標(biāo)畫像最近一輪問題”的結(jié)構(gòu)。比如用戶問“那個學(xué)校怎么樣”系統(tǒng)先查看槽位里的目標(biāo)學(xué)校引用再去檢索。跑了一段時間后指代問題基本絕跡。如果你的對話系統(tǒng)也出現(xiàn)“記不住前面說了什么”的情況不要急著加長上下文窗口。先檢查你是不是把原始文本直接拼進了Prompt而沒有形成結(jié)構(gòu)化的狀態(tài)摘要。原始文本越長模型越容易抓錯重點結(jié)構(gòu)化摘要反而更穩(wěn)。最后再聊兩句這個項目做到后面我最大的體會是做“給建議”的AI最難的不是讓模型變聰明而是讓產(chǎn)品團隊克制住“替用戶做決定”的沖動。早期版本我也追求過“一步到位給出最優(yōu)志愿表”覺得那才是AI能力的體現(xiàn)。但上線后用戶反饋里出現(xiàn)頻率最高的一句話是“感覺被AI安排了”這讓我重新審視了整個交互邏輯。后來我把產(chǎn)品調(diào)性改成了“參謀”風(fēng)格結(jié)果也很微妙用戶主動查“依據(jù)”的次數(shù)多了聊得更深了填完志愿之后回來的復(fù)購和轉(zhuǎn)介紹反而上升了。用戶不是不需要AI而是不需要一個替他承擔(dān)人生決定的AI。他需要的是把紛繁復(fù)雜的信息攤開在桌面上、把權(quán)衡邏輯講清楚的助手。如果你也在做類似的教育咨詢或者高嚴謹決策類AI建議你在項目第一天就把“給建議而不做決定”寫進功能需求而不是等模型上線后再修正。這條原則會貫穿你的數(shù)據(jù)設(shè)計、Prompt設(shè)計、結(jié)果校驗和UI文案越早定下來后面返工越少。