做跨境电商选品这行当，最折磨人的不是找不到数据，而是数据散落在各种地方：某平台后台的销量趋势、运营工具里的关键词热度、供应链那边给的供货价，还有三方数据服务商每周发来的一堆行业报告。以前我们团队的做法是运营手动汇总Excel，技术这边每天写脚本定时抓几个公开接口，晚上统一做清洗入库，再人工看报表挑品。这套流程一周能跑一轮就不错了，等你看上某个品，市场行情早变了。所以当OpenClaw这种智能体编排框架进入视野之后，我第一个想法就是把它和飞书打通，做一套AI电商选品系统，让智能工作流把“数据收集、品类分析、候选推荐”三件事串起来，最后直接通过飞书推到运营面前，选出结果还能在线走审批。这套系统从立项到跑通主流程花了两周多，中间踩了不少坑，也沉淀了一些实打实的经验，今天把整个落地过程拆开聊聊。1. 为什么是 OpenClaw + 飞书：从业务痛点反推技术选型很多人一听到“AI选品系统”，第一反应是做个大模型对话页面，让运营把需求打字进去，AI输出几个品。我一开始也这么想过，但和运营聊完需求就发现方向错了：他们要的不是一个对话机器人，而是一套能把日常工作流程替代掉的东西。运营每天打开电脑第一件事是刷平台后台看飙升榜，第二件事是把三方数据服务商发来的Excel搬到共享表格里，第三件事是凭经验开会讨论哪个品值得上。这些动作有80%都是重复的、结构化的，完全可以由工作流自动化完成。所以选型的核心不是“AI问答”，而是“流程自动化+AI分析能力”的组合。1.1 电商选品到底难在哪选品这个场景有一个非常典型的特点：信息维度多、更新节奏快、决策链路长。一个品能不能做，通常要综合看需求热度、竞争强度、利润空间、供应链适配度四个方向。需求热度看搜索指数和销量增速，竞争强度看商家数量、头部集中度，利润空间要结合广告成本、平台佣金、供货价来测算，供应链适配度又要看现有供应商能不能稳定供货。这些数据分散在不同系统里，人工整合天然就慢，等得久了数据时效性就没了。另一个痛点是复盘的缺失。每周选出来的品，最后实际表现怎么样，很少有人认真回看。不是不想看，是数据都在Excel里、在群里、在每个人的脑子里，根本没法系统性地对照。这就导致选品经验很难沉淀，选品这件事长期停留在“老师傅手感”阶段。这套系统在设计的时候，我特意把“每轮候选品的后续表现回写”也作为一个核心需求，目的就是让AI的推荐质量和人工决策效果能被持续校验。1.2 技术选型的三个关键判断先说OpenClaw为什么合适。它本质上是把AI能力编排成一套可执行的工作流，你可以定义多个Agent角色，让它们分工干活：一个负责拉数，一个负责分析，一个负责生成报告，并且支持定时触发、外部API接入、上下文记忆。这正好覆盖了我们前面说的“数据收集、品类分析、候选推荐”三个环节。用传统开发方式做这套流程，至少要写几千行代码去做任务调度、状态管理、工具集成，而OpenClaw把编排层的事情收敛了，我们只用关心业务本身和配置怎么描述。再说飞书。选飞书不是因为市面上没有别的协同工具，而是因为它有一个其他平台不好替代的组合能力：机器人消息推送可以做到主动找人，多维表格可以当成轻量业务数据库，审批流可以把人工决策嵌进自动化链路里。也就是说，飞书既能当“显示器”也能当“操作台”，AI分析完的结果推送给人看，人看完直接在飞书里点通过或驳回，状态还能自动回写。这种闭环体验，比自建一个后台管理页面轻量得多，运营零学习成本。最后说为什么不能直接用RPA或者自己写定时脚本。RPA擅长的是模仿人操作界面，但面对三方数据服务商返回的各种非结构化、半结构化数据，它的解析和智能判断能力很弱，而且要跟着对方页面改版不断返工。自己写脚本倒是可行，但选品分析的核心不只是“把数拉下来”，还要“看懂数据”，比如某个品类销量涨了20%，要判断是季节性波动还是持续趋势，这就必须引入大模型的分析能力。OpenClaw恰好把这两件事缝合在了一起。1.3 整体架构怎么搭整个系统的逻辑可以分成三层。最底层是数据接入层，负责跟三方数据服务商对接，把不同格式的数据统一成标准结构；中间是AI分析层，由OpenClaw工作流里的多个Agent执行，负责对标准化数据做清洗、评分、排序、生成推荐结论；最上层是协同输出层，也就是飞书，负责把结论展示给运营、收集人工反馈、沉淀历史决策数据。这里有一个容易忽略的点：数据接入层虽然叫“接入”，但它不只是一个API转发器。三方服务商各自的数据口径、字段命名、更新频率都不一样，如果不做统一适配，AI分析层的Prompt根本没法写，因为同一个字段在不同数据源里叫的名字都不一样，比如有的叫“gmv”，有的叫“成交金额”，还有的叫“sales_value”。所以我们在中间加了一个适配器，把这些差异在进AI之前全部抹平。这块细节比较多，下一节单独展开。2. 三方数据服务的对接实践：从接口混乱到统一适配我跟不少做技术的朋友聊过，大家对接三方数据服务商的第一反应都是拿着对方文档挨个调接口，代码写起来很快，但真正跑起来全是问题。这次我们接了三类数据源：某电商平台的商品销量与搜索指数数据、某市场洞察服务商的行业品类趋势数据、某内容平台的短视频/图文热词数据。每一家的对接方式都不一样，有的提供标准REST API，有的是定时推送Webhook到我们服务器，还有一家干脆只给文件导出的方式，每天把CSV发到一个临时下载地址。把这三类揉到一套系统里，统一适配层是必须做的事。2.1 数据服务商选型与协议梳理先说选型。我们在评估数据服务商的时候，不只看数据质量，还重点看了三个东西：是否有明确的数据更新频率说明、接口是否有稳定的调用配额、是否提供沙箱测试环境。有个服务商数据维度很全，但接口限流非常狠，每秒只能调两次，这种接到生产环境里连基础的数据量都跑不满，根本没法用。后来选定的服务商，有的是按条数计费，有的是按调用次数计费，这个也要提前弄清楚，否则跑一轮全量数据成本会吓人。然后是协议梳理。每家对接方式差异很大，落地时我建议先做一张“数据源登记表”，把每个服务商的基本信息固定下来：接口地址、鉴权方式（是AppKey还是Token还是签名）、调用配额、返回格式（JSON还是XML）、更新频率（实时还是T+1）、字段字典（对应关系）。这张表是后续写适配器的依据，也是排查问题时的第一手资料。我们组里当时就是靠这张表，才发现某个服务商把日期字段的时区设成了UTC，导致每天的数据在应用层显示都慢8个小时，排查了一下午。2.2 统一数据适配层怎么做统一适配层做的事情其实就三件：定义标准结构、写转换逻辑、做稳定性兜底。标准结构是我们自己定义的“选品数据中间格式”，所有数据源进来之后都转成这个格式，再送到AI分析层。字段不多，核心就几类：商品/品类的标识、所属类目层级、统计日期、需求热度相关指标（搜索指数、浏览量）、成交相关指标（销量、销售额、增速）、竞争相关指标（在售商家数、集中度）、利润相关指标（均价、参考毛利）。转换逻辑就是针对每个数据源写一个适配器，把对方的字段映射到我们的标准字段上。这里有个经验：不要把所有转换逻辑都堆在一个大函数里，而是用一个配置驱动的思路，把“哪个数据源的哪个字段对应哪个目标字段”写成配置。这样新接入一个数据源时，大部分情况下只改配置就能上线，不需要动代码。不过要注意，配置驱动有个坑：文档和配置会脱节，数据源那边字段改了，配置没同步改，线上就静默出错。我们的做法是写了一个字段完整性校验，每次拉数后对比配置里声明的字段和实际返回的字段，不一致立刻告警。稳定性兜底主要包含重试、限流、幂等和三方故障熔断。重试不能无脑重试，要根据不同的错误码区别对待：限流错误要退避重试，签名失效要重新签名后再试，参数错误重试多少次都没用，直接告警让人来看。限流的话，我们在适配器里做了令牌桶，按各数据源配额动态调整。幂等这块容易被忽略，某数据服务商有一次网络抖动导致消息重复推送，如果消费端不做去重，数据就会重复计算，评分直接漂移。至于熔断，设定一个简单规则：连续10次调用失败就熔断15分钟，不再打对方接口，避免把对方服务打死，等恢复后再继续。2.3 数据质量保障数据质量是AI选品系统的生命线，数据不准，AI再聪明也白搭。我们实际踩过的数据质量坑至少有四类。第一类是空值问题。某服务商返回的数据里，部分类目当天没有销量数据时会返回空，如果直接用空值做标准化，下游评分就会出错。我们在清洗环节把所有空值都显式处理成“该字段缺失”标记，并在评分时对缺失字段做权重收缩，不让一个缺失字段拖垮整个评分。第二类是离群数据。某个品类某一天的销售额突然涨了50倍，一看是平台大促或某个头部链接爆发，如果不做处理，AI会把这种短期脉冲误判成趋势。我们加了一层波动校验：当某个指标单日变化幅度超过预设阈值时，自动标记为“异常波动”，分析层会把它降权处理，除非连续多日维持高位才算趋势。第三类是单位统一。不同数据源的单位千差万别，有的销售额单位是元，有的是千元，甚至有的服务商用美元口径。这听起来很基础，但在真实数据里就会混在一起，标准化时稍微漏一个单位字段，评分结果就差出好几个量级。我们专门做了一个单位换算表，任何字段进入标准格式前必须经过单位校验。第四类是增量与全量的策略。有些数据源支持按时间增量拉取，有些只支持全量拉取再本地做差。全量拉取耗时和成本都高，所以我们在适配器里做了一层“本地增量”机制：每次全量拉到本地以后，跟上一轮数据做diff，只保留变化的部分进入分析层，再定期做一次全量校准，防止diff累积出错。3. AI 选品逻辑与工作流的拼接数据层稳定之后，真正体现系统价值的就是AI选品逻辑这层。这里有一个常见误区：很多人觉得AI选品就是丢一堆数据给大模型，让它“分析一下推荐几个品”。这样做出来结果一定不能直接用，因为大模型容易一本正经地编数据，而且对业务口径没有感知。我们的做法是把它拆成“规则评分 + AI增强解读”两个阶段。规则评分负责客观的量化计算，AI负责把结果转成人话、补充数据之外的判断逻辑。3.1 选品评估模型怎么定义先讲量化评分。我们把选品看成一个多因子打分问题，如果只用一个指标，比如只看销量增速，很容易被低价冲量或刷单数据带偏。我们选了四个维度，每个维度下面再去细分子指标，这里给出我们用的维度和权重，供参考：评估维度子指标示例初始权重需求热度搜索指数、销量增速、内容平台话题热度35%竞争强度在售商家数、头部链接集中度、广告竞价水平25%利润空间参考毛利率、客单价、平台佣金占比25%供应链适配现有供应商匹配度、履约时效、补货周期15%权重不是一成不变的，初期是业务团队开会拍脑袋定的，跑了三周之后根据运营反馈做了调整：比如某个品类搜索热度很高但供应链完全没法做，那需求热度的分再高也没意义，供应链的权重就往上调了。这个调整过程建议不要频繁动，至少跑两周积累数据后再调，否则无法判断是权重问题还是数据问题。评分计算前要做标准化，因为各指标单位不同，比如搜索指数可能是几万量级，毛利率是百分比，不能直接加总。我们用min-max归一化把每个指标压到0到1，再按权重加权求和。需要留意的是，归一化的上下界要用历史数据的分位数来定，不要用绝对最大最小值，否则某个品类的异常值会把正常值全压到很低。3.2 OpenClaw 里的 Agent 设计OpenClaw里我们定义了两个核心Agent，一个叫数据整理Agent，一个叫选品分析Agent，再加一个定时触发器把它们串起来。数据整理Agent的职责是：从统一适配层拿最新数据，做时间窗口筛选（比如只看最近7天和最近30天的趋势），生成一份结构化的“待分析数据集”，输出成JSON给下游。这里的要点是，不要让整理Agent做太多清洗工作，清洗在适配层已经完成了，Agent只做按需筛选，各司其职。选品分析Agent是我们提示词工程的重头戏。它的输入是结构化数据集加上运营配置的过滤条件（比如排除某个类目、指定价格带），输出是一份包含候选品列表、每个品的综合评分、评分依据分析、风险提示的Markdown报告。为了让AI不编数据，我们在Prompt里强约束了三点：一是所有数据引用必须来自输入的数据集，不允许擅自补充外部数据；二是如果要给出判断，必须说明是基于哪个字段得出的，比如“因为搜索指数环比上涨40%，所以需求热度上调”；三是如果数据不足，允许直接说“数据不足”而不是强行推荐。这三点约束下来，AI输出的可参考性提升非常明显。3.3 飞书侧的能力设计选品分析Agent出报告之后，接下来的动作都是飞书完成的，这块设计得直接关系到运营是否愿意用。我们把飞书侧拆成三个能力：机器人推送、多维表格沉淀、审批回传。机器人推送是最直观的触达。每天早上定时任务跑完后，工作流调用飞书机器人，把选品日报推送到一个专门的选品群里。日报内容包括：今日高潜候选品Top10列表、各维度评分摘要、值得关注的异常品类提醒。这里有一个体验小技巧：推送内容不要一大篇文字糊上去，要结构化，每个候选品一行，带评分、带一句话推荐理由，想看详情的直接点链接跳转多维表格。运营在手机上就能快速扫一遍，这是这套系统能被日常使用的前提。多维表格承担“选品池”的角色。我们建了一个选品池表格，字段包括：品名、类目、来源数据源、综合评分、需求热度分、竞争分、利润分、状态（待审核/已通过/已驳回）、运营备注。每一轮AI跑完，候选品自动写入这个表。这里的设计重点是状态字段，它是人工和AI协作的接口：运营在飞书里审核通过某个品，状态更新为“已通过”，后续我们的分析流会自动把这个结果加入样本库，用于后面调权重的参考。审批流做的是“人工兜底”和“决策留痕”。最开始我们尝试让AI全自动推荐、运营只看结果，但运营不敢用，因为万一AI推荐错了，责任归属说不清。后来改成AI推荐 + 人工审批的模式，每一个候选品都需要运营在飞书里点一下审核，结果回写到多维表格。虽然多了一步操作，但大家敢用了，数据也有了。这个教训挺重要：在业务场景里，AI系统落地的关键不是做到多高的准确率，而是要让业务人员觉得“可控”。4. 实操过程：从零搭建一套可复现的最小系统接下来是全文的干货部分，我会按实际动手的顺序，把这套系统从零到上线的主流程完整走一遍。这里不涉及具体的服务器配置细节，聚焦在关键步骤和容易出错的位置上。我们没有用特别复杂的分布式架构，早期就是一台普通应用服务器，OpenClaw跑在工作流容器里，飞书是SaaS服务，三方数据源各自在远端，整个系统的运维压力其实不大。4.1 第一步：初始化工作流配置OpenClaw的安装过程就不废话了，官方文档都有。初始化之后，最先要做的是把工作流骨架搭出来，我建议在代码仓库里建一个清晰的项目目录，把配置文件和代码分开，结构大概是这样：selecting-pipeline/ ├─ config/ │ ├─ datasources.yaml # 数据源注册与字段映射 │ ├─ agents.yaml # Agent定义与Prompt配置 │ └─ schedule.yaml # 定时任务定义 ├─ adapters/ │ ├─ base_adapter.py # 适配器基类 │ ├─ platform_a.py # 某电商平台适配器 │ ├─ insight_b.py # 某市场洞察服务适配器 │ └─ hotword_c.py # 某内容平台热词适配器 ├─ workflows/ │ ├─ daily_select.py # 每日选品主流程 │ └─ report_push.py # 飞书推送子流程 └─ logs/目录结构设计有一个值得说道的点：把每个数据源的适配器独立成文件，而不是写在一个总类里。早期我们为了省事，把三个数据源的转换逻辑写在了一个文件里，结果每次改一个数据源都要全量回归，复杂度上升很快。拆开之后，每个适配器只对一种数据源负责，新增数据源时就是复制一个文件改配置的事。然后是配置数据源。在datasources.yaml里，我们把每个数据源的接入方式、鉴权信息、字段映射声明清楚。下面是一段简化的配置示意：sources: - id: platform_a_sales type: rest endpoint: https://api.example-a.com/v3/trend auth: method: sign key_env: PLATFORM_A_KEY secret_env: PLATFORM_A_SECRET schedule: hourly mapping: item_id: data.items.id category: data.items.cat_name search_index: data.items.search_idx sales_amount: data.items.gmv # 单位换算：原始单位是千元，统一转为元 sales_amount_unit: multiply sales_amount_multiplier: 1000这段配置要表达的是：接入层启动时读取配置，动态生成对应的调用逻辑，不需要硬编码在代码里。实际落地时，配置文件和代码是同步管理的，每次改配置都走代码评审，防止“配置漂移”问题。这里还有一个小坑要提醒：鉴权信息不要明文放在配置里，我们用的方式是从环境变量里读取，配置文件只写环境变量名，避免不小心把密钥提交到仓库。4.2 第二步：准备飞书应用与多维表格飞书侧的工作分两块，一块是创建自建应用拿权限，另一块是设计多维表格结构。创建自建应用这件事，说白了就是去飞书开放平台后台新建一个应用，拿到App ID和App Secret，然后申请操作权限。权限方面，我们申请了一组固定的作用域，包括发送消息到群聊、读写多维表格、获取用户基本信息。这里注意一个常见问题：飞书的权限有的申请完立刻生效，有的是发布应用版本后才生效，如果发现调用时报权限不足，大概率是版本没发布。另一个坑是，自建应用的权限范围是按文档范围来控制的，不要在代码里写死某个具体的表或者群ID，因为权限校验会跟着文档权限走，写死之后一旦重命名就会静默失败。多维表格的结构直接决定了后续数据的可用性。我们建的选品池表格，字段设计如下：字段名字段类型说明品名文本商品/品类名称类目单选所属类目层级数据来源多选命中的三方数据源综合评分数字0-100综合分需求热度分数字子维度分竞争强度分数字子维度分利润空间分数字子维度分供应链分数字子维度分推荐理由文本AI生成的一句话理由状态单选待审核/已通过/已驳回/已上架运营备注文本运营人工填写的补充审核人人员审批流自动写入三维表字段别贪多，运营真正会看的字段就那几个。之前我往表里塞了20多个字段，运营反馈看一眼就头皮发麻，后来砍到12个字段，反而用得更勤快。表格建好后，要在多视图里做一个“运营视图”，按状态分组，默认只显示待审核的记录，这样打开表格就是待办清单，体验很顺。4.3 第三步：接入三方数据服务并跑通全链路数据源接入是这套系统里最耗时的环节。以某平台A的适配器为例，我们做的第一件事是在沙箱环境里调用一次接口，把返回的原始JSON完整保存下来，然后对着文档逐字段核对。这一步一定不能省，多数接口文档和真实返回有出入，比如字段名是下划线还是驼峰，嵌套层级是不是跟文档一致。我们把核对结果记录在数据源登记表里，再开始写映射配置。写适配器的时候，我建议先实现一个基类，把重试、限流、日志都放在基类里，子类只实现两件事：请求参数拼装和响应解析。这样的好处是，后续新增数据源时，子类代码量很小，不容易出错。有一点要留意：三方接口的响应结构尽量不要在解析时用“假设最深层路径”的方式，而是用“先定位外层，再逐层取字段”的方式，因为只要对方在内层加了一个包装字段，整条路径就断了，而外层定位通常更稳定。跑通第一个数据源之后，建议手动触发一次全链路测试：数据源适配器 → 数据整理Agent → 选品分析Agent → 飞书机器人推送。这个测试路径不要图省事跳过Agent，直接用脚本造数据推飞书。Agent环节最容易出问题，比如数据格式不对导致Prompt解析失败、AI超时、输出格式不满足飞书推送的模板要求等，这些只有真正跑一遍才会暴露。4.4 第四步：上线验证与灰度从“能跑”到“敢用”，中间还差一个验证环节。我们没有让AI系统直接替代人工，而是采用“影子模式”跑了两周：每天AI照常推荐候选品，但运营还是按原来的方式选品，两边结果做对照。我们统计三个核心指标：命中率（AI推荐Top10里有多少被运营最终选中）、覆盖率（运营最终选中的品有多少在AI推荐列表里）、时间消耗（运营做一轮选品从原来的多久缩短到多久）。第一周的命中率只有三成左右，运营觉得“这AI也就那样”。我们分析了AI推荐的候选品和运营实际选品的差异，发现主要问题出在供应链维度上：运营手里有表格里看不到的隐性信息，比如某供应商最近配合度差、某个货源地物流不稳，这些AI不知道。后来我们在飞书审批流里加了一个“驳回理由”必填项，把这些隐性知识一点点沉淀成结构化数据，再回填到评分模型里。到第二周结束，命中率提升到了五成以上，时间消耗从原来的每人每天两三个小时压缩到二十分钟左右。这时候运营才真正愿意把它作为日常工具使用。5. 常见问题与排查技巧实录系统跑起来之后，日常维护的核心工作变成了各种问题排查。这一节把我们在两个多月里遇到的高频问题整理成一份速查表，每个问题都附上排查思路，这些经验在别的地方不容易搜到，属于拿时间换来的。5.1 三方数据接口联调阶段现象可能原因排查方法解决方式接口偶尔返回401，但重新调用又好了签名里带的时间戳过期，服务器时间存在偏移对比本机时间与服务端返回的响应头时间启用NTP时间同步，签名时间放宽到5分钟窗口同样的参数，不同的数据源返回的字段名对不上各家字段命名规范不同核对数据源登记表字段映射统一在映射配置里做字段翻译，不直接在代码里判断数据拉取偶尔出现乱序/重复记录数据源侧网络不稳定导致消息重推在适配器里记录消息唯一ID做幂等去重，按ID + 业务日期唯一索引某一天数据明显缺失，但日志显示调用成功数据源阶段性更新延迟核对对方的数据更新公告在配置里增加各数据源的可接受延迟时间，超过则告警这类问题最核心的排查方法是：所有对三方接口的调用，都必须把“原始响应完整body”和“本次调用的请求参数”一起记录到日志里。不要只记录解析后的结果，否则出了问题很难回溯到底是什么数据导致了解析异常。我们后来给每次适配器调用都生成一个requestId，日志里同时打印请求和响应，排查效率至少翻倍。5.2 OpenClaw 工作流运行问题工作流跑起来之后，最先遇到的是任务不按时触发。明明设置每天早上8点跑，结果有些天8点没跑，有些天8点半才跑。查了一下发现是定时表达式里的时区问题，OpenClaw容器默认使用UTC时区，而我们的业务时区比UTC快8个小时，表达式写的是服务器本地时间，自然就错位了。解决方式是统一在配置里显式指定时区，并把日志里的时间戳也统一成业务时区，否则排查时看到的时间跟实际触发时间对不上，非常容易误判。第二个问题是大模型的上下文污染。选品分析Agent在长周期运行后，如果设计成对话模式，前面的对话内容会进入上下文，导致后续输出的判断基准漂移。比如上一轮分析的是家居类目，下一轮换成美妆类目时，如果上下文没有正确隔离，AI的评分口径就会带上上一轮的影子。我们的做法是：选品分析Agent每次都做无状态调用，不保留跨轮对话记忆，所有业务上下文都通过结构化输入传递。这样虽然牺牲了一点“记忆能力”，但对评分稳定性帮助很大。第三个问题是AI输出超时或输出格式不稳定。飞书推送需要固定结构，但大模型的输出偶尔会有多一个逗号、少一个结尾括号的情况，直接解析会失败。我们在工作流里加了一个“格式校验 + 自动修复”的环节，先按模板严格解析，解析失败就交给一个小模型重试一次，而不是直接报错中断。重试仍然失败的情况下，把原始输出发到告警群人工处理。实测下来，这样能把推送成功率稳定在99%以上。5.3 飞书侧集成问题飞书侧的问题集中在两个地方，一个是权限，一个是限流。权限问题前面提过，版本发布后才能生效、代码里不要写死资源ID，这里不再重复。限流的问题是：多维表格的写入API有频率限制，我们刚开始全量写入候选品时，一次性写几百条记录，频繁触发限流报错。解决方式是改成批量写入，每次不超过50条，并且加上指数退避重试。另一个经验是，写表格前先查一下目标表格是否存在、字段ID是否匹配，避免因为表格被人手动改过字段、导致写入时字段ID对不上而报错，这种问题日志里看起来是网络异常，实际上根本不是。机器人消息推送还有一个很隐蔽的坑：消息里如果带了链接，而这个链接指向的多维表格没有给机器人所在的群开启权限，用户点击时会提示“无权访问”。我们一开始推送消息里的候选品报告链接，运营点进去一片红，后来在飞书后台把多维表格的权限配置成“群内可见”，才算解决。这个排查花了半天，事后想想，其实是权限最小化原则的反面教材：为了安全把所有权限都收窄了，结果反而破坏了使用体验。5.4 避坑速查表高频坑一句话建议三方接口返回字段名和文档不一致接入前先打印一次原始响应，逐字段核对文档服务器时区和定时任务错位所有时区配置显式声明，日志统一走业务时区大模型输出不稳定导致下游解析失败增加格式校验与自动修复，不直接中断主流程飞书权限修改后不生效修改权限后记得发布新版本应用多维表格字段被手动修改导致写入异常写前校验字段ID，并规范表格管理流程数据源限流导致拉数中断适配层做令牌桶 + 指数退避，不要暴力重试这套系统上线到现在，最大的感受是：AI电商选品这件事，技术难点其实不在“选品模型”有多聪明，而在于把散落的工具串成一个可用的闭环。OpenClaw解决的问题是让多个AI角色能协作、能调度、能按规则跑，飞书解决的问题是让业务人员愿意用、用得上、操作成本低，三方数据服务商则提供了源头数据。三个环节缺一个，这套系统都落不了地。最后分享一个个人认为很值得做的扩展方向：目前我们把“运营驳回理由”沉淀到了多维表格，但这些反馈还没有自动回流到评分模型的权重调整里。下一步我们计划让OpenClaw定期分析这些人工反馈和最终商品表现数据，自动给出权重调整建议，让这套系统的选品水平能做到持续迭代。到那个时候，它就不只是一个效率工具，而是一个会慢慢长出业务经验的数字选品助理。
做跨境电商选品这行当，最折磨人的不是找不到数据，而是数据散落在各种地方：某平台后台的销量趋势、运营工具里的关键词热度、供应链那边给的供货价，还有三方数据服务商每周发来的一堆行业报告。以前我们团队的做法是运营手动汇总Excel，技术这边每天写脚本定时抓几个公开接口，晚上统一做清洗入库，再人工看报表挑品。这套流程一周能跑一轮就不错了，等你看上某个品，市场行情早变了。所以当OpenClaw这种智能体编排框架进入视野之后，我第一个想法就是把它和飞书打通，做一套AI电商选品系统，让智能工作流把“数据收集、品类分析、候选推荐”三件事串起来，最后直接通过飞书推到运营面前，选出结果还能在线走审批。这套系统从立项到跑通主流程花了两周多，中间踩了不少坑，也沉淀了一些实打实的经验，今天把整个落地过程拆开聊聊。1. 为什么是 OpenClaw + 飞书：从业务痛点反推技术选型很多人一听到“AI选品系统”，第一反应是做个大模型对话页面，让运营把需求打字进去，AI输出几个品。我一开始也这么想过，但和运营聊完需求就发现方向错了：他们要的不是一个对话机器人，而是一套能把日常工作流程替代掉的东西。运营每天打开电脑第一件事是刷平台后台看飙升榜，第二件事是把三方数据服务商发来的Excel搬到共享表格里，第三件事是凭经验开会讨论哪个品值得上。这些动作有80%都是重复的、结构化的，完全可以由工作流自动化完成。所以选型的核心不是“AI问答”，而是“流程自动化+AI分析能力”的组合。1.1 电商选品到底难在哪选品这个场景有一个非常典型的特点：信息维度多、更新节奏快、决策链路长。一个品能不能做，通常要综合看需求热度、竞争强度、利润空间、供应链适配度四个方向。需求热度看搜索指数和销量增速，竞争强度看商家数量、头部集中度，利润空间要结合广告成本、平台佣金、供货价来测算，供应链适配度又要看现有供应商能不能稳定供货。这些数据分散在不同系统里，人工整合天然就慢，等得久了数据时效性就没了。另一个痛点是复盘的缺失。每周选出来的品，最后实际表现怎么样，很少有人认真回看。不是不想看，是数据都在Excel里、在群里、在每个人的脑子里，根本没法系统性地对照。这就导致选品经验很难沉淀，选品这件事长期停留在“老师傅手感”阶段。这套系统在设计的时候，我特意把“每轮候选品的后续表现回写”也作为一个核心需求，目的就是让AI的推荐质量和人工决策效果能被持续校验。1.2 技术选型的三个关键判断先说OpenClaw为什么合适。它本质上是把AI能力编排成一套可执行的工作流，你可以定义多个Agent角色，让它们分工干活：一个负责拉数，一个负责分析，一个负责生成报告，并且支持定时触发、外部API接入、上下文记忆。这正好覆盖了我们前面说的“数据收集、品类分析、候选推荐”三个环节。用传统开发方式做这套流程，至少要写几千行代码去做任务调度、状态管理、工具集成，而OpenClaw把编排层的事情收敛了，我们只用关心业务本身和配置怎么描述。再说飞书。选飞书不是因为市面上没有别的协同工具，而是因为它有一个其他平台不好替代的组合能力：机器人消息推送可以做到主动找人，多维表格可以当成轻量业务数据库，审批流可以把人工决策嵌进自动化链路里。也就是说，飞书既能当“显示器”也能当“操作台”，AI分析完的结果推送给人看，人看完直接在飞书里点通过或驳回，状态还能自动回写。这种闭环体验，比自建一个后台管理页面轻量得多，运营零学习成本。最后说为什么不能直接用RPA或者自己写定时脚本。RPA擅长的是模仿人操作界面，但面对三方数据服务商返回的各种非结构化、半结构化数据，它的解析和智能判断能力很弱，而且要跟着对方页面改版不断返工。自己写脚本倒是可行，但选品分析的核心不只是“把数拉下来”，还要“看懂数据”，比如某个品类销量涨了20%，要判断是季节性波动还是持续趋势，这就必须引入大模型的分析能力。OpenClaw恰好把这两件事缝合在了一起。1.3 整体架构怎么搭整个系统的逻辑可以分成三层。最底层是数据接入层，负责跟三方数据服务商对接，把不同格式的数据统一成标准结构；中间是AI分析层，由OpenClaw工作流里的多个Agent执行，负责对标准化数据做清洗、评分、排序、生成推荐结论；最上层是协同输出层，也就是飞书，负责把结论展示给运营、收集人工反馈、沉淀历史决策数据。这里有一个容易忽略的点：数据接入层虽然叫“接入”，但它不只是一个API转发器。三方服务商各自的数据口径、字段命名、更新频率都不一样，如果不做统一适配，AI分析层的Prompt根本没法写，因为同一个字段在不同数据源里叫的名字都不一样，比如有的叫“gmv”，有的叫“成交金额”，还有的叫“sales_value”。所以我们在中间加了一个适配器，把这些差异在进AI之前全部抹平。这块细节比较多，下一节单独展开。2. 三方数据服务的对接实践：从接口混乱到统一适配我跟不少做技术的朋友聊过，大家对接三方数据服务商的第一反应都是拿着对方文档挨个调接口，代码写起来很快，但真正跑起来全是问题。这次我们接了三类数据源：某电商平台的商品销量与搜索指数数据、某市场洞察服务商的行业品类趋势数据、某内容平台的短视频/图文热词数据。每一家的对接方式都不一样，有的提供标准REST API，有的是定时推送Webhook到我们服务器，还有一家干脆只给文件导出的方式，每天把CSV发到一个临时下载地址。把这三类揉到一套系统里，统一适配层是必须做的事。2.1 数据服务商选型与协议梳理先说选型。我们在评估数据服务商的时候，不只看数据质量，还重点看了三个东西：是否有明确的数据更新频率说明、接口是否有稳定的调用配额、是否提供沙箱测试环境。有个服务商数据维度很全，但接口限流非常狠，每秒只能调两次，这种接到生产环境里连基础的数据量都跑不满，根本没法用。后来选定的服务商，有的是按条数计费，有的是按调用次数计费，这个也要提前弄清楚，否则跑一轮全量数据成本会吓人。然后是协议梳理。每家对接方式差异很大，落地时我建议先做一张“数据源登记表”，把每个服务商的基本信息固定下来：接口地址、鉴权方式（是AppKey还是Token还是签名）、调用配额、返回格式（JSON还是XML）、更新频率（实时还是T+1）、字段字典（对应关系）。这张表是后续写适配器的依据，也是排查问题时的第一手资料。我们组里当时就是靠这张表，才发现某个服务商把日期字段的时区设成了UTC，导致每天的数据在应用层显示都慢8个小时，排查了一下午。2.2 统一数据适配层怎么做统一适配层做的事情其实就三件：定义标准结构、写转换逻辑、做稳定性兜底。标准结构是我们自己定义的“选品数据中间格式”，所有数据源进来之后都转成这个格式，再送到AI分析层。字段不多，核心就几类：商品/品类的标识、所属类目层级、统计日期、需求热度相关指标（搜索指数、浏览量）、成交相关指标（销量、销售额、增速）、竞争相关指标（在售商家数、集中度）、利润相关指标（均价、参考毛利）。转换逻辑就是针对每个数据源写一个适配器，把对方的字段映射到我们的标准字段上。这里有个经验：不要把所有转换逻辑都堆在一个大函数里，而是用一个配置驱动的思路，把“哪个数据源的哪个字段对应哪个目标字段”写成配置。这样新接入一个数据源时，大部分情况下只改配置就能上线，不需要动代码。不过要注意，配置驱动有个坑：文档和配置会脱节，数据源那边字段改了，配置没同步改，线上就静默出错。我们的做法是写了一个字段完整性校验，每次拉数后对比配置里声明的字段和实际返回的字段，不一致立刻告警。稳定性兜底主要包含重试、限流、幂等和三方故障熔断。重试不能无脑重试，要根据不同的错误码区别对待：限流错误要退避重试，签名失效要重新签名后再试，参数错误重试多少次都没用，直接告警让人来看。限流的话，我们在适配器里做了令牌桶，按各数据源配额动态调整。幂等这块容易被忽略，某数据服务商有一次网络抖动导致消息重复推送，如果消费端不做去重，数据就会重复计算，评分直接漂移。至于熔断，设定一个简单规则：连续10次调用失败就熔断15分钟，不再打对方接口，避免把对方服务打死，等恢复后再继续。2.3 数据质量保障数据质量是AI选品系统的生命线，数据不准，AI再聪明也白搭。我们实际踩过的数据质量坑至少有四类。第一类是空值问题。某服务商返回的数据里，部分类目当天没有销量数据时会返回空，如果直接用空值做标准化，下游评分就会出错。我们在清洗环节把所有空值都显式处理成“该字段缺失”标记，并在评分时对缺失字段做权重收缩，不让一个缺失字段拖垮整个评分。第二类是离群数据。某个品类某一天的销售额突然涨了50倍，一看是平台大促或某个头部链接爆发，如果不做处理，AI会把这种短期脉冲误判成趋势。我们加了一层波动校验：当某个指标单日变化幅度超过预设阈值时，自动标记为“异常波动”，分析层会把它降权处理，除非连续多日维持高位才算趋势。第三类是单位统一。不同数据源的单位千差万别，有的销售额单位是元，有的是千元，甚至有的服务商用美元口径。这听起来很基础，但在真实数据里就会混在一起，标准化时稍微漏一个单位字段，评分结果就差出好几个量级。我们专门做了一个单位换算表，任何字段进入标准格式前必须经过单位校验。第四类是增量与全量的策略。有些数据源支持按时间增量拉取，有些只支持全量拉取再本地做差。全量拉取耗时和成本都高，所以我们在适配器里做了一层“本地增量”机制：每次全量拉到本地以后，跟上一轮数据做diff，只保留变化的部分进入分析层，再定期做一次全量校准，防止diff累积出错。3. AI 选品逻辑与工作流的拼接数据层稳定之后，真正体现系统价值的就是AI选品逻辑这层。这里有一个常见误区：很多人觉得AI选品就是丢一堆数据给大模型，让它“分析一下推荐几个品”。这样做出来结果一定不能直接用，因为大模型容易一本正经地编数据，而且对业务口径没有感知。我们的做法是把它拆成“规则评分 + AI增强解读”两个阶段。规则评分负责客观的量化计算，AI负责把结果转成人话、补充数据之外的判断逻辑。3.1 选品评估模型怎么定义先讲量化评分。我们把选品看成一个多因子打分问题，如果只用一个指标，比如只看销量增速，很容易被低价冲量或刷单数据带偏。我们选了四个维度，每个维度下面再去细分子指标，这里给出我们用的维度和权重，供参考：评估维度子指标示例初始权重需求热度搜索指数、销量增速、内容平台话题热度35%竞争强度在售商家数、头部链接集中度、广告竞价水平25%利润空间参考毛利率、客单价、平台佣金占比25%供应链适配现有供应商匹配度、履约时效、补货周期15%权重不是一成不变的，初期是业务团队开会拍脑袋定的，跑了三周之后根据运营反馈做了调整：比如某个品类搜索热度很高但供应链完全没法做，那需求热度的分再高也没意义，供应链的权重就往上调了。这个调整过程建议不要频繁动，至少跑两周积累数据后再调，否则无法判断是权重问题还是数据问题。评分计算前要做标准化，因为各指标单位不同，比如搜索指数可能是几万量级，毛利率是百分比，不能直接加总。我们用min-max归一化把每个指标压到0到1，再按权重加权求和。需要留意的是，归一化的上下界要用历史数据的分位数来定，不要用绝对最大最小值，否则某个品类的异常值会把正常值全压到很低。3.2 OpenClaw 里的 Agent 设计OpenClaw里我们定义了两个核心Agent，一个叫数据整理Agent，一个叫选品分析Agent，再加一个定时触发器把它们串起来。数据整理Agent的职责是：从统一适配层拿最新数据，做时间窗口筛选（比如只看最近7天和最近30天的趋势），生成一份结构化的“待分析数据集”，输出成JSON给下游。这里的要点是，不要让整理Agent做太多清洗工作，清洗在适配层已经完成了，Agent只做按需筛选，各司其职。选品分析Agent是我们提示词工程的重头戏。它的输入是结构化数据集加上运营配置的过滤条件（比如排除某个类目、指定价格带），输出是一份包含候选品列表、每个品的综合评分、评分依据分析、风险提示的Markdown报告。为了让AI不编数据，我们在Prompt里强约束了三点：一是所有数据引用必须来自输入的数据集，不允许擅自补充外部数据；二是如果要给出判断，必须说明是基于哪个字段得出的，比如“因为搜索指数环比上涨40%，所以需求热度上调”；三是如果数据不足，允许直接说“数据不足”而不是强行推荐。这三点约束下来，AI输出的可参考性提升非常明显。3.3 飞书侧的能力设计选品分析Agent出报告之后，接下来的动作都是飞书完成的，这块设计得直接关系到运营是否愿意用。我们把飞书侧拆成三个能力：机器人推送、多维表格沉淀、审批回传。机器人推送是最直观的触达。每天早上定时任务跑完后，工作流调用飞书机器人，把选品日报推送到一个专门的选品群里。日报内容包括：今日高潜候选品Top10列表、各维度评分摘要、值得关注的异常品类提醒。这里有一个体验小技巧：推送内容不要一大篇文字糊上去，要结构化，每个候选品一行，带评分、带一句话推荐理由，想看详情的直接点链接跳转多维表格。运营在手机上就能快速扫一遍，这是这套系统能被日常使用的前提。多维表格承担“选品池”的角色。我们建了一个选品池表格，字段包括：品名、类目、来源数据源、综合评分、需求热度分、竞争分、利润分、状态（待审核/已通过/已驳回）、运营备注。每一轮AI跑完，候选品自动写入这个表。这里的设计重点是状态字段，它是人工和AI协作的接口：运营在飞书里审核通过某个品，状态更新为“已通过”，后续我们的分析流会自动把这个结果加入样本库，用于后面调权重的参考。审批流做的是“人工兜底”和“决策留痕”。最开始我们尝试让AI全自动推荐、运营只看结果，但运营不敢用，因为万一AI推荐错了，责任归属说不清。后来改成AI推荐 + 人工审批的模式，每一个候选品都需要运营在飞书里点一下审核，结果回写到多维表格。虽然多了一步操作，但大家敢用了，数据也有了。这个教训挺重要：在业务场景里，AI系统落地的关键不是做到多高的准确率，而是要让业务人员觉得“可控”。4. 实操过程：从零搭建一套可复现的最小系统接下来是全文的干货部分，我会按实际动手的顺序，把这套系统从零到上线的主流程完整走一遍。这里不涉及具体的服务器配置细节，聚焦在关键步骤和容易出错的位置上。我们没有用特别复杂的分布式架构，早期就是一台普通应用服务器，OpenClaw跑在工作流容器里，飞书是SaaS服务，三方数据源各自在远端，整个系统的运维压力其实不大。4.1 第一步：初始化工作流配置OpenClaw的安装过程就不废话了，官方文档都有。初始化之后，最先要做的是把工作流骨架搭出来，我建议在代码仓库里建一个清晰的项目目录，把配置文件和代码分开，结构大概是这样：selecting-pipeline/ ├─ config/ │ ├─ datasources.yaml # 数据源注册与字段映射 │ ├─ agents.yaml # Agent定义与Prompt配置 │ └─ schedule.yaml # 定时任务定义 ├─ adapters/ │ ├─ base_adapter.py # 适配器基类 │ ├─ platform_a.py # 某电商平台适配器 │ ├─ insight_b.py # 某市场洞察服务适配器 │ └─ hotword_c.py # 某内容平台热词适配器 ├─ workflows/ │ ├─ daily_select.py # 每日选品主流程 │ └─ report_push.py # 飞书推送子流程 └─ logs/目录结构设计有一个值得说道的点：把每个数据源的适配器独立成文件，而不是写在一个总类里。早期我们为了省事，把三个数据源的转换逻辑写在了一个文件里，结果每次改一个数据源都要全量回归，复杂度上升很快。拆开之后，每个适配器只对一种数据源负责，新增数据源时就是复制一个文件改配置的事。然后是配置数据源。在datasources.yaml里，我们把每个数据源的接入方式、鉴权信息、字段映射声明清楚。下面是一段简化的配置示意：sources: - id: platform_a_sales type: rest endpoint: https://api.example-a.com/v3/trend auth: method: sign key_env: PLATFORM_A_KEY secret_env: PLATFORM_A_SECRET schedule: hourly mapping: item_id: data.items.id category: data.items.cat_name search_index: data.items.search_idx sales_amount: data.items.gmv # 单位换算：原始单位是千元，统一转为元 sales_amount_unit: multiply sales_amount_multiplier: 1000这段配置要表达的是：接入层启动时读取配置，动态生成对应的调用逻辑，不需要硬编码在代码里。实际落地时，配置文件和代码是同步管理的，每次改配置都走代码评审，防止“配置漂移”问题。这里还有一个小坑要提醒：鉴权信息不要明文放在配置里，我们用的方式是从环境变量里读取，配置文件只写环境变量名，避免不小心把密钥提交到仓库。4.2 第二步：准备飞书应用与多维表格飞书侧的工作分两块，一块是创建自建应用拿权限，另一块是设计多维表格结构。创建自建应用这件事，说白了就是去飞书开放平台后台新建一个应用，拿到App ID和App Secret，然后申请操作权限。权限方面，我们申请了一组固定的作用域，包括发送消息到群聊、读写多维表格、获取用户基本信息。这里注意一个常见问题：飞书的权限有的申请完立刻生效，有的是发布应用版本后才生效，如果发现调用时报权限不足，大概率是版本没发布。另一个坑是，自建应用的权限范围是按文档范围来控制的，不要在代码里写死某个具体的表或者群ID，因为权限校验会跟着文档权限走，写死之后一旦重命名就会静默失败。多维表格的结构直接决定了后续数据的可用性。我们建的选品池表格，字段设计如下：字段名字段类型说明品名文本商品/品类名称类目单选所属类目层级数据来源多选命中的三方数据源综合评分数字0-100综合分需求热度分数字子维度分竞争强度分数字子维度分利润空间分数字子维度分供应链分数字子维度分推荐理由文本AI生成的一句话理由状态单选待审核/已通过/已驳回/已上架运营备注文本运营人工填写的补充审核人人员审批流自动写入三维表字段别贪多，运营真正会看的字段就那几个。之前我往表里塞了20多个字段，运营反馈看一眼就头皮发麻，后来砍到12个字段，反而用得更勤快。表格建好后，要在多视图里做一个“运营视图”，按状态分组，默认只显示待审核的记录，这样打开表格就是待办清单，体验很顺。4.3 第三步：接入三方数据服务并跑通全链路数据源接入是这套系统里最耗时的环节。以某平台A的适配器为例，我们做的第一件事是在沙箱环境里调用一次接口，把返回的原始JSON完整保存下来，然后对着文档逐字段核对。这一步一定不能省，多数接口文档和真实返回有出入，比如字段名是下划线还是驼峰，嵌套层级是不是跟文档一致。我们把核对结果记录在数据源登记表里，再开始写映射配置。写适配器的时候，我建议先实现一个基类，把重试、限流、日志都放在基类里，子类只实现两件事：请求参数拼装和响应解析。这样的好处是，后续新增数据源时，子类代码量很小，不容易出错。有一点要留意：三方接口的响应结构尽量不要在解析时用“假设最深层路径”的方式，而是用“先定位外层，再逐层取字段”的方式，因为只要对方在内层加了一个包装字段，整条路径就断了，而外层定位通常更稳定。跑通第一个数据源之后，建议手动触发一次全链路测试：数据源适配器 → 数据整理Agent → 选品分析Agent → 飞书机器人推送。这个测试路径不要图省事跳过Agent，直接用脚本造数据推飞书。Agent环节最容易出问题，比如数据格式不对导致Prompt解析失败、AI超时、输出格式不满足飞书推送的模板要求等，这些只有真正跑一遍才会暴露。4.4 第四步：上线验证与灰度从“能跑”到“敢用”，中间还差一个验证环节。我们没有让AI系统直接替代人工，而是采用“影子模式”跑了两周：每天AI照常推荐候选品，但运营还是按原来的方式选品，两边结果做对照。我们统计三个核心指标：命中率（AI推荐Top10里有多少被运营最终选中）、覆盖率（运营最终选中的品有多少在AI推荐列表里）、时间消耗（运营做一轮选品从原来的多久缩短到多久）。第一周的命中率只有三成左右，运营觉得“这AI也就那样”。我们分析了AI推荐的候选品和运营实际选品的差异，发现主要问题出在供应链维度上：运营手里有表格里看不到的隐性信息，比如某供应商最近配合度差、某个货源地物流不稳，这些AI不知道。后来我们在飞书审批流里加了一个“驳回理由”必填项，把这些隐性知识一点点沉淀成结构化数据，再回填到评分模型里。到第二周结束，命中率提升到了五成以上，时间消耗从原来的每人每天两三个小时压缩到二十分钟左右。这时候运营才真正愿意把它作为日常工具使用。5. 常见问题与排查技巧实录系统跑起来之后，日常维护的核心工作变成了各种问题排查。这一节把我们在两个多月里遇到的高频问题整理成一份速查表，每个问题都附上排查思路，这些经验在别的地方不容易搜到，属于拿时间换来的。5.1 三方数据接口联调阶段现象可能原因排查方法解决方式接口偶尔返回401，但重新调用又好了签名里带的时间戳过期，服务器时间存在偏移对比本机时间与服务端返回的响应头时间启用NTP时间同步，签名时间放宽到5分钟窗口同样的参数，不同的数据源返回的字段名对不上各家字段命名规范不同核对数据源登记表字段映射统一在映射配置里做字段翻译，不直接在代码里判断数据拉取偶尔出现乱序/重复记录数据源侧网络不稳定导致消息重推在适配器里记录消息唯一ID做幂等去重，按ID + 业务日期唯一索引某一天数据明显缺失，但日志显示调用成功数据源阶段性更新延迟核对对方的数据更新公告在配置里增加各数据源的可接受延迟时间，超过则告警这类问题最核心的排查方法是：所有对三方接口的调用，都必须把“原始响应完整body”和“本次调用的请求参数”一起记录到日志里。不要只记录解析后的结果，否则出了问题很难回溯到底是什么数据导致了解析异常。我们后来给每次适配器调用都生成一个requestId，日志里同时打印请求和响应，排查效率至少翻倍。5.2 OpenClaw 工作流运行问题工作流跑起来之后，最先遇到的是任务不按时触发。明明设置每天早上8点跑，结果有些天8点没跑，有些天8点半才跑。查了一下发现是定时表达式里的时区问题，OpenClaw容器默认使用UTC时区，而我们的业务时区比UTC快8个小时，表达式写的是服务器本地时间，自然就错位了。解决方式是统一在配置里显式指定时区，并把日志里的时间戳也统一成业务时区，否则排查时看到的时间跟实际触发时间对不上，非常容易误判。第二个问题是大模型的上下文污染。选品分析Agent在长周期运行后，如果设计成对话模式，前面的对话内容会进入上下文，导致后续输出的判断基准漂移。比如上一轮分析的是家居类目，下一轮换成美妆类目时，如果上下文没有正确隔离，AI的评分口径就会带上上一轮的影子。我们的做法是：选品分析Agent每次都做无状态调用，不保留跨轮对话记忆，所有业务上下文都通过结构化输入传递。这样虽然牺牲了一点“记忆能力”，但对评分稳定性帮助很大。第三个问题是AI输出超时或输出格式不稳定。飞书推送需要固定结构，但大模型的输出偶尔会有多一个逗号、少一个结尾括号的情况，直接解析会失败。我们在工作流里加了一个“格式校验 + 自动修复”的环节，先按模板严格解析，解析失败就交给一个小模型重试一次，而不是直接报错中断。重试仍然失败的情况下，把原始输出发到告警群人工处理。实测下来，这样能把推送成功率稳定在99%以上。5.3 飞书侧集成问题飞书侧的问题集中在两个地方，一个是权限，一个是限流。权限问题前面提过，版本发布后才能生效、代码里不要写死资源ID，这里不再重复。限流的问题是：多维表格的写入API有频率限制，我们刚开始全量写入候选品时，一次性写几百条记录，频繁触发限流报错。解决方式是改成批量写入，每次不超过50条，并且加上指数退避重试。另一个经验是，写表格前先查一下目标表格是否存在、字段ID是否匹配，避免因为表格被人手动改过字段、导致写入时字段ID对不上而报错，这种问题日志里看起来是网络异常，实际上根本不是。机器人消息推送还有一个很隐蔽的坑：消息里如果带了链接，而这个链接指向的多维表格没有给机器人所在的群开启权限，用户点击时会提示“无权访问”。我们一开始推送消息里的候选品报告链接，运营点进去一片红，后来在飞书后台把多维表格的权限配置成“群内可见”，才算解决。这个排查花了半天，事后想想，其实是权限最小化原则的反面教材：为了安全把所有权限都收窄了，结果反而破坏了使用体验。5.4 避坑速查表高频坑一句话建议三方接口返回字段名和文档不一致接入前先打印一次原始响应，逐字段核对文档服务器时区和定时任务错位所有时区配置显式声明，日志统一走业务时区大模型输出不稳定导致下游解析失败增加格式校验与自动修复，不直接中断主流程飞书权限修改后不生效修改权限后记得发布新版本应用多维表格字段被手动修改导致写入异常写前校验字段ID，并规范表格管理流程数据源限流导致拉数中断适配层做令牌桶 + 指数退避，不要暴力重试这套系统上线到现在，最大的感受是：AI电商选品这件事，技术难点其实不在“选品模型”有多聪明，而在于把散落的工具串成一个可用的闭环。OpenClaw解决的问题是让多个AI角色能协作、能调度、能按规则跑，飞书解决的问题是让业务人员愿意用、用得上、操作成本低，三方数据服务商则提供了源头数据。三个环节缺一个，这套系统都落不了地。最后分享一个个人认为很值得做的扩展方向：目前我们把“运营驳回理由”沉淀到了多维表格，但这些反馈还没有自动回流到评分模型的权重调整里。下一步我们计划让OpenClaw定期分析这些人工反馈和最终商品表现数据，自动给出权重调整建议，让这套系统的选品水平能做到持续迭代。到那个时候，它就不只是一个效率工具，而是一个会慢慢长出业务经验的数字选品助理。