从重复铺货到一句话交付：一位工程师如何用 WorkBuddy Skills 把业务自动化

从重复铺货到一句话交付：一位工程师如何用 WorkBuddy Skills 把业务自动化

一句话总结：把「多平台货源同步 → 整理商品资料 → 提交电商后台上架」以及「业务运营数据分析」等重复流程，封装成一组可安装、可培训、可验收的 Agent Skills，让业务同事用自然语言就能驱动 WorkBuddy 完成端到端交付。

01 背景：业务跑得很快，人却总在重复劳动

在 B2B / B2C 电商团队里，「商品上架」是最高频、也最耗人的动作之一。与此同时，运营、商品、增长等岗位每天还要做大量数据分析——看 GMV、看转化、找异常原因——同样高度依赖「找数据同学问口径 → 导数 → 人工分析」的老路子。

一条典型上架链路往往长这样：

1. 从批发货源平台或供应商相册类平台找到货源
2. 手动复制标题、货号、价格、规格、主图、详情图
3. 在自有电商后台逐项填写、上传图片、核对 SKU
4. 提交后还要再登录平台确认是否真正上架成功

对运营同事来说，这是机械劳动；对工程师来说，这是高度结构化、却长期没能被工具化的流程——每次需求变动，都要重新写脚本、写文档、做培训，维护成本很高。

WorkBuddy 近期完成全新升级，全面兼容 OpenClaw / Agent Skills 开放标准。这给了我们一个机会：不再把自动化做成「只有工程师能跑的脚本」，而是做成业务同事也能一句话调用的能力包。

02 解法：不是写更多 Prompt，而是交付一组 Skills

我们的目标很明确：

让 WorkBuddy 像一位懂业务的同事——用户说人话，它按规范执行，并把可验收的结果交回来。

围绕这个目标，我们按 Agent Skills 开放标准 设计并落地了 4 个核心业务 Skill + 1 个培训 Skill，组成完整的「商品上架自动化」能力包；数据分析场景则另有一套基于数据资产规范的分析 Skill（见场景四）：

上架相关的四个 Skill 可以独立使用，也可以串联成完整流水线；数据分析 Skill 则把「隐性数据知识」沉淀为可执行能力——这正是 WorkBuddy「多步骤任务自主规划」最擅长的场景。

03 四个真实场景：工程师怎么用，业务同事怎么用

场景一：批发平台链接 → 电商后台上架（最常用）

以前：打开货源页面 → 截图/下载图片 → 复制字段 → 登录电商后台逐项填写，一件商品约 15～30 分钟。

现在：在 WorkBuddy 里说一句话：

帮我把这个批发平台的商品同步过来，并提交到我们电商后台：
[粘贴商品详情页链接]

WorkBuddy 会自动：

1. 打开专用 Chrome，确认商品页面可访问
2. 同步商品数据与图片，保存到本地
3. 按映射规则整理标题、货号、价格、类目、属性、规格
4. 展示员工友好的确认摘要（不是 JSON，是中文条目）
5. 用户回复「确认发布」后，调用平台接口提交上架

全程用户只说业务语言：货号、主图、规格、发布账号——不会看到内部数据结构、脚本名、API 等术语。

场景二：供应商相册批量同步 → 选择性上架

很多货源分散在供应商相册类平台里，一次可能要同步几十家店铺、上千款商品。

以前：人工翻相册、逐款保存，几乎不可规模化。

现在：

帮我把所有关注店铺近 3 个月的商品同步到本地。

WorkBuddy 会引导完成平台扫码登录，批量同步商品数据与图片。同步完成后，还可以继续：

把刚才新同步的商品，整理成上架资料，先给我看摘要，不要发布。

Skill 之间通过明确的编排边界衔接：同步 Skill 负责数据拉取与字段映射，上架 Skill 负责整理与确认门禁——各司其职，不互相污染。

场景三：本地图片直接上架（无需外部同步）

有些同事手里只有商品实拍图和简单文字，没有外部平台链接。

