企业官网建设流程全解析

做提示词工程做到第四个模块，很多人会卡在一个坎上：前面写角色、给格式、塞示例都玩得转，可一旦让模型去“推断”点没明说的东西，输出就开始飘。要么过度脑补，要么保守到什么都不肯说，要么把推断结论和事实陈述搅在一起，读起来像一锅粥。这个模块要解决的就是这件事——让模型基于已有信息做出合理、有边界、可追溯的推断，而不是瞎猜或者装傻。

我把它放在整个提示词工程系列的第四篇，是因为推断能力是前面几个模块的“合流点”：你得先有清晰的角色设定，模型才知道站在谁的立场上推断；你得有结构化的输出约束，推断结果才能被下游直接消费；你得有示例引导，模型才能学会“推断到什么程度算合适”。所以这篇不是孤立技巧，而是把前面攒的功夫用在“从已知推未知”这个高频场景上。适合已经能写出基本可用提示词、但想让模型输出更有信息密度的朋友，也适合刚接触这块、想少走弯路的新手——我会把踩过的坑和能直接抄的模板都摆出来。

1. 先搞清楚“推断”在提示词里到底指什么

1.1 推断不是猜测，边界感是核心

很多人一上来就把“推断”和“让模型自由发挥”划等号，这是第一个大坑。在提示词语境里，推断（Inferring）指的是：基于输入中明确给出的信息，结合常识与领域逻辑，得出没有直接写出但高度可信的结论。它和“猜测”的区别在于证据链——推断的每一步都应该能回溯到原文的某个线索，而猜测是凭空补全。

举个生活化的例子。你看到同事桌上放着一把湿漉漉的伞和一件滴水的外套，你推断“外面在下雨”，这是推断，因为证据（湿伞、滴水外套）支撑结论。但如果你推断“他今天心情不好”，那就越界了，因为证据链断了。模型做推断时同样需要这条链，提示词的任务就是把“允许推断的范围”和“必须止步的红线”划清楚。

我见过太多提示词只写一句“请推断用户的意图”，结果模型要么把用户没说的隐私偏好也编出来，要么面对明显线索却说“无法确定”。问题不在模型，在于提示词没给边界。你得明确告诉它：基于哪些字段推断、推断结论要标注置信度、证据不足时输出“信息不足”而不是硬编。这三条一加，输出质量立刻不一样。

1.2 为什么这个模块值得单独拎出来讲

前面几个模块处理的是“把已知信息组织好”，推断模块处理的是“从已知信息里榨出更多价值”。这两件事的难度不在一个量级。组织信息是确定性的，模型照着格式填就行；推断是不确定性的，模型得自己判断“推多远算合理”。不确定性一上来，提示词的容错设计就变得极其关键。

从应用场景看，推断几乎是所有稍微智能一点的需求的底层能力。客服系统要根据用户几句话推断真实诉求和情绪状态；内容审核要根据文本推断潜在风险等级；数据分析要根据历史行为推断用户分层；甚至写文案时根据产品卖点推断目标人群的痛点，都是推断。这些场景的共同点是：推断结果要能直接支撑决策，所以不能是模棱两可的废话，也不能是过度自信的瞎话。

我自己的体会是，推断类提示词的调试成本比普通提示词高不少，因为你要反复校准“推多远”。但一旦调好，它的复用价值也最高——同一套推断框架换个领域字段就能用。所以这个模块值得花时间单独打磨，而不是随手写两句了事。

1.3 推断类提示词的三个典型失败模式

在动手写之前，先认清失败长什么样，调试时才有方向。我总结下来最常见的是这三种：

第一种是过度推断。模型把蛛丝马迹放大成铁板钉钉的结论，还特别自信。比如输入里只提到用户“最近查询了退款流程”，模型就推断“用户对产品极度不满，有流失风险，建议立即人工介入”。这就推过头了，查询退款流程可能只是好奇，也可能是在帮别人问。过度推断在涉及用户画像、风险评估的场景里特别危险，容易导致误判。

