喜佑天猫国际退款 Agent 产品需求文档（PRD）V1.0

文档状态：开发交付版（V1.0 首版）
业务规则与本期产品方案：已确认
编制日期：2026-10-22
平台与看板名称：天猫国际／喜佑-天猫国际
本期场景：已发货退款、退货退款（审核申请、寄回后退款）
首批店铺：semal海外旗舰店、Cuixo海外旗舰店、LUMO海外旗舰店
启用方式：三店同时启用真实自动处理；本文件不代表已经开发、部署或上线。

0. 文档说明

本文将喜佑退款业务、自动化执行、独立看板、人工接管和验收要求合并为一份完整模块PRD。章节组织沿用既有淘宝退款PRD，业务规则独立，不继承总部的金额、城市、件数、OMS/TMS或退款拒绝规则。

0.1 交付基线

0.2 版本记录

1. 产品概述

1.1 一句话定位

喜佑天猫国际退款Agent每30分钟扫描三家店的已发货退款与退货退款，按固定规则同意退款、提交平台拦截或同意退货；异常与规则外任务转人工，并在独立“喜佑-天猫国际”看板展示执行结果。

1.2 背景与价值

客服当前需在千牛售后工作台与天猫国际后台之间核对金额、物流、原因、时效并完成操作。本期将重复操作固化为可复查、可暂停、可追溯的流程。价值以Agent纯自动完成量、人工完成量、自动化率、退款金额及异常记录衡量；没有可靠历史基线，不编造节省工时或收益目标。

1.3 用户与角色

1.4 本期需求与AI能力概览及CHG索引

本表为唯一CHG索引，后续章节引用上述编号；功能清单仅展开实现职责。

2. 目标与非目标

2.1 本期目标

1. 三家已确认店铺同时启用两类售后的真实自动处理，支持按店铺、场景独立暂停与恢复。
2. 全天每30分钟扫描；等待中的退货物流每30分钟复查；拦截成功未退款按专门30分钟节点复查一次。
3. 已确认规则精确执行；条件缺失、冲突、不可识别或结果未知时不猜测、不重放。
4. 转人工先保留任务与原因，再发一次群通知；成功仅在看板留记录。
5. 独立看板完整展示进入自动化后的任务、阶段进度和最终结果，能够复查原始操作证据。

2.2 非目标与范围边界

• 未发货退款完全排除，不操作、不转人工、不承担异常兜底，不纳入本看板核心任务统计。
• 不处理换货、补寄、维修；不新增自动拒绝、平台申诉或自主协商。
• 不接入总部OMS/TMS拦截工单，不沿用总部500元、长沙、件数等限制。
• 不新增仓库验货、签收或入库作为物流退款前置条件。
• 不新增自动催办、无人响应升级通知，也不因无人响应重新交回Agent执行。
• 不在本期重构其他平台看板，不修改本次提供的公共Demo文件。
• 不指定模型、数据库结构、API路径或部署框架，不以UI演示证明技术已接通。

3. 核心业务规则

3.1 通用原则与优先级

1. 先识别平台、店铺与售后类型；不在范围内直接排除。
2. 先核实平台当前结果：已经退款的售后不再提交退款或拦截，但应核查原Agent任务的必需后置动作；已签收分支的红旗备注未完成时不直接结案，恢复时先读后核查，无法确认则交人工补完。已撤销、完结或人工处理结束的任务不再提交业务动作。已有未明动作先只读核查，禁止再次提交。
3. 本期未完成且当前平台处理剩余时间≤2小时，优先转人工；不继续等待、不自动拒绝。已发起动作保留原台账。
4. 其余按对应场景金额、原因、物流与时效规则判断。退款金额指本次申请金额；审核退货申请用申请退货商品金额，不是整单实付。
5. 本文“元”的50元与1000元门槛均为人民币（CNY／RMB）。金额使用精确金额比较，不能按显示四舍五入值判断。金额非正数、缺失、非人民币、币种无法确认或字段冲突均转人工；不自行换汇，不将外币数值直接与人民币门槛比较。
6. 规则不明确、必要字段缺失、状态冲突或结果未知均停止自动操作并转人工。字段必需性随当前分支确定，不为不需要的物流读取强加依赖。
7. 直接退款只在平台明确退款成功后记退款完成；拦截提交成功不等于退款成功；同意退货成功不等于退款完成。

