CarePilot · 电商售后智能体产品系统

电商售后的本质，是在正向交易完成之后，对“货、钱、单、责”四者的重新对齐。2025年全国12315平台接收网购投诉举报1506.7万件，同比增长14.3%，占投诉举报总量的56.9%。退货使零售商损失收入的20%～25%，全球范围内相当于每年约1万亿美元。女装服饰行业平均退货率已从2019年的30%攀升至2025年的65%～80%，直播电商退货率更高达80%～90%。全国电商退换货快递业务量2023年达82亿件，并以20.7%的年复合增速增长，2028年预计达到209亿件。

售后环节的困难不在于“单点功能缺失”，而在于三组结构性矛盾：

第一，正向系统已经高度成熟，逆向链路却长期断裂。 订单、支付、发货、签收的正向履约早已标准化，但退货一旦发生，仓库收货、质检、退款三套系统往往各跑各的——货退回来了没人及时质检，退款迟迟不发，财务月底对账时退款单与入库单对不上。某项目进场时，退货相关客诉占总客诉近三成。问题的根源不在某一个系统，而在系统之间的接缝。

第二，多平台经营放大了售后分散度，响应时效与对账一致性同时承压。 商家同时经营淘宝、京东、抖音、拼多多、视频号等多个渠道，每个平台的售后规则、状态定义、处理时限各不相同。仅退款在部分平台留给卖家的处理窗口极短，晚看到就等于默认同意；同一笔订单的退款与退货状态在不同后台记录不一致，月末对账差异频发。客服轮番登录多个后台逐条处理，响应超时直接侵蚀店铺评分。

第三，售后决策既需要“确定性”，又需要“灵活性”。 退款条件、运费承担规则、审核时限、部分退换的金额分摊——这些是刚性的商业规则，不能由概率模型随意裁定。但用户表达的方式千差万别，举证材料形态各异，又要求系统具备理解自然语言、识别图片和综合上下文的能力。单纯堆砌 if-else 规则引擎会变得不可维护，完全交给大模型又无法保证资金安全和合规底线。

这一组矛盾的直接后果是：售后处理成本随单量线性增长，而用户对退款时效的预期却在持续收紧。平台侧已在通过规则调整回应这一压力——淘宝、抖音相继将退换货免运费保障的重量门槛从1公斤提升至3公斤，竞争逻辑正从“促下单”向“稳留存”迁移。但运费门槛只是表象，真正决定售后体验的是底层系统能否把退货受理、逆向物流、质检定责、退款核销、工单协同和数据复盘串成一条可追踪、可自动化、可解释的闭环。

项目主要功能可以概括为五条主线：

1. 统一受理：多平台售后单和聊天请求统一归集为售后事项，自动分级、路由和超时预警。
2. 智能决策：规则引擎处理确定性退款资格和金额分摊，受控 AI 处理非结构化意图、举证和政策问答，服务端终裁。
3. 逆向履约：以独立状态机驱动退货、换货、补发、维修流程，打通入库、质检、退款，支持发货前和在途拦截。
4. 资金核销：退款不丢不重，退款单与入库单、原订单、财务凭证按贯穿 ID 对齐，异常自动生成对账工单。
5. 协同复盘：客服工作台人机协同、全程留痕；数据看板反哺商品和流程改进，形成售后闭环。

整体上，项目不是单一退款工具，而是一套多平台售后履约中台：把售后请求变成可追踪事项，把规则和 AI 放在正确边界内，把货、钱、单、责对齐，最终实现售后处理效率、资金安全和用户体验的平衡。

作为核心开发/技术负责人，负责多平台电商售后履约中台。主导售后事项中心、独立状态机、规则+受控 AI 决策引擎、逆向履约与退款核销链路；基于 Spring Boot、RocketMQ、Redis、MySQL、Flowable/LiteFlow、RAG 等技术栈，落地平台适配器、Outbox+幂等、贯穿 ID 对账、人机租约围栏等机制，解决多平台状态不一致、并发重复退款、货钱单对齐和 AI 资金安全边界等难点，实现退款时效从 9 天降至 1.5 天以内、退货客诉占比从近三成降至 6%、退款入库对齐率 99% 以上。