AI抗辩信系统设计手记：从规则库到智能生成与全流程跟踪

把不该丢的钱抢回来：一套AI抗辩信系统的设计手记

大概两年前，我接过一个很特别的活儿。某个做跨境电商的朋友，被平台以“物流时效异常”为由扣了一整月货款，申诉通道填了三次，每次都是模板回复“经核实维持原判”。他自己写抗辩邮件写到失眠，越写越像怨妇，越怨妇越没人理。后来他找到我，问我能不能做个东西，把“人话”翻译成“平台听得懂的规则话术”，再自动跟踪每一封邮件的处理状态。我当时第一反应是：这不就是给唐僧装一个孙悟空的脑袋吗？但做完了才发现，这套东西真正的价值不在于“写”，而在于“搞清楚钱为什么被扣、谁有权决定扣、哪一条规则能反驳”这一整条链路。

这套系统后来被我整理成了一套可以复用的设计思路，名字就叫“AI抗辩信系统”。它解决的痛点非常明确：普通人在面对平台、渠道、机构的不合理扣款时，既不熟悉对方的规则语言，又没有精力反复提交证据，经常把“不该丢的钱”默默认了。系统要做的，就是把用户描述的事实自动转成有依据、有逻辑、有证据索引的抗辩信，再负责发送、跟踪、补件、升级，让每一分该要回来的钱都有机会走完流程。

这篇文章我会把整套系统的设计手记写清楚，包括模块拆分、技术选型、生成策略、发送跟踪、常见翻车点和我的避坑经验。适合正在做客服自动化、文档生成、流程维权类产品的开发者，也适合想自己搭一套追款流程、但不想从零开始踩坑的产品经理。

1. 先搞清楚：什么钱算“不该丢的钱”

1.1 从一封地板价拒赔邮件说起

我复盘过很多真实案例，发现一个共性问题：大部分被扣掉的钱，在规则层面并不是“铁案”。

比如某平台买家退货，快递显示已签收，但仓库迟迟没入库，平台直接判卖家全责退款。这里面的争议点不是“要不要退款”，而是“签收后入库延迟是谁的责任”。再比如某保险渠道拒赔，理由写“既往症”，但用户提供的体检报告显示投保前并无相关记录，这里的争议点是“健康告知与既往症的定义边界”。这些案例的共同特征是：钱确实被扣了，但扣款的依据存在解释空间，只要抗辩信能把事实和规则对应起来，就有翻盘机会。

可现实里，大多数人写抗辩信的水平是这样的：“你们凭什么扣我的钱？我非常不满意，我要投诉！”这种信发出去，对方只能看到情绪，看不到事实链条。而专业机构处理投诉时，最怕的就是情绪化表达，因为情绪化意味着“非理性”，非理性意味着“可以按流程冷处理”。

所以我给系统的第一个定位不是“替用户吵架”，而是“帮用户把吵架变成对账”。系统接收用户口语化的描述，抽取其中的时间、主体、金额、结果、证据材料，最终输出一封格式整齐、条款对应、证据索引清晰的抗辩信。用户负责提供事实，系统负责提供“说法”。

1.2 抗辩信到底在做什么

很多人以为抗辩信就是“投诉信”，这是最大的误解。投诉信的核心是“表达不满”，抗辩信的核心是“主张权利”。前者是情绪导向，后者是规则导向。

一封有效的抗辩信，至少要完成四件事：

• 还原事实：按时间顺序列出发生了什么，避免主观评价。
• 对应规则：引用对方规则、协议、条款中支持自己立场的内容。
• 指出矛盾：说明对方处理决定与事实/规则之间的冲突点在哪里。
• 给出诉求：明确提出希望对方做什么，比如重新核算、撤销扣款、补充赔付。

这四件事里，最难的其实是“指出矛盾”。因为大部分用户根本不知道平台内部有哪些规则，更不知道去哪里查。系统设计时，我的思路是先建立一个“争议类型-规则关键词-证据要求”的映射库。用户选择争议场景后，系统自动提示需要上传哪些证据、引用哪类规则。这样即使没有专业人士参与，生成的抗辩信也能踩在点上。