第二种是推断不足。模型变得过度保守，明明线索很充分，它却反复说“无法确定”“信息不足”。这种情况通常是因为提示词里的约束写得太死，比如“只输出确定的事实”，模型就干脆什么都不推了。推断不足让输出变得没营养，等于白跑一趟。

第三种是事实与推断混淆。模型把推断结论和原文事实混在一起输出，读者分不清哪句是输入里写的、哪句是模型推的。这在需要审计或复核的场景里是硬伤，因为一旦推断错了，你连错在哪一步都追不到。解决办法是强制分离输出结构，事实归事实、推断归推断、证据归证据，三者分栏呈现。

认清这三种失败模式后，后面所有的提示词设计其实都在做一件事：把模型往“合理推断”的中间地带拽，既不冒进也不退缩，同时保证输出可追溯。

2. 推断类提示词的结构骨架怎么搭

2.1 四段式结构：任务、证据、规则、输出

我调试推断类提示词时，基本都套一个四段式骨架，实测下来稳定性最好。这四段分别是：任务定义、证据范围、推断规则、输出格式。缺一段，输出就容易在某方面出问题。

任务定义段回答“推断什么”。要具体到字段级别，比如“推断用户的购买意向等级”，而不是笼统的“分析用户”。字段越具体，模型越不容易跑偏。证据范围段回答“基于什么推断”，把允许使用的输入字段列清楚，同时明确哪些字段不能拿来推断（比如涉及隐私的、来源不可靠的）。推断规则段是核心，回答“怎么推、推多远”，包括置信度怎么标、证据不足怎么办、多条线索冲突时怎么处理。输出格式段回答“推完怎么呈现”，强制分离事实、推断、证据三部分。

这四段看起来朴素，但每一段都有讲究。我试过省掉证据范围段，结果模型开始拿输入里根本没提的东西当依据；也试过省掉推断规则段，模型要么过度自信要么过度保守。四段齐全之后，调试就从“碰运气”变成了“定点修”——哪段出问题改哪段，效率高很多。

2.2 证据范围段：把“能用的料”圈出来

证据范围这一段最容易被忽略，但它直接决定了推断的地基稳不稳。写法上，我习惯用“可用证据”和“禁用证据”两个清单来圈定范围。可用证据列出输入中哪些字段可以作为推断依据，禁用证据列出哪些字段即使存在也不能用。

为什么要分两个清单？因为模型对“可用”的理解往往比你想的宽。你只说“基于用户行为推断”，模型可能把用户填写的昵称、头像风格都拿来当行为证据，这就跑偏了。明确禁用清单能堵住这类漏洞。比如做客服意图推断时，我会写：可用证据包括用户消息文本、历史工单类型、当前会话轮次；禁用证据包括用户昵称、地区、设备型号等与意图无直接关联的字段。

还有一个细节：证据范围要标注证据强度。同样是可用证据，用户明确说“我要退款”是强证据，用户问“退款要多久”是中等证据，用户浏览过退款页面是弱证据。提示词里把强度分级写清楚，模型在推断时就会自动权衡，而不是把所有线索一视同仁。这个技巧我在多个项目里用过，对减少过度推断特别有效。

2.3 推断规则段：置信度、冲突处理、止损线

推断规则段是整个骨架里最需要打磨的部分，我通常会把三件事写死：置信度标注、冲突处理、止损线。

置信度标注要求模型对每条推断给出高、中、低三档，并说明理由。别小看这个要求，它逼着模型在输出前先自我评估一遍，过度自信的情况会明显减少。我一般会定义清楚三档的标准：高置信度指有直接强证据支撑、且无矛盾线索；中置信度指有间接证据或存在轻微矛盾；低置信度指仅有弱证据或线索稀疏。标准写清楚，模型的分档才不会乱。

冲突处理是指多条证据指向不同结论时怎么办。比如用户消息里既说“想续费”又抱怨“价格贵”，这时候推断续费意向就得处理这个矛盾。我的做法是要求模型列出冲突点，并说明最终结论偏向哪一方、为什么。这样即使推断结果有争议，读者也能看到推理过程，而不是面对一个突兀的结论。

