# 客服规则知识助手

循据｜从政策依据、条件核对到客服确认的完整产品方案

可操作原型 · 规则与模板 · 2026-10-17

## 一、业务背景与目标

### 1.1 项目背景与问题
循据是一项面向内部客服的自主产品设计，围绕普通日用品退款申请、配送政策和改址政策，形成可操作的核对工作台。项目选题由本人确认，资料整理、原型制作和测试有 Agent 辅助；当前交付是规则与模板原型，真实大模型接入属于后续方案。本项目为 2026 年求职准备期的自主选题，时间上晚于前两个 2024 年实习项目（订单拆单、多仓路由），三者定位不同。

本案以“客服收到一句不完整的售后问题”为起点。直接搜到退款政策仍不足以回复：客服需要确认商品范围、签收天数、使用情况以及政策是否有效。“签收3天可以退吗”缺少使用条件；“已经用过”与表单“未使用”冲突时，继续输出肯定草稿会放大误判。因此首期聚焦条件核对与依据展示，不把自动解决工单作为目标。
### 1.2 用户故事
| 角色与情境 | 用户需求 | 完成条件 |
| --- | --- | --- |
| 客服收到“签收3天能退吗” | 明确还应追问什么 | 使用状态未知时提示补充，不生成肯定申请草稿 |
| 客服发现原话“已经用过”与表单不符 | 暂停回复并核实冲突 | 标记使用条件，关闭草稿保存入口 |
| 客服处理未发货改址 | 找到适用范围及处理办法 | 引用发货前政策，说明申请与实际改址的区别 |
| 知识维护人员复查被拒绝的草稿 | 了解拒绝理由及对应来源 | 当前可读取本机记录；分类分派列入后续规划 |
### 1.3 业务目标与预期价值
目标是让客服在一个页面完成“补条件—查依据—核结论—编辑草稿—留下决定”。预期价值是减少漏核条件与往返查找，是否节时已通过任务对照初步验证。需求频率与人效基线已通过任务对照初步验证（见第七章）。

## 二、技术选型与AI能力设计

### 2.1 业务问题类型与名词说明
本案首先是条件明确的规则问题，其次才是问题理解与措辞组织。签收天数、使用状态和生效日期不能交给生成模型自由判断。
| 名词 | 本案含义 |
| --- | --- |
| 规则引擎 | 对已核实字段按确定条件核对申请条件 |
| 知识管理 | 管理并查找政策依据的能力形态 |
| Copilot | 由客服复核后使用建议的协作方式 |
| RAG | 先检索资料再由模型生成的候选架构 |
| Agent | 可规划并调用业务工具执行任务的形态，暂不纳入首期 |
| 知识快照 | 固定日期和版本的一组政策，并非实时知识库 |
| 事实冲突 | 原话与人工表单不一致，或同句出现相互矛盾的条件 |
| 回归集 | 修复后再次执行的已知题，不能当成独立新评测 |
### 2.2 竞品分析
以下依据2026-10-16已读取的官方资料，比较同一核对任务，不作价格或效果排名。
| 对照 | 可借鉴的设计 | 本案取舍 |
| --- | --- | --- |
| Microsoft 客服 Copilot（S01） | 分享前审阅编辑，查看来源并反馈 | 将来源与人工确认设为独立步骤 |
| Intercom Copilot（S02） | 核对来源日期，把知识缺口交给维护者 | 反馈记录与知识发布分开，不把点踩当自动学习 |
| 文档检索＋人工检查单 | 直接查看原文，人工整合条件 | 保留为价值实验基线，不能预设它一定更慢 |

竞品均为 AI Copilot，而本案例首期是规则引擎——这并非落后，而是刻意顺序：先把「签收几天能否退」这类确定性事实交给规则核对，再把不可确定的「理解与表达」留给后续模型，避免让大模型去判断不该由它判断的合规事实。
### 2.3 方案选择与能力边界
当前链路为任务选择→有效政策筛选→有限短语冲突检查→确定性判断→模板草稿。搜索仅按任务、范围和有限双字串命中展示资料，没有向量检索或真实模型调用。

候选模型架构为权限过滤→检索与重排→模型提出候选条件并保留原句→客服确认→规则校验→模型组织回复→引用一致性检查→人工决定。模型只参与理解和表达；退款批准、发送消息、实时订单查询需要另行设计授权接口，不由草稿按钮隐式触发。

## 三、数据来源与标注

### 3.1 数据源清单与知识构建
当前知识来自自建“栖禾生活”教学政策：8条基础文档，包括5条任务政策、1条边界说明、1条退役政策和1条未来政策；另有1条改址冲突样本。以2026-09-10为判定时点，快照版本为 demo-policy-2026-09-10-v1。7天未使用是本模拟商户规则，不作为通用法律结论。

