第 12 章 · 选品别靠猜
老板先看这一句： 选品拍脑袋，是跨境压货亏钱的最大源头——竞品降价、差评炸锅你后知后觉，跟不跟全靠直觉。把竞品价格、上新、评论情绪用 AI 挖成信号，选品从「猜」变「数据驱动」，压错方向的风险和库存资金占用一起降下来。该问团队的是：有没有 Golden Dataset 兜底准确率、风险预警是不是人来拍板；「全自动定价」那种野路子预算别批。
关于这一章
前面十一章讲的方法，这一章一次性用出来——只不过场景换成了跨境老板最关心的「选品别靠猜」。
我用日记体，带你走完老陈的家居跨境电商里一个真实形态的项目：老陈想用 AI 帮团队盯住竞品和舆情，反过来指导选品。时间跨度四周，从第一次坐进会议室，到最后五分钟路演。每一周结束，我都会告诉你交付包里又多了哪一件——到本章末尾，你会看到那个「填好七成的可复制交付包」到底长什么样。
这不是一个一切顺利的故事。中间会踩坑、会返工、会被业务方泼冷水。这才是真实的交付。
场景背景：老陈的家居跨境电商，一家做家居用品、在多个平台开店的公司。运营团队每天要人肉盯竞品的价格、上新、卖点，还要翻自家商品的评论和差评——这些信息本该用来指导选品，却散在各处、反应慢、复盘全靠记忆。老陈找来时说的原话是：「能不能搞个 AI，帮我们盯着竞品、顺带告诉我该不该跟？」
为了让这个案例更接近真实交付，而不是一个好听的故事，先把项目基线摆出来：
| 项 | 基线 |
|---|---|
| 团队 | 1 名运营负责人 + 3 名类目运营 + 1 名 Agent 落地工程师 |
| 覆盖平台 | 6 个公开电商/内容平台 |
| 人工耗时 | 每周竞品与评论周报约 4 小时，临时巡检每天约 30 分钟 |
| 主要痛点 | 价格变化发现慢、差评聚类靠人工记忆、周报口径不稳定 |
| 数据边界 | 公开竞品页面 + 平台授权的自家评论样本，不采集个人隐私 |
| 第一战目标 | 先做「差评聚类预警」，不做自动回复、不接定价系统 |
| 试运行窗口 | 4 周 PoC + 上线后 2 周观察 |
Week 0 结束时，我们把验收目标也写成数字，而不是只写「提升效率」：
| 指标 | 当前值 | PoC 目标 | 数据来源 |
|---|---|---|---|
| 周报生成耗时 | 4 小时 | ≤ 15 分钟 | 运营工时记录 |
| 评论分类准确率 | 无统一标准 | ≥ 85% | Golden Dataset |
| 高风险差评漏报 | 无记录 | 0 | 高风险样本集 |
| 运营采纳率 | 0 | ≥ 60% | 周五 Demo 反馈 + 日常使用记录 |
| 单次运行成本 | 无记录 | 可被业务接受，且能监控 | 调用日志 |
Week 0 · 需求共创周
周一：那句愿望背后
「搞个 AI 帮我们盯竞品」——这是第 2 章说的典型「愿望」，不是需求。我没有点头，而是坐下来追问了一下午：
- 你们现在具体盯哪些竞品？靠什么盯？（答：五六个对手，靠人每天翻页面）
- 盯到了之后做什么？（答：改价、调卖点、回差评）
- 最怕漏掉什么？（答：竞品突然降价、自家爆出集中差评）
- 什么样算「帮上忙了」？（答：……没想过）
最后那个「没想过」，就是这个项目最大的风险。我们花了剩下的时间，一起把它想清楚。
周三：填场景卡
对齐之后，我和运营负责人（他就是这个项目的业务搭档，负责定义什么叫好结果）一起填了一张场景卡。填的过程中，「盯竞品」这个模糊愿望，收敛成了三件具体的事：竞品价格变动提醒、自家差评的聚类与预警、每周一份运营周报。
场景卡完整模板见 附录 A。这里是填完后的关键几栏：
| 字段 | 内容 |
|---|---|
| 业务目标 | 增效（少花人肉时间）+ 控险（差评风险早发现） |
| AI 介入点 | 采集、聚类、情绪分析、周报生成交给 AI；风险要不要上报，人来拍板 |
| 数据来源 | 公开竞品页面 + 平台授权的自家评论数据 |
| PoC 范围（做） | 价格提醒、差评聚类预警、每周周报 |
| PoC 边界（不做） | 不自动回复差评、不接入内部定价系统 |
| 合规 | 只碰公开和授权数据，控制采集频率，不碰个人隐私 |
周五：画介入点图 + 排优先级
场景卡定下三件事，我画了一张 AI 介入点图，把「哪步 AI 自动、哪步人工确认」标清楚——尤其是「风险上报」这一步，明确标了人工确认，因为误报一次预警把运营吓一跳，比漏报的代价还麻烦。
介入点图范例见 附录 B。
三件事里，我们用「价值高不高、数据好不好拿、风险大不大」三把尺子排了个序：差评聚类预警 排第一——它数据现成（自家评论有授权）、痛点最尖锐（漏看差评最怕）、风险可控。这就是我们第一个要做的核心 Case。
本周交付包 +2：场景卡（附录 A）、AI 介入点图（附录 B）。
Week 1 · 快验周
周一：先别写代码
按第 17 章的三层路径，第一版绝不从工程化开始。我用一个开箱的工作流工具做定时采集和推送，用一个开箱的对话平台搭了个分析 bot，把上周排第一的「差评聚类预警」先跑起来。目标只有一个：证明这条路走得通，丑没关系。
周四：跑通了，但……
丑版本三天就跑通了：能拉到评论、能聚成几类、能标出情绪、能把「集中出现的差评」推到群里。演示给运营看，他眼睛一亮——然后马上皱眉：「这个『物流慢』的差评，怎么跟『包装破损』混一类了？」
第一个坑来了：聚类的粒度和业务的分类习惯对不上。 AI 按语义聚，业务按处理部门分。这不是技术问题，是没对齐业务口径。
周五：架构图 + 记下第一个失败样本
我把这个「聚错类」的例子原样记了下来——这是第一条失败样本，后面调优和验收都要靠它。同时把当前这套丑架构画成了一张图，标清每层用了什么、哪里是人审节点。
架构图模板见 附录 C。
本周交付包 +1，并开了一个新账本：PoC 技术架构图（附录 C）；失败样本库开张（第 1 条）。
Week 2 · 评估对齐周
周一：先说清什么叫「准」
Week 1 那个「聚错类」的争论让我下决心先做第 22 章的事——在继续调之前，先定义什么叫做对。 我和运营一起，从真实评论里挑样本，凑出了第一版 Golden Dataset：
- 典型样本：最常见的几类差评各挑几条
- 边界样本：那种一条评论里骂了两件事的、难分类的
- 失败样本：包括上周那条「物流/包装混类」
- 高风险样本：涉及安全隐患、要立刻上报的那种
然后定了验收指标：分类准确率、风险预警命中率、周报生成时间、运营采纳率。
第一版 Golden Dataset 的规模不大，但类别必须齐：
| 类型 | 条数 | 来源 | 用途 |
|---|---|---|---|
| 典型样本 | 40 | 最近两周评论 | 覆盖物流、包装、质量、安装、售后等常见问题 |
| 边界样本 | 15 | 一条评论包含多个问题的样本 | 防止「物流慢 + 包装破损」被粗暴归一类 |
| 失败样本 | 12 | Week 1 演示和人工复盘发现 | 防止修过的问题回退 |
| 高风险样本 | 8 | 涉及安全隐患、集中差评苗头 | 要求 0 漏报，且必须人工确认 |
四类样本和指标库见 附录 D。
周三：第一次跑分
拿 Golden Dataset 一跑，分类准确率只有六成多，风险样本还漏了一个——这就是没先定标准的项目永远看不到的真相： 之前「感觉还行」的东西，一量化就现原形。但这不是坏消息，是好消息——现在我们有靶子了。
首轮跑分记录长这样：
| 指标 | Week 2 首轮 | 问题 |
|---|---|---|
| 分类准确率 | 63% | 业务按处理部门分类，AI 按语义分类 |
| 高风险漏报 | 1 条 | 「异味刺鼻」未被识别为潜在安全风险 |
| 周报生成耗时 | 22 分钟 | 能接受，但还没到目标 |
| 运营采纳率 | 35% | 报告有用，但分类口径还不可信 |
周五：按样本调，而不是凭感觉调
我根据跑分结果做了三件事：重写分类的提示词、给它补上业务的分类口径、把高风险类别单独拎出来加规则。再跑一次，准确率上到八成出头，高风险样本零漏报。每一次调，我都对着 Golden Dataset 验证，而不是凭「感觉变好了」。
本周交付包 +1：Golden Dataset（附录 D），并且它现在同时是「验收依据」和「回归门禁」——以后每次改动都要用它回归一遍。
Week 3 · 迭代收敛周
周一：进入周节拍
从这周起，项目进入第 20 章说的周度节拍：周一定目标、周五给运营演示、中间按失败样本迭代。这周的目标是把三件事补齐——价格提醒和周报生成也做出来，接进同一套流程。
周三：一个真实的变更请求
运营周三提了个新要求：「周报能不能按品类分开，别一锅炖？」
这是第 21 章说的需求变更。我没有直接就做，而是把它丢进「需求变更池」里分了类——这是「优化」，不是「缺陷」，也不是「范围扩大」。评估后发现改动不大、价值明确，纳入本周。关键是走了流程：变更被记录、被分类、被评估，而不是随口一说就插队，把节奏冲乱。
变更池和周清单模板见 附录 E。
周五：达到验收线
到周五演示时，三件事都跑通了，各项指标都过了 Week 2 定的验收线。运营第一次主动说：「这个我可以每天用。」——「采纳率」这个指标，第一次有了真实的分子。
Week 4 前的收敛结果如下：
| 指标 | 基线 | Week 2 | Week 4 | 判定 |
|---|---|---|---|---|
| 周报生成耗时 | 4 小时 | 22 分钟 | 6 分钟 | 通过 |
| 评论分类准确率 | 无 | 63% | 88% | 通过 |
| 高风险漏报 | 无 | 1 条 | 0 | 通过 |
| 运营采纳率 | 0 | 35% | 72% | 通过 |
| 人工复核量 | 无 | 每日报告全量看 | 只看高风险和低把握项 | 可接受 |
这里的「通过」不是模型自己说的，是对着同一套 Golden Dataset、同一套业务口径、人审确认记录跑出来的。
本周交付包 +1：30 天落地计划 / 周度清单（附录 E），里面沉淀了这三周的真实节拍。
Week 4 · 上线与路演周
周一：过上线门禁
要真上线，光效果好不够，得过第 23 章那道门。我拿出上线门禁清单逐条打勾：公开数据合规、采集频率受控、不碰隐私、高风险预警有人审、有审计日志、有成本监控、有回滚方案（预警误报激增就自动降级为「只入周报不推送」）。
有两项没过：审计日志字段不全、回滚触发条件没写死。周三补齐。
补齐后的上线观察看板包括五个数：
| 指标 | 为什么看 |
|---|---|
| 每日运行次数 | 确认任务是否稳定触发 |
| 高风险预警数 / 确认数 | 判断误报是否过高 |
| 人工复核耗时 | 防止 AI 省下的时间被人审吃掉 |
| 单次运行成本 | 防止调用量或循环失控 |
| 失败任务数 | 发现采集失败、接口超时、报告生成异常 |
门禁 / 回滚 / 审计清单见 附录 F。
周四：写交接说明
上线不是终点。按第 24 章，我给运营留了一份简单的「怎么自己调」说明——分类口径怎么加、预警阈值怎么改、周报模板在哪改——目标是让他们慢慢能自己运营，我只做监控和升级。
周五：五分钟路演
最后是本章最后要讲的「价值路演」（结构见第 25 章）。五分钟，我按固定结构讲：痛点（人肉盯竞品、漏看差评）→ 价值（周报生成从半天到几分钟、差评预警命中率、运营已在每天用）→ 验证（Golden Dataset 跑分、四周迭代曲线）→ 投产路径（已上线，下一步接价格自动建议）→ 风险控制（合规边界、人审门、回滚方案）。
路演脚本结构见 第 25 章。
本周交付包 +2：上线门禁清单（附录 F）、五分钟路演脚本。
四周之后，交付包里有什么
回头看，这个交付包是这样一件件长出来的：
| 周 | 新增交付物 |
|---|---|
| Week 0 | 场景卡、AI 介入点图 |
| Week 1 | 技术架构图、失败样本库（开张） |
| Week 2 | Golden Dataset + 验收指标 |
| Week 3 | 30 天计划 / 周度清单、需求变更记录 |
| Week 4 | 上线门禁清单、路演脚本 |
换一个项目——比如把同样的方法用到客服、选品或供应链场景——这套交付物七成可以直接复用，只需要替换掉具体的业务口径、样本和指标。这就是「可复制交付包」的意思：你交付的不只是一个智能体，还有一套下次能更快的方法。
常见坑（这一章踩过的）
- 跳过 Week 0 直接开干：最常见的死法，做到 Week 2 才发现方向错了。
- 不先定 Golden Dataset 就调优：你会一直在「感觉变好了」里空转，且无法回归。
- 变更随口就接：不走变更池，节奏一周就乱。
- 门禁当形式：审计和回滚没做实，第一次误报就可能被叫停。
本章产出
老板行动点： 别批「全自动定价/自动跟价」这种野路子预算；改为批一个四周 PoC（场景卡 + Golden Dataset + 上线门禁），并问团队：准确率有没有数据集兜底、风险预警是不是人来拍板。
这一章的产出，就是你自己的那份交付包：挑一个你手边的真实场景，照着 Week 0 → Week 4 的节奏走一遍，把附录 A–F 逐周填出来。走完，你就完成了一次真正的 L3 交付。
成熟度自检
- [ ] 我能照这个四周节奏，独立走完一个 PoC 并通过验收（→ L3）
- [ ] 我能在过程中用变更池管住需求、用 Golden Dataset 管住质量（→ 迈向 L4）