止损线是防止过度推断的闸门。我会明确写：当可用证据不足以支撑任何一档置信度时，输出“信息不足，无法推断”，并列出还需要哪些信息才能推断。这条线一划，模型就不会硬编了。实测下来，止损线加上之后，输出里“信息不足”的比例会上升，但剩下的推断质量明显更靠谱，整体可用性反而更高。

2.4 输出格式段：三栏分离让结果可审计

输出格式我坚持三栏分离：事实陈述、推断结论、支撑证据。事实陈述只写输入里明确有的内容，推断结论写模型推出来的判断（带置信度），支撑证据写每条推断对应哪些事实线索。三栏分开，读者一眼就能分清哪些是“看到的”、哪些是“想到的”。

这个结构在需要复核的场景里价值极大。比如内容风险推断，审核员看到一条“高风险”结论，能立刻顺着支撑证据栏回溯到具体文本线索，判断推断是否合理。如果三栏混在一起，复核就得靠猜，效率低还容易漏。我在实际项目里对比过，三栏分离的输出让复核时间大概缩短了一半，因为不用再逐句分辨哪句是事实哪句是推断。

格式上我一般用带标签的段落或简单表格，不搞太复杂的嵌套。标签用“【事实】”“【推断】”“【证据】”这种直白的标记，模型不容易写错，下游解析也方便。如果推断有多条，就按条目编号，每条推断下面挂对应的证据，结构清晰不打架。

3. 把推断提示词落到具体场景的实操

3.1 场景一：从用户消息推断真实诉求

这是推断类提示词最高频的用法。用户说的话往往不是他真正想要的，得从字里行间推。我拿一个模拟的客服场景来演示，输入是用户发来的一段话：“你们这个会员自动续费怎么关啊，我上个月就被扣了，也没收到提醒。”

先看这段话里有什么。事实层面：用户询问关闭自动续费的方法、提到上个月被扣费、提到没收到提醒。推断层面可以推什么？第一，用户当前的核心诉求大概率是“停止后续扣费”，而不只是“知道怎么关”，因为已经发生了实际扣费，紧迫性更高。第二，用户对“没收到提醒”有不满情绪，这可能是潜在的投诉点。第三，用户的续费意愿为负，短期内不太可能主动续费。

按四段式骨架写提示词，任务定义是“推断用户的真实诉求、情绪状态、续费意愿”，证据范围圈定用户消息文本和当前会话上下文，推断规则要求每条结论标置信度并挂证据，输出格式三栏分离。跑出来的结果里，“停止扣费”诉求给高置信度（有直接表述“怎么关”加已扣费事实），“不满情绪”给中置信度（有“没收到提醒”的抱怨但语气不算激烈），“续费意愿为负”给高置信度（明确要关闭）。

这里有个实操心得：推断诉求时要区分“表层诉求”和“深层诉求”。表层诉求是用户嘴上问的（怎么关），深层诉求是他真正想达成的（别再扣我钱）。提示词里明确要求模型同时输出这两层，客服拿到结果就知道不光要回答操作方法，还得主动确认扣费情况和补偿方案，响应质量完全不一样。这个双层结构我在多个客服类项目里复用，效果稳定。

3.2 场景二：从文本内容推断风险等级

内容审核场景里的推断，难点在于“风险”本身是模糊概念，得先把它拆成可推断的子维度。我的做法是把风险拆成几个具体维度：是否包含攻击性表达、是否涉及敏感话题、是否存在误导性信息、情绪激烈程度。每个维度单独推断，最后再综合评级。

提示词里，任务定义写“对给定文本做多维度风险推断”，证据范围限定为文本本身（不引入外部信息），推断规则要求每个维度给置信度和原文引用作为证据，综合评级时说明各维度权重。输出格式用表格，每个维度一行，列是维度名、推断结果、置信度、证据引用。

跑一个模拟例子，输入是一段带情绪的产品吐槽：“这破玩意儿用了三天就坏，客服还爱答不理，真是服了。”推断结果：攻击性表达维度给中置信度（有“破玩意儿”但属于对产品的吐槽而非人身攻击），敏感话题维度给低置信度（无明显敏感内容），误导性信息维度给低置信度（属于主观体验陈述），情绪激烈程度给高置信度（用词和语气明显激动）。综合评级为“低风险但需关注情绪”。

