拼多多退货退款 Agent 产品需求文档（PRD）V1.0

文档状态：待研发评审
业务规则状态：已确认
版本：V1.0
编制日期：2026-08-10
适用平台：拼多多
金额边界：本次售后申请退款金额 >=500元，转人工处理
首批试运行店铺：PANAPOPO医疗保健官方旗舰店、松藤Yazc海外好物馆、PANAPOPO医疗器械官方旗舰店
事实优先级：规则确认稿 > SOP > 截图证据

1. 产品概述

1.1 一句话定位

拼多多退货退款 Agent 是接入现有拼多多工单自动化系统的新增业务场景，用于定时扫描“退货退款-待商家确认收货”售后单，按确定性规则自动完成低风险退款，并将不满足条件或无法可靠处理的订单转交人工。

1.2 背景

当前拼多多退货退款需要客服进入商家后台，逐单查看退款金额、退货件数、退货物流方向、物流更新时间和平台处理倒计时，再决定自动退款或人工核查。该流程规则明确但操作重复，适合复用现有拼多多浏览器自动化、钉钉通知和运营看板能力。

现有业务 SOP 已确认以下关键事实：

• 本期处理类型为“退货退款”。
• 平台超过 7 天未处理可能自动同意退款。
• 同一订单可能产生多次售后，售后编号是单次售后的唯一标识。
• 低风险订单可直接确认退款，高金额、多件、物流异常和临近超时订单需要人工处理。
• 退款成功后，货款、优惠券和红包由平台按原支付路径处理，Agent 不执行额外资金操作。

1.3 用户与角色

1.4 产品价值

1.5 当前基线

以下经营基线暂无可靠数据，不能在本文中编造。上线后由看板按“退货退款”业务场景独立统计：

• 每日待处理退货退款单量；
• 当前人工平均单笔处理时长；
• 当前超时自动退款单量；
• 当前人工误操作或重复处理量；
• 自动退款覆盖率和人工兜底比例。

2. 目标与非目标

2.1 V1.0 目标

1. 在现有拼多多工单自动化系统中新增“退货退款”业务场景。
2. 对 3 家试点店铺全天定时扫描退货退款售后单。
3. 对同时满足全部自动退款条件的售后单执行真实退款。
4. 对不满足条件、信息缺失或系统异常的售后单停止自动化并发送钉钉转人工通知。
5. 复用现有工单中心、运行日志、转人工、验证定位、店铺管理和运营总览能力。
6. 保证同一售后单不会被 Agent 重复提交退款。
7. 保留场景级紧急暂停能力。

2.2 非目标

• 不处理拼多多仅退款、部分退款、换货、补寄、维修、纠纷、平台介入和仲裁。
• 不处理抖音、天猫或其他平台退款。
• 不自动拒绝任何退款申请。
• 不新增独立运营看板、独立导航或独立店铺管理体系。
• 不重新建设 PDD 登录、钉钉消息和验证码处理能力。
• 本场景不查询或登记 OMS，也不依赖 TMS；OMS、TMS 异常均不得阻塞本场景。
• 不等待买家支付账户实际到账，平台售后状态成功即视为 Agent 操作完成。
• 不建设影子模式或分阶段放量流程。

3. 核心业务规则

3.1 规则原则

1. 自动退款必须同时满足全部放行条件。
2. 任一条件不满足、字段无法可靠读取或执行状态不明确时，Agent 必须停止自动化。
3. 转人工不等于拒绝退款。V1.0 中 Agent 不得点击“拒绝退款”。
4. 退款属于不可逆高风险操作，最终执行必须使用确定性规则，不允许大模型自由推断或补全缺失字段。
5. 所有金额、件数和时间边界按下表精确判断。

3.2 自动退款放行条件

只有同时满足下列全部条件，才允许进入自动退款执行：

3.3 边界定义

