电商Prompt设计陷阱

这道题其实问的是，怎么让大模型在电商这种业务里稳定输出，而不是偶尔惊艳偶尔翻车。核心就一句话：用工程手段把不确定性锁住。我主要从三个层面来拆。

先说角色锚定和结构化。很多人觉得给模型一个角色就够了，比如“你是导购”，但真正落地你会发现，角色不锚定场景，模型容易跑偏。比如商品推荐，我会把用户画像、当前库存、价格带都写进 [[System Prompt]]，像“你是资深导购，用户是25-30岁女性，偏好简约，预算300以内”，这样输出才聚焦。然后输入输出必须结构化，输入用JSON包字段，输出强制格式，比如“推荐1: 商品ID | 理由: 一句话”。为什么？因为自然语言输出太飘了，下游系统没法解析，你总不能人肉看吧。

再一个，[[少样本]]示例。光靠指令不够，模型对格式的理解不稳定。我会给两三个完整示例，比如“用户问夏天透气运动鞋，商品A是网面跑鞋，输出推荐商品A | 理由：网面透气”。这能让模型模仿格式，减少乱答。

举个例子，客服退款场景。用户问“我订单超时没退款”，模型不能瞎编政策。我会把知识库检索到的相关政策段注入prompt，比如“退款规则：超时未退自动触发，48小时到账”，然后加拒答策略：“若问题不在知识库，回复‘已转人工’”。这样既准确又安全。少样本示例在这里特别有用，我通常给一个正确回答和一个拒答示例，模型就学会什么时候该说“不知道”。

但这里有个坑：少样本示例不能太多，否则prompt太长，成本高还容易超上下文。一般两三个就够了，而且要选典型场景。

落地风险我重点说两个。一是[[幻觉]]，模型可能推荐下架商品或编造退款金额。所以输出后一定要加规则校验，比如用正则查商品ID是否在库、金额是否合理，不通过就降级到兜底文案。二是成本，电商场景量大，prompt不能太肥。我通常把长商品描述用 [[Embedding]] 检索，只取Top3注入，而不是全量。这样延迟和成本都能接受。

还有个延伸点：当知识库更新频繁时，Few-shot 示例也要跟着变，否则模型用旧示例会误导。我倾向于把示例也做成动态检索，根据当前query取最相关的示例，效果比固定示例好不少。

最后说下边界。有人问为什么不用 [[RAG]] 或微调？我的看法是：RAG适合知识密集但不需要模型理解的任务，比如政策问答；微调适合风格固定、输出格式统一的任务，比如评论摘要。但电商场景复杂，往往是混合的。比如商品推荐，既需要实时库存（RAG），又需要个性化风格（微调），我会先用微调让模型学会推荐逻辑，再注入实时数据做 RAG。说白了，没有银弹，落地时我会优先用prompt工程，成本低迭代快，只有prompt搞不定才考虑微调。