前陣子幫一個(gè)朋友看他的微信小程序項(xiàng)目《見格MBTI》核心功能很有意思——用戶輸入自己的出生信息或性格描述小程序調(diào)用大模型輸出一整套“五行人格 × MBTI人格”的跨體系解讀。這個(gè)功能聽起來像是套殼問答但真正落地時(shí)才發(fā)覺難點(diǎn)根本不在于調(diào)API而在于怎么讓大模型在兩套完全異源的知識(shí)體系之間穩(wěn)定地建立對(duì)話映射不跑偏、不胡謅、輸出格式還可控。這篇文章就把我們實(shí)際搭建復(fù)雜提示詞架構(gòu)的過程拆開講清楚包含整套Prompt設(shè)計(jì)思路、小程序端的調(diào)用鏈路、踩過的坑和排查方法給正在做類似“傳統(tǒng)文化現(xiàn)代心理學(xué)”類小程序的人一個(gè)可復(fù)用的參考。1. 項(xiàng)目定位與整體架構(gòu)拆解1.1 跨界對(duì)話的核心價(jià)值為什么是五行和MBTI先說產(chǎn)品動(dòng)機(jī)。五行是中國傳統(tǒng)認(rèn)知里的一套動(dòng)態(tài)關(guān)系模型金木水火土本身不是靜止的標(biāo)簽而是一套生克制化的關(guān)系網(wǎng)絡(luò)。MBTI則是基于榮格類型學(xué)發(fā)展出來的現(xiàn)代人格測評(píng)工具通過精力來源、信息獲取、決策方式、生活態(tài)度四個(gè)維度把人分成16種類型。這兩套體系在表面上差異巨大但底層有一個(gè)共同點(diǎn)都在嘗試用一種結(jié)構(gòu)化的方式解釋“人的性格傾向和行為模式”。我們在設(shè)計(jì)《見格MBTI》的時(shí)候想做的不只是“算出你的五行屬性再算出你的MBTI”這種并行輸出而是真正意義上的跨界對(duì)話——讓大模型把兩套體系之間的對(duì)應(yīng)關(guān)系、張力、互補(bǔ)性表達(dá)出來。比如一個(gè)“火”屬性偏強(qiáng)的人在MBTI里更可能對(duì)應(yīng)哪些類型反過來一個(gè)INTP型的人在五行能量結(jié)構(gòu)里會(huì)更貼近“水”還是“金”這種映射不是定死的公式而是需要大模型在理解兩套知識(shí)結(jié)構(gòu)的前提下基于用戶具體輸入做動(dòng)態(tài)判斷。這個(gè)定位決定了整條技術(shù)路線的走向絕對(duì)不能用一個(gè)寫死的規(guī)則表去匹配五行和MBTI那樣做出來的東西沒有生命力也絕對(duì)不能完全放任大模型自由發(fā)揮否則用戶會(huì)得到一堆看似有道理實(shí)則虛無縹緲的廢話。正確的做法是用一套精心設(shè)計(jì)的提示詞架構(gòu)把大模型的生成能力約束在一個(gè)“既有知識(shí)框架、又有彈性推理”的空間里。1.2 小程序的角色與架構(gòu)選型微信小程序在這個(gè)項(xiàng)目里承擔(dān)的是“輕量觸達(dá)”的角色。用戶不需要下載App點(diǎn)開即用天然適合分享裂變。但我們一開始就面臨著幾個(gè)現(xiàn)實(shí)約束第一小程序前端不能直接調(diào)用大模型接口。微信小程序要求所有請求域名必須配置在合法域名白名單里而且大多數(shù)大模型服務(wù)商并不提供直接面向小程序的SDK甚至有些接口的域名無法被直接白名單化。所以必須有一個(gè)中轉(zhuǎn)服務(wù)層。第二小程序的包體積限制。微信小程序主包限制在2MB以內(nèi)這意味著我們不可能把任何重量級(jí)的SDK塞進(jìn)前端所有復(fù)雜邏輯必須放在服務(wù)端。第三交互體驗(yàn)要求。大模型生成完整回復(fù)通常需要幾秒到十幾秒如果小程序端傻等一個(gè)完整的HTTP響應(yīng)才更新UI用戶體驗(yàn)會(huì)很差。所以服務(wù)端需要支持流式輸出SSE把模型生成的內(nèi)容逐段推送到小程序端?；谶@三點(diǎn)我們的整體架構(gòu)確定為三層前端小程序?qū)映袚?dān)信息采集用戶輸入、流式渲染、結(jié)果展示與分享。后端代理服務(wù)層承擔(dān)提示詞組裝、大模型API調(diào)用、流式轉(zhuǎn)發(fā)、敏感內(nèi)容過濾、上下文管理。大模型服務(wù)層承載領(lǐng)域?qū)υ捘芰Ω鶕?jù)后端傳入的提示詞生成內(nèi)容。這個(gè)架構(gòu)本身不復(fù)雜但它決定了提示詞必須由后端統(tǒng)一管理。這樣做的好處非常明顯提示詞更新不需要發(fā)小程序版本后端改完立即生效。我們在實(shí)際開發(fā)中把提示詞拆成了獨(dú)立的配置文件配合版本號(hào)管理回滾也方便。2. 復(fù)雜提示詞架構(gòu)的搭建過程2.1 核心設(shè)計(jì)思路把提示詞當(dāng)成一套“劇本演員手冊”一開始我們想得很簡單寫一段Prompt讓模型扮演“五行MBTI融合分析師”然后就把用戶輸入丟進(jìn)去。測試之后發(fā)現(xiàn)效果很差模型有時(shí)候只講五行不講MBTI有時(shí)候輸出大段空泛的性格描述有時(shí)候格式亂得沒法在小程序里結(jié)構(gòu)化展示。后來我們換了個(gè)思路——把提示詞拆成四個(gè)層次每個(gè)層次解決一個(gè)獨(dú)立問題。整套結(jié)構(gòu)類比一下就是“劇本”定義角色和劇情目標(biāo)“演員手冊”給角色背景知識(shí)和說話風(fēng)格“流程表”規(guī)定每一幕怎么演“交作業(yè)模板”規(guī)定臺(tái)詞用什么樣的格式寫出來。第一層是系統(tǒng)角色設(shè)定。明確告訴大模型它現(xiàn)在是誰、任務(wù)目標(biāo)是什么、必須遵守的邊界有哪些。這一層不涉及具體知識(shí)只做角色和意圖的錨定防止模型在對(duì)話中途“人格漂移”。第二層是知識(shí)注入層。把五行體系的核心知識(shí)結(jié)構(gòu)、MBTI體系的核心維度說明、兩套體系之間的常見對(duì)應(yīng)邏輯以結(jié)構(gòu)化文本的形式寫進(jìn)提示詞。注意這里不是丟一大堆百科詞條而是精心篩選過的“最小可用知識(shí)集”避免上下文被冗余信息撐爆。第三層是對(duì)話流程控制層。定義大模型處理用戶輸入的步驟先解析用戶輸入提煉關(guān)鍵性格特征再判斷對(duì)應(yīng)的五行傾向然后推斷MBTI類型最后給出跨體系融合解讀和行動(dòng)建議。這四步一步都不能亂。第四層是輸出格式層。強(qiáng)制規(guī)定大模型返回的JSON結(jié)構(gòu)包括字段名、含義、取值枚舉等。小程序端拿到這份JSON后直接解析渲染不需要讓大模型生成自然語言段落再由前端做語義提取——那種方式既不穩(wěn)定又浪費(fèi)token。2.2 系統(tǒng)角色與邊界條件設(shè)計(jì)實(shí)操系統(tǒng)提示詞這一部分我們踩過最深的坑是“角色設(shè)定太寬”。最初版本寫的是“你是一位深諳五行學(xué)說和MBTI心理學(xué)的大師”結(jié)果模型每次都在開頭自我介紹一下身份回答內(nèi)容卻蜻蜓點(diǎn)水。后來改成了更具體的角色定義直接編織進(jìn)業(yè)務(wù)目標(biāo)里你是一個(gè)服務(wù)于「五行×MBTI跨界人格對(duì)話」場景的智能分析師。 你的職責(zé)不是向用戶普及五行或MBTI的基礎(chǔ)概念而是基于用戶的個(gè)人描述 給出結(jié)構(gòu)化的跨體系人格解讀。 嚴(yán)格約束 1. 不輸出與五行、MBTI分析無關(guān)的內(nèi)容 2. 不要主動(dòng)詢問用戶隱私信息如生辰八字精確時(shí)間、真實(shí)姓名等 3. 所有結(jié)論必須以兩套體系的融合視角給出避免只講其中一套 4. 面對(duì)不確定的判斷使用“傾向于”“可能更貼近”等措辭禁止武斷定性。這段提示詞里有三個(gè)細(xì)節(jié)值得注意。第一用“不是...而是...”結(jié)構(gòu)直接否定了模型的錯(cuò)誤傾向比單純說“不要介紹概念”有效得多。第二把合規(guī)要求直接寫進(jìn)提示詞避免用戶誘導(dǎo)模型討論不當(dāng)話題。第三用“傾向性措辭”約束模型的確定性表達(dá)這從根上減少了用戶較真追問的概率。角色設(shè)定確定后還要配合溫度參數(shù)。我們測試下來這類分析解讀型場景把temperature設(shè)在0.4到0.6之間最合適。太高了輸出不穩(wěn)定同一個(gè)輸入每次說法都不一樣太低了顯得機(jī)械缺少靈性。最終固定為0.5。2.3 知識(shí)注入層的結(jié)構(gòu)化組織方式知識(shí)注入是整個(gè)提示詞架構(gòu)的基石也是最需要反復(fù)打磨的部分。我們的做法是給大模型提供一份“結(jié)構(gòu)化知識(shí)清單”而不是一段連續(xù)文本。五行部分我們重點(diǎn)注入的不是簡單的性格形容詞表而是五行之間的關(guān)系邏輯[五行知識(shí)框架] - 五行基本屬性金收斂、肅殺、決斷、木生發(fā)、規(guī)劃、仁善、 水流動(dòng)、智慧、變通、火熱烈、外放、禮儀、土承載、穩(wěn)定、信任。 - 五行相生木生火、火生土、土生金、金生水、水生木。 - 五行相克木克土、土克水、水克火、火克金、金克木。 - 分析原則判斷一個(gè)人的主導(dǎo)五行時(shí)需結(jié)合輸入信息中 體現(xiàn)出的行為模式、情緒特征、決策風(fēng)格而非僅憑字面標(biāo)簽。這里有一個(gè)取舍我們故意不把“金代表肺、木代表肝”這類中醫(yī)五行對(duì)應(yīng)關(guān)系放進(jìn)去因?yàn)楫a(chǎn)品定位于人格對(duì)話不涉及健康領(lǐng)域。知識(shí)注入一定要克制只放當(dāng)前任務(wù)需要的知識(shí)否則大模型會(huì)被無關(guān)信息帶偏還有可能觸碰到醫(yī)療建議的合規(guī)紅線。MBTI部分我們同樣做了精簡只保留四個(gè)維度的含義和16種類型的簡要傾向[MBTI知識(shí)框架] - 精力來源E外向從社交獲取能量 / I內(nèi)向從獨(dú)處獲取能量。 - 信息獲取S感覺關(guān)注現(xiàn)實(shí)細(xì)節(jié) / N直覺關(guān)注抽象模式。 - 決策方式T思考邏輯優(yōu)先 / F情感價(jià)值優(yōu)先。 - 生活態(tài)度J判斷喜歡計(jì)劃 / P知覺喜歡靈活。 - 16型人格需基于上述四個(gè)維度的組合進(jìn)行推導(dǎo)禁止杜撰不存在的維度。在知識(shí)注入層之后我們還加了一段“跨體系映射參考”這是一個(gè)開放性的引導(dǎo)不是封閉的規(guī)則表它允許模型靈活推斷同時(shí)提示模型建立兩個(gè)體系間的對(duì)應(yīng)關(guān)系。2.4 對(duì)話流程控制讓模型按步驟走而不跳步流程控制層是把“角色知識(shí)”落地的關(guān)鍵。我們使用了一個(gè)帶編號(hào)步驟的指令塊讓大模型在生成回答時(shí)嚴(yán)格按照順序處理[處理流程] 第一步解析用戶輸入提取與性格、行為、偏好相關(guān)的關(guān)鍵詞和特征描述。 第二步結(jié)合五行知識(shí)框架判斷用戶性格傾向?qū)?yīng)的主導(dǎo)五行元素可取1-2個(gè)。 第三步結(jié)合MBTI知識(shí)框架推斷用戶在四個(gè)維度上的偏好及對(duì)應(yīng)人格類型。 第四步綜合兩套體系生成融合解讀包含主導(dǎo)特質(zhì)、優(yōu)勢分析、 潛在盲區(qū)、發(fā)展建議。為什么強(qiáng)調(diào)流程必須分步而不是讓模型一次完成因?yàn)槲覀冊跍y試中發(fā)現(xiàn)不分步驟時(shí)模型經(jīng)常跳步比如只做了MBTI推導(dǎo)然后就直接跳到發(fā)展建議完全不提五行。分步指令相當(dāng)于給模型的思維過程加上了“軌道”雖然不能百分之百保證不脫軌但穩(wěn)定性大幅提升。另外一個(gè)關(guān)鍵技巧是在流程說明后面補(bǔ)一句“在最終輸出中不得出現(xiàn)步驟標(biāo)記”否則模型會(huì)把“第一步”“第二步”原樣寫進(jìn)給用戶的輸出里體驗(yàn)很差。2.5 輸出格式控制用JSON Schema鎖死結(jié)構(gòu)最后是輸出格式層。這層直接決定了小程序渲染的難易程度。我們采用JSON結(jié)構(gòu)輸出并在提示詞里逐字段說明[輸出格式] 你必須輸出嚴(yán)格的JSON對(duì)象字段如下 { dominant_element: 五行元素取值為金/木/水/火/土, element_traits: 該五行主導(dǎo)下用戶核心特質(zhì)的簡述不超過50字, mbti_type: 四字母MBTI類型, mbti_traits: 該MBTI類型核心特質(zhì)的簡述不超過50字, mapping_analysis: 兩套體系之間的融合分析不少于80字不多于200字, strengths: 基于兩套體系的優(yōu)勢解讀列出2-3點(diǎn), blind_spots: 潛在盲區(qū)解讀列出2-3點(diǎn), suggestion: 發(fā)展建議80字以內(nèi) }這里有一個(gè)特別重要的細(xì)節(jié)必須在提示詞里明確字段長度上限。如果不說模型生成的字段可能長達(dá)幾百字既浪費(fèi)token又讓頁面排版極其難看。我們在長度約束后加了“少于”“不多于”這種精確限定實(shí)測比用“簡潔”這種模糊詞有效得多。另一個(gè)細(xì)節(jié)是在JSON生成后我們要求模型直接輸出JSON不要包一層markdown代碼塊。因?yàn)樾〕绦蚨撕罄m(xù)要做JSON.parse如果模型輸出了json ...包裹的內(nèi)容解析就會(huì)失敗。雖然可以在后端做預(yù)處理但最好讓模型一開始就按裸JSON輸出。3. 小程序端調(diào)用鏈路的實(shí)現(xiàn)細(xì)節(jié)3.1 后端服務(wù)設(shè)計(jì)Model API的封裝與流式轉(zhuǎn)發(fā)后端服務(wù)我們用Node.js實(shí)現(xiàn)主要解決兩件事一是統(tǒng)一封裝大模型API調(diào)用邏輯二是把模型的流式輸出透傳給小程序端。這里給出一段核心路由代碼框架const express require(express); const axios require(axios); const { buildPrompt } require(./promptBuilder); const router express.Router(); router.post(/analyze, async (req, res) { try { const userInput req.body.userInput; const conversationId req.body.conversationId || null; // 構(gòu)建完整提示詞系統(tǒng)提示詞 歷史上下文 當(dāng)前用戶輸入 const messages buildPrompt(userInput, conversationId); res.setHeader(Content-Type, text/event-stream; charsetutf-8); res.setHeader(Cache-Control, no-cache); res.setHeader(Connection, keep-alive); const modelResponse await callModelApi(messages); // 透傳流式數(shù)據(jù) modelResponse.data.on(data, chunk { const parsed parseSSEChunk(chunk); if (parsed parsed.content) { res.write(JSON.stringify({ type: content, content: parsed.content })); } }); modelResponse.data.on(end, () { res.write(JSON.stringify({ type: done })); res.end(); }); } catch (error) { res.status(500).json({ error: 分析服務(wù)暫時(shí)不可用 }); } });這里有幾個(gè)值得細(xì)說的點(diǎn)。第一是SSE格式。小程序端wx.request不支持原生的EventSource所以我們實(shí)際上是手動(dòng)解析服務(wù)端發(fā)來的SSE流。具體做法是后端收到大模型流式響應(yīng)后將每一段數(shù)據(jù)封裝成一行JSON字符串用data:前綴發(fā)送小程序端再用onChunkReceived監(jiān)聽逐段解析。這一步如果不做用戶要等完全生成后才能看到結(jié)果體感差距非常大。第二是上下文管理。我們采用了輕量級(jí)的滑動(dòng)窗口方案后端把用戶最開始的輸入信息作為固定記憶最近兩輪對(duì)話內(nèi)容拼入上下文更早的內(nèi)容一律丟棄。這樣既保留了必要的連續(xù)性又嚴(yán)格控制了token消耗。第三是異步錯(cuò)誤處理。大模型API經(jīng)常出現(xiàn)網(wǎng)絡(luò)超時(shí)或服務(wù)端5xx錯(cuò)誤如果不在前端做好重試提示用戶會(huì)以為小程序崩了。我們的方案是后端捕獲錯(cuò)誤后向小程序返回一個(gè)error類型的事件前端拿到后展示友好的重試引導(dǎo)而不是直接涼掉頁面。3.2 前端小程序交互與渲染策略小程序端的實(shí)現(xiàn)核心集中在三個(gè)頁面邏輯輸入頁、加載頁、結(jié)果頁。我們在一開始考慮過用WebView加載H5頁面來渲染內(nèi)容后來放棄了這個(gè)方案因?yàn)樵撁嬖诜窒砜ㄆ?、?dòng)畫過渡和渲染性能上都有明顯優(yōu)勢。輸入頁要解決的是用戶“不知道說什么”的問題。我們設(shè)計(jì)了幾種快捷輸入方式用戶可以選擇“跟隨引導(dǎo)”——按提示輸入自己的性格偏好、日常行為模式也可以直接輸入一段自由描述。但無論哪種方式取到的原始文本并不直接發(fā)給大模型而是先做一次簡單的關(guān)鍵詞抽取和信息規(guī)整再傳給后端。加載頁的體驗(yàn)設(shè)計(jì)很容易被忽視但對(duì)留存影響很大。大模型生成內(nèi)容通常需要3到8秒用戶等不了白屏。我們的方案是做一個(gè)動(dòng)態(tài)的過渡動(dòng)畫同時(shí)先把用戶輸入內(nèi)容回顯在頁面上配合“正在從兩個(gè)維度分析你的人格結(jié)構(gòu)...”這種過程暗示讓用戶理解當(dāng)前狀態(tài)不是卡死而是計(jì)算中。結(jié)果頁采用分塊渲染的方式。因?yàn)榉?wù)端是流式返回JSON中的字段是一個(gè)個(gè)生成的。我們的策略是收到dominant_element字段后立即展示五行標(biāo)簽收到mbti_type后展示MBTI標(biāo)簽其余長文本字段到達(dá)后再逐步補(bǔ)充。這樣用戶感知到的是“內(nèi)容一點(diǎn)點(diǎn)出現(xiàn)”而不是“一整塊突然冒出來”心理體驗(yàn)會(huì)好很多。前端還需要做一次結(jié)果格式兜底校驗(yàn)。由于大模型輸出天然帶隨機(jī)性即使提示詞里規(guī)定了JSON格式仍然有小概率出現(xiàn)解析失敗的情況。我們的方案是后端在返回給前端之前做一次JSON.parse校驗(yàn)如果失敗則自動(dòng)觸發(fā)一次重試生成如果重試仍然失敗就降級(jí)返回一段純文本輸出保證用戶至少能看到分析內(nèi)容。4. 常見問題與排查技巧實(shí)錄4.1 提示詞越調(diào)越亂模型輸出開始“人格分裂”這是一個(gè)我們過程中反復(fù)遇到的問題。有一次我們把營養(yǎng)建議也加進(jìn)了提示詞目的是讓輸出內(nèi)容更豐富結(jié)果模型開始大段輸出飲食建議完全偏離了人格分析主題。排查后發(fā)現(xiàn)根本原因是知識(shí)注入層混入了與核心任務(wù)無關(guān)的內(nèi)容模型在角色設(shè)定模糊的情況下自主擴(kuò)大了職責(zé)范圍。解決方法是嚴(yán)格執(zhí)行知識(shí)隔離核心任務(wù)需要的數(shù)據(jù)留在提示詞里一切非核心內(nèi)容放到“禁止涉及”列表里。我們在系統(tǒng)提示詞里明確寫了一句“以下內(nèi)容與本對(duì)話無關(guān)禁止主動(dòng)提及健康建議、命理推算、取名建議、婚配建議”效果立竿見影。這個(gè)問題的本質(zhì)是提示詞的“信息熵”過高。大模型在生成時(shí)會(huì)更傾向于使用信息量大的上下文如果無關(guān)知識(shí)塞得太多它會(huì)把注意力分配到錯(cuò)誤的地方。控制知識(shí)注入的純度是提示詞工程里最容易被低估的一環(huán)。4.2 用戶同一個(gè)問題反復(fù)追問輸出內(nèi)容前后矛盾上線后發(fā)現(xiàn)一批投訴用戶第一次問“我適合什么工作方向”得到的回答和第二次問的結(jié)論完全不一樣。這背后有兩個(gè)原因一是大模型生成的隨機(jī)性二是我們?yōu)榭刂苩oken沒有保存完整的對(duì)話記憶。針對(duì)這個(gè)問題我們的解法分三層。第一層是引入固定的“用戶畫像摘要”機(jī)制用戶第一次輸入后后端提取核心特征生成一段摘要文本后續(xù)每一輪對(duì)話中都會(huì)把摘要放進(jìn)提示詞相當(dāng)于讓大模型始終感受到統(tǒng)一的用戶畫像。第二層是把temperature從0.5降到0.4減少隨機(jī)性。第三層是放寬滑動(dòng)窗口把最近三輪對(duì)話全部保留而不是兩輪。這個(gè)調(diào)整之后前后一致性明顯改善。當(dāng)然這里要提醒一句如果產(chǎn)品定位就是“每次隨機(jī)探索”那可以忽略這條經(jīng)驗(yàn)但我們的產(chǎn)品定位是“穩(wěn)定的人格分析工具”一致性就是生命線。4.3 輸出格式不穩(wěn)定前端JSON解析頻繁失敗JSON解析失敗這個(gè)問題在開發(fā)初期幾乎每周都要碰幾次。最典型的情況是模型在JSON前后加了markdown代碼塊標(biāo)記。我們在提示詞里明確寫了“直接輸出裸JSON不要包含markdown代碼塊標(biāo)記”但偶爾還是會(huì)有漏網(wǎng)之魚。后來我們做了一道雙保險(xiǎn)在后端解析層加了一個(gè)sanitize函數(shù)如果首次解析失敗就嘗試剝離代碼塊標(biāo)記、修正多余的逗號(hào)之后再做二次解析如果仍然失敗則觸發(fā)重試。這里的關(guān)鍵是重試次數(shù)要設(shè)上限我們設(shè)了2次超過就直接降級(jí)為文本輸出不無限等下去。另外一個(gè)細(xì)節(jié)是JSON字段里有引號(hào)或換行符時(shí)模型可能沒有正確轉(zhuǎn)義導(dǎo)致解析失敗。我們的做法是在提示詞里給出了一個(gè)“字段內(nèi)容中禁止包含雙引號(hào)和換行符”的規(guī)則同時(shí)在sanitize函數(shù)里做了一層轉(zhuǎn)義處理。4.4 并發(fā)高峰時(shí)段模型響應(yīng)極慢體驗(yàn)斷崖式下降有一天上線了某平臺(tái)的推廣活動(dòng)流量突然漲了十幾倍后端代理服務(wù)的并發(fā)調(diào)用撐不住大量請求排隊(duì)等待模型響應(yīng)頁面一直轉(zhuǎn)圈。排查后發(fā)現(xiàn)問題不只是模型API本身的并發(fā)限制還有我們自己的服務(wù)處理模型響應(yīng)時(shí)使用了同步等待導(dǎo)致Node.js事件循環(huán)被阻塞。解決方法是全面異步化。我們把大模型調(diào)用改為非阻塞模式利用消息隊(duì)列削峰填谷同時(shí)針對(duì)同一個(gè)用戶的多輪請求做合并減少重復(fù)調(diào)用另外在網(wǎng)關(guān)層做了并發(fā)限流超過閾值的請求直接返回“當(dāng)前人數(shù)較多請稍后重試”的提示。這里也分享一個(gè)小經(jīng)驗(yàn)大模型響應(yīng)慢時(shí)不要只盯著模型服務(wù)商先看自己的代理層是不是成了瓶頸。很多團(tuán)隊(duì)把性能問題全部歸因于外部API實(shí)際上自己的代碼往往才是那個(gè)卡脖子的環(huán)節(jié)。4.5 常見問題速查表最后整理一份我們在實(shí)際運(yùn)營中沉淀下來的問題排查表方便新加入項(xiàng)目的成員快速定位問題現(xiàn)象可能原因排查方向模型只講五行不講MBTI提示詞流程控制失效檢查流程控制層是否被其他高權(quán)重指令覆蓋確認(rèn)步驟編號(hào)未被遺漏輸出內(nèi)容空泛無實(shí)質(zhì)知識(shí)注入層過薄補(bǔ)充最小可用知識(shí)集確保模型具備體系內(nèi)的基礎(chǔ)概念JSON解析頻繁失敗模型輸出帶格式雜質(zhì)后端增加sanitize兜底并在提示詞里強(qiáng)化裸JSON要求多輪回答前后矛盾上下文管理丟失引入固定用戶畫像摘要擴(kuò)大滑動(dòng)窗口長度高峰時(shí)段響應(yīng)極慢并發(fā)調(diào)用排隊(duì)阻塞服務(wù)端異步化、消息隊(duì)列削峰、客戶端增加引導(dǎo)性提示內(nèi)容涉及敏感話題系統(tǒng)提示詞約束不足在角色設(shè)定層補(bǔ)充嚴(yán)格負(fù)面清單前置內(nèi)容安全模型檢測5. 提示詞迭代與版本管理的工程化實(shí)踐5.1 提示詞配置文件與版本回滾機(jī)制隨著功能迭代我們把提示詞從Python代碼里硬編碼的字符串遷移成了獨(dú)立的維護(hù)體系。每套提示詞都有版本號(hào)、更新人、變更說明、生效時(shí)間四個(gè)基本信息并存放在后端配置中心。小程序端請求時(shí)帶上當(dāng)前版本號(hào)服務(wù)端根據(jù)版本號(hào)拉取對(duì)應(yīng)的提示詞模板。這份投入非常值得。沒有版本管理之前有一次我和朋友同時(shí)改了提示詞互相覆蓋導(dǎo)致線上突然出現(xiàn)混亂輸出花了很長時(shí)間才定位到是配置被意外改動(dòng)。有了版本管理和線上配置與測試配置分離的機(jī)制之后這類事故徹底杜絕了。提示詞版本管理的幾個(gè)要點(diǎn)每次變更必須有明確度量比如“溫度從0.5調(diào)到0.4”“增加禁言列表”等能量化才能復(fù)盤。大規(guī)模改動(dòng)前先在小流量上A/B測試比如5%的請求走新版本提示詞對(duì)比滿意度后再全量發(fā)布。保留最近3個(gè)可用的歷史版本一旦新版提示詞引發(fā)投訴可以在1分鐘內(nèi)完成回滾。5.2 調(diào)參經(jīng)驗(yàn)temperature和top_p的平衡在大模型API的所有參數(shù)里temperature和top_p直接影響內(nèi)容生成的確定性這兩個(gè)值我們反復(fù)測試了很久。總結(jié)下來參數(shù)項(xiàng)目測試范圍最終取值使用說明temperature0.3-0.80.4越低輸出越穩(wěn)定但低于0.3會(huì)顯得機(jī)械重復(fù)高于0.6后每次回答差異過大top_p0.8-0.950.9控制候選詞范圍與temperature配合使用而非替代max_tokens512-2048900太長浪費(fèi)成本太短會(huì)切掉建議部分還有一個(gè)小經(jīng)驗(yàn)當(dāng)temperature較低時(shí)說明模型傾向于保守輸出的創(chuàng)意性會(huì)減弱。對(duì)于我們的場景這也是可以接受的。做人格分析類產(chǎn)品用戶的信任感首先來自“每次問結(jié)果都差不多”其次才是有趣的驚喜感。如果優(yōu)先追求創(chuàng)意豐富可以把每個(gè)輸出字段單獨(dú)設(shè)定溫度但這個(gè)方案會(huì)顯著增加工程復(fù)雜度目前我們沒有實(shí)施。6. 關(guān)于內(nèi)容安全與產(chǎn)品合規(guī)的排查提示這部分單獨(dú)開一節(jié)說因?yàn)樘菀撞壤?。五行命理、MBTI測評(píng)這類話題天然帶敏感屬性如果內(nèi)容表現(xiàn)不當(dāng)輕則被內(nèi)容安全平臺(tái)攔截重則帶來合規(guī)風(fēng)險(xiǎn)。第一在提示詞中明確禁止輸出醫(yī)療、投資、生育等專業(yè)領(lǐng)域的具體建議。我們有意識(shí)地在系統(tǒng)提示詞里加入了一條“禁止輸出涉及醫(yī)療診斷、疾病預(yù)測、投資理財(cái)、法律咨詢等專業(yè)建議”防止模型被用戶誘導(dǎo)越界。第二關(guān)于五行與命理產(chǎn)品文案里必須把表達(dá)從“命運(yùn)預(yù)測”轉(zhuǎn)向“性格傾向分析”。這個(gè)轉(zhuǎn)向不是文字游戲而是產(chǎn)品定位的根本我們不是告訴用戶“你的命運(yùn)注定如何”而是提供一個(gè)“從不同文化視角認(rèn)識(shí)自己”的工具。這個(gè)定位差異會(huì)直接影響提示詞設(shè)計(jì)——我們要求模型輸出所有內(nèi)容都用“傾向”“可能”“更適合”這類非確定性措辭。第三對(duì)涉政、黃賭毒等敏感輸入必須前置攔截。我們不依賴大模型自身的拒絕能力而是在后端接入內(nèi)容安全服務(wù)做一級(jí)過濾命中黑名單就直接返回“暫不支持該類型問題”不走模型調(diào)用流程。這樣既節(jié)省token也避免大模型輸出不可控內(nèi)容。第四數(shù)據(jù)隱私。用戶輸入的性格描述、出生日期等信息都是敏感數(shù)據(jù)。后端密鑰管理嚴(yán)格獨(dú)立用戶的對(duì)話記錄默認(rèn)不落地存儲(chǔ)如果產(chǎn)品需要做用戶畫像分析也必須先經(jīng)過脫敏再去匿名統(tǒng)計(jì)。7. 后續(xù)擴(kuò)展從“對(duì)話工具”到“人格實(shí)驗(yàn)室”這次做完《見格MBTI》這類跨界對(duì)話產(chǎn)品我覺得復(fù)雜提示詞架構(gòu)的核心收獲是給大模型設(shè)定一套可復(fù)用、可迭代的約束框架遠(yuǎn)比追求某一次的驚艷輸出重要得多。我們已經(jīng)在這套架構(gòu)的基礎(chǔ)上規(guī)劃了三個(gè)擴(kuò)展方向一是加入更多人格分析體系比如九型人格、大五人格與五行和MBTI形成多體系交叉對(duì)話二是增加對(duì)比分析模式讓用戶邀請好友一起測試并生成關(guān)系解讀三是引入歷史名人或虛構(gòu)角色的人格對(duì)照增加娛樂性和分享傳播性。這里順便說一個(gè)踩過的坑擴(kuò)展體系時(shí)千萬不要直接往知識(shí)注入層里平鋪新體系內(nèi)容。每種新體系都需要獨(dú)立的知識(shí)結(jié)構(gòu)、映射邏輯、輸出模板。正確做法是把提示詞架構(gòu)中的“知識(shí)槽位”做抽象按體系平行填充就像數(shù)據(jù)庫表結(jié)構(gòu)一樣而不是讓一段提示詞里堆積所有體系的內(nèi)容。最后再說一句我的體會(huì)提示詞工程的本質(zhì)是在模型的能力邊界和產(chǎn)品需求之間建立一層約束網(wǎng)。網(wǎng)太松模型會(huì)亂跑網(wǎng)太密模型的智能優(yōu)勢又發(fā)揮不出來。找到那個(gè)“既穩(wěn)又活”的點(diǎn)需要不斷測試、不斷積累。希望這篇文章能給正在做類似AI文化創(chuàng)意類小程序的朋友一些啟發(fā)少走幾步彎路。