循据 / CHAPTER 01

一、业务背景与目标

1.1 项目背景与问题

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

本案以“客服收到一句不完整的售后问题”为起点。直接搜到退款政策仍不足以回复：客服需要确认商品范围、签收天数、使用情况以及政策是否有效。“签收3天可以退吗”缺少使用条件；“已经用过”与表单“未使用”冲突时，继续输出肯定草稿会放大误判。因此首期聚焦条件核对与依据展示，不把自动解决工单作为目标。

1.2 用户故事

1.3 业务目标与预期价值

目标是让客服在一个页面完成“补条件—查依据—核结论—编辑草稿—留下决定”。预期价值是减少漏核条件与往返查找，是否节时已通过任务对照初步验证。需求频率与人效基线已通过任务对照初步验证（见第七章）。

循据 / CHAPTER 02

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

2.1 业务问题类型与名词说明

本案首先是条件明确的规则问题，其次才是问题理解与措辞组织。签收天数、使用状态和生效日期不能交给生成模型自由判断。

2.2 竞品分析

以下依据2026-10-16已读取的官方资料，比较同一核对任务，不作价格或效果排名。

竞品均为 AI Copilot，而本案例首期是规则引擎——这并非落后，而是刻意顺序：先把「签收几天能否退」这类确定性事实交给规则核对，再把不可确定的「理解与表达」留给后续模型，避免让大模型去判断不该由它判断的合规事实。

2.3 方案选择与能力边界

当前链路为任务选择→有效政策筛选→有限短语冲突检查→确定性判断→模板草稿。搜索仅按任务、范围和有限双字串命中展示资料，没有向量检索或真实模型调用。

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

循据 / CHAPTER 03

三、数据来源与标注

3.1 数据源清单与知识构建

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

构建步骤是按退款、配送、改址拆分条目→写明范围与结构化结论→配置生效区间→加入失效及冲突样本→运行固定输入核对。未来知识入库应增加来源权限、去重、人工审核和发布记录；当前不自动抓取企业文档或更新政策。

3.2 核心字段/字典

3.3 数据质量、标注与安全

测试题应记录原话、任务、已确认条件、政策版本、预期状态、引用和理由，覆盖正常、缺失、冲突、无依据与越界。开发题用于改规则；独立题须先固定期望再运行，分歧保留理由后复核。

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

循据 / CHAPTER 04

四、产品入口与落地方案

4.1 产品入口与适用范围

入口为客服工作台，服务对象是进行政策核对的客服。首期用独立网页验证任务流程；未来是否嵌入客服侧边栏，取决于用户任务观察和现有系统接口。客户自助入口、工单系统接入不属于当前交付。

4.2 产品方案/流程

4.3 前后条件与回答规则

前置条件：教学政策和本地存储加载成功，客服明确本次任务；退款核实签收天数及使用状态，配送核实地区，改址核实是否发货。问题包含多个任务时，确认主任务只表示本次处理这一项，其他任务继续列为待处理。

后置条件：得到可核对草稿，或得到明确的补充/核实/转业务系统提示。确认后形成本机记录，不产生退款、外发消息或修改真实地址的业务结果。

4.4 可运行样例与结果呈现

在工作台选“退款申请条件”，输入“签收3天，未使用，可以申请退款吗？”，填写3天、未使用、默认知识集合，再点击核对。结果应引用 RET-001 v1.0，表达“符合7天内退款申请条件，可申请审核”，同时说明申请不等于批准。

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

循据 / CHAPTER 05

五、人机协作设计

5.1 核心流程与职责

系统负责检查已配置条件、筛选依据和组织模板；客服负责核实事实、判断政策是否适用以及决定草稿能否使用。知识维护角色处理政策更正与发布，业务系统承担订单查询和实际操作，不能用保存草稿替代业务办结。

5.2 业务协作异常

5.3 工具地图与交接信息

当前工具为本地政策读取、规则核对、有效资料搜索、浏览器事务保存，没有外部订单API。后续如接订单查询，必须带授权订单标识、返回时间及失败原因；如接知识工单，至少交接问题、条件、引用版本、拒绝理由和责任人。

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