这个场景的实操关键是维度拆分要正交，也就是各维度之间尽量不重叠，否则综合评级时权重会打架。我一开始没注意这点，把“攻击性”和“情绪激烈”混成一个维度，结果模型推断时反复纠结，输出很不稳定。拆开之后各推各的，最后再综合，逻辑就顺了。另外，证据引用一定要原文摘录，不能是模型转述，否则复核时对不上原文。

3.3 场景三：从行为数据推断用户分层

行为数据推断的特点是线索多但噪声大，提示词的重点要放在“证据筛选”上。假设输入是一组模拟的用户行为记录：近30天登录12次、浏览商品页40次、加购3次、下单0次、咨询客服1次（问的是配送时效）。

任务定义是“推断用户的购买意向层级和主要顾虑”。证据范围要明确哪些行为算强信号、哪些算弱信号：加购是强信号，浏览频次是中等信号，登录次数是弱信号，咨询内容要看具体问什么。推断规则要求模型先给每条行为打信号强度标签，再综合推断，冲突时说明取舍。

推断结果大致是：购买意向中高（加购3次是强信号，浏览40次说明持续关注），主要顾虑可能是配送时效（咨询内容指向）或价格（加购未下单的常见原因，但证据较弱）。这里置信度要分开标：意向层级给中置信度（有强信号但下单转化为零存在矛盾），配送顾虑给中置信度（有直接咨询证据），价格顾虑给低置信度（纯属常见模式推测，无直接证据）。

这个场景我踩过的坑是把行为频次直接等同于意向强度。登录12次不一定比登录5次意向强，可能只是习惯性打开。所以提示词里我加了一条规则：频次类证据必须结合行为类型判断，单一频次不单独支撑高置信度结论。加上这条之后，推断结果明显更克制也更准。另外，咨询内容这类文本证据权重通常高于纯行为计数，因为它携带的信息更具体，提示词里值得单独强调。

3.4 场景四：从产品描述推断目标人群痛点

这个场景偏内容创作方向，推断的是“什么样的用户会为什么买”。输入是一段模拟的产品描述：“这款便携榨汁杯，USB充电，一次榨一杯，杯身可拆洗，重量300克。”

任务定义是“推断核心目标人群及其主要痛点”。证据范围限定为产品描述中的功能点和参数。推断规则要求每条人群-痛点配对都要挂到具体功能点上，不能凭空联想。输出格式按“功能点→对应人群→对应痛点→置信度”组织。

推断结果举例：USB充电和便携（300克）指向通勤人群和健身人群，痛点是“外出时想喝鲜榨但嫌麻烦”；可拆洗指向注重清洁便利的人群，痛点是“榨汁杯难洗导致闲置”；一次榨一杯指向单人使用场景，痛点是“大容量机器浪费且占地方”。每条都挂到了具体功能点，置信度按功能点与人群的关联紧密度来标。

这里的实操心得是功能点到痛点的映射要克制。一个功能点可能对应多个人群，但提示词里要要求模型优先输出关联最直接的那一两个，而不是穷举。穷举会让输出变得又长又水，决策价值反而低。我一般会加一句“每个人群-痛点配对须说明该功能点为何直接解决该痛点，关联不直接的不输出”，这样输出密度就上来了。

4. 调试推断提示词的常见坑与排查表

4.1 输出太飘或太怂，先查规则段

推断类提示词出问题，十有八九出在推断规则段。输出太飘（过度推断），通常是置信度标准没写清楚，或者止损线缺失，模型觉得“推了也没代价”。输出太怂（推断不足），通常是约束写得太死，比如“只输出有直接证据的结论”，模型就干脆不推了。

排查顺序我一般是：先看置信度三档的定义是否可操作，再看止损线是否明确，最后看有没有“鼓励合理推断”的正向引导。很多人只写约束不写引导，模型接收到的全是“不许这不许那”，自然就缩了。加一句“在证据支持的前提下，鼓励给出有信息量的推断结论”，能明显改善推断不足的问题。这个正负平衡的思路，是我调试了十几版提示词之后才悟出来的。

