前阵子帮一个朋友看他的微信小程序项目《见格MBTI》核心功能很有意思——用户输入自己的出生信息或性格描述小程序调用大模型输出一整套“五行人格 × MBTI人格”的跨体系解读。这个功能听起来像是套壳问答但真正落地时才发觉难点根本不在于调API而在于怎么让大模型在两套完全异源的知识体系之间稳定地建立对话映射不跑偏、不胡诌、输出格式还可控。这篇文章就把我们实际搭建复杂提示词架构的过程拆开讲清楚包含整套Prompt设计思路、小程序端的调用链路、踩过的坑和排查方法给正在做类似“传统文化现代心理学”类小程序的人一个可复用的参考。1. 项目定位与整体架构拆解1.1 跨界对话的核心价值为什么是五行和MBTI先说产品动机。五行是中国传统认知里的一套动态关系模型金木水火土本身不是静止的标签而是一套生克制化的关系网络。MBTI则是基于荣格类型学发展出来的现代人格测评工具通过精力来源、信息获取、决策方式、生活态度四个维度把人分成16种类型。这两套体系在表面上差异巨大但底层有一个共同点都在尝试用一种结构化的方式解释“人的性格倾向和行为模式”。我们在设计《见格MBTI》的时候想做的不只是“算出你的五行属性再算出你的MBTI”这种并行输出而是真正意义上的跨界对话——让大模型把两套体系之间的对应关系、张力、互补性表达出来。比如一个“火”属性偏强的人在MBTI里更可能对应哪些类型反过来一个INTP型的人在五行能量结构里会更贴近“水”还是“金”这种映射不是定死的公式而是需要大模型在理解两套知识结构的前提下基于用户具体输入做动态判断。这个定位决定了整条技术路线的走向绝对不能用一个写死的规则表去匹配五行和MBTI那样做出来的东西没有生命力也绝对不能完全放任大模型自由发挥否则用户会得到一堆看似有道理实则虚无缥缈的废话。正确的做法是用一套精心设计的提示词架构把大模型的生成能力约束在一个“既有知识框架、又有弹性推理”的空间里。1.2 小程序的角色与架构选型微信小程序在这个项目里承担的是“轻量触达”的角色。用户不需要下载App点开即用天然适合分享裂变。但我们一开始就面临着几个现实约束第一小程序前端不能直接调用大模型接口。微信小程序要求所有请求域名必须配置在合法域名白名单里而且大多数大模型服务商并不提供直接面向小程序的SDK甚至有些接口的域名无法被直接白名单化。所以必须有一个中转服务层。第二小程序的包体积限制。微信小程序主包限制在2MB以内这意味着我们不可能把任何重量级的SDK塞进前端所有复杂逻辑必须放在服务端。第三交互体验要求。大模型生成完整回复通常需要几秒到十几秒如果小程序端傻等一个完整的HTTP响应才更新UI用户体验会很差。所以服务端需要支持流式输出SSE把模型生成的内容逐段推送到小程序端。基于这三点我们的整体架构确定为三层前端小程序层承担信息采集用户输入、流式渲染、结果展示与分享。后端代理服务层承担提示词组装、大模型API调用、流式转发、敏感内容过滤、上下文管理。大模型服务层承载领域对话能力根据后端传入的提示词生成内容。这个架构本身不复杂但它决定了提示词必须由后端统一管理。这样做的好处非常明显提示词更新不需要发小程序版本后端改完立即生效。我们在实际开发中把提示词拆成了独立的配置文件配合版本号管理回滚也方便。2. 复杂提示词架构的搭建过程2.1 核心设计思路把提示词当成一套“剧本演员手册”一开始我们想得很简单写一段Prompt让模型扮演“五行MBTI融合分析师”然后就把用户输入丢进去。测试之后发现效果很差模型有时候只讲五行不讲MBTI有时候输出大段空泛的性格描述有时候格式乱得没法在小程序里结构化展示。后来我们换了个思路——把提示词拆成四个层次每个层次解决一个独立问题。整套结构类比一下就是“剧本”定义角色和剧情目标“演员手册”给角色背景知识和说话风格“流程表”规定每一幕怎么演“交作业模板”规定台词用什么样的格式写出来。第一层是系统角色设定。明确告诉大模型它现在是谁、任务目标是什么、必须遵守的边界有哪些。这一层不涉及具体知识只做角色和意图的锚定防止模型在对话中途“人格漂移”。第二层是知识注入层。把五行体系的核心知识结构、MBTI体系的核心维度说明、两套体系之间的常见对应逻辑以结构化文本的形式写进提示词。注意这里不是丢一大堆百科词条而是精心筛选过的“最小可用知识集”避免上下文被冗余信息撑爆。第三层是对话流程控制层。定义大模型处理用户输入的步骤先解析用户输入提炼关键性格特征再判断对应的五行倾向然后推断MBTI类型最后给出跨体系融合解读和行动建议。这四步一步都不能乱。第四层是输出格式层。强制规定大模型返回的JSON结构包括字段名、含义、取值枚举等。小程序端拿到这份JSON后直接解析渲染不需要让大模型生成自然语言段落再由前端做语义提取——那种方式既不稳定又浪费token。2.2 系统角色与边界条件设计实操系统提示词这一部分我们踩过最深的坑是“角色设定太宽”。最初版本写的是“你是一位深谙五行学说和MBTI心理学的大师”结果模型每次都在开头自我介绍一下身份回答内容却蜻蜓点水。后来改成了更具体的角色定义直接编织进业务目标里你是一个服务于「五行×MBTI跨界人格对话」场景的智能分析师。 你的职责不是向用户普及五行或MBTI的基础概念而是基于用户的个人描述 给出结构化的跨体系人格解读。 严格约束 1. 不输出与五行、MBTI分析无关的内容 2. 不要主动询问用户隐私信息如生辰八字精确时间、真实姓名等 3. 所有结论必须以两套体系的融合视角给出避免只讲其中一套 4. 面对不确定的判断使用“倾向于”“可能更贴近”等措辞禁止武断定性。这段提示词里有三个细节值得注意。第一用“不是...而是...”结构直接否定了模型的错误倾向比单纯说“不要介绍概念”有效得多。第二把合规要求直接写进提示词避免用户诱导模型讨论不当话题。第三用“倾向性措辞”约束模型的确定性表达这从根上减少了用户较真追问的概率。角色设定确定后还要配合温度参数。我们测试下来这类分析解读型场景把temperature设在0.4到0.6之间最合适。太高了输出不稳定同一个输入每次说法都不一样太低了显得机械缺少灵性。最终固定为0.5。2.3 知识注入层的结构化组织方式知识注入是整个提示词架构的基石也是最需要反复打磨的部分。我们的做法是给大模型提供一份“结构化知识清单”而不是一段连续文本。五行部分我们重点注入的不是简单的性格形容词表而是五行之间的关系逻辑[五行知识框架] - 五行基本属性金收敛、肃杀、决断、木生发、规划、仁善、 水流动、智慧、变通、火热烈、外放、礼仪、土承载、稳定、信任。 - 五行相生木生火、火生土、土生金、金生水、水生木。 - 五行相克木克土、土克水、水克火、火克金、金克木。 - 分析原则判断一个人的主导五行时需结合输入信息中 体现出的行为模式、情绪特征、决策风格而非仅凭字面标签。这里有一个取舍我们故意不把“金代表肺、木代表肝”这类中医五行对应关系放进去因为产品定位于人格对话不涉及健康领域。知识注入一定要克制只放当前任务需要的知识否则大模型会被无关信息带偏还有可能触碰到医疗建议的合规红线。MBTI部分我们同样做了精简只保留四个维度的含义和16种类型的简要倾向[MBTI知识框架] - 精力来源E外向从社交获取能量 / I内向从独处获取能量。 - 信息获取S感觉关注现实细节 / N直觉关注抽象模式。 - 决策方式T思考逻辑优先 / F情感价值优先。 - 生活态度J判断喜欢计划 / P知觉喜欢灵活。 - 16型人格需基于上述四个维度的组合进行推导禁止杜撰不存在的维度。在知识注入层之后我们还加了一段“跨体系映射参考”这是一个开放性的引导不是封闭的规则表它允许模型灵活推断同时提示模型建立两个体系间的对应关系。2.4 对话流程控制让模型按步骤走而不跳步流程控制层是把“角色知识”落地的关键。我们使用了一个带编号步骤的指令块让大模型在生成回答时严格按照顺序处理[处理流程] 第一步解析用户输入提取与性格、行为、偏好相关的关键词和特征描述。 第二步结合五行知识框架判断用户性格倾向对应的主导五行元素可取1-2个。 第三步结合MBTI知识框架推断用户在四个维度上的偏好及对应人格类型。 第四步综合两套体系生成融合解读包含主导特质、优势分析、 潜在盲区、发展建议。为什么强调流程必须分步而不是让模型一次完成因为我们在测试中发现不分步骤时模型经常跳步比如只做了MBTI推导然后就直接跳到发展建议完全不提五行。分步指令相当于给模型的思维过程加上了“轨道”虽然不能百分之百保证不脱轨但稳定性大幅提升。另外一个关键技巧是在流程说明后面补一句“在最终输出中不得出现步骤标记”否则模型会把“第一步”“第二步”原样写进给用户的输出里体验很差。2.5 输出格式控制用JSON Schema锁死结构最后是输出格式层。这层直接决定了小程序渲染的难易程度。我们采用JSON结构输出并在提示词里逐字段说明[输出格式] 你必须输出严格的JSON对象字段如下 { dominant_element: 五行元素取值为金/木/水/火/土, element_traits: 该五行主导下用户核心特质的简述不超过50字, mbti_type: 四字母MBTI类型, mbti_traits: 该MBTI类型核心特质的简述不超过50字, mapping_analysis: 两套体系之间的融合分析不少于80字不多于200字, strengths: 基于两套体系的优势解读列出2-3点, blind_spots: 潜在盲区解读列出2-3点, suggestion: 发展建议80字以内 }这里有一个特别重要的细节必须在提示词里明确字段长度上限。如果不说模型生成的字段可能长达几百字既浪费token又让页面排版极其难看。我们在长度约束后加了“少于”“不多于”这种精确限定实测比用“简洁”这种模糊词有效得多。另一个细节是在JSON生成后我们要求模型直接输出JSON不要包一层markdown代码块。因为小程序端后续要做JSON.parse如果模型输出了json ...包裹的内容解析就会失败。虽然可以在后端做预处理但最好让模型一开始就按裸JSON输出。3. 小程序端调用链路的实现细节3.1 后端服务设计Model API的封装与流式转发后端服务我们用Node.js实现主要解决两件事一是统一封装大模型API调用逻辑二是把模型的流式输出透传给小程序端。这里给出一段核心路由代码框架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; // 构建完整提示词系统提示词 历史上下文 当前用户输入 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); // 透传流式数据 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: 分析服务暂时不可用 }); } });这里有几个值得细说的点。第一是SSE格式。小程序端wx.request不支持原生的EventSource所以我们实际上是手动解析服务端发来的SSE流。具体做法是后端收到大模型流式响应后将每一段数据封装成一行JSON字符串用data:前缀发送小程序端再用onChunkReceived监听逐段解析。这一步如果不做用户要等完全生成后才能看到结果体感差距非常大。第二是上下文管理。我们采用了轻量级的滑动窗口方案后端把用户最开始的输入信息作为固定记忆最近两轮对话内容拼入上下文更早的内容一律丢弃。这样既保留了必要的连续性又严格控制了token消耗。第三是异步错误处理。大模型API经常出现网络超时或服务端5xx错误如果不在前端做好重试提示用户会以为小程序崩了。我们的方案是后端捕获错误后向小程序返回一个error类型的事件前端拿到后展示友好的重试引导而不是直接凉掉页面。3.2 前端小程序交互与渲染策略小程序端的实现核心集中在三个页面逻辑输入页、加载页、结果页。我们在一开始考虑过用WebView加载H5页面来渲染内容后来放弃了这个方案因为原生页面在分享卡片、动画过渡和渲染性能上都有明显优势。输入页要解决的是用户“不知道说什么”的问题。我们设计了几种快捷输入方式用户可以选择“跟随引导”——按提示输入自己的性格偏好、日常行为模式也可以直接输入一段自由描述。但无论哪种方式取到的原始文本并不直接发给大模型而是先做一次简单的关键词抽取和信息规整再传给后端。加载页的体验设计很容易被忽视但对留存影响很大。大模型生成内容通常需要3到8秒用户等不了白屏。我们的方案是做一个动态的过渡动画同时先把用户输入内容回显在页面上配合“正在从两个维度分析你的人格结构...”这种过程暗示让用户理解当前状态不是卡死而是计算中。结果页采用分块渲染的方式。因为服务端是流式返回JSON中的字段是一个个生成的。我们的策略是收到dominant_element字段后立即展示五行标签收到mbti_type后展示MBTI标签其余长文本字段到达后再逐步补充。这样用户感知到的是“内容一点点出现”而不是“一整块突然冒出来”心理体验会好很多。前端还需要做一次结果格式兜底校验。由于大模型输出天然带随机性即使提示词里规定了JSON格式仍然有小概率出现解析失败的情况。我们的方案是后端在返回给前端之前做一次JSON.parse校验如果失败则自动触发一次重试生成如果重试仍然失败就降级返回一段纯文本输出保证用户至少能看到分析内容。4. 常见问题与排查技巧实录4.1 提示词越调越乱模型输出开始“人格分裂”这是一个我们过程中反复遇到的问题。有一次我们把营养建议也加进了提示词目的是让输出内容更丰富结果模型开始大段输出饮食建议完全偏离了人格分析主题。排查后发现根本原因是知识注入层混入了与核心任务无关的内容模型在角色设定模糊的情况下自主扩大了职责范围。解决方法是严格执行知识隔离核心任务需要的数据留在提示词里一切非核心内容放到“禁止涉及”列表里。我们在系统提示词里明确写了一句“以下内容与本对话无关禁止主动提及健康建议、命理推算、取名建议、婚配建议”效果立竿见影。这个问题的本质是提示词的“信息熵”过高。大模型在生成时会更倾向于使用信息量大的上下文如果无关知识塞得太多它会把注意力分配到错误的地方。控制知识注入的纯度是提示词工程里最容易被低估的一环。4.2 用户同一个问题反复追问输出内容前后矛盾上线后发现一批投诉用户第一次问“我适合什么工作方向”得到的回答和第二次问的结论完全不一样。这背后有两个原因一是大模型生成的随机性二是我们为控制token没有保存完整的对话记忆。针对这个问题我们的解法分三层。第一层是引入固定的“用户画像摘要”机制用户第一次输入后后端提取核心特征生成一段摘要文本后续每一轮对话中都会把摘要放进提示词相当于让大模型始终感受到统一的用户画像。第二层是把temperature从0.5降到0.4减少随机性。第三层是放宽滑动窗口把最近三轮对话全部保留而不是两轮。这个调整之后前后一致性明显改善。当然这里要提醒一句如果产品定位就是“每次随机探索”那可以忽略这条经验但我们的产品定位是“稳定的人格分析工具”一致性就是生命线。4.3 输出格式不稳定前端JSON解析频繁失败JSON解析失败这个问题在开发初期几乎每周都要碰几次。最典型的情况是模型在JSON前后加了markdown代码块标记。我们在提示词里明确写了“直接输出裸JSON不要包含markdown代码块标记”但偶尔还是会有漏网之鱼。后来我们做了一道双保险在后端解析层加了一个sanitize函数如果首次解析失败就尝试剥离代码块标记、修正多余的逗号之后再做二次解析如果仍然失败则触发重试。这里的关键是重试次数要设上限我们设了2次超过就直接降级为文本输出不无限等下去。另外一个细节是JSON字段里有引号或换行符时模型可能没有正确转义导致解析失败。我们的做法是在提示词里给出了一个“字段内容中禁止包含双引号和换行符”的规则同时在sanitize函数里做了一层转义处理。4.4 并发高峰时段模型响应极慢体验断崖式下降有一天上线了某平台的推广活动流量突然涨了十几倍后端代理服务的并发调用撑不住大量请求排队等待模型响应页面一直转圈。排查后发现问题不只是模型API本身的并发限制还有我们自己的服务处理模型响应时使用了同步等待导致Node.js事件循环被阻塞。解决方法是全面异步化。我们把大模型调用改为非阻塞模式利用消息队列削峰填谷同时针对同一个用户的多轮请求做合并减少重复调用另外在网关层做了并发限流超过阈值的请求直接返回“当前人数较多请稍后重试”的提示。这里也分享一个小经验大模型响应慢时不要只盯着模型服务商先看自己的代理层是不是成了瓶颈。很多团队把性能问题全部归因于外部API实际上自己的代码往往才是那个卡脖子的环节。4.5 常见问题速查表最后整理一份我们在实际运营中沉淀下来的问题排查表方便新加入项目的成员快速定位问题现象可能原因排查方向模型只讲五行不讲MBTI提示词流程控制失效检查流程控制层是否被其他高权重指令覆盖确认步骤编号未被遗漏输出内容空泛无实质知识注入层过薄补充最小可用知识集确保模型具备体系内的基础概念JSON解析频繁失败模型输出带格式杂质后端增加sanitize兜底并在提示词里强化裸JSON要求多轮回答前后矛盾上下文管理丢失引入固定用户画像摘要扩大滑动窗口长度高峰时段响应极慢并发调用排队阻塞服务端异步化、消息队列削峰、客户端增加引导性提示内容涉及敏感话题系统提示词约束不足在角色设定层补充严格负面清单前置内容安全模型检测5. 提示词迭代与版本管理的工程化实践5.1 提示词配置文件与版本回滚机制随着功能迭代我们把提示词从Python代码里硬编码的字符串迁移成了独立的维护体系。每套提示词都有版本号、更新人、变更说明、生效时间四个基本信息并存放在后端配置中心。小程序端请求时带上当前版本号服务端根据版本号拉取对应的提示词模板。这份投入非常值得。没有版本管理之前有一次我和朋友同时改了提示词互相覆盖导致线上突然出现混乱输出花了很长时间才定位到是配置被意外改动。有了版本管理和线上配置与测试配置分离的机制之后这类事故彻底杜绝了。提示词版本管理的几个要点每次变更必须有明确度量比如“温度从0.5调到0.4”“增加禁言列表”等能量化才能复盘。大规模改动前先在小流量上A/B测试比如5%的请求走新版本提示词对比满意度后再全量发布。保留最近3个可用的历史版本一旦新版提示词引发投诉可以在1分钟内完成回滚。5.2 调参经验temperature和top_p的平衡在大模型API的所有参数里temperature和top_p直接影响内容生成的确定性这两个值我们反复测试了很久。总结下来参数项目测试范围最终取值使用说明temperature0.3-0.80.4越低输出越稳定但低于0.3会显得机械重复高于0.6后每次回答差异过大top_p0.8-0.950.9控制候选词范围与temperature配合使用而非替代max_tokens512-2048900太长浪费成本太短会切掉建议部分还有一个小经验当temperature较低时说明模型倾向于保守输出的创意性会减弱。对于我们的场景这也是可以接受的。做人格分析类产品用户的信任感首先来自“每次问结果都差不多”其次才是有趣的惊喜感。如果优先追求创意丰富可以把每个输出字段单独设定温度但这个方案会显著增加工程复杂度目前我们没有实施。6. 关于内容安全与产品合规的排查提示这部分单独开一节说因为太容易踩雷。五行命理、MBTI测评这类话题天然带敏感属性如果内容表现不当轻则被内容安全平台拦截重则带来合规风险。第一在提示词中明确禁止输出医疗、投资、生育等专业领域的具体建议。我们有意识地在系统提示词里加入了一条“禁止输出涉及医疗诊断、疾病预测、投资理财、法律咨询等专业建议”防止模型被用户诱导越界。第二关于五行与命理产品文案里必须把表达从“命运预测”转向“性格倾向分析”。这个转向不是文字游戏而是产品定位的根本我们不是告诉用户“你的命运注定如何”而是提供一个“从不同文化视角认识自己”的工具。这个定位差异会直接影响提示词设计——我们要求模型输出所有内容都用“倾向”“可能”“更适合”这类非确定性措辞。第三对涉政、黄赌毒等敏感输入必须前置拦截。我们不依赖大模型自身的拒绝能力而是在后端接入内容安全服务做一级过滤命中黑名单就直接返回“暂不支持该类型问题”不走模型调用流程。这样既节省token也避免大模型输出不可控内容。第四数据隐私。用户输入的性格描述、出生日期等信息都是敏感数据。后端密钥管理严格独立用户的对话记录默认不落地存储如果产品需要做用户画像分析也必须先经过脱敏再去匿名统计。7. 后续扩展从“对话工具”到“人格实验室”这次做完《见格MBTI》这类跨界对话产品我觉得复杂提示词架构的核心收获是给大模型设定一套可复用、可迭代的约束框架远比追求某一次的惊艳输出重要得多。我们已经在这套架构的基础上规划了三个扩展方向一是加入更多人格分析体系比如九型人格、大五人格与五行和MBTI形成多体系交叉对话二是增加对比分析模式让用户邀请好友一起测试并生成关系解读三是引入历史名人或虚构角色的人格对照增加娱乐性和分享传播性。这里顺便说一个踩过的坑扩展体系时千万不要直接往知识注入层里平铺新体系内容。每种新体系都需要独立的知识结构、映射逻辑、输出模板。正确做法是把提示词架构中的“知识槽位”做抽象按体系平行填充就像数据库表结构一样而不是让一段提示词里堆积所有体系的内容。最后再说一句我的体会提示词工程的本质是在模型的能力边界和产品需求之间建立一层约束网。网太松模型会乱跑网太密模型的智能优势又发挥不出来。找到那个“既稳又活”的点需要不断测试、不断积累。希望这篇文章能给正在做类似AI文化创意类小程序的朋友一些启发少走几步弯路。