循据 / CHAPTER 06

六、原型与交互设计

6.1 原型阅读说明

打开可操作原型。工作台包含核对页面、知识列表和历史记录；用退款正常样例、缺条件样例及改址冲突样例即可进入主分支。先读条件和来源，再看草稿，最后操作保存。

6.2 核心交互路径

主路径：选择退款示例→核对条件→查看 RET-001→修改措辞→确认保存→打开历史记录读回。与客户沟通前仍由客服决定如何使用。

缺条件路径：清空“是否使用”→重新核对→出现待补充提示且无可保存草稿→补齐真实状态→再次核对。冲突路径：把原话改为“已经用过，能退款吗”，表单保留未使用→进入需人工核实→核实后修正表单再运行。

6.3 交互细节与保存验收

核对中锁定输入和按钮，避免重复触发；仅搜索资料不生成可保存分析。修改问题或任一条件，清空旧草稿并关闭保存；旧规则版本恢复时要求重新核对。草稿编辑与事实变更分开处理，前者记录新修订，后者重新分析。

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

循据 / CHAPTER 07

七、评估体系与风险兜底

7.1 可复核验收标准

7.2 数据表现与口径说明

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

漏核条件率为遗漏必填条件即生成结论的任务占比；耗时仅统计正确完成任务，同时报告正确完成比例。

7.3 风险兜底与预期价值验收

严重错误单列，包括把未知当未使用、无来源作肯定结论和声称已执行退款，不能被总体通过率掩盖。知识加载或存储初始化失败时关闭核对入口；无依据、冲突转人工。未来模型超时、引用不支持结论或条件不确定时，回到原文与检查单，不自动放行。

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

循据 / CHAPTER 08

八、版本规划与迭代

8.1 真实迭代记录

8.2 版本规划与迭代闭环

P0为当前可操作核对流程：三类任务、条件与来源、异常阻断、编辑及本机记录。P1计划增加拒绝原因分类、知识缺口责任人和任务耗时观察；先确认反馈能被维护者处理，再扩展知识。

P2是模型验证：冻结独立验收集，在相同快照下比较文档搜索、规则模板和RAG；记录模型、提示词、原始响应、失败重试、时延与费用。只有来源、条件和回复均可核验后，再讨论授权订单查询。P1/P2没有承诺实施日期，按验收结果决定是否推进。

8.3 项目资源与证据索引

资源包括自建教学政策、浏览器工作台、固定测试集、官方公开文档与原案例库方法参考。本人独立完成选题、业务规则设计与验证方案，Agent 辅助资料整理和原型实现；无企业客户、真实订单接口或上线收益记录。

本案例直接引用S01 Microsoft客服Copilot与S02 Intercom使用建议。其余公开资料统一列入资料索引，分别支持供采和履约案例。

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

订单拆单 / CHAPTER 01

一、背景与问题

1.1 项目背景与问题

在上海艾哲智网络科技担任后台产品实习生期间，我在全棉时代客户的订单履约项目中，独立梳理拆单条件、主子单关系及异常处理规则，主笔原型、评审与验收方案。该项目在实习前已由团队立项并完成前期开发，本人加入后负责拆单规则梳理、原型与试点验收。

多商品订单中，一部分商品已有库存，另一部分仍待补货。按整单齐套后发货，现货也会被缺货商品阻塞；直接拆分又会增加包裹和运费，并带来库存占用、部分取消及状态查询问题。因此需要在交付时效、额外费用与订单可追溯之间作出取舍。

方案针对已支付、尚未下发仓库的普通实物订单：先检查是否有仓库能够整单履约；若没有，再核对分批授权和费用条件，将现货与待补商品拆成两批。主例采用无额外优惠的交易金额快照：棉柔巾2包、棉湿巾1包、婴儿纱布浴巾1条，行实付分别为69.80元、29.90元、89.00元，总计188.70元。浴巾缺货时，99.70元现货进入首批履约，89.00元待补。

1.2 用户故事

1.3 名词说明

1.4 试点范围与数据口径

