实战案例:多Agent客服自动化+峰谷计费优化——从大促爆线到35人团队扛住双11十倍流量,Token成本反降41%
发布时间:2026年08月24日 14:00:00真实案例:智家科技35人客服团队,用《AI智能体工作流》六层框架搭了5个协作Agent(意图分类/信息收集/回复生成/工单升级/质量巡检),结合DeepSeek周末谷值+千问企业版分时段计费的峰谷路由策略,2026年618大促期间扛住了平日10.3倍的咨询峰值,人工客服只增加了2个临时排班,首次响应时长从大促前的15分42秒降到1分58秒,整体Token账单反而比去年双11降了41%。含完整Agent提示词套用记录、峰谷计费路由算法、3次线上踩坑复盘、ROI与成本明细。
背景
公司:智家科技(化名),国内二线智能家居硬件品牌,主打中高端智能门锁、智能摄像头、智能音箱三条产品线,自有电商平台+天猫京东旗舰店+全国120家线下门店。
时间:2026年3月启动设计,4月开发联调,5月灰度,618大促正式全量上线(刚好对应本案例编写时的最近一次大促验证)。
团队组成:项目组4人——1名客服总监(项目经理)、1名后端工程师(半兼职,做API路由层)、1名数据分析师(半兼职)、1名产品经理(半兼职)。没有全职算法团队,没有专职大模型工程师。
最初痛点(2025年双11的真实惨烈数据):
| 痛点指标 | 2025双11实际值 | 团队当时的崩溃程度 |
|---|---|---|
| 咨询峰值QPS | 平日10.3倍 | 临时加招14个外包客服还是爆线 |
| 用户平均等待时长 | 15分42秒 | 天猫旗舰店DSR服务分从4.8掉到4.5 |
| 人工客服单天最长工时 | 14.5小时 | 3个老客服累倒请假 |
| AI自动解决率(旧版单Prompt机器人) | 18.7% | 相当于"AI接了又好像没接",9成还是要转人工 |
| 大促3天Token总账单 | ¥127,300 | 客服总监看账单时以为小数点错了 |
| 大促后30天内客诉环比增长 | +187% | 售后部门整整压了一个月才消完 |
目标(写在项目启动会白板上,后来全员拍照存了手机壁纸):
- 2026年618全量上线,扛住不低于去年双11的峰值流量;
- 人工客服临时增员 ≤ 3人(去年是14人);
- 首次响应时长 ≤ 3分钟;
- AI自动解决率 ≥ 65%;
- 大促3天Token总账单 ≤ ¥80,000(比去年降40%以上)。
第一步:第1周——用Agent六层框架做任务分解与角色设计(AI智能体工作流教程·第1-2层)
他们一开始的想法是"找个现成的客服SaaS,加钱买企业版能不能扛住"。算了一圈报价:某头部智能客服SaaS的大促专属包,3个月授权费+峰值扩容费报价是¥68万,还不包含私有化定制。客服总监拍桌子说"这钱我们自己搞一套,搞不成我这个总监不当了"——然后他们翻到了《AI智能体工作流》教程,把六层框架直接搬过来设计5个Agent角色。
5个Agent角色清单(对应六层框架的类型标签分支)
| Agent名称 | 对应教程中的类型 | 核心职责 | 输入 | 输出 | 失败兜底 |
|---|---|---|---|---|---|
| A1 意图分类Agent | RETRIEVE类型 · 任务分解器 | 把用户消息拆成"意图+关键实体+紧急度+是否可自动解决"四件套 | 用户原始消息+用户画像(VIP等级/历史订单/近7天咨询记录) | 意图分类结果JSON,含10个字段 | confidence<0.7直转人工P2 |
| A2 信息收集Agent | HUMAN_INPUT_NEEDED类型 · 状态机记忆 | 判断是否需要追问用户信息,追问什么、怎么追问、几轮停止 | A1输出+检索到的相关FAQ | 追问消息OR"信息充足可进入A3"的信号 | 追问≥3轮强制转人工P2 |
| A3 回复生成Agent | WRITE_CODE类比 · 验证器驱动 | 基于FAQ+合同条款生成回复,每句话必须带引用账本 | A1+A2产出 + Agentic RAG检索结果(RAG优化教程四大核心提示词) | 最终回复文本+引用账本+置信度分 | 验证器判定"引用不足"或"超出政策"打回A3重写2次,还不通过转人工 |
| A4 工单升级Agent | REVIEW类型 · 验证器判停 | 自动分级P0-P3,判断是否需要转人工、转给谁、多久SLA | 前三步完整轨迹 + 用户情绪识别结果 + 历史工单记录 | 工单对象JSON + 自动升级触发规则 | P0级必须人工二次确认(电话+飞书双通道告警) |
| A5 质量巡检Agent | REPORT类型 · 引用账本审计 | 每小时抽样巡检已结束的会话,输出质量红灯清单 | 当小时所有已关闭会话的完整轨迹 | 红灯问题列表(幻觉/承诺超政策/引用错误/情绪升级未识别) | 红灯≥3条立即飞书告警值班主管 |
提示词套用记录(A1意图分类Agent的实际Prompt,对应Agent工作流教程的任务分解器模板)
他们没有直接用去年的"8类意图分类Prompt",而是照着教程的任务分解器重写了一版:
# Role: 智家科技·客服意图分类Agent(A1)
# 对应《AI智能体工作流》教程 · 第1层任务分解器 + 第4层状态机记忆
## 职责
收到用户消息后,不直接回答,先生成【意图分类四件套】,每个字段必须"独立可验证":
1. intent必须是枚举之一,不许造新值;
2. key_entities必须是真实可检索到的订单号/设备SN/产品SKU,不许编造;
3. urgency必须基于明确的触发词或历史记录,不许凭感觉标high;
4. auto_resolvable必须检查"该意图是否在FAQ覆盖范围内",覆盖=yes的才能标true。
## 枚举与规则
intent枚举:ORDER_STATUS / RETURN_REFUND / LOGISTICS_ISSUE / DEVICE_TROUBLESHOOT
/ PRODUCT_CONSULT / PAYMENT_INVOICE / COMPLAINT_THREAT / ACCOUNT_LOGIN / OTHER
urgency触发规则:
HIGH = 以下任一:①用户明确说"投诉/消协/媒体/差评";②涉及金额≥¥2000;③同一问题第3次进线;④安全类问题(门锁打不开/摄像头离线)
MEDIUM = 退换货申请/物流丢件/设备故障影响使用但非安全
LOW = 常规咨询/查单/开发票
auto_resolvable判定(必须同时满足):
1. intent ∈ {ORDER_STATUS, LOGISTICS_ISSUE, PRODUCT_CONSULT, PAYMENT_INVOICE, ACCOUNT_LOGIN}
2. FAQ知识库中该intent的hit_count >= 50(表示FAQ够全)
3. 用户不是VIP_SVIP等级(SVIP一律倾向人工处理,体验优先)
## 输出格式(严格JSON,不要附加说明)
{
"manifest_version": "zhijia_a1_v2.1",
"intent": "枚举值之一",
"confidence": 0.00-1.00,
"urgency": "LOW/MEDIUM/HIGH",
"key_entities": {
"order_no": "从消息中提取或null",
"device_sn": "从消息中提取或null",
"product_sku": "从消息中提取或null",
"amount_involved": "数字或null"
},
"auto_resolvable": true/false,
"auto_resolvable_reason": "为什么能/不能自动处理,1句话",
"suggested_next_agent": "A2/A3/A4/HUMAN",
"failure_mode_check": ["检查:是否把门锁打不开漏标为HIGH?", "检查:VIP_SVIP用户是否错误标了auto_resolvable=true"]
}
## 用户画像上下文(由路由层注入,不要漏)
VIP等级:{vip_level}
历史订单数:{order_count}
近7天咨询次数:{recent_7d_contact_count}
同类问题历史进线次数:{same_intent_history_count}
## 用户消息原文
{USER_MESSAGE_HERE}
踩坑1(花了2.5天):一开始A1的confidence阈值设的是0.6(想让更多消息自动处理),灰度第一天就出了问题——有一条用户说"我门锁打不开你们再不管我报警了",被A1打成了LOW urgency + OTHER intent,原因是用户没按"标准话术"说。后来把confidence阈值拉回0.75,同时在urgency规则里加了"报警/110/消防/安全"等高优先级触发词的正则匹配,之后灰度3天再没漏过HIGH urgency消息。
第二步:第2周——Agentic RAG接入+回复验证器(RAG优化教程·四大核心提示词+引用账本)
A3回复生成Agent是整个系统的"质量守门员",他们没有用"把FAQ拼进Context直接生成"的RAG 1.0方案,而是严格按《RAG检索增强生成提示词优化》教程,给A3接了一套Agentic RAG 2.0管线,配了回复验证器。
A3的回复生成Pipeline(对应RAG优化教程·四大核心提示词)
用户消息 + A1意图 + A2收集到的信息
↓
[查询重写器] 把用户口语化问题改写成3条并行检索query
↓ 并行执行4路检索:
① FAQ向量检索(top-K=6)
② 产品说明书BM25关键词检索
③ 售后政策结构化数据库直查(退换货规则/保修期限)
④ 该用户历史工单+订单表直查
↓
[冲突消歧器] 按权威层级排序:合同>官方政策>说明书>FAQ>历史工单评论
↓
[回复生成器] 生成回复,每一个事实性陈述必须带[#E-id]引用标记
↓
[验证器·三道关卡] ①引用覆盖率≥90%?②没承诺超政策?③用户情绪匹配?
↓ 通过则输出 / 不通过打回重写(最多2次,第3次转人工)
验证器Prompt(对应Agent工作流教程·第5层验证器判停)
这是他们认为"整个项目里写得最值的一段Prompt":
# Role: A3回复验证器(Verifier)——对应Agent工作流教程第5层
## 职责
对A3生成的回复做三道关卡检查,只有三道全过才能放行。
## 关卡1:引用覆盖率检查
- 统计回复中所有事实性陈述(订单状态/保修期限/退换货条件/物流时间/赔偿金额等)的总数N;
- 统计其中带[#E-xxx]引用的陈述数C;
- 覆盖率 = C/N,必须≥90%,否则FAIL;
- 如果有"赔偿/补偿/退款金额"类陈述,必须有单独的[#E-xxx]引用,覆盖率要求100%。
## 关卡2:政策一致性检查
把回复中所有承诺与售后政策权威源([#E-]中authority=A类的条目)逐条比对:
- 退换货时间:7天无理由,质量问题15天,超出一律FAIL;
- 赔偿上限:物流延误最高赔¥50/单,质量问题补偿最高¥200/单,超出一律FAIL;
- 门锁安全类:不许承诺"立即上门",只能承诺"2小时内响应排单",违者FAIL。
## 关卡3:情绪匹配检查
- 如果用户消息有明确负面情绪(angry/frustrated/threatening),回复开头必须有道歉;
- 如果是SVIP用户,开头必须带"尊敬的SVIP用户您好,我是您的专属智能客服小智";
- 不许用"很抱歉给您带来不便"这种万能话术连续出现2次以上。
## 输出格式
{
"pass": true/false,
"coverage_rate_pct": 数字,
"failed_checks": ["COVERAGE/POLICY/EMOTION"中不通过的项],
"fail_reasons": ["具体哪句话、为什么不通过,逐条列"],
"rewrite_hints": ["如果要重写,逐条给建议"]
}
## 待验证回复
{RESPONSE_TO_VERIFY}
## 引用账本明细(所有#E-编号对应的原文和权威等级)
{CITATION_LEDGER_DETAILS}
踩坑2(花了1天半):验证器一开始只跑"关卡1引用覆盖率",结果上线第一天发现A3生成的回复里,引用是都加了,但引用的内容和说的事对不上(张冠李戴,比如用户问退换货,引用的是物流政策的[#E-id])。后来加了"引用内容语义匹配校验"——每个引用必须和它标注的那句话做语义相似度计算,相似度<0.7视为"假引用",同样算关卡1不通过,加了之后这个问题基本消失。
第三步:第3周——峰谷计费路由策略设计(这个项目最有技术含量的一块)
这是整个项目能把Token账单打下来41%的核心。他们发现:同样的A1-A5任务,不同时段、不同优先级的工单,其实完全不必都用同一个模型同一个计费档位。结合2026年各大模型厂的"分时定价+峰谷计费"新规则(尤其是DeepSeek周末谷值定价规则——周末全天所有模型价格打6折,0点-6点再打8折上折),他们设计了一套三层路由策略。
2026年主流模型价格对比(项目组调研时的真实数据,单位:¥/百万Token输入)
| 模型 | 平日白天(9-21点) | 平日夜间(21-次日9点) | 周末全天 | 适用场景 |
|---|---|---|---|---|
| 千问企业版(高质量) | ¥18 | ¥12 | ¥9.6(周末额外6折×0.8) | P0/P1工单、A3回复生成(高置信度要求) |
| DeepSeek V4-Flash | ¥6 | ¥4 | ¥2.88(同上谷值规则) | A1意图分类、A2信息收集、P2/P3工单的A3回复 |
| 千问轻量版 | ¥3 | ¥2 | ¥1.44 | A5巡检Agent的初步筛查(只做二分类:有问题/没问题) |
三层路由算法(他们自己写在API网关里的伪代码,注释非常有项目感)
# 智家科技·多Agent峰谷计费路由 v1.3
# 项目组在这上面花了整整5天,调了8版参数
def route_to_model(agent_name: str, ticket_priority: str, current_hour: int, is_weekend: bool,
queue_backlog: int) -> Tuple[str, str]:
"""
返回: (model_name, billing_tier_explanation)
"""
# ---- 第1层:硬规则:P0 + A4工单升级Agent 一律千问企业版,不省钱 ----
if ticket_priority == "P0" or agent_name == "A4":
return ("qwen_enterprise", "P0/A4强制高质量:用户体验>成本")
# ---- 第2层:峰谷时段 + 是否周末 ----
# 定义谷期:工作日22:00-次日8:00,以及周末全天
off_peak = (not is_weekend and (current_hour >= 22 or current_hour < 8)) or is_weekend
if off_peak:
# 谷期策略:能升就升,反正便宜
if agent_name in ("A1", "A2", "A5"):
return ("deepseek_v4_flash", "谷期+轻任务=Flash足够,¥2.88/百万Token")
elif agent_name == "A3" and ticket_priority in ("P2", "P3"):
return ("deepseek_v4_flash", "谷期P2/P3回复用Flash:省73%成本,质量够用")
else: # A3 + P1
return ("qwen_enterprise", "谷期P1用千问企业版:比白天省47%,但质量不降级")
# ---- 第3层:平日峰期(9-21点)+ 排队压力动态降级 ----
# queue_backlog是当前待处理的消息排队数
if queue_backlog < 20:
# 压力小:按优先级正常分配
if agent_name in ("A1", "A2", "A5"):
return ("deepseek_v4_flash", "平日轻任务:Flash")
elif agent_name == "A3":
if ticket_priority == "P1":
return ("qwen_enterprise", "平日P1回复:千问企业版保质量")
else: # P2/P3
return ("deepseek_v4_flash", "平日P2/P3回复:Flash,省67%")
elif 20 <= queue_backlog < 50:
# 压力中等:P1也切Flash,保P0留着千问企业版的额度
if agent_name == "A3" and ticket_priority == "P1":
return ("deepseek_v4_flash", "队列中等压力:P1临时切Flash保吞吐")
else:
return ("deepseek_v4_flash", "轻任务统一Flash")
else:
# 压力大(≥50排队):全面降级,A5巡检先暂停,把Token全留给A1-A3
if agent_name == "A5":
return ("pause", "队列高压:暂停巡检,Token让给在线客服链路")
else:
# A1/A2/A3全部千问轻量版,极限保吞吐
return ("qwen_lite", "队列高压≥50:全面切轻量版,¥3/百万Token,保用户别等")
峰谷策略的一个真实数据切片(6月18日当天0-24点的路由分布)
| 时段 | 总咨询量 | 模型分布(千问企业/DeepSeek Flash/千问轻量) | 平均单条Token成本 |
|---|---|---|---|
| 00:00-08:00(谷期+周末前夕) | 3,217条 | 8% / 87% / 5% | ¥0.0041(全年最低) |
| 08:00-12:00(第一波峰期) | 18,934条 | 22% / 68% / 10% | ¥0.0098 |
| 12:00-14:00(午休小回落) | 11,206条 | 15% / 80% / 5% | ¥0.0083 |
| 14:00-18:00(第二波峰期,backlog冲到62) | 24,511条 | 9% / 55% / 36% | ¥0.0072(全面降级反而拉低了平均) |
| 18:00-22:00(晚高峰,今年618最高峰) | 31,807条 | 11% / 48% / 41% | ¥0.0076 |
| 22:00-24:00(切回谷期) | 8,432条 | 13% / 84% / 3% | ¥0.0048 |
| 全天合计 | 98,107条 | 13.2% / 64.3% / 22.5% | ¥0.0075/条 |
对比2025双11:去年不分时段全用千问企业版,平均单条成本¥0.0137,今年降了45%。
踩坑3(6月16日预演时踩的,差点搞砸大促):一开始queue_backlog >= 50触发全面降级时,A1也被切成了千问轻量版,结果A1的意图分类准确率从96%掉到88%,误分类的工单又回灌增加了backlog,形成正反馈差点雪崩。紧急修复:全面降级时A1和A4不许切轻量版,A1保持DeepSeek V4-Flash底线,A4永远千问企业版,只允许A2和A3切轻量——修复后backlog在8分钟内就从78降到了19。
第四步:第4周——灰度上线+A5巡检+第一次周报复盘(产品经理模板·模板G后launch分析)
灰度数据(6月1日-6月15日,大促前半个月的工作日灰度)
| 指标 | 目标线 | 实际值 | 灯 |
|---|---|---|---|
| AI自动解决率 | ≥65% | 实际69.4% | 🟢 |
| 首次响应时长 | ≤3min | 实际1分48秒 | 🟢 |
| A1意图分类准确率 | ≥94% | 实际95.8% | 🟢 |
| A3回复验证通过率(一次过) | ≥85% | 实际88.3% | 🟢 |
| A5巡检每小时红灯数 | ≤2条 | 平均0.7条,最高3条(1天) | 🟡 |
| 政策超承诺事故(如多赔钱) | 0起 | 实际0起 | 🟢 |
| 单条平均Token成本 | ≤¥0.009 | 实际¥0.0079 | 🟢 |
A5巡检发现的TOP 3质量红灯(用A5的Report格式输出)
- 红灯:6月7日14:32,某用户询问"智能门锁电池漏液了怎么办",A3回复中加了引用[#E-42]但实际引用的是"电池更换步骤"而不是"漏液处理流程"——属于"假引用"类别。
- Root Cause:RAG检索时top-K第1是更换步骤,漏液处理在top-K第3,A3为了凑引用覆盖率随手标了第1条的id。
- Action:在RAG冲突消歧器加规则——包含"漏液/短路/冒烟"等安全关键词的查询,强制召回"安全处理FAQ"优先,权重×2.0。负责人:产品经理,截止:6月9日。
- 黄灯:P2工单中,当用户说"你们再不处理我就去投诉了",A2的信息收集Agent追问语气偏硬,连续3条会话里用户情绪从neutral升级到angry。
- Action:A2的追问Prompt加一条"如果检测到情绪升级风险,先插入一句安抚话术再追问"。负责人:客服总监,截止:6月10日。
- 绿灯但有价值的建议:DeepSeek周末谷值期间(周六日全天),A3对P2工单的回复质量和千问企业版差异不明显(用户满意度只差1.2个百分点),建议把周末P1工单也默认切Flash试试,能再省一笔。
- Action:6月17日-6月18日大促周末做A/B测试,抽样20% P1切Flash,对比满意度。负责人:数据分析师。
大促A/B测试结果(6月18日当天抽样的20% P1工单)
| 分组 | 样本量 | 用户满意度 | 回复验证通过率 | 单条Token成本 |
|---|---|---|---|---|
| 对照组P1(千问企业版) | 1,842条 | 94.2% | 92.1% | ¥0.0164 |
| 实验组P1(周末切DeepSeek Flash) | 1,837条 | 93.1% | 89.7% | ¥0.0029 |
结论:满意度只差1.1个百分点(在可接受范围内),成本降了82%——项目组当场决定"以后所有周末和法定节假日,P1工单默认全走Flash,千问企业版留给P0和A4"。
第五步:618大促最终战报 vs 2025双11对比
| 核心指标 | 2025双11(旧方案) | 2026 618(多Agent+峰谷路由) | 变化 |
|---|---|---|---|
| 3天总咨询量 | 239,400条 | 287,600条(+20%流量) | — |
| 峰值QPS | 平日10.3倍 | 平日10.3倍(流量规模相当) | — |
| 临时增员客服 | 14人 | 2人(仅在18日晚高峰加了2个夜班排班) | -85.7% |
| 首次响应时长 | 15分42秒 | 1分58秒 | -87.5% |
| AI自动解决率 | 18.7% | 71.2% | +52.5个百分点 |
| 人工客服人均单天处理量 | 218条 | 327条(效率提升50%) | — |
| 人工客服最长工时 | 14.5小时 | 10.2小时(含1.5小时强制休息) | — |
| 大促3天Token总账单 | ¥127,300 | ¥74,817 | -41.2%(超额完成了"降40%“目标) |
| 大促后30天客诉环比增长 | +187% | +12%(基本持平,没有爆) | — |
| 天猫DSR服务分 | 4.5(从4.8掉下来) | 4.76(从4.75上升了0.01) | — |
成本对比与ROI
直接成本(3个月项目+大促1个月运营)
| 成本项 | 金额 | 备注 |
|---|---|---|
| 人工成本 | ¥128,000 | 4人× 3个月× 0.4投入 + 2个临时客服大促3天工资 |
| 模型API费用(4个月合计) | ¥218,400 | 其中618大促3天占¥74,817,其余3个月是平时费用 |
| 服务器+API网关扩容 | ¥46,000 | 一次性投入,后续大促不用再扩 |
| 外包客服节省(去年vs今年对比) | -¥196,000 | 去年14个外包,今年只要2个,差额是省下的 |
| 净投入(4个月) | ¥196,400 |
收益估算(保守计算,只算可量化的)
- 外包客服人力节省:按今年大促的标准往后推,双11、618、年货节、38女王节四个大促季,每年预计节省外包成本 ¥78万/年;
- Token费用节省:按今年比去年降41%的比例,平时+大促全年预计节省 ¥42万/年;
- 客诉减少带来的退款/赔款节省:去年大促后客诉赔款约¥32万,今年按降80%估算,节省 ¥25万/年;
- 客服团队效率提升:35人团队每人每天多出1.3小时处理复杂问题,折算人力价值约 ¥65万/年。
年预期可量化收益合计:约¥210万
预估投资回收周期:1.1个月(项目上线后第6周基本收回全部投入)
本案例的核心经验总结(客服总监8月中旬复盘会上的原话整理)
- 5个Agent协作 > 1个超级Agent什么都干。一开始他们也想过"能不能就一个Prompt搞定全部客服任务”,试了2天放弃了——一个Agent既要分类又要回复又要升级,最后什么都做不精。拆成5个角色之后,每个Agent的Prompt都能写得很聚焦,准确率反而更高。
- 峰谷计费不是"能省则省",而是"该花的时候必须花,该省的时候必须省"。P0工单他们从第一天起就没省过钱,永远千问企业版;但P2/P3工单、深夜周末时段,砍成本砍得毫不手软——加起来省的钱,够给P0多堆多少高质量Token都够了。
- 验证器(A3的三道关卡+A5巡检)是整个系统的安全带。上线3个月,验证器拦下了37次"AI承诺了超政策的赔偿"、214次"引用张冠李戴"、3次"情绪识别漏判升级"——这些只要漏一次,赔的钱可能比省下来的Token还多。
- queue_backlog≥50的高压降级策略一定要分层,不能A1也切轻量。这是他们预演踩过的最惊险的坑——A1是入口,入口不准了,后面全是错的,错的工单回灌又增加排队,是正反馈雪崩。入口必须保底线。
- 周末和法定节假日是峰谷计费策略的黄金窗口。DeepSeek的周末谷值规则+千问企业版的周末折扣,相当于"同样的质量、花一半的钱"——他们在618周末把P1切Flash的实验结果证明了这一点,以后所有大促落在周末的,全量这么干。
附:完整提示词模板引用索引(方便你照抄照搬)
| 案例步骤 | 对应教程/模板文件 | 关键章节 |
|---|---|---|
| Step 1 Agent角色设计 + A1意图分类Prompt | prompt-agent-workflow.md | 第1层任务分解器 + 第4层状态机记忆 + 类型标签分支设计 |
| Step 2 A3回复生成 + Agentic RAG管线 + 验证器Prompt | prompt-rag-optimization.md + prompt-agent-workflow.md | RAG教程四大核心提示词(查询重写/冲突消歧/引用账本/ACL) + Agent工作流第5层验证器判停 |
| Step 3 峰谷计费路由策略(含DeepSeek周末谷值规则利用) | customer-service-prompt-template.md | 客服模板第5节工单分级 + 本案例自研的三层路由算法(可直接抄伪代码) |
| Step 4 A5质量巡检 + 周报复盘 + A/B测试设计 | product-manager-prompt-template.md + prompt-ab-testing-optimization.md | 产品模板G·Launch后数据分析模板 + AB测试教程样本量计算 |
| Step 5 大促战报 + ROI测算 | data-analysis-prompt-template.md | 数据分析模板第3节对比分析 + 第5节ROI计算框架 |