做这个映射库的过程很痛苦，需要大量读各类平台的服务协议、扣款规则、争议处理流程。但它的价值极高，因为后面所有的生成prompt、证据校验、状态分类，都依赖这个库里沉淀出来的结构化知识。如果你想复刻这套系统，我建议把至少60%的精力投在规则库里，而不是语言模型上。

2. 系统整体设计与架构

2.1 模块划分与链路

整套系统的核心链路是：信息采集 -> 事实抽取 -> 争议画像 -> 抗辩信生成 -> 渠道适配 -> 发送与跟踪 -> 结果复盘。

在实际工程里，我把它拆成五个独立模块，每个模块都能单独测试、单独替换：

有人会问：为什么生成引擎不直接挂在信息采集后面，非要中间加一层“争议画像”？我的回答是：直接生成确实快，但你会失去对生成方向的把控。同样一段“快递签收后未入库”的描述，在“卖家投诉物流”和“买家申请退款”两个场景下，需要引用的规则和表达策略完全不同。没有画像层，LLM只能泛泛而写，很难产出“运单签收时间早于退款判决时间”这种精准打击句。

2.2 技术选型与关键取舍

技术栈方面，我的组合是：FastAPI做服务端、PostgreSQL存结构化数据、Redis做任务队列、云函数做定时调度，LLM部分用了两个模型：一个负责抽取事实，一个负责生成正文。

为什么把抽取和生成分开？最直接的原因是稳定性和成本。抽取任务要求“输出字段固定、不要自由发挥”，用小参数模型加上严格的JSON Schema约束就能跑得非常稳，一次调用成本极低。生成任务需要“组织语言、引用规则、控制语气”，必须用指令遵循能力强的大模型，而且要预留多轮调优空间。两个任务混用一个模型，要么代价太高，要么质量不稳。

另一个关键取舍是：信函模板和LLM生成的比例。一开始我也追求“全AI生成”，后来发现很多渠道对格式有硬性要求，比如某个平台只支持纯文本表单且限制2000字，某个保险渠道需要按固定分节标题上传附件。这时候纯AI生成就不如“模板骨架 + AI填充 + 规则校验”的模式稳定。我们最终的做法是：每个争议类型预设骨架，LLM只负责填充事实和论据，最后模板引擎统一渲染。这样做的好处是格式永远可控，不会出现AI突然给你加一段“以上谨代表我个人意见”这种多余内容。

3. 核心模块的拆解与实现

3.1 从“情绪化描述”到“结构化事实”

这个模块是整个系统里最容易被低估的部分。用户不会像客服工单那样规规矩矩地给你时间、地点、金额，他们更可能说的是：“那个破平台乱扣钱，气死我了，上个月明明说好退运费，结果又扣了我一笔，找了客服也没用。”

这段描述里有三件事必须抽出来：扣款主体（平台）、金额（运费）、状态（承诺后退运费却再扣）。还有一件事是缺失的：订单编号或时间范围。事实抽取模块的目标就是把“气死我了”这类噪声过滤掉，只留下可用于后续争议画像的字段，并向用户追问缺失项。

我采用的方案是“意图识别 + 槽位抽取 + 补问对话”三件套。意图识别判断用户是要投诉扣款、申请减免、还是有其他诉求；槽位抽取从自由文本中提取主体、金额、时间、凭证编号等；补问对话专门处理缺信息的情况。这里有个很实用的技巧：不要把槽位抽取的希望全押在LLM上，规则兜底能省很多事。比如金额字段，先用正则把所有“人民币”“元”“¥”结尾的数字抓出来，再交给LLM判断具体语义，准确率能提升不少。