试点覆盖全棉时代天猫旗舰店棉品商品组，时间为2024年6月1日—6月14日，共14天，覆盖618活动期间；对照取2023年6月1日—6月14日同渠道、同商品组的部分缺货订单。对照组取去年618活动同期历史订单数据，与试点期活动条件可比。

取消率按各自14天统计窗口内的缺货取消订单数除以对应部分缺货订单数计算，相较历史同期下降约8个百分点。取消笔数按“买家主动发起取消且退款原因归类为发货超时 / 缺货等待”从退款工单表筛选，不包含尺码不合、质量问题等其他取消原因。

试点1,240笔订单中，60笔提交前被准入阻断（40笔缺分批授权、20笔费用超限）；1,180笔进入提交，首次成功1,172笔，8笔遇到订单版本冲突。首次提交成功率约99%。版本冲突单进入重新读取、校验与重试流程，单独记录，不等同于终局业务失败。

1,172笔成功拆分订单的增量履约成本合计约7,000元，单均约6元，包含运输、包材和作业成本；运输费用按方案费率测算。汇总与计算口径见试点统计表，效率和时效变化见6.1。

订单拆单 / CHAPTER 02

二、竞品分析

2.1 三平台分批履约能力对比

三家的共同设计要点是保留交易、履约批次与物流包裹的关联，并处理部分发货状态。本项目将补货重新校验、授权记录、库存占用和取消试算串联到同一操作流程。

2.2 差异化定位

2.3 可借鉴的点与渠道约束

渠道准入按“渠道＋类目＋订单类型＋活动规则版本”配置；任一必需规则未知时，默认关闭自动拆单，交由运营核对后再启用。

订单拆单 / CHAPTER 03

三、产品方案

3.1 核心思路

有货先发，缺货单独等待，补货后继续履约。 先检查能否由单仓整单发出；无法整单履约时，将现货生成主单、缺货生成子单。父订单统一保留付款和优惠，运营可调整拆分方案，补货事件触发子单重新检查。

仓库选择与约束比较见多仓智能分仓案例。

3.2 旧流程与新流程

3.3 前置与后置条件

预计增量成本＝分批运输、包装及操作成本合计－整单一次履约对应成本；实际结算还需核对售后等费用。演示默认费用上限8元、待补金额门槛12元，仅为可调整的示例参数，不是测得的最优值或通用业务结论。超限由授权人员审批或保持整单等待；人工审批不替代买家分批授权，不因拆包向买家新增运费。

3.4 子单状态与库存账

待补货 → 已备待发 → 拣货打包 → 已出库 → 已完成。待补、待发可取消；拣货中取消需仓库拦截，成功才释放库存，失败继续拣货，超时升级人工并保持占用。只有实际出库回执才转已出库并走售后。父单在全部商品完成或取消后结束履约。

库存账分别记录实物、不可售、订单占用与可用数量，且每笔占用可追到订单、履约单及SKU。确认拆单时，主单按需求占用现货，待补单也按各行欠量预留当前可得库存；已有预占订单优先迁移占用归属，或由库存服务做一致性调整，不先释放到公共池再重新抢占。操作失败保持原账，出库才减少实物库存。

待补子单保留其他现货及赠品已取得的占用，即使尚未齐套仍保持待补货；后续补货只补足欠量。例如赠品GF可用10件、当前任务需求1件，确认时仅占用1件，可用剩余9件，不占满库存池。取消只释放该范围实际持有的占用。没有占用的缺货行取消时不增加库存。生产中的一致性实现由研发结合库存服务能力确定。

3.5 核心改动点

独立优惠例： 这是一笔不同于主例的交易快照，优惠前208.70元，使用20.00元券。消费上游交易系统已给出的行级分摊，不给主例188.70元再减一次优惠。

纯履约拆分不重算满减资格。赠品绑定浴巾，不参与金额分摊。缺少上游优惠明细时先阻断金额确认并核对，不在履约环节自行猜分摊。

原型提供“赠品缺货”场景，补齐浴巾后可核对默认等待与经授权取消赠品的差异。本期不开放第三批赠品后补，维持最多两批；任何补发或替换承诺均需另行方案评审。

