业务规则与 Few-shot 示例

为什么业务规则必须细化到可执行？

• 场景: 一个帮用户打电话处理账单的 Agent，可砍价、可申请退款、可取消订阅;
• 计费设计: 三种模式——按省钱提成（如省下金额的 20%）、按服务收固定小费、特别困难任务预收款且不退款;
• 模糊规则的代价: “根据任务情况选择合适的计费类型”会让行为极不稳定;
• 边界歧义一: “帮我退掉上个月买的衣服”既像“帮用户省钱”又像“取回本属于他的钱”，分类不清;
• 边界歧义二: “帮我取消 Netflix 订阅”确实让用户未来不再付费，但算不算“省钱”没有明确定义;
• 后果: 同样的任务在不同时间得到完全不同的分类，业务逻辑不可预测;
• 明确化示例: 提成仅限通过谈判降低现有账单的场景；退款与取消服务绝对不能用提成;

NEVER use percentage_based_one_time for refunds and service cancellations.
Use fixed_fee instead.

• 概率细化: 成功率按固定流程分步评估，估出的概率直接映射计费模式（高于 60% 用可退款模式、低于 30% 直接拒绝任务）;
• 金额细化: 通话按每分钟 $0.05 计费，汇总后四舍五入到最接近的整数美元;
• “节省”的口径: 只基于现有账单计算，否则模型可能把“避免明年涨价”也算成省钱;
• 设计哲学: 大语言模型擅长遵循复杂指令与从长上下文提取信息，但不应在业务规则制定上被赋予过多自由裁量权;

提示词应该由谁设计？

• 分工: 在优秀的 Agent 公司里，提示词一般由产品经理设计，基于线上数据、用户反馈与运营经验迭代规则;
• 工程师角色: 把规则准确编码进提示词，保证格式正确、结构清晰，但不擅自决定业务逻辑;
• 原因: 业务规则细化不是技术问题而是产品设计问题，需要产品经理深度参与;
• 类比: 好的新员工培训不是“你很聪明，自己看着办”，而是提供详细 SOP，让员工在明确框架内发挥;

何时该给模型看 Few-shot 示例？

• 适用条件: 期望输出难以用规则精确描述时——特定风格的文案、结构化报告格式、客服语气分寸;
• 做法: 给出两三个高质量的输入-输出示例，模型凭上下文学习能力“临时学会”这些模式;
• 效果: 往往胜过等量篇幅的抽象规则;
• 反向条件: 对模型本就擅长、规则又容易说清的任务，示例只是浪费 token;
• 放置位置一: 放进系统提示词，成为静态前缀的一部分，对所有请求生效;
• 放置位置二: 伪造一组 user/assistant 消息放在首轮对话中，适合按会话类型选用不同示例集的场景;
• 缓存约束: 无论放在哪里，示例都处于上下文靠前区域，一旦确定就应保持字节级稳定;
• 禁忌: 按请求动态检索“最相关”的示例等于每次改写前缀，缓存会持续失效——生产系统为每类任务准备固定示例集;
• 数量: 两三个精心挑选、覆盖边界情况的示例通常胜过十个大同小异的示例，后者既占上下文又稀释对规则的注意力;

提示工程消融实验得出哪些结论？

• 框架: 基于 Tau-Bench，模拟航空公司客服与零售客户支持两个场景，覆盖航班改签、退款、库存查询等多步任务;
• 方法: 控制变量法——设定基线（结构化提示词、完整工具描述、专业中立语气），逐维度修改;
• 维度一（语气与风格）: 三种风格差异显著，但对任务完成率影响相对有限;
• 维度二（信息组织）: 保留全部规则但打乱结构、去除层次后，任务成功率下降超过 30%;
• 维度三（工具描述）: 保留函数签名与参数定义、移除所有描述性文本后，工具调用错误率增加 45%;
• 总结: 对人类友好的信息组织方式，对模型同样友好;