DM-02 · 判责辅助决策

① 场景引入

美团赔付规范细则数十条（接单 10 分钟内取消赔 50%、以上赔 100%） · Meta 教训：AI 终审 + AI 复审 = 死循环

一、这件事现在是什么样

客诉与判责 · 真实业务触发

DM-01 里那条食安投诉升级到判责：用户要求全额退款加医药费 300 元；订单时间线显示商家 22:15 送达（正常）、用户 23:40 首次联系客服（间隔 85 分钟）、无当日就医凭证（次日门诊记录一张，无法直接关联本单）；商家主张「出餐与包装全程合规，不能排除用户自食其他食物」；另有两单待判：骑手洒餐（用户拍照 + 骑手已承认）、商家漏送（系统出餐记录明确）。运营主管今天要出三个判责结论，每个都可能被商家或用户申诉。

二、痛点 · 每条都有来源

1美团《商家责任场景赔付管理规范》细则数十条：接单 10 分钟内取消赔 50%、10 分钟以上赔 100%、发票错误赔

100%——细则量超出人工记忆，判责本质是规则匹配问题依据 · 《美团商家责任场景赔付管理规范》：赔付细则数十条（接单 10 分钟内取消赔 50%、10 分钟以上赔 100%、发票错误赔 100% 等），自配送超时申诉需第三方配送凭证——细则量超出人工记忆，判责是规则匹配问题2判责依据是「问题类型 + 系统数据综合判断」——事实基础是下单、出餐、配送、沟通的时间线证据链，中小平台没有系统能力时就是客服人肉翻后台依据 · 美团客诉处理规则：「平台将依据买家投诉的问题类型、现有系统数据综合判断」——判责的事实基础是时间线证据链，不是谁嗓门大3AI 终审的反面教材：Meta 误删后申诉仍由 AI 复审，6 万人请愿人工复审；YouTube 申诉 3 分钟被 AI 驳回——涉及赔付与处罚的终审没有人工救济就是死循环依据 · Meta 教训：AI 审核误删账号后申诉仍由 AI 复审，一周即驳回，用户陷入解封死循环，6 万人联名请愿要求人工复审——全自动处置没有人工救济的终局4电商法第 38 条「知道或应当知道未采取必要措施则连带」——判责记录本身就是平台「已采取必要措施」的举证依据 · 《电子商务法》第 27 条：平台对入驻经营者身份、地址、联系方式、行政许可等真实信息「进行核验、登记，建立登记档案，并定期核验更新」；第 38 条：对关系消费者生命健康的商品或服务未尽资质审核义务造成损害的，依法承担相应责任5中小平台的判责现状是「谁接住谁处理」，标准是经验加和气——同类纠纷不同结论，商家申诉时无据可查依据 · 区域平台「平台运营」JD 原文：门店入驻审核 + 团单上架优化 + 活动资源对接 + 差评快速响应机制 + 数据报告，五件事写在同一份 6-9 千月薪的岗位说明里

三、换个做法之后

变化不在「快」，在「参与的角色」和「覆盖的范围」

✕ 现在的做法

• 美团《商家责任场景赔付管理规范》细则数十条：接单 10 分钟内取消赔 50%、10 分钟以上赔 100%、发票错误赔 100%——细则量超出人工记忆，判责本质是规则匹配问题判责依据是「问题类型 + 系统数据综合判断」——事实基础是下单、出餐、配送、沟通的时间线证据链，中小平台没有系统能力时就是客服人肉翻后台AI 终审的反面教材：Meta 误删后申诉仍由 AI 复审，6 万人请愿人工复审；YouTube 申诉 3 分钟被 AI 驳回——涉及赔付与处罚的终审没有人工救济就是死循环电商法第 38 条「知道或应当知道未采取必要措施则连带」——判责记录本身就是平台「已采取必要措施」的举证

✓ 交给 Agent 之后

• 多来源文件一次读入，先做口径与完整性校验，再开始算
• 每条结论绑定来源文件、字段或条号，可以被审
• 产出是企业真会流转的正式件（带签批栏），不是一张展示用的表
• 该拦的地方给出「现在还不能提交」，并给不用干等的替代方案

四、场景闭环

5 步 · 每一步的产出都是下一步的输入

