# 第 39 章 客户侧案例：零售库存智能补货

## 本章目标

- **O1** 能够定义“补货建议”进入“红线结果”所需的判断条件（产物：零售案例证据链）
  - 证据: 零售案例证据链写明从“补货建议”到“红线结果”的进入条件
- **O2** 能够构造零售案例证据链，写明分支、否决项和责任人（产物：零售案例证据链）
  - 证据: 零售案例证据链至少包含一个继续分支、一个停止分支和各自责任人
- **O3** 能够在零售案例中区分补货建议、红线判定与采用观察（产物：零售案例证据链）
  - 证据: 产物记录一个建议的依据、红线结果、放行决定和待观察采用指标

## 学习路径

- **初学者**: 本章迁移任务是：能够在零售案例中区分补货建议、红线判定与采用观察。先按图中的“条件门禁”关系完成零售案例证据链的第一项证据，再逐项核对责任人与判断标准。
- **有经验者**: 先用当前项目完成这一任务：能够在零售案例中区分补货建议、红线判定与采用观察。提交零售案例证据链后，再对照正文复核关系类型、缺失证据和授权边界。

## 教学图解

- **必交产物**: 零售案例证据链
- **图解类型**: retail-evidence
- **关系语义**: 输入经过条件分支汇入明确门禁；停止与继续是互斥结果，红线不能被其他得分补偿。
- **核心概念**: 补货建议 · 红线结果 · 采用观察

![第 39 章零售案例证据链教学图](/learning/diagrams/zh/chapter-39.svg)

沿条件分支阅读零售案例证据链，在门禁处作出可追溯的停止或继续决定。

图以“补货建议”为输入，经“红线结果”的条件分支到达“采用观察”所控制的门禁。两条路径最终必须落在停止或继续之一；缺证据和红线失败不能被其他表现抵消。

> **公开课程改编版。**正文依据内部教材整理，保留概念、流程与示范。案例规模、用时、提升比例及目标阈值均用于教学，不是本站交付成果或通用标准。工具、平台与技能描述需在实际环境核验。提示词不能授予权限；重试次数不自动触发恢复；恢复须先保护工作并确认目标、共享状态和外部数据影响。

## 课程讲解

本案例为教学重组，数字为演示量级。客户、人物、对话与项目记录均为虚构，不对应真实公司的经营结果。下文所有样本数、阈值、时间安排和采用数据都是教学设定，用于检验决策过程，不能作为行业基准。

### 39.1 客户说要智能补货，现场却在核对昨天的数据

周一早上，FDE 林宁来到一家连锁零售企业的运营办公室。项目发起人要求：“先把缺货降下来，月底告诉我投入产出。”补货主管却把一张表推过来：“每天都在核对库存，系统再多一个入口，我们的人更忙。”技术负责人补充：“销售明细和供应商价格不能离开内网。”同一个项目，从第一天起就有三个不同的成功定义。

林宁没有马上承诺一个自动下单 Agent。她坐到补货员旁边，看完一次任务：库存快照已生成，异常商品已筛出，在途订单已核对，促销安排已确认，补货数量已修改，主管已批准，采购单已提交。最慢的环节并非填写数量，而是解释“为什么这个数量可信”。有的库存快照晚到，有的商品刚结束促销，还有的在途数量没有同步。

这改变了问题的定义。首期交付对象是带证据的补货建议与人工确认流程：数量由客户既有补货规则计算，模型解释依据、指出异常、提示缺失信息。模型不自行预测所有需求，也不直接向采购系统下单。这个边界让团队能够检验一个具体假设：补货员能否在保留判断权的条件下，减少反复找依据的工作。

### 39.2 三天 scoping：把博弈写成可执行边界

第一天访谈事件流，第二天盘点数据，第三天对齐进入验证期的条件。林宁发现，销售按日汇总可在项目内网读取，库存有明确快照时间，在途订单由采购接口提供，促销表却由业务人员手工维护。团队把每种数据的负责人、获取权限、更新时间和缺失时动作写入盘点表。销售明细无须进入模型上下文，解释只使用获准的聚合字段；日志记录请求编号、版本和判定结果，原始业务值留在客户受控空间。