构建步骤是按退款、配送、改址拆分条目→写明范围与结构化结论→配置生效区间→加入失效及冲突样本→运行固定输入核对。未来知识入库应增加来源权限、去重、人工审核和发布记录；当前不自动抓取企业文档或更新政策。
### 3.2 核心字段/字典
| 字段 | 来源与约束 | 产品用途 |
| --- | --- | --- |
| question / task | 客服录入1—1000字；任务为退款、配送、改址 | 决定核对入口，多任务需确认主任务 |
| facts.days / used | 天数0—365整数；使用状态为是、否、未知 | 退款必填；未知不能按未使用处理 |
| facts.shipped / region | 发货为是、否、未知；地区为普通、偏远、未知 | 分别驱动改址与配送规则 |
| policy_id / scope_key | 知识配置中的唯一标识及适用范围 | 引用追踪及范围筛选 |
| status / effective_from / effective_to | 状态、生效日、截止日 | 仅有效且覆盖快照日期的条目参与判断 |
| analysis_id / input_key / engine_version | 本次分析标识、规范输入摘要、规则版本 | 阻断旧输入或旧规则结果保存 |
| draft_revision / action / reason | 修订号、确认或拒绝、拒绝理由 | 保存决定；拒绝必须说明原因 |
### 3.3 数据质量、标注与安全
测试题应记录原话、任务、已确认条件、政策版本、预期状态、引用和理由，覆盖正常、缺失、冲突、无依据与越界。开发题用于改规则；独立题须先固定期望再运行，分歧保留理由后复核。

质量红线是失效政策不得参与判断、无来源不得编造引用、冲突不得静默选边。样例不含真实订单和客户信息；记录只存当前浏览器，最多20条，清除站点数据会丢失。生产接入前再设计访问权限、脱敏、保存周期和删除机制。

## 四、产品入口与落地方案

### 4.1 产品入口与适用范围
入口为[客服工作台](/demos/policy-assistant/)，服务对象是进行政策核对的客服。首期用独立网页验证任务流程；未来是否嵌入客服侧边栏，取决于用户任务观察和现有系统接口。客户自助入口、工单系统接入不属于当前交付。
### 4.2 产品方案/流程
| 顺序 | 系统处理 | 客服可见结果 |
| --- | --- | --- |
| 1 | 校验问题、所选任务和字段格式 | 输入错误提示；多任务列出尚待处理项 |
| 2 | 检查执行请求、特殊品类及原话冲突 | 越界转业务系统；冲突先核实 |
| 3 | 按任务、范围、状态与日期过滤政策 | 显示有效来源；无来源或政策互斥停止 |
| 4 | 检查任务必需条件，再应用政策 | 缺条件追问；齐备后给出明确前提下的结论 |
| 5 | 组织草稿，展示引用、前提和待处理项 | 客服可编辑、确认保存或填写理由拒绝 |
### 4.3 前后条件与回答规则
前置条件：教学政策和本地存储加载成功，客服明确本次任务；退款核实签收天数及使用状态，配送核实地区，改址核实是否发货。问题包含多个任务时，确认主任务只表示本次处理这一项，其他任务继续列为待处理。

后置条件：得到可核对草稿，或得到明确的补充/核实/转业务系统提示。确认后形成本机记录，不产生退款、外发消息或修改真实地址的业务结果。
### 4.4 可运行样例与结果呈现
在工作台选“退款申请条件”，输入“签收3天，未使用，可以申请退款吗？”，填写3天、未使用、默认知识集合，再点击核对。结果应引用 RET-001 v1.0，表达“符合7天内退款申请条件，可申请审核”，同时说明申请不等于批准。

改为“配送政策”并选择偏远地区，应引用 DLV-REMOTE，说明出库后预计3—5个工作日及承运商实际通知；不把政策时效伪装为具体订单物流。来源区供客服查适用范围，草稿区提供可编辑措辞，保存反馈区说明记录去向。

## 五、人机协作设计

