30 分钟到 10 秒：云飞扬帮一家跨境客户，把上架做成自动化

上架一个商品，原来要花 30 分钟到一个小时；现在一批商品并行跑，实际提交上架只要 10 秒。

做出这个反差的，不是某家大厂的自动化中台，而是我们（云飞扬，腾讯 WorkBuddy 官方服务商）用 腾讯 WorkBuddy，为一家华南跨境电商客户交付的一套上架数字员工。

客户匿名，但提效是实打实的——数字在后面。

一个人、几块屏幕、一堆等着手工搬上线的货——上架慢，根子就在这里

一、客户卡在哪：上架，是个被低估的慢动作

跨境卖家的日常里，很多时间不是花在选品和运营上，而是花在「把货搬上线」这件笨重的事上。

以这家华南跨境电商客户为例，一个 UPC 要走完上架，得依次做几件事：

先从货源站抓取商品信息，再翻译成目标市场的语言，然后逐条填写多个站点的字段、录入商品条码，最后跨不同站点分别提交。整套走下来，一个 UPC 要 30 分钟到一个小时。

一个 UPC 的五步：抓取信息 → 翻译 → 填多站点字段 → 录条码 → 跨站点提交

数量一放大，问题就成了倍。

旺季一天要上新几十个商品，按一个 30 分钟算，就是十几个小时的纯手工活——

几乎得专人从头盯到尾，中途出一次错，还得回头重来。这一个 UPC 的过程，还只是「单个商品」的账。

收尾同样磨人。

商品上架之后，还要到各个站点手动清理重复、冲突的信息，每个站点都要过一遍，又搭进去几分钟。

改促销更麻烦：要切站点、切账号、重新输密码，再一个个改折扣，改错一处就得从头再查一遍。

上架完还要逐站点清理重复信息，改促销要切账号、重输密码——重复劳动最磨人

这些事单看都不难，难的是它们叠在一起——

变成了「明明不缺货、不缺订单，却卡在上架这一步」的尴尬。团队大量精力耗在数据搬运上，而不是选品和增长。老板最怕的不是不会卖，是有货却上不去。

客户真正需要的，不是又一套通用大系统，而是能把自家的上架流程接住的自动化。

二、我们给它做了三件事

01 商品抓取与内容生成

用 CodeBuddy 从货源站把商品信息抓回来，批量翻译、填标签，还能导出快递物流和货箱用的贴单标签——过去靠人工一条条搬，现在一句话触发。

02 跨店跨站点上架克隆

在拉美多站点之间铺货，提供按 UPC、按商品 ID、按链接三种克隆方式，信息更全更稳；哪国卖得好，改个站点就能克隆过去，不用从零再录一遍。

03 促销活动批量提报

多国站点活动统一管；平台规定折扣往低改必须先暂停再重报，我们把它做成 CodeBuddy 里的自动动作——

系统自动识别、先暂停再重报，人不用记规则。

一套系统解决三件事：批量抓取生成、跨店克隆铺货、促销批量提报

三、我们是怎么一步步做出来的

外人看，这是「一个上架工具」；我们自己看，难点从来不在功能本身，而在那些藏在平台规则、接口边界和真实操作习惯里的坑。

整个研发，我们走的是一条踩过坑才确认的路——按时间顺序，分成五步。

先把工具链交代清楚。这一路用的是一套组合：CodeBuddy 负责出方案、搭原型、写实现；代码提交到 CNB，每一次改动都留痕，回滚与复查都有据可查；需求与任务则记在 TAPD 上，做到哪一步、还剩什么，一查就知道。

串起来就是一条接力链：TAPD 管「要做什么」→ CodeBuddy 管「具体怎么实现」→ CNB 管「做完的每一版存在哪」。下面这五步，就是在这条链路上跑出来的。

01 先把客户真实的上架流程摸透

动手之前，我们先看客户原来是怎么做的：

货从哪儿来、一个 UPC 要走哪几步、卡点在哪、哪种操作最容易出错。这一步不做，后面全是白做——

因为上架这件事，流程细节比功能清单更重要。

02 用 CodeBuddy 出高保真原型，确认了再开发

我们并没有一上来就写代码，而是先用 CodeBuddy 搭出一个高保真原型给客户确认：

界面长什么样、点一下发生什么、哪些字段要填。原型对了，再进入正式开发——

避免做出「不是客户要的」这种最贵的返工。

03 把最容易出错的平台规则做成自动动作

克隆提速 + 修误报。

按商品 ID 克隆比按 UPC 更快；我们重点修了克隆「误报」问题——

让系统返回真正的错误原因，而不是只抓片段乱猜，排错时间大幅缩短。

失败自动兜底。

上架偶发失败，CodeBuddy 自动轮巡重试（按 5 → 10 → 15 分钟递增间隔轮巡，最多 5 轮），不用人工盯着重试。