1. 时间线证据链汇拢订单各节点 × 沟通各节点排成一条线，缺项标出
2. 规则逐条匹配纠纷特征对上赔付细则逐条比对，命中与不命中各有说明
3. 历史判例对照本平台同类纠纷的历史结论调出——同类不同判的矛盾点标红
4. 责任初判与置信度四方责任（商家/骑手/用户/平台）初判 + 证据齐全度置信度
5. 判责建议书成稿证据链 +规则匹配 + 初判建议，签字栏留白

要准备什么：订单履约时间线下单、接单、出餐、取餐、送达各节点时间纠纷沟通记录用户诉求、商家主张、骑手陈述的原始记录赔付规则与历史判例规则文本 + 本平台同类纠纷的历史结论补充证据材料照片、就医凭证、承认记录等为什么这个场景值得做

优先级评分：痛感 5 × AI 适配 4 ÷ 落地难度 3 = 8.0

最大差异点：判责辅助不是「AI 来判」，是把判责拆成三段可核验的工作：证据链汇拢（订单时间线 × 沟通记录 ×历史判例）、规则匹配（当前纠纷对上哪条赔付细则）、建议与置信度（证据齐就高置信，证据缺就标注缺什么）。主管签字的时候，每一条结论后面都挂着证据与规则原文——这才是「同类纠纷同结论」的底气，也是被申诉时的挡箭牌。

评分口径：痛感看「这事没做好谁会生气、生气到什么程度」；

AI 适配看「输入是否非结构化、是否要跨部门取数、错了能不能当场看出来」；

落地难度是分母 —— 需要客户先做数据治理的场景，分数会被压得很低。

五、会产出什么

判断标准只有一个：这份东西能不能直接进企业的流程

• 正式件本体：判责建议书（三单合并）.docx 正式件 · 证据链 × 规则匹配 × 初判建议 · 主管签字栏
• 可派发清单：证据缺口清单.xlsx 每单缺什么证据 / 补证路径 / 时限
• 可派发清单：历史判例对照表.xlsx 同类纠纷历史结论 × 本次建议 · 矛盾点标红

这套东西不承诺什么：判责结论必须人工签批：本场景只出证据链、规则匹配结果与建议，「商家/骑手/用户/平台责任」的认定与赔付金额由运营负责人签字；食安类纠纷的证据不足时按「存疑有利于用户」的监管口径建议保守处置，但建议不等于结论。

② Live Demo（演示逐步）

美团赔付规范细则数十条（接单 10 分钟内取消赔 50%、以上赔 100%） · Meta 教训：AI 终审 + AI 复审 = 死循环

演示模式 · 可视化预演 本页展示的是「应该怎么跑、每一步看什么、交付什么」，用的是真实业务格式的脱敏构造数据， 不宣称已接入客户生产系统，也不承诺任何效率提升百分比。

案例设定：邻聚生活客服组长阿青周三判责 3 单完结纠纷——美团赔付规范细则数十条没人背得下（接单 10 分钟内取消赔 50%、10 分钟以上赔 100%、发票错误赔 100% 等），判责的事实基础是下单、出餐、配送、沟通的时间线证据链——中小平台没有系统能力时就是客服人肉翻后台。

本周判责3 单规则匹配1 单 · 自配送超时证据链完整2 单 · 时间线齐责任判定商家 1 · 骑手 1 · 平台 1

输入本地生活平台手上能拿到的东西

不需要整理格式、不需要改文件名 · 直接拖进对话框

• 01_3单完结纠纷订单与时间线.xlsx 3 单完结纠纷的完整时间线——下单、接单、出餐、取餐、送达、用户沟通平台后台+ 商家自存
• 02_美团赔付规范_第4902条.txt 《美团商家责任场景赔付管理规范》第 4902 条原文——接单超时、送达超时、发票错误等细则美团规则中心
• 03_历史判例对照表_近6个月.xlsx 近 6 个月 32 单判责完结案例——判责一致性的对照依据客服组 · 上次汇总 2025-04
• 04_AM-01入网审查记录单_老广炭火.docx AM-01 产出的入网审查记录单——本场景用作「平台已采取必要措施」的举证AM-01 阶段二产物

注意标橙色那一份 —— 01_3单完结纠纷订单与时间线.xlsx。它平台后台 + 商家自存，平时压根不在核对范围里。这个场景的价值，很大一部分就来自把它读进来。

提示词就说这么几句

没有模板、没有表单 · 专业规则由 Skill 兜底