4.2 事实和推断搅在一起，靠格式强制分离

这个问题的根源往往是输出格式段写得太松。如果只写“请输出推断结果”，模型很自然会把事实和推断揉在一段话里。解决办法不是反复叮嘱“别混”，而是用格式强制分离——三栏标签一上，模型想混都难。

我还会在格式段加一条：每条推断结论后面必须紧跟“依据：”并引用事实栏中的对应条目编号。这样推断和事实之间有了显式链接，混在一起的情况基本绝迹。如果模型偶尔还是混，就在示例里给一个反例，展示“混着写”和“分开写”的对比，模型学得很快。示例引导在格式纠偏上比纯文字约束有效得多，这点我在前面模块就验证过，这里同样适用。

4.3 证据不足时硬编，止损线要写死

模型硬编推断是本能，因为它被训练成“尽量给出有用回答”。要压住这个本能，止损线必须写得非常明确，不能留模糊空间。我一般这么写：“当可用证据无法支撑任何一档置信度时，必须输出‘信息不足’，并列出推断所需但当前缺失的信息项。禁止在证据不足时给出推测性结论。”

关键词是“必须”和“禁止”，语气要硬。软绵绵的“建议在证据不足时说明”基本没用，模型会选择性忽略。另外，止损线最好配合示例，给一个“证据不足正确输出”的样例，模型照着样例走，硬编的情况会大幅减少。我实测过，加了止损线示例之后，硬编率大概从三成降到了一成以内，剩下的漏网之鱼再靠置信度标注兜底。

4.4 常见问题速查表

这张表我基本每次调新场景都会过一遍，大部分问题能对上号。表里没覆盖的，多半是场景特有的逻辑问题，那就得回到任务定义段重新想清楚“到底要推断什么”。

5. 让推断结果真正可用的几个进阶技巧

5.1 给推断结论加“可行动建议”字段

推断本身不产生价值，推断支撑的行动才产生价值。所以我习惯在输出格式里加一栏“建议动作”，要求模型基于推断结论给出下一步建议。比如客服场景推断出“用户核心诉求是停止扣费且有不满情绪”，建议动作就是“优先确认扣费明细并提供关闭指引，视情况给出补偿方案”。

这一栏的价值在于逼着模型把推断落到具体场景里，而不是停在抽象结论上。加了建议动作之后，输出从“分析报告”变成了“决策辅助”，可用性上了一个台阶。要注意的是，建议动作也要标置信度关联——高置信度推断对应明确建议，低置信度推断对应“建议进一步核实”这类保守动作，避免基于弱推断做出激进决策。

5.2 用少样本示例校准推断尺度

推断的“尺度感”很难用文字描述清楚，用示例校准最有效。我一般给两到三个示例，覆盖“合理推断”“过度推断（反例）”“推断不足（反例）”三种情况，让模型通过对比理解边界在哪。

示例的写法有讲究：合理推断的示例要展示完整的证据链和置信度标注；过度推断的反例要标出“哪一步越界了”；推断不足的反例要标出“哪些线索被浪费了”。三个示例一摆，模型对“推多远”的把握会准很多。我在一个风险推断项目里对比过，加示例前后，人工复核的返工率差了将近一倍。示例的成本是一次性的，收益是持续的，这笔账很划算。

5.3 分步推断比一步到位更稳

复杂推断场景里，让模型一步给出最终结论往往不稳。更好的做法是拆成两步：第一步只做证据提取和信号强度标注，第二步基于第一步的结果做综合推断。两步之间用明确的分隔，第一步的输出作为第二步的输入。

分步的好处是每步的认知负荷都降低了，模型不容易在长链条推理里跑偏。而且第一步的证据提取结果本身就有价值，即使第二步推断有争议，证据部分还能复用。我在用户分层那个场景里就是分步做的：先让模型把每条行为打上信号强度标签，再基于标签做分层推断，稳定性比一步到位好不少。分步的代价是提示词变长、调用次数变多，但对准确性要求高的场景，这个代价值得付。