高管希望首期覆盖所有商品，业务主管担心错误建议最终变成对员工的问责，技术团队则拒绝临时开通外部模型通道。林宁提出一个可签认的范围：限定五家门店的常温日用品，排除生鲜、新品和大促；只读数据，人工提交采购；无可靠库存时间或在途信息时，返回“待核对”，禁止生成确定数量的解释。高管保留扩围决策权，业务主管确认规则和异常处理，技术负责人拥有数据边界与发布审批权。

分歧记录里没有写“三方达成一致”就结束，而是记下交换条件：高管接受缩小范围，换取每周可复查的评估和采用报告；业务方接受试用，换取保留修改、拒绝和原流程入口；技术团队开放限定只读接口，换取内网部署、访问审计与明确接手人。FDE 可以在获批环境内调整提示词，但新增数据域、改变写入路径或扩大门店范围必须重新获准。

scoping 的出口是四份材料：事件流与需求草案、数据盘点、十条种子用例、进入验证期的条件判断。判断写得很克制：“数据能支撑限定场景，进入验证；若关键字段持续不可得，则缩小范围或停止。”桌面演示只用了合成输入，不接生产任务，不把演示结果当验收。真正的数据验证在授权环境内开始。

### 39.3 从 10 个用例到 120 条 golden set

最初的 10 个用例包含六个常规补货、两个信息缺失和两个异常边界。每条都附输入快照、预期动作、证据字段和禁止项。第一次跑完，团队发现模型会把“库存未知”解释成“库存为零”。补货规则的单元测试全部通过，这条解释依然可能诱导错误操作。代码验收与模型输出验收由此有了具体分工。

验证期内，业务主管和补货员根据试点业务记录补充代表性用例，把已发现的失败回流，再构造对应风险的对抗样本。定稿的 golden set v1 共 120 条独立用例：100 条回归用例，其中包含作为 smoke 的 10 条；另有 20 条对抗用例。smoke 是回归子集，不能再相加算成 130 条。回归层记录常规、数据缺失、在途异常、促销切换各类覆盖；对抗层单列诱导编造、越权读取和忽略缺失字段等挑战。

这里的 120 条是限定门店与商品范围的初始教学规模，不是第 22 章“几百条量级”的替代标准，更不意味着凑满数量即可上线。新增品类、季节变化或罕见失败出现时，都要重新审查覆盖并扩集；范围越广，所需证据越多。针对风险刻意增加的样本也会改变分布，因此按层和类别报告结果，不能把全体 120 条的通过率说成生产准确率。

团队保留一部分未用于提示词调试的回归样本，由业务方持有标签，发布候选版才运行，防止反复看题调参形成虚假的进步。记录里同时注明这一小样本检验的局限：它能发现已覆盖的失败，不能证明所有真实任务都可靠。每次改动都登记数据集、模型、提示词、规则、judge 与运行配置版本，让后续比较能重现。

### 39.4 judge 校准：先证明尺子能识别危险答案

补货数量和字段格式用确定性校验；解释是否有依据、是否遗漏关键异常，再交给 LLM-as-judge。业务主管把评分规则写成可观察行为：“合格”须引用有效快照和在途依据；“边界”是解释不完整但没有危险推断；“不合格”包括编造数据、忽略必需字段或越权建议。禁止项单列，不能靠文字流畅或覆盖更多要点抵消。

两名业务人员独立判断 40 份输出，再对分歧逐条仲裁，形成校准参考。其中 20 份用于修订 rubric 和示例，另 20 份封存用于检验，均不计入那 120 条用例的通过数。封存部分含十份常规和十份边界、失败输出。judge v1 与人工在常规组一致 10/10，在边界组仅一致 6/10：它会奖励听起来完整、实际把缺失在途量当零的解释。

团队只用可见的校准材料修订 judge，随后启用另一批未看过的 20 份检验输出，得到常规 10/10、边界 9/10 的一致结果。两批不同，不能把数字直接视作同集提升的因果证据；报告附上构成和分歧，说明它只是继续使用 judge 的有限依据。危险项仍由规则和人工兜底，剩余分歧进入复核。judge v2 冻结后，基线与候选配置均用它重新评估，旧分数不混入新对比。

### 39.5 一次回退：总分守住了，红线没有守住