帮我把这几张商品图上架，货号 ABC123，价格 89，类目女装连衣裙。

WorkBuddy 会：

• 根据图片推断类目、属性、颜色尺码（低置信时会追问）
• 把本地图片上传到平台，替换为可访问的 URL
• 生成确认摘要，等用户明确确认后才真正发布

这里有一个我们刻意设计的安全门禁：默认必须用户说「确认发布」才会调用真实接口；只有明确开启「无人值守模式」时才跳过确认——避免 AI 误发商品。

场景四：业务运营数据分析——从「找数、导数、猜数」到「问一句、拿结论」

以前：运营同事想做一次数据分析，往往要跨好几个人、好几步：

1. 定口径：先找数据同学确认「这个指标从哪张表取、怎么算、有没有坑」
2. 导数据：再提需求从 Hive / MySQL 导数，或自己写 SQL 但经常拿不准表和字段
3. 人工分析：Excel 里透视、对比、找原因——分析思路全靠人脑，重复问题每次从头来

瓶颈不在「会不会写 SQL」，而在数据知识散落在人脑子里——表结构、字段含义、业务规则、指标口径，新人问一遍、老人答一遍，很难沉淀。

现在：我们把核心数据表按 「数据资产定义与管理规范」 系统整理，再封装成 Skill，通过 MCP 直连 Hive / MySQL，让 WorkBuddy 帮业务运营直接做分析。

第一步：把「隐性数据知识」变成可执行的 Skill

工程师侧先把每张核心表按标准模板整理成结构化文档，覆盖四块内容：

整理完成后，不是丢进 Wiki 吃灰，而是封装进数据分析 Skill——Agent 读 Skill 就知道该查哪张表、用什么口径、有哪些业务边界（比如「交易订单不含特定类型的非交易单」）。

第二步：MCP 连接 Hive / MySQL，WorkBuddy 直接查数

Skill 里写清楚数据资产；执行层通过 MCP 连接器 对接 Hive / MySQL。业务同事在 WorkBuddy 里用自然语言提问，Agent 会：

1. 理解分析目的，匹配 Skill 中的表与指标定义
2. 自动生成并执行查询（无需人工导 CSV）
3. 按业务口径解读结果，输出可读结论

典型对话示例：

帮我看一下上周某品类的 GMV，按商家 TOP 10 排名，并对比上上周的变化。

最近 7 天新注册用户的下单转化率是多少？和上个月同期比怎么样？

帮我分析一下某商家近 30 天的退款率异常原因，看看是哪些 SKU 拉高的。

WorkBuddy 会自主完成「选表 → 写查询 → 取数 → 解读」，运营同事不需要知道表名、字段名、SQL 语法——只需要说清楚「想看什么、对比什么、找什么原因」。

和场景一～三同一套工程思路

数据分析 Skill 与上架类 Skill 遵循同一套工程原则：

• 用户层：运营只说「GMV」「转化率」「商家排名」，不说内部表名、状态码
• 执行层：Skill 里沉淀表结构、口径、血缘；MCP 负责连库查数
• 渐进式披露：核心表清单和常用指标在 SKILL.md，单表细节在 references/ 按需加载
• 可迭代：新增一张表或改一个口径，更新 Skill 文档即可，全员生效

04 工程师视角：写好 Skill，比写好脚本更重要

作为工程师，我们最大的体会是：WorkBuddy 的上限，不取决于模型有多聪明，而取决于 Skill 有没有把业务边界写清楚。

在落地过程中，我们总结了几条可复用的工程原则——也适用于任何想在 WorkBuddy 上交付 Skills 的开发者：

1. 用户层与执行层分离

• 用户看到的：「正在整理上架资料」「请核对商品信息」「已提交上架，任务编号 xxx」；或「上周某品类 GMV 为 xxx，较上上周增长 x%」
• Agent 内部执行的：脚本参数、结构化数据、SQL 查询、配置文件路径

业务同事不需要懂技术，WorkBuddy 也不应该把技术细节复述给用户。

2. 渐进式披露，控制上下文