这条是客户真实踩过坑之后，我们硬加上的稳定性保障。

本地加载加速。

页面数据从本地数据表直接加载，比走平台接口逐个拉取快，操作不卡。

对一天要上新几十个商品的团队，这点延迟的差距会被放大成体感。

04 让子代理独立审查，给质量上双保险

这套系统不是「一个人从头写到尾」。

主代理负责需求梳理与方案设计，具体的编码实现交给子代理执行；审查则由另一个上下文完全独立的子代理承担——它看不到主代理的「思路滤镜」，只盯着产物找问题，避免「自己写、自己审」那种看不出毛病的盲区。审出来的问题，再回到 TAPD 上落成待办——谁改的、改到哪，一眼能追。

05 实测迭代，用真实商品验证

上线只是开始。

我们拿真实商品实测，发现问题就改；克隆策略试错过几种，最后才收敛到「按 ID 更快 + 修误报」的组合。所有结论以实测为准，不靠拍脑袋。

一句话概括这条研发路线：先摸流程 → 再出原型 → 把易错规则做成自动动作 → 子代理独立审查 → 实测迭代。质量不靠一个人扛，靠流程和独立审查兜底。

五步研发路：摸流程 → 出原型 → 易错规则自动化 → 独立审查 → 实测迭代

四、效率，落在数字上

这套上架数字员工跑起来后，同一批商品、同一个团队，前后是两种活法。我们把能省的环节一个个拆开看——省在哪、省多少，都落在数字上。

原来

上架 1 个 UPC：30 分钟 ～ 1 小时

现在

多 UPC 并行抓取，6 分钟一轮；实际提交上架仅需 10 秒

额外省

不用再上架后手动清理多站点信息，又省下几分钟

从 30 分钟到 10 秒：不是快了一点，是换了一种工作方式

先把最直观的对比摆出来：

过去上架 1 个 UPC，要 30 分钟到 1 小时；现在系统支持多 UPC 并行抓取上架信息，6 分钟一轮，真正提交上架只要 10 秒。

这不是「快了一点」，而是从「一个一个搬」变成了「一批一批过」。

快在哪？

拆开看有两点。一是抓取方式变了——过去是一个 UPC 一个 UPC 地等，现在是多 UPC 并行，一轮 6 分钟同时处理一批；二是提交方式变了——

页面数据从本地数据表直接读，不走平台接口逐个拉，提交动作本身被压到 10 秒。

过去对照过去

一个 UPC 从抓信息、翻译、填多国字段到跨站点提交，30 分钟～1 小时；上架完还要手动清理多站点重复信息，又搭进去几分钟。批量上新时，几乎得专人盯着一整天。

现在对照现在

多 UPC 并行抓取（6 分钟一轮），实际提交上架 10 秒；多站点信息自动同步，不用再手动清理。

批量上新时，人只需把任务挂上，剩下的交给系统跑。

省下的不只是时间。

一次要上几十个商品时，人力从「专人盯着搬」变成「挂个任务走人」；省下来的这段时间，回到选品、回到增长这些真正值钱的事上。

稳定性上，误报修复让返工变少、轮巡重试让失败不用人守——这两项也在悄悄省时间。

一句话：

原来一个人一小时勉强上一个，现在一批 UPC 并行跑、提交只要 10 秒，还顺手省掉了最烦的手动清理。

提效是数量级的——不是「快了一点」，是「换了一种工作方式」。

五、我们踩过的坑，变成三条经验

01 客户的判断不一定准

AI 提边界问题时，客户常凭使用经验判断，未必真实——要实测、要拿最真实的反馈，而不是「客户说能就行」。

02 查问题让 AI 给依据，再人工复核

让 AI 说出「依据是什么」，再结合人工判断它查的原因是否站得住脚。光看结论不行，得看它凭什么下结论。

03 行不通就换思路

一条路走不通，立刻换方案，不硬刚。上架这件事试错过几种克隆策略，最后才收敛到「按 ID 更快 + 修误报」的组合。

一句话记住

好的数字员工，不是替人做决定，是把人从最重复的活里解放出来。

六、我们交付的，是一套能跑的提效

这套上架数字员工，底层跑在 腾讯 CodeBuddy 上，由我们（云飞扬）作为腾讯 WorkBuddy 官方服务商落地交付。

类似的打法——高频、有规则、可核对——合同风险体检、报销核对、简历筛选、商品上架，都能用 CodeBuddy 这么搭。

想知道你自己的跨境上架 / 多场景流程，能不能也用 腾讯 CodeBuddy 这样提效？
加微 linkkap168（备注「AI 上架」）——具体做法与落地思路，由腾讯 WorkBuddy 官方服务商云飞扬整理