补问环节的设计也很有讲究。不能问“请提供完整证据链”，用户听到这种话会直接放弃。要问“该订单的编号是多少？”，要问“你是在哪一天发现被扣款的？”，一次只问一项，用选择题而不是填空题。实测下来，跟用户做三轮以内补问，信息完整度可以到85%以上；超过三轮，流失率明显上升。所以这个模块还要配套一个“容忍度阈值”，信息完整度低于60%时不建议硬生成抗辩信，先让用户补充关键缺项。

3.2 生成引擎：抗辩信文本质量怎么保证

信函生成是整个系统的门面，用户第一眼看到的就是这封信。质量不好，前面所有结构化工作都会归零。

我的生成策略分三层。第一层是选择“视角”，系统会自动判断用户是“被扣款方还是申诉方”，不同视角对应的语气和角色完全不同。第二层是挑选“论据包”，从争议画像模块拿到策略ID后，从规则库中拉取对应的条款原文、历史判例、证据要求，拼成一个上下文包喂给LLM。第三层才是“生成正文”，此时的Prompt包含事实时间线、争议焦点、引用条款、附件清单和输出格式约束。

之所以要这么层层递进，是因为LLM如果没有足够高质量的上下文，很容易写出“事实正确但没有杀伤力”的软绵绵文字。我试过一次比较典型的输出：“我方认为平台扣款行为存在不妥，恳请贵方核实。”这段单独看没问题，但放到抗辩场景里，它既没有指出对方违反了哪一条规则，也没有提出明确诉求，属于典型的无效抗辩。而带论据包之后，LLM会把“依据平台店铺规范第X条，通过物流签收状态判定买家已收货，不应适用未收到货退款”这种落点写进去，读起来完全不一样。

写Prompt还有一个特别值得强调的点：给LLM明确“不要做什么”比“要做什么”更重要。我在系统里固定了一段“写作禁令”：不要使用攻击性语言、不要承认用户存在主观过错、不要编造未提供的证据、不要使用夸张形容词。这些限制看起来简单，但能过滤掉大量劣质输出。尤其是“不要编造证据”，这件事一旦发生，抗辩信就直接废了，还会给用户带来信用风险。

生成完成之后，还要过一道“事实一致性校验”，这一步常被忽略。方法很朴素：把生成文本里出现的所有时间、金额、单号，与从用户输入里抽取出来的结构化字段做交叉比对，不一致就重新生成。严格模式可以做到一个错单号都不出现，这在给平台提交抗辩时非常重要，因为对方会拿细节当把柄。

3.3 分发与追踪：信发出去只是开始

很多人做抗辩系统，写到“信发出去”就宣告完工，这是大错特错。真实的抗辩过程从来不是一封信能解决的，后续的跟踪、补件、升级，才是决定成败的关键。

分发层的第一个任务是渠道适配。我维护了一份渠道配置表，记录每个渠道支持的提交方式、格式要求、截图要求、时效预期。最开始我只接了邮件，后来陆续接上了在线表单、工单系统、企业微信对接，每个渠道都有自己的一套字段映射。这里提醒一句：渠道适配的坑在于“看似能通用、实际每个都不一样”。比如邮件可以写长正文并传附件，某平台表单就限制每条留言2500字符且不支持附件，同一封抗辩信必须做裁剪和附件拆分后才能提交。

追踪层更核心。我设计了一套状态机，分“已发送、待确认、已接收、处理中、要求补件、维持原判、部分退款、全额退款”八种状态。大部分状态可以通过邮件回执、渠道通知hook来处理，但“要求补件”这种状态光靠自动化不够，还得配合语义识别。对方回复“请提供完整物流跟踪记录”时，语义分类模型会把这条消息标成“补件要求”，然后系统自动给用户发起补件任务，催收资料。

这里还有一类很容易出错的情况，就是对方回复的是一段客套话，比如“感谢您的耐心等待，我们非常重视您的反馈”，如果不做语义分类，很容易被当成“处理中”而无限挂起。我加了一个“活性判断”规则：超过30天没有实质进展且没有补件动作的案件，自动触发升级动作，要么建议用户走下一级渠道，要么重发一封更直接的函件。做过维权的人都知道，“被沉默”是最大的敌人，所以追踪模块一定要时刻让案件处于“有人管”的状态。