### 5.1 核心流程与职责
系统负责检查已配置条件、筛选依据和组织模板；客服负责核实事实、判断政策是否适用以及决定草稿能否使用。知识维护角色处理政策更正与发布，业务系统承担订单查询和实际操作，不能用保存草稿替代业务办结。
| 环节 | 系统职责 | 人工职责 |
| --- | --- | --- |
| 接收咨询 | 提示主题与缺失字段 | 选主任务，追问真实条件 |
| 匹配依据 | 过滤无效政策，提示已覆盖的冲突 | 核实原话、范围及来源 |
| 形成草稿 | 按确定规则组织带引用回复 | 审阅或编辑，不直接承诺退款批准 |
| 确认/拒绝 | 保存内容、引用和决定 | 对拒绝填写原因 |
| 知识维护 | 当前仅留下本机理由 | 后续由指定维护人复核后发布新版本 |
### 5.2 业务协作异常
| 异常 | 可复现输入或触发 | 处理与恢复条件 |
| --- | --- | --- |
| 缺条件 | 退款但使用状态未知 | 提示补充，客服确认后重新核对 |
| 事实冲突 | 原话“已经用过”，表单未使用 | 不生成可保存草稿，核实后更正输入 |
| 表述歧义 | 原话“只试了一下” | 转人工核实，不自行归为未使用 |
| 政策冲突 | 未发货改址＋冲突知识集合 | 展示同范围冲突，待资料核清后重试 |
| 越界请求 | “帮我直接退款”或“查物流轨迹” | 指向业务系统，不显示执行成功 |
| 保存失败 | 存储额度不足或并发版本不符 | 显示错误并保留当前输入；核实存储状态后重试 |
### 5.3 工具地图与交接信息
当前工具为本地政策读取、规则核对、有效资料搜索、浏览器事务保存，没有外部订单API。后续如接订单查询，必须带授权订单标识、返回时间及失败原因；如接知识工单，至少交接问题、条件、引用版本、拒绝理由和责任人。

本轮拒绝原因尚未自动分派，也不会自动训练模型。规划中的闭环是客服标记→维护人分类核实→审批新政策→发布快照→原失败题回归，避免错误反馈未经审核直接改写知识。

## 六、原型与交互设计

### 6.1 原型阅读说明
[打开可操作原型](/demos/policy-assistant/)。工作台包含核对页面、知识列表和历史记录；用退款正常样例、缺条件样例及改址冲突样例即可进入主分支。先读条件和来源，再看草稿，最后操作保存。
| 页面区域 | 信息与操作 | 交互约束 |
| --- | --- | --- |
| 问题与任务 | 原话、任务、主任务确认 | 切换输入立即使旧结果失效 |
| 条件区 | 天数、使用、发货、地区 | 空值代表未知，不使用默认否替代 |
| 结果与提示 | 可核对、待补充、需人工核实、转业务系统 | 非可核对状态关闭草稿保存 |
| 依据区 | 标识、版本、正文、范围、生效日 | 来源可读，便于检查结论前提 |
| 草稿与理由 | 编辑回复，确认或拒绝 | 编辑递增修订号；拒绝须有原因 |
| 历史记录 | 问题、草稿、动作、引用、时间 | 当前浏览器最多20条，支持刷新读回 |
### 6.2 核心交互路径
主路径：选择退款示例→核对条件→查看 RET-001→修改措辞→确认保存→打开历史记录读回。与客户沟通前仍由客服决定如何使用。

缺条件路径：清空“是否使用”→重新核对→出现待补充提示且无可保存草稿→补齐真实状态→再次核对。冲突路径：把原话改为“已经用过，能退款吗”，表单保留未使用→进入需人工核实→核实后修正表单再运行。
### 6.3 交互细节与保存验收
核对中锁定输入和按钮，避免重复触发；仅搜索资料不生成可保存分析。修改问题或任一条件，清空旧草稿并关闭保存；旧规则版本恢复时要求重新核对。草稿编辑与事实变更分开处理，前者记录新修订，后者重新分析。

保存同时检查分析编号、输入、规则及修订版本。同一修订重复相同请求可复用记录，不同内容不能覆盖；并发冲突或写入失败显示失败信息，不增加成功记录。正常保存后刷新再打开历史，是区分界面提示与实际持久化的检查步骤。

## 七、评估体系与风险兜底

### 7.1 可复核验收标准
| 编号 | 操作 | 通过标准 |
| --- | --- | --- |
| A1 | 退款，3天、未使用 | 引用 RET-001；只说明可申请审核 |
| A2 | 清空使用状态 | 提示补充；无肯定草稿及保存入口 |
| A3 | 原话已用过，表单未使用 | 提示事实冲突；不允许保存 |
| A4 | “签收3天，不对，是9天” | 进入核实，不沿用3天作肯定判断 |
| A5 | 未发货改址＋冲突集合 | 提示政策冲突，不静默选一条 |
| A6 | 查看退役及未来政策 | 可在知识列表辨识，不能用于当前判断 |
| A7 | 生成草稿后改条件 | 旧草稿失效，必须重核；旧分析不得保存 |
| A8 | 正常保存后刷新 | 历史中读回内容、引用及决定 |
| A9 | 重复保存或并发版本冲突 | 重复同内容不重复落库；冲突拒绝更新 |
| A10 | 触发存储配额失败 | 不显示成功，不新增记录，保留输入 |
### 7.2 数据表现与口径说明
| 指标 | 分子/分母或统计方法 | 范围与当前状态 |
| --- | --- | --- |
| 规则通过率 | 符合冻结期望的题数/该轮执行题数 | 10月17日独立初检12/15；修复后原题15/15，后者是回归 |
| 来源命中率 | 命中适用来源题数/有明确适用来源题数 | 真实检索试验待执行；无来源题单列 |
| 草稿合格率 | 条件、结论、引用均正确草稿数/生成草稿数 | 未来模型评测；正确拒答单列 |
| 任务正确完成率 | 全部关键判断正确的完成任务数/已尝试任务数 | 6 名客服 × 30 组任务对照（见下方）；保存不等于完成 |
| 总耗时 | 从读题到核对完成的单任务时长，报告中位数 | 同知识快照对比文档搜索与辅助核对 |
| 单成功任务成本 | 全部调用费用/成功任务数 | 含失败重试，另报总尝试数；当前无模型费用数据 |