取消与退款试算： 取消前按渠道、活动版本、发起原因及仓库状态确定策略，分别展示分摊本金、优惠扣回、运费调整与预计退款结果。赠品随关联商品核对，政策未知则阻断退款确认。

退款保留两种处理策略：保留其余商品原优惠，或按活动规则追回保留商品的已享优惠后净退。策略未知不生成可确认结果；后续取消范围变化须重新试算。逐项金额放在交互原型中核对，不执行实际支付退款。

三单争抢两件补货： 同仓W1有三笔有效待补任务，各缺浴巾1件，本次补货仅2件。排序取原始承诺与该任务已登记的内部跟进期限中较早的时间，再按支付时间、订单号稳定排序。本例以2024年6月8日00:00为基准，任务的跟进期限如下，按登记期限排序。

实际顺序为A→B→C；无承诺任务按已登记的内部跟进期限参与排序，不无限后置。每次分配前重查订单有效性、仓库和所有SKU：本任务既有占用＋当前可新增占用必须满足全部需求，才一次性补足占用并转待发。若A另缺关联赠品小方巾（GF）且未占用到足量，则跳过A并记录赠品不足，两件浴巾可分给B、C；该队列采用默认赠品同批策略，A原有占用继续保留；需要切换赠品策略时，先完成单订单例外核对，不能由队列自动少发赠品。已取消任务排除，其他任务已占库存不计入可分配量，重复事件不再次增加可用量或占用。本排序是最小方案选择，后续可结合实际服务等级评审。

3.6 时间、授权与异常处理

原始发货承诺来自订单渠道，不随补货计划静默顺延。补货计划负责人维护预计补货可用时间，包含到货后的收货、质检等环节；运营核验客户侧安排，修改保留版本及原因。预计到货不直接等于可发货。

发现缺货即建任务、指定负责人并发起必要沟通。时间管理保留两个概念：内部跟进期限和承诺提前预警。取“发现时间＋内部跟进时限”与“原始承诺－预警提前量”的较早值；没有原承诺则采用内部期限，进入风险窗口立即升级。原型以发现后2小时、承诺前4小时演示，可按服务要求调整。补货预计可用时间缺失时立即向负责人确认，到期仍未解决则升级并登记下一次跟进。

3.7 附录：接口协作边界

我独立梳理业务输入、维护异常规则清单与阻断条件，主笔授权范围、状态变化和验收场景的协作约定；产品经理评审业务方案，研发确定接口及库存一致性的技术实现。

订单拆单 / CHAPTER 04

四、原型交互与数据字典

4.1 原型交互

打开拆单确认原型。页面展示交易金额快照、主子单预览及商品勾选、“保持整单等待”“确认拆单”操作。缺货行不能进入主单，勾选变化后按原交易快照汇总金额。

原型覆盖正常拆分、授权缺失、费用门槛、优惠与赠品、取消试算、拣货拦截、既有占用迁移及三单补货分配。补货、出库、签收和取消均为本地演示操作，支付退款不执行。交互记录只保存在当前页面，刷新恢复初始场景。

4.2 数据字典

订单拆单 / CHAPTER 05

五、项目资源

5.1 排期与资源

以下为交付资源与上线验证计划。

5.2 我在其中的角色

订单拆单 / CHAPTER 06

六、预期价值与验收标准

6.1 试点结果

两组采用相同渠道和商品组，对照期为2023年6月1日—6月14日（去年618活动同期历史数据），试点期为2024年6月1日—6月14日。取消率展示为整百分比，成本展示为约数；完整数量和复算公式见试点统计表。

6.2 验收标准

多仓路由 / CHAPTER 01

一、背景与问题

1.1 业务背景与核心问题

在上海艾哲智网络科技的后台产品实习中，我在全棉时代客户的多仓履约项目中，独立梳理订单分仓条件、候选仓排序及人工调整规则。该项目在实习前已由团队立项，本人加入后负责候选仓排序、人工调整规则及试点验收。