DM-01 升级过来的食安判责，另外还有两单纠纷一起处理。这是三单的订单时间线和沟通记录，这是赔付规则文本和历史判例，用户补了一张次日的门诊记录。 帮我做判责辅助：

1. 三单的时间线证据链各排一条，缺什么证据标出来。
2. 每单对上赔付规则逐条匹配，命中哪条、依据什么，写清楚。
3. 食安这单：餐费和医药费分开看，医药费的证据缺口指出来，别替我决定赔不赔。
4. 历史判例里同类纠纷怎么判的调出来，跟我们这次的建议对一对，有矛盾标红。
5. 每单给初判建议加置信度，签字栏留白。 记住：你出建议，结论我签。

规则匹配逻辑、置信度分级、历史判例对照模板在能力包里；现场只需给时间线、沟通记录、规则文本、历史判例。

13 单纠纷按「时间线 + 规则匹配」过一遍

判责从「谁嗓门大」变成「谁时间线对」

订单类型关键时间线匹配规则DD20260820-0034未送达12:01 下单 · 12:24 出餐 · 未送达第 4902 条二.（2）

DD20260822-0078上菜慢18:35 下单 · 19:25 送达 · 用户等 50 分钟第 4902 条二.（1）DD20260825-0011发票错误11:10 下单 · 11:55 送达 · 发票抬头错第 4902 条三.（1）从历史判例想起的顺序 · 先时间线后规则判责的事实基础是时间线证据链，不是哪条规则该赔多少。客服一上来就背「50% / 100%」是错的——先确认时间线事实，规则自动匹配。2单 1 · DD20260820-0034 · 自配送未送达

未送达就是骑手责任，但需要证据

要素事实规则匹配判定下单12:01——出餐12:24（商家 23 分钟出餐，正常）——送达未送达——配送商家自配送需第三方配送凭证无凭证规则匹配第 4902 条二.（2）无凭证按 100% 赔付骑手 100% 赔付该拦的直觉 · 先查配送归属再谈赔付商家自配送「未送达」要 100% 赔付——但配送人员是商家自己的人还是平台的？查时间线：12:24 出餐后无取餐记录、无骑手扫码、配送无 GPS 轨迹——是商家自配送，且商家无第三方配送凭证。按规则 100% 赔付，判骑手。

第 3 步 · 单 2 · DD20260822-0078 · 上菜慢

上菜慢是商家责任，但有 AM-01 留痕可以反推

第 4 步 · 单 3 · DD20260825-0011 · 发票错误

发票错误是商家责任，规则明文

不讲省了多久 · 讲少了几个隐患、沉淀了什么

③ 能力沉淀（Skill / 提示词 / 预期输出 / 人工边界）

美团赔付规范细则数十条（接单 10 分钟内取消赔 50%、以上赔 100%） · Meta 教训：AI 终审 + AI 复审 = 死循环

1. Skill 能力包

导入之后，同类任务会自动按这套规则走 —— 提示词才能写得那么短

判责辅助决策 —— 细则几十条没人背得下，终审永远是人 · Skill

SKILL.md 主本 + references（输出骨架 / 判据 / 渲染脚本）· 符合 WorkBuddy Skill 规范

版本 v1.0

judgment-assist-with-evidence.zip

在 WorkBuddy 里直接上传这个 zip 即可导入

包内结构

• SKILL.md 主本 —— YAML 元信息 + 执行流程 + 硬规则 + 人工边界
• references/output_template.md 输出骨架（sheet 名 / 分区顺序 / 列头）+ 可直接运行的渲染脚本
• references/judgement_rules.md 判据与口径 —— 什么情况算异常、什么情况必须拦住

references 不会一次性全读进来 —— Agent 按需取用。所以 Skill 可以写得很细，不会拖慢每次对话。

2. 原始素材

这些就是本地生活平台手上真实能拿到的东西 —— 格式不统一是常态，不是问题

📁DM-02 · 演示素材

脱敏构造数据 · 真实业务格式 · 埋点可核验

共 4 份

• 01_3单完结纠纷订单与时间线.xlsx 3 单完结纠纷的完整时间线——下单、接单、出餐、取餐、送达、用户沟通 TXT02_美团赔付规范_第4902条.txt《美团商家责任场景赔付管理规范》第 4902 条原文——接单超时、送达超时、发票错误等细则
• 03_历史判例对照表_近6个月.xlsx 近 6 个月 32 单判责完结案例——判责一致性的对照依据 DOC04_AM-01入网审查记录单_老广炭火.docxAM-01 产出的入网审查记录单——本场景用作「平台已采取必要措施」的举证

