1. 为什么“推断”是提示词工程里最容易被低估的一环
很多人做提示词工程，注意力几乎全放在“让模型写点什么”上——写文案、写代码、写邮件。但真正把大模型用出生产力的人，往往更在意另一件事：从一段现成的文本里，把没明说的信息挖出来。这就是“Inferring”，也就是推断。
举个最直白的例子。你手里有一条用户反馈：“这个功能我找了半天没找到，最后放弃了。”表面看这是一句抱怨，但里面其实藏着好几层可推断的信息：用户遇到了导航或信息架构问题、用户的耐心阈值不高、这个功能可能入口太深、用户最终流失。如果只让模型“总结一下这条反馈”，它大概率会给你一句“用户对功能查找体验不满”，信息量几乎为零。但如果提示词设计成“推断这条反馈背后可能的产品问题、用户情绪强度和流失风险”，输出就完全不一样了。
这一篇要聊的，就是怎么用提示词把大模型的“推断能力”稳定地调出来。它适合两类人：一类是已经会用大模型做基础任务、但总觉得输出“不够聪明”的从业者；另一类是做数据分析、用户研究、内容审核、需求整理这类工作，天天要面对大量非结构化文本、急需把隐性信息显性化的人。核心关键词就三个：推断、提示词设计、信息抽取。整篇内容围绕这三个词展开，讲清楚推断类提示词的底层逻辑、设计套路、实测踩坑和可复现的模板。
先说一个反直觉的结论：推断类提示词的效果，八成取决于你把“推断什么”定义得多具体，而不是取决于你用了多花哨的措辞。我见过太多人写“请深入分析这段话”，然后抱怨模型输出空洞。问题不在模型，在于“深入分析”这四个字对模型来说等于没约束。推断的本质是“在已知信息上做有依据的延伸”，所以提示词必须告诉模型：从哪个角度延伸、延伸到什么颗粒度、依据是什么、不确定的时候怎么处理。这四件事讲清楚了，推断质量立刻上一个台阶。
2. 推断和“总结”“分类”到底差在哪：先把任务边界划清楚
2.1 三种任务的心智模型对比
很多人把推断和总结混为一谈，结果提示词写出来四不像。我用一个表格把三者的差别摆清楚，这个对比是我在实际项目里反复用来给团队对齐认知的：
| 任务类型 | 输入到输出的关系 | 典型问法 | 输出特征 | 失败表现 |
|---|---|---|---|---|
| 总结 | 压缩，信息不增加 | “这段话讲了什么” | 更短、更概括 | 漏掉关键细节 |
| 分类 | 映射到既定标签 | “这条属于哪一类” | 从候选集中选一个 | 标签边界模糊时乱选 |
| 推断 | 延伸，信息增加但有依据 | “从这段话能推出什么” | 比原文多出隐性结论 | 无依据地编造 |
关键差别在最后一行。总结和分类都是“信息不增不减或只减不增”，而推断是信息增加。这就带来一个天然风险：模型可能增加的是它自己脑补的东西，而不是文本里真正支撑得住的结论。所以推断类提示词的第一要务不是“让模型多想”，而是“让模型想得有理有据”。
2.2 为什么推断任务对提示词更敏感
分类任务你给个标签集，模型基本能稳定输出；总结任务你给个长度限制，也八九不离十。但推断任务没有天然的边界——从一句话里能推出来的东西理论上无穷多。你今天问“这条评论反映了什么需求”，明天问“这条评论的用户画像是什么”，同一个模型给出的推断方向完全不同。
这意味着推断类提示词必须承担起“划定推断空间”的责任。我通常用三个约束来框定：推断维度（从哪些角度看）、证据要求（每个结论要能指回原文哪句）、置信度标注（拿不准的要标出来）。这三条加上去，输出立刻从“散文”变成“可用的分析结论”。下面几节会分别展开怎么落地。
2.3 一个最小可用的推断提示词骨架
在展开细节之前，先给一个我反复用、几乎可以套到大多数场景的骨架，方便你有个整体印象：
你是一名[角色]。下面是一段[文本类型]。 请从以下维度进行推断：[维度1]、[维度2]、[维度3]。 要求： 1. 每条推断必须标注支撑它的原文片段（引用原句或关键词）； 2. 对把握不足的推断，标注置信度为“低/中/高”； 3. 不要引入原文没有依据的外部信息； 4. 如果某个维度无法推断，明确写“信息不足”，不要硬编。 文本：[...]这个骨架看起来朴素，但它把“推断什么、凭什么推、推不准怎么办”三件事都写死了。后面所有进阶技巧，都是在这个骨架上做加法。
3. 把“推断什么”写死：维度拆解是提示词的地基
3.1 维度不是越多越好，而是要“正交且可验证”
新手最容易犯的错，是把推断维度写成一大串近义词：“请分析用户的需求、诉求、期望、想法、意图”。这五个词在模型眼里高度重叠，输出会反复说同一件事。正确的做法是让维度之间正交——每个维度回答一个不同的问题，彼此不重叠。
以用户反馈推断为例，我常用的正交维度组是这样的：表层诉求（用户明说了要什么）、深层动机（用户为什么会有这个诉求）、情绪状态（强度与正负）、行为倾向（接下来可能做什么，比如流失、投诉、复购）、产品线索（文本暴露出的功能或体验问题）。这五个维度分别对应“要什么、为什么、什么感受、会怎样、哪里出了问题”，互不重叠，合起来又能拼出一个完整判断。
3.2 每个维度配一句“操作定义”，模型才不会跑偏
光给维度名还不够。“情绪状态”这种词，模型可能理解成“分析作者写作时的情绪”，也可能理解成“分析文本传达给读者的情绪”。差别很大。我的做法是给每个维度补一句操作定义，明确“看什么、输出什么格式”。
比如“行为倾向”这个维度，操作定义写成：“基于文本中表达的不满程度和已采取的行动（如已放弃、已投诉、表示会再试），推断该用户接下来最可能的1到2个行为，并说明依据。”这样模型就知道要从“已采取行动”和“不满程度”两个抓手去推，而不是泛泛而谈。
3.3 维度拆解的实操：从“一句话需求”到“五维推断表”
拿一个真实场景走一遍。假设输入文本是：“更新之后登录要验证两次，烦死了，再这样我就换别家了。”
按上面的五维框架，提示词要求模型输出一张表。实测输出大致是：
| 推断维度 | 推断结论 | 原文依据 | 置信度 |
|---|---|---|---|
| 表层诉求 | 希望取消重复验证 | “登录要验证两次” | 高 |
| 深层动机 | 追求操作效率，反感流程冗余 | “烦死了” | 中 |
| 情绪状态 | 强负面，接近忍耐临界点 | “烦死了”“再这样” | 高 |
| 行为倾向 | 高流失风险，可能已开始比较替代方案 | “换别家” | 中 |
| 产品线索 | 版本更新引入了多余的验证步骤 | “更新之后” | 高 |
这张表的价值在于：每一条结论都能指回原文，产品同学拿到手可以直接排优先级，而不用再回头读原始文本。这就是“维度+证据+置信度”三件套的威力。如果只写“请分析这条反馈”，你拿到的多半是一段没法直接用的散文。
3.4 维度数量控制在3到6个，超过就要分组
我试过给模型塞十个推断维度，结果输出质量断崖式下跌——模型会平均用力，每个维度都写得很浅，还容易串味。经验值是3到6个维度最舒服。如果业务确实需要更多角度，就分两轮推断：第一轮做核心维度，第二轮基于第一轮结论做深挖。比如先推断“问题+情绪+行为”，再针对“行为倾向=高流失”的样本做第二轮“流失原因推断”。分轮做比一次性堆维度稳得多。
4. 让推断“有据可查”：证据锚定与置信度标注
4.1 没有证据锚定的推断，等于让模型自由发挥
推断类提示词最大的坑，是模型给你一段听起来很专业、但原文根本没支撑的结论。比如输入只是“页面加载有点慢”，模型却能推出“该用户所在地区网络基础设施较差”。这种推断一旦进入业务决策，就是灾难。
解决办法是强制证据锚定：要求每条推断后面附上原文引用。提示词里明确写“每条结论必须引用原文中的词或句子作为依据，若找不到依据则不得输出该结论”。这一条加上去，模型的“脑补率”会明显下降，因为它被要求对自己的输出负责。
4.2 置信度标注怎么设计才有用
置信度不是让模型随便标个“高/中/低”就完事。要让标注有意义，得给它判断标准。我在提示词里通常这样定义：高——原文有直接表述支撑；中——原文有间接线索但需一步推理；低——仅有微弱暗示，存在其他解释。把标准写进提示词，模型标注的分布才会合理，而不是清一色“高”。
这个设计在实际使用中特别有用。做批量文本分析时，我会先把“低置信度”的推断过滤掉或人工复核，只让高、中置信度的结论进入下游流程。这相当于给推断结果加了一道质量闸门。
4.3 处理“信息不足”：明确说不知道比硬编更有价值
推断任务里，“信息不足”是一个合法且重要的输出。但模型天生倾向于“给个答案”，所以提示词必须显式授权它说不知道。我常用的写法是：“如果某个维度在原文中缺乏足够依据，请输出‘信息不足’，并说明缺少哪类信息，不要进行推测性填充。”
这条约束带来的好处是双向的：一方面减少了编造，另一方面“缺少哪类信息”本身就是有价值的元信息——它告诉你，要提升推断质量，还需要补充采集什么数据。比如大量反馈在“产品线索”维度都是“信息不足”，说明你的文本采集可能漏掉了关键上下文。
4.4 证据锚定的一个进阶玩法：反向验证
推断做完之后，可以再加一步“反向验证”提示：让模型检查自己给出的每条推断，问一句“如果这条推断是错的，原文会是什么样”。这一步能逼出一些站不住脚的结论。实测下来，大约能筛掉一到两成过度推断。这个技巧在需要高准确率的场景（比如合规审核、风险识别）里特别值得加，成本只是多一轮调用。
5. 推断类提示词的四种典型场景与模板
5.1 场景一：从用户反馈推断需求与风险
这是推断最经典的应用。模板核心是把“反馈”翻译成“产品语言”。提示词除了五维框架，我还会加一条“按业务影响排序输出”，让模型把推断结论按严重程度排个序。这样产出的不是一张平铺的表，而是一份带优先级的清单，产品同学直接能用。
5.2 场景二：从对话记录推断意图与下一步
客服对话、销售对话这类文本，推断重点是“对方真正想要什么”和“下一步该做什么”。这里的维度我会换成：显性意图、隐性顾虑、决策阶段、建议回应策略。特别注意“隐性顾虑”这个维度——客户嘴上说“我再看看”，推断出的顾虑可能是价格、可能是信任、可能是决策权不在他手里。提示词要求模型给出“支持该顾虑的原文线索”，避免瞎猜。
5.3 场景三：从长文档推断结构化结论
合同、报告、会议纪要这类长文本，推断的价值在于“把散落的信息聚成结论”。这类场景提示词要强调“跨段落综合”——要求模型在推断时引用多个位置的原文，而不是只盯着一句话。我通常会让它先做一遍“关键事实抽取”，再做“基于事实的推断”，两步走比一步到位稳。
5.4 场景四：从数据描述推断异常与原因
给模型一段指标描述（比如“本周转化率下降15%，主要集中在移动端新用户”），让它推断可能原因。这类推断风险最高，因为原因空间太大。我的做法是强制模型输出“假设列表”而非“结论”，每条假设标注“可验证方式”——比如“假设：新用户引导流程改动导致，验证方式：对比改动前后新用户首日完成率”。把推断变成“待验证假设”，既保留了推断的价值，又避免了把猜测当事实。
6. 实测踩坑：推断提示词最容易翻车的五个地方
6.1 坑一：维度写得太抽象，输出全是正确的废话
最早我做推断提示词，写的是“请深入分析这段文本的深层含义”。结果模型输出“该文本表达了用户的不满情绪，建议关注用户体验”。这话永远正确，也永远没用。根因是“深层含义”没有操作定义。后来改成具体维度加证据要求，输出才落地。教训：抽象形容词是推断提示词的天敌。
6.2 坑二：没限制推断范围，模型开始“写小说”
有一次做评论推断，没限定“只基于文本”，模型给一条普通差评推断出了“该用户可能近期遭遇生活挫折，情绪迁移到产品上”。这就是典型的过度推断。修复方法是加“禁止引入文本外的个人背景假设”这条硬约束，并且要求每条推断都能指回原文。推断的边界是文本，越界就是编造。
6.3 坑三：置信度标注形同虚设
早期我让模型标置信度，结果它几乎全标“高”。后来发现是没给判断标准。补上“高=直接表述、中=间接线索、低=微弱暗示”的定义后，分布才正常。任何让模型自评的字段，都必须给评分标准，否则等于没评。
6.4 坑四：一次推断维度太多，输出互相污染
前面提过，维度超过六个，模型会串味。我遇到过“情绪状态”维度里混进了“行为倾向”的内容。解决办法是分轮推断，或者把维度分组、每组单独一次调用。宁可多调几次，不要一次塞满。
6.5 坑五：忽略“信息不足”的合法地位
最开始我没授权模型说“不知道”，结果它在信息稀薄的文本上硬编，产出大量低质量推断。加上“信息不足”选项后，整体输出质量反而提升了，因为模型不再被迫在没依据的地方凑答案。允许模型说不知道，是提升推断可信度最便宜的一招。
7. 把推断做成流水线：批量处理与质量抽检
单条文本的推断做顺了，下一步就是批量。批量场景下，提示词要额外考虑两件事：输出格式的机器可解析性和质量抽检机制。
格式上，我一般要求模型输出JSON或固定列的表格，字段名固定，方便下游脚本直接消费。比如每条推断输出{维度, 结论, 依据, 置信度}四个字段。这样几百条文本跑完，可以直接入库做统计，比如“高置信度流失倾向占比”。
质量抽检上，我会随机抽10%的推断结果人工核对，重点看两件事：证据是否真的支撑结论、置信度标注是否合理。抽检发现系统性偏差（比如某类文本总是过度推断），就回头改提示词里的维度定义或约束条件。这个“跑批—抽检—改提示词”的循环，比一次性把提示词打磨到完美更现实。
还有一个实操细节：批量推断时，把“角色设定”和“推断规则”放在系统提示里，把“待推断文本”放在用户消息里，这样规则部分可以被缓存复用，成本和延迟都会好一些。文本特别长的时候，先做一轮关键句抽取再推断，比直接塞全文更稳，也更省。
推断这件事，说到底是在教模型“有分寸地多想一步”。分寸来自维度定义和证据约束，多想一步来自你给的推断空间。这两者平衡好了，大模型就不再只是一个“会写字”的工具，而是一个能帮你从海量文本里读出弦外之音的分析助手。我自己在项目里最深的体会是：推断提示词的迭代，本质上是在迭代你对业务问题的理解——你能把“想从文本里知道什么”拆得多清楚，模型就能推断得多准。