订单能否从某仓发出，不仅取决于收货地，还取决于商品库存、仓库启停、处理负载和数据时效。固定区域分仓难以覆盖临时缺货与拥堵；只按距离选择最近仓，也可能把订单分给无法承接的节点。项目需要在完整履约的前提下选择合适的发货仓，并让运营能理解、调整和追溯分配结果。

方案在支付后、仓库开始拣货前进行路由决策，先过滤不满足条件的仓，再按距离推荐。以深圳收货、购买棉柔巾2包及棉湿巾1包为例：佛山节点满足库存与容量条件时进入候选；缺货、停用或拥堵时展示剔除原因，选择下一可行节点。所有节点均不满足条件时，订单转待处理。

1.2 用户故事

1.3 名词说明

1.4 数据表现与口径说明

以下为 10 条固定场景的测算演示，用于验证路由规则按设计运行，非真实业务订单统计。展示参数采用佛山、苏州、武汉、成都、天津五个区域节点，固定武汉节点为演示基线，不代表客户真实分仓策略。5 条正常配置场景用于成对比较，5 条节点变化场景用于异常验收（关闭原仓后改选可行仓）。换仓率统计发货仓与原分配仓是否一致，远距离分配率统计直线距离是否超过 500km 阈值，两者分别计算。

远距离分配率的 500km 为分析分组阈值，用于粗筛远距离分配，不代表必然的运输里程、成本或时效边界。试点期承运商分段费率：≤500km 为 5.80 元、500—1200km 为 7.20 元、>1200km 为 9.00 元，统一计费重量、无附加费，与单均估算运费 6.36 元的方案测算口径一致。以五个收货城市、每城两条订单构成 10 条固定场景，另在第二条中关闭第一条推荐的可行节点，检查替代推荐；查看十组路由对照与节点参数。

多仓路由 / CHAPTER 02

二、竞品分析

2.1 主流产品方案对比

本案例对标「分仓 / 多仓履约能力」，选取京东全渠道履约、旺店通 ERP、Shopify 三类具备就近分仓与容量分配能力的代表产品；与订单拆单案例对标「平台缺货拆单规则」（京东、淘宝、抖店）的视角不同。

本项目落点：支付后检查候选仓的库存、启停、容量和时效，再推荐最近可行仓；运营可改选合格候选，确认时重新校验库存并占用。

2.2 差异化定位

2.3 可借鉴的点与后续规划

多仓路由 / CHAPTER 03

三、产品方案

3.1 核心思路

把“固定仓发货”改为“最近的可行仓发货”。 收货地址确定后，先筛选全量SKU有货、已启用且容量允许的仓库，再按距离排序。推荐结果供运营确认或改选；确认时复核库存，成功占用后再下发WMS。

3.2 旧流程与新流程

3.3 路由推荐规则

3.4 极端情况与异常处理

3.5 关键接口设计

路由由OMS履约编排层决定，WMS提供库存与接单结果，物流侧重新计算面单和揽收信息。

多仓路由 / CHAPTER 04

四、原型交互与数据字典

4.1 原型交互

打开路由运营原型。包含“路由推荐—规则配置—健康监控”三个页面。推荐页展示订单、收货城市、候选表、当前建议及确认入口；人工调整只能选择满足条件的节点并填写原因。

配置页可修改节点启停、SKU库存、负载与数据时效；修改后旧推荐失效。监控页按当前输入显示缺货、超载与过期节点，不使用预置“已处理成功”的假通知。确认后展示实际选择节点与占用结果；刷新恢复场景初始值。

4.2 数据字典

多仓路由 / CHAPTER 05

五、项目资源

5.1 排期与资源

5.2 我在其中的角色

多仓路由 / CHAPTER 06

六、预期价值与验收标准

6.1 场景测算与预期价值

10 条固定场景（5 条正常配置、5 条节点变化）验证路由规则按设计运行：5 条正常场景中远距离分配率从 80% 降至 40%、换仓率 40%、单均估算运费从 6.92 元降至 6.36 元；节点变化场景用于异常验收，不用于降本效果。出库时效与真实业务改善为后续观测指标。以下目标与验证口径用于后续放量复评。

6.2 验收标准