3.2 店铺白名单

必须可靠唯一识别店铺与订单。平台店铺标识、登录态及名称映射由技术侧受控配置并校验；不能凭相似店名串店。账号密码不写入PRD、任务或日志。

3.3 已发货退款（CHG-02、CHG-03）

实际物流已签收优先进入已签收分支，不受买家“已收货／未收货”自述影响。

已签收小额退款成功后，在主订单插红旗，并在已有备注末尾追加【智能体已退+退款金额】，金额为本次实际退款金额；没有备注直接填写。不覆盖、不删除、不前置原备注。不能仅根据金额小于订单金额自行猜测“部分退款”，需平台可可靠识别的退款范围信息。

3.4 审核退货申请（CHG-04）

其他原因、1000元整及以上、字段缺失或无法确认均转人工。提交说明固定为：

亲亲，您的退货申请已通过，请尽快按照退货地址寄回。退货须知：①退回产品需为未拆封使用产品；②产品瓶身溯源查伪码未破损/刮开；③拒收快递到付

此话术是买家提醒，不表示需等待仓库验货。

3.5 买家寄回后退款（CHG-05）

只检查最新一条轨迹正文，不匹配历史任意轨迹、目的地或签收地址。途经当地即可；不要求仓库到货、签收、入库或验货。同一最新时间存在相互冲突且无法确定顺序的记录，按信息冲突转人工。

无任何物流记录时，从买家填写退货单号时间起算；已有记录时，从最新物流更新时间起算，每次更新重新计算。最新轨迹不匹配时72小时整转人工；最新轨迹匹配时不要求取得无关的72小时起算字段。平台临期和金额边界仍优先。

4. 核心流程

4.1 主流程

flowchart TD
  subgraph AG["退款Agent"]
    A["CHG-01 每30分钟扫描三店两类售后"] --> B{"范围内且可唯一识别？"}
    B -->|否| X["排除范围外；范围内身份不明转人工"]
    B -->|是| C["读取当前结果和既有动作台账"]
    C --> D{"已完成或已有未明动作？"}
    D -->|资金或平台已结束| E["同步资金结果；核查必需后置动作，不重复退款"]
    D -->|动作未明| H["CHG-07 只读核查，转人工，禁止重放"]
    D -->|无| F{"未完成且剩余≤2小时？"}
    F -->|是| H
    F -->|否| G{"场景阶段"}
    G -->|已发货未签收| I["CHG-02 金额校验；退回拒收直退，否则平台拦截"]
    G -->|已签收| J["CHG-03 小于50元部分协商退款"]
    G -->|退货申请| K["CHG-04 原因与商品金额校验，同意退货"]
    G -->|寄回后| L["CHG-05 金额、最新轨迹和72小时校验"]
    L -->|不足72小时且不匹配| W["等待下次复查"]
    I --> R["执行前复核；按动作台账提交一次"]
    J --> R
    K --> R
    L -->|匹配可退款| R
    I -->|规则外或异常| H
    J -->|规则外或异常| H
    K -->|规则外或异常| H
    L -->|超时或异常| H
  end
  subgraph P["千牛与天猫国际"]
    R --> S["返回退款／同意退货／拦截当前结果"]
  end
  subgraph O["看板与人工"]
    S --> T["CHG-08 同步阶段与最终结果；拦截未退30分钟后复查一次"]
    H --> N["CHG-06 人工工单落库，群通知一次"]
    N --> M["客服核查平台结果，处理后在看板关闭"]
    W --> T
    E --> T
  end

节点简写不替代第3章判断表。拦截查询失败立即转人工；正常未退款才等待复查；退款成功后已签收分支继续红旗备注动作。

4.2 操作步骤与系统截图

以下图片用于入口、按钮和字段位置说明，保留原图；不同截图可能来自不同售后，不构成同一订单的完整成功证据。示例中的金额、原因及旧文字不得覆盖第3章。

