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

把不该丢的钱抢回来一套AI抗辩信系统的设计手记大概两年前我接过一个很特别的活儿。某个做跨境电商的朋友被平台以“物流时效异常”为由扣了一整月货款申诉通道填了三次每次都是模板回复“经核实维持原判”。他自己写抗辩邮件写到失眠越写越像怨妇越怨妇越没人理。后来他找到我问我能不能做个东西把“人话”翻译成“平台听得懂的规则话术”再自动跟踪每一封邮件的处理状态。我当时第一反应是这不就是给唐僧装一个孙悟空的脑袋吗但做完了才发现这套东西真正的价值不在于“写”而在于“搞清楚钱为什么被扣、谁有权决定扣、哪一条规则能反驳”这一整条链路。这套系统后来被我整理成了一套可以复用的设计思路名字就叫“AI抗辩信系统”。它解决的痛点非常明确普通人在面对平台、渠道、机构的不合理扣款时既不熟悉对方的规则语言又没有精力反复提交证据经常把“不该丢的钱”默默认了。系统要做的就是把用户描述的事实自动转成有依据、有逻辑、有证据索引的抗辩信再负责发送、跟踪、补件、升级让每一分该要回来的钱都有机会走完流程。这篇文章我会把整套系统的设计手记写清楚包括模块拆分、技术选型、生成策略、发送跟踪、常见翻车点和我的避坑经验。适合正在做客服自动化、文档生成、流程维权类产品的开发者也适合想自己搭一套追款流程、但不想从零开始踩坑的产品经理。1. 先搞清楚什么钱算“不该丢的钱”1.1 从一封地板价拒赔邮件说起我复盘过很多真实案例发现一个共性问题大部分被扣掉的钱在规则层面并不是“铁案”。比如某平台买家退货快递显示已签收但仓库迟迟没入库平台直接判卖家全责退款。这里面的争议点不是“要不要退款”而是“签收后入库延迟是谁的责任”。再比如某保险渠道拒赔理由写“既往症”但用户提供的体检报告显示投保前并无相关记录这里的争议点是“健康告知与既往症的定义边界”。这些案例的共同特征是钱确实被扣了但扣款的依据存在解释空间只要抗辩信能把事实和规则对应起来就有翻盘机会。可现实里大多数人写抗辩信的水平是这样的“你们凭什么扣我的钱我非常不满意我要投诉”这种信发出去对方只能看到情绪看不到事实链条。而专业机构处理投诉时最怕的就是情绪化表达因为情绪化意味着“非理性”非理性意味着“可以按流程冷处理”。所以我给系统的第一个定位不是“替用户吵架”而是“帮用户把吵架变成对账”。系统接收用户口语化的描述抽取其中的时间、主体、金额、结果、证据材料最终输出一封格式整齐、条款对应、证据索引清晰的抗辩信。用户负责提供事实系统负责提供“说法”。1.2 抗辩信到底在做什么很多人以为抗辩信就是“投诉信”这是最大的误解。投诉信的核心是“表达不满”抗辩信的核心是“主张权利”。前者是情绪导向后者是规则导向。一封有效的抗辩信至少要完成四件事还原事实按时间顺序列出发生了什么避免主观评价。对应规则引用对方规则、协议、条款中支持自己立场的内容。指出矛盾说明对方处理决定与事实/规则之间的冲突点在哪里。给出诉求明确提出希望对方做什么比如重新核算、撤销扣款、补充赔付。这四件事里最难的其实是“指出矛盾”。因为大部分用户根本不知道平台内部有哪些规则更不知道去哪里查。系统设计时我的思路是先建立一个“争议类型-规则关键词-证据要求”的映射库。用户选择争议场景后系统自动提示需要上传哪些证据、引用哪类规则。这样即使没有专业人士参与生成的抗辩信也能踩在点上。做这个映射库的过程很痛苦需要大量读各类平台的服务协议、扣款规则、争议处理流程。但它的价值极高因为后面所有的生成prompt、证据校验、状态分类都依赖这个库里沉淀出来的结构化知识。如果你想复刻这套系统我建议把至少60%的精力投在规则库里而不是语言模型上。2. 系统整体设计与架构2.1 模块划分与链路整套系统的核心链路是信息采集 - 事实抽取 - 争议画像 - 抗辩信生成 - 渠道适配 - 发送与跟踪 - 结果复盘。在实际工程里我把它拆成五个独立模块每个模块都能单独测试、单独替换模块职责关键产出信息采集端收集用户聊天式描述、证据材料、关联订单信息结构化案件事实表拉取上游订单/转账/合同数据争议画像匹配争议类型、生成抗辩策略、挑选规则依据策略ID、引用条款、证据清单信函生成调用LLM按不同渠道格式生成正文抗辩信正文、摘要、附件清单渠道路由判断并适配邮件/表单/在线客服等不同出口发送任务、格式包、自动抄送规则跟踪与复盘定时检查回执、识别“需要补件/被驳回”等状态状态看板、下一步行动建议有人会问为什么生成引擎不直接挂在信息采集后面非要中间加一层“争议画像”我的回答是直接生成确实快但你会失去对生成方向的把控。同样一段“快递签收后未入库”的描述在“卖家投诉物流”和“买家申请退款”两个场景下需要引用的规则和表达策略完全不同。没有画像层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抗辩信做的事情是让一个不擅长写字的普通人也能用规则听得懂的语言和它们对话。操作上我想给准备做类似系统的朋友一条建议先把“争议场景库”做小做透再考虑规模化。我一开始贪多接了十几个场景结果每个场景的规则库都薄得像纸生成的信件质量参差不齐。后来砍到五个高频场景把每个场景的条款映射、证据要求、补问逻辑都做到极致整体效果才真正立起来。另外一个实用的扩展方向是“抗辩后续动作的自动化”。现在系统能生成信件、跟踪状态、提醒补件但对于“对方已经同意退款但迟迟不打款”这类情况还缺少自动追款能力。我正在做一套“逾期催办引擎”基于回执中的承诺日期倒推自动生成催办信不需要用户再手动干预。这大概是下一步最值得投入的地方。做这套系统的过程让我对“钱是怎么被扣的”有了全新的理解。很多扣款并不是一方作恶而是规则的不透明和执行流程的粗糙造成的。我们可能改变不了规则但至少可以用一套逻辑清晰的工具把那些稀里糊涂丢掉的确定性一点点抢回来。