上一篇把提示词写成“背景—任务—约束—输入—输出—验收”契约。本篇继续解决一个现实问题规则已经清楚模型仍不理解企业特有分类或复杂任务容易漏步骤。我们将用少样本示例校准决策边界用“先分解、后作答、只输出可审计摘要”的方式提升多步任务稳定性。一、痛点规则说得清楚边界仍然模糊“退款咨询归售后支付失败归支付”看似明确但“优惠券失效导致实付金额变化客户要求退差价”究竟属于哪类自然语言类别往往依赖隐含惯例。少样本提示不是给模型补知识库而是展示输入到输出的映射、标签边界和所需粒度。一个贴近边界的反例通常比五个容易案例更有价值。另一个常见问题是多步任务。要求模型直接给采购建议它可能跳过币种换算、库存约束或风险检查。传统“请一步一步思考”可能增加计算但冗长推理并不等于正确还可能泄露不该展示的内部信息。工程上更可靠的是规定可验证的中间产物先提取变量再调用确定性计算最后给结论与证据摘要。消费者需要的是可审计依据不是无限展开的自由文本推理。二、原理示例在上下文中定义局部任务少样本学习通过上下文示范模式不会永久更新模型参数。示例应覆盖代表性正常案例、最容易混淆的边界和拒答情形并保持格式完全一致。顺序也会影响结果把与当前输入最相似或最能区分类别的案例放近一些但评测时要固定排序避免把顺序变化误判为模板改进。选择示例时要防止标签泄漏。若输入里出现“这是支付类”模型只是复制答案若每个退款案例都特别长模型可能学到长度而非语义。应删除偶然相关特征并建立留出集。示例数量受上下文成本制约不是越多越好优先增加“能改变决策边界”的样本。下面程序从候选示例中选择同时覆盖标签与困难边界的最小集合再渲染为一致格式。真实系统可用人工标签、向量相似度与多样性重排替换这里的固定分数。fromdataclassesimportdataclassdataclass(frozenTrue)classExample:text:strlabel:strdifficulty:intexamples[Example(付款页面报错未扣款,支付故障,1),Example(已发货商品希望退货,售后退款,1),Example(优惠券失效要求退还差价,优惠争议,3),Example(重复扣款要求原路退回,支付故障,3),Example(询问会员积分何时到账,账户权益,2),Example(商品破损并要求补发,售后退款,3),]defselect(items:list[Example],limit:int)-list[Example]:rankedsorted(items,keylambdax:(-x.difficulty,x.label,x.text))chosen[]coveredset()foriteminranked:ifitem.labelnotincoveredandlen(chosen)limit:chosen.append(item)covered.add(item.label)foriteminranked:ifitemnotinchosenandlen(chosen)limit:chosen.append(item)returnchosen selectedselect(examples,4)forindex,iteminenumerate(selected,1):print(f{index}. [{item.label}]{item.text}difficulty{item.difficulty})print(flabels{len({item.labelforiteminselected})})print(fexamples{len(selected)})运行输出1. [优惠争议] 优惠券失效要求退还差价 difficulty3 2. [售后退款] 商品破损并要求补发 difficulty3 3. [支付故障] 重复扣款要求原路退回 difficulty3 4. [账户权益] 询问会员积分何时到账 difficulty2 labels4 examples4三、实现把推理变成可验证的工作流先写零样本基线并记录错误再决定是否需要示例。若错误来自业务标签含义增加少样本若来自外部事实缺失应该检索资料若来自算术应该调用计算器若来自输出格式优先使用结构约束。不要把所有失败都交给示例解决。多步任务可采用“提取—计算—核验—回答”四段式。模型只负责从文本提取数量、单价和规则程序执行乘法及上限判断模型最后依据计算结果组织语言。提示中要求输出简短依据、关键假设和无法确定项不要求暴露完整隐藏推理。这样既便于审计也降低推理文本被下游误当事实的风险。以下脚本创建四类评测输入覆盖相似正常项、边界项、信息不足和标签外输入。把真实案例脱敏后替换内容即可。fromdataclassesimportdataclassdataclass(frozenTrue)classLabeledCase:text:strexpected:strrules{支付故障:(付款失败,重复扣款),售后退款:(退货,破损),账户权益:(积分,会员),}cases[LabeledCase(付款失败但未扣款,支付故障),LabeledCase(重复扣款并要求退款,支付故障),LabeledCase(我想处理昨天那件事,信息不足),LabeledCase(请帮我写生日祝福,范围外),]defclassify(text:str)-str:forlabel,keywordsinrules.items():ifany(keywordintextforkeywordinkeywords):returnlabelif昨天那件事intext:return信息不足return范围外correct0forindex,caseinenumerate(cases,1):actualclassify(case.text)okactualcase.expected correctint(ok)print(fcase{index}expected{case.expected}actual{actual}ok{ok})print(faccuracy{correct/len(cases):.2f})运行输出case1 expected支付故障 actual支付故障 okTrue case2 expected支付故障 actual支付故障 okTrue case3 expected信息不足 actual信息不足 okTrue case4 expected范围外 actual范围外 okTrue accuracy1.00每次比较零样本、两样本、四样本三个版本记录准确率、拒答正确率、平均输入 token 与延迟。若四样本只提升一个百分点却增加大量成本应考虑检索最相近示例而不是固定塞入全部样本。动态检索还要防止把测试答案或未经审核的用户内容当示例。四、踩坑示例污染与“推理越长越好”第一个坑是示例答案本身错误。模型会忠实模仿错误标签因此示例必须双人复核并带来源。第二个坑是格式漂移示例输出含解释而正式要求只要标签模型会优先模仿示例。第三个坑是类别分布失衡八个支付案例和一个售后案例会暗示先验分布评测结果可能在真实流量上失真。思维链方面不要把一大段看似合理的推导当作证明。语言模型可能先猜结论再生成解释。关键计算交给代码关键事实附证据关键决策列出通过或失败的规则。对简单任务强迫多步推理还会增加时延与错误机会。应在消融实验中比较直接回答与分解工作流只有确有提升才保留。还要分清“自洽采样”和事实校验。多次采样取多数票可缓解某些推理波动但相同知识盲区会让多个答案一致地错外部数据、日期和政策仍须查证。敏感场景不要保存完整中间推理日志只记录必要结构化字段并做脱敏。五、验证用边界案例衡量真实增益验收至少报告整体准确率、各类别召回率、信息不足拒答率和格式通过率。只看总体准确率会掩盖小类别全部失败。为每次误判标注原因标签定义、示例选择、输入歧义、事实缺失或模型不遵循。只有前两类适合通过少样本修复。保留一份从未进入提示的盲测集。若训练案例提升而盲测下降说明示例过拟合。最后做顺序扰动测试交换示例顺序后结论不应大幅变化若变化明显增加更清晰的规则或缩小标签重叠而不是继续堆示例。下一篇将把本篇的一致示例格式推进为机器可消费的 JSON 契约处理字段缺失、类型错误、额外文本和 Schema 校验让模型输出真正接入程序。参考来源Brown 等Language Models are Few-Shot LearnersWei 等Chain-of-Thought Prompting Elicits ReasoningWang 等Self-Consistency Improves Chain of Thought Reasoning 觉得有用就点个赞 收藏方便回头查阅有疑问直接在评论区留言我看到都会回。 本文属于《提示词工程实战》系列持续更新关注不迷路。 文章里的代码都能直接跑。想要可直接 clone 的完整工程 配套部署脚本 / 踩坑清单评论一声或发邮件到cj2664qq.com我免费发你。如果你正好在做类似系统、或有工程化难题想找人做也欢迎邮件聊一句——我按实际情况评估能落地的就接单或出方案。评论和邮件都能直接找到我不用跳别的平台。