步骤1 进入售后工作台（CHG-01）

千牛工作台→售后→售后工作台；识别当前店铺与两类售后，排除未发货退款。按当前实际状态进入审核申请或寄回后处理，不能只依赖历史截图的页签名称。

步骤2 核验已发货物流与退款信息（CHG-02、CHG-03）

打开详情，读取售后号、订单号、本次金额、退款范围、申请原因、发货物流与平台剩余时间。明确退回／拒收且金额合规直接退款；已签收走小额部分协商分支。

步骤3 平台创建拦截与查询结果（CHG-02）

进入已授权天猫国际后台→订单管理→以同一订单号查询→核对店铺与订单→创建拦截→确认提交结果。无需在PRD展示登录密码。

拦截成功后立即查退款，正常未退款时30分钟后只读复查一次；仍未退款转人工。图示拦截结果不能替代退款成功回执。

步骤4 已签收部分退款、红旗与追加备注（CHG-03）

核验“部分退款、本次金额<50元、与商家协商一致退款”，提交后核实平台退款成功，再操作主订单备注。图中示例金额不得直接作为50元分支的放行样本。

在下图主订单备注弹窗选择自定义红旗，保留原备注，在末尾追加【智能体已退+退款金额】，点击确定并重新读取确认。图中的旧备注不作为模板。

退款已成功但插旗／备注失败时，保留退款成功事实，任务显示待人工补完，不重复退款。

步骤5 审核退货申请（CHG-04）

进入待审核退货申请，查看准确原因及申请退货商品金额；符合第3.4节时点击同意退货，在确认弹窗提交固定退货说明，重新读取状态确认进入待买家寄回。

步骤6 寄回后物流判断与退款（CHG-05）

进入待收货任务，核对买家退货物流单号，打开物流轨迹，取最新记录正文与时间；按第3.5节执行，不采用客服旧示例中“结构化目的地或签收地址”的描述。

点击后必须重新核实平台退款成功；操作图只说明按钮位置，不证明本期真实退款验收通过。

5. 功能清单

6. 独立看板要求（CHG-08）

6.1 名称与UI

本看板最终接入现有用户服务平台，作为“喜佑-天猫国际”子看板，不单独建设一套平台。业务入口及显示名称均为“喜佑-天猫国际”，不混入总部淘宝列表。沿用指定Demo子看板的白底卡片、浅灰页面背景、山茶红主色 #D9353F、8px圆角、指标层级、图表排列、表格与分页样式。顶部依次为标题、日期与店铺／场景筛选、刷新区域；主区依次为六指标、业务量趋势、双列24小时分布与场景分布、订单明细。

只复用UI和交互模式，不复制Demo随机数据、固定演示日期、平台配置或技术实现。若公共组件存在，研发优先复用；不要求为本期重建公共框架。

6.2 筛选与交互

• 日期预设、起止日期输入和范围日历沿用Demo交互，实际“今日”按北京时间，不固定在演示日期。开始晚于结束或日期无效时提示并保留上一有效结果。
• 店铺：默认全部三店，可单选；场景：默认全部，可选已发货退款、退货退款；退货退款的审核／寄回阶段在明细中区分，不增加第三个独立业务总量。
• 日期按任务首次创建时间归属，包含开始日00:00:00至结束日次日00:00:00之前的任务；结果取当前最新状态。日期、店铺和场景对指标、趋势、场景和明细联动。
• 最近24小时处理分布独立于日期筛选，按查询时刻向前24小时、北京时间小时分桶；仍跟随店铺与场景筛选，明确显示范围。
• 明细保留处理状态与处理结果筛选、分页；条件变化返回第一页。顶层统计不因明细分页变化，明细专属筛选不反向改变顶部指标。
• 刷新同步筛选范围内最新数据，显示最后更新时间；数据加载、空结果、无权限和接口失败必须可区分。请求失败不得把指标显示成0；可保留上次值并明确“更新失败”。
• 不增加“换货”“其他工单”虚假分类；业务类型拆分弹层仅显示本期实际支持的两类，数据支持但当期无记录显示0，维度缺失不补0。