5.4 定期用“对抗样本”检验推断边界

提示词上线不是终点，得定期拿边界案例去撞一撞，看推断会不会越界或退缩。我一般准备一组对抗样本：证据极少的（测止损线）、证据冲突的（测冲突处理）、证据充分但结论反直觉的（测是否被常识带偏）、包含诱导性表述的（测是否被带节奏）。

拿这组样本定期跑一遍，能提前发现提示词在真实数据分布变化后的漂移。比如业务场景从“售前咨询”扩展到“售后投诉”，原来的证据强度标准可能就不适用了，对抗样本能帮你快速定位哪里需要调。这个习惯我从第三个模块就养成了，推断模块尤其需要，因为推断的边界比格式更容易随场景漂移。

6. 推断模块和前面模块怎么串起来用

6.1 角色设定决定推断立场

推断结论的立场很大程度上由角色设定决定。同一个用户消息，以“客服专员”角色推断和以“风控专员”角色推断，关注点和结论会完全不同。所以推断提示词里的角色设定不能随便写，要跟推断目标对齐。

我的做法是把角色设定写得更具体：不只是“你是客服”，而是“你是一名负责续费挽留的客服专员，关注用户流失信号和挽回机会”。角色越具体，推断的注意力分配越准。这个思路其实是从第一个模块（角色设定）延续下来的，只是在推断场景里，角色的作用从“决定说话风格”变成了“决定推断视角”，值得重新审视一遍角色描述。

6.2 结构化输出是推断结果的容器

推断结果如果是一段自由文本，下游几乎没法用。所以第三个模块（结构化输出）的功夫在这里必须用上。三栏分离、条目编号、置信度标签，这些都是结构化输出的具体应用。我甚至会把推断结果的字段名固定下来，方便下游程序直接解析。

结构化还有一个隐性好处：它逼着模型把模糊的推断拆成离散的字段，拆的过程本身就是一次自我检查。模型在填“置信度”字段时，会不自觉地重新评估一遍证据够不够。这种“格式倒逼质量”的效果，在推断场景里比在普通输出场景里更明显。

6.3 示例引导降低推断的方差

推断类任务的输出方差天然比格式化任务大，因为“推多远”没有唯一答案。示例引导是压方差最有效的手段。我在推断提示词里放的示例，重点不是展示“标准答案”，而是展示“推理过程的写法”——证据怎么引、置信度怎么标、冲突怎么处理。

示例数量上，两到三个足够，太多反而会让模型过度模仿示例的具体内容而不是学习推理方式。示例的选择要覆盖不同置信度档位，让模型看到高、中、低三档分别长什么样。这个做法和第二个模块（示例引导）一脉相承，只是在推断场景里，示例的重点从“输出长什么样”偏向了“推理怎么走”。

7. 我踩过的几个真实坑

7.1 把“推断”写成“分析”，模型开始写小作文

早期我写任务定义时用了“请分析用户意图”，结果模型输出了一大段分析性文字，有结论有论述，但就是没有清晰的结构化推断结果。问题出在“分析”这个词太开放，模型的理解是“写一段分析”。后来改成“请推断并输出以下字段：核心诉求、情绪状态、续费意愿，每个字段给置信度和证据”，输出立刻收敛了。

这个坑的教训是：任务定义要用“推断+字段”的句式，不要用“分析”这种开放动词。推断是收敛的，分析是发散的，动词选错，输出形态就错。类似的开放动词还有“解读”“评估”“判断”，用的时候都要配具体的字段清单，否则模型容易自由发挥。

7.2 置信度只写“高中低”，模型分档全靠感觉

有一版提示词我只写了“请标注置信度（高/中/低）”，没给判定标准。结果模型的分档非常随意，同样的证据强度，有时标高有时标中。后来我把三档标准写死：高=直接强证据且无矛盾，中=间接证据或轻微矛盾，低=弱证据或线索稀疏。分档立刻稳定了。

这件事让我意识到，任何要求模型做分类的地方，分类标准都必须可操作。光给标签名不给判定规则，等于让模型猜你的标准。这个原则在推断场景里尤其重要，因为置信度是推断结果可信度的直接体现，分档一乱，整个输出的可信度就打折了。

