做电商运营的人都熟悉这个场景：同一款货，天猫、京东、抖音、拼多多各填一遍，属性名不一样、枚举值不一样、主图尺寸不一样、标题字数上限也不一样。上新一款还能忍，一次上二十款就开始怀疑人生。
这件事特别适合交给 Agent，但它不是「让模型写文案然后一键发布」那么简单。真正决定成败的是主数据和映射表，模型只负责填空和改写。这篇讲的是怎么把上架做成一条可重跑的流水线。
一、先划清：上架不是售后，也不是盯竞品
站内相邻的三块先说清分工：电商订单与售后处理管的是订单进来以后（改地址、退换货、异常件）；竞品价格监控管的是看别人改了什么价；本篇管的是商品从「仓里有货」到「在平台上能被搜到、被看懂、被下单」这一段。
这段的产出物不是一篇文案，而是一份能通过平台校验的商品记录。平台校验不过，文案写得再好也上不去。所以整条流水线的重心，应该放在「结构化字段」上，而不是「文采」上。
二、商品主数据：SPU 和 SKU 先拆开
上架乱，八成是主数据没拆干净。先把两个概念钉死：
- SPU = 一个款。共享标题、卖点、详情页、类目。比如「XX 牌保温杯 500ml」。
- SKU = 一个可售单元。颜色、尺码、容量、套装组合，任何一个变化都是新 SKU。
落到表上就是两张表：一张商品主表（SPU），一张 SKU 表（价格、库存、条码、规格值）。其余都是视图，不是第三张表。三件必须先定的事：SPU 主键用什么（自建编码，别用平台商品 ID）、SKU 编码怎么生成（建议「SPU 码 + 两位变体序号」）、变体关系怎么表达（哪个属性是销售属性、哪个是普通属性）。
为什么强调别拿平台商品 ID 当主键？因为同一款货在四个平台是四个 ID。你一旦用它做主键，主数据就被平台绑死了，换平台等于重建。
三、类目属性：必填项决定能不能上架
平台的类目属性分三层，Agent 要分别处理：
- 类目路径：叶子类目决定后面出现哪些属性。选错类目，属性全错，搜索也搜不到。
- 类目属性：分必填、选填、以及带枚举值的下拉。枚举值必须照抄平台原文，不要自己造同义词——「不锈钢」和「304 不锈钢」在平台眼里是两个值。
- 销售属性：颜色、尺码这类生成 SKU 的属性，决定变体矩阵的维度。
还有两个特别容易被忽略的点：单位与精度（克还是千克、厘米还是毫米，填错就是十倍百倍误差）和多值字段的分隔符（有的平台用逗号，有的用竖线，有的只认多选）。这些细节建议单独列一张「平台怪癖表」，比写在提示词里靠谱。
遇到属性填不出来，只有两条路：补数据，或者换类目。换类目会影响搜索流量，属于业务决策，Agent 不应该自己换。
四、标题与卖点：搜索词从哪来
标题不是创作，是匹配。三个可靠来源，按优先级排：
- 平台搜索下拉与搜索词报告：用户在搜索框里真实敲的词，最接近成交意图。
- 客服高频问法：问「能装多少度水」的人多了，说明「保温时长」该进标题或卖点。
- 退货原因与差评：因为「尺寸比想象小」退货多，标题里就该写清容量，而不是等售后解释。
结构上建议：品牌 + 品类词 + 关键属性 + 场景或人群。品类词必须前置，因为在 60 字符的限制下，后面的词很可能被截断。同义词不要堆，堆了不加权，还拉低可读性。
卖点写「能验证的好处」，不写「高端品质」「匠心工艺」这类无法验证的话。可验证的意思是：这句话在参数表或详情页里能找到对应数据。写不出来的，就是编的。
五、主图与详情页：五段结构
图片这块先定规范，再谈生成。批量处理图片那套流水线可以复用，但上架图有额外的硬约束：
- 首图：白底或纯色底，主体占比 60%–80%，尽量不压文字。多数平台的首图校验是机器做的，压了字容易被判不合规。
- 规格：尺寸、比例、单图大小、最多几张，每个平台一张表。批量改尺寸时注意别拉伸变形。
- 详情页五段：解决什么问题 → 关键参数（必须与属性表完全一致）→ 与同类相比的差异点 → 使用场景 → 包装清单与售后承诺。
一条硬规则：详情图里出现的任何参数，都必须在属性表里有出处。图里写「耐温 -20℃ 到 120℃」而表里写 100℃，这不是文案问题，是合规问题。校验做法很简单——把图里的数字抽出来，和表里的字段做一次比对，不一致就退回。
六、多平台字段映射：一张表管到底
这是整条流水线最值钱的一张表。列这样设计：
- 我方字段名、字段类型、是否必填、取值范围；
- 平台 A 的字段名、是否必填、枚举值、长度上限；平台 B、平台 C 同理；
- 转换规则（直接映射 / 枚举翻译 / 拼接 / 截断 / 计算）；
- 备注（这个平台为什么要特殊处理）。
维护成 CSV 或在线表格，作为单一事实来源。Agent 每次上架都读这张表生成各平台的提交数据，而不是靠提示词记规则。这样平台改规则时，只改一行，不用改代码也不用改提示词。
枚举翻译要单独建字典，比如「颜色：藏青 → 平台 A 的 深蓝 → 平台 B 的 宝蓝」。这类映射看着琐碎，但它决定了批量上架的通过率。表格处理这块可以直接用Excel 自动化的思路，把映射表当输入、把各平台提交表当输出。
七、批量执行：试跑、限流和幂等
批量操作最容易出事的不是逻辑，是节奏。四件事必须做：
- 阶梯试跑：先 3–5 个 SKU 跑通，再看 20 个，最后全量。每一步都人工看一遍前台效果。
- 限流与串行：串行优于并发。平台的写接口限流通常不公开，保守取比激进试更省事。
- 失败分类：校验失败（改数据）、权限不足（改配置）、限流（等）、网络（重试）。四类处理方式完全不同，混成一个「失败重试」会把数据错误重试十遍。排查思路参考工具调用失败排查。
- 幂等：用「SKU + 平台 + 版本」做幂等键，重跑不重复建商品。所有写操作之前先查一次是否存在，存在就更新而不是新建。
还要有一张状态表：每个 SKU 在每个平台处于「待提交 / 已提交待审 / 已上架 / 审核驳回 / 失败」哪一档，驳回原因是什么。没有这张表，跑到一半断了就只能全量重来。这套思路和变更后验证清单是一回事——变更之后的核对，比变更本身更重要。
八、上架前自检八项，上架后核对三件
自检八项，做成一个 Agent 每次必跑的函数，不通过就不提交：
- 必填属性是否齐全（按映射表逐项对）；
- 枚举值是否都在平台允许范围内；
- 标题长度与敏感词是否合规；
- 主图规格（尺寸、比例、大小、张数）是否达标；
- 价格、划线价、库存是否填写且逻辑自洽（划线价必须高于售价）；
- 发货时效与运费模板是否绑定；
- 售后承诺（七天无理由、质保期）是否与类目要求一致；
- SKU 矩阵是否完整（每个销售属性组合都有对应 SKU，没有空档）。
上架后核对三件：前台能不能搜到（用核心词搜一遍，别只看后台状态）、搜索词能不能命中（长尾词试两个）、价格库存与后台是否一致（缓存和审核延迟都会造成不一致）。抽检比例和方式可以参考人工复核抽检，新品类全检，老品类抽检。
九、改价与下架：留痕比速度重要
上架之后就是维护，维护里最危险的动作是批量改价。三条规矩：
- 活动价与划线价分开管：活动价带时间窗，到点自动恢复；划线价是长期价，不能被活动价覆盖。
- 改价必须二次确认 + 变更前快照：把改之前的全量价格导一份出来。批量改价出错，唯一能救命的就是这份快照。
- 下架不删除：下架只是状态变更，删除是另一个权限。历史销量、评价、搜索权重都挂在商品上，删了就是归零。
如果要做价格实验，别直接改线上价，用A/B 实验那套思路，先定指标和护栏（转化率、退货率、毛利），再决定放量。
十、三条边界
- 不编造参数与资质：材质、认证、功效、产地，没有依据就不填。这类错误不是「优化」，是虚假宣传。
- 不伪造评价、销量和紧迫感：刷单、假库存倒计时、假「已售 10 万+」，短期有用，长期是封店风险。
- 不越权改价、不擅自删除：改价和删除属于高风险动作，必须有人确认。这条可以照客户可见动作的原则来设：只要外部可见，就要留最后一道人工确认。
工具权限上也要配合：给 Agent 的账号只开「创建/更新」，不开「删除」和「批量调价」。写工具的时候把这几个动作拆成独立工具，比在一个大工具里传 action 参数安全得多，设计思路见工具怎么设计。
十一、五个容易踩的坑
- 拿平台商品 ID 当主键：多平台一铺开就崩，想换平台等于重建主数据。
- 属性表照抄竞品：竞品的参数本身可能是错的，抄过来就是把别人的错误变成自己的责任。
- 图里写参数、表里没同步：最容易被平台判违规，也最容易被职业打假盯上。
- 一次性全量并发：限流、封 IP、审核堆积，出了问题还定位不到是哪个 SKU。
- 改价不留快照：回滚不了，只能一单一单手动改回去。
再补一个隐性的：用模型自由发挥填属性。属性和文案不一样，它要过校验、要参与筛选。让模型「理解一下自己填」，通过率会低得让你怀疑人生。正确做法是模型只在枚举范围内选，选不出来就留空交给人。
十二、总结
商品上架这件事，Agent 的定位应该很清楚：它是执行器，不是决策者。主数据、映射表、类目选择、价格策略这些是人定的；填表、改写标题、批量改图、跑校验、记录状态，这些是它干的。
如果只做一件事，我建议先把「多平台字段映射表」建起来。这张表建好，上架就从「每次重新理解平台规则」变成「按表填空」，效率和准确率都会立刻不一样。至于详情页那部分，本质上和自动出图表一样——规范和口径定在前面，生成才敢放量。