4. 实操记录：三个案例让我改进了设计

4.1 电商保证金扣款案：被忽略的时间线

第一个完整跑通系统的案例，是某电商店主被扣保证金，理由是“商品描述与实物不符”导致平台先行赔付。店主非常委屈，因为买家退货前多次使用商品，货也明显有磨损，但平台客服表示“按照规则，描述不符判定成立，保证金扣除”。

我还原事实时发现，店主只提到了“买家退货”和“商品磨损”，却漏了一个关键时间点：商品详情页更新是在买家下单后两天才完成的。也就是说，“描述不符”的判断实际上不能覆盖买家下单时的页面版本，这是整封信最有力的反驳点。系统抽取模块补问对话时精准追问了“商品详情页最后一次修改时间”，拿到后信函质量直接上了一个台阶。

这个案例让我意识到，抗辩信翻盘往往不是因为文笔好，而是因为“把关键时间点放到正确的位置”。后来我在事实抽取模块里增加了一条规则：只要争议类型与“描述不符”相关，自动追问详情页修改时间、下单时间、交付使用时间三个时间点。这种基于场景的追问，比任何通用槽位抽取都高效。

4.2 重复扣款案：缺失的证据索引

第二个案例是用户被某订阅服务连续扣了两笔相同金额，理由是“自动续费规则用户已同意”。用户觉得冤枉，说自己根本没点过自动续费。问题是系统打开后，扣款记录页面只显示了最新一笔，早期记录要一层层点进去才看得到。

我把这个案件完整的证据清单列给用户后才发现，用户手上根本没有“扣款协议版本”的存档。于是抗辩信里只能主张“重复扣款未提前通知”这一条，而不是干巴巴地说“我没有同意”。修改后效率立竿见影，因为平台方无法证明“用户在扣款前收到过明确弹窗提醒”，最终退还了第二笔费用。

这个案例给系统的启发是：证据清单要和信函正文一起生成，并作为附件索引附在信函中。用户不需要上传所有证据，系统会自动根据争议策略挑选最相关的三到五份，还帮用户补齐证据名称、获取路径、证明点三项说明。这封信从“我申诉”变成了“我们这边证据齐了，就差你核实”，节奏完全不同。

4.3 保险拒赔案：追问出“隐藏事实”

第三个案例是某保险产品理赔被拒，理由是“未如实告知健康状况”。用户觉得很冤，因为投保时已经确认自己填了所有体检异常项。系统在生成初稿时，只是把用户提交的描述和体检报告一起放进去，结果生成的抗辩信一直被对方用模板顶回。

后来用户补了一份关键材料：投保前的智能核保问答截图，里面明确显示“所选既往症列表不含当前疾病”。我立刻把这份证据加进论据包，并把抗辩策略从“我们没有隐瞒”改成“该疾病不在投保问卷列出的既往症范围内，且用户已按问卷要求完成全部告知”。最后案子在补充材料后达成和解。

这个案例说明，抗辩信的成败往往取决于“你掌握了哪些对方没见过、或者对方没仔细看的证据”。系统能做的，不只是把现有材料整合成信件，还要能在对话中诱导用户回忆起容易被忽略的材料来源。我后来在信息采集模块里加了一项“材料回溯”功能，针对每个争议类型，列出常见“隐藏材料”清单，比如投保问卷截图、订阅扣款前预警短信、商品页历史版本缓存，这样用户按清单找证据的成功率会高很多。

5. 常见问题与排查技巧实录

5.1 LLM幻觉：最怕它编出漂亮话

说实话，做AI生成类系统，我最担心的就是模型一本正经地编事实。尤其是抗辩信这种场景，用户说没有保健品健康告知记录，LLM可能会顺着用户的情绪写成“我方从未接受过任何体检”，这就变成了假证据，后果很严重。

