如果你把 Mac Studio M2 Ultra 当作“家庭私有 AI 生产机房”，那真正决定系统可交付的，往往不是 ComfyUI 跑得多快，也不是 RAG 回答多聪明，而是两件事：

1. 资产是否可追溯（哪一版素材、哪一版文案、哪一次上架、哪一轮客服对话）
2. 系统是否可回滚（发现侵权/素材不合规/文案踩雷，能不能一键定位并撤回）

这一篇我们就做一件“看似土、但极其工程化”的事：统一目录结构、命名规范、版本策略、以及 SSOT（单一事实源），让 Make Agents、ComfyUI、RAG、Shopify 之间的协作变得可控。

---

1）核心原则：目录是你的“数据库”，命名是你的“主键”

在电商 AI 自动化里，一切资产最终都要落盘：

• 输入：产品白底图、供应链资料、竞品截图、卖点笔记
• 过程：ComfyUI 生成物、质检记录、参数与模型版本
• 输出：主图/场景图/详情页、Listing 文案字段包、上架 payload
• 运营：广告素材版本、A/B 测试、客服对话与问题归因

所以我们先确定三个硬原则：

• H1：同一 SKU 的所有东西必须落在同一个“SKU 根目录”下
• H2：任何可变内容必须版本化（V001/V002…）
• H3：任何可自动化编排的内容必须结构化（JSON/YAML/CSV），而不是散落的文本

---

2）你要的不是“文件夹”，而是“资产流水线拓扑”

下面这张图，你可以理解为本专栏的“文件系统协议”。

你会发现：这不是“好看”的目录，而是为了 Make Agent 可以定位、读写、审计。

---

3）推荐目录结构（可直接复制使用）

以单个 SKU 为单位，目录结构建议如下（示例 SKU：PET-BRUSH-001）：

• 00_meta/：SKU 元信息与 SSOT（强制存在）
• 01_input/：输入资料（原图、参考、供应链）
• 02_gen/：ComfyUI 输出（主图/场景/详情 + 质检）
• 03_copy/：RAG 输出（字段化文案包 + 版本）
• 04_publish/：上架输出（payload、截图、回滚信息）
• 05_ops/：投放与 A/B（素材、落地页、实验记录）
• 06_cs/：客服对话与问题归因
• 99_logs/：流水线日志与审计

---

4）命名规范：用“可机器解析”的格式，避免人为歧义

4.1 统一命名的四段式

建议所有核心文件名遵循：

{SKU}__{ASSET_TYPE}__{CHANNEL}__V{NNN}

• SKU：唯一标识，如 PET-BRUSH-001
• ASSET_TYPE：资产类型（img-main / img-scene / img-detail / copy / payload / qa）
• CHANNEL：渠道或规格（shopify / tiktok / xhs / meta-ads / 800x800）
• VNNN：版本号（V001 起）

示例：

• PET-BRUSH-001__img-main__shopify-800x800__V003.png
• PET-BRUSH-001__img-scene__meta-ads-1200x628__V001.png
• PET-BRUSH-001__copy__shopify__V002.json
• PET-BRUSH-001__payload__shopify__V001.json

4.2 为什么要把“渠道/规格”写进文件名？

因为你后面一定会出现：

• 同一张图要裁 800×800、1200×628、1080×1440
• 同一套文案要适配 Shopify、TikTok Shop、独立站落地页
• 同一 SKU 要跑多轮 A/B（版本号必须能区分）

把“规格”写在文件名里，你就能做到：搜索即定位，脚本也能做批处理归档。

---

5）SSOT（单一事实源）：每个 SKU 必须有一份“真相文件”

你这条生产线的“真相”不在 Excel，也不在口头沟通，而在一份结构化元数据里。

建议在每个 SKU 的 00_meta/ 下放一个：

• sku.json（主元信息）
• mapping.json（字段映射：Make/Shopify/Notion）
• policy.json（合规与禁词/禁图规则）
• versions.json（素材与文案版本索引）

5.1 SSOT 里至少要包含什么？

最低配置（建议）：

• SKU 基本信息：类目、成本、售价、毛利、目标平台
• 视觉约束：风格、背景库、光照、禁用元素
• 文案约束：品牌词表、禁词、语气、语言
• 上架字段映射：title、body_html、tags、images、variants
• 版本索引：当前“生产可用”的素材版本与文案版本（类似 current_release）

---

6）版本策略：用“发布版本”而不是“最近版本”

很多人版本号越滚越大，但最后上架用的是哪一版，没人说得清。

所以建议你引入两个概念：

• Work Version（工作版本）：V001/V002…，不断试错
• Release Version（发布版本）：R2026-01-16 这种“可交付快照”

目录层面可以这样组织：

• 02_gen/release/R2026-01-16/
• 03_copy/release/R2026-01-16/
• 04_publish/release/R2026-01-16/

这一步的价值在于：回滚只需要回到某个 Release 目录，而不是翻文件海。

---

7）把目录标准“变成自动化”：Make Agent 只要遵循协议就能跑

当你的目录与命名足够严格，你才能让 Make 的编排层“少做判断，多做执行”，比如：

• “为 10 个 SKU 生成主图与文案”
• Agent 拆任务 → 调 ComfyUI → 归档到 02_gen/ → 写版本索引 → 调 RAG → 保存到 03_copy/ → 生成 payload → 放到 04_publish/

这一切的前提，是 路径与命名是稳定协议。

---

8）你可以直接照做的“最小落地清单”

本篇不讲虚的，给你一个落地 checklist：

• 每个 SKU 建立固定目录（00/01/02/03/04/05/06/99）
• 所有核心文件名遵循四段式命名（SKU__type__channel__VNNN）
• 00_meta/sku.json 作为 SSOT 强制存在
• 引入 Release 版本快照（RYYYY-MM-DD）
• ComfyUI 输出必须回写“参数与工作流版本”
• RAG 输出必须是“字段化 JSON”，不要散文式文案
• 上架必须保存 payload 与发布记录（可回滚）

---

评论区互动

1）你更偏向用哪种“资产主索引”？
A. sku.json 为主（推荐）
B. Notion 为主（SSOT 在 Notion）
C. Google Sheet/Excel 为主

2）你希望目录标准覆盖到哪个粒度？
A. 只到 SKU 级
B. 要到素材规格级（800x800、1200x628…）
C. 要到每次投放实验（A/B 的版本、数据回流）

你在评论区回复“1A/1B/1C + 2A/2B/2C”，我下一篇可能就按你的选择，把“服务编排、自启动、健康检查、日志与告警”写成一套可复制的机房运行手册。