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