第 13 章 · 供应链总掉链
老板先看这一句： 前端广告投得再欢，断货一个月、订单对不上账、上架踩了认证红线整店被关，前面全白跑。库存预测、订单自动归集、贸易与平台合规嵌进流程，能同时压住断货、积压和违规罚款三笔大钱。该问团队的是：大金额补货和合规放行是不是人都审过；给 AI 接系统时的写库/扣款权限，这笔险不能冒。
关于这一章
前面几章讲的方法，这一章用到跨境老板最怕的「后端地基」上——供应链、订单、合规。我用日记体，带你走完老陈家居一个真实形态的项目：老陈最初说「想搞个 AI 管库存」，真坐下来一对齐，发现他根本不是要管库存，而是要别再断货、别再漏跟物流、别再把认证红线撞上。时间跨度四周，从第一次会议室到五分钟路演。每周结束，我都会告诉你交付包里又多了哪一件——到本章末尾，你会看到那个「填好七成的可复制交付包」到底长什么样。
这不是一个顺风顺水的故事。中间误补过货、压过库存、合规词也差点漏判。这才是真实的交付。
场景背景：老陈家居，做落地灯/收纳/小家具/氛围装饰，Amazon（主）+ Shopify 独立站 + TikTok Shop，市场 EN/DE/FR/ES/JP，约 120 个活跃 SKU。订单、物流、清关靠三个人肉跟；缺货靠经验，常常断了一个月才发现；CE/FCC/UKCA/GDPR/各平台禁售词靠运营拿小本本记，易漏。老陈找来时的原话是：「能不能搞个 AI，帮我们管管库存？」
为了让这个案例更接近真实交付，先把项目基线摆出来：
| 项 | 基线 |
|---|---|
| 团队 | 1 名运营负责人 + 3 名类目运营 + 1 名 Agent 落地工程师（FDE） |
| 覆盖渠道 | Amazon（主）、Shopify、TikTok Shop、少量 Walmart/eBay，共 4 平台 |
| 市场 | 英语（美/英）、德语（DE）、法语（FR）、西语（ES）、少量日语（JP） |
| 活跃 SKU | 约 120 个 |
| 人工耗时 | 类目运营每天约 1.5h 跟单/清关；新品上架前合规自查约 30 分钟/个 |
| 主要痛点 | 缺货靠经验、物流异常发现晚、合规词靠人记易漏 |
| 数据边界 | ERP / 店铺后台 / 物流系统只读接口，不写库、不扣款 |
| 第一战目标 | 先做「缺货/物流异常预警」，再做「合规审核自动化」 |
| 试运行窗口 | 4 周 PoC + 上线后 2 周观察 |
Week 0 结束时，我们把验收目标也写成数字，而不是只写「提升效率」：
| 指标 | 当前值 | PoC 目标 | 数据来源 |
|---|---|---|---|
| 缺货预警提前量 | 0 天（断货才发现） | ≥ 7 天 | 库存 + 销量日志 |
| 物流异常发现时延 | 平均 3 天 | ≤ 4 小时 | 物流轨迹 |
| 合规审核耗时 | 30 分钟/个 | ≤ 5 分钟/个（AI 起草 + 人审） | 工时记录 |
| 合规漏判 | 无记录 | 0（高风险必人审） | 合规 Golden Dataset |
| 人工跟单工时 | 约 25h/周 | 降 ≥ 60% | 工时记录 |
Week 0 · 需求共创周
周一：那句愿望背后
「搞个 AI 管库存」——这是典型「愿望」，不是需求。我没有点头，而是坐下来追问了一下午：
- 你们现在具体怎么管库存？（答：看 Excel，凭感觉补）
- 最怕漏掉什么？（答：断货、物流卡住、上架踩红线）
- 什么样算「帮上忙了」？（答：……没想过）
最后那个「没想过」，就是这个项目最大的风险。我们花剩下的时间，一起把它想清楚：老陈要的从来不是「库存报表」，而是别在断货之后才拍大腿、别让物流异常拖成客诉、别把认证红线撞上整店被关。
周三：填场景卡
对齐之后，我和运营负责人（他就是这个项目的业务搭档，负责定义什么叫好结果）一起填了一张场景卡。填的过程中，「管库存」这个模糊愿望，收敛成了两件具体的事：缺货/物流异常预警、合规审核自动化。
场景卡完整模板见 附录 A。这里是填完后的关键几栏：
| 字段 | 内容 |
|---|---|
| 业务目标 | 控险（别断货 / 别漏跟物流 / 别踩合规红线）+ 增效（少花跟单时间） |
| AI 介入点 | 预测、异常检测、合规扫描交给 AI；补货是否执行、合规是否放行，人来拍板 |
| 数据来源 | ERP / 店铺后台 / 物流系统只读接口，不写库不扣款 |
| PoC 范围（做） | 缺货/物流异常预警、合规审核自动化 |
| PoC 边界（不做） | 不自动补货、不自动上架放行、不接扣款接口 |
| 合规 | 只读数据、PII 脱敏、合规放行人审；接口最小授权（见第 14 章过度代理风险） |
周五：画介入点图 + 排优先级
场景卡定下两件事，我画了一张 AI 介入点图，把「哪步 AI 自动、哪步人工确认」标清楚——尤其是「补货执行」和「合规放行」两步，明确标了人工确认，因为误补一次货压的是真金白银，漏放一个认证关的是整店。
介入点图范例见 附录 B。
两件事里，我们用「价值高不高、数据好不好拿、风险大不大」三把尺子排了个序：缺货/物流异常预警 排第一——它数据现成（ERP+物流有授权）、痛点最尖锐（断货最怕）、风险可控。这就是我们第一个要做的核心 Case。
本周交付包 +2：场景卡（附录 A）、AI 介入点图（附录 B）。
Week 1 · 快验周
周一：先别写代码
按第 17 章的三层路径，第一版绝不从工程化开始。我用一个开箱的工作流工具做定时拉取和推送，用一个开箱的对话平台搭了个分析 bot，把排第一的「缺货/物流异常预警」先跑起来。目标只有一个：证明这条路走得通，丑没关系。
周四：跑通了，但翻车了
丑版本三天就跑通了：能读销量、能对物流轨迹标异常、能把「可能断货」推到群里。演示给运营看，他眼睛一亮——然后当场按了补货。问题来了：数据源里 ERP 的销量是 T+1 同步，某款落地灯当天的真实销量还没回写，AI 误判「销量突跌、即将断货」，发了一条预警。运营没核实就补了 800 件。
结果销量正常，800 件压了仓，占用资金约 $30k，两个月才消化完。这是第一个坑：数据不准就预警 = 误补货压库存。
周五：架构图 + 记下第一个失败样本
我把这个「误预警导致误补货」的例子原样记了下来——这是第一条失败样本，后面调优和验收都要靠它。同时把当前这套丑架构画成了一张图，标清每层用了什么、哪里是人审节点。并在数据入口加了一层校验：销量数据延迟超过阈值时，预警降级为「待核实」、不推送，必须先人审再补。
架构图模板见 附录 C。
本周交付包 +1，并开了一个新账本：PoC 技术架构图（附录 C）；失败样本库开张（第 1 条：数据延迟导致误预警）。
Week 2 · 评估对齐周（合规 Golden Dataset）
周一：先说清什么叫「合规通过」
Week 1 那个误预警让我下决心先做第 22 章的事——在继续调之前，先定义什么叫做对。 我和运营一起，从真实上架记录里挑样本，凑出了第一版合规 Golden Dataset：
- 典型样本：各市场常见禁售词、认证表述（CE / FCC / UKCA / GDPR 相关）
- 边界样本：那种一个词在 DE 可以、在 FR 不行的（如某类「消毒/抗菌」表述）
- 失败样本：包括历史上被下架过的链接原词
- 高风险样本：涉及 PII 出境、安全认证缺失、整店级红线
然后定了验收指标：禁售词命中率、认证缺失识别率、审核耗时、漏判率。第一版规模不大，但类别必须齐：
| 类型 | 条数 | 来源 | 用途 |
|---|---|---|---|
| 典型样本 | 60 | 近半年上架文案 | 覆盖 EN/DE/FR/ES/JP 禁售词、CE/FCC/UKCA 表述 |
| 边界样本 | 20 | 一国可一国不可的词 | 防止跨境口径被一刀切 |
| 失败样本 | 15 | 历史下架链接原词 | 防止同类问题回退 |
| 高风险样本 | 10 | PII / 安全认证缺失 | 要求 0 漏报，且必须人工确认 |
四类样本和指标库见 附录 D。
周三：第一次跑分
拿 Golden Dataset 一跑，禁售词漏判 3 条（都是小语种边界词），认证缺失识别还行——这就是没先定标准的项目永远看不到的真相： 之前「感觉文案没啥问题」的东西，一量化就现原形。但这不是坏消息，是好消息——现在我们有靶子了。
首轮跑分记录长这样：
| 指标 | Week 2 首轮 | 问题 |
|---|---|---|
| 禁售词命中率 | 漏判 3 条 | 小语种边界词没覆盖 |
| 认证缺失识别 | 基本识别 | 个别 UKCA 表述漏 |
| 合规审核耗时 | 12 分钟 | 比人工快，但还没到目标 |
| 运营采纳率 | 40% | 报告有用，但口径还不可信 |
周五：按样本调，而不是凭感觉调
我根据跑分结果做了三件事：补小语种词库、给高风险类别单独加规则、把认证表述清单接进扫描。再跑一次，漏判归零，审核耗时压到 5 分钟以内。每一次调，我都对着 Golden Dataset 验证，而不是凭「感觉变好了」。
本周交付包 +1：Golden Dataset（附录 D），并且它现在同时是「验收依据」和「回归门禁」——以后每次改动都要用它回归一遍。
Week 3 · 迭代收敛周
周一：进入周节拍
从这周起，项目进入第 20 章说的周度节拍：周一定目标、周五给运营演示、中间按失败样本迭代。这周的目标是把两件事补齐——合规审核自动化接进上架流程，缺货/物流预警加了数据校验层后复跑。
周三：一个真实的变更请求
运营周三提了个新要求：「预警能不能按渠道分开看？Amazon 和 TikTok Shop 分开，不然群里太吵。」
这是第 21 章说的需求变更。我没有直接就做，而是把它丢进「需求变更池」里分了类——这是「优化」，不是「缺陷」，也不是「范围扩大」。评估后发现改动不大、价值明确，纳入本周。关键是走了流程：变更被记录、被分类、被评估，而不是随口一说就插队，把节奏冲乱。
变更池和周清单模板见 附录 E。
周五：达到验收线
到周五演示时，两件事都跑通了，各项指标都过了 Week 0 定的验收线。运营第一次主动说：「这个我可以每天用。」——「采纳率」这个指标，第一次有了真实的分子。
Week 4 前的收敛结果如下：
| 指标 | 基线 | Week 2 | Week 4 | 判定 |
|---|---|---|---|---|
| 缺货预警提前量 | 0 天 | 5 天 | 9 天 | 通过 |
| 物流异常发现时延 | 3 天 | 8 小时 | 4 小时 | 通过 |
| 合规审核耗时 | 30 分钟 | 12 分钟 | 4 分钟 | 通过 |
| 合规漏判 | 无记录 | 3 条 | 0 | 通过 |
| 人工跟单工时 | 25h/周 | 14h/周 | 8h/周 | 通过 |
| 人工复核量 | 全量跟单 | 每日看高风险项 | 只看高风险 + 低把握项 | 可接受 |
这里的「通过」不是模型自己说的，是对着同一套 Golden Dataset、同一套业务口径、人审确认记录跑出来的。
本周交付包 +1：30 天落地计划 / 周度清单（附录 E），里面沉淀了这三周的真实节拍。
Week 4 · 上线与路演周
周一：过上线门禁
要真上线，光效果好不够，得过第 23 章那道门。我拿出上线门禁清单逐条打勾：只读权限、PII 脱敏、合规人审、审计日志、成本监控、回滚方案（预警误报激增就自动降级为「只入周报不推送」）。
有两项没过：审计日志字段不全、回滚触发条件没写死。周三补齐。
补齐后的上线观察看板包括五个数：
| 指标 | 为什么看 |
|---|---|
| 每日运行次数 | 确认任务是否稳定触发 |
| 高风险预警数 / 确认数 | 判断误报是否过高 |
| 人工复核耗时 | 防止 AI 省下的时间被人审吃掉 |
| 单次运行成本 | 防止调用量或循环失控 |
| 失败任务数 | 发现采集失败、接口超时、报告生成异常 |
门禁 / 回滚 / 审计清单见 附录 F。
周四：写交接说明
上线不是终点。按第 24 章，我给运营留了一份简单的「怎么自己调」说明——预警阈值怎么改、合规词库在哪加、周报模板在哪改——目标是让他们慢慢能自己运营，我只做监控和升级。
周五：五分钟路演
最后是本章要讲的「价值路演」（结构见第 25 章）。五分钟，我按固定结构讲：痛点（断货一个月才发现、跟单靠人、合规词靠小本本记）→ 价值（缺货提前 9 天预警、合规审核从 30 分钟到 4 分钟、人工跟单降 68%）→ 验证（Golden Dataset 跑分、四周迭代曲线）→ 投产路径（已上线，下一步接清关文件起草）→ 风险控制（只读权限、合规人审门、回滚方案）。
路演脚本结构见 第 25 章。
本周交付包 +2：上线门禁清单（附录 F）、五分钟路演脚本。
四周之后，交付包里有什么
回头看，这个交付包是这样一件件长出来的：
| 周 | 新增交付物 |
|---|---|
| Week 0 | 场景卡、AI 介入点图 |
| Week 1 | 技术架构图、失败样本库（开张） |
| Week 2 | 合规 Golden Dataset + 验收指标 |
| Week 3 | 30 天计划 / 周度清单、需求变更记录 |
| Week 4 | 上线门禁清单、路演脚本 |
换一个项目——比如把同样的方法用到客服、选品或营销场景——这套交付物七成可以直接复用，只需要替换掉具体的业务口径、样本和指标。这就是「可复制交付包」的意思：你交付的不只是一个智能体，还有一套下次能更快的方法。
改造前 / 后数字对比
四周跑完，老陈家居的后端地基变成了另一副样子：
| 指标 | 改造前 | 改造后 | 变化 |
|---|---|---|---|
| 缺货预警提前量 | 断货后平均 5 天才发现 | 提前 9 天预警 | 从「事后救火」变「事前布防」 |
| 物流异常发现时延 | 平均 3 天 | ≤ 4 小时标红 | ↓ 约 95% |
| 合规审核耗时 | 30 分钟/个 | 4 分钟/个 | ↓ 87% |
| 清关/商品合规文件自动生成比例 | 0% | 约 80%（AI 起草 + 人核） | 新能力 |
| 人工跟单工时 | 约 25h/周 | 约 8h/周 | ↓ 68% |
| 合规漏判 | 偶发（靠人记易漏） | Golden Dataset 回归 0 漏报（人审兜底） | 可控 |
这些数字背后有一条铁律：清关/合规文件是 AI 起草、人审确认，绝不是 AI 直接放行。
一个真实的翻车片段：合规词差点漏判，靠人审拦下
Week 2 跑分之后，运营把一个准备上 JP 市场的新品链接丢进系统。AI 扫完标了「通过」——但那是因为当时词库里还没有覆盖到日语语境下的一处平台禁售表述。好在流程里合规放行是人工确认节点，运营对照 Golden Dataset 的高风险样本逐条过，发现了这条 JP 专属禁售词，拦下了上架。
如果当时把合规全交给 AI 自动放行，这条链接上架当天就可能被平台下架、甚至连累同店权重。这个片段后来被我加进 Golden Dataset 的「失败样本 + 高风险样本」里——AI 永远只能做到「当前词库内的准」，跨语言、跨市场的红线，必须有人审兜底。
常见坑（这一章踩过的）
- 跳过 Week 0 直接开干：最常见的死法，做到 Week 2 才发现方向错了——老陈要的不是库存报表，是别断货别踩线。
- 数据不准就预警：数据源延迟/口径错，预警变成误报，误补货压库存（我们 Week 1 真压了 $30k 的货）。先校验数据再预警。
- 合规全交给 AI 不人审：AI 标「通过」就上架，漏一个认证整店被关。合规红线必须由人审拍板。
- 清关文件错填：HS 编码 / 原产地 AI 起草但没人核实，关税算错被海关查验、延误又罚款。文件可自动生成，错填代价高，必须人核。
- 门禁当形式：审计日志和回滚没做实，第一次误报就可能被叫停。上线门禁（附录 F）逐条打勾，不是走过场。
本章产出
老板行动点： 别批「AI 全自动补货、自动上架放行」的预算；改为批一个四周 PoC（场景卡 + 合规 Golden Dataset + 上线门禁），并问团队：大金额补货和合规放行是不是人都审过、给 AI 的接口权限是不是只读不写。
这一章的产出，就是你自己的那份交付包。往落地工具包里放四件（对应老陈项目的真实交付）：
- 供应链/合规场景卡（模板见 附录 A）：先圈定你最疼的是缺货预警、物流跟单还是合规审核，别一上来全做。
- 合规词库 / Golden Dataset（见 附录 D）：CE/FCC/UKCA/GDPR/各平台禁售词 + 各国红线样本，作为上架前的固定门和回归依据。
- 缺货/物流异常预警看板：提前 9 天预警、物流异常 ≤4 小时标红，大金额补货与合规放行走人审。
- 上线门禁清单（见 附录 F）：只读权限、PII 脱敏、合规人审、回滚方案。
这四件，和前面各章的场景卡一起，构成你「业务全链路」的落地工具包骨架。
成熟度自检
- [ ] 我能用 AI 做缺货/物流异常预警 + 合规扫描，并让人审大金额补货和合规放行（→ L3）
- [ ] 我把合规检查嵌进上架/出境流程，且用 Golden Dataset 做回归、PII 有人审兜底（→ 迈向 L4）