• 金额 499.99元可继续判断，500元必须转人工。
• 本次售后申请退货 4件可继续判断，5件必须转人工。
• 物流最新节点距当前 72小时整时，按“≥72小时”转人工。
• 平台剩余处理时间 72小时整时，按“≥72小时”可继续判断。
• “发往长沙”只要求退货物流轨迹中出现“长沙”字段，不要求已到达长沙、物流签收或仓库确认到货。
• 本场景不访问 OMS，仓库信息不参与自动退款判断、转人工通知或看板健康检查。
• “最新物流节点”取平台当前展示的最后一条有效物流轨迹时间，不按创建售后时间或上传物流单号时间计算。
• 同一订单可有多个售后单，必须按售后编号分别处理。
• 时间计算统一使用北京时间（Asia/Shanghai）和经过时间同步的系统时间源；同一轮判断及执行前复核必须分别使用单一校验时刻。

3.4 范围与状态映射

3.4.1 【本次更新】首批试点店铺

店铺名称与店铺 ID 必须一一匹配。账号、密码、手机号等凭据不写入 PRD、普通配置或日志；上线配置应通过现有受控方式提供。

3.5 规则优先级

从高到低依次为：

1. 已完成、已撤销或不在试点范围：跳过。
2. 重复任务、并发锁、售后状态变化：阻止执行。
3. 必要字段、PDD 或页面异常：转人工。
4. 金额、件数、物流方向、物流 72 小时、处理倒计时规则：转人工或放行。
5. 全部条件满足：执行自动退款。

4. 核心流程

flowchart TD
    A[每30分钟触发扫描] --> B[读取3家试点店铺白名单]
    B --> C[进入拼多多待处理退货退款列表]
    C --> D[按剩余处理时间从短到长读取]
    D --> E{店铺和场景是否启用}
    E -->|否| F[跳过并记录]
    E -->|是| G[按店铺ID+售后编号加锁]
    G --> H{是否已处理或正在处理}
    H -->|是| I[跳过重复任务]
    H -->|否| J[读取售后、金额、件数、物流和倒计时]
    J --> L{字段和页面是否正常}
    L -->|否| M[生成中风险人工工单]
    L -->|是| N[执行确定性规则判断]
    N --> O{全部自动退款条件满足}
    O -->|否| P[生成高风险人工工单]
    O -->|是| Q[持锁重读全部输入并重算R01-R09]
    Q --> R{全部条件仍满足}
    R -->|人工已完成| S[标记人工已完成并跳过]
    R -->|状态变化未完成| T[高风险转人工]
    R -->|是| U[留存证据并持久化执行意图]
    U --> V[点击确认退款]
    V --> W{页面明确显示退款成功/售后完结}
    W -->|是| X[记录自动退款成功]
    W -->|否| Y[重新查询售后状态]
    Y --> Z{复查后是否已成功}
    Z -->|是| X
    Z -->|否或不明确| AA[标记待验证并高风险转人工]
    M --> AB[发送钉钉转人工通知]
    P --> AB
    T --> AB
    AA --> AB
    AB --> AC[等待人工处理]
    AC --> AD[后续扫描发现人工已完成]
    AD --> AE[关闭人工任务并记录结果]

4.1 当前人工操作流程（SOP）

当前客服在拼多多商家后台按以下路径处理退货退款：

步骤1：进入售后工作台

进入“商家后台 → 售后工作台”，在“待商家处理”中选择“退货退款”，进入待处理售后列表。

步骤2：查看售后详情

打开待处理售后单，查看售后编号、本次退款金额、退货件数和退货物流单号等本次处理所需信息。

步骤3：查看退货物流

切换到“退货物流”，查看最新物流轨迹。物流轨迹中出现“长沙”字段即可进入退款确认，不要求物流已到达或已签收长沙。

步骤4：确认退款

确认符合第 3 章自动退款规则后，点击“同意退款”，并在确认弹窗中完成退款操作。