6.3 任务粒度与六项指标

唯一业务任务为“业务线＋店铺唯一标识＋售后编号”。同一退货退款的审核与寄回阶段沿用一个父任务，保留阶段执行记录，不因为审核成功增加一条退款完成。再次扫描、重复通知、重启和阶段流转不新增总量。

人工关闭、买家撤销或平台终止应保留实际结果；无人处理的被动撤销／关闭不算Agent纯自动完成，也不伪装成人工完成。其平台终态与任务业务结果独立记录，必要时由人工核实关闭并留原因。

6.4 图表

两张图均支持鼠标悬浮到对应日期／小时区域查看具体数据：趋势图显示日期（周／月时为实际起止区间）与进入自动化单量；时段分布图显示起止日期时间、Agent纯自动完成、人工完成及合计。零值明确显示0，跨日显示完整日期，移出图表后提示隐藏；切换筛选、刷新或空数据时清除旧提示，不改变统计口径。

趋势粒度采用指定Demo现有规则：所选范围含首尾日≤31天按日、32～180天按周、>180天按月。周按周一至周日、月按自然月；首尾不足完整周／月只统计筛选范围内日期，图上标明粒度。此为已读取Demo的当前交互基准，不另造分桶阈值。

6.5 订单明细

明细最少展示店铺、订单号、售后号、场景／阶段、本次申请金额、任务创建时间、当前处理状态、处理结果、实际完成时间和转人工原因。没有完成时间显示“—”，不以转人工或审核通过时间填充。不设置操作列、查看详情入口或任务详情抽屉。

规则版本、判断值、原动作回执、通知结果与证据仍作为执行记录保留，不在本看板增加详情界面。与任务无关的客户信息不另行采集。

本看板不提供人工接单、填写处理结果或关闭操作。人工仍按群反馈在现有业务系统核查和处理；完成结果回写方式作为技术联调项，不自行新增界面。只有取得可信的人工完成记录才计入人工完成，不能以群通知或接单代替。已人工接管任务不会因下轮扫描重新自动执行。

6.6 运行控制

本看板不提供运行设置、店铺／场景启停弹窗或配置入口。店铺／场景启停能力保留在既有管理侧，具体接入由技术评审确认，不在本期看板新增管理界面。登录健康与最近更新作为只读运行信息，不占六项业务指标。暂停后禁止新增不可逆提交，已提交未明动作仅核查，不重复执行。范围外系统OMS/TMS故障不得阻断本业务。

7. 核心功能详细需求

7.1 扫描与复查（CHG-01）

全天每30分钟扫描白名单店铺的两类未完结售后，覆盖审核申请和寄回阶段。无任务只记扫描日志，不创建空工单；店铺无法登录时记录运行异常，不构造虚假售后。按平台剩余时间由短到长处理，时间缺失且无法确认当前截止时转人工。

同一店铺、场景的上轮未结束时不得并发重复扫描。拦截复查以成功提交时间+30分钟为节点，不得因固定扫描时刻额外延长一个周期；需调度到期查询。停机跨过到期时间后，恢复时先核查现状与临期，不能重新起算等待时间。

7.2 字段读取与判定（CHG-02至CHG-05）

按分支读取最低必需字段；截图文字、页面提示与可用结构化字段相互冲突时不猜测。不得从聊天或历史备注自行放宽金额、原因、物流规则；识别到需解释的特殊约定时交人工。对应规则版本与判断快照保存在任务中。

退货审核通过后保留父任务并等待寄回；买家尚未填写物流单号，不伪造填写时间启动72小时计时。后续仍按真实平台状态与临期规则观察，必要信息无法取得且无法可靠判断时转人工。

7.3 不可逆动作（CHG-07）

每次同意退款、提交拦截、同意退货或修改红旗备注前，重新核对店铺、订单、售后、当前状态、金额、相关条件、场景开关、权限和剩余时间。数据已改变则重新判断，不使用旧快照提交。状态守卫按动作区分：退款与拦截要求售后仍可执行对应动作；退款后的红旗备注以已确认退款成功、主订单唯一、该后置动作尚未完成为前提，不再要求售后处于可退款状态。已退款进入临期也不重新发起资金动作，后置步骤无法安全完成时交人工。