SKILL.md 只写核心指令和编排顺序；字段映射、API 契约、单表数据资产细节下沉到 references/ 目录，按需加载——既保证 Agent 执行准确，又不撑爆上下文窗口。

3. 随包自包含，安装即可用

每个 Skill 目录自带脚本、虚拟环境安装指引、配置示例。用户通过一键安装包拿到 Skill 文件夹后，不依赖整个代码仓库就能运行——这是可交付与「只能在开发机跑」的根本区别。

4. 正向契约，不写历史包袱

Skill 文档只描述「当前应该做什么」，不写「不要用旧字段」「不要传旧参数」——让 Agent 始终面向最新业务规则，而不是在兼容说明里迷路。

5. 培训也是 Skill

培训引导 Skill 会在安装完成后主动问候，给出多个场景的培训菜单，并提供可直接复制发送的示例话术。非技术同事的 onboarding 成本，从「读 20 页文档」变成「跟 AI 聊 3 分钟」。

6. 数据类 Skill 的关键不在 SQL，而在数据资产文档

先把表结构、口径、血缘按规范模板整理清楚，再封装进 Skill；MCP 只负责执行查询。运营问「GMV 怎么算」，Agent 读 Skill 就知道口径，而不是每次临时猜。

05 交付形态：一句话安装，全员可用

我们把上架相关的 Skills 打成一键安装包，最终用户只需：

1. 安装 WorkBuddy
2. 对 WorkBuddy 说：

帮我安装 skills，skill 包下载地址为 [内部分发包地址]，
具体安装方法参考下载文件中的部署文档。

Agent 会自动下载、解压、安装依赖，并通过培训引导 Skill 带用户完成首次上手。

数据分析 Skill 则按同样思路交付：数据资产文档随 Skill 打包，MCP 连接器在 WorkBuddy 中配置 Hive / MySQL 访问权限即可。

这意味着：工程师写一次 Skill，业务全员复用；WorkBuddy 负责执行，人负责确认关键决策。

06 效果：从「人驱动工具」到「AI 交付结果」

更重要的是：WorkBuddy 交付的是本地可验收的结果——同步的结构化数据、下载的图片、生成的上架草稿、数据分析结论与图表——不是一段需要人工再整理的聊天回复。

07 给工程师的建议：从第一个 Skill 开始

如果你也在用 WorkBuddy，想把重复业务流程变成可复用能力，建议从这几步起步：

1. 选一个最小闭环：不要一上来就做「全能 Skill」，先做一个「输入 URL → 输出结构化文件」或「输入分析问题 → 输出查数结论」的原子能力。
2. 按 Agent Skills 标准写 SKILL.md：name、description（写清何时触发）、核心指令、Constraints。
3. 在 WorkBuddy 里跑真实对话：用业务同事的真实话术测试，而不是工程师视角的精确指令。
4. 把培训写进 Skill：降低交付成本，比优化脚本性能更重要。
5. 数据类场景先整理数据资产：用规范模板把核心表、指标口径、血缘关系写清楚，再封装 Skill + 接 MCP。

WorkBuddy 已内置 50+ 种 Skills，也支持零代码新建或导入 OpenClaw 兼容 Skills——能力可以无限扩展，关键是你愿不愿意把团队经验写成 Skill。

写在最后

WorkBuddy 这次升级，对我们工程师来说最大的变化不是「多了一个 AI 对话框」，而是多了一种交付形态：

把业务 know-how 封装成 Skill → 安装到 WorkBuddy → 业务同事用自然语言调用 → AI 自主规划、执行、交付可验收结果。

从多平台货源同步到电商后台上架，从相册批量铺货到新人 3 分钟上手，从运营问一句 GMV 到分钟级分析报告——这些不再是各自为战的脚本和文档，而是一组可安装、可培训、可迭代的能力包。

如果你也在探索「AI 怎么真正进业务」，欢迎下载 WorkBuddy，从你的第一个 Skill 开始。

WorkBuddy 官网：https://www.workbuddy.cn