异常分支： 物流轨迹未显示发往长沙，或任一自动退款条件不满足时，不执行退款，转人工处理；当前流程不点击“拒绝退款”，也不在自动任务内持续等待物流更新。

图片来源：《拼多多退货退款SOP_项目基线0730.xlsx》“操作步骤-退货退款”。4张图片分别对应售后入口、售后详情、退货物流和确认退款，保留 SOP 原始清晰度，仅用于公司内部需求评审和开发交接。图片仅说明现有页面路径与关键操作位置，不覆盖第 3 章的 Agent 业务规则。

5. 功能清单

拼多多退货退款 Agent V1.0
├── P0 业务场景接入
│   ├── 新增“退货退款”场景类型
│   ├── 三家试点店铺场景白名单
│   └── 场景级启停开关
├── P0 售后任务扫描
│   ├── 全天每30分钟定时扫描
│   ├── 按处理倒计时排序
│   └── 售后唯一键去重与加锁
├── P0 数据读取
│   ├── PDD售后字段读取
│   └── 退货物流轨迹读取
├── P0 规则决策
│   ├── 金额与件数判断
│   ├── 长沙物流方向判断
│   ├── 两类72小时时间判断
│   └── 标准转人工原因码
├── P0 自动退款执行
│   ├── 执行前状态复核
│   ├── 确认退款
│   ├── 成功状态核验
│   └── 结果不明确时禁止盲目重试
├── P0 人工兜底
│   ├── 高/中风险分级
│   ├── 钉钉群通知
│   ├── 单次通知去重
│   └── 人工完成后自动闭环
├── P0 看板复用
│   ├── 运营总览新增业务场景
│   ├── 工单中心场景筛选
│   ├── 运行日志与转人工记录
│   └── 验证定位复用
└── 非本期
    ├── 其他平台与售后类型
    ├── 自动拒绝退款
    ├── 新建独立看板
    └── 影子模式

6. 现有看板改造要求

6.1 改造原则

• 不新增侧边导航和独立页面。
• 将“退货退款”作为现有工单模型中的第 4 个业务场景接入。
• 顶部汇总指标继续统计全部场景，同时支持通过现有店铺、日期和业务场景条件查看退货退款数据。
• 场景展示名称固定为“退货退款”；内部场景代码由开发按现有命名规范确定并在技术评审时记录。
• 本场景仅依赖 PDD、钉钉和现有看板，不查询或登记 OMS，也不依赖 TMS。健康检查和执行前置条件必须按场景依赖判断，不能因 OMS 或 TMS 异常暂停退货退款。

6.2 运营总览

“业务场景分布”从 3 个场景增加为 4 个场景，新增“退货退款”一行，至少展示：

• 工单总量；
• 自动退款成功量；
• 人工协助量；
• 自动化成功率；
• 尚未成功量。

“处理结构”与顶部指标自动纳入退货退款数据，不另建指标卡。

6.3 工单中心、日志与转人工

• 工单中心支持按“退货退款”筛选。
• 工单详情展示第 8 节定义的核心业务字段、规则命中结果和证据。
• 运行日志记录扫描、加锁、读取、判断、执行、复核、通知和关闭全过程。
• 转人工列表展示工单问题、风险等级、通知状态、人工处理状态和关闭时间。
• 验证定位继续用于“退款执行结果未知”等待核实任务，不承载影子模式。

6.4 关键页面线框图

┌────────────────────────────────────────────────────────────────────┐
│ 店铺筛选 | 日期筛选 | 业务场景筛选 | 实时连接 | 刷新 | 场景启停      │
├────────────────────────────────────────────────────────────────────┤
│ 工单总量 | 自动化成功 | 人工协助 | 处理中 | 等待中 | 异常 | 待验证  │
├─────────────────────────────────────┬──────────────────────────────┤
│ 业务场景分布                        │ 处理结构                     │
│ 在途无理由退款                      │ 自动化成功 / 人工协助 / 失败 │
│ 已发货无轨迹退款                    │                              │
│ 异常网点预警                        │                              │
│ 退货退款  ← 本期新增                │                              │
├─────────────────────────────────────┴──────────────────────────────┤
│ 店铺运行健康：每家店铺按场景检查 PDD 依赖，不检查 OMS / TMS          │
└────────────────────────────────────────────────────────────────────┘