动作先持久化准备记录，进入提交阶段后立即标记“已发起／结果待确认”，不能等成功页面出现后才建记录。每个动作有唯一业务键；至少由父任务、阶段、动作类型组成，同意退货与退款互不覆盖。平台退款结果关联售后，订单备注关联主订单，防止串写。

提交失败但可证明未发出请求时才允许重新准备；请求已发出或无法确认是否发出时禁止自动重试，只读核查并转人工。红旗备注也需先读后写，重查已存在相同动作记录时不重复追加，不以文本相似猜测另一个退款动作已完成。

7.4 部分成功与人工接管（CHG-03、CHG-06、CHG-07）

7.5 AI产品契约

Agent负责读取、固定规则判断、授权范围内工具调用和结果核查；不自由决定退款金额、不生成新的退货话术、不自行改写原因或推断物流完成。输入为平台当前字段、规则版本、店铺配置与既有动作；输出为分支、动作、结果、原因码及可核查证据。

不确定或解析失败停止动作并转人工；资金动作以平台结果验收，不以模型回答“成功”验收。无跨店共享客户记忆或自行学习修改规则功能；不引入RAG、模型选型、成本阈值等未确认范围。识别与工具方案由研发确认，但不能降低确定性约束。

8. 数据规范

8.1 字段产品契约

字段名为建议映射，不是指定数据库表结构。金额为精确十进制、保留平台原始币种，时间保存可明确转换为北京时间的时间戳；缺失不得写0冒充有效业务值。

8.2 数据边界

业务任务与动作日志按业务线隔离，授权内可查三家店；其他总部业务不得出现在喜佑筛选与统计。历史总部任务不迁入喜佑，喜佑新增流程不得回写总部规则。凭据通过受控配置交接，不记录Cookie、Token或密码。原图使用授权不等于日志和群消息可无限传播个人信息；群消息仅带处理所需字段，截图按授权范围保留。

9. 状态与看板映射

主任务、阶段、资金动作、人工、通知分轴保存，不用单一“成功”覆盖全流程。

已完成任务不可由重复扫描退回待处理；资金成功不等于父任务已完成，已签收退款后需继续核查红旗备注，重启不能跳过后置动作；阶段成功不能覆盖父任务尚未完成状态。completion_mode建议为none／pure_auto／manual，人工标识一经发生保留。handoff_status为none／pending／accepted／closed；notification_status为not_sent／sending／sent／failed。动作状态为prepared／submitting／succeeded／failed／unknown，unknown不允许重放。

10. 转人工规则（CHG-06）

10.1 原因码

同任务可保存多个原因，通知以当前主要原因和已执行动作说明；主要原因优先保留结果未知、临期等影响接管的风险，不因多原因发多条业务通知。

10.2 钉钉通知

@使用受控用户标识映射并在联调验证，不根据姓名猜ID。同一父任务首次进入人工队列时形成一个通知事件，重复扫描、原因更新和无人响应不新增通知。发送失败可针对同一事件做技术防重重试，不是新增催办；发送结果未知先查投递结果，不能盲发第二条。最终失败在看板显著展示，由人工监控。

通知模板：

【喜佑-天猫国际｜需人工处理】
店铺：{store_name}
订单号／售后号：{order_id}／{aftersale_id}
场景／阶段：{scene}／{stage}
本次申请金额：{refund_amount} {currency}
主要原因：{handoff_reason}
已执行动作与结果：{action_summary}
平台剩余处理时间：{remaining_time}
注意：请先核查既有退款／拦截结果，避免重复提交。
看板入口：{dashboard_link}
@三位指定人员

10.3 人工闭环

客服核查平台状态与既有台账，在现有业务系统处理后保留结论、是否退款、实际金额、完成时间与操作人；可信完成记录回写看板，不在本看板新增接单或关闭入口。无需通过群回复自动识别结案。不存在已确认的接单SLA，不在本期添加新时限；值班及资金核对安排作为上线准备，不用“发通知成功”替代人工完成。

