本文由 莫潇羽@复源AI社区（bbs.fuyuan7.com） 撰写，转载请注明出处。
快速摘要
这篇文章讲的不是"怎么用 AI 生成一张图"，而是把 WorkBuddy 当成一个"电商内容中台"来搭：一个 SKU 只录一次，后面主图、详情页、模特图、场景图、对标风格、带货视频全部串起来批量产出。文中给出一套我自己设计的五 Skill 编排方案（商品档案、模特场景池、主图详情页流水线、对标账号拆解、视频导演），每个 Skill 的字段结构、SKILL.md 关键片段、判断逻辑我都写了出来。核心目标是三件事：资产复用率拉满、批量并发省时间、全流程符合 2025 年 9 月起实施的 AI 内容标识办法和主流平台的最新规则。文末给了一个"一天上二十个新品"的实操流程模板，可以直接对着抄。
想看完整拆解，往下翻。
一、为什么普通商家用 AI 越用越乱，而系统化玩家已经批量出货
我这半年前前后后跟不少电商老板聊，发现一个特别扎眼的现象：几乎每个店都在用 AI 生图，用 AI 剪视频，但真正把 AI 变成"生产线"跑起来的，十家里不到一家。绝大多数还停在"打开某某工具，输一句提示词，等半分钟，看着还行就存下来"这种散点式的玩法。
问题不在工具本身，而在用法。散点式的用法有三个致命毛病，越用越明显。
第一个是碎片化。今天用 A 工具画主图，明天用 B 工具做详情页，后天开 C 平台生成短视频。产物散落在电脑各个文件夹里，命名规则一人一样，用完就找不到。想复盘"上次那个爆款主图到底是怎么写的提示词"，得翻半小时聊天记录。这不是 AI 的问题，是没系统。
第二个是没有复用。同一个模特，穿完 A 商品就没了；下次上新品，从零再拉一次提示词、再抽卡二十次、再挑一张凑合的。同一套场景，第一个视频用完，下一个视频完全不知道去哪找。等于每上一个新品都是从零开始，AI 的边际成本一直是满的，根本没有把过去的产出攒下来当资产用。
第三个是上新就重来。每来一个新品，得重新描述卖点、重新写主图脚本、重新找对标博主、重新研究这个赛道的拍法。老板以为雇了 AI 就能省人，结果发现 AI 只是省了执行环节，前面的"理解商品、匹配调性、规划内容"这些活儿还是自己在干，还得干很多遍。
我做过一个粗略估算：一个中等规模的服装店，一个月上二十款新品，如果用散点式的 AI 用法，每款平均要花三到四个小时才能凑齐"主图+详情页+短视频"这一套内容；如果把系统搭好，同样二十款新品，平均下来单款能压到二十到四十分钟。差别就在于有没有资产库、有没有 Skill 编排、有没有审核动线。
那为什么我最后选 WorkBuddy 来搭这套系统，而不是自己写脚本调 API？三个原因。
第一个原因是 Skills 生态可以直接把复杂动作封装起来。 WorkBuddy 的 Skill 本质上就是一个 SKILL.md 文件加一堆脚本工作流，你把某个复杂任务（比如"给一个新商品建档"）写成一个 Skill，以后每次触发它，就是一行斜杠命令。装好了之后所有商品都走同一套流程，字段规范、命名规范、状态机规范都能自动落到位。这个和自己写 Python 脚本的区别在于，Skill 是能被自然语言触发和参数化的，不用你每次改代码。
第二个原因是国内网络不折腾。 我早期试过用境外的编程 Agent（比如 Codex 之类）来做同样的事情，效果确实不差，但网络一直是个坎。图片生成偶尔超时，视频生成经常返回失败，登录 token 时不时得重新处理。WorkBuddy 服务器在国内，模型走的是腾讯自己的通道，还能挂上 Hunyuan、DeepSeek、GLM 这些国产旗舰模型，不用为了跑通一个工作流去操心那些和业务没关系的事。
第三个原因是可以联动腾讯生态和国内主流工具。 比如商品资料放在腾讯文档里，Skill 可以直接拉取；生成的图片可以走企业微信推给运营；对接抖音的分析工具或即梦的 CLI 也很顺畅。这些都不是"能不能做到"的问题，是"顺不顺手"的问题。做电商内容不是写论文，顺手比高大上重要一百倍。
搞清楚了"为什么系统化"和"为什么选它"，接下来就是最关键的问题：这套系统到底长什么样，怎么拆，怎么在 WorkBuddy 里落地。这一部分我拆了整整一章讲清楚。
二、整套系统的三层结构：资产层、Skill 编排层、审核交互层
我先把架构图放这里，后面的每一节都是在给这张图里的某个模块添肉。
flowchart TB
subgraph L3[审核交互层：让人只做判断，不做执行]
UI[资产面板 / 审核台]
end
subgraph L2[Skill 编排层：把复杂任务封装成一句指令]
S1[商品档案 Skill]
S2[模特场景池 Skill]
S3[主图详情页 Skill]
S4[对标拆解 Skill]
S5[视频导演 Skill]
end
subgraph L1[资产层：一切复用的地基]
A1[商品档案库]
A2[模特资产库]
A3[场景资产库]
A4[风格模型库]
A5[素材产出库]
end
UI --> S1 & S2 & S3 & S4 & S5
S1 --> A1
S2 --> A2 & A3
S3 --> A5
S4 --> A4
S5 --> A5
A1 & A2 & A3 & A4 --> S3 & S5我把整个系统拆成三层，从底到上分别是资产层、Skill 编排层、审核交互层。这个拆法不是随便定的，是经过几轮踩坑后我个人认为最健康的一种分法，理由后面细说。
2.1 资产层：所有能复用的东西都放这里
资产层是这套系统的地基，也是决定你到底能省多少时间的关键。我把它分成五类：
- 商品档案库：每个商品的结构化档案，包括基础信息、SKU 矩阵、卖点、目标人群、类目属性等。这是所有下游内容生成的输入源。
- 模特资产库：可以反复复用的模特底图、三视图、穿搭图。同一个模特可以给多个商品做代言。
- 场景资产库：分成两种，一种是"空场景"（比如街边橱窗、咖啡店窗边、家居飘窗），可以反复复用；另一种是"复合场景"（模特 + 商品 + 场景的三合一图），一次性的。
- 风格模型库：对标账号拆解之后沉淀下来的 JSON 风格模型，描述"这个博主的视觉调性 / 剪辑节奏 / 常用动作 / 场景习惯"等，用于后续生成视频时套用。
- 素材产出库：最终产出的主图、详情页、视频文件，按商品-SKU-场次组织。
所有资产都放在 WorkBuddy 的工作空间下的固定目录结构里。我推荐的目录布局是这样的：
ecommerce-content-factory/
├── assets/
│ ├── products/ # 商品档案（每个商品一个 JSON + 一个图片文件夹）
│ │ ├── SKU-000012/
│ │ │ ├── profile.json
│ │ │ ├── raw-images/
│ │ │ └── outputs/
│ ├── models/ # 模特资产
│ │ ├── MDL-000003/
│ │ │ ├── portrait.png
│ │ │ ├── three-view.png
│ │ │ └── meta.json
│ ├── scenes/ # 场景资产
│ │ ├── empty/ # 可复用空场景
│ │ └── composite/ # 一次性复合场景
│ ├── style-models/ # 对标风格 JSON
│ └── outputs/ # 最终交付物
├── skills/ # 你自定义的所有 Skill
└── logs/ # 每次调用的日志和审核记录这个目录结构不是我拍脑袋定的，是踩过坑之后总结的：能不能高效复用，取决于命名规则和目录深度是不是稳定。规则一旦定下来就不要频繁改，改一次所有历史 Skill 都得跟着改索引路径，得不偿失。
2.2 Skill 编排层：把复杂任务封装成一句指令
Skill 编排层是这套系统的"大脑"。我一开始也想过要不要拆得非常细，比如"生成主图-白底图"是一个 Skill，"生成主图-场景图"又是一个 Skill。后来发现拆得太细反而难维护，也不方便串起来。我最后收敛到五个 Skill：
|
Skill 名称 |
主要职责 |
输入 |
输出 |
触发时机 |
|
商品档案 Skill |
类目识别、字段自适应、多 SKU 建档 |
商品原始图 + 卖家资料 |
结构化 profile.json |
新品入库时 |
|
模特场景池 Skill |
模特和空场景资产的生成与复用调度 |
商品调性 + 目标人群 |
模特图 + 场景图 |
上新品或做新场景时 |
|
主图详情页 Skill |
主图矩阵和详情页分段的批量出图 |
商品档案 + 模特 + 场景 |
主图组图 + 详情页图 |
建档完成后 |
|
对标拆解 Skill |
对标账号数据抓取 + 风格化蒸馏 |
对标账号主页链接 |
风格模型 JSON |
找到新对标或增量更新时 |
|
视频导演 Skill |
从故事版到成片的视频链路 |
商品 + 模特 + 场景 + 风格模型 |
分镜图 + 视频文件 |
有成片需求时 |
五个 Skill 之间不是孤立的，前四个都是在为最后一个"视频导演"打地基。第五个之所以放在最后，是因为它是最耗时、最耗积分、最需要人工审核的环节，也是把前面所有资产整合起来输出最终产物的环节。
每个 Skill 我都建议在项目级别管理，而不是个人级别。原因很简单：项目级 Skill 在云端统一管理，双端一致 ，团队里任何一个人（无论用客户端还是 Web 端）都能调到同一版本。个人库和项目库是隔离的，云上任务只能选到云上的 Skill，客户端任务只能选到客户端库的，一开始不注意这个坑很容易踩。
2.3 审核交互层：让人只做判断，不做执行
这一层的存在意义特别简单：电商内容里 AI 只能负责生成，最终能不能上架必须由人拍板。所以每个 Skill 在关键节点必须留一个"人审"的卡点。
我的做法是让每个 Skill 在关键节点都输出一个格式统一的"审核卡片"，包含四个字段：
- 状态（草稿 / 待审 / 通过 / 打回）
- 产物预览（图片或视频缩略图 + 关键文本）
- 一键操作指令（"通过"、"打回并说明原因"）
- 上下文摘要（这一步用了哪些资产、什么提示词）
用户看到审核卡片之后，回复一句话（"通过"或者"打回，前三个镜头太雷同，改成不同的机位"），Skill 就继续往下走或者返工。这样做的好处是把和 AI 的交互从"打字型"变成了"按钮型"，运营同学不用背提示词，也不需要理解底层原理，看图判断"能不能用"就行。
WorkBuddy 客户端里其实已经支持 Markdown 渲染，所以审核卡片可以直接用 Markdown 表格加一段引导话术呈现。要更专业的话可以做一个本地网页，把所有商品的当前状态汇总成一个可点击的面板，但我个人觉得先跑通再美化，直接用 Markdown 卡片就够用了。
2.4 关键变量的传递链路：一图看懂谁引用谁
这套系统里有几个关键 ID 会在各个 Skill 之间反复传递，一开始容易搞混。我用最简单的方式把传递链路画一下，读到后面各章节的时候可以回来对照：
[原始商品图 + 卖家资料]
↓ 商品档案 Skill
product_id (例：SKU-2026-000012)
↓
├──→ 模特场景池 Skill
│ ↓
│ MDL_id (例：MDL-000003) —— 记录到 product_id 的关联表里
│ SCN_id (例：SCN-000018) —— 空场景资产库编号
│
├──→ 主图详情页 Skill
│ 输入：product_id + MDL_id + SCN_id
│ 输出：assets/products/{product_id}/outputs/*.png
│
└──→ 对标账号拆解 Skill (与 product_id 无关，独立跑)
↓
STYLE_id (例：STYLE-000042)
↓
视频导演 Skill
输入：product_id + MDL_id + SCN_id + STYLE_id
输出：assets/products/{product_id}/outputs/*.mp4核心记忆点只有一条：product_id 是整条链路的锚，其他 ID（MDL / SCN / STYLE）都是通过"关联表"挂在 product_id 下面的可选资产。商品档案里维护一个 related_assets 字段专门记这些关联，下游 Skill 触发时先读档案，就能知道要拉哪些资产出来用。
想不清楚流程的时候，回来看这张图。
2.5 从架构到实操：接下来怎么读这篇文章
三层结构讲完了，接下来的几章会挨个把五个 Skill 的具体设计、SKILL.md 关键片段、字段结构、判断逻辑写清楚。莫潇羽@复源AI社区的一贯风格，讲干货不端着，能给伪代码的绝不只画图。
如果你是完全没用过 WorkBuddy 的新手，建议这个阅读顺序：先跳到第九章看"冷启动 —— 先跑通最小闭环"，再回来按第三章学装 Skill，然后从第四章开始按顺序看具体实现。这样能让你保持"我在往一个具体目标推进"的感觉，而不是被架构章节淹没。
如果你已经有 WorkBuddy 使用经验，就按当前顺序往下读。
三、Skill 从哪里来，往哪里去：安装、管理和从零沉淀的方法论
聊具体的电商 Skill 之前，我先花一章说清楚一件事：Skill 到底怎么装进 WorkBuddy，怎么管，以及最关键的 —— 怎么把你踩坑总结出来的一套操作步骤，反过来沉淀成一个可以反复调用的 Skill。这一步很多教程都跳过了，导致新手看完之后觉得"哦，Skill 好像很厉害"，但轮到自己动手时压根不知道从哪儿下手。
3.1 三种装 Skill 的方式，分别适合什么场景
WorkBuddy 里装 Skill 有三条主路径，我按"从省事到自定义程度最高"排一下顺序。
第一条路：从 SkillHub 官方市场直接找。 打开 WorkBuddy 客户端，进"技能"面板，点"查找技能"，输入你要干的事的描述，系统会推荐匹配的 Skill。这是最省事的路径，官方推荐的 Skill 都做过基本审核，权限申请、脚本内容都是可见的。做电商内容的话，SkillHub 里常见的能直接用的有：网页无头浏览器（用来跑对标账号数据抓取）、PDF 解析、Excel 批处理、图片压缩、文件批量重命名等。这些属于"通用工具型"Skill，装完就能给你自定义 Skill 当积木用。
第二条路：导入别人写好的本地技能包。 在"技能"面板点"上传技能"，把一个 .zip 或者 SKILL.md + 相关脚本的文件夹拖进去，系统自动完成配置。这条路适合你从社区、GitHub、公司内部拿到别人调好的 Skill 直接用。不过这里有个安全提醒必须注意：非官方 Skill 存在被注入恶意提示词、越权访问文件、留后门程序等风险。Skill 调用第三方接口、修改本地文件、执行系统命令时，都是以你本人身份执行的。涉及批量写入、删除、系统配置变更、支付类操作的 Skill，第一次务必先在测试目录里跑一遍，别一上来就对着真实资产文件夹开火。
第三条路：自己写。 这也是我这套电商系统里所有 Skill 的来源。SKILL.md 用 YAML 头 + Markdown 正文的语法，结构非常简单，会写 Markdown 就能上手。自己写 Skill 的价值在于：它跟你的实际业务耦合度最高，字段结构、命名规则、审核卡点全都按你的意思来，一次配好后续多人复用。
装好之后管理层面还有几个坑要提前避开。个人库和项目库是隔离的，客户端个人库里的 Skill 只能在客户端个人任务里用，云上任务只能用云上库里的 Skill；跨端要用，就得把 Skill 提升到项目级。Skill 建议做版本管理，YAML 头里加一个 version 字段，改动大的时候写清楚 changelog，新版本先在测试环境跑通再推到正式项目。我自己的习惯是每个 Skill 目录下加一个 CHANGELOG.md，比 Git commit 更直观。
3.2 把一次成功的操作沉淀成 Skill 的四步法
这是我最想跟你分享的一段，因为这一步没走通，你装再多别人的 Skill 也解决不了自己的问题。做电商内容尤其如此：每个店的类目、SKU 组织方式、审美偏好、目标平台都不一样，别人的 Skill 是别人的最优解，不一定是你的。
我总结了一个"从案例到 Skill"的四步法，每一步都有具体的检查点。
第一步：只封装"跑通三次以上"的动作。 这是最重要的一条规则。如果你只是偶尔要做一次某个操作，就用助理模式聊天式地跑一次；如果你发现自己连续三次以上在做同一件事（比如三次都在给不同商品写主图提示词、三次都在整理同一种格式的商品表），那这个动作值得沉淀成 Skill。低于三次频次的动作沉淀出来是负资产，维护成本大于收益。
第二步：先在助理模式跑通完整流程，把过程完整记录下来。 不要一上来就写 SKILL.md，先在普通对话里跑一遍完整流程。跑的过程中打开录屏或者边操作边做笔记，重点记三件事：每一步你给 AI 的指令原话是什么、AI 每一步的产出是什么、你在哪些节点做了修正。这些原话和修正就是你未来 SKILL.md 里最有价值的部分 —— 它们浓缩了你的领域知识。
第三步：把流程翻译成 SKILL.md 的三大块。 一个健康的 SKILL.md 结构基本上是三块：元数据头（YAML 里的 name、description、version）、触发条件描述（description 字段里详细说什么时候该用这个 Skill，越具体越好，防止误触发）、执行规则正文（Markdown 写的操作规范，包括输入、步骤、约束、输出格式、审核卡点）。我给你一段电商类 Skill 的最小模板：
---
name: product-archive-v1
description: 用于给新的电商商品建档。触发条件：用户上传商品图片
或提供商品资料目录路径，并要求"建档""录入""入库""建立档案"。
也适用于用户提到"新品上架"、"整理这个 SKU"等