7. 核心功能详细需求

7.1 任务扫描与排序

触发方式：系统全天运行，每 30 分钟触发一次，扫描频率作为场景配置项保留。

扫描范围：

• 【本次更新】仅扫描 3.4.1 节已确认的 3 家店铺及其上线前校验通过的店铺 ID；
• 仅扫描拼多多“退货退款-待商家确认收货”状态；
• 按平台剩余处理时间从短到长处理；
• 店铺未启用、场景暂停或 PDD 登录不可用时，不进入自动退款判断。

扫描结果：

• 无任务：记录本次扫描完成，不创建空工单；
• 发现任务：生成或复用唯一任务；
• 同一售后已存在未关闭任务：不重复创建；
• 已由人工或平台处理完成：标记跳过并记录最新状态。

7.2 字段读取

Agent 必须读取并结构化保存以下信息：

• 店铺 ID、店铺名称；
• 售后编号、订单号；
• 售后类型、售后状态；
• 本次售后申请退款金额；
• 本次售后申请退货件数；
• 退货物流单号；
• 完整物流轨迹及最新节点时间；
• 平台剩余处理时间。

读取原则：

• 页面没有展示、字段为空或无法可靠识别时，不允许使用默认值猜测；
• 拼多多退货退款不访问 OMS，不读取或保存仓库字段；
• 多物流单号、异常格式或无法确定最新有效节点时，按“信息识别失败”转人工。

7.3 确定性规则判断

规则判断必须输出：

• 每条规则的输入值；
• 每条规则的通过/不通过结果；
• 最终决策：自动退款、转人工或跳过；
• 命中的标准原因码；
• 规则版本和判断时间。

同一售后同时命中多个转人工原因时：

1. 风险等级取最高等级；
2. “工单问题”展示优先级最高的主原因；
3. “转人工原因”列出全部命中事实；
4. 只发送一条钉钉消息。

7.4 自动退款执行

执行前必须再次读取：

• 店铺白名单和场景开关；
• 售后编号；
• 当前售后状态；
• 本次退款金额；
• 本次退货件数；
• 退货物流轨迹及最新节点时间；
• 平台剩余处理时间；
• 平台确认退款按钮是否可用。

执行规则：

1. 在持有任务锁的状态下，以同一校验时刻重新计算 R01-R09，而不是只比较部分字段。
2. 任一条件不再满足时，禁止点击退款，并按最新条件跳过或转人工。
3. 留存执行前页面截图、规则判断快照和场景开关状态。
4. 生成唯一 attempt_id，先持久化“不可逆操作准备执行”的执行意图，再点击“确认退款”。
5. 点击后立即将执行阶段更新为“已发起，结果待确认”，不得等到页面成功后才首次落库。
6. 页面明确显示“退款成功”或“售后完结”，记录自动退款成功。
7. 页面超时、断网、进程崩溃或结果不明确时，恢复流程必须先按售后编号重新查询平台状态，不得直接重放点击动作；任何遗留 prepared 记录也必须视为“可能已点击”。
8. 复查仍无法确认结果时，状态改为“待验证”，同步发起高风险人工接管。
9. Agent 不检查买家账户是否实际到账。

7.5 幂等、并发与状态变化

任务唯一键：店铺ID + 售后编号。

并发要求：

• 同一唯一键同一时间只允许一个执行实例持有锁；
• 锁实现方式和超时时间由技术方案确定，但不得允许锁超时后直接重复退款；
• 人工和 Agent 可能同时打开售后单，因此点击前必须复核平台状态。
• 每次不可逆执行必须有唯一 attempt_id 和持久化执行阶段；任务恢复、锁过期或进程重启后，只要存在 prepared/submitted/unknown 任一执行记录，均只允许查询平台结果，不允许新建退款尝试或再次点击。查询后仍无法确认时进入待验证并转人工。

