意图推理是提示词工程里难度偏高的一类任务。它不是简单地让模型回答问题，而是要求模型基于有限的表面信息，推测出行为背后的真实动机。用户嘴上说的和心里想的往往不一致，点击、停留、取消、重复操作这些行为背后都藏着没有直接表达出来的诉求。如果提示词写得含糊，模型很容易给出武断的结论，或者干脆把表面行为复述一遍就交差。这篇文章会拆解意图推理提示词的设计思路，给出可直接复用的结构模板和调试方法。
为什么行为和意图之间会有落差
要设计好意图推理的提示词，首先得理解落差产生的原因。第一种落差来自表达能力限制，用户不知道怎么准确描述自己的需求。比如用户反馈"这个按钮不好用"，可能是按钮位置不合理、可能是响应太慢、也可能是文案有歧义，用户自己说不清楚，只能给一个笼统的评价。
第二种落差来自场景约束。用户在某些场合不方便直接说出真实目的。典型例子是企业采购场景中，联系人的诉求可能代表整个部门的流程痛点，但他只会描述自己的操作步骤，不会上升到流程层面的总结。
第三种落差来自认知偏差。用户有时会把解决方案当成需求本身。用户说"我需要一个导出Excel的功能"，真实意图可能是"领导要一份月度汇总数据"，导出Excel只是他想到的实现方式。如果系统未来提供自动生成的月报，他的问题同样被解决了。理解这三种落差，能帮助你在写提示词时引导模型去区分表面诉求和深层意图。
意图推理提示词的核心结构
一个稳定的意图推理提示词通常包含五个部分：角色与任务定义、输入信息说明、推理规则约束、不确定性处理机制、输出格式定义。很多人写这类提示词失败，就是因为只有第一和第五部分，中间的推理规则完全缺失，导致模型只能凭感觉下结论。
角色设定上，建议给模型一个具体的专业身份，比如"资深用户研究员"或"客服质检专家"，而不是泛泛的"助手"。专业身份会激活模型在训练中学到的相关领域知识，让推理更有章法。推理规则部分是核心，需要明确告诉模型从哪些维度观察行为、按什么优先级排除假设、什么情况下应该输出不确定结论。
你是一名资深用户研究员，擅长从用户行为中推断真实意图。 【任务】 分析下方用户行为记录，推断其真实意图，并给出置信度和依据。 【推理规则】 1. 先列出所有 plausible 的意图假设（至少2个，不超过4个） 2. 对每个假设，找出支持与反对的行为证据 3. 优先采信有多次行为佐证的假设，单次行为只能作为弱证据 4. 证据不足以区分时，明确输出"意图不确定"，不要强行选择 5. 区分"用户表达的诉求"与"用户可能的深层需求"，两者分开输出 【输出格式】 - 表面诉求： - 深层意图：（置信度：高/中/低） - 支持证据： - 反对证据： - 建议的下一步确认动作：
这个模板里最值得注意的一点是要求模型先列出多个假设再逐一验证，而不是直接跳到结论。这种"先发散后收敛"的强制流程，能显著降低模型的武断倾向。另外，输出"建议的下一步确认动作"也很重要，意图推理的产出不应该只是判断，还应该包含验证判断的行动建议，这样整个推理链条才是闭环的。
典型场景应用与常见错误
在客服对话分析场景中，意图推理提示词常用来识别高风险用户。比如用户三次提到"算了不弄了"，单看文字是放弃，但如果同时伴随多次重新登录、反复查看订单详情的行为，真实意图可能是"想要一个挽留方案"。这时提示词中必须把行为序列和时间戳作为输入提供进去，只给对话文本是不够的。
产品反馈分析是另一个高频场景。用户提交的反馈往往是零散的抱怨，需要模型归纳出背后的共性需求。这种场景下提示词要加入归纳层级的约束，比如"将反馈映射到功能层、流程层、预期层三个层级，每层分别给出意图描述"，避免模型把所有问题都堆在一个平面上。
常见的错误写法有三种。第一种是让模型"猜猜用户在想什么"，没有任何证据约束，模型会输出看起来流畅但毫无依据的推测。第二种是把推理规则写得过长过细，模型反而抓不住重点，规则控制在五到八条效果最好。第三种是忽略了"不确定"这个合法输出选项，强迫模型必须给出明确意图，结果模型在证据不足时会编造理由。允许模型承认不确定，是让推理结果可信的前提。调试时建议准备一组已经有人工标注结论的样本，用同一份提示词批量跑一遍，对比模型输出和人工结论的差异，针对分歧样本调整推理规则的措辞，这比盲目改提示词有效得多。