一个用户做完MBTI测试看到自己是ENTJ紧接着系统又弹出一句“你是金命且带水相属于金水相生格局决策果断但不失变通。”大多数人的第一反应是“这也行”第二反应是“这两种体系到底是怎么被揉到一起的”这道题背后真正有技术含量的事不是让大模型“知识面广”也不是靠一句简单的Prompt让它自由发挥而是要在微信小程序里搭出一套稳定、可复现、能控制成本的双体系对话引擎。以《见格MBTI》这类项目为例它的核心难点就是一套“复杂提示词架构”既要让大模型理解五行系统里的相生相克关系又要让它精确处理MBTI十六型人格的维度组合还要把两套语言翻译成用户能读懂的、风格统一的结论。这篇不打算讲玄学也不打算铺开讲心理学理论而是从工程实现角度把跨界对话系统的提示词分层、映射规则、小程序端协同、实战排坑完整过一遍适合正在做微信小程序AI问答功能、想接入大模型又不想被内容质量拖垮的开发者参考。1. 五行和MBTI之间到底缺的是“知识”还是“规则”1.1 两套“编码系统”各自的语法先说一个很容易被忽视的事实五行和MBTI根本不是同一种结构的东西。五行本质上是一套“属性关系”的编码系统。金木水火土不只是五个标签更重要的是它们之间存在生、克、乘、侮的关系网络——金生水、水生木、木生火、火生土、土生金金克木、木克土、土克水、水克火、火克金。所以五行不是“你是哪一个”的分类题而是“你在什么状态、和什么相生、被什么制约”的关系题。MBTI则是典型的维度组合型编码。E/I、S/N、T/F、J/P四对维度二选一组合出十六种类型背后还牵涉荣格八维认知功能的排序。它更接近一套分类逻辑先确定你是外向还是内向、靠实感还是直觉做判断再确定计划和决策偏好。它是一个“组合结果”但不太关心“这个结果如何流动、如何和另一个结果相互作用”。两种系统天然不对齐。想在大模型里把它们拉通必须先想清楚“翻译层”是什么。否则就会出现一个尴尬局面模型一会儿跟你讲ENTJ的决策风格一会儿跟你讲五行属性两套概念在同一个回答里打架用户看着热闹细想全是缝合感。1.2 直接写一句Prompt会翻什么车很多人的第一版提示词长这样“你是一个精通五行和MBTI的专家帮我分析一下ENTJ。”这句话看着没问题实际跑起来问题一大堆。第一角色边界模糊。模型不知道自己到底该以“人格心理学家”的身份说话还是以“传统文化解读人”的身份说话于是它会两种腔调混着来。第二推理路径缺失。提示词没有告诉模型“怎么从ENTJ推到五行”它只能凭训练数据里的印象自由发挥——而训练数据里这两者之间本来就没有严格对应关系所以它每次都在猜。第三输出不稳定。同样一个问题上午问和下午问给出的五行归属可能完全不同。第四格式不受控。有时给你一大段散文有时突然变成表格有时还冒出几个emoji小程序端根本没法做统一渲染。这些翻车现场并不是模型能力不够而是提示词没有承担“规则引擎”的职责。跨界对话的关键不是让模型“知道得多”而是让它“按固定路径算”。1.3 “跨界对话”真正的工程定义我把跨界对话拆成三个可验证的能力做技术的人都应该先对齐这个定义再做设计可从MBTI类型稳定映射到五行属性同一输入永远得到同一输出可在五行生克框架下给出性格描述、关系分析所有推导都遵循预先给定的规则表输出可解析、可渲染小程序端拿到结果后可以直接拼装UI不需要“猜模型这次到底想说什么”。满足这三点“跨界对话”才不是一个Slogan而是一个能跑通闭环的功能。后面所有的提示词架构、前后端设计都是围绕这三个目标展开的。2. 把提示词切成五层每一层只负责一件事跨界类提示词最大的毛病是“一锅炖”。角色设定、知识背景、推理规则、输出格式全塞在一段话里模型既记不住也分不清优先级。我在实际项目里习惯把提示词拆成五层每层各司其职效果比堆一段几千字的长文本稳定得多。2.1 L1 系统角色层把“身份边界”钉死系统角色层不只要告诉模型“你是谁”更要告诉模型“你不是谁”。这一点在五行、MBTI这种带有文化解读属性的场景里尤其重要。一段可参考的System Prompt如下你现在是一个“双体系认知协调引擎”。 你的任务不是宣扬五行学说也不是给人格心理学下诊断而是用两套符号系统为用户提供一种跨文化的自我观察视角。 所有输出必须同时体现MBTI的维度逻辑和五行的关系逻辑但不得混淆两套体系的术语不得以“宿命”“注定”等绝对化措辞下结论。角色层是地基。它决定了模型后续所有的回答风格和边界感。如果不把“不是给人格下诊断”这句话写进去模型很容易在对话里说出“你天生就适合做领导”这种越界表述。2.2 L2 知识锚点层给模型一本不会记错的字典大模型对五行口诀的记忆来自训练语料而语料里的口诀混杂且互相矛盾。所以不能指望模型“本来就知道”必须在每次请求里把这份事实字典塞进去。五行基础属性 金——收敛、决断、秩序、锐利 木——生长、规划、进取 水——流动、智慧、适应 火——热情、扩散、行动 土——稳定、承载、信任 生克规则一律以此表为准不得引用其他口诀 金生水水生木木生火火生土土生金 金克木木克土土克水水克火火克金知识锚点层做的是两件事把模型容易自由发挥的事实先钉死让后续的规则层在引用这些概念时模型可以照着文本做推理而不是从训练参数里“回忆一个大概”。“一律以此表为准”这句很重要它能压制模型从别处学来的错误记忆。2.3 L3 映射规则层让模型从“背诵”变成“计算”知识锚点只是一份字典真正让模型“按固定路径推导”的是映射规则层。MBTI到五行的映射路径 1. 先确定该MBTI类型的主导认知功能与辅助认知功能 2. 根据主导功能确定主行根据辅助功能确定辅行 3. 判断主行与辅行之间的生克关系得出相态描述 4. 基于主辅关系组织最终表达这一层是整个提示词架构的灵魂。没有规则层模型只能靠记忆输出结果时对时错有了规则层大模型才变成一台能按流程计算的解释器。你甚至可以理解为把思考过程从模型的黑盒里搬进了提示词变成一个你可以控制和修改的“开源流程”。2.4 L4 上下文管理层把用户人格结果变成持久事实用户做完MBTI测试后他的类型和五行结果就已经确定了。这应该作为系统级上下文长期存在而不是让模型每次重新推断。用户已知事实不可更改 - MBTI类型ENTJ - 主导认知功能Te外倾思考 - 辅助认知功能Ni内倾直觉 - 五行主辅主金辅水金水相生 所有回答必须基于以上事实展开不得推翻或重新推导用户类型。只要用户人格结果没有变这些话就应该每次都出现在请求里。它彻底解决了“同一用户不同时间问出不同结果”的漂移问题。2.5 L5 输出协议层用JSON锁住格式漂移大模型默认爱输出Markdown但Markdown在微信小程序里并不原生支持而且模型对“用什么级别标题、表格几列”的记忆极不稳定。输出协议层要做的就是规定一个前端可以稳定解析的结构。{ title: 金水相生ENTJ的决断与变通, summary: 不超过80字的总览, dimensions: [ 从主导功能Te看金主决断与秩序, 从辅助功能Ni看水主洞察与流动 ], relation_advice: 与哪种五行气质的人更易形成滋养关系, action_tips: [具体可执行的1-2条建议] }让大模型只填字段前端负责设计UI格式漂移的问题会消失大半。这也是提示词架构能和前端工程配套的真正原因。3. 映射规则怎么落地从认知功能到五行组合提示词分层有了接下来要解决一个最核心的产品设计问题十六种MBTI类型怎么稳定地推出“主行辅行”这里需要一张团队内部先对齐的映射表。3.1 认知功能到五行的映射表怎么定我建议不要直接做“16型→五行”的硬编码表而是先做“认知功能→五行”的映射再通过功能组合推导类型这样维护成本低、可解释性强。认知功能倾向描述五行映射Te外倾思考组织、效率、外部逻辑金主Ti内倾思考分析、定义、内部逻辑金主Fe外倾情感群体情感协调、共情氛围火暖性外放Fi内倾情感内在价值判断、深度认同水深流Se外倾实感即时应变、体验当下火行动态Si内倾实感经验存储、稳定秩序土主Ne外倾直觉发散联想、可能性探索木生长发散Ni内倾直觉洞察趋势、压缩概括水深邃流动必须说清楚这不是学术定论而是产品设计决策。五行的归类本身就有多种传统文化流派MBTI的认知功能排序也有不同解释版本。关键是团队内部统一并固定下来模型就能稳定复算。等产品跑一段时间如果发现某类用户的反馈普遍不佳改映射表就可以了不需要重新训练模型。3.2 16型人格如何推导出“主行辅行”每个MBTI类型按主导功能和辅助功能组合得出“主行辅行相态描述”ENTJTe主导→金Ni辅助→水主辅关系为金生水气态描述锐意深远INFPFi主导→水Ne辅助→木主辅关系为水生木气态描述深流滋养ESTPSe主导→火Ti辅助→金主辅关系为火克金气态描述破局行动ISFJSi主导→土Fe辅助→火主辅关系为火生土气态描述温暖守护这样十六型每一型都能推出唯一的主辅组合再结合相生相克关系给出气态描述。推导过程确定性强也方便后续做关系分析。小程序端可以预先维护一份十六型功能排序表作为静态数据字典提示词里只需要引用结果不用每次都让模型做全套推导。3.3 生克关系如何转成关系分析一旦两个人各有主行辅行关系分析就能规则化相生两个能量系统之间存在滋养与互补关系相克存在张力与挑战但也意味着互补空间比和同气频率接近容易互相理解也可能缺乏火花把这些规则写进提示词再配上一两个示例模型就能在“交友匹配”“团队协作”这类功能里输出稳定的关系结论。这里特别注意不要真的让模型“算八字合不合”而是引导到“不同能量气质的协作建议”上产品价值和合规边界都能兼顾。3.4 几个Few-shot示例给模型“规范动作”Few-shot示例不是给模型一个“正确答案”而是给它一套“规范动作”。以关系分析为例用户我是ENTJ朋友是INFP我们合得来吗 助手从能量结构看你们是“金水”与“水木”的组合。ENTJ主金金生水INFP主水水生木。整体能量流向是连续相生的滋养链你在决策和推进上更果断对方在价值和灵感上更敏感。协作建议是你负责搭框架对方负责丰富内容。两个示例就够。太多会占用上下文也会让模型把示例当成唯一正解失去必要的生成空间。4. 微信小程序端与大模型API的协同细节提示词架构只是上半场下半场要把这套对话能力放进微信小程序。小程序端的工程约束和普通Web应用很不一样有几个细节处理不好产品根本跑不起来。4.1 完整请求链路与密钥安全最基础也最关键的一条不要在微信小程序前端直接放模型API密钥。完整的请求链路应该是小程序前端 → 后端服务或微信云函数 → 大模型API → 流式返回 → 前端渲染。密钥放在后端或云函数中前端只传用户输入和必要状态。小程序包是可以被反编译的任何写在前端代码里的密钥都会裸奔这个坑踩一次就是安全事故。如果用了微信云开发通过云函数转发请求还有一个附加好处可以绕过部分域名白名单配置的麻烦云函数发起的是服务端请求不需要在小程序后台一个个配request合法域名。4.2 域名白名单小程序和普通网页最大的不同微信小程序里发起网络请求request、uploadFile、downloadFile等接口的域名必须在小程序管理后台配置为合法域名而且要求HTTPS。开发阶段可以在开发者工具里勾选“不校验合法域名”但上线前不配置好真机测试直接失败。这个配置往往被忽略。很多开发者习惯在本地接口调试得很顺利换到真机就报“url not in domain list”排查半天发现是域名没加白。建议项目早期就把生产环境域名定下来配合服务端一起配好省得后面切换域名还要改一大堆配置。4.3 流式输出的三种落地方式大模型API普遍支持流式输出体验上像打字机一样逐步出字用户等待焦虑会小很多。但在微信小程序里实现流式并不像Web端SSE那样开箱即用我的经验有三种做法WebSocket直连体验最接近实时但需要自己管理连接状态、断线重连和心跳实现成本较高。云函数WebSocket把连接托管在云上前端只管收发稳定性好一点但会引入额外的连接管理复杂度。分段轮询后端把大模型响应切成几个片段前端定时拉取用延时逐段渲染。实现最简单适合追求快速上线。一个务实的取舍产品早期用分段轮询快速验证体验用户量起来、交互复杂度上来之后再换WebSocket。不要一上来就追求最复杂的技术方案。4.4 Markdown渲染不要相信模型的格式稳定性小程序没有内置Markdown渲染能力。大模型返回的内容里如果有##标题、-列表、表格直接塞进rich-text组件基本都会渲染错乱。我用过几种方案最推荐的是“让模型只输出JSON前端自己拼UI”。提示词的输出协议层强制模型把内容拆成title、summary、dimensions、action_tips等字段前端拿到后按设计稿逐字段渲染。JSON结构解析是确定性的不会出现“这行到底是一级标题还是加粗文本”的歧义。如果产品里有大量自由文本段落实在绕不开Markdown可以引入开源的Markdown渲染方案比如towxml系列。但要做好心理准备任何依赖模型格式稳定性的方案都要在提示词里反复强调格式并在前端做容错解析。4.5 内容安全兜底与合规措辞涉及五行、性格分析这类带有解读性质的生成内容上线前必须接入内容安全校验。小程序端本身有能力对文本做敏感词检测但对语境层面的问题判断有限生成内容更多需要靠提示词做前置约束。我的做法是把合规措辞直接写进系统角色层比如强制模型使用“从五行视角看”“倾向于”“可能更适合”这类表达禁止出现“你注定”“一定会”“最适合你”等绝对化断言。这样生成内容从一开始就是温和的建议语气而不是确定性结论。尤其要避免与医疗、投资、重大决策挂钩的表述否则产品随时可能因为内容风险被下架。4.6 缓存降本把高频问题挡在模型外面每次请求都要携带系统角色、知识锚点、映射规则、Few-shot示例这些加起来往往两三千字Token成本不小。高并发时成本会以肉眼可见的速度上涨。我当初做类似功能时实测最有效的降本手段是“按MBTI类型问题场景做缓存”。同一个用户、同一个类型、同一个高频问题第一次调用模型生成结果写入KV缓存之后相同问题直接读缓存返回不重复调用模型。配合云开发的数据库实现起来并不复杂。实际跑下来常见问题命中率高的话成本能降到原来的三分之一甚至更低。5. 实际开发中踩过的坑稳定性的三座大山这个功能做下来我遇到的最大问题不是“模型不够聪明”而是“模型太不稳定”。下面三个坑踩过一遍之后我对“提示词工程”这几个字的理解完全变了。5.1 生克关系被模型“背错”压制训练记忆的干扰有一次让模型分析“土生金”它输出的却是“土生木”。原因很简单大模型对五行生克的记忆来自训练语料而语料里各种口诀混在一起它是在联想不是在计算。修复方法也很直接把生克表完整写进知识锚点层并加上“无论你对五行生克的记忆如何一律以本对话中给出的生克表为准”。这句话非常关键它等于在前面拦了一道闸让模型优先采纳对话内的事实而不是自己脑子里的模糊记忆。修复之后生克关系错误基本没有再出现过。5.2 格式漂移格式约束不能靠“请求语气”请求里明明写了“二级标题用##”模型前两个回答乖乖遵守第三个回答突然用了一级标题加粗小程序前端解析直接崩了。后来我意识到格式约束不能写在“角色描述”里指望模型自觉而是要通过输出协议层彻底“去Markdown化”。改成JSON输出后前端按字段渲染模型根本没有机会产生格式漂移。同时把温度参数调低比如0.2到0.4创造性内容单独开一条更高温度的回答链路。经验是结构化程度越高的输出温度越要低。5.3 人格漂移上下文注入的位置很重要同一个用户第一次问输出“金水相生”过了会儿再问同类型问题输出变成了“木火相生”。原因特别简单用户之前的人格结果没有作为系统级事实注入模型每次把对话都当成独立的空会话。修复方案是把用户已确定的MBTI类型、主导功能、五行主辅拼到System Prompt最前面作为不可变事实。同时要求模型所有回答基于这份事实展开不得重新推导。改完之后人格漂移问题基本归零。这个经验也说明上下文管理不是把历史记录一股脑塞给模型而是把“已经确定的结论”固化下来减少模型每轮重新判断的机会。5.4 成本失控长规则按需拼装知识锚点加映射规则加示例全套拼起来可能三千字每个用户每次请求都发一遍高峰期一天几千次调用成本直接失控。后来我把规则拆成“基础版”和“完整版”两套。基础功能只携带基础属性表关系分析和深度解读才加载完整映射规则。再加上缓存成本能压掉一半以上。提示词架构不只是功能设计也是成本设计——不是每次都传最多字就最聪明而是按需加载给模型够用的上下文反而更稳定。6. 这套“双体系提示词架构”能复用到哪里做完这个项目之后我最大的感受是真正值钱的不是“五行”或“MBTI”这两个具体领域而是“双体系对话”的工程方法。只要两个知识体系需要桥接这套五层提示词架构就适用。6.1 星座与MBTI同一套构架换一张映射表星座的十二属性特点、元素分类火象、土象、风象、水象和MBTI十六型做对话本质上和五行完全同构。把知识锚点层的五行表换成星座元素表映射规则改为“星座元素→性格倾向→与MBTI功能的对应”输出协议保持JSON不变一套架构直接平迁。6.2 中医体质与生活建议知识边界比知识量更重要中医九种体质、日常作息、运动、饮食之间的建议生成是最典型的“传统知识现代AI问答”组合。架构依旧是知识锚点体质特征表、映射规则体质到生活方式的推导路径、输出协议建议卡片。但这一类必须特别谨慎。医疗健康类建议不能做确定性断言不能替代诊断。提示词里应强制模型使用“参考”“建议”“如不确定请咨询专业人士”等表达涉及症状判断的词直接屏蔽。知识边界做得好这类产品反而更容易建立长期信任。6.3 生肖与传统节气问答传统文化的产品化机会生肖、传统节气、民俗文化与AI问答结合当前内容供给很少产品化空间不小。用户缺的从来不是知识而是“让大模型稳定输出、格式化返回、成本可控”的工程能力。五层提示词架构可以直接平移映射表按产品定位重做即可。做这一类传统文化的产品我个人的底线是把内容定位成“文化视角的趣味参考”不渲染宿命论不给确定性结论。当用户问出“我这辈子是不是注定做X”模型要懂得用“从某种视角看你可能更适合……”来回应既保持对话温度又不越界。这个边界感一开始就要写进系统角色层不能指望上线之后再做补救。最后再分享一个亲测有效的小技巧让大模型在双体系之间做“翻译”时不要直接给结论而是把推导过程一并输出。比如用户问“我为什么是金命”模型回答“因为你的主导认知功能是Te外倾思考在功能排序里位列第一我们把它映射到金的收敛与决断属性”信任度比直接说一句“你是金命”高非常多。成本几乎为零但用户留存差异很明显。做文化类AI产品仪式感也是体验的一部分而对外可见的推导过程就是这个产品最真实的仪式感。 
长河君 · 2026/10/20 2:54:49 · 阅读 1.2k 小程序AI对话：MBTI与五行双体系提示词架构实战
一个用户做完MBTI测试看到自己是ENTJ紧接着系统又弹出一句“你是金命且带水相属于金水相生格局决策果断但不失变通。”大多数人的第一反应是“这也行”第二反应是“这两种体系到底是怎么被揉到一起的”这道题背后真正有技术含量的事不是让大模型“知识面广”也不是靠一句简单的Prompt让它自由发挥而是要在微信小程序里搭出一套稳定、可复现、能控制成本的双体系对话引擎。以《见格MBTI》这类项目为例它的核心难点就是一套“复杂提示词架构”既要让大模型理解五行系统里的相生相克关系又要让它精确处理MBTI十六型人格的维度组合还要把两套语言翻译成用户能读懂的、风格统一的结论。这篇不打算讲玄学也不打算铺开讲心理学理论而是从工程实现角度把跨界对话系统的提示词分层、映射规则、小程序端协同、实战排坑完整过一遍适合正在做微信小程序AI问答功能、想接入大模型又不想被内容质量拖垮的开发者参考。1. 五行和MBTI之间到底缺的是“知识”还是“规则”1.1 两套“编码系统”各自的语法先说一个很容易被忽视的事实五行和MBTI根本不是同一种结构的东西。五行本质上是一套“属性关系”的编码系统。金木水火土不只是五个标签更重要的是它们之间存在生、克、乘、侮的关系网络——金生水、水生木、木生火、火生土、土生金金克木、木克土、土克水、水克火、火克金。所以五行不是“你是哪一个”的分类题而是“你在什么状态、和什么相生、被什么制约”的关系题。MBTI则是典型的维度组合型编码。E/I、S/N、T/F、J/P四对维度二选一组合出十六种类型背后还牵涉荣格八维认知功能的排序。它更接近一套分类逻辑先确定你是外向还是内向、靠实感还是直觉做判断再确定计划和决策偏好。它是一个“组合结果”但不太关心“这个结果如何流动、如何和另一个结果相互作用”。两种系统天然不对齐。想在大模型里把它们拉通必须先想清楚“翻译层”是什么。否则就会出现一个尴尬局面模型一会儿跟你讲ENTJ的决策风格一会儿跟你讲五行属性两套概念在同一个回答里打架用户看着热闹细想全是缝合感。1.2 直接写一句Prompt会翻什么车很多人的第一版提示词长这样“你是一个精通五行和MBTI的专家帮我分析一下ENTJ。”这句话看着没问题实际跑起来问题一大堆。第一角色边界模糊。模型不知道自己到底该以“人格心理学家”的身份说话还是以“传统文化解读人”的身份说话于是它会两种腔调混着来。第二推理路径缺失。提示词没有告诉模型“怎么从ENTJ推到五行”它只能凭训练数据里的印象自由发挥——而训练数据里这两者之间本来就没有严格对应关系所以它每次都在猜。第三输出不稳定。同样一个问题上午问和下午问给出的五行归属可能完全不同。第四格式不受控。有时给你一大段散文有时突然变成表格有时还冒出几个emoji小程序端根本没法做统一渲染。这些翻车现场并不是模型能力不够而是提示词没有承担“规则引擎”的职责。跨界对话的关键不是让模型“知道得多”而是让它“按固定路径算”。1.3 “跨界对话”真正的工程定义我把跨界对话拆成三个可验证的能力做技术的人都应该先对齐这个定义再做设计可从MBTI类型稳定映射到五行属性同一输入永远得到同一输出可在五行生克框架下给出性格描述、关系分析所有推导都遵循预先给定的规则表输出可解析、可渲染小程序端拿到结果后可以直接拼装UI不需要“猜模型这次到底想说什么”。满足这三点“跨界对话”才不是一个Slogan而是一个能跑通闭环的功能。后面所有的提示词架构、前后端设计都是围绕这三个目标展开的。2. 把提示词切成五层每一层只负责一件事跨界类提示词最大的毛病是“一锅炖”。角色设定、知识背景、推理规则、输出格式全塞在一段话里模型既记不住也分不清优先级。我在实际项目里习惯把提示词拆成五层每层各司其职效果比堆一段几千字的长文本稳定得多。2.1 L1 系统角色层把“身份边界”钉死系统角色层不只要告诉模型“你是谁”更要告诉模型“你不是谁”。这一点在五行、MBTI这种带有文化解读属性的场景里尤其重要。一段可参考的System Prompt如下你现在是一个“双体系认知协调引擎”。 你的任务不是宣扬五行学说也不是给人格心理学下诊断而是用两套符号系统为用户提供一种跨文化的自我观察视角。 所有输出必须同时体现MBTI的维度逻辑和五行的关系逻辑但不得混淆两套体系的术语不得以“宿命”“注定”等绝对化措辞下结论。角色层是地基。它决定了模型后续所有的回答风格和边界感。如果不把“不是给人格下诊断”这句话写进去模型很容易在对话里说出“你天生就适合做领导”这种越界表述。2.2 L2 知识锚点层给模型一本不会记错的字典大模型对五行口诀的记忆来自训练语料而语料里的口诀混杂且互相矛盾。所以不能指望模型“本来就知道”必须在每次请求里把这份事实字典塞进去。五行基础属性 金——收敛、决断、秩序、锐利 木——生长、规划、进取 水——流动、智慧、适应 火——热情、扩散、行动 土——稳定、承载、信任 生克规则一律以此表为准不得引用其他口诀 金生水水生木木生火火生土土生金 金克木木克土土克水水克火火克金知识锚点层做的是两件事把模型容易自由发挥的事实先钉死让后续的规则层在引用这些概念时模型可以照着文本做推理而不是从训练参数里“回忆一个大概”。“一律以此表为准”这句很重要它能压制模型从别处学来的错误记忆。2.3 L3 映射规则层让模型从“背诵”变成“计算”知识锚点只是一份字典真正让模型“按固定路径推导”的是映射规则层。MBTI到五行的映射路径 1. 先确定该MBTI类型的主导认知功能与辅助认知功能 2. 根据主导功能确定主行根据辅助功能确定辅行 3. 判断主行与辅行之间的生克关系得出相态描述 4. 基于主辅关系组织最终表达这一层是整个提示词架构的灵魂。没有规则层模型只能靠记忆输出结果时对时错有了规则层大模型才变成一台能按流程计算的解释器。你甚至可以理解为把思考过程从模型的黑盒里搬进了提示词变成一个你可以控制和修改的“开源流程”。2.4 L4 上下文管理层把用户人格结果变成持久事实用户做完MBTI测试后他的类型和五行结果就已经确定了。这应该作为系统级上下文长期存在而不是让模型每次重新推断。用户已知事实不可更改 - MBTI类型ENTJ - 主导认知功能Te外倾思考 - 辅助认知功能Ni内倾直觉 - 五行主辅主金辅水金水相生 所有回答必须基于以上事实展开不得推翻或重新推导用户类型。只要用户人格结果没有变这些话就应该每次都出现在请求里。它彻底解决了“同一用户不同时间问出不同结果”的漂移问题。2.5 L5 输出协议层用JSON锁住格式漂移大模型默认爱输出Markdown但Markdown在微信小程序里并不原生支持而且模型对“用什么级别标题、表格几列”的记忆极不稳定。输出协议层要做的就是规定一个前端可以稳定解析的结构。{ title: 金水相生ENTJ的决断与变通, summary: 不超过80字的总览, dimensions: [ 从主导功能Te看金主决断与秩序, 从辅助功能Ni看水主洞察与流动 ], relation_advice: 与哪种五行气质的人更易形成滋养关系, action_tips: [具体可执行的1-2条建议] }让大模型只填字段前端负责设计UI格式漂移的问题会消失大半。这也是提示词架构能和前端工程配套的真正原因。3. 映射规则怎么落地从认知功能到五行组合提示词分层有了接下来要解决一个最核心的产品设计问题十六种MBTI类型怎么稳定地推出“主行辅行”这里需要一张团队内部先对齐的映射表。3.1 认知功能到五行的映射表怎么定我建议不要直接做“16型→五行”的硬编码表而是先做“认知功能→五行”的映射再通过功能组合推导类型这样维护成本低、可解释性强。认知功能倾向描述五行映射Te外倾思考组织、效率、外部逻辑金主Ti内倾思考分析、定义、内部逻辑金主Fe外倾情感群体情感协调、共情氛围火暖性外放Fi内倾情感内在价值判断、深度认同水深流Se外倾实感即时应变、体验当下火行动态Si内倾实感经验存储、稳定秩序土主Ne外倾直觉发散联想、可能性探索木生长发散Ni内倾直觉洞察趋势、压缩概括水深邃流动必须说清楚这不是学术定论而是产品设计决策。五行的归类本身就有多种传统文化流派MBTI的认知功能排序也有不同解释版本。关键是团队内部统一并固定下来模型就能稳定复算。等产品跑一段时间如果发现某类用户的反馈普遍不佳改映射表就可以了不需要重新训练模型。3.2 16型人格如何推导出“主行辅行”每个MBTI类型按主导功能和辅助功能组合得出“主行辅行相态描述”ENTJTe主导→金Ni辅助→水主辅关系为金生水气态描述锐意深远INFPFi主导→水Ne辅助→木主辅关系为水生木气态描述深流滋养ESTPSe主导→火Ti辅助→金主辅关系为火克金气态描述破局行动ISFJSi主导→土Fe辅助→火主辅关系为火生土气态描述温暖守护这样十六型每一型都能推出唯一的主辅组合再结合相生相克关系给出气态描述。推导过程确定性强也方便后续做关系分析。小程序端可以预先维护一份十六型功能排序表作为静态数据字典提示词里只需要引用结果不用每次都让模型做全套推导。3.3 生克关系如何转成关系分析一旦两个人各有主行辅行关系分析就能规则化相生两个能量系统之间存在滋养与互补关系相克存在张力与挑战但也意味着互补空间比和同气频率接近容易互相理解也可能缺乏火花把这些规则写进提示词再配上一两个示例模型就能在“交友匹配”“团队协作”这类功能里输出稳定的关系结论。这里特别注意不要真的让模型“算八字合不合”而是引导到“不同能量气质的协作建议”上产品价值和合规边界都能兼顾。3.4 几个Few-shot示例给模型“规范动作”Few-shot示例不是给模型一个“正确答案”而是给它一套“规范动作”。以关系分析为例用户我是ENTJ朋友是INFP我们合得来吗 助手从能量结构看你们是“金水”与“水木”的组合。ENTJ主金金生水INFP主水水生木。整体能量流向是连续相生的滋养链你在决策和推进上更果断对方在价值和灵感上更敏感。协作建议是你负责搭框架对方负责丰富内容。两个示例就够。太多会占用上下文也会让模型把示例当成唯一正解失去必要的生成空间。4. 微信小程序端与大模型API的协同细节提示词架构只是上半场下半场要把这套对话能力放进微信小程序。小程序端的工程约束和普通Web应用很不一样有几个细节处理不好产品根本跑不起来。4.1 完整请求链路与密钥安全最基础也最关键的一条不要在微信小程序前端直接放模型API密钥。完整的请求链路应该是小程序前端 → 后端服务或微信云函数 → 大模型API → 流式返回 → 前端渲染。密钥放在后端或云函数中前端只传用户输入和必要状态。小程序包是可以被反编译的任何写在前端代码里的密钥都会裸奔这个坑踩一次就是安全事故。如果用了微信云开发通过云函数转发请求还有一个附加好处可以绕过部分域名白名单配置的麻烦云函数发起的是服务端请求不需要在小程序后台一个个配request合法域名。4.2 域名白名单小程序和普通网页最大的不同微信小程序里发起网络请求request、uploadFile、downloadFile等接口的域名必须在小程序管理后台配置为合法域名而且要求HTTPS。开发阶段可以在开发者工具里勾选“不校验合法域名”但上线前不配置好真机测试直接失败。这个配置往往被忽略。很多开发者习惯在本地接口调试得很顺利换到真机就报“url not in domain list”排查半天发现是域名没加白。建议项目早期就把生产环境域名定下来配合服务端一起配好省得后面切换域名还要改一大堆配置。4.3 流式输出的三种落地方式大模型API普遍支持流式输出体验上像打字机一样逐步出字用户等待焦虑会小很多。但在微信小程序里实现流式并不像Web端SSE那样开箱即用我的经验有三种做法WebSocket直连体验最接近实时但需要自己管理连接状态、断线重连和心跳实现成本较高。云函数WebSocket把连接托管在云上前端只管收发稳定性好一点但会引入额外的连接管理复杂度。分段轮询后端把大模型响应切成几个片段前端定时拉取用延时逐段渲染。实现最简单适合追求快速上线。一个务实的取舍产品早期用分段轮询快速验证体验用户量起来、交互复杂度上来之后再换WebSocket。不要一上来就追求最复杂的技术方案。4.4 Markdown渲染不要相信模型的格式稳定性小程序没有内置Markdown渲染能力。大模型返回的内容里如果有##标题、-列表、表格直接塞进rich-text组件基本都会渲染错乱。我用过几种方案最推荐的是“让模型只输出JSON前端自己拼UI”。提示词的输出协议层强制模型把内容拆成title、summary、dimensions、action_tips等字段前端拿到后按设计稿逐字段渲染。JSON结构解析是确定性的不会出现“这行到底是一级标题还是加粗文本”的歧义。如果产品里有大量自由文本段落实在绕不开Markdown可以引入开源的Markdown渲染方案比如towxml系列。但要做好心理准备任何依赖模型格式稳定性的方案都要在提示词里反复强调格式并在前端做容错解析。4.5 内容安全兜底与合规措辞涉及五行、性格分析这类带有解读性质的生成内容上线前必须接入内容安全校验。小程序端本身有能力对文本做敏感词检测但对语境层面的问题判断有限生成内容更多需要靠提示词做前置约束。我的做法是把合规措辞直接写进系统角色层比如强制模型使用“从五行视角看”“倾向于”“可能更适合”这类表达禁止出现“你注定”“一定会”“最适合你”等绝对化断言。这样生成内容从一开始就是温和的建议语气而不是确定性结论。尤其要避免与医疗、投资、重大决策挂钩的表述否则产品随时可能因为内容风险被下架。4.6 缓存降本把高频问题挡在模型外面每次请求都要携带系统角色、知识锚点、映射规则、Few-shot示例这些加起来往往两三千字Token成本不小。高并发时成本会以肉眼可见的速度上涨。我当初做类似功能时实测最有效的降本手段是“按MBTI类型问题场景做缓存”。同一个用户、同一个类型、同一个高频问题第一次调用模型生成结果写入KV缓存之后相同问题直接读缓存返回不重复调用模型。配合云开发的数据库实现起来并不复杂。实际跑下来常见问题命中率高的话成本能降到原来的三分之一甚至更低。5. 实际开发中踩过的坑稳定性的三座大山这个功能做下来我遇到的最大问题不是“模型不够聪明”而是“模型太不稳定”。下面三个坑踩过一遍之后我对“提示词工程”这几个字的理解完全变了。5.1 生克关系被模型“背错”压制训练记忆的干扰有一次让模型分析“土生金”它输出的却是“土生木”。原因很简单大模型对五行生克的记忆来自训练语料而语料里各种口诀混在一起它是在联想不是在计算。修复方法也很直接把生克表完整写进知识锚点层并加上“无论你对五行生克的记忆如何一律以本对话中给出的生克表为准”。这句话非常关键它等于在前面拦了一道闸让模型优先采纳对话内的事实而不是自己脑子里的模糊记忆。修复之后生克关系错误基本没有再出现过。5.2 格式漂移格式约束不能靠“请求语气”请求里明明写了“二级标题用##”模型前两个回答乖乖遵守第三个回答突然用了一级标题加粗小程序前端解析直接崩了。后来我意识到格式约束不能写在“角色描述”里指望模型自觉而是要通过输出协议层彻底“去Markdown化”。改成JSON输出后前端按字段渲染模型根本没有机会产生格式漂移。同时把温度参数调低比如0.2到0.4创造性内容单独开一条更高温度的回答链路。经验是结构化程度越高的输出温度越要低。5.3 人格漂移上下文注入的位置很重要同一个用户第一次问输出“金水相生”过了会儿再问同类型问题输出变成了“木火相生”。原因特别简单用户之前的人格结果没有作为系统级事实注入模型每次把对话都当成独立的空会话。修复方案是把用户已确定的MBTI类型、主导功能、五行主辅拼到System Prompt最前面作为不可变事实。同时要求模型所有回答基于这份事实展开不得重新推导。改完之后人格漂移问题基本归零。这个经验也说明上下文管理不是把历史记录一股脑塞给模型而是把“已经确定的结论”固化下来减少模型每轮重新判断的机会。5.4 成本失控长规则按需拼装知识锚点加映射规则加示例全套拼起来可能三千字每个用户每次请求都发一遍高峰期一天几千次调用成本直接失控。后来我把规则拆成“基础版”和“完整版”两套。基础功能只携带基础属性表关系分析和深度解读才加载完整映射规则。再加上缓存成本能压掉一半以上。提示词架构不只是功能设计也是成本设计——不是每次都传最多字就最聪明而是按需加载给模型够用的上下文反而更稳定。6. 这套“双体系提示词架构”能复用到哪里做完这个项目之后我最大的感受是真正值钱的不是“五行”或“MBTI”这两个具体领域而是“双体系对话”的工程方法。只要两个知识体系需要桥接这套五层提示词架构就适用。6.1 星座与MBTI同一套构架换一张映射表星座的十二属性特点、元素分类火象、土象、风象、水象和MBTI十六型做对话本质上和五行完全同构。把知识锚点层的五行表换成星座元素表映射规则改为“星座元素→性格倾向→与MBTI功能的对应”输出协议保持JSON不变一套架构直接平迁。6.2 中医体质与生活建议知识边界比知识量更重要中医九种体质、日常作息、运动、饮食之间的建议生成是最典型的“传统知识现代AI问答”组合。架构依旧是知识锚点体质特征表、映射规则体质到生活方式的推导路径、输出协议建议卡片。但这一类必须特别谨慎。医疗健康类建议不能做确定性断言不能替代诊断。提示词里应强制模型使用“参考”“建议”“如不确定请咨询专业人士”等表达涉及症状判断的词直接屏蔽。知识边界做得好这类产品反而更容易建立长期信任。6.3 生肖与传统节气问答传统文化的产品化机会生肖、传统节气、民俗文化与AI问答结合当前内容供给很少产品化空间不小。用户缺的从来不是知识而是“让大模型稳定输出、格式化返回、成本可控”的工程能力。五层提示词架构可以直接平移映射表按产品定位重做即可。做这一类传统文化的产品我个人的底线是把内容定位成“文化视角的趣味参考”不渲染宿命论不给确定性结论。当用户问出“我这辈子是不是注定做X”模型要懂得用“从某种视角看你可能更适合……”来回应既保持对话温度又不越界。这个边界感一开始就要写进系统角色层不能指望上线之后再做补救。最后再分享一个亲测有效的小技巧让大模型在双体系之间做“翻译”时不要直接给结论而是把推导过程一并输出。比如用户问“我为什么是金命”模型回答“因为你的主导认知功能是Te外倾思考在功能排序里位列第一我们把它映射到金的收敛与决断属性”信任度比直接说一句“你是金命”高非常多。成本几乎为零但用户留存差异很明显。做文化类AI产品仪式感也是体验的一部分而对外可见的推导过程就是这个产品最真实的仪式感。