状态变化处理：

7.6 人工兜底与任务生命周期

转人工后：

1. 自动化流程立即停止；
2. 任务状态改为“待人工处理”；
3. 同一售后单只发送一次钉钉通知；
4. Agent 后续只检查是否已由人工处理完成，不再自动退款；
5. 发现人工处理完成后自动关闭任务并记录实际结果；
6. 只有授权人员主动重置任务，才允许重新进入规则判断。

人工接单和处理时效复用现有拼多多工单的人工协作 SLA；若现有系统未配置 SLA，业务必须在上线前提供。系统不重复发送同一钉钉消息，但应在现有看板持续展示未接单和临近平台截止时间的人工任务。

待验证状态守卫：

• pending_verification 任务不得直接重置为可自动执行；
• 必须由授权人员先在拼多多平台确认“未退款”，上传或关联核验凭证，并记录核验人、核验时间和结论；
• 若人工确认已退款，直接关闭任务并记录实际完成方式。

7.7 场景开关与紧急暂停

• 支持全局“退货退款”场景开关；
• 支持按店铺启停该场景；
• 关闭开关后不得创建新的自动退款执行任务；
• 正在执行的任务应在下一次不可逆操作前检查开关状态；
• 出现误退款、重复提交、平台风控或页面异常时，运营可立即暂停该场景；
• 暂停后已有人工任务继续保留并可跟踪关闭。

自动熔断建议（待业务/技术评审，不属于当前已冻结规则）：

当前已确认能力为“场景级/店铺级紧急暂停”。下表是对直接上线真实退款的安全增强建议，是否启用及阈值须在评审后单独确认；未确认前不得写成现行业务规则。

如后续启用自动熔断，熔断不得删除或关闭已有任务；恢复必须按第 12.1 节权限矩阵执行并记录证据。

8. 数据规范

8.1 核心字段

8.2 数据最小化

• 业务判断不需要的买家姓名、手机号、详细地址、聊天原文不得写入普通运行日志。
• 页面截图可能包含敏感信息，必须沿用现有系统的受控访问权限和存储策略。
• 账号、密码、Cookie、Token 和钉钉密钥不得出现在工单字段、日志或截图说明中。
• 钉钉消息只允许发送到公司批准的现有内部群，群成员和机器人权限沿用现有配置并在上线前核验。
• 截图应裁剪到完成判断所需的最小区域；账号、Cookie、Token、买家手机号和详细地址等区域不得入图或必须脱敏。
• 日志、截图和导出文件必须使用现有内部存储、传输加密、访问控制和下载审计能力。
• 日志和截图保留时间复用现有拼多多工单系统配置；若现有系统无明确的保留期限和到期删除策略，则视为上线阻塞项，必须在技术评审中补齐。

9. 状态与看板映射

不新增一套看板状态体系，但数据模型必须把“主任务状态、人工接管状态、钉钉通知状态”拆成三条状态轴，避免结果未知与人工接管互相覆盖。

影子模式不在本期范围，“待验证”只用于退款执行结果不明确的真实任务。

状态轴规则：

• task_status=pending_verification 时，可以同时存在 handoff_status=pending/accepted；
• ding_status独立记录未发送、发送中、发送成功、发送失败，不改变业务判断结果；
• 只有平台结果明确或人工完成核验后，pending_verification 才允许关闭；
• 看板“待验证”按主任务状态统计，“其中人工协助”按人工接管状态统计，同一任务可以同时进入两个指标，但工单总量只计算一次。
• 未经人工介入即由 Agent 明确核验成功的任务，完成方式为 pure_auto；进入人工接管或待验证后再由人工完成/确认的任务，完成方式统一为 manual_assisted，不得同时计入纯自动完成。