我的排查策略是：生成后强制做“证据映射检查”。信函里的每一个事实性断言，都必须能在用户的输入或上传材料中找到对应出处，否则就标记为“无法溯源”并拦截重写。技术上，实现方式是把用户提供的结构化字段、证据文件名、OCR读取的关键句全部放进一个“可信事实池”，LLM生成时只允许引用池内内容。经过一段时间测试，这个方法基本消除了新增幻觉，偶尔出现也只是泛化表述层面的，不涉及具体数字。

5.2 对方回复“模板话术”时如何判断状态

跟踪模块最常见的误判，是把“人工客服正在核实”当成“已经实质推进”。我试过按关键词“核实”“处理中”来分类，准确率很低，因为模板话术里全是这类词。

后来换成了“行为信号”判断法。只有当回复中出现以下特征时才认定为实质进展：明确引用了你的抗辩编号、提到了资金解冻/退回的时间预期、要求补充具体材料的名称、直接反驳了你某条引用条款。如果回信只是泛泛而谈，一律视为“冷处理”，并触发自动催办。这套规则让跟踪判定准确率从不到60%提升到90%以上。

5.3 渠道限流与配额：一封信被卡在半路

邮件渠道看似简单，实际上有许多软限制。某个邮件服务商对同一收件人每日发送量做严格限制，即使我们能获取到多个客服地址，也不能在一天内高频发送。否则要么被退信、要么被标记为垃圾邮件。

我们做了一套“发送配额表”，按渠道、收件方、当天已发数量三个维度做限流。同时，每次发送前会用邮件服务商的API做一次收件人有效性校验。这个技术在批量维权场景里特别关键，否则一旦被对方邮件系统拉黑，整个案件都会进入死胡同。

5.4 权限与数据安全：抗辩信不能乱存

抗辩信涉及大量交易流水、健康信息、身份信息，合规红线必须一早就画清楚。我的经验是：证据材料只做必要采集，不采集与争议无关的敏感字段；数据存储做字段级加密；所有生成信函保留审计日志，确保“哪段内容来自哪个用户材料”可追溯。这个设计不只是为了让合规过关，更是为了用户在证据争议时能自证清白。毕竟抗辩信的本质是“讲事实”，事实必须有出处。

6. 关于这套系统，我再多说几句

最后聊点系统之外的东西。

很多人觉得“AI抗辩信系统”是在教用户怎么钻空子，其实不是。真正跑过大量案例后你会明白，这套系统的作用是替用户把“原本就该被尊重的规则”重新放到桌面上。平台、渠道、机构每天处理海量投诉，它们习惯于用模板来筛选诉求，那些表达不清、证据零散的用户天然会被过滤掉。AI抗辩信做的事情，是让一个不擅长写字的普通人，也能用规则听得懂的语言和它们对话。

操作上，我想给准备做类似系统的朋友一条建议：先把“争议场景库”做小做透，再考虑规模化。我一开始贪多，接了十几个场景，结果每个场景的规则库都薄得像纸，生成的信件质量参差不齐。后来砍到五个高频场景，把每个场景的条款映射、证据要求、补问逻辑都做到极致，整体效果才真正立起来。

另外一个实用的扩展方向是“抗辩后续动作的自动化”。现在系统能生成信件、跟踪状态、提醒补件，但对于“对方已经同意退款但迟迟不打款”这类情况，还缺少自动追款能力。我正在做一套“逾期催办引擎”，基于回执中的承诺日期倒推自动生成催办信，不需要用户再手动干预。这大概是下一步最值得投入的地方。

做这套系统的过程，让我对“钱是怎么被扣的”有了全新的理解。很多扣款并不是一方作恶，而是规则的不透明和执行流程的粗糙造成的。我们可能改变不了规则，但至少可以用一套逻辑清晰的工具，把那些稀里糊涂丢掉的确定性，一点点抢回来。