验证末期，基线 A 把数量计算和解释拆开。候选 B 为减少一次调用，合并了异常判断与解释，代码和接口测试均通过。团队按第 23 章在相同 golden set v1、judge v2、输入快照及运行配置下比较；两版均跑全量，并保存逐条输出。发布门槛事先写明：smoke 全过，回归不低于基线且各类不退化，对抗禁止项零命中。

| 检查项 | 基线 A | 候选 B |
|--------|--------|--------|
| smoke 通过 | 10/10 | 10/10 |
| 回归通过 | 94/100 | 94/100 |
| 对抗禁止项命中 | 0/20 | 3/20 |
| 回归输出中无依据陈述 | 1/100 | 3/100 |
| 回归格式合规 | 100/100 | 100/100 |
| 每条回归任务平均模型调用费用 | 0.040 元 | 0.030 元 |
| 同批回归任务端到端 P95 延迟 | 3.2 秒 | 2.5 秒 |

费用仅是这批请求的模型调用费，不含部署、人审与维护；延迟只适用于该测试环境。B 更快、更便宜，但三条对抗失败都把“未知在途”解释成无需扣减的零值。人工核验后，重复运行仍能复现这个模式。通过率持平掩盖了失败类型的迁移，不能抵消预先约定的禁止项红线。

林宁决定撤回尚未上线的 B 候选，恢复 A 的发布配置，停止 B 的灰度申请。这是验证期的方案回退，尚无采购单需要撤销。技术团队拿到可复跑记录，业务主管拿到三条失败对操作的影响说明，高管拿到“暂不换取这部分降本”的判断。A 中那条无依据陈述也不被略过：人工复核所有建议，禁止自动采购，该失败列入修复清单；客户确认受控试点条件后才进入交付。后续修复新增用例时升版，并让 A 与修复版在新集上重跑。

### 39.6 驻场与灰度：38% 为什么还不够，74% 又说明什么

交付前，客户技术负责人先在隔离环境演练配置恢复、权限失效和接口超时。随后开只读影子运行，把建议与现行处理对照，不影响下单；通过检查再由一小组补货员进行人工确认试用。每轮都核对失败记录和回退入口，获得业务与技术负责人放行后，才把建议入口开放给五店全部目标用户。全程保留既有采购审批。

采用观察从全部目标用户获得权限后的首个完整周开始，之前的小组灰度不与它混算。固定 cohort 为 50 名有补货职责的人员，四周内名单、岗位资格与访问权限均不变。周窗口为客户当地时间周一零点至周日结束；“活跃采用”要求至少完成一次真实任务的建议核对并提交处理结果，接受、修改或说明理由后拒绝均计入。只登录、浏览或参加培训不算，任务事件按用户去重。

| 全员开放后的完整周 | 活跃采用人数 / 固定目标人数 | 周活采用率 |
|--------|--------|--------|
| 第 1 周 | 19/50 | 38% |
| 第 2 周 | 26/50 | 52% |
| 第 3 周 | 32/50 | 64% |
| 第 4 周 | 37/50 | 74% |

第一周低于业务方约定的试点观察目标，林宁每周三天驻场跟看操作。她看到补货员必须在两个页面间找快照时间，而拒绝建议的理由需要重复录入。团队把依据放到同一任务页，复用原有原因码，并安排值班主管带着真实任务练习。非驻场日异步处理回归和文档，发现的新失败留在客户环境内回流。

四周数据说明固定用户群完成真实任务的人数增加，不能证明建议被照单采纳，更不能证明模型独立造成增长。界面调整、培训、主管推动和工作量变化都可能影响结果。团队另报建议接受、修改、拒绝的任务级比例与任务机会数；没有任务的人员仍留在固定分母里并单列说明，避免悄悄改变口径。

这四个七天窗口也不是第 26.3 节定义的上线后 30 天 production adoption；30 天累计去重必须等完整窗口结束另算，不能用四周百分比求平均代替。面对高管的 ROI 追问，林宁交出下一步测量方案：按相近门店与品类比较同环节工时、缺货和积压，控制促销与季节因素，同时计入人审和维护成本。当前材料没有足够证据宣布库存改善或财务回报。

### 39.7 四条复盘：交付结果需要四种不同的证据

第一条，范围由现场事实约束。“智能补货”被拆成可验证的建议流程后，数据缺失、审批责任和采购权限才有了位置。缩小首期范围必须同时留下扩围条件，否则试点容易长期停在最简单的业务角落。