10. 转人工规则

10.1 风险分级与原因码

10.2 钉钉通知

【本次更新】通知配置：

固定 @ 人员：张欣（子宁）、易嘉豪（狄云）、何紫辉（婉安）、陈姣群（梨花）、蔡妍（今夏）、彭心雨（听竹）、彭玉洁（青顾）、曾昶（霜寒）、刘敏（秦桑）、崔志文（行云）。

人员显示名称为业务确认口径；开发应复用现有钉钉成员映射或配置对应用户标识，不得使用手机号、账号密码等敏感信息进行明文配置。人员调整属于通知配置变更，不要求修改业务判断代码，但必须记录变更前后值和确认人。

标题固定为：拼多多退款工单转人工

消息模板：

拼多多退款工单转人工
自动化流程已停止，请人工核查并继续处理。

工单信息
• 店铺：{store_name}
• 工单问题：{issue_type}
• 售后编号：{aftersale_no}
• 订单号：{order_no}
• 物流单号：{logistics_no}

转人工说明
• 转人工原因：{handoff_reason}
• 风险等级：{risk_level_cn}

{configured_mentions}

字段规则：

• 工单问题填写标准分类名称；
• 转人工原因填写实际命中值，不只写原因码；
• 同时命中多个原因时合并为一条说明；
• 风险等级显示“高”或“中”；
• 自动退款明确成功时不发送钉钉消息；
• 转人工和系统异常通知必须发送至群号 189925002005，逐一 @ 已确认的 10 位人员，不得 @所有人或额外 @ 群内其他成员；
• 拼多多退货退款不读取仓库信息，转人工消息不展示仓库字段；
• 售后编号用于区分同一订单的多次售后，在原有字段基础上新增，不删除原模板字段；
• “退款执行结果未知”必须在转人工原因中明确提示“先核查平台状态，禁止直接再次退款”；
• 消息发送成功后保存平台返回标识，避免重复发送；
• 必须先持久化人工工单，再发送钉钉通知，防止通知失败导致任务丢失；
• 发送失败时使用同一消息幂等标识重试，优先复用现有重试次数和间隔；若现有系统没有明确策略，由技术评审补充可配置的重试上限和退避间隔；
• 达到最终失败条件后，在现有看板产生高优先级告警，由授权人员决定是否暂停该店铺；恢复前必须确认钉钉发送能力正常。
• 因业务已确认仅使用钉钉群作为人工通知渠道，最终发送失败时不再调用其他外部渠道；上线前必须指定负责监控现有看板告警的运营/系统管理员值班角色，并在看板中记录告警确认状态。未指定值班角色时不得上线真实退款。

11. 异常与恢复策略

禁止事项：

• 禁止在结果未知时直接再次点击退款；
• 禁止因页面元素相似而推测按钮；
• 禁止缺失金额、件数、物流或倒计时仍自动退款；
• 禁止自动点击拒绝退款；
• 禁止 TMS 异常影响本场景；
• 禁止将真实订单数据复制到未批准的外部 AI 或第三方服务。

12. 权限与安全

1. 【本次更新】只允许 3.4.1 节已确认店铺名称及其校验通过的店铺 ID 启用真实退款权限。
2. 场景开关、店铺白名单和重置人工任务操作必须受角色权限控制。
3. 退款账号权限、登录态和密钥沿用现有安全管理，不写入 PRD、日志或配置页面明文。
4. 自动退款操作必须可追溯到店铺、售后编号、规则版本、执行实例和时间。
5. 自动退款前、执行结果和异常页面均需留存证据。
6. 人工重置任务必须记录操作人、时间和原因。
7. 页面或平台规则发生变化时，应先暂停场景再评估，禁止在未知页面继续真实退款。
8. 业务已确认三家试点店铺直接上线风险，并于 2026-08-10 补充确认具体店铺名称和通知配置；该事实不替代系统的幂等、审计和紧急暂停要求。

12.1 权限矩阵

