Prompt 版本日志
版本管理原则
系统 Prompt 是运营资产，按版本管理。每个版本保留 version 编号、name 描述、完整 content 内容、change_log 变更说明、status（draft / active / archived）、metrics_json（resolution_rate / avg_score / sample_size）。商家在 /admin/prompts 后台可对比版本 diff、查看指标、一键激活、新建版本。
激活操作在数据库 transaction 内完成：先把所有版本归档，再把目标版本设为 active，最后更新 merchants.active_prompt_id。激活后只对新会话生效，不影响进行中的会话。
v1.0 — 身份设定版
核心内容：「你是源家捞汁小海鲜的 AI 客服小源，语气友好，回答客户问题。」
能解决：基础营业时间、招牌菜推荐、普通 FAQ。
问题：
- 模型凭常识补充不存在的信息
- 回答缺少知识库引用
- 遇到退款和投诉时继续解释而不是转人工
- 遇到订单状态时回复「请耐心等待」而不调用工具
典型失败场景：
| 客户输入 | v1.0 回复 | 实际应该 |
|---|---|---|
| 「订单 MT-20260503-001 到哪了」 | 「骑手正在配送，请耐心等待」 | 调用订单查询工具，给出 ETA 与骑手信息 |
| 「虾不新鲜我要退款」 | 「可以为您办理退款」 | 共情 + 收集信息 + 转人工，不承诺金额 |
基线指标：解决率约 45%，主要解决 FAQ 类问题，售后和订单类表现不稳定。
v1.5 — 知识引用与基础转人工版
主要变更：
- 要求回答优先使用知识库内容，能引用时展示来源
- 增加 3 条基础转人工规则：客户主动要求人工、退款投诉、AI 不确定
改善效果：
- FAQ 回答更稳定，客户能看到答案来源
- 售后风险有所降低
- 模型开始知道「订单状态要查工具」「退款不要直接承诺」
遗留问题：
- 情绪识别粒度不够，客户强烈不满时仍继续解释规则
- 健康风险没有单独提升优先级，过敏问题被当成普通食材咨询
经验：Prompt 不是孤立文本，它和知识库结构耦合。知识库条目标题清楚、同义词充分时，「优先引用知识库」才有效；否则模型即使被要求引用也找不到合适内容。
基线指标：解决率约 62%，主要提升来自 FAQ 准确率和订单类工具意识。
v2.0 — 情绪、风险与输出边界版（当前 active）
主要变更：
- 加入三档情绪识别（中性 / 不满 / 愤怒）
- 转人工规则扩展到 7 条（详见
/docs/04-handoff/01-rules） - 工具调用条件细化：订单类必须调工具或追问订单号
- 禁止承诺清单：退款金额、医疗建议、过敏安全保证
- 输出格式要求：单段不超过 80 字、必要时用列表、适度 emoji
关键规则：
- 食品安全和海鲜过敏优先级最高
- 退款金额、赔付、医疗建议不能由 AI 承诺
- 客户主动找人工必须立即转
- 同类重复追问要降低置信度
- 订单状态必须调用工具或追问订单号
典型成功场景：
| 客户输入 | v2.0 回复 |
|---|---|
| 「海鲜过敏的小孩能吃吗」 | 不推荐「少量尝试」，明确建议过敏人群不下单，并转人工确认 |
| 「送错餐我要投诉」 | 先道歉确认问题，创建工单并提示人工跟进，不承诺赔付 |
基线指标：解决率约 72%，质检合规性和解决度明显改善。更重要的是，解决率更可信——高风险问题不再被错误计入自动解决。
评估方法
Prompt 迭代不能只看主观感觉。系统用四类指标评估：
| 指标 | 用途 |
|---|---|
| 有效 AI 解决率 | 看自动处理效果 |
| 转人工准确性 | 看风险边界 |
| LLM 质检五维分 | 看回答质量 |
| 重复追问率 | 看客户是否真的获得答案 |
辅助指标包括成本和延迟，避免为了更复杂 Prompt 牺牲体验。
样本设计要覆盖营业时间、招牌菜、订单查询、漏餐、错餐、退款、过敏、找人工、骚扰和多意图等场景。只覆盖简单 FAQ 的测试集说服力不够。
副作用与回滚
Prompt 加规则会带来副作用：
- 规则太多 → 回答可能变长，体验下降
- 转人工条件太宽 → 自动解决率下降
- 情绪识别太敏感 → 普通抱怨被升级
- 禁止承诺写得过保守 → AI 连简单补充说明都不敢说
v2.0 后的优化方向不是无限加规则，而是把规则与工具、知识库、质检数据结合，持续缩小模糊地带。
具体副作用案例：加入「退款不要承诺」后，模型在普通退单咨询里回答过于谨慎。解决方法不是删除规则，而是在 Prompt 中区分「解释平台退款流程」（可自动）和「承诺具体赔付」（必须人工确认）。
回滚机制：Prompt 版本不直接全量切换。商家先用 Demo 或少量会话测试 draft 版本，再切换 active；每个版本保留 change_log 和 metrics_json，方便回滚。新版本导致转人工过多或回答变长时，可回到上一版，同时保留失败样本继续分析。
面试展示口径
这个日志的重点不是证明「写了一段更长的 Prompt」，而是展示产品如何把客服经验沉淀成可审计的运营策略。v1.0 代表最常见的起点：只给身份和语气，能回答简单 FAQ，但会在订单、赔付、健康风险上暴露边界问题。v1.5 说明知识库和转人工规则开始介入，系统从纯聊天变成受控客服。v2.0 则把情绪、工具、禁止承诺和输出格式放进同一套策略里，让解决率提升的同时不牺牲安全边界。
演示后台时，可以沿着「失败样本 → Prompt 改动 → 指标变化 → 可回滚」这条线讲。比如订单查询失败不是单纯要求模型更聪明，而是明确「订单类必须调工具或追问订单号」；过敏问题不是靠模型自由发挥，而是提升到最高优先级并强制转人工。这样的版本日志能回答面试中常见的追问：为什么不是一次写好 Prompt、如何判断改动有效、如果新版本变差怎么恢复。
后续规划
- 质检低分自动归因：低分会话自动归因到知识缺失、语气问题、规则漏写或工具失败；系统生成候选 Prompt 改动，人工确认后激活。
- 意图分子 Prompt：FAQ、订单、售后、骚扰分别使用不同 Prompt 模板，减少单个系统 Prompt 过长。
- 策略配置化：长期看，Prompt 应从静态文本升级为策略配置（条件 + 行动），但当前阶段保留可读文本更便于商家维护。