7.3 忘了写“禁止推断隐私字段”，输出踩了红线

有一次做用户意图推断，输出里冒出了对用户年龄段的推断，而输入里根本没有年龄相关信息，模型是从昵称风格硬推的。虽然只是模拟数据，但这个问题很典型：模型会拿任何它觉得“相关”的线索去推断，包括你不希望它碰的字段。

修复方法是在证据范围段加禁用清单，明确列出“禁止推断的字段”，比如年龄、性别、地区、收入等与任务无关或敏感的字段。禁用清单要写得具体，不能只写“禁止推断隐私信息”，因为模型对“隐私”的界定可能和你不一致。列出具体字段名，堵漏效果最好。这个坑让我在之后所有推断提示词里都加了禁用清单，成了标配。

7.4 分步推断时忘了传递中间结果

分步推断的第一次尝试，我把两步写在同一个提示词里，以为模型会自动把第一步的结果带到第二步。结果模型在第二步里重新推了一遍证据，和第一步的标注对不上。问题在于我没显式要求“第二步必须基于第一步的输出”。

修复很简单：在第二步的任务描述里明确写“基于上一步输出的证据标注结果进行综合推断，不得重新提取证据”。加了这句之后，两步就咬合上了。分步推断的关键是步骤之间的数据传递要显式声明，不能指望模型自己衔接。这个细节在提示词变长之后特别容易漏，我现在写分步提示词都会专门检查一遍衔接句。

8. 一套可以直接抄的推断提示词模板

8.1 通用模板结构

把前面的东西收拢成一个可复用的模板，结构如下。任务定义段写清推断字段清单；证据范围段分可用证据和禁用证据，并标注证据强度分级；推断规则段写置信度三档标准、冲突处理方式、止损线；输出格式段用三栏分离加建议动作栏；最后附两到三个示例覆盖不同置信度档位。

模板不是拿来即用的，每个场景都要改字段和证据清单。但骨架不变，改起来快。我一般新场景上手先套模板跑一版，看输出哪里不对，再定点改对应段落，比从零写快得多。模板的价值在于把“结构正确”这件事一次性解决，剩下的精力全花在“内容准确”上。

8.2 模板使用时的三个检查点

套模板跑第一版之后，我会重点检查三处。第一处是证据范围段的禁用清单是否覆盖了本场景的敏感字段，这个漏了容易出合规问题。第二处是置信度标准是否和本场景的证据类型匹配，比如行为数据场景的“强证据”定义和文本场景就不一样。第三处是止损线的触发条件是否清晰，跑几个证据不足的样本看模型会不会硬编。

这三处检查完，基本能保证第一版可用。后续优化就靠对抗样本和真实数据反馈来迭代了。推断提示词没有“一劳永逸”的版本，业务数据分布一变，边界就得重调。但有了这套骨架和检查点，每次调整都是有的放矢，不会推倒重来。

8.3 从模板到落地的最后一步

模板跑通之后，最后一步是把它嵌进实际工作流。如果是人工使用，就把输出格式调成方便阅读的样式；如果是程序调用，就把字段名固定成下游能解析的格式，并约定好“信息不足”时的返回值。这一步看着琐碎，但决定了推断结果能不能真正被用起来。

我见过不少推断提示词调得挺好，但输出格式和下游系统对不上，最后还得人工转一道，价值大打折扣。所以我在模板阶段就会问清楚：这个推断结果谁来消费、以什么形式消费。答案不同，输出格式段的写法就不同。人工消费可以宽松点，程序消费就得严格按字段来。这个前置问题想清楚，能省掉后面很多返工。

最后分享一个我在实际使用中的小习惯：每次调完推断提示词，我会把“改了什么、为什么改、改完效果如何”记一行在一个小本子上。推断的边界调整很微妙，隔几天再回来看，很容易忘了当时为什么那么改。记下来之后，下次遇到类似问题能直接翻记录，少走很多重复的弯路。这个习惯比任何模板都值钱，因为它积累的是你自己的场景经验。