权限名称与现有系统角色不一致时，可在技术方案中映射，但不得降低上述最小权限和审计要求。

12.2 上线风险接受记录

本轮已确认“三家试点店铺直接开放真实自动退款、不经过影子模式”，但上线前仍需形成独立、可审计的风险接受记录。记录至少包含：

• 确认日期和审批责任角色（无需在 PRD 中写个人姓名）；
• 三家试点店铺范围；
• 已知风险：误退款、重复退款、页面变化、账号风控、钉钉通知失败和结果未知；
• 已具备的控制：人工兜底、幂等、执行前复核、证据留存和紧急暂停；
• 证据位置或会议/审批记录编号。

该记录当前状态为待业务归档；归档完成是上线前置条件，不能仅以 PRD 内文字替代审批证据。

13. 非功能性需求

13.1 可靠性

• 重复退款提交数必须为 0。
• 同一售后单的钉钉转人工消息不得重复发送。
• 自动退款明确成功的任务不得发送钉钉通知。
• 转人工和系统异常通知必须发往已确认群，并仅逐一 @ 已确认的 10 位人员。
• 退款结果未知时不得自动重试不可逆操作。
• 任一必要依赖不可用时，系统必须安全停止而非继续猜测。

13.2 可观测性

• 每轮扫描记录开始时间、结束时间、店铺、发现任务数和处理结果。
• 每个任务记录完整状态流转和规则命中明细。
• 运营总览可查看该场景的工单量、自动成功、人工协助、异常和待验证。
• 支持按日期、店铺、业务场景、售后编号、订单号和状态检索。

13.3 性能与调度

• 默认每 30 分钟扫描一次，全天运行。
• 扫描必须在下一调度周期前完成；若无法完成，系统不得并发启动相同店铺的重复扫描。
• 实际并发数和单轮超时由技术评审根据现有系统容量确定。

13.4 兼容性

• 复用现有拼多多工单系统支持的运行环境和浏览器版本。
• PDD 页面结构变化必须可被监控和告警。
• PDD、钉钉和看板接口按现有能力接入，不新增不必要的第三方依赖。

14. 验收标准

14.1 业务规则用例

除指定变量外，以下用例均假设：试点店铺已启用、售后类型正确、字段完整、PDD 正常、未被重复处理。

14.2 幂等与异常用例

说明：什么是幂等？ 同一店铺、同一售后编号的任务，即使被定时扫描重复发现、被多个执行实例同时获取，或在网络超时、进程重启后再次恢复，系统也只能真正发起一次退款。实现时以“店铺 ID + 售后编号”作为任务唯一键；如果点击退款后的结果不明确，只能先查询拼多多平台的最终状态，仍无法确认时必须转人工，禁止再次点击“同意退款”。

14.3 看板验收

• 运营总览的业务场景分布新增“退货退款”。
• 顶部汇总和处理结构正确纳入退货退款数据。
• 工单中心、运行日志、转人工和验证定位均可按“退货退款”筛选。
• 三家试点店铺可独立启停该场景。
• 店铺健康检查对本场景只校验 PDD，不校验 OMS 或 TMS。
• “待验证”只统计真实退款结果不明确的任务。

14.4 上线验收门槛

本期按业务决定直接向 3 家试点店铺开放真实自动退款，不设置影子模式和样本准确率门槛。上线前仍必须满足：

1. 本文 P0 功能全部完成并通过测试；
2. A01-A12、B01-B21 验收用例全部通过；
3. 三家店铺 ID、退款权限和场景开关配置完成；
4. PDD、钉钉和现有看板联调通过；
5. 唯一键、执行前复核、结果未知禁止重试和紧急暂停能力可用；
6. 【本次更新】钉钉群名称、群号、成功不通知和固定 @10 人配置验证通过；
7. 真实退款操作日志和证据截图可查询；
8. 权限矩阵、紧急暂停和待验证状态守卫可用；
9. 日志、截图和钉钉数据的访问、脱敏、保留及删除策略已验证；
10. 金额核对责任角色和误退款处理路径已明确。