11. 异常与恢复策略（CHG-07）

暂停不等于撤销已发送平台请求。恢复必须核查未明动作、当前权限、规则版本与店铺身份，管理员执行且保留恢复记录；业务原因转人工的任务不自动释放回执行队列。

12. 权限与安全

最终角色映射与现有权限体系由技术评审落地。未授权访问返回无权限，不泄露其他业务线任务。三店真实动作启用前完成账号权限核验与业务负责人确认；具体上线时间和审批记录另行留存，不把本PRD完成当作平台资金操作已执行。

截图存储位置、访问控制、保留期限、到期删除与下载审计由现有制度和技术能力确认。已获PRD原图使用授权；不将密码、Token、Cookie写入任何交付文档或群消息。

13. 非功能性需求

13.1 可靠性

同一售后不得重复退款、重复拦截或因阶段切换重复计数；任务、动作与通知防重可在重启后继续生效。平台结果无法确认时不得显示纯自动完成。不能以一张示例截图替代真实动作回执。

13.2 可观测性

记录每轮扫描起止、店铺场景、发现数、排除数、判断结果、提交动作、结果核查与通知结果。日志关联父任务、动作键、规则版本、操作者和时间；可定位系统异常与业务转人工的区别。不得写入凭据。

13.3 调度与兼容

30分钟为业务调度周期，72小时与平台临期均采用实际时间戳比较；并发、超时、容量和接口限流策略由研发确认，不编造性能数值。未完成扫描不并发重复启动，同店跨周期任务由执行锁约束。优先保证结果未知动作核查与临期接管。

新版UI支持Demo已有桌面布局与窄屏重排模式；具体浏览器矩阵沿用现有项目支持范围，联调确认。无图表数据或图表加载失败时，明细与异常状态仍可辨识，不伪造展示。

14. 验收标准与开发自测

14.1 开发自测职责与前提

当前无独立测试人员，本章全部业务、边界、异常、权限、看板和上线前验证用例由开发人员自测执行，问题修复后由开发复测并保留结果与证据。产品／客服负责业务规则和业务结果确认，不设置独立测试岗位或测试交接环节。

除用例指定变化外，使用授权测试售后，店铺与场景启用，必要字段完整、无人工接管、剩余时间>2小时、无未明动作。每条记录输入快照、操作前后平台状态、动作提交次数和看板结果；真实资金动作仅在另行受控测试安排下执行。

14.2 业务正常与边界

14.3 异常、防重与权限

14.4 看板与统计

以上用例中的“／01”等为CHG-01简写，均指第1.4节已登记编号。

14.5 上线门槛

三店身份与权限核验、千牛与天猫国际真实页面联调、动作防重及只读恢复、已签收红旗备注、两阶段退货、30分钟复查和临期接管均需通过。群号、逐一@映射、一次通知防重、人工完成结果同步与隔离统计需验证。账号凭据、资金核对责任、应急值班、暂停恢复与证据保留安排需在上线前落实。未完成项只标待联调／待验证，不写已上线。

15. 上线与运营

15.1 首批方式

三家店同时启用已发货退款和退货退款真实自动处理，不新增影子模式为本期必经运行阶段。具体上线时间由业务与研发安排；技术验收不替代资金动作授权与上线确认。各店、各场景必须可独立暂停。

15.2 应急处置

发生误退款、重复提交、平台风控、定位失效、结果未知或证据不可追溯时，停止受影响范围新动作并保留既有记录。管理员与客服负责人核查后恢复，不允许通过清空台账规避防重。误退款按公司已有追偿、申诉或损失处置流程办理；责任角色与实际流程上线前落实，不在此编造。

15.3 运营口径

核心六指标按第6章统计，额外运行明细支持查看：

上述辅助项可在运行记录或既有统计入口查询，不新增一套与Demo冲突的顶部指标。平台显示退款成功只代表售后平台结果，不代表买家支付账户到账已核验。