---
title: 11-sanitaryware-ai-ordering-platform
description: 文本抽取：AI研讨会/11-sanitaryware-ai-ordering-platform
updated: 2026-11-04
tags: [原始文档, 抽取, AI研讨会]
source: AI研讨会/11-sanitaryware-ai-ordering-platform
source_type: txt
source_hash: 572ad673b7c9
extracted_at: 2026-11-04
quality: ok
---

---
source: AI研讨会/11-sanitaryware-ai-ordering-platform.html
type: html
size_kb: 259
category: AI研讨会
quality: ok
---

知名卫浴品牌业务系统 AI 智能层建设方案｜商派 ShopeX 项目提案
ShopeXAI
00 需求还原
01 总框架
02 老系统不换
03 订货会流程
04 数据关联
05 运行机制
06 业务目标
07 十例剖析
08 配合清单
导出 PDF
商派 ShopeX × 知名卫浴品牌 · 项目提案
知名卫浴品牌业务系统
AI 智能层建设方案
八套老系统一套不换，在上面长出智能化、AI 化、Agent 化的能力——问数、预警、报表不再依赖大量二次开发；一期落点 12 月全国订货会，以订货链路为第一块试验田
00 / 需求还原
知名卫浴品牌的需求分两层：给老系统建一个 AI 智能层，一期落在订货会
八套老系统一行代码不改，在它们之上加一层 AI 智能层：问数、预警、报表、技能这些过去只能靠大量二次开发才能补齐的能力，现在由这层直接长出来——让现有系统智能化、AI 化、Agent 化。客户原话："想做一个 AI 订单的平台，所有 AI 都在这个平台上，可以问问题、有一些技能，还能推送、预警。" —— 知名卫浴品牌领导层 · 需求沟通会
为什么会有这个需求 · 四条现实压力
压力 01 · 人力
微信人肉答疑，扛不住
订单部靠人工在微信端回 5 渠道 × 5 角色的日常查询，同一问题几十种问法、口径不一。问答类占 90 项的三成，是人工最重的活。
压力 02 · 架构
八套系统各管一段，中间没有桥
订单散在 B2B、订货宝/K3、乐渠、OMS、C2F，财务在 SAP。跨系统问数、预警、报表过去只能靠大量二开补，又贵又慢。
压力 03 · 管理
要管住渠道，不只服务渠道
推送预警里一半是催办与考核：超期未提、达成缺口、订单经理考评与一票否决——客户要的是能压着渠道按规则动作的工具。
压力 04 · 节点
12 月订货会，第一块试验田
咨询量翻几倍、主战场在经销商手机端。会前解读、会中查单、会后预警——这是客户点名的第一个落地场景，也是智能层必须赶上的硬节点。
智能层的能力全景 · 90 项需求收成四类模块
能力 01 · 答（问答 27 项）
24 小时替人答疑
政策、返利、交期、账户对账进知识库统一作答——同一问题同一答案，答不了转人工，不硬编。
能力 02 · 查 / 析（报告 19 项）
一句话查全链路、自动出报告
MCP 直连八套系统实时取数，一个订单从下单到履约一次问清；报告按统一口径自动生成，不再人肉拼系统。
能力 03 · 推（推送提醒 16 项）
出事之前先预警
超期未提、预定金不足、达成缺口、账户余额——阈值触发、主动送达企微 / 短信 / 挂件，从"事后发现"变"事前预警"。
能力 04 · 做（技能 28 项）
把老员工手上的活自动化
交期分配、预定金冻结解冻、对账审核等——规则先落纸再执行，高风险动作过确认门、全程留审计回执。
需求底稿：《知名卫浴品牌订单 AI 需求调研汇总》90 项条目 · 《AI 订单助理需求说明》PPT 8 页 · 8/21—9/4 四轮沟通与企微记录 · 覆盖 3 大场景 / 4 种交互形态 / 5 渠道 × 5 角色
01 / 总体框架
商派独创的双智能体 AI 外骨骼体系，
帮助品牌企业的业务系统逐步具备 AI 能力
1.1 总体结构 · 商派 AI 外骨骼架构
商派把"老系统不动、AI 加在外面"这种做法称为 AI 外骨骼架构：老系统是骨骼，一套不换；AI 是穿在骨骼外面的那层，力量由它提供，动作还是原来那套。两只手臂各管一段——嵌入式智能体嵌入系统内部，相当于系统的一个助手；工作台智能体（WorkBuddy）在系统外，可以完全操控系统；两者共用同一个 智能体底座（MCP 连接器、Skill 技能包、Token 计量、确认门与审计）。
图 1 · 商派 AI 外骨骼架构总览：老系统不动，嵌入式 / 工作台两只手臂共用一套底座
外部使用者 · 经销商 / 分销商 / 零售下单者
移动端为主 · 订货会现场与日常订货 · 不进后台，只要结果
内部使用者 · 订单中心 / 供应链 / IT
坐在电脑前 · 查数、出报告、做预测、批量处理
在订货页面里直接对话
在工作台里自然语言指令
AI 外骨骼层 · 商派交付，穿在老系统外面，可穿脱、可插拔
老系统是骨骼，外骨骼是加在外面的一层——骨骼不动，能力外挂
嵌入式智能体
嵌进老系统页面的挂件
· 嵌进 订货宝 / B2B / 乐渠 页面任意位置
· 经销商不离开原系统，说话就能办事
· 移动端优先，订货会现场直接用
政策返利问答
模拟订货测算
订单确认回写
预警接收
老系统群（骨骼）
B2B · OMS · 订货宝/K3
乐渠 · C2F · 产品中台
SAP（财务）· E3（电商库存）
主数据仍在这些系统里 · 不做双账本
一行代码不改 · 不替换 · 不迁移
嵌入
MCP
工作台智能体
系统外的 WorkBuddy 工作台
· 不进系统后台，一句话查数、出报告
· 销售预测、以销定产建议、批量处理
· Skill 自己写，越用越顺手
跨系统查数
诊断报告
销售预测
推送配置
智能体底座 · 两只手臂共用一套
MCP 连接器
Skill 技能包
Token 计量
知识库 RAG
确认门
审计留痕
配一个智能体 = 配置项，不是开发任务 · 每次读写过闸门、留回执
老系统还是那副骨架，AI 外骨骼穿在外面——力气翻倍，动作不换，人还在环里
1.2 落到知名卫浴品牌 · AI 订货平台总体架构
图 2 · 知名卫浴品牌 AI 订货平台总体架构：使用者 → 两种 AI 形态 → 智能体平台 → MCP 连接层 → 治理闸门 → 八套老系统
嵌入式智能体（外部）
工作台智能体（内部）
回写/推送
外部使用者 · 代理商 / 分销商 / 零售下单者
移动端为主 · 订货会现场与日常订货 · 不进后台，只要结果
内部使用者 · 订单中心与供应链
订单管理 · 价格员 · 产品线 · 供应链 · IT · 坐在电脑前工作的人
在订货页面里直接对话
在工作台里自然语言指令
嵌入式智能体 · 系统内助手
H5 挂件 · 嵌进原有页面
嵌进订货宝 / B2B / 乐渠页面任意位置，不离开系统说话就能办事
订货会数据类
政策返利问答
产品 / 品类推荐
订货模拟与达成测算
订单确认与回写
预警推送接收
移动端天然适配
后台蓝图配置即上线 · 改配置不用重新发版 · 解决不了转人工
工作台智能体 · WorkBuddy
WorkBuddy · 系统外独立工作台
不进系统后台，一句话查数、出报告、做预测、批量处理
一句话跨系统查数
订单诊断报告
销售预测
以销定产建议
批量处理
推送规则配置
对账与诊断
自然语言驱动 · MCP 直连系统 · Skill 自己写、越用越顺手
两条线共用同一底座 · 不是二选一，是各管一段
商派智能体平台（Agent Hub）· 两条线共用的配置与编排层
配一个智能体 = 配置项，不是开发任务
蓝图设计
Skill 技能包
模型中转站
Token 计量
人群与权限
长期记忆
确认门策略
审计留痕
多实例共用一套 Token 生态 · 每次请求用量后台可查 · 版本可追溯 · 配完即上线
Skill 调用 · 模型中转 · 工具注册
MCP 连接层与知识底座 · 翻译层
工具注册 · 统一调用 · 渠道 × 角色的数据隔离在这一层完成
知识库 · RAG 问答
政策文件 · 返利规则 · 产品手册 · 操作说明
结构化建库 · 同一问题同一答案 · 可转人工
八套系统连接器 · 逐套 API 盘点后开发
OMS · B2B · 订货宝/K3 · 乐渠
C2F · SAP · E3 · 产品中台
事件引擎 · 推送预警
阈值规则 · 定时任务
企微 / 短信 / 挂件触点
读写请求
治理闸门
确认门：回写下单、冻结解冻、过账等高风险动作先列影响清单、人工点确认才执行 · 审计留痕：全程回执 · 权限矩阵：5 渠道 × 5 角色，各看各的数据
过闸后落回原系统
知名卫浴品牌老系统 · 一套都不换
不动表结构 · 不动二次开发 · 数据仍落回原系统，AI 不建新库、不做双账本
OMS订单评审·工单
B2B代理商采购
订货宝 / K3经销商采购
乐渠零售管理
C2F定制
SAP财务
E3电商库存
产品中台商品主数据
结果回写 · 预警推送（经挂件 / 企微 / 短信送达）
八套老系统不动：嵌入式智能体管系统里的人，工作台智能体管电脑前的人，底座是同一套 MCP、Skill 与 Token 生态。
嵌入式智能体线：外部使用者 → 挂件 → 连接层 → 老系统
工作台智能体线：内部使用者 → WorkBuddy → 连接层 → 老系统
虚线：结果回写与预警推送的回路
琥珀色：治理闸门与事件引擎（管住 AI 的手）
读图要点：嵌入式智能体和工作台智能体不是两个项目，是同一个底座的两个出口。经销商在挂件里问"我订 300 套能拿几个点返利"，和订单中心在 WorkBuddy 里问"高定渠道本月达成多少"，调用的是同一批连接器、同一套权限规则、同一池 Token。差别只在于：嵌入式智能体的能力菜单由后台蓝图配出来、面向移动场景；工作台智能体由使用者自己用自然语言驱动、面向生产作业。
02 / 老系统为什么不用换
AI 是加挂层，不是替换层
知名卫浴品牌的八套系统承载着十年以上的业务流程和数据沉淀，换任何一套都意味着业务停摆、数据迁移和全员再培训。这套框架的做法是在系统外面加一层"会说话的手"，系统本身一行代码不动。
理由 01 · 接入方式
读写走接口，不碰表结构和二开
所有查询与回写都经过 MCP 连接器调用系统已有 API，不改数据库、不改二次开发。连接器卸掉，系统回到原状，零侵入、可回退。
商派自有系统路径：升语言版本 + App 插件装 MCP
知名卫浴品牌八套均为第三方：逐套 API 盘点 + 连接器开发
理由 02 · 数据归属
主数据不动，不做双账本
订单、库存、财务的主数据仍落在 OMS、订货宝/K3、SAP 里。AI 只读、以及经确认门回写，不新建数据库——避免出现"系统一套数、AI 一套数"的对账灾难。
知识类（政策/返利/手册）进知识库，不进业务库
交易类实时查原系统，不做缓存副本
理由 03 · 成本对比
换八套 vs 加一层，账很好算
替换：业务停摆 + 数据迁移 + 全员再培训，周期以年计。加挂：接一套用一套，12 月订货会先上线挂件四模块，验证后再逐套扩连接器，风险切成小段。
一期只接订货会必需的连接器，其余排期
每套连接器独立验收、独立计价
理由 04 · 治理兜底
不动系统，也能管住 AI 的手
客户最担心的不是 AI 够不够聪明，是它会不会擅自动订单。治理闸门就设在智能层与老系统之间：AI 可以读、可以算、可以给建议，但凡要往系统里写，必须先列出"改哪张单、改什么字段、影响多少金额"，由人点确认才执行，并且全程留回执、事后可追溯。
读的放行、写的过闸：查数、查库存、表单预填自动返回；下单回写、预定金冻结解冻、过账这类动作先弹影响清单，人确认才执行
权限在 MCP 层就切清：5 渠道 × 5 角色各看各的数据，越权取数在到达老系统之前就被拦下
"他这些系统该有的都有了，换是换不动的。他要的是上面有一层 Agent 来桥接，根据需要的产生应用来响应。"— 知名卫浴品牌需求沟通会议 · 客户背景转述
03 / 端到端流程
订货会场景概要图
按会前、会中、会后三段，分外部经销商线（嵌入式智能体）、内部订单中心线（工作台智能体）、系统与数据底座三条泳道。编号即执行顺序：12-14 是底座，01 是配置，02-08 是经销商在手机上走完的一条完整订货路径，09-11 是内部线在会前会后的作业。
图 3 · 订货会场景端到端流程：三阶段 × 三泳道，14 个节点
会前 · 打底与配置
会中 · 移动端现场
会后 · 跟踪与履约
外部 · 经销商线（嵌入式智能体）
01 挂件配置上线
订货会四模块：数据 / 政策 / 产品 / 品类
权限视图：哪个渠道哪个角色看什么
知识库就绪：返利规则、下单规则、手册
后台蓝图配置即上线，不用发版
兜底：解决不了的转人工客服
02 扫码进订货会页 · 识别身份
自动切到该经销商的政策视图（手机端）
03 政策问答
订多少拿几个点
品类推荐
04 一句话查单
订单 / 库存 / 余额
跨系统一次问清
05 订货模拟
达成测算：补哪些品
够到下一档返利
06 确认下单
过确认门 → 回写
订货宝 / B2B
07 订单进度 · 物流一句话查
会后随时问，不用打电话催客服
08 预警推送接收
超期未提 / 预定金不足 / 业绩缺口
经挂件 / 企微 / 短信主动送达
内部 · 订单中心线（工作台智能体）
09 报告模板与阈值配置
诊断报告模板 · 推送阈值 · 预测口径
把老员工的规则先落纸再固化
10 现场支援与接待监控
复杂问题转人工 · 接待量与未解决率实时看
订货会当天有人兜底、有数可看
11 会后经营作业
诊断报告自动生成 · 推送规则运营
以销定产建议进 OMS 工单 · 业绩复盘一句话
系统与数据底座（MCP · 知识库 · 事件引擎）
12 打底：知识库建库 + 连接器接通
13 实时执行：MCP 查询 · 确认门回写 · 权限隔离
14 事件触发：阈值命中 → 企微 / 短信 / 挂件送达
底座就绪，支撑配置与问答
推送经挂件 / 企微 / 短信送达经销商
流程的关键设计：经销商全程不离开订货页面、不装新 App；每一步 AI 给出的答案都标明数据来源（哪套系统、哪个时点）；下单这类写动作必须过确认门；会中所有接待留痕，会后自动变成诊断报告和推送规则的养料。订货会验证的不是一个功能，是"嵌入式智能体 + 底座"这条整链路。
04 / 数据关联
四类数据、四条管道，权限线贯穿全程
不是把所有数据搬进一个湖，而是按数据性质走四条管道：静态知识走知识库、交易数据走 MCP 实时查、阈值事件走事件引擎、AI 产生的结果走回写与审计。每条管道的源头、加工方式和消费形态都不同，混在一起就会做出又慢又错的中台。
图 4 · 数据关联图：源系统 → 四类管道 → 四种消费形态 → 业务价值
数据源（老系统 / 文档）
加工管道
消费形态
业务价值
政策 / 返利 / 规则文档静态知识 · 变化低频
商品主数据 · 产品中台品类 / 规格 / 手册
订单 · 库存 · 价格B2B / 订货宝K3 / 乐渠
财务 · 预定金 · 应收SAP
定制订单 · 工单C2F / OMS
历史订单 · 经销商画像用于推荐与预测基线
知识库 · RAG（静态知识）结构化建库 · 检索增强 · 版本可追溯
MCP 实时查询（交易数据）不缓存副本 · 每次查原系统 · 带时点标注
事件引擎（阈值事件）订阅交易数据变化 · 阈值命中即触发
回写与审计（结果数据）确认门放行才写 · 全程回执可追溯
问答同一问题同一答案
报表一句话跨系统出数
推送出事之前先预警
技能把规则固化成动作
人工接待量下降政策口径零分歧
查单从半天到秒级跨部门协调归零
超期未提率下降资金占用可控
老员工经验变资产新人上手周期缩短
落回原系统
权限线贯穿：
5 渠道 × 5 角色 → 数据范围。代理商 A 与代理商 B 问同一政策得到各自视角的答案；价格员、结算专员、导购各看各的数。隔离在 MCP 层完成，不在应用层打补丁。
环节数据从哪来走哪条管道落到哪 / 谁消费关联键
| 政策问答 | 政策文件、返利规则文档 | 知识库 RAG | 挂件问答 · 经销商与内部同库 | 渠道 + 角色 → 政策视图
| 一句话查单 | B2B / 订货宝K3 / 乐渠 / C2F | MCP 实时查询 | 挂件与 WorkBuddy 共用结果 | 订单号 / 经销商编码
| 订货模拟 | 价格政策 + 历史订单 + 库存 | 知识库 + MCP 组合 | 挂件模拟页 → 确认门 | 经销商编码 + 品类
| 确认下单 | AI 生成的订单草案 | 回写与审计 | 订货宝 / B2B 原系统 | 订单号回执 + 操作留痕
| 推送预警 | 交易数据变化（超期/余额/达成） | 事件引擎 | 企微 / 短信 / 挂件 | 阈值规则 + 责任人
| 诊断报告 | 全链路订单 + 提货 + 库存 | MCP 聚合 | WorkBuddy 报表页 · 订单中心 | 渠道 + 时间窗 + 口径版本
05 / 运行机制
Skill、MCP、Token，双智能体的定义与作用
四个部件各管一件事：Skill 管"把流程变成可执行动作"，MCP 管"让 AI 够得着系统"，Token 管"用量与钱"，双智能体管"谁在什么位置用"。四者咬合在一起，才是一个能报价、能验收、能扩展的工程体。
部件 01
Skill 技能包 · 把流程固化成动作
一个 Skill = 一段被文档化、可重复执行的业务流程：取数规则、计算逻辑、动作清单、确认节点都在里面。
机制：触发（一句话或事件）→ 执行（按规则取数、计算、生成动作清单）→ 边界（高风险动作停在确认门，人点确认才执行，全程回执）。trigger → fetch → compute → [confirm gate] → act → receipt
知名卫浴品牌对应：22 项技能编排需求从零共创，逐项标规则来源（人脑 / Excel / 文档）与确认节点
首批：交期按波次分配、预定金冻结解冻、报关单装箱清单生成
部件 02
MCP 连接器 · AI 与系统之间的同传
把每套系统的 API 注册成标准工具，任何智能体用同一种协议调用；权限与数据范围也在这一层切清。
机制：工具注册（系统 API → 标准工具）→ 统一调用（两种形态同一协议）→ 隔离（渠道 × 角色的数据范围在 MCP 层判定）。register → invoke(authz) → isolate → audit
知名卫浴品牌对应：八套第三方系统逐套盘点 API 后开发连接器，一套一验收一计价
知识类不走 MCP 走知识库；交易类不走缓存走实时查
部件 03
Token 生态 · 用量与钱的计量单位
每一次 AI 请求消耗 Token，后台按请求可查、按模型分列；多个智能体、多个实例共用一池。
机制：计量（每次请求用量可查）→ 共用（多实例一套生态）→ 结算（平台订阅按渠道/角色分级，Skill 共创按项，集成按系统套数）。request → meter(model) → pool → invoice(tier)
知名卫浴品牌对应：订货会峰值用量可预估，预算按 Token 包 + 订阅分级报，回应"一个 Skill 多少钱"
业务部门按效果验收时，Token 账单是成本侧的透明凭据
部件 04
双智能体 · 各管一段，不是二选一
外 = 嵌入式智能体（挂件），长在系统里，服务经销商与老板；内 = 工作台智能体（WorkBuddy），在系统外，服务订单中心与 IT。
机制：外部由 Agent Hub 蓝图配置上线、能力菜单可配、移动端适配；内部由自然语言驱动、Skill 自养；两者共用同一批 Skill、MCP 与 Token。hub.configure → widget.serve | buddy.drive → shared(skill, mcp, token)
知名卫浴品牌对应：订货会现场以外部线为主，会后经营以内部线为主，读的是同一批连接器
经销商端存疑不过度承诺：三种形态都进方案，让客户圈范围
06 / 业务目标
这套方案可以实现什么
业务目标现状方案落地后度量口径
| 订货会咨询接待 | 微信人工回复，同一问题几十种问法，会中峰值接不住 | 挂件 24 小时同一问题同一答案，人工只接转办与例外 | 接待量、未解决率、转人工率
| 跨系统查单 | 五套系统人工拼数，一个订单问半天 | 一句话全链路说清，带数据时点标注 | 查单耗时、跨部门协调次数
| 经销商行为管理 | 超期未提、预定金不足靠事后发现 | 阈值触发主动送达，扣款预警在事前 | 超期未提率、预定金占用、达成率
| 订单诊断与产供销协同 | 报告靠老员工 Excel，出一次几天 | 报告分钟级自动生成，以销定产建议直达 OMS 工单 | 报告产出时长、预测准确率
| 政策一致性与培训成本 | 政策靠老员工口口相传，新人上手慢 | 知识库同问同答，老员工经验固化成 Skill | 新人上手周期、政策争议单数
"不要拿蓝图去讲我们有什么，拿蓝图去讲：你们要的那个平台，我们已经长出了一半，剩下的一半正好和你们一起长。"— 内部会议 · 对知名卫浴品牌下次沟通的定位
07 / 十例工程剖析
依照以上方案，10 个场景的具体实现举例说明
例 01PPT P3 · 场景一表格 R3嵌入式 · 挂件 · 知识问答+推荐
"推荐几款带数显的恒温淋浴器" —— 按卖点/功能推荐产品
PPT 原文要求：根据描述的功能找到产品，并根据历史数据 / 产品属性进行推荐。同页还有产品对比、竞品对比、产品介绍、品类核心产品（新品/核心品/爆款）四类问法，共用同一条检索管线。
图 1-1 · 卖点推荐执行管线：混合检索召回 → 规则+销量排序 → 推荐卡片
1
挂件触发
经销商手机端问：
"推荐几款带数显的
恒温淋浴器"
2
意图解析
LLM 抽取槽位：
品类=淋浴器
特征=[数显,恒温]
3
混合检索召回
属性过滤(结构化)
+ 卖点向量召回(RAG)
源：产品中台知识库
4
排序与过滤
近3月销量加权
库存充足度(E3)
渠道可售资格过滤
5
推荐卡片输出
参数对比表 · 卖点话术
库存紧张/充足提示
可追问"对比A和B"
6 反馈回流：点击/加购/下单行为回流 → 调整排序权重；未解决 → 转人工导购，接待记录进知识库优化问题对
要客户源系统的哪些数据
源系统数据字段级要求时效
| 产品中台 | SPU/SKU 主数据 | 品类树、结构化属性（数显/恒温/流量/尺寸/材质）、卖点标签、上市日期 | 日同步
| 产品中台/文档库 | 产品手册、彩页、竞品对标资料 | PDF/PPT 原件，用于解析建向量库 | 新品上市时更新
| E3 | 库存 | SKU × 仓库可用量 | 实时查
| 销售系统（B2B/乐渠） | 历史销量 | SKU × 月销量，近 6 个月 | T+1 快照
需开放什么接口
接口方向说明
| product.search / product.detail | 只读 | 产品中台属性检索与详情，支持按属性组合过滤
| inventory.queryBySku | 只读 | E3 按 SKU 查可用库存（含在途可选）
| sales.monthlyBySku | 只读 | 销量月表，T+1；或每日快照推送到中间库
| 文档导出通道 | 一次性 | 手册/彩页批量导出用于建库，之后增量
客户需配合输出的参数
参数提供部门形式
| 属性词典与同义词表（"数显"="数字显示"="带屏"） | 产品部 | Excel 词表
| 新品/核心品/爆款打标规则 | 产品线 | 规则文档
| 渠道可售资格矩阵（哪个渠道能卖哪些品类） | 销售管理 | Excel 矩阵
| 竞品对标关系表（本品 SKU ↔ 竞品型号） | 市场部 | Excel
模型选型
环节技术说明
| 意图解析/槽位抽取 | LLM（平台模型中转站接入） | 问法千变万化，规则写不全
| 卖点检索 | Embedding + BM25 混合检索 | 属性走结构化过滤，卖点话术走向量召回
| 排序 | 规则 + 销量加权 | 一期不上学习排序，可解释优先
| 话术生成 | LLM（受控：只基于召回的属性与卖点） | 防幻觉：参数数字必须来自结构化字段
判定：直接可实现。前提有二：① 产品中台属性结构化完成度——若"数显/恒温"只是手册里的文案而非属性字段，则依赖向量召回，准确率下降，需产品部先补属性词典；② 手册类 PDF 需批量导出建库。本例管线同时覆盖同页 R1/R2/R4/R5（产品对比、竞品对比、产品介绍、品类核心产品），一次建库五类问法全通。
例 02PPT P3 · 场景一表格 R7嵌入式 · 挂件 · 计算技能
"6月和7月还需要下单多少" —— 下单保障缺口测算
PPT 原文要求：根据客户 6-7 月的提货目标以及 6-7 月已下单数据，给出还需要补单的缺口。P4 R4/R5 同族："这个月还需要下单多少""下个月（季度）订单还差多少"——同一 Skill 换时间窗。
图 2-1 · 保障缺口计算管线：三源取数 → 公式计算 → 缺口解读 → 可一键转下单草案
1
挂件触发
经销商问"6月和7月
还需要下单多少"
身份自动带入渠道/角色
2
意图解析
识别=保障缺口测算
时间窗=[6月,7月]
主体=当前经销商
3
三源取数 MCP
目标：业绩目标源
已下单：B2B订单
已提货：SAP出货
4
规则计算
缺口=目标−已下单
保障度=已下单/目标
剔除取消单/退货单
5
输出与转化
缺口金额+分月明细
按品类给补单建议
"一键下单"→草案
6 写动作支路：下单草案 → 确认门（展示金额/政策/预定金影响清单）→ 经销商确认 → 回写 B2B → 回执留痕，全程审计
要客户源系统的哪些数据
源系统数据字段级要求时效
| 业绩目标源（绩效系统或 Excel） | 经销商 × 月提货目标 | 目标金额、分月拆分、渠道归属；若在 Excel 需月度上传机制 | 月初锁定
| B2B | 已下单明细 | 订单号、经销商编码、金额、品类、下单日期、状态（含取消标记） | 实时查
| SAP | 已提货/出货 | 出货单、金额、日期、对应订单号 | T+1 或实时
需开放什么接口
接口方向说明
| target.getByDealer | 只读 | 按经销商+月份查目标；无系统则约定 Excel 模板月度导入
| order.listByDealer | 只读 | B2B 订单查询，支持时间窗与状态过滤
| sap.shipmentByDealer | 只读 | SAP 出货查询
| order.createDraft | 写 | 下单草案回写（仅确认门放行后调用）
客户需配合输出的参数
参数提供部门形式
| 保障度公式口径（保障度=已下单/目标？含不含在途？） | 订单中心 | 规则文档，一页纸
| 目标分月拆分规则（季度目标如何摊到月） | 销售管理 | 规则文档
| 剔除口径（取消单、退货冲减、赠品单是否计入） | 订单中心+财务 | 规则文档
| 预警分级线（PPT 中出现保障度 30% 即预警） | 订单中心 | 阈值表
模型选型
环节技术说明
| 意图与时间窗解析 | LLM | "6月和7月""下季度"等表达归一化
| 缺口计算 | 规则引擎（Skill 内固化公式） | 钱的计算不交给 LLM，公式可审计
| 补单建议 | LLM + 历史订单结构 | 按经销商历史品类占比生成建议组合
判定：可实现，但规则先落纸。计算本身简单，难点全在口径：保障度公式、目标数据来源、剔除规则三项若客户给不出书面口径，这个数字就不能对外——报错一个缺口金额，经销商会拿着截图找客服对质。建议把"口径确认会"作为本 Skill 的第一个交付里程碑。
例 03PPT P8 · 订单诊断报告事件 · 每周定时批处理嵌入式+工作台共用
每周预生成《订单诊断报告》—— 七模块全维诊断 + 下单建议
PPT 原文要求：系统每周预生成《订单诊断报告》，客户可在助手聊天页面随时点击查看。七模块：订单提货达成（达成率/业绩缺口）、订单保障（保障度/保障缺口）、提货均衡性（分旬提货占比/均衡性要求）、未提订单（本月未提/超期未提/扣款预警）、订单交期分析（交期分布/历史交期/交期与业绩预警）、问题诊断与下单建议、提货计划与资金准备（本月预计提货/账户余额/缺口款项/解冻预定金）。
图 3-1 · 诊断报告生成管线：定时批处理 → 七模块规则计算 → 症候库诊断 → LLM 叙事 → 双端分发
1
定时触发
每周日 22:00 批处理
按经销商逐个生成
全量约数千份/周
2
七模块取数
目标/B2B订单/SAP出货
未提与交期(OMS)
余额与预定金(SAP)
3
指标计算+诊断
达成率/保障度/分旬占比
超期天数/资金缺口
症候组合→结论库匹配
4
LLM 叙事生成
诊断结论→自然语言
下单建议(带金额)
数字只许引用计算层
5
渲染与双端分发
HTML 报告入库(版本号)
嵌入式:挂件推送"报告已生成"
工作台:订单员看汇总异常榜
6a 经销商侧回流：点击查看率、报告内"一键下单/补预定金"
按钮转化 → 衡量报告是否真的驱动了提货行为
6b 订单员侧回流：对诊断结论"采纳/驳回"标注 →
驳回样本回流症候库，规则逐周迭代（人在环上）
要客户源系统的哪些数据
模块源系统数据
| 提货达成/保障 | 目标源 + B2B + SAP | 目标、已下单、已提货（同例 2）
| 均衡性 | SAP 出货 | 分旬提货金额与笔数、对应订单交期
| 未提订单 | OMS / B2B | 未提明细、约定提货时间、超期天数
| 交期分析 | OMS / C2F | 订单交期分布、历史平均交期、交期特性（定制更长）
| 资金准备 | SAP | 账户余额、冻结预定金、可解冻金额
需开放什么接口
接口方向说明
| 例 2 全部只读接口 | 只读 | 复用，批量调用需性能约定（夜间批窗口）
| sap.deposit.query | 只读 | 冻结/可解冻预定金
| report.store（平台侧） | 写 | 报告版本化存储，可追溯每期口径
| 挂件推送通道 | 写 | 报告就绪通知，点击进入
客户需配合输出的参数
参数提供部门形式
| 分旬划分与均衡性要求（每旬提货占比红线） | 订单中心 | 规则文档
| 诊断症候库：缺口×保障×交期特征 → 结论与建议的映射表（PPT 原文"针对业绩缺口，结合订单保障、未提订单、交期特性给出问题诊断与下单建议"） | 资深订单员共创工作坊 | 结构化规则表，首批 20-30 条
| 解冻预定金条件 | 财务 | 规则文档
| 报告版式确认（七模块顺序、红黄绿灯阈值） | 订单中心 | 样张签认
模型选型
环节技术说明
| 七模块指标 | 规则引擎批量计算 | 数千份/周，必须确定性、可复算
| 问题诊断 | 症候库匹配（决策表） | 不让 LLM 自由诊断——建议错了要担责
| 叙事与建议文案 | LLM 受控生成 | 模板内填数，数字强制引用计算层结果
| 批量调度 | 平台定时任务 | 失败重试与缺数降级（某源缺数则模块标注"数据未就绪"）
判定：可实现，核心工作量在症候库共创。这份报告是 PPT 的收官能力，也是知名卫浴品牌"用 AI 管代理商"意图的集中体现。技术上无难点（批处理+规则+受控生成），真正的门槛是诊断口径——老订单员看一眼就知道"这个客户该催提货还是该催下单"，这个判断必须变成决策表。建议安排 2-3 场共创工作坊，用真实客户数据回放校准，首批 20-30 条症候规则上线，之后每周用驳回样本迭代。
例 04PPT P4 · 表格 R1/R7嵌入式 · 挂件 · 跨系统计算
"6-7月还要提多少货，准备多少预定金" —— 未提订单与资金测算
PPT 原文要求：列出交期在 6、7 月的订单总额，并计算出预定金金额（R1）；计算出这个月订单缺口，根据预定金规则算出需要准备的预定金金额（R7）。同页 R6"查询目前冻结了多少预定金"、R8"预定金规则查询"共用同一套数据与规则。
图 4-1 · 预定金测算管线：跨 OMS/B2B/SAP 三系统 → 规则计算 → 资金准备清单 → 可选冻结申请过确认门
1
挂件触发
"6-7月还要提多少货
准备多少预定金"
2
意图解析
拆成两个子任务：
①未提测算 ②预定金测算
串联执行
3
跨系统取数
OMS:6-7月交期未提订单
SAP:余额+已冻结预定金
知识库:预定金比例规则
4
规则计算
预定金=Σ(订单额×品类比例)
资金缺口=需备−余额+已冻结
分月列出提货节奏
5
资金准备清单输出
未提明细(单号/SKU/金额)
分月预定金需求+缺口
附打款提醒时点建议
6 写动作支路：经销商可发起"预定金冻结/解冻申请"→ 确认门（财务规则校验+影响清单）→ 回写 SAP → 双方回执
要客户源系统的哪些数据
源系统数据字段级要求时效
| OMS / B2B | 未提订单 | 订单号、SKU、数量、金额、约定交期、已提数量 | 实时查
| SAP | 账户与预定金 | 各账户余额、冻结预定金（按订单关联）、解冻记录 | 实时查（财务敏感，需授权白名单）
| 政策文档 | 预定金规则 | 品类×客户等级的比例表、冻结/解冻/超期扣款规则 | 政策变更时更新知识库
需开放什么接口
接口方向说明
| oms.unshippedOrders | 只读 | 按经销商+交期窗查未提订单
| sap.account.balance | 只读 | 账户余额（各账户），IP 白名单+字段级授权
| sap.deposit.frozen | 只读 | 冻结预定金按订单明细
| sap.deposit.apply | 写 | 冻结/解冻申请，仅确认门放行后，异步+回执
客户需配合输出的参数
参数提供部门形式
| 预定金比例表（品类×渠道×客户等级） | 财务+销售管理 | 结构化 Excel（从政策文件抽取后财务签认）
| 冻结/解冻/超期扣款触发条件与时点 | 财务 | 规则文档
| SAP 接口授权范围（哪些账户字段可对外查询） | 财务+IT | 授权清单
| 打款提醒节奏（提前几天提醒、提醒几次） | 订单中心 | 阈值表
模型选型
环节技术说明
| 意图拆解 | LLM | 一句话拆两个子任务并串联
| 金额计算 | 规则引擎 | 财务数字零容错，LLM 不碰算术
| 规则问答（R8"查预定金规则"） | RAG | 同一知识库，引用原文条款作答
判定：可实现，预定金规则表是第一前置。涉及 SAP 财务数据，接口授权与字段白名单要走客户财务流程，周期不可控——建议本周即发起授权申请。比例表若散在多份政策文件里且版本不一，以财务签认的结构化版本为准，知识库同步标注生效日期。
例 05PPT P4 · 表格 R3 + P6 阈值推送事件引擎 · 定时+阈值
"我有没有超期未提的订单" —— 超期未提明细与扣款预警
PPT 原文要求：列出客户的超期未提订单明细、要求提货时间、扣款预警（P4 R3）。P6 场景二进一步要求主动推送："XXX（客户名），超期订单订单号、数量、金额，什么时候将要被扣预定金，请及时提货"——问答与推送共用同一套判定逻辑，一个被动应答、一个主动送达。
图 5-1 · 超期未提双路管线：每日批扫（主动推）+ 实时问答（被动查），共用同一判定规则
A
主动路 · 每日 06:00
批扫全量未提订单
判定超期天数≥N
计算扣款倒计时
B
被动路 · 实时问答
经销商挂件里问
"有没有超期未提"
身份自动限定数据范围
共用判定内核
OMS/B2B 未提订单+交期
超期起点口径(约定提货日)
扣款规则(超X天扣预定金)
A→ 预警消息生成与触达
LLM 按模板个性化(客户名/单号/金额/倒计时)
分级触达：挂件→企微→短信升级
频控：同一单同一周不重复轰炸
B→ 明细清单输出
超期订单明细+要求提货时间
扣款预警金额与时点
附"一键查看提货流程"引导
C 回流与看板
触达回执(送达/已读/点击)入库
订单员看板：推送后仍未提货名单
→ 人工介入打电话（AI 管到提醒为止）
要客户源系统的哪些数据
源系统数据字段级要求时效
| OMS / B2B | 未提订单 | 约定提货日期、超期天数、扣款触发标记 | 每日批扫 + 实时查
| SAP | 扣款执行结果 | 实际扣款记录（用于闭环核销预警） | T+1
| CRM/主数据 | 经销商联系人 | 手机号、企微绑定、渠道归属、责任人（客代） | 变更同步
需开放什么接口
接口方向说明
| oms.unshippedOrders | 只读 | 复用例 4；批扫走夜间批量视图避免压生产库
| 企微消息通道 | 写 | 客户已有企微体系，走客户企微应用或商派通道，二选一
| 短信通道 | 写 | 升级触达用，客户采购或复用商派通道
| notify.receipt（平台侧） | 写 | 送达/已读回执入库
客户需配合输出的参数
参数提供部门形式
| 超期判定起点（约定提货日 or 交期+N 天宽限） | 订单中心+财务 | 规则文档，需财务确认扣款合规
| 扣款倒计时口径（超期几天扣、扣多少） | 财务 | 规则表
| 预警分级与触达策略（提前 7/3/1 天，挂件→企微→短信） | 订单中心 | 阈值表
| 频控与免打扰（每周上限、夜间不推、豁免客户名单） | 销售管理 | 策略表
模型选型
环节技术说明
| 超期判定 | 事件引擎规则 | 确定性判定，不用模型
| 消息个性化 | LLM 模板填槽 | PPT 已给 8 个消息模板，LLM 只做称谓/明细/语气的自然化
| 问答路 | MCP 查询 + LLM 组织 | 与推送共用判定内核，保证"问的和推的一致"
判定：可实现，误报是最大风险。扣款预警推错（把没超期的说成要扣款）会直接伤害经销商关系，因此超期起点口径必须财务书面确认，上线前用近 3 个月历史数据回放对账：AI 判定结果 vs 实际扣款记录，一致率达标（建议 ≥99%）才开推送。频控策略也需客户拍板——推送是管理动作，轰炸会让经销商屏蔽通道。
例 06PPT P4 · 表格 R9/R10嵌入式 · 挂件 · 财务查询
"查询一下5月对账单" / "查询目前的账户余额" —— 对账与账户
PPT 原文要求：列出 5 月对账单（R9）；列出客户目前在集团的账户余额——各个账户（R10）。P2 概览页也把"账户对账相关问题"列为九大类之一。这是财务敏感级最高的一类问答。
图 6-1 · 对账查询管线：强鉴权 → SAP 取数 → 模板渲染 → 差异走人工工单
1
挂件触发
"查询一下5月对账单"
登录态=经销商账号
仅能查本主体
2
意图+强鉴权
解析期间=2026-05
MCP 层校验数据范围
财务字段白名单放行
3
SAP 取数
期初/出货/回款/返利
期末余额、各账户分列
取"已过账"口径数据
4
模板渲染+勾稽
期初+发生=期末 自检
对账表模板(财务签认版)
金额格式与科目映射
5
输出
挂件内结构化账单卡片
可下载 PDF 版
标注数据时点与口径
6 差异支路：客户点"对这笔有异议"→ 生成对账工单 → 推送财务对接人 → 处理结果回写并通知客户，全程留痕（AI 不裁决差异，只传递）
要客户源系统的哪些数据
源系统数据字段级要求时效
| SAP | 对账单五要素 | 期初余额、出货发生、回款发生、返利/折让、期末余额，按经销商×月×账户 | 月度关账后发布；月中查"实时余额"需标注未关账口径
| SAP | 账户结构 | "各个账户"的账户类型清单（货款户/返利户/保证金户等） | 主数据同步
| B2B/OMS | 出货明细关联 | 账单行 → 订单号可下钻 | 实时查
需开放什么接口
接口方向说明
| sap.statement.monthly | 只读 | 按经销商+期间查对账单（SAP 标准 FI/SD 报表接口或中间视图）
| sap.account.list | 只读 | 各账户余额实时查
| 工单系统接口 | 写 | 异议工单创建与状态回查（客户现有 OA/客服系统，或平台侧建工单）
客户需配合输出的参数
参数提供部门形式
| 对账单模板与科目映射（SAP 科目 → 客户能看懂的行名） | 财务 | 模板签认
| "已过账 vs 未关账"两种口径的展示规则 | 财务 | 规则文档
| 返利在账单中的列示规则（已兑现/预提分列？） | 财务 | 规则文档
| 异议工单流转 SLA 与对接人矩阵 | 财务+客服 | 流程文档
模型选型
环节技术说明
| 意图解析 | LLM | 只解析期间与账单类型，不生成数字
| 账单生成 | 模板渲染（无生成式） | 财务输出必须与 SAP 逐分一致，禁止 LLM 参与数字
| 勾稽自检 | 规则校验 | 期初+发生≠期末 即拦截不展示，报数据质量告警
判定：可实现，但按"财务级"标准交付。三条铁律：① 数字只从 SAP 来，LLM 全程不碰金额；② 关账口径必须标注（月中查询展示的是未关账实时数，与月底正式账单可能有差异，界面必须写明）；③ AI 不裁决对账差异，只提供"一键异议"通道。SAP 接口授权是长周期项，与例 4 合并一次申请。
例 07PPT P5 · 定制品表格 R3/R11写动作 · 确认门 · 转人工
"请帮我加急**订单" —— 加急申请的收集、确认与流转
PPT 原文要求：填写需求日期和加急原因（自动转人工），订单提醒到总代及集团订单员账号（R3）；"这个订单XXXXXX安排加急发货"填写收件信息（自动转人工）并提醒到总代及集团订单员账号（R11）。这是 PPT 里典型的"AI 收集 + 人来执行"类需求，同页 R8 改地址、R12 售后催单、R13 投诉关键词同属此族。
图 7-1 · 加急流转管线：槽位收集 → 可行性预判 → 确认门 → 工单双推 → 状态回传与超时升级
1
挂件触发+核单
"帮我加急XX订单"
MCP 核对该经销商
名下订单真实性/状态
2
LLM 槽位收集
多轮追问补齐：
需求日期/加急原因
收件信息(R11发货类)
3
可行性预判
查 C2F/OMS 生产环节
已投产不可逆→提示风险
规则判断可否受理
4
确认门
展示影响清单：
改期风险/费用/不承诺
客户点确认才提交
5
加急工单生成与双推
工单=订单快照+槽位+影响清单
企微推总代账号+集团订单员账号
同步建跟踪任务(SLA 计时开始)
6 闭环：人工处理结果回填工单 → 状态回传经销商挂件（受理/改期成功/无法满足+原因）→ SLA 超时自动升级到销售管理
投诉关键词支路（R13）：检测到"延误/延期/投诉"→ 跳过预判直接高优工单 + 转总代及集团订单员，情绪识别提升优先级
要客户源系统的哪些数据
源系统数据字段级要求时效
| C2F / insight | 定制订单与生产进度 | 合同号、生产订单号、当前环节、可加急环节标记 | 实时查
| OMS | 标准订单状态 | 评审/排产/发货环节流转记录 | 实时查
| 组织主数据 | 总代-集团订单员映射 | 每个总代对应的集团订单员、企微账号、升级链 | 变更同步
需开放什么接口
接口方向说明
| c2f.order.progress | 只读 | 定制订单环节查询（P5 R5"查合同号/生产订单号/SAP单号进度"同源）
| ticket.create / ticket.status | 写/读 | 加急工单创建与状态回查（平台侧工单或客户 OA）
| 企微应用消息 | 写 | 按映射表推送到人，需客户企微管理员配置应用与可见范围
客户需配合输出的参数
参数提供部门形式
| 加急受理规则（哪些环节可加急、哪些不可逆） | 供应链+订单中心 | 规则文档
| 加急审批链（金额/数量超阈值是否需审批） | 销售管理 | 流程文档
| SLA 与升级链（几小时响应、超时升级给谁） | 订单中心 | 阈值表
| 总代↔集团订单员账号映射表 | 销售管理 | Excel，企微 userid 级
| 投诉关键词库（延误/延期/投诉及变体） | 客服 | 词表，可持续补充
模型选型
环节技术说明
| 槽位收集 | LLM 多轮对话 | 缺什么问什么，收齐为止
| 关键词/情绪识别 | 规则词表 + LLM 兜底 | R13 投诉检测：词表命中即触发，语义变体由 LLM 判
| 可行性预判 | 规则引擎 | 基于生产环节状态机，不猜测
| 流转编排 | 工作流引擎 | 工单状态机：提交→受理→处理→回传→关闭
判定：直接可实现，且是"AI 不越权"的样板。本例的设计原则值得对客户强调：AI 只做收集、预判、流转、回传四件事，加急成不成由人决定——确认门里明确写"不承诺加急结果"。这正好回应业务部门对"AI 乱动订单"的顾虑，也是 P5 页 R8 改地址、R12 售后催单、R13 投诉转接三个同族需求的统一模板。
例 08PPT P5 · 定制品表格 R9工作台为主 · 聚合报表
"**零售中心/**门店/*客户的到区域出货情况" —— 多维聚合报表
PPT 原文要求：显示产品系列/到区域维度销售情况，及每个月出货数量情况，按降序排列。这是典型的管理层/订单员分析型问法——维度多（系列×区域×门店×月）、数据量大、权限敏感，适合工作台智能体（WorkBuddy）承载，嵌入式智能体按角色开放简化视图。
图 8-1 · 聚合报表管线：维度解析 → 快照聚合（非实时扫库）→ 权限裁剪 → 图表输出 → 下钻追问
1
WorkBuddy 触发
订单员/管理者问：
"XX零售中心到区域
出货情况"
2
维度解析
LLM→结构化查询：
维度[系列,区域,月]
度量[出货数量,金额]
3
快照聚合取数
SAP出货日快照(T+1)
门店主数据(乐渠)
系列映射(产品中台)
4
聚合+权限裁剪
预置聚合模板计算
降序排列
按角色裁数据范围
5
图表报告输出
HTML 报表(柱状+明细表)
LLM 写摘要结论
16秒级生成(蓝图实测)
6 下钻回流："其中XX门店单独看""环比上月"→ 追问继承上下文再聚合；高频问法沉淀为固定报表进老板看板（P2 概览页"老板"角色）
要客户源系统的哪些数据
源系统数据字段级要求时效
| SAP | 出货明细 | 出货日期、SKU、数量、金额、收货方（门店/零售中心编码） | T+1 日快照（量大，不实时扫生产库）
| 乐渠 / 门店主数据 | 零售中心-门店-区域层级 | 门店编码、归属零售中心、区域划分、开关店状态 | 变更同步
| 产品中台 | SKU→产品系列映射 | 系列/品类两级 | 日同步
需开放什么接口
接口方向说明
| sap.shipment.dailySnapshot | 只读·批量 | 每日增量推送或开放批量抽取视图（数仓模式）
| store.hierarchy | 只读 | 门店层级与区域归属
| product.seriesMap | 只读 | 系列映射
| 权限服务 | 只读 | 查询者角色与数据范围（对接客户统一身份或平台人群配置）
客户需配合输出的参数
参数提供部门形式
| 区域划分口径（大区/省/城市哪级算"区域"） | 销售管理 | 维度定义文档
| 系列分类映射表（SKU 归系列的规则） | 产品部 | Excel
| 数据权限矩阵（零售中心经理看本中心、区域总看本区域…） | 销售管理+IT | 角色×范围矩阵
| 历史数据初始化范围（回溯几年） | IT | 一次性约定
模型选型
环节技术说明
| 维度解析 | LLM → 预置聚合模板参数填充 | 不用开放 text2SQL：模板化聚合可控、可审计、性能稳
| 聚合计算 | 快照库上的预聚合（OLAP） | 系列×区域×月的立方体，查询毫秒级
| 摘要结论 | LLM 受控生成 | 只描述计算结果（Top/环比/异常），不外推
判定：可实现，架构上必须走快照而非实时。出货明细是千万行级数据，实时扫 SAP 生产库既慢又危险——这正对应内部会议讨论的"轻数中台"路线：每日 T+1 快照 + 预聚合，20-30 张宽表结构即可支撑全部分析型问法。权限裁剪是硬前提：区域数据是敏感经营数据，角色×范围矩阵需客户销售管理与 IT 共同签认后才可对该问法开放。
例 09PPT P6 · 场景二 8 类推送模板事件引擎 · 定时+阈值双触发
"完成率不足50%，请及时提货" —— 业绩达成主动推送全家族
PPT 原文要求（消息模板节选）："XXX（客户名），本月业绩目标XXX万，已提货XXX万，完成率不足50%，请及时提货完成业绩目标"（阈值触发）；"7月业绩目标XXX万，已下单XXX万，订单保障度30%，请及时补充订单"；"目前账户余额XXX万，请密切关注本月提货目标以及余额数据"（定时推送）。8 类模板 = 定时（业绩达成数据/本月剩余提货/订单保障数据）+ 阈值（业绩预警/超期未提/保障预警/余额预警/余额推送）。
图 9-1 · 推送家族管线：双触发 → 按经销商计算 → 分级判定 → 个性化文案 → 多触点频控触达 → 回执回流
1
双触发
定时：每日08:00/月初
阈值：出货回款过账
事件即时重算该经销商
2
按经销商计算
达成率=已提货/目标
保障度=已下单/目标
余额 vs 剩余提货需求
3
分级判定
<50% → 业绩预警(高优)
65% → 进度提醒(常规)
余额<需求 → 余额预警
4
个性化文案
PPT 8 模板为基底
LLM 填客户名/数字/明细
数字强制引用计算层
5
多触点频控触达
挂件聊天窗(主通道)
企微/短信(升级通道)
同人同类周频上限+免打扰
6 回执回流：送达/已读/点击入库存证；点击"去提货"→ 直接进挂件下单流程（推送即入口）
订单员侧：推送后 N 天仍未动作的经销商生成"人工跟进名单"→ 工作台看板，AI 管提醒、人管关系
要客户源系统的哪些数据
源系统数据字段级要求时效
| 目标源 + B2B + SAP | 目标/已下单/已提货/余额 | 复用例 2、例 4 数据面 | 定时批 + 过账事件触发
| CRM/主数据 | 触达通道档案 | 每经销商：挂件账号、企微 userid、手机号、偏好通道、归属客代 | 变更同步
| OMS | 本月剩余提货计划 | 待提货订单交期分布（"本月剩余提货"模板用） | 日批
需开放什么接口
接口方向说明
| 例 2/例 4 全部只读接口 | 只读 | 复用；批扫走快照视图
| SAP 过账事件订阅（或轮询） | 事件 | 出货/回款过账后触发重算；SAP 无事件能力则 15 分钟轮询增量
| 企微应用消息 + 短信网关 | 写 | 同例 5；客户企微管理员配置
| notify.receipt | 写 | 回执存证，供频控与效果分析
客户需配合输出的参数
参数提供部门形式
| 8 类模板的阈值分级表（50%/65%/余额线，分渠道可不同） | 订单中心+销售管理 | 阈值表
| 推送节奏日历（月初推保障、每周一推达成、扣款前 3 天推余额） | 订单中心 | 排期表
| 频控与免打扰规则（周上限、时段、豁免名单如战略客户由客代人工沟通） | 销售管理 | 策略表
| 文案语气审签（8 模板 LLM 化后的样张，销售管理签认） | 销售管理 | 样张签认
模型选型
环节技术说明
| 触发与判定 | 事件引擎规则 | 定时任务 + 阈值规则，全部确定性
| 文案生成 | LLM 模板填槽 | PPT 已给全文模板，LLM 只自然化表达，数字锁死引用
| 通道决策 | 规则（偏好+升级链） | 不用模型，按档案与回执历史选通道
判定：直接可实现，PPT 已把最难的部分（消息模板）写完了。客户 8 个模板连措辞都拟好了，等于验收标准自带。工程量集中在：① 事件引擎对接 SAP 过账事件（或轮询降级）；② 触达通道档案的完整度——企微 userid 与手机号的覆盖率决定送达率，需客户先做一轮档案清洗；③ 频控策略拍板。上线策略建议：先开"挂件内推送"单通道灰度两周，回执数据达标后再开企微/短信升级链。
例 10PPT P7 · 场景三 订单员分析工作台 · WorkBuddy · 分析+预测
"某款单品还能卖多久？" —— 单品库存周转与可售天数预估
PPT 原文要求：AI 会结合历史销量和当前库存，给出一个预估的销售天数，这对制定采购计划非常有价值。同页族：热销产品分析（近三月每品类 TopN+库存状态）、商品库存健康度（水位+风险+健康等级+建议"观察"）、欠货分析（订单交付+产能→交货周期+欠货严重产品）——四项共用同一套销存数据面。
图 10-1 · 库存周转分析管线：SKU 解析 → 销存四面取数 → 两期算法（规则→时序）→ 健康评级 → 采购建议支路
1
WorkBuddy 触发
订单员问"XX单品
还能卖多久"
或批量"全品类健康度"
2
SKU 解析
品名/编码模糊匹配
多 SKU 命中→列选
品类问法→展开 SKU 集
3
销存四面取数
E3:当前库存(分仓)
销售:近90天日销量
OMS:在途 + 排产计划
4
两期算法
一期:可售天数=库存/日均
(30/60/90天加权移动平均)
二期:时序预测+安全库存
5
评级输出+LLM解读
健康等级:健康/观察/风险(阈值表)
分仓风险点(某仓水位过低)
欠货族:叠加产能→交货周期预估
6 行动支路："风险"级 SKU → 一键生成采购/调拨建议单 → 确认门（数量/金额/供应商）→ 回写 OMS/采购流程 → 回执
回流：订单员对预估"准/不准"标注 → 校准移动平均窗口与阈值；标注样本积累后再评估是否上二期时序模型
要客户源系统的哪些数据
源系统数据字段级要求时效
| E3 | 库存 | SKU × 仓库 × 可用/在途/锁定量 | 实时查 + 日快照（趋势用）
| B2B/乐渠/电商 | 销量明细 | SKU × 日销量（分渠道），近 12 个月 | T+1 快照
| OMS / 工厂 | 在途与排产 | 在途采购单、生产计划（未来供给） | 日批
| OMS | 欠货族追加：产能数据 | 品类产能、订单积压、平均交货周期 | 周批
需开放什么接口
接口方向说明
| e3.inventoryBySku | 只读 | 分仓库存实时查
| sales.dailyBySku | 只读·批量 | 日销量快照（分析走快照不走生产库）
| oms.intransitAndPlan | 只读 | 在途与排产
| purchase.createSuggestion | 写 | 采购建议单（确认门后）
客户需配合输出的参数
参数提供部门形式
| 日均销窗口与加权（30/60/90 天哪个为准） | 订单中心+供应链 | 参数约定
| 健康等级阈值表（可售天数 <15 天=风险？分品类） | 供应链 | 阈值表
| 促销剔除口径（大促脉冲是否剔除出日均） | 销售管理 | 规则文档
| 新品处理规则（无历史时按品类均值还是人工设定） | 产品线 | 规则文档
| 安全库存标准（二期预测的约束输入） | 供应链 | 参数表
模型选型
环节技术说明
| 一期·可售天数 | 加权移动平均（规则） | 可解释、当天可上线，PPT 要求的"预估销售天数"一期即达成
| 一期·健康评级 | 阈值决策表 | PPT 原文"健康等级为健康、建议观察"即此形态
| 二期·需求预测 | 时序模型（指数平滑/Prophet 类） | 积累 3 个月标注后评估；促销/季节因子进特征
| 结果解读 | LLM | 把数字翻译成"这款还能卖 23 天，华东仓偏低，建议调拨"——数字锁死引用
判定：分析直接可实现，预测分两期。这正是内部对客户优先级判断的落点——客户自己把"销售预测、净需求预测"排在第三期（"比较复杂的"）。一期用移动平均 + 阈值评级就能交付 PPT 描述的全部输出形态（预估天数、健康等级、风险点、建议），先跑起来积累"准/不准"标注；二期再上时序模型就有了训练与验收依据。欠货分析多依赖产能数据，若工厂排产不透明，该子项降级为"基于在途+积压的交货周期估算"并在报告中标注口径。
08 / 三张配合清单
十例合起来看：客户要配合的其实是三张清单
把 10 个例子的"数据、接口、参数、模型"四栏纵向合并，客户侧的配合项收敛为三类——这也是下次沟通可以直接递给知名卫浴品牌 IT 与业务部门的作业清单。
清单一 · IT 侧
接口开放清单（按系统归并）
B2B：订单查询、订单草案回写（写）
OMS：未提订单、交期、在途与排产、工单创建（写）
SAP：出货、账户余额、预定金、月度对账单、过账事件订阅；财务字段白名单 + IP 授权（周期最长，最先启动）
E3：分仓库存
C2F / insight：定制订单进度
产品中台：属性检索、系列映射、手册文档批量导出
乐渠 / 主数据：门店层级、经销商联系人、总代↔订单员映射
通道类：企微应用消息、短信网关、工单系统
清单二 · 业务侧
规则参数落纸清单（口径文档化）
财务类：预定金比例表、冻结/解冻/扣款规则、对账口径与科目映射、关账口径
目标类：保障度公式、目标分月拆分、剔除口径、预警分级线
预警类：超期判定起点、扣款倒计时、频控与免打扰、触达升级链
分析类：健康等级阈值、日均销窗口、促销剔除、区域与系列口径、数据权限矩阵
诊断类：症候库（缺口×保障×交期→结论建议映射，资深订单员共创）
流转类：加急受理规则、审批链、SLA、投诉关键词库
清单三 · 组织侧
共创与验收机制
口径确认会：每个计算类 Skill 上线前，业务部门书面签认公式（例 2/4/5/6 的硬前提）
症候库工作坊：2-3 场，资深订单员用真实数据回放校准诊断报告（例 3）
历史回放对账：预警类上线前用近 3 个月数据回放，AI 判定 vs 实际扣款一致率 ≥99%（例 5）
样张签认：推送文案、报告版式、对账单模板，先签样再批量（例 3/6/9）
标注回流：预估准不准、诊断采纳/驳回，人在环上持续校准（例 3/10）
灰度节奏：先挂件单通道、先单渠道（如高定）、再全量——12 月订货会前完成一轮灰度
例PPT 出处需求线路判定关键前置
| 01 | P3 R3 | 按卖点推荐产品 | 嵌入式 | 直接可实现 | 产品中台属性结构化 + 属性词典
| 02 | P3 R7 | 下单保障缺口 | 嵌入式 | 规则先落纸 | 保障度公式与目标数据源签认
| 03 | P8 | 每周订单诊断报告 | 事件+双端 | 规则先落纸 | 症候库共创工作坊
| 04 | P4 R1/R7 | 未提+预定金测算 | 嵌入式 | 规则先落纸 | 预定金比例表 + SAP 财务授权
| 05 | P4 R3 + P6 | 超期未提扣款预警 | 事件+嵌入式 | 规则先落纸 | 超期口径财务确认 + 历史回放对账
| 06 | P4 R9/R10 | 对账单/余额查询 | 嵌入式 | 直接可实现 | 对账模板签认 + SAP 接口授权
| 07 | P5 R3/R11 | 订单加急转人工 | 嵌入式·写 | 直接可实现 | 加急受理规则 + 账号映射表
| 08 | P5 R9 | 区域出货聚合报表 | 工作台 | 快照先行 | T+1 出货快照 + 权限矩阵签认
| 09 | P6 全页 | 业绩达成推送家族 | 事件 | 直接可实现 | 阈值分级表 + 触达档案清洗
| 10 | P7 | 单品库存周转预估 | 工作台 | 分两期 | 一期移动平均+阈值表；二期时序模型
总结论：PPT 八个页面、约 60 个需求点，没有一个落在框架之外——问答走知识库 RAG，查询走 MCP 实时查，计算走规则 Skill，推送走事件引擎，报告走批处理+受控生成，写动作全部过确认门。真正的实施工作量不在 AI 侧，在两张表上：接口授权表（尤其 SAP 财务，周期最长，本周就该启动）和规则口径表（预定金、保障度、超期、症候库——今天都在老员工脑子里）。这两张表的完成速度，决定 12 月订货会能上线多少。
知名卫浴品牌业务系统 AI 智能层建设方案｜商派 ShopeX 项目提案 · 依据 90 项需求调研、客户《AI 订单助理需求说明》PPT 8 页原文、8/21—9/4 沟通记录与 9/4 内部落地讨论整理 · 2026-09-07
← 返回总览