第二条，评估集和 judge 都需要被审查。十条用例启动对话，120 条建立初始回归资产；数量本身不提供保证。边界覆盖、未用于调试的样本、人工仲裁与版本记录，决定这份证据能支撑多大的承诺。

第三条，回退要兑现事先写下的红线。候选 B 的速度收益是真实的演示结果，但禁止项命中使它失去放行资格。撤回时留下负面结论和复现材料，下次才能避免重新支付同样的试错成本。

第四条，采用和业务收益要分别验收。37/50 证明的是一周内有多少目标用户完成了真实任务；补货是否更准确、成本是否下降，仍需各自证据。移交时客户接手人要能独立重跑评估、解释指标、演练恢复；获准外传的合成失败复现再按第 29 章进入团队积木，指定维护者，不能把客户数据直接带走。

### 39.8 【练习】为候选 B 写一份可追责的决定

题目：沿用本章数据，写一页交付决定：说明是否放行 B、引用哪条门槛、恢复什么配置、由谁执行与确认；再分别给技术负责人、业务主管、高管写一句解释。最后定义 30 天采用率的分子与分母，并指出现有周数据无法算出它的原因。

引导：把“数字看起来差不多”变成逐项证据。解释若涉及根因，区分已经复现的现象与尚待实验的假设；向高管汇报时保留调用费的范围，不把少一次调用换算成总项目 ROI。

参考方向（供讲师参考）：合格答卷应拒绝 B 的当前发布申请，说明回退发生在生产前；人工确认、配置恢复与采购撤销是不同动作。30 天指标需要完整窗口内真实使用的去重用户及对应目标用户名单，四份周活人数缺少跨周重叠信息。若答案只报“74% 证明成功”，应要求补出它不能证明的结论。

---

> 本章材料与来源说明：本章全部客户情节与数值均为虚构教学材料。三阶段节奏沿用第 27 章已注明来源的业界材料；golden set、judge 校准、回归与基线方法承接第 22、23 章，干系人协作承接第 28 章，采用口径承接第 26.3 节，知识移交承接第 29 章。本章的具体门槛、样本构成、费用、时间与采用曲线是教学设计，不是上述来源的实测结论，也不新增特定公司的业界事实断言。

---

## 独立练习

使用虚构或已获授权的脱敏材料，先独立作答，再查看参考。将产物保存为 `chapter-39.md`，写上版本、决定、证据和缺项。

教学候选常规94/100、红线失败3/20，旧与新周采用19/50、37/50。写发布决定、所缺证据，并区分周采用与30天观察。

<!-- chapter-artifact-requirement -->
### 本章必交产物：零售案例证据链

以下证据必须出现在本次独立练习的提交物中；正文原有问题用于提供内容，不能替代这些验收项。

- O1: 零售案例证据链写明从“补货建议”到“红线结果”的进入条件
- O2: 零售案例证据链至少包含一个继续分支、一个停止分支和各自责任人
- O3: 产物记录一个建议的依据、红线结果、放行决定和待观察采用指标

<details>
<summary>查看参考反馈（先独立作答）</summary>

## 参考反馈

红线失败阻断发布，不用94%抵消。周采用分母为该周可用机会或用户，必须先固定定义；37/50不等于30天持续采用。需修复逐例证据、同条件回归、人工复核与接管记录。全部数字是虚构教学数据，不是本站客户指标。

### 自评与下一步

对照本章目标检查：决定是否明确，依据是否能复现，未知项是否如实记录。参考给出一种判断方式，不是唯一答案；若不同结论能提供同等证据，可请同伴复核。缺少证据的部分记未完成，再回到对应步骤补充。

</details>

## 来源与边界

登记来源只支持本章涉及的外部事实；零售案例证据链、示例数字和练习情境属于课程内部教学设计，必须在实际项目中重新验证。

- [建立成功标准与评估](https://platform.claude.com/docs/en/test-and-evaluate/develop-tests) — Anthropic, 2026-09-17. 评估应从可观察成功标准、用例和版本化证据开始。
- [NIST AI 风险管理框架](https://www.nist.gov/itl/ai-risk-management-framework) — National Institute of Standards and Technology, 2026-09-17. AI 风险治理需要跨设计、开发、部署和使用阶段持续识别、测量、管理与记录。