15. 上线与运营

15.1 上线方式

• 【本次更新】PANAPOPO医疗保健官方旗舰店、松藤Yazc海外好物馆、PANAPOPO医疗器械官方旗舰店同时启用“退货退款”场景；
• 上线即执行真实自动退款；
• 不运行影子模式；
• 业务在上线前提供准确店铺 ID；
• 开发复用现有 PDD、钉钉和看板配置。

15.2 紧急停止条件

如评审确认启用自动熔断，则按第 7.7 节建议执行；当前已冻结规则是：出现以下任一情况时，运营或系统管理员应立即关闭场景开关：

• 发生误退款；
• 发现重复退款提交；
• 拼多多触发账号或自动化风控；
• 页面结构变化导致关键字段或按钮无法可靠识别；
• 产生退款结果未知任务；
• 日志或证据缺失，无法追溯真实退款操作。

关闭后所有新增任务停止自动执行，不影响已生成的人工工单继续处理。恢复前必须完成影响核查和问题修复，由具备权限的系统管理员执行、客服负责人确认，并记录恢复人、确认人、时间和依据。

15.3 运营指标

统计按任务 created_at 归属所选日期区间，状态取查询时最新状态；同一唯一键只计一个工单。

“Agent操作成功”仅表示拼多多售后状态成功，不表示买家支付账户实际到账；两者不得混用。

15.4 金额核对与误退款闭环

• 核对频率待业务确认；安全建议为上线首周至少每日核对一次 Agent 自动退款记录与拼多多实际完成状态、退款金额，后续频率根据首周结果调整。该建议不得在未确认前写成现行业务规则。
• 核对范围至少包含店铺、售后编号、订单号、attempt_id、申请退款金额、平台完成状态和操作时间。
• 业务必须在上线前指定核对责任角色；核对结果和差异记录作为项目运行证据保留。
• 发现状态或金额差异时，立即暂停受影响店铺场景并创建高风险事件，核查是否存在误退款、重复退款或平台状态延迟。
• 确认误退款后，应保留完整证据并按公司现有客服追偿、平台申诉或内部损失处理流程执行；若现有流程不存在，业务必须在上线前补充责任人和处理路径。

16. 责任与证据链

17. 依赖与待提供项

17.1 待业务提供

• 3.4.1 节三家已确认店铺各自的准确店铺 ID；
• 上线操作时间和人工兜底值班安排；
• 上线首周金额核对责任角色；
• 金额核对频率（安全建议为上线首周每日一次）；
• 钉钉最终发送失败时负责监控并确认看板告警的值班角色；
• 现有误退款追偿、平台申诉或内部损失处理路径；若尚无流程，则需指定责任人和处置方式。
• 现有拼多多工单人工协作 SLA；若尚无统一 SLA，则需提供高风险/中风险工单的接单和处理时限。
• 三家店铺直接上线真实退款的独立风险接受记录及证据位置。

17.2 待技术确认

• 现有拼多多工单项目的代码仓库、部署环境和接口位置；
• 新业务场景内部代码；
• PDD 售后列表与详情页的稳定定位方式；
• 任务锁、幂等记录、截图存储和日志保留的现有实现；
• 钉钉消息幂等与发送失败告警机制；
• 已确认群号 189925002005、成功不通知及固定 @10 人映射的上线前技术验证；
• 场景开关关闭时对执行中任务的安全停止实现。
• 现有日志/截图的访问权限、脱敏、加密、下载审计、保留期限和到期删除能力。
• 是否启用第 7.7 节自动熔断建议及具体阈值；未确认时只实现已冻结的手动紧急暂停。

以上待技术确认项不得改变本文已经确认的金额、件数、物流、时间、人工兜底、直接上线和系统复用规则。若实现需要扩大业务范围或改变规则，必须重新发起需求确认。