怎么用

• 把素材全部拖进 WorkBuddy 对话框（不需要整理格式、不需要改文件名）
• 粘贴下方提示词发送
• 拿到正式件初稿 —— 签批栏留空，推荐意见留空，由你填

3. 提示词卡片

DM-01 升级过来的食安判责，另外还有两单纠纷一起处理。这是三单的订单时间线和沟通记录，这是赔付规则文本和历史判例，用户补了一张次日的门诊记录。 帮我做判责辅助：

1. 三单的时间线证据链各排一条，缺什么证据标出来。
2. 每单对上赔付规则逐条匹配，命中哪条、依据什么，写清楚。
3. 食安这单：餐费和医药费分开看，医药费的证据缺口指出来，别替我决定赔不赔。
4. 历史判例里同类纠纷怎么判的调出来，跟我们这次的建议对一对，有矛盾标红。
5. 每单给初判建议加置信度，签字栏留白。 记住：你出建议，结论我签。

为什么这么短就够了：规则匹配逻辑、置信度分级、历史判例对照模板在能力包里；现场只需给时间线、沟通记录、规则文本、历史判例。

换成你自己的业务：把素材换成你手上的真实文件即可。导入 Skill 之后，

该走几步、什么口径、什么情况必须拦住，Agent 自己知道 —— 你只需要说清这是什么事。

自己组织输入的三步法

• 用自然语言说清核心需求 —— 就按平时跟同事交代活的方式说：什么事、什么文件、什么要求。不用讲究格式。
• 调用 Skill 补齐专业规则 —— 导入本页 Skill 后，流程、口径、硬规则 Agent 自己知道。
• 用「增强提示词」补全遗漏 —— 输入框旁边有增强按钮，把随口说的话补成更完整的表述。

分工：自然语言负责「这是什么事」，Skill 负责「该怎么做」，增强提示词负责「别漏了什么」。

4. 预期输出

不方便现场跑的时候可以直接拿这份给客户看 · 与实跑结果同结构

📋正式交付物

带签批栏 / 冻结首行 / 开筛选 —— 判断标准是「能不能直接进企业的流程」

共 3 份

• DM-02_判责建议书（三单合并）.docx 正式件 · 证据链 × 规则匹配 × 初判建议 · 主管签字栏
• DM-02_证据缺口清单.xlsx 每单缺什么证据 / 补证路径 / 时限
• DM-02_历史判例对照表.xlsx 同类纠纷历史结论 × 本次建议 · 矛盾点标红

Skill 里固化了什么：医药费那 300 元被单独拎出来了历史判例翻出了一笔旧账排除性结论把技术动作翻译成钱

输入清单：订单履约时间线下单、接单、出餐、取餐、送达各节点时间纠纷沟通记录用户诉求、商家主张、骑手陈述的原始记录赔付规则与历史判例规则文本 + 本平台同类纠纷的历史结论补充证据材料照片、就医凭证、承认记录等

人工边界：判责结论必须人工签批：本场景只出证据链、规则匹配结果与建议，「商家/骑手/用户/平台责任」的认定与赔付金额由运营负责人签字；食安类纠纷的证据不足时按「存疑有利于用户」的监管口径建议保守处置，但建议不等于结论。

升为客户真实案例还缺什么：客户当前真实输入文件（不要整理过的）岗位现行 SOP 与审批链（金额分档、谁签字）至少一次真实出过问题的案例客户当前正在用的正式输出模板客户确认的阈值口径（多少天算临期、多少金额算大额）

5. 同一角色下的其他场景

客诉与判责 · 产出即下一步输入

• DM-01 · 客诉工单分诊与优先级：群里 1,200 条消息，食安的那条不能沉底

上下游串起来就是完整链路。每一步的产出都是下一步的输入，不用在不同工具之间来回复制粘贴。

场景内容基于 WorkBuddy 产品能力整理，演示中的企业、人物与数据均为虚构，不代表任何客户的实际成效；痛点引用的公开来源已做脱敏处理。网页版由原资料转换，部分演示表格以原文形式展示。