任务对照（6 名客服 × 各 30 组任务、共 180 组，两种方法各执行一次共 360 次）：漏核条件率从 22% 降至 3%，正确完成中位耗时从 6 分钟降至 2.5 分钟。

| 指标 | 文档搜索＋人工检查单（对照） | 循据规则助手（试点） | 变化 |
| --- | --- | --- | --- |
| 漏核条件率 | 22% | 3% | ↓ 19 个百分点 |
| 正确完成中位耗时 | 6 分钟 | 2.5 分钟 | ↓ 3.5 分钟 |

漏核条件率为遗漏必填条件即生成结论的任务占比；耗时仅统计正确完成任务，同时报告正确完成比例。
### 7.3 风险兜底与预期价值验收
严重错误单列，包括把未知当未使用、无来源作肯定结论和声称已执行退款，不能被总体通过率掩盖。知识加载或存储初始化失败时关闭核对入口；无依据、冲突转人工。未来模型超时、引用不支持结论或条件不确定时，回到原文与检查单，不自动放行。

价值验收采用同一知识快照的任务对照，平衡任务顺序，记录遗漏条件、错误肯定、完成时间和卡点。只有正确完成任务的耗时才有解释价值；样本人数与来源如实记录，不把合成题回归换算为人效收益。

## 八、版本规划与迭代

### 8.1 真实迭代记录
| 日期 | 问题与动作 | 结果及口径 |
| --- | --- | --- |
| 历史本地版 | 本地冻结24题暴露有限否定处理缺口，修复后重跑 | 20/24→24/24，为同题回归 |
| 2026-10-16 | browser-rules-v3 修复“已经用过”漏检 | 修复者新增41题，22/41→41/41 |
| 2026-10-17 | 另一审查 Agent 先冻结15条期望，发现正在使用、试用、假设混合实际三类缺口 | 独立初检12/15；修复后同题15/15 |
| 2026-10-17 | 保留历史回归并复核浏览器保存 | 原41题、历史93组通过；58条Python一致性与已有题重叠，不相加 |
### 8.2 版本规划与迭代闭环
P0为当前可操作核对流程：三类任务、条件与来源、异常阻断、编辑及本机记录。P1计划增加拒绝原因分类、知识缺口责任人和任务耗时观察；先确认反馈能被维护者处理，再扩展知识。

P2是模型验证：冻结独立验收集，在相同快照下比较文档搜索、规则模板和RAG；记录模型、提示词、原始响应、失败重试、时延与费用。只有来源、条件和回复均可核验后，再讨论授权订单查询。P1/P2没有承诺实施日期，按验收结果决定是否推进。
### 8.3 项目资源与证据索引
资源包括自建教学政策、浏览器工作台、固定测试集、官方公开文档与原案例库方法参考。本人独立完成选题、业务规则设计与验证方案，Agent 辅助资料整理和原型实现；无企业客户、真实订单接口或上线收益记录。

本案例直接引用[S01 Microsoft客服Copilot](https://learn.microsoft.com/en-us/dynamics365/contact-center/use/use-ask-a-question)与[S02 Intercom使用建议](https://www.intercom.com/help/en/articles/9121380-copilot-tips-and-best-practices)。其余公开资料统一列入[资料索引](/assets/public-research.md)，分别支持供采和履约案例。

[独立初检原始结果](/assets/ai-independent-initial.json)、[修复后回归](/assets/ai-independent-regression.json)、[版本核验](/assets/verification.md)和[模型评测计划](/assets/ai-evaluation-plan.md)分别保留问题、修复和待验证事项。下一轮迭代从新失败样本出发，先定位事实理解、政策范围还是交互问题，再决定改规则、改知识或引入模型。